The mental model
A is a single apparel design — a men’s polo for SS27, a winter parka, a kids’ tee — kept in one place and reused across every order, season, and customer that sells it. Around that one record, four roles divide the work cleanly:- The style owns the design and the documents that define it.
- Orders consume the style — a customer commits to buy specific colorways and quantities of it by a given date.
- Manufacturing orders produce the style — they are the production documents issued for a specific order’s run of it.
- Versions preserve history — the style’s documents move forward as numbered revisions, so the style keeps evolving while every earlier state remains intact for the order it was built for.
What the style owns
The style record is the home of the design. It carries the design’s commercial identity and owns every document that describes how the design is made and costed. The style’s commercial identity:- The design’s name, the the design was developed for, the season, the gender, and the structured list of the design is produced in.
- The style’s thumbnail image — what you see in lists, pickers, and reports across the system.
- A unique style number assigned by the platform on create.
- Its — the per-piece list of fabrics and trims.
- Its — the per-piece price build-up, factory side and customer side.
- Its tech-pack files — the design and construction package the factory works from.
- Its other production artifacts — the , packing, quality-control, and cost-analysis records that attach to the design.
The customer is captured at the design
When you link a Customer to a style at create-time, the customer’s name is captured on the style and stays visible on the style row, on pickers, and on reports. The capture is deliberate: the style is a long-lived design record, and its readable identity for the buyer it was developed for must survive churn in the customer master. Even if the customer record is later removed, the captured name stays on the style — so a year-old design still reads as the design it was. The Style page covers the linking rules and the unlink behavior in full.How orders consume the style
An is a customer’s commitment to buy specific colorways and quantities of one or more styles by a specific ship date. Orders consume styles — they point back at the style they run, draw on the style’s BOM and cost sheet for their material list and costing, and add the order-side details that only that order needs. The line between the two is sharp:- On the style: the design’s reusable identity, its documents, and the colorway palette it is produced in.
- On the order: the customer commitment — which colorways are being ordered, in what sizes, in what quantities, at what prices, for what ship date.
How manufacturing orders produce the style
A manufacturing order is the production document issued for a specific order’s run of a style. It references the version of the style’s artifacts that have been approved for that run, so the factory works from a settled material list and a settled price build-up rather than from whatever the style happens to look like today. This page does not go deeper than the model-level role; the full mechanics live on the manufacturing-order pages.How versions keep history first-class
If many orders share one style, what stops a change made for one order from disturbing another? Versioning. Every meaningful change to a style document — a BOM revision, a cost-sheet revision — saves as a new . The previous version stays exactly as it was. Each order keeps a pin onto the version it is working from, so:- An order in production carries on with the version it was built on, even after the style has moved on.
- Revising a document for one order does not silently change another.
- The history of every change is preserved, not overwritten.
Contrast: order-centric vs. style-centric
A traditional order-centric system puts the product inside the order. The same jacket ordered three times becomes three separate copies of the BOM and the cost sheet, each re-entered, with no shared record and no easy way to compare or reuse them. When the customer asks for a swap on the autumn order, no one is sure which copy of the BOM the spring order was built on. GarmentFlow’s style-centric model puts the product in the style. The jacket is entered once, the BOM and cost sheet are built once, and the orders point back at the style they run. Reorders draw on what is already there. Changes for one order are captured as a new version that order is pinned to; other orders are not disturbed. The design’s full history sits in one place — readable months and seasons later.Where you encounter the model
- In the Styles module — the list of every style in your tenant, the style detail page with its BOM, Cost, and other artifact tabs, and the controls for opening a new version and switching the current one.
- Inside an order — the order’s view of each style it runs, showing which version of the BOM and cost sheet the order is pinned to, and the order-side details (colors, sizes, quantities) for that order’s run.
- Across downstream work — purchasing, the readiness engine, and production all resolve the per-order version through the style, so each consumer reads the right version for the order it is acting on.