Overrides are settings that let you replace fields and configurations for Products within particular Segments in the YOM system. They let you adjust prices and sales terms for a previously segmented group of Commerces. This makes it easier to customize prices and discounts by different criteria and time periods.
What is the purpose of overrides?
To let a Commerce see a correct, personalized catalog of Products. This means the commerce must see only the products assigned to it, with the correct prices and commercial terms.
Important design consideration
Although the Product object also contains price information and whether the product is enabled, the design decision was made that for all customers (CPG) and all commerces these characteristics (price and enabled) should always come from an override. The goal is for pricing and enablement to be the responsibility of a single model.
Why and how are overrides used?
Making sure a commerce sees the right catalog is a problem each CPG solves in its own way, with varied business rules. The brute-force solution is to store the (product, commerce) pair for every product and commerce. While that is a correct solution, it produces a huge amount of data, so a more efficient solution is needed: overrides. In this case two critical data pairs are stored: (product, segment), which corresponds to the override, and (segment, commerce), which corresponds to the usersegments model. This way, if two commerces share segments they will see the same catalog and there is no need to duplicate product information. This reduces the size of the stored data by several orders of magnitude.
An important detail is that not every product needs overrides for a segment, and a commerce can belong to several segments. When a commerce has a product modified by two segments, these overrides are applied in order of priority, from highest to lowest, when the catalog is queried. Applying an override means changing the fields present in Override to the value of the override being applied. If the override does not contain a field, that field is not changed. Similarly, the enabled field of overrides determines whether a product is enabled. A product is enabled if the lowest-priority override has the value true; if it has false, the product is not visible to that commerce.
To make sure every product is enabled and has a price from an override, the usual practice is to create a base segment. This is a segment that every commerce belongs to. In this base segment one override is created per product. This override has the enabled field set to false and a high priority value (that is, the other overrides take precedence over the base one). The value typically used for this is 10000. A price of 99999 is also usually set, but that is done to make errors easier to spot.
Business examples
Single price list case:
If a customer has one price list used for all commerces, there will be two segments: the base segment and the segment corresponding to the single price list. All commerces will be assigned these two segments. The single-list segment will have one override per product (if the price list does not include a product, the base override turns it off).
Multiple price list cases:
One commerce, one list: this happens when a commerce has a single price list. It can be due to regional pricing, commercial terms, and so on. In this case, if there are N price lists, there are N+1 segments: the base segment and one segment per price list. Each commerce has two segments: the base segment and one of the others. Here not every product may have an override, because some products are exclusive to certain regions.
One commerce with multiple price lists: this situation occurs when price segmentation varies by category, or when there are restrictions on selling certain products to a commerce (alcohol, for example). Several examples follow.
| --- | --- | --- | --- | --- |
The pricing structure lets you define Overrides related to the Product price within the Segment.
| --- | --- | --- | --- | --- |
Example
"pricing": {
"pricePerUnit": 10000,
"operation": "replace",
"discountType": "percentage",
"discountList": [0.05, 0.10],
}
In this example:
"replace", replacing the price."percentage".The constraints structure lets you define overrides on the same field in the Product object. This is mainly used to change the minimum purchase units for a given Segment.
| --- | --- | --- | --- | --- |
Example
{
"minUnit": 12,
"stepSize": 6
}
In this example, this segment is required to buy a minimum of 12 units of the Product, and to add them in groups of 6.
The tax structure lets you define overrides on the same field in the Product object. This is mainly used to change the purchase tax for a given Segment.
| --- | --- | --- | --- | --- |
Example
{
"taxCode": "IVA-15",
"taxRate": 0.15,
"taxName": "IVA"
}