The nightly job archived rentals whose cars were still out
A booking said collect 9,797 rupees, fully settled and archived all at once. The cause was a nightly job closing rentals that had not ended.
One booking on the office screen said three things at once: collect 9,797 rupees, fully settled, and archived. A customer cannot owe money and owe nothing. The owner asked which was true, and nobody could say.
Pulling that thread for GOI Car & Taxi, a self-drive and taxi hire business in Goa, led somewhere worse than one confusing screen. A nightly job was closing bookings whose cars were still on the road, and a large pile of security deposits was showing as still held. Since the new money ledger went live on 30 June, 119 bookings had been closed that way, at about four a night and still going. A further 152 expired bookings showed deposits still held, together 769,000 rupees.
What was actually going on
Three things, only one of them in the booking that started it.
The nightly job archived any booking past its dates, whether or not the car had come back. It was closing bookings that were waiting for a drop-off to be assigned or were mid-return.
Then the refund. When a refund was paid out on that booking, the ledger filed it in the deposit lane as money going out. The deposit balance went to minus 4,797. The part of the screen that works out how much deposit is still to collect saw a hole and turned it into a phantom amount to collect. That is the 9,797 on the screen.
The 152 bookings were a different kind of problem. Most of that 769,000 had very likely been handed back in cash and never logged, so the books show money held that customers already have. Only one booking had the exact broken-ledger pattern. Across the wider set, the log counts 1.16 million rupees of deposits shown as unreturned, of which 700,000 belongs to rentals that genuinely ran.
What we changed
The nightly job now leaves alone any booking with drop-off work outstanding. A refund gets its own kind of entry and its own split between lanes, so it can no longer drag the deposit negative. The figure for deposit still to collect cannot fall below zero. Every place that writes a refund refuses to refund more than was taken. Archived bookings now show a Refunded tile and a notice that money is still held.
We tested it on a copy of production. On the real booking, the phantom 9,797 to collect was gone and the refunded amount showed instead. Twelve settlement cases passed, along with browser tests that drive the screens as the office does. One row of reference data was added to the production database before the code went out, and the change was deployed on 4 August.
What it did not fix
The 119 bookings already closed and the 769,000 rupees were documented for the owner to decide on, not corrected behind his back. The data cannot tell us whether each deposit was returned. Someone has to check cash records, booking by booking, and that is a business decision, not a software one.
Nor does the change stop a person recording a refund on the wrong booking. It only stops the system from letting it exceed what was taken.
The pattern, for anyone who archives by date
A job that closes records because a date has passed is asking the wrong question. Ask what state the record is in. A rental is not over when its dates end; it is over when the car is back.
Check for yourself: find any record your system shows as closed, and look at whether it still shows money held. If it does, the closing rule and the money rule have drifted apart.
Where this ends up
Keeping the money view and the booking’s real state in step is the point of the ledger in Sazinga Rentals.