Sales
Void or Delete a Saved Sale Safely
Use the Sales History Delete action only for a whole saved sale that must be voided; returns, cart cancellation and line corrections use different workflows.
- Menu path
- Home -> Sales History -> locate sale -> Delete -> Proceed
- Verified from
- Posnic demo and current POS source reviewed on 2026-09-08
Technical source evidence
frontend/static/script/js/modules/js/sales.js saved-sale actions, KOT visibility rule and delete route, api/src/controllers/sales.controller.js deleteSales permission, manager approval and SALE_VOID audit, api/src/repositories/sale.repository.js deleteSales recycle backup, transaction, wallet, register and inventory effects, Current local Posnic POS Sales History and delete confirmation reviewed on 2026-09-08
Choose the Correct Correction
Delete in Sales History is the current whole-sale void action. It is not the normal way to fix every sales mistake. Decide what business event actually happened before touching the saved bill.
| Situation | Use | Reason |
|---|---|---|
| Sale has not been saved | Cancel or clear the New Sale cart | There is no saved bill to void. |
| One line or price is wrong and policy permits correction | Edit the saved sale | Preserves the bill while correcting allowed details; paid-sale editing is not offered in the current recent-sales list. |
| Customer brings merchandise back | Return items | Records the merchandise and refund workflow instead of erasing the original sale. |
| The entire saved bill is duplicate, test or invalid | Delete / void the saved sale | Removes the active sale and reverses linked records according to the current implementation. |
| Restaurant order is still an active KOT | Use the KOT cancel workflow | The Sales History delete action is hidden while KOT mode is enabled. |
Confirm Permission Before the Shift
The operator needs Sales Delete access. When the operator does not have the Till/POS Void a sale action, the API requests an authorised manager approval token. Configure both controls before relying on voids during a busy shift.
- Give permanent Sales Delete permission only to roles that may remove complete saved bills.
- Leave Void a sale restricted when your policy requires a manager PIN or card at the till.
- Test the exact cashier role, branch and device; administrator access can hide permission problems.
- A forbidden response means the role or manager approval is missing, not that the operator should create another sale.
Locate and Verify the Sale
- Open Home -> Sales History.
- Locate the bill by bill number first; otherwise compare date, time, customer and total.
- Open the sale and compare its item names, quantities, prices and payment status with the receipt or correction request.
- Record the business reason and approving manager according to shop policy before deletion; the current confirmation does not collect a reason.
- Return to the matching row and choose the trash / Delete action.
Understand the Confirmation
The current dialog says Delete Record and warns that related transactions will also be deleted. Close is the safe exit. Proceed performs the whole-sale deletion immediately; there is no second review screen and no in-place Undo button.
- Stop if the bill behind the dialog is not the intended sale.
- Stop if the request is only for a return, refund or line correction.
- Confirm cash, card, wallet or customer-credit consequences before proceeding.
- Select Proceed once, then wait for Sales History to refresh instead of clicking repeatedly.
What Posnic Changes
| Area | Current source behavior | Operator consequence |
|---|---|---|
| Sales History | The sale is removed from the active sales collection after a recycle-bin backup is written. | Do not expect the voided bill to remain as an ordinary active sale row. |
| Audit | A SALE_VOID audit event is written with bill and total details. | Keep the approver and business reason in the shop's correction record. |
| Cash register | The sale ID is removed from matching register_sales references. | Reopen register totals before close. |
| Partial / wallet payment | Related customer transactions are backed up and deleted, then wallet balance is recalculated. | Check the customer account immediately. |
| Inventory | For non-Hold sales, tracked items are added back only when branch stock-management logging is enabled in the current implementation. | Verify quantity and Inventory Logs; never assume stock returned. |
| External payment | Posnic removes its linked record but cannot itself reverse a bank, card-terminal or gateway settlement. | Complete the provider refund or reversal separately when required. |
Reconcile Immediately After Proceed
- Search Sales History for the bill number and confirm the active row is gone.
- Check the affected items in Inventory and Inventory Logs, especially when stock-management logging is disabled or the item does not track inventory.
- Open the customer account when the sale used credit, wallet or partial payment and confirm the recalculated balance.
- Recheck the open register and the relevant payment report.
- Complete any cash handback, card refund or gateway reversal using the approved external process.
- Run the day-close or daily report again and attach the void approval to the shift record.
When Something Looks Wrong
- Delete action missing: confirm the role has Sales Delete access and that KOT mode is not hiding the recent-sales delete action.
- Manager approval rejected: use an active authorised manager credential with Void a sale permission.
- Stock did not increase: inspect item Track inventory and branch stock-management-log configuration, then make an approved stock adjustment if necessary.
- Customer balance is unexpected: review the backed-out partial or wallet transaction before accepting another payment.
- Wrong bill was deleted: stop further corrections and ask an administrator to inspect Recycle Bin and audit evidence; do not invent a replacement bill without approval.
- Report and terminal disagree: reconcile the external payment first, then document the variance for register close.