Difference between revisions of "Implementing versioning"

From PegaWiki
Jump to navigation Jump to search
(draft 1-28 part 2)
Tag: Visual edit
(draft - 1-29)
Tag: Visual edit
Line 23: Line 23:
  
 
=== What affects versioning  ===
 
=== What affects versioning  ===
On the metadata screen of all entities, we have two properties
+
On the metadata screen of all entities, we have two properties  
  
 
1) Effective date
 
1) Effective date
Line 29: Line 29:
 
2) End date
 
2) End date
  
These two dates are the core properties driving the versioning logic in PCS.
+
These two dates are the core properties driving the versioning logic in PCS out of the box.
  
 
Whenever the user changes any one or both of these effective dates, the PCS application automatically creates a new major version for the new entity.   
 
Whenever the user changes any one or both of these effective dates, the PCS application automatically creates a new major version for the new entity.   
Line 39: Line 39:
 
#* If User A clicks Next after changing the effective date or end date or both, the next major version, 02-01, is assigned if there are no existing versions in the system with the new dates that were entered.  
 
#* If User A clicks Next after changing the effective date or end date or both, the next major version, 02-01, is assigned if there are no existing versions in the system with the new dates that were entered.  
  
=== Design inputs, how to plan versioning and updates ===
 
 
=== Extend versioning in PCS ===
 
=== Extend versioning in PCS ===
There is a centralized data page "D_NewVersion" which drives the versioning for all entities in PCS.
+
There is a centralized data page "D_NewVersion" found in the ruleset PegaHC-USA-PCS:08-01-01 which drives the versioning for all entities in PCS.  
  
User can find more details on use of data page at https://community.pega.com/sites/default/files/help_v85/index.htm#oxy_ex-1/platform-helpsystem/rule-/rule-declare-/rule-declare-pages/data-pages-con.htm    
+
User can find more details on use of data page at https://community.pega.com/sites/default/files/help_v85/index.htm#oxy_ex-1/platform-helpsystem/rule-/rule-declare-/rule-declare-pages/data-pages-con.htm
 +
 
 +
If the implementation team wants to change the default versioning logic, they can include any other property from the implementation layer or base PCS layer to the above data page.
 +
 
 +
There could be many scenarios under which the implementation team may want to enhance the versioning logic, like having open ended plans or controlling the versions of plans for a particular calendar year, or having the versioning for plans for a particular line of business or may be add versioning based on input requests from sales automation system.
 +
 
 +
=== Design inputs, how to plan versioning and updates ===
 +
The auditing needs of the organization should be kept in mind when trying to enhance the versioning logic by the implementation team. Any property
  
 
== Results ==
 
== Results ==
 
Understanding the configuration options available for the versioning logic is extremely critical for the implementation team. With this knowledge, the implementation team can act as informed advisor to the business team throughout the life of the project. Not only that, the implementation team can also facilitate and deliver quick results if the business team wants to extend the versioning logic to properties beyond the effective dates, without breaking any guardrails and being in compliance with Pega's best practices.
 
Understanding the configuration options available for the versioning logic is extremely critical for the implementation team. With this knowledge, the implementation team can act as informed advisor to the business team throughout the life of the project. Not only that, the implementation team can also facilitate and deliver quick results if the business team wants to extend the versioning logic to properties beyond the effective dates, without breaking any guardrails and being in compliance with Pega's best practices.

Revision as of 12:45, 29 January 2021


Curator Assigned shahp@pegasystems.com
Request to Publish
Description Implement versioning
Version as of
Application Pega Product Composer for Healthcare
Capability/Industry Area Healthcare

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ Please Read Below ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

Enter your content below. Use the basic wiki template that is provided to organize your content. After making your edits, add a summary comment that briefly describes your work, and then click "SAVE". To edit your content later, select the page from your "Watchlist" summary. If you can not find your article, search the design pattern title.

When your content is ready for publishing, next to the "Request to Publish" field above, type "Yes". A Curator then reviews and publishes the content, which might take up to 48 hours.

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ The above text will be removed prior to being published ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

Versioning in PCS[edit]

In Pega Product Composer for Healthcare, entities such as a benefit or plan can undergo changes in their life cycle. Workflows of these entities generally progress at different times in discrete phases. During a phase, user might need to allocate a different set of data or enforce different business rules. In these situations, user can represent the changes to an entity in time blocks. Each time block of an entity is a version.

The time block used in PCS are effective dates and these dates drive versioning for all entities in PCS.

Users can find detailed explanation about how versioning works in PCS at https://community.pega.com/knowledgebase/articles/pega-product-composer-healthcare-implementation-guide/85/versioning

What affects versioning[edit]

On the metadata screen of all entities, we have two properties

1) Effective date

2) End date

These two dates are the core properties driving the versioning logic in PCS out of the box.

Whenever the user changes any one or both of these effective dates, the PCS application automatically creates a new major version for the new entity.

  1. User A creates a new e-visit benefit. Version 01-01 is assigned by the application.
  2. User A moves the benefit to the Dev-Approved status. The benefit is now in the Dev Approved work queue and is available in the application’s search list with the Dev-Approved work status.
  3. Later, User A opens the entity in the application, and clicks Save as new version.
    • If User A clicks Next without changing the effective date or end date or both, the next minor version, 01-02, is assigned to the e-visit benefit.
    • If User A clicks Next after changing the effective date or end date or both, the next major version, 02-01, is assigned if there are no existing versions in the system with the new dates that were entered.

Extend versioning in PCS[edit]

There is a centralized data page "D_NewVersion" found in the ruleset PegaHC-USA-PCS:08-01-01 which drives the versioning for all entities in PCS.

User can find more details on use of data page at https://community.pega.com/sites/default/files/help_v85/index.htm#oxy_ex-1/platform-helpsystem/rule-/rule-declare-/rule-declare-pages/data-pages-con.htm

If the implementation team wants to change the default versioning logic, they can include any other property from the implementation layer or base PCS layer to the above data page.

There could be many scenarios under which the implementation team may want to enhance the versioning logic, like having open ended plans or controlling the versions of plans for a particular calendar year, or having the versioning for plans for a particular line of business or may be add versioning based on input requests from sales automation system.

Design inputs, how to plan versioning and updates[edit]

The auditing needs of the organization should be kept in mind when trying to enhance the versioning logic by the implementation team. Any property

Results[edit]

Understanding the configuration options available for the versioning logic is extremely critical for the implementation team. With this knowledge, the implementation team can act as informed advisor to the business team throughout the life of the project. Not only that, the implementation team can also facilitate and deliver quick results if the business team wants to extend the versioning logic to properties beyond the effective dates, without breaking any guardrails and being in compliance with Pega's best practices.