Dynamics 365 Business Central

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.

Field "G/L Account range" of table "Cost Type" (table 1103) is very short, only 50 char.

This short lenght makes unfriendly the activities of the user when mapping chart of account (many many records!) into the corresponding record of Chart of Cost Tipes (one record).

It is the same concept of "Totaling" field of Acc. Schedule line table that is 250 char.

It is not a blocking limitation but if the lenght of this field is extended we gain a better feeling from users that has to map Chart of account with Chart of cost type.

When creating/modifying a permission set you can either include/exclude whole permission sets by referencing them or single select individual objects that you would like to have included. The latter part can be very cumbersome when making custom permission sets for a customer.

An improvement in the process could be to allow for either multiselect or setting a range – or both.

By allowing multiselect you can do your lookup to the object list, set you filter/range and select potentially all, and have them added to your permission set.

By allowing to set a range, you would make it possible to select whole groups of objects in one go and set the object permissions for the whole range – plus it would make it more easy to get an overview, as it was a whole range that you would review in one go, and not having to go through one object at a time.

This would truly help to get customers to better utilize the permission sets, as it would make this process of creating the right permissions much smoother.

In Business Central, it is currently not possible to directly register the consumption of materials from an advanced warehouse (WMS-enabled location) within a service order. This limitation creates a significant gap for companies that rely on service management and also use warehouse management features.

We request the ability to:

• Register material consumption directly from a WMS-managed location in a service order.
• Maintain full traceability of consumed items linked to the service order.
• Avoid the need for workarounds such as inventory journals or warehouse transfers to non-WMS locations.

This functionality would greatly improve operational efficiency and data integrity for service-based organizations using advanced warehouse management.

he European Accessibility Act (EAA) mandates that PDF documents, like other digital content, be accessible to people with disabilities. PDF/UA (Universal Accessibility), defined by ISO 14289, is the standard that ensures PDFs meet accessibility requirements. The EAA, which came into effect in June 2022 with enforcement by July 2025, ensures that documents, including PDFs, are accessible to users of assistive technologies.

If I use Additional Reporting Currency then I must have the option insert „Additional-currency amount“ before posting Purchase Invoice in Purchase Invoice statistics – Lines. Please, add field Additional-Currency Amount, Additional-Currency Base to VAT amount Line. Program will fill in Additional-Currency Amount by currency Exchange rates. And then user adjust „Additional-Currency Amount“. Program will calculate Add.-Curr. VAT Difference. User must have possibility adjust Additional-Currency Amount because they must have right amount by document from vendor. This is necessary due to tax laws.

The result will be the correct filling of the VAT entry (field – „Additional-Currency Amount“ and field „Add.-Curr. VAT Difference“.)