Decomposition Relationships

Within the decomposition process, a decomposition relationship creates a one-to-one (1:1) relationship between a source product and a destination product. You can also create one-to-many (1:M) and many-to-one (M:1) relationships.

After the capture of a customer order, the order is decomposed into sub-orders, called fulfillment requests, tailored for specific downstream systems. The decomposition process enriches commercial information from the original order by executing rules that derive the technical attributes required to fulfill the order. Industries Order Management uses decomposition relationships to define these rules.

Order decomposition breaks down the original commercial order into technical orders that are custom-designed for fulfillment systems according to use case requirements. The Order Decomposition process does not modify the original order. Instead, the process generates a set of Fulfillment Requests (FR), each containing Fulfillment Request Lines (FRL). An FRL is a wrapper for the technical product specification defined in the catalog in a similar manner in which the Order Item is a wrapper for the commercial product specification. The FRL has an action that is identified during the decomposition process based on analysis of the current technical inventory and the desired state of the technical inventory at the end of the fulfillment process. The FRL action is calculated by the decomposition module and is not a direct copy of the related source order item. The destination (FRL) action might be completely different from the source order item action.

Order Decomposition is driven from the configuration of the technical catalog, which includes the definition of the technical product specifications and decomposition relationships defined between commercial entities and technical entities. All technical product specifications influence how Order Management decomposes those specifications through the Scope field.

A decomposition relationship creates a one-to-one (1:1) relationship between a source product and a destination product. To create a one-to-many (1:M) relationship, you can create multiple decomposition relationships for any given source product. Finally, you can also create many-to-one (M:1) relationships by using multiple decomposition relationships and the Scope function.

Decomposition Relationships

• One-to-One Decomposition
  A common use case for a one-to-one order decomposition involves an offer containing multiple products of the same type that must be activated individually.
• One-to-Many Decomposition Relationship
  There are different types of decompositions relationships, including the one-to-many type. A common use case for a one-to-many order decomposition is an offer containing a product that affects multiple fulfillment systems.
• Many-to-One Decomposition Relationship
  Order Management Standard supports many-to-one (M:1) attribute propagation in multi-level decomposition. For M:1 decomposition, Order Management Plus displays multiple assets for a single Inventory Item and multiple Source Order Items for a single decomposed Order Item.
• Product Class Decomposition
  The product catalog can define multiple products of the same type. Typically, these products require the same fulfillment in Order Management, which means that they decompose the same way.
• Grouping Multiple Fulfillment Requests into One Request
  A common use case for grouping multiple fulfillment requests into one fulfillment request may involve a business process that requires all STB devices needing provisioning to be sent simultaneously to the provisioning system.
• Model a Product as an Attribute
  To reduce the catalog size, you may be able to model a product as an attribute. This translates to an attribute that has a true or false value that symbolizes whether the customer has the product or not.
• One-Time Decomposition
  One-time decomposition is also known as Event Service, and allows you to configure a product specification as "not assetizable" for any one-time events, such as customer email notifications.
• Augment Callout with Temporary Information
  Augmenting a callout with temporary information combines the Grouping pattern with the Event Service pattern to achieve the desired result. You interact with the Device Inventory and inform the system of all the STBs leased to the customer.
• Mapping Temporary Information to a Technical Product
  You can use the Order Management Decomposition Relationship screen to map virtually any field or attribute from the source to the target.