Support Co-term from CPQ and Order Management

Oracle Subscription Management now supports co-terming for subscription renewals and new subscription sales initiated from CPQ and Order Management. You can select an existing active subscription product line and use its end date as the end date for the subscription product being renewed or newly added, so related subscriptions renew together. You can also choose to consolidate the new subscription product into the same subscription header as the selected existing subscription. For co-term scenarios, the eligible subscription list is limited to active subscriptions that belong to the same customer, business unit, legal entity, and currency. When an AttachToSubscriptionNumber attribute is passed from CPQ through Order Management to Subscription Management, it overrides grouping rules and the selected target subscription is used directly. and makes co-term behavior more predictable. 

The subscription profile is not derived for the new subscription and instead the subscription profile of the Subscription number passed is used.

• Aligns related subscriptions so they renew together
• Reduces renewal fragmentation for add-ons and near-term renewals
• Simplifies subscription lifecycle management for sales teams and customers
• Supports consolidation of new subscription products into an existing subscription
• Reduces administrative overhead by managing related subscriptions under a single renewal path
• Makes co-term behavior more predictable by allowing CPQ and Order Management to identify the target subscription directly on an already active subscription for co-term selection and amend flows. 

Steps to enable and configure

You don't need to do anything to enable this feature.

Tips and considerations

• Mandatory attributes are the identity gate:
  Business Unit, Legal Entity, Primary Party, Currency, Subscription Number
• Non-mandatory/defaulting attributes are the “soft validation” set:
  SubscriptionProfileId, PricingSystem, FreezePriceFlag, PricingStrategyId

• How mandatory and non-mandatory attributes impact subscription

  Attribute combination when AttachToSubscriptionNumber is sent	Resulting behavior
  Mandatory/core identity attributes match: Business Unit, Legal Entity, Primary Party, Currency, and Subscription Number	The subscription product is created under the subscription mentioned in attribute AttachToSubscriptionNumber and will be in active status.
  Mandatory/core identity attributes do not match	The subscription is not created and the interface ends in error with an error message indicating that the susbcription number mentioned in attribute AttachToSubscriptionNumber was not found.
  Mandatory/core identity attributes match, and all non-mandatory/defaulting attributes also match:	The subscription product is created under the subscription mentioned in attribute AttachToSubscriptionNumber and will be in active status.
  Mandatory/core identity attributes match, but one or more non-mandatory/defaulting attributes mismatch: SubscriptionProfileId and/or PricingSystem and/or FreezePriceFlag and/or PricingStrategyId	The subscription product is created under the subscription mentioned in attribute AttachToSubscriptionNumber and will be in active status.
  AttachToSubscriptionNumber present, but SubscriptionProfileId is null on the inbound transaction	Subscription Profile is not derived when AttachToSubscriptionNumber is present.
  AttachToSubscriptionNumber present during renew/amend flow	Grouping rules are effectively overridden by the explicit attach target i.e. grouping rule is not used when AttachToSubscriptionNumber is sent. The subscription product is created under the subscription mentioned in attribute AttachToSubscriptionNumber and will be in active status.
  Optional/segregation attributes mismatch on co-term scenario	The subscription is still created in Active status and the subscription number in attribute AttachToSubNumber prevails.