Standard Asset-Based Ordering
Overview
Oracle CPQ has introduced the platform-based implementation of Asset-Based Ordering (ABO), referred to as Standard ABO. With Standard ABO, ABO-specific package updates are no longer required to enable new features. New ABO-related features are included within the Oracle CPQ Update. Standard ABO provides the following feature enhancements:
-
Seamless tracking of partial fulfillment of an asset on an order for customer environment integration with Oracle Fusion applications such as Oracle Order Management and Oracle Subscription Management.
-
Better visibility into asset order status with a new Pending status. The Pending status indicates the order is successfully submitted and the asset is not yet fulfilled.
-
Less administrator and implementer overhead to incorporate ABO features into the Oracle CPQ application. Standard ABO consolidates all new Asset-Based Ordering features directly into the Oracle CPQ product, streamlining delivery through regular product updates. With Package ABO, new Asset-Based Ordering features are decoupled from Oracle CPQ product and need additional implementation and deployments.
-
An intuitive interface for mapping custom asset attributes to transaction attributes and vice versa.
Standard Asset-Based Ordering (ABO) is used to sell tangible assets or subscriptions for services delivered over a period of time (e.g. Solar panel with battery and associated warranty). The Standard ABO functionality provides the ability to create and store customer assets in CPQ. Assets can be created, modified, suspended, resumed, renewed, and terminated. Customers can use Standard ABO in conjunction with System Configuration and can use REST APIs to integrate with external applications, such as Oracle Order Management.
Standard ABO supports subscription and asset-based products by recording fulfilled lines as assets. Sales users can create, modify, and terminate asset-based products using orders stored in Oracle CPQ and can also reconfigure an order to make changes to an existing order stored in CPQ.
Note: Customers using Package ABO (Oracle CPQ 25C or earlier) can continue with their current setup. However, beginning in 25D, new ABO features will no longer be delivered via migration packages. Refer to Package Asset-Based Ordering.
Assets
A standard ABO asset is created in “Pending” status when an order is placed successfully with the fulfillment system. A “Pending” status indicates that the sales order for those asset(s) are being processed but not yet fulfilled. When an order is fulfilled, the asset status is set to “Active”. Once created, customers can use Oracle CPQ transactions and the ABO Workbench to view and manage their assets. When a CPQ transaction is fulfilled, it records only the delta—the specific changes made to the asset—rather than the entire asset. The asset will be updated with the delta change to bring it to the same state as last transaction.
Asset Management
Asset Action Codes
Action Codes track changes to assets during the asset lifetime. There are two types of action codes:
- Basic: Basic action codes keep track of changes. Add, Update, and Delete are examples of basic action codes.
- Business-Specific: Business-specific action codes keep track of business processes. Business-specific action codes include Terminate, Suspend, Resume, and Renew.
The following action codes are available for line items on quotes and orders.
- Add - Adds a new product to the customer's assets.
- Update - Updates either an attribute value or delta field value for an existing product (e.g. asset or order).
- Delete - Deletes, deactivates, or disconnects an existing product (e.g. asset or order).
- Hyphen (-) - Tracks the No Changes to an Existing Asset action using the hyphen character (-).
- Terminate - Terminates a subscription service.
- Suspend – Suspends a subscription service.
- Resume – Resumes a subscription service.
- Renew – Renews a subscription service.
Note: The placement of action codes—whether in the main document or sub-document—and the positioning of columns in User Interface are determined by each customer's implementation preferences.
Fulfillment Status
The fulfillment status identifies the current state of an order and the associated saved BOM instance, which is the asset information obtained from the Oracle CPQ Model Configuration page.
The fulfillment status can contain six possible values:
- CREATED: Upon creating the configured lines, the fulfillment status is set to CREATED and indicates the quote has not been submitted for fulfillment.
-
PROCESSING: Indicates the sales order has been created and is currently being processed.
- BEING_FULFILLED: Indicates the sales order was submitted to the fulfillment system and Oracle CPQ has not yet been notified of the sales order's fulfillment.
- FULFILLED: Indicates the sales order is fulfilled and assets have been activated in Oracle CPQ.
-
PARTIALLY FULFILLED: Indicates the sales order is partially fulfilled. Some of the sales order quantity has been fulfilled and the remaining quantity is pending fulfillment.
- CLOSED: Indicates the sales order is closed or canceled.
Asset Creation
Creating an asset generates a traceable item that integrates with your fulfillment system. REST APIs are used to create and update assets in the Oracle CPQ asset repository.
Transaction based REST APIs are used to update the fulfillment status on the transaction line item. Transaction line Item status can be Created, Being Fulfilled, Partially Fulfilled or Fulfilled
Example Process Flow:
- When sales user adds subscription products to a CPQ transaction, the transaction line items display a "Created" status.
- When the sales user submits the transaction to the fulfillment system and the order is created in the fulfillment system, the transaction line item status changes from "Created" to "Processing".
- When the fulfillment system fulfills the order and notifies CPQ, the transaction line item status changes from "Being Fulfilled" to "Fulfilled".
For assets created in Oracle CPQ, the fulfillment system fulfills the order and notifies CPQ via an integration flow that uses the Asset REST APIs to create/update assets and transaction based REST APIs to update the fulfillment status on the transaction line item.
- When the order is fulfilled, the asset status is updated to “Active” and recorded in the Oracle CPQ asset repository.
-
Once the asset is in “Active” status, other ABO operations such as Modify, Renew, Suspend, Resume, Terminate, etc. can be performed on the active asset.
Asset Data Integrity Settings
Oracle CPQ supports the following Commerce Options settings for protecting asset data integrity in Standard ABO implementations:
-
Action Restrictions – In the Standard ABO implementation, you are denied permission to perform any actions on an asset if that asset is included in an open order. An open order is a quote that includes a line item with quantity still waiting to be fulfilled. This enhancement allows you to determine the appropriate action for active orders. This guardrail is set by default in Standard ABO and cannot be modified.
-
Subscription Ordering for Simple Products - Customers can enable Subscription Ordering support to directly add simple products to a Commerce Transaction for an asset-based order. A simple product is a product that does not have its part number associated with any of the related configuration models. When enabled, users can use Quick Add to add simple products to a Transaction without navigating away from the Transaction page. They can also add simple products using a parts search.
-
Commerce Library Function to get attributes list for ABO delta action code determination - Customers can enter the Commerce Library function which provides a of commerce line item attributes that will be used to calculate delta data. When the commerce line item attribute value changes commerce line item attribute "Line Delta Action Code" is populated with the appropriate action code.
-
Restrict Modification for Non-Subscription Products – When enabled, this Commerce Setting option prevents modifications to assets of type Goods. By default, it is set to Yes.
-
ABO Enabled Standard Commerce Process Variable Name – This Commerce Setting allows you to specify a single ABO-enabled commerce standard process variable name. This helps prevent downstream integration errors and ensures accurate end-to-end processing when multiple standard commerce processes are in use. However, if only a single standard commerce process is present, setting this variable is not strictly necessary. In such cases, the system defaults the value to 'oraclecpqo', ensuring API invocations still align with integration setups configured in Oracle Integration Cloud (OIC).
Asset Modification
Sales users can modify the details of an asset using the following methods:
- If the quote has not been submitted to the fulfillment system to create an order (i.e. the fulfillment status of the quote line is "Created"), the user can reconfigure the quote to update the quote line prior to submission for fulfillment.
-
After the order has been fulfilled and the asset is in an “Active” state, the user can use the Standard ABO Modify action on the ABO Workbench. Sales users can create a modify order by adding, deleting, or updating a component of a fulfilled asset.
The Modify action calculates the changes or deltas to each component in the asset's BOM and creates rows with action codes indicating the changes.
For example, when a user modifies a phone plan subscription from a Prepaid 40 plan to a Prepaid 50 plan two rows are created.
One a row to delete the Prepaid 40 asset BOM component and another row to add the Prepaid 50 asset BOM component.
Note: You cannot modify an asset with a future start date from the ABO Workbench. However, it is possible to achieve this using a modify REST service or by launching the configurator with the assetKey and the future request date.
Asset Termination
The Terminate action on the ABO Workbench is used to end a subscription. Sales users create a transaction and specify the request date, and then they access the ABO Workbench to select and terminate the asset.
For example, a customer terminates a cable television subscription. The sales user creates a Commerce transaction for the customer and specifies the request date for the termination. The sales user selects the Customer Assets action to display the ABO Workbench. After the sales user selects and terminates the asset, transaction displays with the appropriate action codes to terminate the subscription. When the Terminate action completes, the closed date of the asset becomes the date the customer requested the subscription termination.
Key Concepts
ABO Workbench
The ABO Workbench allows sales users to view and manage active assets.
To access the ABO Workbench, open a quote with an associated customer Id and click Customer Asset. The Customer Assets Commerce action is used to retrieve and display assets for the associated Customer ID in ABO Workbench.
Note:The out-of-the-box ABO Workbench displays active root assets based on the request date associated with the current Transaction.
Asset Key
Standard ABO supports detailed tracking of an asset key for a line item. When an asset is included in an order it is assigned an asset key. As the order goes through the order process, an asset key may need to be changed. Tracking the asset key allows customers to access the asset history and better align with subscription order flow.
The following Standard ABO order flow conditions dictate when a new asset key is required:
-
Asset action Modify generates a new asset key for lines with action code Add and Update
-
Asset action Modify does not generate a new asset key for lines with action code Delete and No Update.
-
Renew and Resume flows require a new asset key to be generated on Subscription items.
-
Suspend and Terminate flows do not generate a new asset key.
Asset Repository
In the out-of-the-box implementation of Standard ABO, asset information is stored locally in the Oracle CPQ repository. The local asset repository is not versioned and only keeps track of the latest view of the asset. A one-way synchronization occurs from quote/order to asset and a snapshot of all the relevant data used to create the asset is stored in the asset repository to reflect the state of the asset at that point in time.
Pricing fields are recalculated whenever an asset is loaded into a Configuration session. For Oracle CPQ Commerce integrations, we the price is recalculated each time the user creates a new transaction to modify or renew an asset
BOM Instance
A Configuration BOM instance is represented by a JSON object. BOM items can be classified as sales items, manufacturing items, or both. These items are defined in the BOM Item Definition table. This BOM instance is referenced during reconfiguration and is used to generate Sales BOMs and Manufacturing BOMs, which can be sent to a back-end system for order fulfillment.
CPQ uses sales items to create a Sales BOM instance during Configuration, sales items are used for quotes, and the Sales BOM instance is used during reconfiguration. In other words, Standard ABO only uses Sales BOMs.
Note: Sales items must have corresponding Part Numbers defined in the Oracle CPQ Parts Database.
For Standard ABO implementations, the BOM instance contains the delta configuration of the change compared with the projected asset.
The changed BOM item will have an applicable action code of add, delete, or update.
Delta Functionality
When users request a change to an existing asset (i.e. product or service) or a projected future asset, they usually initiate a Delta quote. Delta functionality compares a projected original asset BOM instance with a new asset BOM instance and creates a new BOM instance with action codes indicating the components that changed.
BOMs for Delta Functionality
There are four BOMs used for comparison to calculate the differences:
- ConfigBom: Corresponding to the Configuration user selections in the Configurator UI.
- PacBom: (also known as the priorBom) This is the base against which delta calculation will be conducted and indicates the projected state of an asset. It is read from user session cache and the entry in the user session cache is prepared before the Configurator is launch.
- InputBom is what was passed to the Configurator to launch the UI.
- The InputBom does not participate in the delta process directly. The only reason it is supplied is for reconfiguration.
- If the line is newly created during the prior save, we want to carry over the information from the prior save instead of creating the line from scratch, especially to preserve the assetkey from the prior save of the current line.
- DeltaBom is the output of the delta process and is used to generate transaction lines in Commerce.
When Standard ABO is not enabled, the deltaBom will be the same as the configBOM.When Standard ABO is enabled for an existing configuration, the deltaBom might contain additional/different lines than the configBom. The new lines represent the lines in the original configuration that are unselected by the user.
- In commerce, those extra lines will be represented as a line with an actionCode of Delete.
- In addition to the action code, the delta process also assigns the assetkey for the newly added BOM item.
Projected BOMs - PacBom vs InputBom
The projected asset cache contains two BOMs, the PacBom and the InputBom.
- For Modify operations the PacBom is the same as the InputBom
- For Reconfiguration the PacBom and InputBom are different
- The PacBom is the projection before applying the current line reconfiguration
- The InputBom is the projection after applying the current line reconfiguration, for example:
- An asset has the following configuration: Color=Red, Size=Large
- The current line has a change to Color=Blue
- When we try to reconfigure the current line the PacBOM has Color=Red, while the InputBOM has Color=Blue
- Strictly speaking, the InputBOM is used to bring the configurator up to the same configuration as last saved, and the PacBOM is used for delta comparison at Update Transaction time.
-
In the above example, if the user changes the color to red and the size to small during reconfiguration, and then saves.
The delta configuration saved to Commerce will be:
- Color No-change since the latest configuration has the same value as the pacBom and the asset
- Size – Change to Small
Note: Until the order is submitted, no matter how many times the user reconfigures and saves the line, the delta comparison is always against the projected stage before the current order, because the delta is about the aggregate change the user made within current order. The comparison between different reconfigurations within the same order is not important.
Delta Process Logic
The following items describe the logic within the delta process.
- When a component only exists in a new instance, add the component to the delta BOM using the Add action code.
- When a component only exists in the original instance, add the component to the delta BOM using the Delete action code.
- When a component exists in both the original and new instance, add the component to the delta BOM and compare the component attributes.
- If there are no changes, set the component action code to hyphen (-).
- If changes were made or an attribute was added or deleted, set the component action code to Update. The component action code is set to Update in the following scenarios:
- The addition or removal of a BOM attribute
- The update of a BOM attribute
- The update of one of the three key attributes: partnum, qty, parentId
- The child action codes reflect changes to the child entity but not the parent items.
- Attribute-level changes display new and updated attributes summarized in the Attributes field in a comma-delimited format. Deleted attributes do not display in the Attributes field.
- Apply simulates the impact of a set of changes on an original asset. The output is a future asset and is the inverse function of Delta, which projects the future state of an asset. If A1 delta A2 = C, then A1 apply C = A2.
Matching the Child BOM Item between the Original and New Instance
CPQ uses the "assetKey" attribute to compare the old and new instance of a given BOM item. An internal BOM ID gets associated to a given assetKey and is generated dynamically based on the user’s selection on Configuration UI and the BOM Mapping rule. For scenarios where a user deselects and reselects an attribute’s value, driving the selection of the same asset, the system cannot conclusively determine the user’s intention, which could be the reselection of the same original asset or deletion of the original asset and addition of a new, but the same, asset.
Oracle CPQ identifies the same BOM item with the original assetKey if the de-selection and selection is change on a non-array attribute. However, for array attribute-based BOM item selection, the assetKey might change.
Simple Product Support for Subscription Ordering
Customers can enable Subscription Ordering support to directly add simple products to a Commerce Transaction for an asset-based order. A simple product is a product that does not have its part number associated with any of the related configuration models. When enabled, users can use Quick Add to add simple products to a Transaction without navigating away from the Transaction page. They can also add simple products using a parts search.
System Configuration
System Configuration refers to a product offering which is made of multiple sub products, each of which can have a set of rules to define the structure leading to an n-level nested configuration to define the overall offering or permutations of configurable attributes which go together to make the sub product and ultimately the overall product.
System Configuration refers to the way Oracle CPQ is used to configure and bundle the product or set of products that are sold using a group of related models that together define an entire system. A system is a hierarchical arrangement of connected configurable models with a system root containing all of the other models.
When Standard ABO is enabled, it saves a delta configuration at the end of the configuration session. The delta configuration is stored in the Configuration BOM Instance, but it is not exposed for direct access.
NOTES
The Standard ABO Asset Action Log History includes log entries through REST API for new, modify, renew, resume, suspend, and terminate asset actions. An Asset action log entry occurs when an automated job runs to create a draft quote from the Oracle Subscription application. Asset action entries are logged for action invocation from the Asset Workbench, Oracle Subscription, and REST API.
Related Topics
See Also