A Bag Is Not a Kilo: Why Stock Is Counted in Whole Numbers
There is no unit of measure on an item, and stock is stored as a whole number. You cannot hold 12.5 kilos or issue half a litre. That is a real constraint with a clean answer — define the item as the smallest unit you ever transact — and a set of consequences worth understanding before you name your first hundred items.
A trader weighs out 12.5 kilograms of seed. A storekeeper issues 40 litres from a 200-litre drum. A miller receives 43 bags of maize that weigh 3,847 kilos in total. All three are ordinary agricultural transactions, and all three run into the same wall: an item in this system has no unit of measure, and its stock is a whole number.
There is a good answer to this, it takes ten minutes to understand, and it has to be decided before you build your item list rather than after — because renaming three hundred items and restating their history is not a ten-minute job.
What is actually stored
The precise position, since half-measures in describing it are what cause the trouble. An item carries a name, a category, a description, a barcode, a buying price, a selling price, a weighted average cost and a whole-number stock figure. There is no unit field. There is no purchase unit, no stock unit, no conversion factor and no pack size.
The quantity at each location is a whole number too, and the movement paths agree with each other: transfers, check-ins and check-outs all validate and cast quantities as integers, with a minimum of one. This is consistent rather than accidental — there is no path that quietly accepts a decimal and then rounds it somewhere you cannot see.
What you say in the yard What the system stores
A bag of maize One unit of an item you named "Maize — 90kg bag"
The 90 kilos live in the item name and in your head. Nothing knows the bag weighs 90kg, so nothing can convert bags to kilos or price per kilo for you.
12.5 kg of seed 12 or 13 units of an item named "Certified seed — 1kg"
Half a unit cannot be stored. If you genuinely transact in half-kilos, the unit has to be the half-kilo — or 500g, named as such.
A 200-litre drum Either 1 unit of "Herbicide — 200L drum" or 200 units of "Herbicide — 1L"
This is the whole decision. The first is easy to receive and impossible to issue in part; the second is easy to issue and makes your purchase order read 200.
3,847 kg across 43 bags 3,847 units of a 1kg item, or 43 units of a bag item
Only one of those two figures can be your stock. The other is a number on a weighbridge ticket that the system will never hold.
Half a bale of twine Not storable
If a half is a real transaction, the bale is not your unit. There is no partial-unit concept to fall back on.
The pattern in every row: the unit is carried by the item's name, which means it is carried by your naming discipline and nothing else. A system that has no unit field also has no way to catch a mistake in one.
The rule that resolves it
Define the item as the smallest unit you ever transact in, and put the unit in the name. Not the unit you buy in, not the unit you count in at stock-take — the smallest one that ever appears on an issue, a sale or a transfer.
If you ever issue a single litre, the item is a litre. If you always move whole drums and never decant, the item is a drum. If you sell fertiliser both by the 50kg bag and by the kilo, the item is a kilo and a bag is fifty of them. The cost of choosing the larger unit is that the smaller transaction becomes impossible; the cost of choosing the smaller one is bigger numbers on documents. Bigger numbers are a nuisance. Impossible transactions are a reason people stop using the system.
Choose the smallest unit you ever transact in. Large numbers on a document are an irritation; a transaction the system cannot represent is how a store goes back to a paper book.
| Commodity | Sensible item unit | Why |
|---|---|---|
| Fertiliser sold by bag and by kilo | Kilogram | The kilo sale exists, so the kilo has to be the unit. A bag is a quantity of 50 |
| Fertiliser only ever sold in sealed bags | Bag, weight in the name | Nothing is ever decanted, so the bag is the smallest real transaction |
| Herbicide decanted from drums | Litre | A part-drum issue is routine, and a drum cannot be split |
| Veterinary vaccine in vials | Vial or dose, stated | Whichever one your issue note says. Decide once and name it explicitly |
| Maize received on a weighbridge | Kilogram | The weighbridge produces kilos; forcing bags loses the precision you paid to measure |
| Twine, sacks, crates | Piece | Already whole units — no decision to make |
Deciding a unit, per item, in one pass
The commodity is weighed at intake or at sale
Use the kilogram
Anything weighed should be stored in the weight unit, because the whole reason you weighed it was to be precise. Bag counts are then a division you do for reporting, and the arithmetic runs the right way — kilos to bags rather than bags to an assumed weight.
The commodity is sealed and never opened
Use the pack, with the size in the name
"Urea — 50kg bag" is honest, readable on a purchase order and correct on a stock count. The stock figure is a bag count, which is what your storekeeper counts anyway.
You sell the same thing both ways
Use the smaller unit, always
One item in the smaller unit beats two items for the same commodity. Two items means two stock figures for one physical pile, and the day somebody decants a bag without transferring between them, both are wrong.
You genuinely need fractions — 12.5 kg, 0.5 L
Shrink the unit until the fraction disappears
Half-kilos become 500g units; half-litres become 500ml units. The numbers get bigger and everything else works, including cost per unit and reorder points. This is the escape hatch for every fractional case.
You need both a weight and a count on the same record
Accept that only one of them is stock
Stock is one number. A weighbridge ticket, a bag count or a moisture reading that also matters belongs in a custom field, a document attachment or the batch record — captured, but not the stock figure.
What the choice costs you downstream
Two consequences are worth pricing before you commit, because both are invisible until you meet them.
The first is cost per unit. Weighted average cost is held per item, so if the item is a 50kg bag, the cost is per bag and every per-kilo figure you quote is a division you do yourself. That is fine for a store that thinks in bags and unhelpful for one that prices per kilo.
The second is freight. Landed cost — freight, duty, clearing, transport — can be spread across the lines of a purchase order by value or by quantity, and nothing else. There is no weight basis and no volume basis. On a mixed container that is exactly backwards for agriculture: a tonne of fertiliser and a carton of seed dressing arrive on the same truck, and quantity-based allocation charges the carton the same freight as a bag while value-based allocation charges the expensive seed dressing most of a fertiliser truck's haulage.
The workaround for freight, and its price
If your items are already defined in kilograms, then allocating landed cost by quantity is allocating by weight — the two coincide. That is a genuine argument for the kilogram as your unit, and it is the strongest one in this article. For containers mixing weight units with piece units, allocate by value and accept the distortion, or split the shipment across two purchase orders and allocate each on its own basis.
Scoring your own item list
Every item name states its unit
Make them prove it: Read ten item names at random. Can a new storekeeper say what one unit is, without asking?
One commodity, one item
Make them prove it: Search for your top five commodities. Is each one a single item, or several in different units?
No fractional transaction is required
Make them prove it: Ask the storekeeper for the last five part-issues they made. Could each be expressed in whole units?
Weighed goods are stored in weight units
Make them prove it: Is anything that crosses a scale stored as bags?
The unit works for landed cost
Make them prove it: Would quantity-based freight allocation be roughly fair across your typical container?
Prices are quoted in the stored unit
Make them prove it: Does your price list use the same unit as the item?
Where the extra numbers should live
Choosing one unit does not mean throwing the others away. A weighbridge ticket number, a moisture percentage, a bag count, a grade — all of them can be captured, just not as the stock figure. Custom fields on items and on the movement documents hold them, the batch record holds a batch number and an expiry date, and attachments hold the ticket itself as a scan.
That distinction is the practical resolution of this whole article: stock is one whole number in one unit, and everything else about the consignment is recorded beside it rather than inside it. A store that understands that gets clean stock figures and keeps its measurements. A store that fights it ends up with two items for one pile of maize.
What we do and do not do
What AWRA OpsHub does today
- Whole-number stock, consistently. Every movement path validates and stores integers, so no route quietly rounds a decimal behind your back.
- Batch and lot records with batch number, expiry date, supplier and purchase-order reference, plus per-batch cost.
- Custom fields on items and movement documents, for weighbridge tickets, moisture readings, bag counts and grades.
- Weighted average cost per item, rolled forward through landed cost, in whatever unit you chose.
- Landed cost allocation across purchase-order lines by value or by quantity.
What it does not do
- No unit of measure on an item. No unit field, no purchase-versus-stock unit, no conversion factor, no pack size. The unit lives in the name.
- No fractional quantities. 12.5 cannot be stored; the unit has to shrink until the fraction disappears.
- No unit conversion, so bags-to-kilos and litres-to-drums are arithmetic you do outside the system every time.
- No weight or volume basis for landed cost, which is the allocation basis a mixed agricultural container actually needs.
- No dual unit of measure — one item cannot be stocked in kilos and sold in bags.
- No catch-weight handling, so items whose individual weight varies (a carcass, a bunch, a crate of tomatoes) are counted rather than weighed.
The absent unit field is the root of every line on the right, and the naming convention is the whole mitigation. That is a real limitation, stated plainly — and it is entirely survivable if the decision is made once, deliberately, before the item list exists.
Our take
Define every item as the smallest unit you ever transact in, put that unit in the name, and prefer the kilogram for anything that crosses a scale — it keeps your measurement precision and makes quantity-based freight allocation approximately correct at the same time. Put weighbridge tickets, moisture and bag counts in custom fields beside the stock figure rather than trying to make the stock figure carry them. Decide this before your first import, because the names are the only unit system you have.
See the item master and batch records
Items with barcodes, batches with expiry and supplier references, custom fields for the measurements that matter, and weighted average cost carried through landed cost.
Explore inventory managementFrequently asked questions
Can we store 12.5 kilograms of something?
No. Stock is a whole number on the item and a whole number at each location, and every movement path validates quantities as integers with a minimum of one. The fix is to shrink the unit until the fraction disappears: if half-kilos are a real transaction, the item is a 500g unit, and 12.5 kilos becomes 25 of them. Nothing rounds a decimal silently anywhere, which is the one good thing about the constraint — it fails at entry rather than in a report.
How do we handle bags when we buy in kilos?
Pick one and put it in the item name. There is no unit of measure field and no conversion factor, so nothing can hold that a bag is 50 kilos. If anything is ever sold or issued by the kilo, make the kilo the unit and treat a bag as a quantity of 50 on the document. If bags are always sealed and never decanted, make the bag the unit and state the weight in the name — "Urea — 50kg bag".
Should a weighbridge commodity be stored in kilos or bags?
Kilos. You weighed it precisely, and storing bag counts throws that precision away in exchange for an assumed weight per bag that will not hold. Storing kilos also makes quantity-based landed-cost allocation behave like weight-based allocation, which is the basis a mixed agricultural shipment actually needs and the only one available.
Can we allocate freight by weight?
No. Landed cost spreads across purchase-order lines by value or by quantity only. On a mixed container that misprices exactly the case where freight matters most — a tonne of fertiliser and a carton of seed dressing on the same truck. Two workarounds: define weighed items in kilograms so quantity allocation coincides with weight, or split a genuinely mixed shipment across two purchase orders and allocate each on the basis that suits it.
Where do we record the weighbridge ticket and moisture reading?
In custom fields on the item or the movement document, in the batch record, or as an attachment of the ticket itself. Stock is one whole number in one unit; everything else about the consignment is recorded beside it rather than inside it. That is the practical resolution — you keep the measurements without trying to make the stock figure carry two meanings at once.
What if the same commodity really is sold both by bag and by kilo?
One item, in kilos. The alternative — two items for one physical pile — breaks the first time somebody decants a bag without recording a transfer between them, and then both stock figures are wrong and neither is obviously the wrong one. A single item in the smaller unit means a bag sale is a quantity of 50, which is only an inconvenience on the document.
Does this affect items with variable individual weight?
Yes, and there is no catch-weight support to fall back on. A carcass, a bunch of bananas or a crate of tomatoes whose weight varies per unit can be counted as pieces or stored as kilos, but not both, and nothing links a piece count to an actual weight. For those lines the honest approach is kilos as stock plus a piece count in a custom field, accepting that the piece count is descriptive rather than something reports can total against stock.
