Change offer (subscription version)

Change offer (subscription version)

Key concepts

A subscription can exist in several versions over time. Each version represents a period during which a given offer is active. For each subscription version, Opencell keeps at least: version number, offer, validity period (validFrom, validTo), and links to previous/next versions.

Only one version is active at a given date.

When you change the offer, Opencell terminates the current version at a given date and creates a new version starting at the effective date of the change.

Old vs new version and delayed termination: You can delay termination of the old version until the new version is activated (useful for provisioning). Effective date controls when the new offer starts; validity periods must not overlap. Only allowed target offers can be selected as defined by the offer template.

Typical use cases

• Upgrade or downgrade: Move a customer from one offer to another (e.g., Basic Premium) without interruption.

• Catalogue migration: Transition existing subscriptions to a new or updated offer during catalogue evolution.

• Correcting offer selection: Fix an incorrect initial offer choice without terminating and recreating the subscription.

• Commercial adjustments: Apply new pricing, bundles, or terms following renegotiation or business changes.

How it works

1. Initiate Offer Change

   • User selects the subscription and triggers the “Change offer” action.

   • System validates eligibility (active status, allowed target offers, valid effective date).

2. Create New Version

   • A new subscription version is created with the selected offer and effective date.

   • Links to previous and next versions are established.

   • Validity periods (validFrom, validTo) are set.

   • Optionally, termination of the old version can be delayed until the new version is activated (for provisioning scenarios).

3. Service/Product Instantiation

   • Services and products associated with the new offer are instantiated as per configuration.

   • Custom fields and renewal terms can be copied from the previous version if required.

4. Activation

   • If immediate, the new version becomes active and the old version is terminated.

   • If delayed, activation is performed manually via the portal or API, at which point the old version is terminated.

5. Rollback (if needed)

   • If the change needs to be reverted (e.g., due to error or failed provisioning), the rollback action cancels the new version and reactivates the previous one, subject to business rules (e.g., no billing has occurred on the new version).

User journey

Change a subscription offer

• Open the subscription in the back-office portal.

• Use the Change offer action.

• Select the new offer, effective date, and any specific options (e.g. delayed termination of old version).

• Confirm the change; a new subscription version is created.

Activate a pending version

• Open the subscription showing a future or pending version.

• Use the Activate version action (label may vary depending on implementation).

• Optionally adjust the effective date if allowed.

• Confirm; the new version becomes active and the old version is terminated (if not already).

Roll back the last offer change

• Open the subscription where the last operation was an offer change.

• Use the Rollback offer change action.

• Confirm the rollback; the system cancels the latest version and reactivates the previous one, subject to business rules.

Version navigation and display

• Each subscription displays its version number and validity period (start and end dates).

• Users can navigate between versions (previous / next) from the subscription view.

• Only one version is active at any point in time; past and future versions are clearly indicated.

• Lists and search results can be configured to show or filter by the current version, or to include historical versions.

Business rules and constraints

• Offer change is only allowed for subscriptions in a valid state (typically active or in-service).

• The effective date of the new version must be on or after the subscription start date and must respect catalogue validity.

• If allowed target offers are configured on the original offer, only those offers can be selected as the new offer.

• Version periods cannot overlap: when a new version becomes active, the previous version is automatically ended according to configuration.

• Rollback is generally restricted once billing events have occurred on the new version; this may be controlled by project-specific rules.

Impact on billing

• Charges associated with the old offer stop as of the termination date of the old version.

• Charges associated with the new offer start as of the effective date of the new version.

• Depending on project configuration, proration or adjustments may be applied when the effective date is mid-period.

• In a rollback, billing adjustments (e.g. cancelling charges on the new version and restoring the previous one) may be performed automatically or manually, according to implementation.

API support (overview)

• The change offer functionality is exposed via dedicated APIs to:

  • Create a new subscription version with a different offer.

  • Activate a pending (patched) subscription version.

  • Roll back the last offer change.

• Technical details (endpoints, payloads, and response formats) are documented in the API reference and are not covered in this functional page.

Limitations and recommendations

• Mass migrations (large populations of subscriptions) should be planned and tested carefully; performance and billing impact must be evaluated.

• Rollback should be used promptly after a mistake is detected; the longer the new version is in use (especially with invoicing), the more complex manual corrections may become.

• When using delayed termination of the old version, monitoring of provisioning and activation status is recommended to avoid double charging or service gaps.

• It is recommended to test common offer change scenarios in a non-production environment (including billing runs) before enabling them in production.