Khata — selling on credit

Menu: Sell → Khata · Sell → Receipts · Sell → Returns · Sell → Customers · Who: owner, branch manager, cashier (the two registers and writing a debt off are not a cashier's)

A distributor loads a van and drives a round. At each shop he leaves three loaves on credit; three days later he stands at that same counter and does three things at once — takes back the one that spoiled, leaves today's delivery, and collects money. Sometimes all of it, sometimes half, sometimes none.

That is what the khata is for. A shop that sells over a counter and takes the money there does not need any of this.

Opening an account

Khata → Open a khata. Pick any shop off the customer book and it joins the trade list. A reason is kept on the record.

The ceiling is set next, on the account itself — Khata → the shop → Credit terms:

• Credit limit — leave it empty for no ceiling, which is a real answer and not a gap. A limit of zero would refuse every sale, so the two are never read for each other.
• This shop buys on account — unticking it takes them off the trade list.

Only somebody who may write a debt off may set the terms it runs on. That is the owner, and anyone the owner grants it to. A branch manager cannot: a credit limit is worth money forever.

Every change is on the record — who moved the ceiling, from what to what, when and why. "Who gave this man a two-lakh limit" is the first question an owner asks, and the current figure cannot answer it.

An account that still owes money cannot be closed, and the refusal names what is on it. Nothing would be lost — the ledger never deletes — but a shop taken off the list while it owes forty thousand disappears from every screen that shows who owes what, and the debt goes with it.

What they owed before Sellify

Khata → the shop → Opening balance. Once per shop, ever. Positive is a debt; a shop that is in credit with you is entered as a negative.

It sits on the statement like every other row, so a khata that arrived with the shop reads the same way as everything since — and the button is only there while the account has no rows yet. An opening is what a khata STARTS at; one that has been sold into since is corrected with an adjustment, where the reason and the record are.

Selling on account

At the till, name the shop and choose On account as the payment. That is the whole change — everything else about the sale is an ordinary sale: the same cart, the same tax, the same stock coming off the shelf, the same figure on the Z report.

Part cash, part on account is an ordinary split. Rs 3,000 handed over and Rs 2,000 on the khata is two payment rows, and only the Rs 2,000 reaches the ledger. The tax follows the mix exactly as a cash/card split does.

The drawer is untouched. Money on a khata is not cash, so no till is ever expected to hold it and no day close asks about it.

Over the limit

A sale past the ceiling is stopped, and the refusal names the balance, the limit and the shortfall — so nobody does subtraction at a shop's counter.

A manager can lift it with their PIN, and who let that sale through is recorded on the order. Set approvals.credit_limit_override off and the ceiling is absolute: nobody passes, and no manager is fetched — being sent for one only to be refused in front of the customer is the worst version of that screen.

An owner or a branch manager ringing it themselves needs no PIN, and is still recorded.

Hand over now, or send with the van

A credit sale asks once, when it is placed:

• Hand over now — the goods leave with the customer. Stock comes off the shelf there and then, like any retail sale.
• Send with the van — the order goes on the dispatch board, and the shelf is charged when the van actually leaves. Goods in a van while the shelf still says they are in the building means the next till sells something that has physically gone.

A drop that fails voids the sale, puts the stock back and reverses the khata entry. Nothing was delivered, so nothing is owed.

The visit — three things at one counter

Khata → the customer → Start a visit. One screen:

1. What came back — off any open bill, priced at what that bill actually charged.
2. Today's delivery — an ordinary cart, put on the khata.
3. What they paid — cash, card, or a bank transfer with its reference.

All three save together or none of them do. A shop is never left having handed goods back against a delivery that then failed to save.

The order they are applied in is deliberate: the return first, so the credit it raises is off the queue; then the sale; then the money, so it runs down the real queue. A shopkeeper who hands over exactly what they owe is square when the salesman walks out.

Goods that came back

A return is its own document on its own day. Monday's three-loaf bill stays a three-loaf bill and a one-loaf credit note sits under it — the balance is what comes right. Rewriting the invoice would leave the shopkeeper's own copy of the paper disagreeing with ours, and would move figures out of a sales report somebody has already read.

Three loaves out can never be four loaves back. The ceiling counts every return ever raised against that line.

Each line says what condition the goods came back in:

• Good — back on the shelf, sellable.
• Damaged / Expired — back on the shelf and then written off again, as two separate movements. "How much came back" and "how much was WASTED" are different questions, and a shop that only ever sees the net figure cannot tell a slow-selling stockist from a careless one.

A cash sale can be returned too, and the return says which: cash back now, or credit to the ledger.

No return window unless you set one. credit.return_window_days is empty out of the box — the bread man comes back in three days and a wholesaler in two months, and a product that picked one would refuse a real return at a real counter with the goods already on it.

Money coming in

Khata → the customer → Take money. One figure is typed: the amount. Which bills it clears is worked out here, oldest first.

An account cannot be settled with more credit. Cash, card, or wallet for a cheque or a bank transfer with its number in the reference.

Money left over is not an error. An overpayment stays on the account as an advance — the balance goes negative, which is what "in credit" means — and the next sale is what it lands on, by itself.

Taken at the counter, or collected on the round

One field decides, and it matters:

A salesman usually has no login, so he is an employee row — the same as a rider.

Settling the round

A day will not close with a collector's cash in his pocket, and the refusal names him. Nothing else in the day close can see that money: the bills he was paid against were rung in days ago and counted since.

The collector declares what he counted; the server works out what was expected and the variance. Short is a negative number, the same convention as everywhere else in Sellify.

The register — every receipt you have taken

Menu: Sell → Receipts · Who: owner, branch manager

The khata answers what a shop owes today. The register answers what was actually handed over, and when — which is the page you open when a shopkeeper's own account disagrees with yours and the argument is about one payment in March.

It is this branch's book and follows the branch picker at the top of the screen. A balance is company-wide, because a shop that buys at one outlet and pays at another owes one debt; a receipt was taken at one counter, or by one salesman riding out of one outlet.

Narrow it by shop, by who collected it, and by a date range. Two columns answer the questions a register is opened for:

Open a row to see what it closed, who recorded it, and the cheque or transfer number.

A cashier does not have this screen. Taking money is counter work and they do that on the khata; reading months back to settle an argument is not, and their own day is already answered by their shift and the Z report.

Saying which bills a receipt was really for

Sellify puts money against the oldest bill first, which is what a shopkeeper is chased for and what is right almost always. It is wrong exactly when they insist a particular payment was for a particular delivery.

Open the receipt and press Say which bills. Type what belongs against each bill and save. Every open bill on that account is listed, and so is any bill this receipt has already closed — that is usually the one you are moving money off. Each box says what that bill can take.

Sellify refuses three things, each in a sentence naming the bill:

• more than the receipt was worth, spread across the lot
• more than a bill is actually owed
• the same bill named twice

No money moves. The balance was settled the day the money was handed over; all this changes is which invoice reads as paid on the statement. That is why it is the owner's and the branch manager's.

Leaving every box empty is a real answer: it takes the receipt off every bill and leaves the whole of it standing to their credit, against the next delivery.

It is the same screen as Accounts → Supplier payments, read the other way round. What you owe a distributor and what a shop owes you are two books with one shape.

credit.settle_collectors turns the guard off, for a shop whose salesmen pay straight to the owner.

Re-allocating a receipt

Oldest-first is right almost always, and wrong exactly when a shopkeeper insists a payment was for a particular delivery. A manager can move it: no money moves, only which invoice reads as paid — which is what a month-end statement gets argued over.

The register — everything that came back

Menu: Sell → Returns · Who: owner, branch manager

The section above records a return against the sale it came off, which is the right way round when somebody is standing at your counter with a loaf. It is the wrong way round when the question is "what did we take back this month, and how much of it went in the bin" — answering that meant opening every sale one at a time.

This is one row per document, newest first, for this branch. Narrow it by shop and by a date range.

Open a row for the lines themselves: how many of each, what condition, what the customer got for it, the reason somebody typed, and who recorded it.

Nothing on this screen writes. A receipt can be re-allocated because which bill it closed is a judgement; a return is not. The prices, the discount and the tax are the sale's own frozen figures, and the stock has already moved. Goods recorded wrong come back out through a stock adjustment, where the reason and the record are — not by editing this.

It is not the Returns report. That one (Reporting → Reports → Credit → Sales returns) is summarised by day, because what it answers is the split — good against damaged against expired, as a trend. This answers a single argument: which item, off which bill, on which day, credited to whom.

What the khata is made of

Every row on the statement is one of seven things, and each carries the date, the branch, the document behind it, who wrote it and why:

opening · sale · credit note · payment · allowance · write-off · adjustment

A mistyped receipt is corrected with an adjustment, which is the owner's act with a typed reason on it. Nothing is ever deleted.

The five reports

Reports → Credit.

• Customer statement — one shop, the page that gets handed over at month end. It opens with what was brought forward rather than at zero, because a March statement starting at nothing tells a shopkeeper they owed nothing on the 1st.
• Receivables aging — 0–30 / 31–60 / 61–90 / 90+. It buckets the bill, not the balance: a shop that pays every delivery a fortnight late and one that has not paid since January owe the same figure, and only the buckets tell them apart. A shop in credit is its own column, not netted in.
• Sales by party — bought, returned and paid on one line. One who buys forty thousand and returns eight is not the same customer as one who buys forty thousand and returns nothing.
• Sales returns — good against damaged and expired.
• Collections — per collector: what they took, what they declared, and the variance.

The first three name a shop and its number, so they are never shown to the assistant.

The van's own till

Admin → Terminals → Credit customers. Off by default.

A salesman standing in a shop doorway with no signal has to be able to name the shop, so his till carries this branch's credit customers. A counter till never does — a customer book on a tablet that can be left in a taxi is a decision somebody should have made on purpose.

It carries who they are, never what they owe. Name, phone and address ride down; the balance and the limit do not. Those are counted from rows another till is moving while this one is dark, so a figure shipped to a tablet would be wrong the moment it landed — and a limit checked against a stale balance is not a limit.

So on a dark till: the shop can be named and the sale can be rung, but what they owe and the sale on account both need the server, and the screen says so in a sentence rather than greying a button out.

What the khata does not do

• No per-customer price list. A trade customer is charged the shelf price, and where a rate was agreed the counter types it — which records the price it replaced and refuses anything below cost. A real wholesale price list has to reach the menu, the offline bundle and every report at once, and is its own piece of work.
• No routes. Which shops a van visits in what order is not something Sellify plans.
• No van as a stock location. The order is what takes goods off the shelf.
• No batch or expiry tracking on a return. Returned goods are counted, never traced.
• No interest and no ageing charges. Nothing is added to a balance for being old.

Buying it

Credit sales is a module and it is off by default — every other module in Sellify is on, because switching gating on must never take something away from a shop that already had it, and that cannot apply to a module nobody has yet. A shop selling over a counter must not find a credit button on its till because somebody added a feature.

Buying Bookings brings it with it: a deposit lands on a customer's ledger, so the diary cannot work without the khata underneath it.