Difference between revisions of "Implementing versioning"
(editorial comments, asked some questions)
Tag: Visual edit
Revision as of 21:02, 29 January 2021
|Request to Publish|
|Version as of|
|Application||Pega Product Composer for Healthcare|
In Pega Product Composer for Healthcare, entities such as a benefit or plan can undergo changes in their life cycles. Workflows of these entities generally progress at different times in discrete phases. During a phase, you might need to allocate a different set of data or enforce different business rules. In these situations, you can represent the changes to an entity in time blocks. Each time block of an entity is a version. The effective dates in PCS are used as the time blocks. They drive versioning for all entities in PCS.
For more information about how versioning works in PCS, see Versioning.
In the Enter details step of all entitiy creation, the following two core properties drive the versioning logic in PCS:
- Effective date
- End date
Whenever you change one or both of these effective dates, the PCS application automatically creates a new major version for the new entity. If the effective dates are not changed, the application creates a minor version.??? what prompts the minor version? The clicking of Save as? if so we should mention it here??? For example:
- User A creates a new e-visit benefit. Version 01-01 is assigned by the application.
- 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.
- 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. ?? and so what happens if there is an existing version in the system????
Extend versioning in PCS
Ther centralized D_NewVersion data page, which is found in the ruleset PegaHC-USA-PCS:08-01-01, drives the versioning for all entities in PCS. For more information about using data pages, see Data pages.
If the implementation team wants to change the default versioning logic, they can add any other property from the implementation layer or base PCS layer to the D_NewVersion data page.
There could be many scenarios under which the implementation team might want to enhance the versioning logic, such as having open-ended plans, controlling the versions of plans for a particular calendar year, having the versioning for plans for a specific line of business, or adding versioning based on input requests from a sales automation system. ??? should you show the data page with an example????
When the implemention team tries to enhance the versioning logic, they need to keep the auditing needs of the organization in mind. The use of a centralized module for versioning means that the changes are applied to all entities. One of the most common inputs to the design for versioning is the process by which the plans change from year-to-year and the compliance requirements changes in reporting. They must also keep in mind the overall stage in which the updates occur and must adjust the versioning configuration accordingly. If the implementation team wants to prevent updates from occuriring to the plans in the Production stage without changing the version, they can update the configuration page by clicking Configure -> Product Composer System -> Configuration in Dev Studio. ??? please check this paragraph as i made changes....???
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 advisors to the business team throughout the life of the project. Additionally, 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 keeping compliant with Pega's best practices.