Ralat: Correcting a Closed Repair Without Losing the Trail
The transaction is closed. The customer has gone. The receipt is printed.
Then a week later you open a report and realise the labour was recorded at a hundred and fifty thousand when two hundred and fifty was agreed. Or a part that genuinely went onto the unit never made it onto the bill.
At this point most shops do one of two things, and both are bad. The first: leave it, because changing an old transaction feels dangerous. Your reports are then permanently wrong, and you stop trusting your own numbers. The second: change the data quietly by some other route, so the figure is right but nobody knows why it moved — which is far more dangerous.
Ralat is the correct door for both. You pick the transaction that is wrong, fix the figures, and the system recalculates the totals.
What makes it trustworthy sits behind the screen: every correction is stored as its own version, complete with the figures as they were before. The old ones are not deleted. So “why did this change?” can always be answered by showing rather than explaining.
One warning before you open it: a correction is not a tidying session. The great temptation is to fix three other things that happen to look untidy — and this tutorial explains why that is exactly what makes the trail useless.
Before you start
- The repair you want to correct already exists and is finished.
- You know exactly what is wrong. Opening a correction while still hunting is the quickest way to make a second mistake.
Steps
-
First make sure this is a correction, not a return
Three things get confused. A return is goods or work the customer brought back. A cancellation is a repair that never got done. A correction — Ralat — is a transaction where the work was right but the figures were recorded wrong. Choosing the wrong door here makes your reports describe something that never happened.
-
Open Perbaikan → Ralat, then Tambah baru
The screen greets you with one line: "Pilih transaksi perbaikan yang akan diralat!" — pick the repair to be corrected. You do not type an invoice number from memory; you choose it from the list of existing transactions.
Corrections have their own menu, separate from returns. -
Find it by whichever column you remember best
The list shows Waktu Masuk, Waktu Diambil, Nomor Nota, Pelanggan, Nomor Kontak, Daftar Item, the unit data, Model, Kode Cari, and who did the work. If the invoice number escapes you, search by customer name or Kode Cari — those are what usually stick. Press Pilih on its row.
Search by whichever field you remember best. -
Understand the crucial part: a correction versions, it does not overwrite
This is why the feature deserves your trust. Every correction is stored as its own version, complete with the earlier figures — total bill, total discount, total payment, service cost and parts cost. The old numbers are not deleted. So when somebody later asks "why did this change?", the answer can be shown rather than explained.
A correction never overwrites; it creates a version. -
Fix only what is wrong — do not tidy other things while you are there
The great temptation on opening a correction is to fix three other things that happen to look untidy. Do not. One correction should answer one mistake, because a version holding many changes at once is impossible to trace when you are working out which one caused trouble.
-
Write the note as if explaining to somebody else, not to yourself
Each correction carries a note field. "Fixed" is useless. "Labour recorded at 150k, should be 250k as originally agreed" is useful — because in three months the person reading it is not you, and they have no context beyond that sentence.
-
Check the totals once the correction is saved
A correction recalculates. Reopen the transaction and read three figures: total bill, total paid, and the remainder. If the transaction was settled and the bill has now risen, there is a receivable to chase — and that is a conversation with the customer you had better start today.
Check the totals once the correction is saved. -
Check the stock effect when parts were involved
Changing parts on a finished transaction moves stock. Open Persediaan → Arus Stok for that item and confirm the movement makes sense. This is the most commonly skipped step, and the most common source of next month stock discrepancy.
Check the stock impact when parts are involved. -
Limit who may make corrections
A correction changes figures on a closed transaction — authority that should not sit with everybody. Set it under Pengaturan → Hak Akses so only an owner or admin can. Not out of suspicion, but because somebody rushing in front of a customer should not be able to alter last month reports.
Limit who is allowed to correct.
What you end up with
Recording mistakes on finished transactions can be fixed with recalculated figures while the earlier version stays stored — so your reports are right without losing the trail of what changed and why.
If something goes wrong
The transaction does not appear in the selection list
The correction list shows existing repair transactions. If yours is missing, check you are in the right shop, and that it really is a repair — sales and purchases have correction routes of their own.
I need to cancel the whole transaction, not fix its figures
That is not a correction. A repair that never got done is handled through the Batal (cancelled) status, and goods returned by a customer through Retur. Both have their own tutorials.
After correcting, a settled transaction now shows a balance
That is correct and expected — the bill rose while the payment stayed. The remainder stands as a receivable. Contact the customer now rather than discovering it at month-end.
Last month figures changed too
That is the consequence of correcting a transaction from last month. If the books are already closed through the accounting module, speak to whoever handles the bookkeeping before correcting — cross-period corrections have rules of their own.
How many times may one transaction be corrected?
Each correction adds a version, so technically it can repeat. But a transaction corrected repeatedly usually signals a problem in how things are entered rather than in the transaction. When that happens, fix the recording habit.