Basket Validation

Basket validation ensures that certain conditions are met before performing an operation on a basket.

The following basket items are checked:

The user is eligible for the offers contained in the basket.
The offers in the basket are effective.
The price list entries that were used to create the basket are still effective.

Basket validation is enabled or disabled by passing the validatebasket query parameter. The default value is true. To turn off the basket validation, pass false as the value for the query parameter.

The basket operations that supports basket validation are shown here:

Basket Operation	Description
Add offer to a basket	The effectivity and eligibility of the root offer is checked. If the offer is eligible and effective, the add-to-basket will proceed.
Add new offer to an existing basket	The existing basket is validated. Only when the basket is valid, any add or update operations are allowed.
Update an existing basket	The existing basket is validated. Only when the basket is valid, any add or update operations are allowed.
Get basket details	The basket details are validated. Depending on the the validation result, the response will be modified.
Delete offer from an existing basket	The delete operation is performed first, and the validation is preformed on the remaining offers in the basket.
Create cart using a basket	The basket is validated. Only if the validation is successful will cart creation be allowed.

The fields in the table below are checked when performing effectivity checking:


For products	<>IsActiveIsOrderableSellingStartDateSellingEndDateEndOfLifeDate</>
For promotions	<>IsActiveIsOrderableEffectiveFromEffectiveUntil</>
For price list entries	<>IsActiveEffectiveFromEffectiveUntilThe calculated effective date based on the TimePlan and TimePolicy applied</>

When adding an offer (either a product or promotion) to the basket (either an empty basket or an existing valid basket), the eligibility and effectivity of the offer that is being added is checked. Only when the offer is eligible and effective will the basket be created. For invalid offers, depending on the reason, the different responses are shown below.

Example: An ineligible offer is added for anonymous users.

Response:

validation1

Example: An ineligible offer is added for logged-in users.

Response:

Validation2

Example: The offer being added is not effective.

Response

Validation3

Example: The product being added to the basket does not have a valid price list entry.

Response:

Validation4

An existing basket might have one or more ineligible offers in it. This may be because the basket was created in an older version of the product (pre-Fall '20) or the basket was created with validatebasket query parameter set to false. For this example, assume that the basket was created with a bundle named DTHOffer, and DTHOffer is eligible only if the account SLA is Silver. Also, the default value of the SLA is Bronze. Below is the basket structure:

Example: Validation while performing basket operation on an invalid basket having ineligible offer(s)

For the above basket, a subsequent basket operation will return one of the following responses:

Anonymous user:

Result:
Logged-in user, case 1:

Result:
Logged-in user, case 2

Result:

After some time interval, the offers in the basket are eligible but,For offer SportsPack,

The SellingEndDate and EndOfLifeDate are ineffective.
The Effective Until Date of the OT PLE,50$OTCharge, used, is now ineffective

Once the basket is ineffective, further basket operations (except getBasket) return a response similar to the response shown below.

Response

When an invalid basket is found during basket validation, the response will contain an extra node named BasketValidationResult. In the node, the details about why the basket is invalid are available. The InvalidOffers node contains:

InvalidPLEs - This node contains the details of all the ineffective price list entries for all of the invalid offers in the basket.
InvalidProducts - This node contains the details of the products that are invalid, with the name of the fields indicating which product is invalid.
InvalidPromotions - This node contains the details of the promotion(s) that are invalid, with the name of the fields indicating which the promotion is invalid.

If basket validation fails, the errorCode in the response will be 422 with an appropriate error message.

When a getBasket operation is performed, an extra nextAction node is available in the response. This node contains details about how to correct the basket. See the examples for more information.

For add-to-basket operations, validation is performed only when basketAction is set to AddWithNoConfig.
Price list entry validation is only for price list entries that were used to create the basket. If an offer has more than one price list entry but was not used, then the validation will not be performed for those price list entries.
Price list entry validation is performed only if the basket was created with active PricingInterface implementation as PricingPlanService.
Basket validation does not support the price list entry validation if the pricing is done using a custom implementation for PricingInterface; for example, if the prices were picked from a Matrix.
For price list entry validation, there must be an entry in the CachedAPIResponse__c SObject of Type=pleOfferMap and cacheKey=<<CartContextKey>> must be available. If the basket was created using a version earlier than Fall '20, the pleOfferMap will not be available for that basket; therefore the PLE validation for that basket will be skipped.
Basket validation does not apply to the effectivity of the CatalogProductRelationship.
When adding a new offer to either an empty or existing basket, validation is performed only for the root offer; that is, only for the offer passed in the post body of the API call. Validations are not done for child products or auto-add relationship products.
Effectivity checking for new offers is supported starting in Fall '20f. If offer details were generated in an earlier version, the effectivity check for the offer being added to the basket will not occur.
The eligibility check for the offers in the basket is done only for the offers present in the catalog passed in the input. If there are offers from different catalogs, they will not be checked for eligibility.