Before you migrate to Standard Digital Commerce, learn how Standard Digital Commerce differs from Digital Commerce.
In Winter '23 and onwards, Standard Digital Commerce uses a new pricing plan called Standard Pricing Plan. After you enable Standard Digital Commerce, Salesforce enables and uses this pricing plan in your org. The Standard Pricing Plan has the same set of features as the Default Pricing Plan that Digital Commerce used in previous releases. For example, you can use it to create custom steps, modify the sequence of steps, and call new interface implementations. It also support pre-ho and post-hooks on individual pricing plan steps.
In Spring '23 and onwards, Standard Digital Commerce supports only the DefaultPricingPlan for both the Cart Based APIs and the Standard Digital Commerce APIs.
If you enabled Standard Digital Commerce in the Winter '23 release, and upgraded it to Spring '23 release, then merge the StandardPricingPlan and DefaultPricingPlan. For more information, see Merge Price Plans
In Digital Commerce, when you ran Basket operations, the API calls sometimes created the following:
Pseudo-accounts and pseudo-orders
Order line items
Order price adjustments
Order applied promotions
Order applied promotion items
In Standard Digital Commerce, these objects aren't created during Basket operations. Therefore, you can't use any custom triggers for Configure or Basket operations on these objects that you created. This includes any custom code written in interface implementations such as custom hooks or steps. Refactor any such customizations to use cart documents instead. Cart documents provide additional scalability and performance during Configure and Basket operations.
Cart documents are trimmed and flexible JSON structures that can be used with the CPQ on Core services. You can then translate the output JSON to send a response to the top layer APIs such as DC APIs.
To learn how to use cart documents, see Use Cart Documents.
You an add custom fields to cart documents using field mapping. After you create the custom field for Order or OrderItem sObjects, map them to a key in the cart document. The key is the internal representation of the custom fields in the cart document. Therefore, they don't include prefixes such as the namespace or "__c".
When you specify the key, follow these recommendations:
Use the field name.
Don't add prefixes such as the namespace or "__c".
Unique for the org.
When the cart document wrapper updates the value for a custom field, this mapping is used to get the key in the cart document. The corresponding node is also updated with the value. This mapping is also used to create a response such as the external representation that contains the namespace prefix and "__c" using the internal cart document.
In this example, if a new custom field is created on OrderItem, then you must also create a mapping record for the field. To create a new mapping, from Setup, in the Quick Find box, enter
Custom Settings, and then select Custom Settings. Next to Custom Field Maps, click Manage and click New.
You can use attribute-based pricing in the following ways:
Using the Java Core Service: Use custom designed services on Salesforce Core to implement Attribute-Based Pricing. With this approach, attribute-based pricing uses the Salesforce platform. Using the default attribute-based pricing behavior allows for faster, efficient, and optimized execution versus Apex code. If your implementation of attribute-based pricing doesn't use significant customizations, we recommend using this approach.
Using VPL Code running on the Apex Tier: Use existing VPL classes to work with the cart document JSON. If you want to customize your implementation, use this approach.