# Migration Considerations

Before you begin, [Check Feature Compatibility](/docs/industries/cme/guide/review-the-considerations.md) for using the standard cart APIs.

## Interfaces and Implementations

Following table lists supported interfaces and implementation class names.

| Interface Name (in Cart APIs)                                                                         | Supported in Cart APIs | Supported with Standard Cart APIs | Interface Name (when Standard Cart APIs are enabled) | Active Implementation Class Name |
| ----------------------------------------------------------------------------------------------------- | ---------------------- | --------------------------------- | ---------------------------------------------------- | -------------------------------- |
| PricingInterface                                                                                      | Y                      | Y                                 | CpqPricing                                           | CpqPricingOrchestratorService    |
| ProductValidationInterface                                                                            | Y                      | Y                                 | CpqValidation                                        | CpqValidationService             |
| TightestMatchInterface                                                                                | Y                      | Y                                 | CpqTightestMatch                                     | CpqTightestMatchPLEService       |
| TimePolicyInterface                                                                                   | Y                      | Y                                 | CpqTimePolicy                                        | CpqTimePolicyService             |
| CpqAppHandlerHook                                                                                     | Y                      | Y                                 | CpqAppHandlerHook                                    |                                  |
| PricingElementServiceImplementationH<br>PricingPlanServiceHook<br>CustomPricingElementServiceImplHook | Y                      | Y                                 | CpqPricingHook                                       | Custom Hook Implementation Name  |
| ContextRuleService                                                                                    | Y                      | Y                                 | CpqContextRule                                       | CpqContextRuleService            |
| DefaultPricingVariableCalcImplementaInterface                                                         | Y                      | Y                                 | CpqPricingVariableCalc                               | CpqPricingVariableCalcService    |
|                                                                                                       |                        |                                   | CartResponse                                         | CartResponseService              |
| PricingSelector                                                                                       | Y                      | N                                 |                                                      |                                  |
| CtxRulesPriceListsOpen                                                                                | Y                      | Y                                 | CpqPricingEligibility                                | CpqPricingEligibilityService     |

:::important
- If a product is marked as IsOrderable\_\_c=false, Advanced rules and PCPs will not work correctly in Standard Cart APIs. Instead, configure the Product with IsOrderable\_\_c=true and filter the Products in [Availability and Eligibility Interface Implementations](https://help.salesforce.com/s/articleView?id=ind.v_dev_t_availability_and_eligibility_interface_implementations\_652003.htm\&type=5).
- When EPC job is run without selecting any PriceList, it caches the PCP data for products marked IsOrderable\_\_c=false. Then PCP rules will work for all the products.
- To return a custom field in a Cart API response, the field must be explicitly included in the fields parameter, either in the API URL parameters or the request body. The CPQV2 field settings approach for controlling response fields is supported for the getCarts and GetCartsItems APIs. It does not apply to other Standard Cart APIs.
- Standard Cart APIs enforce Double as the required data type for the pricing or currency-related fields. Users must update such Integer values in their custom code to Double type (for example, 0 → 0.0) as Integer types might cause type mismatch exceptions at the runtime. All future implementations must use Double type for the currency related fields.
:::

## Cart Documents

To learn how to use cart documents, see [Use Cart Documents](/docs/industries/cme/guide/use-cart-document-cpq.md).

## Product Configuration Procedure (PCP) Execution Order

Product configuration procedure (PCP) rules must run before validation and pricing so that any attribute or line-item changes they make are included in those steps. Treat Standard Cart API behavior as the correct reference implementation.

### Standard Cart APIs

In Standard Cart APIs, PCP rules run once, before validation and pricing. Attribute values that PCP rules change are therefore available to the pricing engine.

When you set attribute values from custom code, use `setItemAttributes` so that PCP rules pick up the new values. See [Use CpqCartDocument](/docs/industries/cme/guide/use-cart-document-cpq.md#update-attribute-values).

Do not update attributes or line items during the pricing step. Pricing must operate on a stable, finalized set of line-item data.

### Classic Cart APIs

In Classic Cart APIs, PCP rules currently execute twice during Add Line Item (`postCartItems`) operations:

1. Once before validation and pricing
2. Once during the post-execute hook (after pricing)

The second execution is not the intended behavior:

- Changes made during the post-execute hook are not persisted.
- Modifying line items after pricing has started is not recommended, because pricing should operate on a stable, finalized set of line-item data.

To stop PCP rules from running in the post-execute hook, set both of these values to `False` in **Vlocity CMT Administration** → **CPQ Configuration Setup**:

- `RunPCPInAddPostExecuteMethod`
- `RunPCPInUpdatePostExecuteMethod`

## Attribute-Based Pricing

To learn how to use Attribute-Based Pricing, see [Set up Attribute-Based Pricing](/docs/industries/cme/guide/comms-set-up-attribute-based-pricing-cart.md).
For more information, see [Attribute-Based Pricing](https://help.salesforce.com/s/articleView?id=ind.comms_attribute_based_pricing.htm\&type=5)

## Context Mappings

Context Rules with context mappings having Initialisation Type as `Type In` and `Scope SObject` are not supported in Standard DC and Cart APIs.

## Changes to Response

### Messages Node in postCartItems API (Standard Cart API)

When a postCartItems API adds a product with configuration issues to the cart, the `messages` node in the Standard Cart API response shows both success and error messages. For example, if a required attribute lacks a default value and the product is still added, the `messages` node in response includes both the success and the error messages. Here's a sample messages node in the postCartItems API response:

```
{"severity": "INFO","message": "Successfully added.","code": "150"}
{"severity":"ERROR","message":"Required attribute missing for ProdWithTextAttr.", "code":"204","messageId":"...","bundleId":"..."}

```

:::note
The GetCartItems API still has the same behavior in Standard CPQ as in Classic CPQ for backward compatibility.
:::

### Actions Node

The `actions` node consists of two main protocols to invoke CPQ APIs, and there are separate nodes for each protocol: `remote` and `rest`.

In Classic CPQ, whether the API is invoked via REST or as a Remote call, it populates both `remote` and `rest` nodes.

In Standard CPQ, the API populates actions node based on the protocol.

- If a REST call is made, the API populates the rest action node in the response.
- If a Remote call is made, the API populates the remote action node in response.