1 Executive summary

Manufacturers, distributors, and retailers increasingly handle products whose sellable characteristics span multiple dimensions (size × color × material, etc.). Today Business Central’s single‑code Variant model cannot:

• express more than one variant dimension,
• group variants for streamlined pricing,
• keep document descriptions in sync with the chosen variant, or
• hold different Unit‑of‑Measure (UoM) conversion factors for each variant.

The result is item‑list proliferation, custom extensions, higher license & maintenance cost, and slower adoption. We propose an enhanced Variant framework that is backward‑compatible yet delivers the flexibility expected from modern ERP software.

2 Detailed proposal

1. Nested Variant Dimensions

(e.g., Size and Color on the same SKU)

Capability: Only one Variant Code field; customers create concatenated codes (“L‑RED”) or separate Item Nos.

Current Gap: Introduce a Variant Dimension master (table) in which each item can enable one or more dimensions (Size, Color, Style…). Variant records become the Cartesian combination of dimension values. Pages & APIs show dimension columns instead of a single code.

2. Variant Groups

(for pricing, discounts, planning)

Capability: Users mimic groups with prefix naming or Attribute filters; no native logic.

Current Gap: Add a Variant Group entity that can bundle any set of variants (e.g., All‑Matte‑Finishes). Extend Price/Discount, Item Ledger entry filtering, and MRP parameters to accept Variant Group in addition to Variant and Item filters.

3. Variant‑Aware Descriptions

Capability: Description on sales/purchase/warehouse docs must be manually edited or achieved via events.

Current Gap: Core platform concatenates [Item Description] + “ – ” + [Variant Description] (culture aware) whenever Variant is validated on any document or journal line. Provide a company switch per document type.

4. Unit of Measure by Variant

Capability: Table 5404 key = Item No. + Code; cannot store variant‑specific conversions.

Current Gap: Extend Item Unit of Measure key to include Variant ID. When a Variant is chosen, default UoM and Qty./UoM come from the matching record. Include validation logic in all posting code units and adjust planning engine conversions.

3 Business value

• Reduced master‑data explosion – one item can now cover dozens of combinations without concatenated Variant codes or new Item Nos.
• Accurate costing & pricing – variant‑specific carton/roll conversions, dimensional weights, or packaging factors drive precise landed cost and margin.
• Streamlined price list maintenance – pricing teams update a Variant Group once instead of touching every individual Variant.
• Cleaner user experience – customers and sales reps choose “12 in × Black” from drop‑downs; document lines auto‑describe the product correctly.
• Lower total cost of ownership – eliminates common customizations requested by almost every apparel, building‑products, and electronics customer.

4 User stories

1. Purchasing agent buys window‑flashing tape in cartons. The 4‑inch Size variant converts 1 Carton = 18 Rolls while 12‑inch converts 1 Carton = 6 Rolls. Purchase orders default Carton; receiving posts inventory in Rolls by Width automatically.
2. Salesperson adds Item TAPE‑FLASH to a sales quote, selects Size = 9 in and Color = Black. The line description instantly becomes “Window Flashing Tape – 9 in Black”.
3. Pricing manager runs a seasonal promotion on all Color = White variants across four tape widths by assigning them to Variant Group WHITE‑PROMO and uploading one price line.
4. Planner sets a safety stock level on Variant Group HIGH‑VOLUME‑WIDTHS comprising 6 in and 9 in sizes only.

5 Technical design considerations

• Backward compatibility:
• Default Variant Dimension setup = 1 dimension named “Variant Code”; existing data continues to work.
• Existing AL code that reads VariantCode still compiles; developers opt‑in to dimension arrays via new APIs.
• Performance:
• Table extensions indexed on (Item No., Variant ID) to match current key path lengths.
• API & Data Exchange:
• OData/V2 and v3 APIs expose variant dimensions as separate properties; legacy Variant Code returned as pipe‑delimited string for compatibility.
• Synch‑nav apps (Shopify, LS Retail) leverage the richer structure without data mapping hacks.
• Reporting:
• Standard reports gain fast filters on Variant Dimension and Variant Group.
• Analysis Views/Datasets include Variant Group as a dimension value.
• Upgrade path:
• Wizards convert concatenated Variant Codes (SIZE‑COLOR) into nested dimensions based on separator rules.