Why a Farmer’s Price Is Never Recalculated: Price Snapshotting and FIFO in Depot Software

Every depot operator knows the conversation. A farmer comes back weeks after delivery and questions the per-kilo price. The operator remembers a different number. Nobody has a locked record of what was quoted on that day, so the argument is settled by whoever is more stubborn.

That looks like a people problem. It is a data-model problem. simpliDepot is built so that the argument has nothing to stand on.

The core rule: the price at intake is copied, not referenced

simpliDepot keeps a price catalog by variety and grade, with effective dates. When a lot is weighed and graded at intake, the price in force that day is copied onto the lot and stays there permanently. It is never recalculated.

The obvious alternative is to store a reference to the price table row and look the price up whenever you need it. That works until the price table changes: a row is edited, a new effective date is added, and suddenly every historical lot points at a different number. The payout record changes without anyone touching the lot.

A snapshot avoids that. The lot carries the price that applied when the fruit was weighed, whatever the price table says now.

flowchart TD
    A["Farmer delivers fruit"] --> B["Weigher records weight per grade"]
    B --> C["Price lookup for the intake date"]
    C -->|"no price set"| X["Intake blocked"]
    C --> D["Price per kilo copied onto the lot"]
    D --> E["Lot in stock"]
    E --> F["Sales order draws oldest lot first"]
    F --> G["Buyer invoice and farmer payout"]

A related guard: if no price has been set for that variety and grade, intake is blocked outright. A missing price cannot quietly turn into a zero or a guess that someone sorts out later.

Exact money, not floating point

Prices and payouts are computed with exact decimal arithmetic, not floating point, and the rounding rules are applied consistently at snapshot time. This is unglamorous, but it is what lets a farmer’s payout and a buyer’s invoice agree to the last satang across thousands of lots. Floating-point drift is exactly the kind of small error that turns into a monthly reconciliation fire drill.

Numbers that never collide

Harvest season means several weighing stations and several cashiers working at once. Two properties matter:

• Lot numbers are sequential and stay safe when several stations submit at the same time.
• Invoice numbers are gap-free and sequential even when several cashiers are billing at once.

Hand-typed invoice numbers get duplicated or skipped. Numbers issued by the system under concurrency control do not.

FIFO allocation: oldest lot first, and honest about shortfalls

When a buyer places a sales order, simpliDepot allocates stock oldest-lot-first, automatically. Two details matter more than they sound:

• Partial allocation is tracked line by line, not silently dropped. If a line can’t be fully filled, you see that on the order.
• Lot status moves on its own from graded, to partially sold, to sold out as stock sells down.

Every sales order line keeps a full FIFO allocation trail. That is what lets you answer the traceability question after the fact: which farmer’s lot ended up on which buyer’s truck.

Inventory and reports can’t drift

Stock-on-hand and reporting are live read-only views over the same intake, sales, and billing records. There is no separate inventory ledger to reconcile against, so there is nothing to fall out of sync. Each stage owns its own data and hands off to the next, and the views just read.

What it doesn’t do on its own: offline intake

An honest limit, because it affects site planning. simpliDepot is a hosted web platform, so recording intake and sales needs connectivity. For sites with unreliable internet, a local network setup or offline buffering is something we scope during discovery. It is not a built-in feature to assume. If your weighing station is far from good coverage, raise it in the first call.

Not only durian

simpliDepot was built first for durian, but varieties, grades, and prices are configuration, not hardcoded logic. The same lot, grade, and FIFO model fits other graded commodities sold by weight, such as mango, rubber, and palm fruit, with the catalog set up for your own tiers.

Two earlier posts follow that thread. From Durian Depot to Recycle Depot maps the same pipeline onto a material recovery business, including where it would need extending. EUDR Is Coming for Thai Rubber and Palm Oil is candid about what the platform does not do today, such as capturing plot geolocation at intake.

Related reading

• The Modern Durian Depot: Stop Counting Stock on Paper, Start Running a Real Business
• Idempotency in Payment APIs: Preventing Double Charges with Stripe, Omise & 2C2P: the same discipline that keeps a payout from being recorded twice.
• FarmScript: Designing a Programming Language for Chanthaburi Durian Farmers

FAQ

How do you actually prevent price disputes?
The price in effect on the intake date is locked onto the lot when it is graded and is never recalculated, even if the price table changes later. That snapshot is the record for any payout question.

What happens if nobody has set a price yet?
Intake is blocked until a price exists for that variety and grade.

Can several weighing stations and cashiers work at the same time?
Yes. Lot numbers and invoice numbers are generated so they don’t collide, even when submissions arrive together.

Does it connect to accounting software?
As an add-on on the Professional and Platform tiers, scoped during onboarding to whatever export or API your accounting system needs.

Try the real thing

The full stack is running with sample farmers, buyers, and lots, and you can log in with any of the demo roles (weigher, cashier, manager, admin) and walk the intake-to-invoice flow yourself: simpliDepot live demo. The product page, with tiers and the deployment process, is at simpliDepot.

To talk through your own depot, tell us your commodity, depot count, and timeline at hello@simplico.net and we will send a scoped proposal within 48 hours.