.left-arrow.case-study { left: calc(50vw + 683px - 54px - 70px); } .right-arrow.case-study { left: calc(50vw + 683px - 54px - 20px); }
By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.

Related articles

DevelopersAPI guides

Contract versioning

Contract versioning provides an auditable process for changing contracts over time, whether this is due to alterations, renewals, or fundamental changes. Versioning is supported for distributor support contracts (DSCs), customer pricing contracts (CPCs), and special pricing agreements (SPAs).

Versioning has two components- versions and periods:

  • A version of a contract is a new contract that completely replaces the old version. Throughout the system, the version of a contract is appended to the ID and will be of the form VN where N is the version number (i.e., V1, V2, V3 … VN).
  • A period change can be made without altering the version. For example, if a contract runs from January 1st until March 31st, then a new period will run from April 1st to June 30th (assuming you want it the same length). Typically periods are denoted by P1, P2, P3… PN.

Contracts that support versioning will denote what period and version they are via PN-VN. Based on periods and versions Enable supports three versioning actions:

  • Renewals: extend a contract term by editing the contract's end date. A contract that is renewed twice will have a code of P3-V1.
  • New version: this method allows you to edit the terms of a contract.  This allows corrections after approval has occurred. The user can change rates, included products, included branches, etc. These changes are retrospective and will trigger calculations on any already submitted transactions to be recalculated based on the new terms.
  • Split: Splitting allows you to make concurrent version and period adjustments arising from renegotiations. By splitting the contract into two, changes part way through a period can be made. The first contract resulting from the split has the same start date as the original one and ends at the split date you define. The second contract resulting from the split takes the user-defined split date's start date and its end date from the original contract's end date. This means a contract that has never been renewed and never had a new version (P1-V1) will become P1-V2 (starting on the original start date, ending on the split date) and P2-V1 (starting on the split date and ending on the original contract end date). These changes allow you to maintain the prior claim calculations retrospectively and only adhere to the updates from the split date onwards.

If you encounter issues making changes to your contract please reach out to our support team here.

Not useful
Very useful
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Still have questions?
Raise a ticket or contact our support team.