Product Breakdown
Breaks one product down into several other products: a large sack into branded retail packs, a gift basket taken apart again, or a set sold piece by piece. The parent leaves stock, the results enter stock, and the parent value is split across the results - by selling price by default.
When To Use This Form
- Breaking one item into several different products, each with its own code, barcode, and selling price - a sack of rice into 1 kg, 2 kg, and 5 kg packs sold as products of their own.
- Taking apart a gift basket or bundle that did not sell, back into the items inside it.
- Splitting a set into parts that are sold separately.
- A breakdown may produce more than one kind of result, and each kind carries its own share of the value.
When This Form Is NOT Needed
The case that most often reaches for this form by mistake:
- Buy by the sack, sell by the kilo under the same product code. Multi-unit handling in the Product master already covers it - the unit content (1 sack = 25 kg) takes care of stock, with no document at all.
- A breakdown is only needed when the results are other products: their own code/barcode, selling price, and cost.
- One question decides it: is the result a new product code in the Product master, or merely another unit of the same product?
Using this form for a multi-unit case splits the stock of one item across two product codes, and inventory reports will never merge them again.
How To Fill It
- Fill Division, Department, date, and time. The document number fills itself.
- Fill Product to Break Down, its unit, and the Quantity being broken down.
- In the Breakdown Results table, add each resulting product with its unit and quantity.
- Leave the Purchase Price of the results at 0 to have the value split automatically - this is the recommended way.
- Type a Purchase Price only on rows whose value you have decided yourself; the rows still at 0 receive the remainder.
- Save. The server fills the Purchase Price and Subtotal of every row and writes them back to the document.
The save button rejects a document whose total result quantity is 0.
How The Value Is Split
The value being split is the parent’s moving-average COGS at the document date and time, times the quantity broken down. The results always sum to exactly that value.
- Selling price proportional by default. Each row’s weight = the level 1 selling price of the chosen unit x that row’s quantity. A pack that is dearer per kilo absorbs more value - this is the usual joint-cost method, and closer to reality than splitting evenly per kilo.
- When no result has a selling price yet, the split falls back to base quantity (unit content x quantity) instead of silently producing zeros.
- Purchase Price 0 means "calculate it for me". A row holding a number is a human decision and is left alone; the remaining parent value is split across the rows still at 0.
- When every row was typed by hand and the total is exactly the parent value, nothing is changed at all - a fully hand-made split is honoured, including every time a finished document is re-saved.
- When every row was typed by hand but the total misses, or the hand-typed rows alone already exceed the parent value, every row is reallocated. An unbalanced journal does far more damage than one overwritten number.
- The rounding remainder goes to the row with the largest weight, so the total is exact - not a stray cent left hanging.
Roles without the Show Purchase Price History permission never see the Purchase Price column, so for them the value is always split automatically.
Fields To Watch
| Field | What to watch |
|---|---|
| Division, Department | Branch and warehouse where the stock moves. Both sides of the transaction always sit in the same division and department - this form never moves goods between warehouses. A role locked to one division/department cannot change them. |
| Invoice | Document number, filled automatically per division when numbering is on. It uses the same numbering source as the other inventory forms. |
| Date, Time | Transaction time. This time decides which COGS is used and the moving-average order after it; the time fills itself when the document is created. |
| Serial Number, Expiration Date | Shown only when the company uses serial numbers. |
| Notes | Copied to this document’s stock-book rows and journal rows, trimmed to 100 characters. |
| Product to Break Down, Name | The parent product leaving stock. The name fills automatically. |
| Unit, Quantity | Unit and quantity of the parent being broken down. Stock is recorded in the base unit. |
| Purchase Price (parent) | Usually needs no entry: the value comes from the parent’s moving-average COGS. A number typed here is only used when the parent product has never had a COGS at all. After saving, the server writes back the COGS actually used. |
| Breakdown Results | The result detail table. Each row: product, unit, quantity, Purchase Price per unit, and Subtotal. |
| Purchase Price (result) | 0 = calculate it for me. A typed number is kept as far as possible - see "How The Value Is Split". |
| Subtotal | Quantity x Purchase Price, computed by the server. |
| Approval Status | Pending Approval / Approved / Rejected - only meaningful when the approval workflow covers this document. |
What Happens After Saving
- Stock of the parent decreases and stock of each result increases in that department, at the document date and time, in base units.
- A new COGS record is created for each result product, from the value allocated to its row divided by that row’s quantity, averaged against the stock already on hand.
- Automatic journal: credit the parent’s inventory account, debit each result’s inventory account, summed per account. One shared inventory account across all products means no journal rows - and that is correct.
- The value of this transaction is always neutral: no profit, loss, or cost is created by moving value between products. Assembly labour, packaging cost, and shrinkage are deliberately out of scope - they add value from outside inventory and need an offset account of their own.
- Every re-save deletes and rewrites this document’s journal, stock book, and COGS records.
- Editing or backdating an old document recalculates the COGS chain after that date automatically, so the moving average of later transactions stays correct. That means saving an old document can change the profit shown by later sales reports - that is the correction, not a defect.
- When the approval workflow is on for this document, stock, COGS, and journals only change after it is approved. Before approval the document is saved but has touched nothing. Revoking the approval pulls all three back out.
Common Problems
- The Purchase Price I typed was overwritten. That happens when the rows do not sum to the parent value, or the typed rows alone already exceed it. Leave some rows at 0 so the remainder has somewhere to land.
- The split feels unfair between pack sizes. It is selling-price proportional by default, not per kilo. A mistyped selling price in the unit master makes the split wrong too.
- All results come out at 0. The parent has no COGS yet: no purchase, Incoming Inventory, or opening balance. Give the parent a value first, or type the parent Purchase Price once for a product that has genuinely never had one.
- The split changed after I re-saved. The parent COGS on that date may have moved because another document was backdated. The total stays neutral.
- Parent stock goes negative. This form does not refuse a breakdown with insufficient parent stock - check Product Movement first.
- Deleting the document. Its stock, journal, and COGS records go with it, and the COGS chain of the affected products is recalculated.
Menu Location
- Products & Inventory / Stock Operations / Product Breakdown
/form/productdisassemble