Buy by the Box, Sell by the Piece: Multi-Unit and Assemblies

Level Intermediate Role Owner, Admin Module Inventory, Products About 12 minutes
Updated

You buy oil by the box of twelve. You sell it by the bottle. And every time a delivery arrives, somebody in your shop opens a calculator.

That looks trivial until you count how often it happens. Twelve times a month, across twelve product lines, with the typing mistake that is always possible. Then one day system stock is fifty units adrift from the shelf, and nobody knows since when.

The answer is not a bigger calculator. One item may carry several units at once — and each unit brings three things of its own: how many base units it contains, what it sells for, and its item code.

So you record “bought 2 boxes”, and the system knows that means 24 bottles. You sell “1 bottle”, and stock drops by one. Nobody types a conversion again.

What usually surprises people is the per-unit selling price. A box price is not the bottle price times twelve — it is usually lower, because that is how wholesale works. Each unit stores its own price, so your trade discount stops being a manual sum that can go wrong.

Then there is one more thing that often gets confused with this, and this tutorial settles both at once: assembled products. Not the same goods in different packaging, but a new product built from several others — a scheduled-service bundle holding oil, a filter and a spark plug.

The distinction matters, because the two solve completely different problems.

Before you start

  • The parent product is registered along with its base unit.
  • Settle on the right base unit first — changing it after transactions exist is far more trouble.

Steps

  1. Set the base unit as the smallest thing you have ever sold

    This is the most important decision in the whole tutorial. If you have ever sold a single piece, the base unit is the piece — not the box. Every stock calculation rests on the base unit, so choosing one that is too large makes retail sales impossible to record cleanly.

    Product quantity unit list underpinning multi-unit conversion
    The base unit is the smallest unit you have ever sold.
  2. Switch on Multi Satuan, then enter the conversion figures

    The switch is in the Pengaturan section of the product form, in the same row as Punya Stok and Bergaransi. Once on, each additional unit carries how many base units it contains. A box holds 24 pieces, a dozen holds 12. That figure is what lets the system know buying two boxes means stock rises by 48 — you never calculate it yourself.

    Multi-unit switch on the product form with its conversion fields
    Turn on multi-unit, then fill in the conversion figure.
  3. Give each unit its own selling price

    This is the part people most often assume is impossible. A box price is not simply the piece price times 24 — it is usually lower, because that is how wholesale works. Each unit stores its own selling price, so your trade discount stops being a manual sum on every transaction.

    Selling price field on the product form for each unit
    Each unit may carry its own selling price.
  4. Give each unit its own item code where that helps

    Each unit can carry its own code. Useful when your supplier uses a different code for the bulk packaging, or when the barcode on the box differs from the barcode on the piece.

  5. Test with one real purchase and one real sale

    Buy a box, then sell a single piece. Open the stock card. If the conversion is right, stock rises by 24 then falls by 1. If it shows a rise of 1 then a fall of 1, the conversion figure was never filled in — and all your stock will be wrong from that day onward.

  6. Now the Rakitan switch — a different problem entirely

    In the same row as Multi Satuan sits one called Rakitan (assembly). Multi Satuan is the same goods in different packaging; Rakitan is a new product built from several others. A scheduled-service bundle holding oil, a filter and a spark plug is Rakitan — not Multi Satuan. Two neighbouring switches, two completely unrelated problems.

    Assembly switch on the product form for building a bundle
    Assemblies solve a different problem from multi-unit.
  7. List the components and how many of each

    An assembled product stores a list of components and the quantity of each. An oil-change bundle holds 4 litres of oil, 1 oil filter and 1 washer. Those quantities are what get used when the bundle sells.

    Spare-part flag on the product form while listing bundle components
    List each component along with how many go in.
  8. Learn its limit now, not after your stock goes wrong

    This part has to be honest. Rakitan RECORDS what a bundle is made of, but selling the bundle does NOT automatically deduct each component from stock. So the bundle still needs stock of its own, and you still record material usage as you normally would. If what you expected was oil stock dropping by itself the moment an oil-change bundle sells, that expectation needs correcting now.

  9. The practical consequence: bundles need stocking themselves

    Because bundle stock stands alone, its availability is counted from that bundle stock — not from how many components you hold. Having 50 litres of oil and 25 filters does not make an oil-change bundle automatically available. The bundle has to be stocked through a purchase or a stock count, exactly like an ordinary product. This surprises people more than anything else here, so decide now whether you are ready to manage one extra stock line.

    Stock movement showing a bundle needs its own stock line
    The consequence: the bundle needs stocking on its own.
  10. So what is it for? Consistency and evidence

    Two things. First, the bundle composition is recorded officially — so "scheduled service package" means the same thing at every branch and every till, rather than depending on who is serving. Second, that composition is captured in the change log, so if the contents get altered quietly one day, there is a trail. For a shop with more than one person on the till, that is not a small thing.

  11. Do not overdo it: bundle only what genuinely sells together

    A shop that builds twenty bundles ends up using none, because finding the bundle takes longer than picking the items. Start with the three combinations that most often sell together — and keep the stock consequence from the previous step in mind.

What you end up with

Goods bought in bulk and sold loose are recorded with automatic conversion and their own per-unit prices — and bundle compositions are recorded officially so their contents mean the same at every till, with the stock limitation understood from the start.

If something goes wrong

I bought a box but stock only went up by one

The conversion figure for that unit is missing or set to 1. Fix the conversion, then correct the stock through a count — fixing a conversion does not recalculate transactions already recorded.

The box price changes when I change the piece price

Check whether a price has actually been entered for the box unit. A unit left without its own price will follow the calculation from the base unit.

I chose the wrong base unit and everything is now a mess

Do not change the base unit on a product that already has transaction history. It is safer to create a new product with the correct base unit, archive the old one, then move the remaining stock across through a count.

A bundle sold but its component stock did not go down

That is correct behaviour, not a fault. Rakitan records what a bundle contains; it does not deduct component stock on sale. Record material usage as you normally would — through a repair for workshop jobs, or by selling the components themselves.

I want component stock to drop automatically when a bundle sells

Not possible yet. For now the honest approach is to sell the components as separate lines on one receipt — stock stays correct and the customer still pays one total. Bundles exist to standardise what is included, not to move stock.