Browse all topics
Make
Parts into finished goods.
See step 4 in the Overview →Product types and stock modes
Every product carries two independent settings. Its type — physical, assembled or service — decides whether it has a parts list and whether it holds stock at all. Its stock mode — ready stock, on demand or hybrid — decides what happens once stock reaches zero. Neither setting implies the other, and neither is the display category your storefront shows shoppers.
The three numbers of a built product
A built product has three stock figures, not one. On hand is the finished units sitting on a shelf. Assemblable is how many more its components could produce right now. Available is on hand plus assemblable, minus whatever is already promised to orders. Assemblable is worked out separately at each location, because parts in two buildings cannot become one finished unit.
Build a bill of materials
A bill of materials is the parts list for one built product. Open the product, add each component with the quantity needed per finished unit, and save — the list saves as one piece, not row by row. Components must already exist as products. Saving moves no stock; it tells Mossery how many units you could build from what is on the shelf right now.
Record production output
Recording output books a finished batch in against its production run. Open the run, enter the date and how many units arrived in this delivery, then confirm the material that batch consumed. Finished units go on stock, and the inputs come off where they physically sit — at the partner for an outsourced run. Partial deliveries are normal; record each one as it lands.
Run an assembly order
An assembly order turns components into finished units at one location. A supervisor creates it and approves it; whoever is packing opens it on their phone, enters how many they finished in this session, and confirms. Components come off stock and finished units go on, both at that location. You can pack across several sessions until the order is complete.
Share one production recipe across many products
A production recipe lists the materials one finished unit uses. Products that are made the same way can share one recipe instead of each having its own copy. Write the recipe on one product, then use Assign to SKUs on the recipe page to point the others at it. Changing a shared recipe changes it for every product that uses it.
A kit will not build even though the app says it can
Buildable is counted per location, so the usual cause is components sitting somewhere else: the headline figure on a product list is org-wide and can pair a part in one warehouse with a part in another. Next most likely, the kit contains sub-kits nobody has built yet, or component stock is already allocated to orders. An unapproved order blocks it too.