Transitioning from Sitecore Experience Commerce to OrderCloud: Inventory and Pricing

In this article, we will review and compare Sitecore Experience Commerce inventory and pricing entities against OrderCloud's inventory and pricing to facilitate developers looking to transition from XC to OrderCloud as well as identify a path for migration of existing XC solutions to OrderCloud.

We will look at a high-level comparison of architecture, functionality, and data models, with greater focus on transitioning from Sitecore Experience Commerce, meaning identifying the closest path to parity as possible in OrderCloud, using the Habitat catalog and SXA Storefront.

Conceptual Architecture and Features

Inventory

Single Inventory Approach

When it comes to inventory management, in its most basic form, a sellable item or item variation will contain inventory information on an associated entity within an inventory set. To be able to resolve the inventory, the sellable item must be associated to a catalog (or category within a catalog) and the catalog must be associated to the inventory set.

Figure 1: The sellable item and item variation relationship to inventory information.

In a more simplified comparison, OrderCloud also has a separate underlying inventory object assigned to a product or variant, however it's represented and managed as a sub-object of the product/variant. No relationship to a catalog or inventory set equivalent is required.

Figure 2: The product and variant relationship to inventory, equivalent to XC's standard inventory architecture for single inventory management.

Multi-Inventory Approach

When it comes to dealing with multiple catalogs in XC, the approach has a new layer of complexity; catalogs may have different associated inventory sets, which means that the inventory information entity the commerce engine resolves to is based on catalog-inventory set association.

Figure 3: Sellable item vs item variation inventory management in XC.

In OrderCloud, it is also possible to store multiple sets of inventory data using inventory records, providing two paths for inventory management. For implementations where single sets of inventory data will only ever be required, the traditional inventory management approach in figure 2 can be used. Where multi-inventory management is required, inventory records can be leveraged.

In OrderCloud's multi-inventory management approach, admin addresses are effectively the inventory set equivalent in creating a logical grouping of inventory records; catalog assignments are still not required to resolve inventory.

Multiple inventory records can be assigned to an address, and although it's not required in the XC to OrderCloud migration, it's mentioned simply for a more complete understanding of the OrderCloud architecture.

Figure 4: OrderCloud's inventory record approach for both single and multi-inventory support.

The most notable difference between the two systems is the Commerce Engine controls the logic to resolve the appropriate inventory information entity, while the middleware application of an OrderCloud implementation would be responsible for resolving applicable inventory records.

Inventory sets can represent the grouping of inventory information entities, typically for source or purpose, e.g. warehouse stock or reserved inventory for online sales. These are used in common customisations, such as click and collect, where more than one inventory set is utilised in a storefront. Using inventory records in OrderCloud can achieve the same result.

Inventory Properties

Apart from the expected quantity property, XC's inventory information also contains information such as invoice unit price and currency, preorderable and backorderable details. While the commerce engine does perform some logic for decrementing backorder and preorder inventory quantities, the implementation is not complete, therefore we won't treat this as a functional gap between the two systems and simply adding them to OrderCloud's extended properties (xp) will suffice from the data migration perspective.

Inventory records have the additional benefit of owning their xp. This means that additional properties such as preorderable and backorderable details better fit the context in the inventory record xp, over the product xp, which would be required when using the traditional product inventory approach.

Pricing

The pricing architecture is where we run into some challenges during an XC to OrderCloud migration. As XC supports both list prices and price cards at both the sellable item level and the item variation level, including a mix of both, we'll try and cover the most likely scenarios.

List Pricing Approach - Sellable Item Level

Starting with the most basic approach to pricing migration, sellable items have a list price policy that stores a list of multi-currency pricing. Note that item variations do not have list pricing in this example and will inherit from the sellable item. Also leaving the price card architecture out of the equation, the list pricing approach is represented in figure 5.

Figure 5: XC list pricing for sellable items and item variations.

In OrderCloud, pricing is managed via price schedule objects that are assigned to products. In order to replicate the XC architecture, a price schedule is required to represent each list price, then a product assignment is used to create the relationship between the product, the price schedule, and finally a buyer user group. The buyer user group represents the currency that will be resolved by the OrderCloud API and the custom middleware would then be responsible for moving a buyer user between the buyer groups.

This approach would only work for profiled users. See OrderCloud: How to Globalize your eCommerce for more information.

Figure 6: A multi-currency approach for profiled users.

If we only need to support a single currency then we can take advantage of a more simplified approach using just the product and price schedule, using the DefaultPriceScheduleID.

Figure 7: OrderCloud single price approach for products and products with variants.

List Pricing Approach - Item Variation Level

XC also allows for list prices to be set at the item variation level, which includes fallback to the sellable item list pricing if not supplied. Excluding the fallback pricing, we see the following representation of a sellable item with list pricing configured against the item variations in figure 8.

Figure 8: XC list pricing at the variant level.

While OrderCloud does support price markups on spec options, which does alter variant pricing, the functionality is quite rigid and we will find that we won't be able to replicate variant level pricing that XC allows.

More information regarding product specs and price markup can be found at OrderCloud: Working with Specs - Price Markup.

Price Card Approach

Associations

In XC, a price book can be associated to multiple catalogs, which represents the price book that the catalog will attempt to resolve price cards from for a given sellable item.

Figure 9: Price Books can be associated to more than one catalog.

Price cards can be resolved, by name or by tag association, to more than one price card across multiple price books. The Commerce Engine contains some additional logic to identify the eligible price cards, prioritise them, and determine the winning price card.

Figure 10: Sellable items are resolved back to a price book based on catalog-price book associations, however multiple price cards may also be resolved. Associations may be resolved by price card name or by tag.
Scheduled Pricing

Taking a step back to look at the minimal configuration of a single price card associated to a sellable item, the price snapshots on the price card represent scheduled pricing. Each snapshot supports multi-currency tiered pricing, and also has approval workflow to prevent new pricing from accidently going live.

Figure 11: Resolving a price from a single price card association in XC.

In OrderCloud, the price schedule contains PriceBreaks, allowing for tier pricing for a single currency. The SaleStart and SaleEnd date/time properties dictate the timeframe when the SalePrice values are active, which is also flagged by the calculated property IsOnSale.

PriceSchedule assignments support price scheduling without needing to differ from the assignment architecture shown in figure 6 and figure 7.

"PriceBreaks": [
  {
    "Quantity": 1,
    "Price": 3.99,
    "SalePrice": null
  },
  {
    "Quantity": 5,
    "Price": 3.49,
    "SalePrice": 2.99
  }
],
"Currency": "USD",
"SaleStart": "2022-03-03T00:00:00+00:00",
"SaleEnd": "2022-04-03T00:00:00+00:00",
"IsOnSale": true
Challenges

With an undertanding of XC price card functionality, OrderCloud does not have the capabilities to replicate the functionality. A summary of the challenges facing price card migration are documented in the table below.

XCOrderCloud
A sellable item can resolve to multiple price cards, which has logic to prioritise and resolve a single price card.Where OrderCloud has multiple price schedules assigned at the same level of specificity, there is no logic to identify which price schedule should be prioritised, which may result in unexpected pricing being applied.
Price cards are grouped into price books, which can be resolved by the price book association of the catalog.Price schedules can be assigned to a specific buyer group, however this is not enough to replicate XC behaviour for determining price by catalog assignment.
Price cards may contain multiple price snapshots for scheduled pricing support.Price schedules allow for sale pricing, based on a specific date and time, however I future sale price cannot be prepared ahead of time if a sale price is currently active.
Using price cards without list pricing allows standard pricing to be scheduled.Price schedules only allow sale pricing to be scheduled, however the standard price may still be updated in real-time.
Price cards support multi-currency.OrderCloud has partial multi-currency support, however there is no support for products that require variant-specific pricing.
XC pricing has support for item variation-specific pricing.OrderCloud has no support for products that require variant-specific pricing, although it does have price markups per spec option, which does not align with XC's item variation-specific pricing.
XC Price Snapshots have approval workflow.Price schedules have no approval workflow.

Data Mapping

With the conceptual analysis above, we will now review what data mapping would look like for migration and from a comparison standpoint.

In the XC Entity/Component column, components are assumed to live on the primary XC entity being mapped.

OrderCloud IDs do not allow spaces. It is important that the IDs are parsed to remove/replace invalid characters consistently.

Admin Addresses

While admin addresses are a representation of inventory sets, there are a number of mandatory fields for address details that do not exist in XC. These fields can either be filled out with dummy data or enriched with the appropriate values.

OC PropertyData TypeRequiredXC Entity/ComponentXC PropertyData TypeNotes
IDstringNoInventorySetFriendlyIdstring
CompanyNamestringNoN/AN/AN/A
FirstNamestringYesN/AN/AN/A
LastNamestringNoN/AN/AN/A
Street1stringYesN/AN/AN/ASample data will need to be supplied.
Street2stringNoN/AN/AN/A
CitystringYesN/AN/AN/ASample data will need to be supplied.
StatestringYesN/AN/AN/ASample data will need to be supplied.
ZipstringYesN/AN/AN/ASample data will need to be supplied.
CountrystringYesN/AN/AN/ASample data will need to be supplied.
PhonestringNoN/AN/AN/A
AddressNamestringNoInventorySetDisplayNamestring
xpobjectNoN/AN/AN/A
xp.DescriptionstringNoInventorySetDescriptionstring

Inventory Records

The xp in inventory records should only be mapped if they are being used in the XC implementation to avoid unnecessary bloating of the xp. The xp mapping can also be used on the product for the traditional inventory management approach.

OC PropertyData TypeRequiredXC Entity/ComponentXC PropertyData TypeNotes
productIDstringYesSellableItemFriendlyIdstring
IDstringNoInventoryInformationFriendlyIdstring
OwnerIDstringNoN/AN/AN/A
AddressIDstringNoInventorySetFriendlyIdstring
OrderCanExceedbooleanNoN/AN/AN/A
QuantityAvailableintegerNoInventoryInformationQuantityinteger
xpobjectNoN/AN/AN/A
xp.InvoiceUnitAmountdecimalNoInventoryInformationInvoiceUnitPrice.Amountdecimal
xp.InvoiceUnitCurrencystringNoInventoryInformationInvoiceUnitPrice.CurrencyCodestring
xp.PreorderablebooleanNo[PreorderableComponent]Preorderableboolean
xp.PreorderAvailabilityDatedatetimeoffsetNo[PreorderableComponent]PreorderAvailabilityDatedatetimeoffset
xp.PreorderedQuantityintegerNo[PreorderableComponent]PreorderedQuantityinteger
xp.PreorderLimitintegerNo[PreorderableComponent]PreorderLimitinteger
xp.BackorderablebooleanNo[BackorderableComponent]Backorderableboolean
xp.BackorderAvailabilityDatedatetimeoffsetNo[BackorderableComponent]BackorderAvailabilityDatedatetimeoffset
xp.BackorderedQuantityintegerNo[BackorderableComponent]BackorderedQuantityinteger
xp.BackorderLimitintegerNo[BackorderableComponent]BackorderLimitinteger

Price Schedules

As price schedules only support the equivalent of static list pricing of XC's sellable items, this data mapping only covers this scenario.

OC PropertyData TypeRequiredXC Entity/ComponentXC PropertyData TypeNotes
OwnerIDstringNoN/AN/AN/A
IDstringNoSellableItem
[ListPricePolicy].Prices
FriendlyId
CurrencyCode
string
string
NamestringYesSellableItem
[ListPricePolicy].Prices
FriendlyId
CurrencyCode
string
string
ApplyTaxstringNoN/AN/AN/A
ApplyShippingbooleanNoN/AN/AN/A
MinQuantityintegerNoN/AN/AN/A
MaxQuantityintegerNo~[LineQuantityPolicy]MaximumdecimalXC stores this in the environment policies.
UseCumulativeQuantitybooleanNo~[RollupCartLinesPolicy]RollupbooleanXC stores this in the environment policies.
RestrictedQuantitybooleanNoN/AN/AN/A
PriceBreaksarrayNoN/AN/AN/A
PriceBreaks.QuantityintegerNoN/AN/AN/ASet to 1.
PriceBreaks.PricefloatNo[ListPricePolicy].PricesAmountdecimalFor a given price in the [ListPricePolicy].Prices array.
CurrencystringNo[ListPricePolicy].PricesCurrencyCodestringFor a given price in the [ListPricePolicy].Prices array.
xpobjectNoN/AN/AN/A

References

Sitecore Experience Commerce: Pricing Calculation Logic – Part 2

In this article, we highlight the expected pricing outcomes through decision tables.

For a high-level look at the important aspects of the business logic that determine list and sell prices, see Pricing Calculation Logic - Part 1.

Pricing Transparency (Advanced)

The following decision tables can be utilised to help understand and troubleshoot pricing outcomes.

Important notes:

  • The business logic applies to the OOTB Sitecore Commerce solution.
  • Price cards are resolved by the price book associated to the catalog.
  • These findings do not take into consideration promotions, specifically those that affect sellable item/variant sell price.

Sellable Item Price Calculation

These messages will be applied to the MessagesComponent of a  SellableItem entity.

In simplying the table, I took a few shortcuts to note:

  • 'Valid snapshot' conditions assume a price card has been resolved by name or tag. Refer to the previous flow diagrams in Pricing Calculation Logic - Part 1 to understand the more complex conditions.
  • For 'Has variants?', 'Calculate item list price in depth?', and 'Has list price for currency?' conditions, the Rules that state a group 'N'. However, I actually mean that some, but not all, of these conditions can be true.

Variant Price Calculation

These messages will be applied to the MessagesComponent of a  ItemVariationComponent within the SellableItem entity.

In simplying the table, I took a few shortcuts to note:

  • 'Valid snapshot' conditions assume a price card has been resolved by name or tag. Refer to the previous flow diagrams in Pricing Calculation Logic - Part 1 to understand the more complex conditions.

Cart Item Calculation (Sellable Item)

These messages will be applied to the MessagesComponent of a sellable item CartLineComponent.

Messages will be applied in the following order:

  1. Sellable Item Price Calculation
  2. Cart Item Calculation (Sellable Item)

Cart Item Calculation (Variant)

These messages will be applied to the MessagesComponent of a variant CartLineComponent.

Messages will be applied in the following order:

  1. Sellable Item Price Calculation
  2. Variant Price Calculation
  3. Cart Item Calculation (Variant)

References

Sitecore Experience Commerce: Pricing Calculation Logic – Part 1

In this multi-part article, we will review the Sellable Item/Variant price calculation processes that determines and differentiates the list pricing from the sell pricing.

As this is one of the more complex areas of Sitecore Commerce, Part 1 will cover the business logic used to apply the pricing, while Pricing Calculation Logic - Part 2 will highlight the expected pricing outcomes through decision tables.

This article is intended to suplement the official Pricing transparency documentation.

Introduction

The  MessagesComponent on the SellableItem entity, ItemVariationComponent, and CartProductComponent provides the audit trail for how the sellable item/variant pricing was calculated. The '<=' in the Text property is not a logic operator, but instead represents the assignment of the source to the price type.

{
	"@odata.type": "#Sitecore.Commerce.Core.MessagesComponent",
	"Id": "47edb873fe754c89ae4bc41d7c309811",
	"Name": "",
	"Comments": "",
	"Policies": [],
	"Messages": [
		{
			"Code": "Pricing",
			"Text": "SellPrice<=PriceCard.Snapshot: Price=$10.00|Qty=1.0|PriceCard=Habitat_PriceCard"
		},
		{
			"Code": "Pricing",
			"Text": "ListPrice<=PricingPolicy: Price=$1,919.69"
		}
	],
	"ChildComponents": []
}
{
	"@odata.type": "#Sitecore.Commerce.Core.MessagesComponent",
	"Id": "ed77a9de5db941ffbfcf0b217e3affda",
	"Name": "",
	"Comments": "",
	"Policies": [],
	"Messages": [
		{
			"Code": "Pricing",
			"Text": "Variation.SellPrice<=Variation.PriceCard.Snapshot: Price=$9.00|Qty=1.0|Variation=56042567|PriceCard=Habitat_VariantsPriceCard"
		},
		{
			"Code": "Pricing",
			"Text": "Variation.ListPrice<=Variation.PricePolicy: Variation=56042567|Price=$2,429.99"
		}
	],
	"ChildComponents": []
}
{
	"@odata.type": "#Sitecore.Commerce.Core.MessagesComponent",
	"Id": "7e6bc27965ef4f3a954e6fcdadb96fa5",
	"Name": "",
	"Comments": "",
	"Policies": [],
	"Messages": [
		{
			"Code": "Pricing",
			"Text": "SellPrice<=PriceCard.Snapshot: Price=$10.00|Qty=1.0|PriceCard=Habitat_PriceCard"
		},
		{
			"Code": "Pricing",
			"Text": "ListPrice<=PricingPolicy: Price=$1,919.69"
		},
		{
			"Code": "Pricing",
			"Text": "Variation.SellPrice<=Variation.PriceCard.Snapshot: Price=$9.00|Qty=1.0|Variation=56042567|PriceCard=Habitat_VariantsPriceCard"
		},
		{
			"Code": "Pricing",
			"Text": "Variation.ListPrice<=Variation.PricePolicy: Variation=56042567|Price=$2,429.99"
		},
		{
			"Code": "Pricing",
			"Text": "CartItem.SellPrice<=PriceCard.ActiveSnapshot: Price=$6.00|Qty=5.0"
		},
		{
			"Code": "Pricing",
			"Text": "CartItem.ListPrice<=SellableItem.Variation.ListPrice: Price=$2,429.99"
		}
	],
	"ChildComponents": []
}

The 2 primary pricing scenarios we see in Sitecore Commerce are:

  • The pricing of a sellable item/variant as is (per single unit)
  • The pricing of a sellable item/variant once added to the cart. Pricing calculations here may also affected by quantity, via price tiers of associated price cards, and specific promotions that affect the sell price.

Sellable Item/Variant Pricing Calculations

The first scenario, where we are retrieving a sellable item/variant, to display on the Product Listing or Product Details pages for example, calculates the pricing through the following steps:

  1. Calculate Sellable Item Sell Price
  2. Calculate Variations Sell Price
  3. Calculate Sellable Item List Price
  4. Calculate Variations List Price
  5. Reconcile Sellable Item Prices

Important notes:

  • The business logic applies to the OOTB Sitecore Commerce solution.
  • Price cards are resolved by the price book associated to the catalog.
  • These findings do not take into consideration promotions, specifically those that affect sellable item/variant sell price.

Calculate Sellable Item Sell Price

The CalculateSellableItemSellPriceBlock will attempt to determine the sell price for the sellable item, adding it to the PurchaseOptionMoneyPolicy.

Notable flow aspects

  • Only the first attempt at resolving a price card will be utilised. i.e. if the price card name associated to the sellable item cannot be resolved to a price card or valid snapshot, the price card by tags logic is not used as a fall back.

Calculate Variations Sell Price

The CalculateVariationsSellPriceBlock will attempt to determine the sell price for each variant of the sellable item.

Notable flow aspects

  • The flow diagram represents a single variant. The pipeline block will utilise this flow for each variant.
  • Only the first attempt at resolving a price card will be utilised.
  • If the price card is resolved from the sellable item, the message will not reflect that the price card was retrieved from the sellable item.

Calculate Sellable Item List Price

The CalculateSellableItemListPriceBlock will attempt to determine the list price for sellable item.

Notable flow aspects

  • The GlobalPricingPolicy's CalculateItemListPriceInDepth property is set to false by default.
  • When iterating over variants for a valid ListPricingPolicy, the first variant to have a valid ListPricingPolicy will be used. The logic does not look for the lowest or highest price amongst all variants.

Calculate Variations List Price

The CalculateVariationsListPriceBlock will attempt to determine the list price for each variant of the sellable item.

Reconcile Sellable Item Prices

The ReconcileSellableItemPricesBlock will attempt to resolve missing List Prices and Sell Prices from the sellable item and variants. A flow diagram has been created for the Sellable Item and Variants separately.

Notable flow aspects

  • Setting the list price to 0 will ensure a price has been assigned.

Notable flow aspects

  • Setting the list price to 0 will ensure a price has been assigned.

Cart Line Calculations

The second scenario mentioned was that where the pricing calculation of sellable items/variants that have been added to the cart. The following step is performed after the standard pricing calculations to take into consideration the price tiers from price cards:

  1. Calculate Cart Line Price

Calculate Cart Line Price

The CalculateCartLinePricesBlock will determine and apply the appropriate list and sell prices for each cart line.

Notable flow aspects

  • There is an expectation that the list price and sell prices would have been resolved in Reconcile Sellable Item Prices.
  • Where a snapshot exists on a sellable item/variant the cart line's quantity value will determine the price tier that will be utilised to retrieve the sell price from.
  • The messages from the Sellable Item and, if applicable, Variant are copied into the cart line MessagesComponent to document the pricing stacks, which assist in auditing pricing overrides in determining the final pricing.

Glossary

Navigating the pricing logic can be time-consuming due to similar and varied terms being used for similar or varying components, so here is a short glossary for better clarification.

  • Sellable Item/Variant List Pricing (Policy): The list pricing policy represents an array of prices (only one price per currency) that are associated to a sellable item/variant is specified under the Pricing entity view of the sellable item/variant in the Merchanding manager.
  • Price Card (Name): The price card or price card name associated to the sellable item/variant is specified under the Pricing entity view of the sellable item/variant in the Merchanding manager.
  • Sellable Item/Variant list price: This is the ListPrice property of a Sellable Item/Variant, not to be confused with the ListPricingPolicy.
    "Policies": [
    	{
    		"@odata.type": "#Sitecore.Commerce.Plugin.Pricing.ListPricingPolicy",
    		"PolicyId": "0d4cee51dffd44aa8a019394dd5ad1b1",
    		"Prices": [
    			{
    				"CurrencyCode": "USD",
    				"Amount": 1919.69
    			},
    			{
    				"CurrencyCode": "CAD",
    				"Amount": 2078.26
    			}
    		]
    	}
    ],
    "ListPrice": {
    	"CurrencyCode": "USD",
    	"Amount": 1919.69
    }
    
  • Sell Price: The sell price is associated to a Sellable Item/Variant or Cart Line via the PurchaseOptionMoneyPolicy.
    "Policies": [
    	{
    		"@odata.type": "#Sitecore.Commerce.Plugin.Pricing.PurchaseOptionMoneyPolicy",
    		"PolicyId": "12b963fe3b2b47618555c8783c877002",
    		"Models": [],
    		"Expires": "2019-04-22T12:30:46.5380974Z",
    		"SellPrice": {
    			"CurrencyCode": "USD",
    			"Amount": 10
    		},
    		"FixedSellPrice": false
    	}
    ]
    
  • (Cart Line) Unit List Price: This is the determined list price of the cart line.
    "Policies": [
    	{
    		"@odata.type": "#Sitecore.Commerce.Plugin.Pricing.PurchaseOptionMoneyPolicy",
    		"PolicyId": "5e6c1f42c7c94bc4b79696e716b6cda5",
    		"Models": [],
    		"Expires": "2019-04-22T13:13:18.8117816Z",
    		"SellPrice": {
    			"CurrencyCode": "USD",
    			"Amount": 6
    		},
    		"FixedSellPrice": false
    	}
    ],
    "UnitListPrice": {
    	"CurrencyCode": "USD",
    	"Amount": 2429.99
    }
    

References