Case study · Apparel & retail
An ERP that can price a product nobody has made yet
A customisable apparel brand sells garments that only exist once somebody configures them. Standard ERP assumes a catalogue of fixed products. We extended Business Central so a configuration is a first-class thing that can be costed, stocked against and manufactured.
Engagement · Extension & rollout
A Business Central extension for made-to-order manufacturing.
- Industry
- Apparel & retail
- Solution
- Made-to-order ERP extension
- Platform
- Dynamics 365 Business Central
- Engagement model
- Dedicated product team
- Market stage
- Scaling manufacturer
- Scope
- Extension, integration, rollout
- Integration
- eCommerce storefront
- Deployment
- Business Central online
Outcomes
What changed once configuration became first-class
A made-to-order business is judged on whether it can quote accurately and ship on time. Both depend on the ERP understanding what was ordered.
-
0
SKUs created per configuration
A configured garment is modelled as attributes against an order line, not as a new item card. The previous approach would have generated tens of thousands of dead SKUs within a year.
By design: configuration held as order-line attributes
-
95%
Reduction in manual order entry
Storefront configurations arrive in Business Central complete, with the bill of materials already derived, instead of being retyped by an order clerk.
Measured against orders previously keyed by hand
-
4 hrs
Faster quote turnaround
Costing runs against the derived bill of materials the moment a configuration is built, so a quote is produced while the customer is still deciding.
Measured from enquiry to quote issued
Context
The situation before the extension
Why a catalogue-shaped ERP fights a made-to-order business.
The business
A brand selling apparel that customers personalise — fabric, colour, trim, placement, sizing — so almost every order is a combination nobody has produced before.
The starting point
Business Central was in place for finance and purchasing, but every configured order was re-keyed by hand and costed from a spreadsheet the production manager maintained.
The trigger
Creating an item card per combination is the obvious fix and the wrong one: the permutations run to tens of thousands, and the item list becomes unusable within months.
What they wanted
Configurations that flow from the storefront into the ERP, cost themselves against real component prices, consume the right stock, and produce a works order the factory can follow.
Constraints
No SKU explosion · component stock has to reflect what configurations actually consume · costing must use live component prices, not a stale sheet · the factory needs a routing it recognises · the storefront and the ERP must never disagree about what was ordered.
System
What it runs at today
The extension as it runs today.
-
1
Item card per component
Stock is held at component level, where it physically exists
-
5
Configuration attribute groups
Fabric, colour, trim, placement and sizing, each with its own rules
-
2
Systems kept in step
Storefront and Business Central, one order record
-
0
Spreadsheets in the costing path
Costing runs from live component prices
The engineering problem
Four problems with made-to-order in a catalogue ERP
Every one of these comes from the same root: standard ERP assumes the product existed before the order did.
-
A SKU per combination destroys the item list
The instinctive approach is an item card for every configuration. With five attribute groups and a handful of options each, that is tens of thousands of cards — a list nobody can search, reports nobody can read, and a master-data job that never ends.
What we did
Configuration is stored as structured attributes on the sales line, with a derived bill of materials generated at order time. One component item card exists per physical thing the factory holds.
-
Costing has to happen before the product exists
A customer wants a price for a garment that has never been made. Costing from a maintained spreadsheet is slow and goes stale the moment a supplier price changes.
What we did
A costing routine that walks the derived bill of materials against live component costs, so a quote reflects what the components actually cost today.
-
Stock is consumed at component level, not product level
Availability for a configured garment is not a stock figure — it is a question about whether every component is available. Treating it as a single number tells the customer something untrue.
What we did
Availability is calculated across the derived bill of materials, so a promise date reflects the component with the longest lead time rather than an optimistic total.
-
The factory needs a works order, not an attribute list
A production team cannot work from a JSON blob of configuration choices. They need a routing with operations in the order they are performed.
What we did
The derived bill of materials feeds a production order with routing, so the factory receives the same document format regardless of how unusual the configuration is.
Architecture
How it fits together
Simplified — the shape of the system rather than every service in it.
-
Storefront
- Product configurator
- Attribute rules
- Price preview
The customer-facing configurator, with the same attribute rules the ERP holds, so the two cannot disagree about what is a valid combination.
-
Integration
- Order API
- Attribute mapping
- Idempotent posting
Configured orders post into Business Central complete, with retries resolving to the same order rather than creating a duplicate.
-
Business Central extension
- Configuration attributes
- Derived BOM
- Costing routine
- Availability
The AL extension: configuration held against the sales line, bill of materials derived from it, costing and availability calculated across that bill.
-
Production & finance
- Production orders
- Component inventory
- Standard BC posting
Downstream everything is ordinary Business Central — production orders, inventory movements and posting run on the standard functionality.
The extension deliberately stops at the point where standard Business Central takes over. Everything downstream of the derived bill of materials is stock functionality, which is what keeps the system upgradeable.
Solutions
What the extension adds
Four additions, each stopping at the point where standard Business Central already does the job.
-
Configuration model
Attribute groups with validity rules, held against the sales line rather than as item cards.
-
Bill of materials derivation
Components resolved from a configuration at order time, including quantities that vary with size.
-
Costing routine
Walks the derived bill against live component costs to produce a quote price.
-
Availability calculation
Promise dates driven by the component with the longest lead time, not an average.
-
Storefront integration
Configured orders posted into Business Central complete and idempotently.
-
Production handoff
A standard production order with routing, generated from the derived bill.
Key capabilities
What it does day to day
Six capabilities across the order-to-production path.
| Capability | Runs | Refresh | What it does |
|---|---|---|---|
| Product configuration | Customer | Per order | Attribute-based configuration with the same validity rules on the storefront and in the ERP |
| Derived bill of materials | Automatic | On order | Components resolved from the configuration rather than from a pre-built SKU |
| Costing | Automatic | On quote | Costed against live component prices, not a maintained spreadsheet |
| Availability | Automatic | Real time | Calculated across every component, so the promise date reflects the longest lead time |
| Production orders | Automatic | On release | A routing the factory recognises, whatever the configuration |
| Finance posting | Standard BC | Continuous | Ordinary Business Central posting downstream of the extension |
Integrations
How the moving parts plug in
A configuration travels from the storefront to the factory without being retyped.
Customer
- ConfiguratorFabric, colour, trim, placement, size
- Price previewFrom live component costs
- OrderPosted complete
Business Central extension
- Configuration attributesHeld on the sales line
- Derived BOMComponents resolved at order time
- Costing & availabilityAcross the whole bill
Standard Business Central
- Production order
- Component inventory
- Finance posting
Because the configuration lands on the order rather than becoming a new item, the item list stays the size of the component catalogue instead of growing with every sale.
Security & data
What keeps the data trustworthy
An ERP extension touches costing, inventory and posting, so the controls are about correctness as much as access.
-
Standard BC permissions
The extension uses Business Central's own permission sets rather than inventing a parallel model, so access stays where the finance team already administers it.
-
Idempotent order posting
A retried storefront post resolves to the existing order rather than creating a second one.
-
Costing traceability
Each derived bill of materials records the component prices used, so a historical quote can be explained months later.
-
Upgrade safety
The extension only adds; it does not modify base objects, so Business Central's continuous updates apply without a re-implementation.
The brief
Made-to-order is a data-modelling problem before it is an ERP problem
A brand that personalises its products is not selling a catalogue. It is selling a set of choices, and the thing the customer buys comes into existence at the moment they finish choosing. Standard ERP is built on the opposite assumption: the product exists, has a number, and has a cost.
The work here was deciding what a configured garment *is* inside Business Central. Get that wrong and everything downstream — costing, stock, production, reporting — inherits the mistake.
- Configuration as order data, not as a new product
- Components stocked where they physically exist
- Costing from live prices at the moment of quoting
- A works order the factory recognises
What the extension had to respect
- 01Business Central's upgrade path — no modified base objects
- 02The finance team's existing permission model
- 03The storefront's configurator rules, which must not drift from the ERP's
- 04A factory that works from printed routings
Process
We modelled the product before writing any AL
On an ERP extension the data model is the decision. Code written before that is code written twice.
-
Modelling the configuration
Working through every attribute, every rule about which combinations are valid, and how quantities change with size — before anything was built against it.
-
Deciding what Business Central already does
Mapping which parts were genuinely missing and which were us not knowing the product. The extension got smaller twice during this stage.
-
Building the extension
AL development against the agreed model, adding only, so the upgrade path stays intact.
-
Storefront integration
Posting configured orders in complete, with the configurator and the ERP sharing one set of validity rules.
-
Rollout with the factory
Production ran both ways for a period, with the old spreadsheet costing checked against the new routine until the numbers agreed.
Technology
A Business Central extension, not a parallel system
Everything that standard Business Central does well was left alone.
Business Central
- AL extension
- Business Central online
- Standard posting
- Permission sets
Configuration
- Attribute model
- Validity rules
- Derived BOM
Integration
- Order API
- Idempotent posting
- Attribute mapping
Production
- Production orders
- Routings
- Component inventory
Business impact
What changed for the business
Three things the operation noticed.
-
Quotes while the customer waits
Costing against live component prices turns a next-day quote into a same-conversation one.
-
An item list people can use
Components only. Searching for a fabric returns a fabric, not ten thousand garment permutations.
-
Upgrades stay routine
Because nothing in the base application was modified, Microsoft's updates land without a project attached.
The result
Tens of thousands of products, one manageable item list
Configured orders arrive from the storefront complete, cost themselves against live component prices, reserve the right components and produce a works order the factory recognises.
The item list holds components — the things that physically exist in the building — rather than a card for every combination a customer might one day choose.
- Configuration modelled as order data, not as SKUs
- Costing and availability derived at order time
- Standard production orders downstream
- No base objects modified, so upgrades stay routine
What we would repeat on a Dynamics extension
- 01Settle the data model before writing a line of AL
- 02Find out what the product already does before extending it
- 03Add, never modify — the upgrade path is worth more than the shortcut
- 04Run the old and new costing side by side until they agree
Verified reviews
What clients say about our Dynamics work
Verified reviews from clients of ours on similar work, published on Clutch. They are not from this project.
-
Custom Software Development
Web-Based Coupon App Development
The work produced by the team was of exceptional quality.
Jon Thies
CTO, Model Rocket Feb 2022 – Mar 2023
-
Custom Software Development
Mobile & Web Platform Development & Design
Silver Scintilla was responsive, respectful, and enjoyable to work with, quickly addressing any questions or requests.
DeShawn Brown
CEO & Founder, Lithios Jun 2021 – Nov 2022
-
Custom Software Development
Web-Based HRM System Development
Silver Scintilla provided the best solution with scalable functionality, personalized features, and robust security.
Suheb Khan
Director, Collaborative Insight Technologies Jul 2020 – Jun 2022
Free discovery call
Have an idea? Let's turn it into AI-powered software.
Book a free discovery call with our experts. Share your idea and we will help you shape the scope, timeline and budget, under NDA.
- Free consultation
- NDA before we talk
- Transparent estimate