Gene Lane Chief Operations Officer

It would be nice to be able to use Azure Blob storage as standard storage for attachments in Business Central. We have found https://www.linkedin.com/pulse/business-central-azure-blob-storage-bert-verbeek/ for a custom setup, but when for example sales documents are moved (Quote --> Order --> Posted Invoice) the documents do not transfer and cause issues.

Firstly, would like a feature that in company setup that allows you to toggle on and off using item variants, this would then update all reports to include variants when run.

For example: Sales Orders would concatenate the item code and variant code.

Pages would automatically add the variant code on the view without the need for personalization.

Secondly, would like to see the ability to have Item Variant Groups. This would allow us to have the same master item, with multiple groups underneath that have multiple item variants. We sell products where there are 5 "groups" for the different colors of the product. However, each group has its own cost and its own sales price.

On both the Sales Documents lists (ie Sales Orders, Sales Invoices, Returns, etc.) and Purchase documents alike, it would be awesome if the amount recalculated to show what was remaining.

For instance: if a sales order originally had $1,000 on the order, but $750 was shipped and invoiced, the remaining amount would show only $250 instead of the $1,000.

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.