Asset-Based Ordering Implementation

Oracle CPQ 23B introduces the Standard Process for new Oracle Sales integrated site installations. This feature only effects new ABO implementations using the Standard Process. There is no change to existing ABO implementations.

Customers already using Asset-Based Ordering that want to upgrade to the Oracle CPQ 23B platform release, can continue to use the 21A ABO or earlier implementation packages.

Customers implementing the new Commerce Standard Process (available in Oracle CPQ 23B platform release), must import the new 23B ABO implementation package and optionally merge their customization manually to the new package after careful planning and testing during implementation.

CPQ delivers a new ABO implementation package in Oracle CPQ 23B to support the new Commerce Standard Process. The Standard Process simplifies administrator setup for new ABO implementations by providing a pre-defined set of ABO-related Commerce attributes, actions, library functions, and data columns.
Customers can import the new 23B ABO implementation package to add additional content such as Commerce library functions and util libraries.
Customers can make UI layout changes by adding attributes and actions as per their requirements.
Implementation details that are not relevant while using the new Commerce Standard Process and the latest 23B ABO Implementation package are duly noted in the Oracle CPQ ABO Implementation Guide.
All other sections are relevant and should be reviewed carefully during implementation.

Beginning in Oracle CPQ 22D, a "_c" suffix will be appended to the variable name provided by the administrator. Prior to Oracle CPQ 22D, custom asset field variable names had a "_asset_custom_" prefix.

Oracle CPQ 22C provides a significant increase in the number of asset fields, including in the size of string type fields. This update also makes asset field administration consistent with other CPQ items.

Oracle CPQ 21D delivered delta pricing to Oracle CPQ Commerce transactions for ABO sites. Oracle CPQ 22B extends the delta pricing functionality to include projected assets. Therefore, Commerce Delta Pricing must be enabled to provide delta pricing for projected assets. The reference application sub-document "netAmount_l" attribute value from the prior order is used to populate the prior price value to enable the delta price calculation for open orders.

Customers can view delta pricing for Follow-On orders and Reconfigure actions.

Sample Use Case

A procurement specialist for a hospital places a monthly order for personal protective equipment (PPE).

Transaction for personal protective equipment (PPE)

A few days after the order is placed, hospital guidelines are updated stating hospital staff must double mask. The initial order supply will not be enough to comply with the new guidelines. The procurement specialist places a new follow-on order for the initial order. As shown in the following image, the Delta Price and Rollup Delta Price are displayed for the follow-on items.

Delta Price and Rollup Delta Price are displayed for the follow-on items

Shortly after the follow-on order the procurement specialist wants to order additional PPE items to receive a volume discount. He is able to reconfigure the follow-on order, which is still in the Created state. The following image shows the updated Delta Price, Rollup Delta Price, and List Price values.

Updated Delta Price, Rollup Delta Price, and List Price values

The reference application sub-document "netAmount_l" attribute value is used to populate the prior price value to enable the Delta Price calculation for open orders. CPQ 22B also provides the new Variable Name of Net Amount attribute at the Sub-Document Level used for Delta Price Commerce Option in case your site uses a custom attribute for the sub-document net amount value. This option doesn't need to be specified if you use the default sub-document "netAmount_l" attribute.

If this option is not specified and the sub-document Net Amount attribute does not exist, Delta Price will not be calculated for open orders.

If your site uses the default sub-document "netAmount_l" attribute and Commerce Delta Pricing for ABO is enabled, you don't need to do anything to enable Delta Pricing for Projected Assets,
If Commerce Delta Pricing for ABO is not enabled, you need to enable Commerce Delta Pricing, refer to Enable Commerce Delta Pricing for ABO.
If your site uses a custom net amount attribute, navigate to Admin > Commerce Settings and specify the Variable Name of Net Amount attribute at the Sub-Document Level used for Delta Price Commerce Option.

Note: Sales users need to invoke a modify type action to populate the delta price values in the Line Item Grid.

Beginning in Oracle CPQ 21D, users who have ABO enabled can directly reconfigure child system models from the Line Item Grid in the Transaction UI. In previous releases, users could only reconfigure the child models of a system by first reconfiguring the root model, then navigating to the child to make changes. This feature makes reconfiguring child system models easier for end users.

For an ABO enabled site with system configuration implemented, the following ABO Commerce library functions must be added to the Transaction and Transaction Line Commerce processes. BML scripts for these library functions are included as part of the 19B or later ABO Implementation Package and detailed instructions are included in the Oracle CPQ Asset-Based Ordering Implementation Guide (19B and later).

oRCL_abo_ReconfigureAction
oRCL_abo_BuildLineItemHierarchy

Oracle CPQ 21B provided configuration delta pricing information inside the Configuration UI when implemented with Asset-Based Ordering (ABO). Oracle CPQ 21D introduces a new sub-document Delta Pricing Attribute Set and new Commerce library functions to extend the delta pricing to Oracle CPQ Commerce transactions for ABO sites.

The sub-document Delta Pricing Set contains the following Currency type attributes:

The Delta Price attribute (_delta_price) displays the price difference for the updated line item.
The Prior Price attribute (_prior_price) displays the prior price for the updated line item.
The Rollup Delta Price attribute (_rollup_delta_price) displays the model level price difference of all child items for the updated model.

This feature allows for delta pricing information to be easily available to end users by enabling the following valuable operations:

View delta pricing information on the Line Item Grid and the sub-document page for both legacy and JET Transaction UIs.
Support delta pricing on the Transaction UI for Add, Update, Delete, Renew, and Terminate ABO flows.
Provide rollup delta pricing for new, updated, and modified models.

Sample Use Case

A sales user wants to update a SIM card order for their customer. The customer wants to change the original request of 100 - 5G SIM cards to 400 – 5G SIM cards, and 100 - 3G SIM cards to 25 – 3G SIM cards. In the Subscription Workbench, the sales user selects the previously fulfilled model and clicks Modify to bring up the existing asset details. After changing the SIM card quantities for the previous configuration, the sales user clicks Add to Transaction to proceed.

The transaction displays the original request (100 - 4G SIM cards, 100 - 5G SIM cards, and 100 - 3G SIM cards) and the modified order (100 - 4G SIM cards, 400 - 5G SIM cards, and 25 - 3G SIM cards). The Prior Price and Delta Price columns show the values for each line item, and the Rollup Delta Price column shows the total delta change for the model.

Commerce Delta Pricing

Note: For instructions to enable this feature, refer to Enable Commerce Delta Pricing

Beginning in Oracle 21B, we have provided customers the ability to easily copy ABO order lines and Transactions. When creating similar Transactions, this feature can reduce configuration errors and make the ordering process more efficient for customers.

Copying a Transaction creates a new Transaction from an existing Transaction in the Transaction Manager. The copied Transaction will contain the attributes as defined by the Copy action Initialization tab. The new Transaction will have newly assigned Instance IDs that are different from the source Transaction. The Line Items will have the Action Code of Add and the Transaction ID, User Name, and Creation Date are updated accordingly.

Copy a Transaction

Copy Transaction Lines

Note: For instructions to enable this feature, refer to Enable Copy Transaction and Transaction Lines in Oracle CPQ.

In Oracle CPQ 21B Asset-Based Ordering users are able to easily view pricing differences between the current state of an asset configuration and pending asset modifications of that same configuration. This delta configuration pricing information is supported inside the Configuration User Interface. The delta pricing feature is supported only for BOM Items/BOM Mapping in Oracle CPQ with Oracle CX Commerce integrations. When implemented, end users are able to view relevant pricing information to aid in pricing and purchasing decisions.

Sample Use Case

Lisa wants to view the delta price between the last configured model for her customer and a possible model configuration change. In the Subscription Workbench, Lisa selects the previously configured model and clicks Modify to bring up the existing asset details.

Modify asset item

Lisa selects different RAM and graphics card selections from that of the previous model configuration and clicks Update. The delta price for each item is shown in the Delta Price column for the line items.

Update Configuration

Additionally, the Total Price is updated with the Total Delta Price of the BOM displayed. Since the price difference is within her customer's budget, Lisa clicks Add to Transaction to proceed with this asset.

Delta price for reconfigured BOM

Note: For instructions to enable this feature, refer to Enable Configuration Delta Pricing.

The Oracle CPQ Ref App used by the ABO package stores the commerce start, end, and request dates as date-only format without timestamp and time zone, while asset start and end dates are stored with full timestamp information. In Oracle CPQ 20C and earlier, during the translation of the date information between commerce and asset, the commerce date is always based on the "0" hour of the server default time zone (usually GMT+0).

End users that are in the same time zone as the server default see the commerce asset date and time information consistently. However, when an end user is located in a different time zone than the server default and their user profile is set to display their local time zone, the conversion between the server time zone and the user's local time zone may transition midnight and cause the commerce date display to be different than the asset date display.

In Oracle CPQ 21A, an updated 21A ABO package provides a new administrator-defined business-level time zone setting called businessTimeZone. The business time zone is used, rather than the server default time zone, as the basis for all asset-related date and full timestamp translations. This provides administrators the ability to set a time zone that is more relevant to their business.

The updated package interprets the commerce date fields consistently during ABO processing based on the specified business time zone setting. End users may need instruction on how to interpret their user interface display of start, end, and request date fields in relation to the overall business time zone setting.

Within the 21A ABO package, the abo_loadDefaultContext BML function has been enhanced to include the businessTimeZone setting.

Existing customers wanting to upgrade to the 21A ABO package can upgrade and merge their customization to the new package or review the text files provided in the 21A ABO package with their current files and make the necessary modifications. For more information about upgrading, refer to the Oracle CPQ 19B or later Asset-Based Ordering Implementation Guide.

Notes:

The default businessTimeZone setting is GMT+0.
Once set up, asset start and end dates are populated based on business time zone; therefore, changing the business time zone setting to a different time zone should be avoided. If a change to the business time zone is required, it must be carefully planned with detailed analysis regarding the impact to legacy data.
Only an end user with the same time zone preference as the business time zone will see start and end date matching the business time zone on the asset user interface. End users in different time zones than the designated business time zone will see a different start and end date displayed for an asset based on that end user's time zone preference. End users need to be aware of how the date fields are displayed in relation to the overall company business time zone setting.

Simple Product Support for Subscription Ordering

Beginning in Oracle CPQ 19B, 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.

Simple Product for ABO

When Subscription Ordering for Simple Products is enabled and a simple product is added to a Transaction, the following attributes are automatically populated.

Line Item Attribute	Simple Product Value
BOM ID	SPI
BOM Part Number	The simple product part number
BOM Quantity	1
BOM Level	0
Asset Key	A unique ID is generated to track the simple product as an asset.
Action Code	Add

For instructions to enable this option, refer to Enable Subscription Ordering for Simple Products.

Notes:

Oracle CPQ strongly recommends that administrators install the 19B ABO Implementation Package to use simple products. Refer to the 19B ABO Implementation Guide for instructions to use simple products with the 18D ABO Package.
Simple Product functionality is not supported in external order implementations such as Oracle CX Commerce.

Multi-Select Support for Asset Operations

New Transaction Support for Asset Operations

Notes:

Most of the 19B Asset-Based Ordering enhancements require installation of the 19B ABO Implementation Package. Exceptions are noted for some multi-select operations.
If customers using the 18D ABO Implementation Package do not wish to use the 19B Asset-Based Ordering enhancements, the 18D ABO Implementation Package will continue to work.

Support for System Configuration Models

Suspend and Resume Actions on Child and Grandchild Models and Parts

In Oracle CPQ Release 18D, when using modify, reconfigure, or follow-on order Asset-Based Ordering flows on assets, users can Suspend and Resume child and grandchild models and parts in a configurator session. In prior releases, these operations were only supported on the asset as a whole.

This enhancement provides a basic framework that provides customers the ability to customize the behavior by creating Configuration attributes, BOM mappings, and constraints to support the Suspend and Resume operations on child models, according to their business requirements.

Sample Administrator Steps

The following section provides a list of typical setup information for Suspend and Resume on child and grandchild models and parts.

Create two Configuration attributes for each model or part you are enabling the Suspend and Resume operations -- one to capture the Suspend and Resume actions and another optional Configuration attribute to store the projected state of the asset for rule enforcement. If this enhancement is enabled for all models, administrators can create the Configuration attributes at the Product Family level and add them to the Configuration flow layout at the child and grandchild level. For example:
- Create a Configuration attribute with variable name 'oRCL_ABO_Action' to capture the user intent to Suspend or Resume.
  - Variable Name = oRCL_ABO_Action
  - Data Type = Text
  - Display Type = Single Select Menu
  - Menu Values = SUSPEND, RESUME
- Create a configuration attribute with variable name 'oRCL_ABO_PriorAssetState' to capture the projected state of the asset that is calculated and stored in the attribute at runtime. This can also be created as a hidden attribute.
  - Variable Name = oRCL_ABO_PriorAssetState
  - Data Type = Text or Single Select Menu
  - If we are defining a Single Select Menu, then the menu values should be as follows - ACTIVE, SUSPENDED
- The variable name of the Configuration attribute is not significant, but it must match the BOM Mapping rules created later.
Add configuration attributes 'oRCL_ABO_Action' and 'oRCL_ABO_PriorAssetState' to the child and grandchild levels of a UI layout, so that Suspend and Resume actions are available on child models to users.
Create constraints to ensure the Suspend and Resume actions are only enabled or disabled in the Model Configuration page session depending on the value of the projected state of the asset. This allows the user to determine whether Suspend or Resume is allowed. In the above sample setup, administrators can create the rule at the Product Family level. For example, a sample script can be as follows:
```
if (oRCL_ABO_PriorAssetState == "SUSPENDED") {
  return "RESUME|^|";
}
if (oRCL_ABO_PriorAssetState == "ACTIVE") {
  return "SUSPEND|^|";
}
if (oRCL_ABO_PriorAssetState == "") {
  return "SUSPEND|^|";
}
return "SUSPEND|^|RESUME|^|";
```
Navigate to Admin > Data Tables, For each model or part for which this enhancement is enabled, create relevant BOM data table mappings in the Oracle_BomAttrMap data table between the Commerce line attribute 'oRCL_ABO_ActionCode_l' and the configuration attribute for capturing user intent to Suspend or Resume, that is 'oRCL_ABO_Action' in the above example.
Optionally, create relevant BOM data table mappings in Oracle_BomAttrMap between BOM attribute 'oRCL_ABO_PriorAssetState' and the configuration attribute created to capture the projected state of the asset, that is 'oRCL_ABO_PriorAssetState' in the above example.

Retain Configuration Attributes without Mapping in BOM Tables

Update Configuration REST API Operation

In Release 18D, in order to preserve unmapped configuration attributes and to support system configuration, an additional RESTful call is required to copy these configuration attribute values from order line and store them on the root asset after fulfillment.

The "updateConfiguration" REST API operation accumulates a projection of all configuration attributes from all relevant open order lines related to an asset and stores this information in the "configAttrInfo" attribute on the root asset. For additional information, refer to Asset REST APIs.

When orders are stored in CPQ, invoke the update configuration REST API operation, after invoking the synchronize operation to create or update assets in the Oracle CPQ Asset repository during the fulfillment flow. The following tasks are required to update configuration values:

Invoke the synchronize REST API operation. For example:

https://sitename.oracle.com/rest/v7/assets/actions/synchronize

Invoke the update configuration REST API operation. For example:

https://sitename.oracle.com/rest/v7/assets/actions/updateConfiguration

When orders are stored outside of Oracle CPQ (e.g. in Oracle CX Commerce), the "updateConfiguration" action is automatically invoked when the REST API is invoked to update the "fulfillmentStatus" attribute of the "configBomInstance"' resource to "FULFILLED". For orders stored outside of CPQ, the following flow is expected during fulfillment:
- When the order is submitted for fulfillment, invoke a REST API call to update the "fulfillmentStatus" attribute of the "configBomInstance" resource to "BEING_FULFILLED".
- After the order is fulfilled by the fulfillment system, invoke the synchronize REST API operation.
```
https://sitename.oracle.com/rest/v7/assets/actions/synchronize
```
- After the order is fulfilled, invoke a REST API call to update the "fulfillmentStatus" attribute of the "configBomInstance" resource to "FULFILLED".

Note: The "updateConfiguration" action is automatically invoked and an additional API call is not required to update configuration values in assets.

Reconfigure an Asset After Resume or Renew Operations

Reconfigure, Modify, and Follow-On Order REST API Operations

In releases prior to Oracle CPQ 18B, a client application has to make two separate calls to perform reconfigure, modify, or follow-on order operations.

The modify REST endpoint is invoked, the projected state of the asset is calculated and a URL with ProjectedAssetCache(PAC) key is returned in the response. For example:

"configuratorURL": https://sitename/commerce/new_equipment/products/model_configs.jsp?_from_partner=true&product_line=laptop&model=laptopModel&segment=computer&bm_sales_root_bom_item_id=abo_98228aac-867e-43a7-9823-76dc7c444dca&configContextKey=be2c0b20-49e4-4642-adfc-a207b529b282

The client application uses the response "configurationURL" to launch the configurator.

Beginning in Oracle CPQ 18B, additional URL parameters are passed during reconfigure, modify, or follow-on order operations. These parameters allow client applications to directly launch the configurator when preforming reconfigure, modify, or follow-on order operations. The following additional URL parameters are included:

assetKey - An invariant key that uniquely identifies the asset component for the lifetime of the asset. This is a required parameter and this attribute value can be found by querying assets resource.
transactionDate - The date (in ISO format) on which the transaction is effective. This is optional. If a date is not passed in then this will default to current date during processing.
sourceIdentifier - The Oracle CPQ Commerce Process variable name (e.g. oraclecpqo). This parameter is only required for orders stored in CPQ. If a value is not included for the "sourceIdentifier", the operation will default to "_external_order" which indicates that the order is stored outside CPQ.
id - The transaction identifier. This parameter is only required for orders stored in CPQ. This parameter is used to synchronize the modified data to the referenced Transaction during modify or follow-on order operations.

Note: Only authenticated users who are logged in to the application can use the additional URL parameters to directly launch the configurator.

Beginning in Oracle CPQ 18C, additional security access tokens are passed as URL parameters during modify and follow-on order operations. The additional security access tokens enable guest users to directly launch the configurator when preforming modify or follow-on order operations.

Note: External applications need to setup an Authentication Certificate Integration to acquire security access tokens. For more information, refer to Oracle CX Commerce Integration > Create an Authentication Certificate Integration Type.

The access token should be used, as URL parameters when the following REST APIs are invoked from external applications. The following access token parameters must be included in the URL: accessTokenData, accessToken, and publicKeyVarName.

Sample URL with the new URL parameters

The following section provides reconfiguration, modify, and follow-on order examples for REST API calls in Oracle CPQ 2017 R1, Oracle CPQ 18B, and Oracle CPQ 18C.

Reconfigure Examples

Modify Examples

Follow-On Order Examples

External Client Application Integration

As part of the external client application integration, Oracle CPQ administrators must configure a "Client Side" integration to enable a Configurator action for a specific product family. The action sends items to the external client application cart via a button that displays on the Oracle CPQ Model Configuration page after configuring the "Client Side" integration. When using an external client application to create orders, the Oracle CPQ Model Configuration page opens in an embedded iframe in the external client application and allows the user to configure an order.

Either Oracle CPQ or the external client application stores orders independently during the order capture process. When orders stored in Oracle CPQ and orders stored in an external client application co-exist on a customer site, the Asset-Based Ordering solution processes the orders separately. An external client application that stores order data can invoke Oracle CPQ Asset REST APIs to retrieve the active asset list from the Oracle CPQ asset repository for display in their own Customer Assets page. From the Customer Assets page in the external client application, users can perform other asset-based operations such as Modify, Terminate, Suspend, Resume, and Renew by executing the REST API Services for Assets available in Oracle CPQ 2017 R1.

In addition, administrators can use REST APIs to synchronize the asset changes to the Oracle CPQ asset repository or external asset repository after creating and fulfilling external orders based on changes made using asset based operations. When an external client application is used, it can invoke REST APIs to exchange data with the external order fulfillment system.

Notes:

If customers implement the 2017 R1 Asset-Based Ordering solution and continue to store orders in CPQ, the execution of most asset operations will continue as in the 2016 R1 Asset-Based Ordering implementation. The one exception is the updateAsset operation, which is not available in the 2017 R1 Asset-Based Ordering integration. The abo_updateAsset BML function is available in the 18C and later ABO implementation packages.
Integrating with an external client application is an optional step. To enable an external client application and integrate with Asset-Based Ordering, administrators must use the Oracle CPQ Edit Integration page to define a "Client Side" integration at the product family level. For more information, refer to the Configuration Integration.

Configuration BOM Instance

BML Library Functions for External Client Application Integration

External Client Integration Resource

The Configuration BOM Instance Resource (i.e. configBomInstance resource) is used primarily when orders are stored in an external client application. Users can perform standard REST operations on the configBomInstance resource. The configBomInstance resource stores the configBomInstance when a user customizes a product using the Oracle CPQ Model Configuration page and adds the product to the shopping cart of the external client application. Oracle CPQ stores all configBomInstances in its own repository. A unique identifier (configId) allows users to locate a saved configBominstance, and REST APIs are available to extract and return the BOM instance in the form of a JSON response.

The data in the configBomInstance resource keeps track of external open orders relevant to a particular asset. The configBomInstance resource is applicable when asset based operations are performed while creating new assets or making changes to existing assets. After a configBomInstance is saved in the configBomInstance resource, the fulfillmentStatus attribute in the configBomInstance resource should be updated at regular intervals during the course of order creation, submission, and fulfillment.

Similarly, administrators must keep the transaction id and transaction date attributes in the configBomInstance in sync to hold the values from the corresponding fields in the external client application. When customers use an external client application to store orders and integrate the external client application with Oracle CPQ to implement Asset-Based Ordering, they have the option of implementing open order synchronization if they support open orders.

Note: Unless the status is "Being Fulfilled", obsolete data in the configBomInstance resource is cleaned-up periodically. For additional information, refer to the Open Order Synchronization section of the 2017 R1 ABO Implementation Guide and Configuration BOM Instance Resource.

REST API Services for Assets

REST API services for assets allow external client applications to Modify, Terminate, Suspend, Resume, and Renew assets.

Modify Asset – Modify a subscription service by modifying an asset. This operation calculates the projected state of the asset for the requested date and returns a configuration URL that launches the model configurator page, which reflects the projected state.
TerminateAsset – Terminate a subscription service by terminating an asset. This operation merges a termination request with the projected asset for the requested date and stores the results to a Configuration BOM Instance. For termination requests, the root item action code is set to Terminate and subordinate asset action codes are set to Delete.
Suspend Asset - Suspend a subscription service by suspending an asset. This operation merges a suspend request with the projected state of the asset for the requested date and stores the results to a Configuration BOM Instance repository. For suspend requests, the root and subordinate action codes are set to Suspend. Once the suspend request is fulfilled and the asset data is updated, the Suspend Date on the asset should be set to the date the request is effective.
ResumeAsset – Resume a suspended subscription service by resuming an asset. This operation merges a resume request with the projected state of the asset for the requested date and stores the results to a Configuration BOM Instance repository. For resume requests, the root and subordinate action codes are set to Resume. Once the resume request is fulfilled and the asset data is updated, the Resume Date on the asset should be set to the date the request is effective.
Renew Asset – Renew a subscription service by renewing an asset. This operation merges a renew request with the projected state of the asset for the requested date and stores the results to a Configuration BOM Instance. For renew requests, the root and subordinate action codes are set to Renew. Once the renew request is fulfilled and the asset data is updated, the End Date on the asset should be set to the date up to which the request is renewed.

REST API Services for Configuration BOM Instance

Use REST API services for a Configuration BOM Instance when storing orders in an external client application to reconfigure an order, create a Follow-On order, or retrieve a saved Configuration BOM Instance.

Reconfigure an Order – This operation updates an asset prior to fulfillment and internally calculates the projected state of the order. The response returns a new "configurationURL", which launches the Model Configuration page and reflects the user intended net changes to the subscription. Use this operation when storing orders in an external client application. When orders are stored in CPQ, use the Reconfigure action (_reconfigure_action) as used in the Oracle CPQ 2016 R1 release.
Create Follow-on Order – This operation makes changes to an existing and unfulfilled order. Once created, the follow-on order calculates the projected state of the order to allow the user to make additional changes. The response returns a new "configurationURL" that launches the model configurator page and reflects the user intended net changes to the subscription. Use this operation when storing orders in an external client application. When orders are stored in CPQ, use the Follow-On order action (oRCL_ABO_CreateFollowOnOrder) as used in the Oracle CPQ 2016 R1 release.
Get Configuration Instance – This operation uses one of the following identifiers to retrieve a saved Configuration BOM Instance:
- The lineId returned from a Terminate, Suspend, Resume, or Renew service
- The config_id returned by client side JSON object for client integration case.
Note: Get Configuration Instance is only available for external client application integrations.

Asset-Based Ordering Implementation

Overview

23B Features

22D Features

22C Features

22B Features

21D Features

21B Features

21A Features

19B Features

18D Features

2017 R1 Features

Administration

Related Topics