One bill, and the number nobody typed

What this lesson is about

Every garment has a list of what goes into it. In this app that list is one table, and it does two jobs at once. It says what the garment is made of. It also prices it. The pricing works only if each line carries a quantity and a rate. This lesson is about where the quantity comes from when nobody types one. It is also about a mistake that is easy to make twice on the same line.

Simran opens the Bill of materials section of STY-204. Her order from Kilbraken Stores is for six thousand polos, and she has to quote it this week.

The basis for the arithmetic in this lesson. Every figure below is worked from the formula the application uses, with the inputs named, so you can redo it with a calculator. Money is US dollars. The style grades across a six-size scale: XS, S, M, L, XL and XXL.

One bill, three layers

There is one table behind the bill, and fabric and trims both live in it. What separates them is not where you typed them. It is a classifier that reads each line and decides which cost layer it feeds.

The three layers are fabric, decoration and trim. A line goes to decoration if its category says so, or if its own words say print, embroidery, wash, applique, badge, patch, heat transfer or sequin. It goes to fabric if its category is shell or lining, or if the line reads as a fabric by its text, its weight or its width. It goes to trim only on an explicit signal: a trims or packaging category, or a component name the app recognises as a trim.

Then the rule that surprises people. Anything left over defaults to fabric. The reasoning is in the source. A bill line with no trim signal at all is far more likely to be a fabric or a component than a trim. It is a sensible default, and it is still a default, so a badly named uncategorised line lands in the wrong layer quietly.

The cure is not to argue with the classifier. It is to set the Category on the line.

What a line costs

A line's cost is not stored. It is computed, every time, from three fields:

line cost = consumption × (1 + wastage % ÷ 100) × unit cost

Two properties of that expression matter more than the expression itself.

The first is that it returns nothing rather than zero when either the consumption or the unit cost is missing. The roll-up then counts that line as uncosted and reports the count. An unpriced line is never quietly added in as free.

The second is that the roll-up refuses to add across currencies. It groups the costed lines by currency. A single total, and a comparison against the style's target cost, only appear when the whole bill is in one currency and that currency is the target's. Put one trim in rupees because that is how the supplier quoted it, and the bill stops producing a single number until somebody resolves it.

Five costed lines, one uncosted, and a trims subtotal of 0.3505 a garment. The rib is not zero. It is missing, and the bill says so.

The number nobody typed

The body fabric line is the interesting one, because its consumption is usually the last thing anybody knows. Simran has a graded measurement spec and a fabric weight. She does not yet have a marker, which is the cutting plan that lays every pattern piece onto the fabric.

The app offers a button on the line: Calculate from measurements. Its own one-line description says it estimates consumption from the graded measurement points and the material's weight or width, and calls it a costing-stage estimate that a marker refines later. It is deterministic arithmetic, not a prediction.

Here is the whole chain, in order.

First an area, per size, in square centimetres:

area = (body length + sleeve length + length allowance) × (chest flat + width allowance) × 2

The allowances default to eight centimetres on the length and two on the width. The final doubling is the front and back panels. Then the method branches on the fabric's construction:

• Knit gives kilograms: area × grams per square metre ÷ 10,000,000
• Woven gives metres: area ÷ (cuttable width in centimetres × 100)

Then three scalars, in this order: divide by the marker efficiency, multiply by one plus the wastage, multiply by one plus the shrinkage. The marker efficiency is the share of the cut sheet the pattern pieces actually occupy, so dividing by it adds back the waste nesting leaves between the pieces. The application's built-in values are 82% for knits and 80% for wovens.

Working it through

STY-204's body fabric is a single jersey at 190 grams per square metre. Take size M, whose measurement spec is a body length of 71, a sleeve length of 22 and a chest flat of 52.

• Length: 71 + 22 + 8 = 101
• Width: 52 + 2 = 54
• Area: 101 × 54 × 2 = 10,908 square centimetres
• Raw kilograms: 10,908 × 190 ÷ 10,000,000 = 0.207252
• After the marker: 0.207252 ÷ 0.82 = 0.252746
• After 10% wastage: 0.2780 kilograms a garment

The app does that for every size that has a spec value, then averages.

The average of those six is 0.2938 kilograms a garment. At a fabric price of 7.50 a kilogram, the fabric line costs 2.2035 a garment, and with the trims subtotal the bill stands at 2.5540.

Two wastages, one line

Now the mistake. The estimate you just saw already has wastage inside it. The value written to the line is the figure after wastage.

The line also has its own Wastage % field, and the line-cost formula multiplies by it. Its default is zero, so nothing goes wrong on its own. It goes wrong when somebody applies the estimate and then types the factory's usual cutting allowance into the wastage box, because that is what you do on a line you priced by hand.

The arithmetic of the mistake, on STY-204:

• Correct: 0.2938 × 7.50 = 2.2035 a garment
• With 10% typed into the line's wastage box as well: 0.2938 × 1.10 × 7.50 = 2.42385
• Difference: 0.22035 a garment, or 1,322.10 across six thousand

Nothing warns you. The evidence is there if you look for it. Applying an estimate writes a line to the style's activity log that names the formula, and the formula text names the wastage it used. But the two fields sit on the same line and neither mentions the other.

A working rule: if the consumption came from the calculator, the line's wastage stays at zero. If you typed the consumption from a marker or a cut plan, the wastage box is where the cutting allowance belongs.

Two defaults for the same percentage

There is a second, smaller version of the same trap. It is worth knowing because it explains a discrepancy people report as a bug.

The wastage box on the calculation panel opens filled in with 10. The application's own construction-aware defaults, used when nothing overrides them, are different: 6% for knits, 12% for wovens and 8% for a seamless garment. Those defaults sit under a per-category consumption standard and under a factory-wide fabric-wastage setting, both of which override them, and the reviewer's box overrides everything.

So the same line, estimated two ways, gives two numbers.

Neither number is wrong. They answer slightly different questions. The honest move is to decide once what your factory's cutting wastage on knits actually is, set it in the factory settings, and stop retyping it.

The average is a plain average

One more property of that average, because it changes what the number means.

The engine can weight the per-size values by an order's size breakdown. Nothing in the application supplies one from the style side today, so what you see on the style is the plain average across every size that has a spec value. Every size counts once, whatever you will actually cut.

With a bell-shaped size curve this barely matters. Give STY-204 a curve of 240, 900, 1,860, 1,680, 960 and 360, and the weighted average is 0.293 against the plain 0.2938. That is a difference you can ignore.

It matters when the curve is not centred. Suppose Kilbraken buys only S to XL: 1,200, 2,400, 1,800 and 600. The plain average is still 0.2938, because XS and XXL still count. The weighted answer is 0.2866. On six thousand garments that is 43.2 kilograms and 324.00, quoted against sizes nobody ordered.

Audit a MerchandiserOS bill of materials with me, line by line, looking for the errors that do not stop anything.

For each line I will give you: the component name, the material text, the category if one is set, the consumption and its unit, the wastage percentage on the line, the unit cost and its currency, and the GSM or cuttable width if the line carries one.

Work through four questions in this order.

First, classification. For each line, say which cost layer it will feed — fabric, decoration or trim — and say WHY, from its category and its own words. Flag every line whose layer is being decided by the fallback rather than by an explicit signal, because those are the ones that will surprise somebody.

Second, the double wastage. For any line whose consumption came from the measurement calculator, the wastage is already inside that number, and a percentage typed into the line's own wastage box applies it a second time. Ask me where each consumption came from before you judge it. Where a line has both an estimated consumption and a non-zero wastage, work out the cost with and without, and give me the difference per garment and across my order quantity.

Third, the honest gaps. List every line with no unit cost and every line with no consumption, and say plainly that these are absent rather than zero. If more than one currency appears, say that the bill will produce no single total until that is resolved.

Fourth, what is not on the bill at all. Given the garment, name the components you would expect and cannot see.

Two rules. Never invent a price or a consumption to fill a gap. And when you are unsure whether a line is a fabric or a trim, say so and tell me which field would settle it.