Crates and deposits

Track returnable crates per customer — what went out, what came back empty, and the security deposit you hold against the difference.

5 min read · updated 28/05/2026

Opt-in Capability · off

Crates is switched offCrates

You can read the guide. An owner or manager flips this Capability on in settings — it then lights up across the app.

Overview

If you move milk, curd, or bottled goods, your stock rides in crates that are supposed to come back. Every customer holds some of your crates at any moment, and you hold a security deposit against them. Today that count lives in a register book — and every missing crate is a silent argument at settlement time. The Crates Capability turns the register into a live ledger: crate types with a deposit rate, a per-customer running balance, and a movement log of every issue, return, and correction.

Opt-in Capability · off

Crates is switched offCrates

You can read the guide. An owner or manager flips this Capability on in settings — it then lights up across the app.

This is an opt-in Capability — the Owner enables it per tenant. Installing the Dairy Pack force-enables it (crates are daily money for liquid-milk distribution), but beverages, gas, or bakery businesses can switch it on without any Pack.

Key concepts

Crate type — one kind of returnable asset (say, "Blue 20L crate") with the deposit you charge per crate, in rupees. Retire a type instead of deleting it — old movements keep their history, and empties can still come back.
Balance — per customer, per crate type: how many crates the customer holds right now, and how much deposit you hold against them. Two numbers, always current.
Movement — one line in the register: an issue (crates went out, deposit charged at the current rate), a return (empties came back, deposit refunded proportionally to what you actually hold), or an adjustment (a signed correction for breakage or a miscount — notes are mandatory).
Delivery prompt — when a shipment is delivered, Neev nudges you to record the crates that went out with it. It never records a movement on its own: the count at the door is a physical fact only your operator knows.

Common workflows

Set up your crate types

Create each returnable asset with its per-crate deposit. The rate applies to future issues only — deposits already held never move when you edit a rate.

Issue crates with a delivery

Record how many crates of which type went to which customer. The balance goes up and the deposit is charged at the type's current rate. If the issue answers a delivery prompt, the prompt closes with it.

Take empties back

Record returns as crates come back. You cannot return more than the customer holds — the over-return is rejected, not silently absorbed. Deposits refund pro-rata: return everything and the deposit zeroes out exactly.

Correct the count when reality disagrees

Broken crate? Miscount? Record an adjustment with a signed quantity and an explicit deposit movement, plus a note saying why. Adjustments are the audit trail of every dispute you settled.

Role notes

This Capability binds to Owner by default through the standard catalog expansion — capability.crates.read and capability.crates.write. Grant the read key to a Manager who watches balances, and the write key to whoever records movements at dispatch.

Gotchas

Warning

Deposits live in the crate ledger, not in invoices. A crate security deposit is not a GST supply, so it never appears as an invoice line, never enters GST reports, and — in this release — does not show in the customer's outstanding-balance figure on the credit screen. The per-customer crate balance screen is the source of truth for deposit money.

Tip

Returns refund from the deposit you actually hold, not the current catalog rate. That means you can re-price a crate type any time without creating refund gaps on crates issued at the old rate.

Was this helpful?