Product Assembly
Combines several products into one other product: gift baskets, hampers, bundles, or sets that have their own barcode and price. The components leave stock, the assembled product enters stock, and the cost of the result is computed from the value of its components.
When To Use This Form
- Building gift baskets or hampers from finished goods that are also sold separately.
- Creating a bundle recorded as its own product because it has its own barcode, selling price, and stock.
- Joining components into one set sold as a whole - a tool set, a uniform set, a mixed-content carton.
- Not a replacement for the Production module: there is no BOM, work center, operation, or status stage here. If the assembly repeats with a fixed recipe, labour cost, and stages, use Production Orders.
When This Form Is NOT Needed
One case is misunderstood most often, and using this form for it is what wrecks stock:
- Buy in large units, sell in small units - buy by the sack, sell by the kilo; buy by the carton, sell by the piece. As long as it is the same product code, multi-unit handling in the Product master already covers it: the unit content (1 carton = 12 pieces) is what moves stock, and no document needs to be created at all.
- Assembly is only needed when the result is a different product - its own code/barcode, selling price, and cost.
- When in doubt, check the Product master. Does the result exist as its own product code? Use this form. Is the result merely another unit of the same product? Do not use this form.
Using this form for a multi-unit case records the stock of one item under two product codes at once, and no report can merge them again without voiding the document.
How To Fill It
- Fill Division, Department, date, and time. The document number fills itself.
- Fill Assembled Product: the product produced. The list only holds active non-service products that have a base unit, limited to the product groups your role may access.
- Fill the Unit and Quantity of the result - how many baskets were made.
- In the Assembly Components table, add each component with the unit and quantity consumed for the whole result above (not per single result).
- Save. The Purchase Price of the result fills itself after saving.
The save button rejects a document whose total component quantity is 0 - a basket cannot exist without contents.
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. |
| Assembled Product, Name | The product produced. The name fills automatically and cannot be typed. |
| Unit, Quantity | Unit and quantity of the result. Stock is recorded in the base unit (unit content x quantity). |
| Purchase Price (result) | Cannot be typed. The server fills it after saving: the total value of all components divided by the result quantity. The only way to change it is to change the components. |
| Assembly Components | The component detail table. Each row: product, unit, quantity, Purchase Price per unit, and Subtotal. |
| Purchase Price (component) | Cannot be typed. While you pick the product and unit it shows the latest COGS from the stock book as a preview; after saving the server overwrites it with the moving-average COGS at this document’s date and time. |
| Subtotal | Quantity x Purchase Price, computed by the server. |
| Approval Status | Pending Approval / Approved / Rejected - only meaningful when the approval workflow covers this document. |
The Purchase Price column only appears for roles with the Show Purchase Price History permission. Roles without it can still save the document - the server computes the values as usual.
What Happens After Saving
- Stock of each component decreases and stock of the assembled product increases in that department, at the document date and time, in base units.
- A new COGS record is created for the assembled product: its total value divided by the result quantity, then averaged against the stock already on hand.
- Automatic journal: credit the inventory account of each component, debit the inventory account of the result, summed per account. When every product uses the same inventory account - the most common case - no journal row at all is created, 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. A document with no components, no result product, or zero quantity may still be saved but posts nothing.
- 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 result has zero Purchase Price. The components never had a COGS - no purchase, Incoming Inventory, or opening balance has given them one. Give the components a value first, then re-save the assembly.
- Component value differs from yesterday’s purchase price. What is used is the moving-average COGS at the document date and time, not the latest invoice price.
- Component stock goes negative. This form does not refuse components with insufficient stock. Check Product Movement for that warehouse before assembling in bulk.
- No journal is created. Usually correct: the components and the result share one inventory account. Check the inventory account on each product group if they really must differ.
- The result product is missing from the list. Service products, inactive products, products without a base unit, and products outside the product groups your role may access do not appear.
- 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 Assembly
/form/productassemble