Settings

Control and Audit Sale Date Backdating

Allow changing sale date controls the New Sale date picker. When off, Posnic fills the current outlet time and disables picker interaction, but this is a client-side workflow control rather than an API authorization boundary.

Menu path
Manage -> Core Settings -> Sale -> Allow changing sale date
Verified from
Posnic demo and current POS source reviewed on 2026-09-13
Technical source evidence

Live demo rechecked 2026-09-13 at Manage -> Core Settings -> Sale and Sales -> New Sale, frontend/modules/settings_write.html allow_sale_date_edit, frontend/static/script/js/modules/js/settings.js setting load, local cache and save, frontend/static/script/js/modules/js/sales.js applySaleDateLock and New Sale payload, api/src/models/setting.model.js branch setting persistence, api/src/helpers/sales.helper.js report date filtering, api/src/repositories/sale.repository.js stored sale-date normalization

Configure sale-date editingThe switch is a branch setting under Core Settings -> Sale. Decide the policy before the trading day and test it on every active till.
Verify the New Sale dateNew Sale shows the active transaction date at the upper right. When editing is allowed the field opens the date picker; when locked it is pinned to the current outlet time.

Understand the Two Modes

SettingNew Sale behaviorOperator implication
OnThe date field keeps its date-picker behavior and a cashier can choose another date and time.Backdating and future-dating become possible from the standard till interface.
OffPosnic replaces the field with the current time in the outlet time zone, removes the picker hook and blocks pointer interaction.A normal cashier cannot select another date from New Sale.
Unset or client errorThe current code leaves the field editable.Treat an unexpected editable date as a control failure and stop before saving.
Edit saved saleThe existing sale date is read-only in the normal edit flow.The New Sale switch is not a general permission for rewriting every historical date.

Recognize the Control Boundary

The lock is applied by the New Sale browser code after reading a locally cached branch setting. The sale API still receives the date supplied in the transaction payload. It is therefore a cashier-interface safeguard, not an audit-grade server permission or protection against custom API requests, altered clients or a failed cache refresh.

  • Do not describe the switch as preventing all backdated sales.
  • Restrict Sale Write and API access separately.
  • Use individual employee accounts so a saved transaction has an accountable operator.
  • Review sales by business date and modification date where the report exposes both.
  • Escalate an editable field while the switch is off as a till configuration incident.

Choose a Backdating Policy

Operating situationRecommended modeRequired control
Normal live counter salesOffRecord the sale when money and goods change hands.
Approved offline-entry recoveryTemporarily on for an authorized operatorUse source receipts, a bounded time window and manager review.
Historical migrationDo not use the live till casuallyUse an approved import or migration plan with reconciliation.
Training or demo dataOn only in a non-production outletKeep test transactions out of live reports and tax periods.
Regulated tax or closed accounting periodOffRequire accountant-approved correction procedures instead of backdating.

Turn Sale-Date Editing Off

  1. Finish or park any sale already open on the till.
  2. Open Manage -> Core Settings and select Sale.
  3. Clear Allow changing sale date.
  4. Use the main Core Settings Save button and wait for the success response.
  5. Open a fresh Sales -> New Sale screen; do not test with a page that was already open before saving.
  6. Confirm the upper-right date shows the current outlet date and time.
  7. Select the date field and verify no date picker can be used.
  8. Repeat the test on every active device and after switching outlets.

Allow an Approved Backdated Sale

Enable the setting only for a controlled operational reason. A changed date can move revenue, tax, stock evidence and customer history into another business period.

  1. Record the manager approval, intended source document and exact permitted date range.
  2. Enable Allow changing sale date in the correct outlet and save.
  3. Open a fresh New Sale and select the intended date and time in the outlet time zone.
  4. Enter the sale from the original receipt or other approved evidence; do not estimate tender, tax or quantities.
  5. Before payment, compare customer, items, quantities, tax, discount, tender and selected date with the evidence.
  6. Save once and record the generated bill number in the recovery log.
  7. Turn date editing off again immediately after the approved batch and retest a fresh New Sale.
  8. Reconcile the bills in Sales History, payment reports, tax reports and stock logs.

Know Which Dates Reports Use

SurfaceRelevant behaviorAudit consequence
Receipt and sale detailShow the stored transaction date.Confirm the selected business date on the saved bill.
Sales HistoryUses stored business-side date fields with legacy fallbacks and may show return/update timing for returned sales.Use bill number and detail view when dates appear inconsistent.
Some sales and KOT reportsFilter the sale date.A backdated transaction can appear in the earlier selected period.
Other tax, payment and item reportsSome filter updated_date instead.An older business date entered today can appear in a current modification window.
Dashboard and day boundariesUse the outlet time zone.Test dates near midnight after any outlet time-zone change.
Inventory LogsProvide separate movement evidence.Reconcile stock timing instead of assuming the receipt date explains every log timestamp.

Audit Backdated Activity

  1. Export or record the approved bill-number list before beginning the review.
  2. Run Sales History for both the original entry day and every selected backdated day.
  3. Compare bill number, customer, operator, items, total, tender and stored sale date with source evidence.
  4. Run payment transaction reports for the actual collection period and reconcile settlement evidence.
  5. Run sales-tax and GST working reports across both relevant date windows when tax applies.
  6. Review Inventory Logs for each affected tracked item.
  7. Document differences caused by sale-date versus updated-date filtering; do not force unlike reports to match.
  8. Have the owner or accountant sign off before closing the correction batch.

Troubleshooting

ProblemLikely reasonControlled response
Date picker still opens after turning the switch offThe New Sale tab or device cache predates the saved change, or the client lock failed open.Stop the sale, reload Core Settings, reopen a fresh New Sale and report a repeat failure.
Date field is read-only but still opens a pickerThe editable field uses readonly text with the commonDate picker hook.Test actual picker interaction; readonly alone does not prove the lock is active.
Backdated bill is missing from today's sales reportThat report filters the stored sale date.Run the report for the selected backdated period and reconcile by bill number.
Old bill appears in a current reportThe report filters updated_date or the sale was edited/returned today.Inspect the report's date rule and source sale detail.
The displayed time is wrongOutlet time zone or device state is incorrect.Verify outlet locale settings before creating more transactions; do not compensate by choosing a false sale time.
Employee can submit a custom dated transactionThe UI switch is not server-side authorization.Restrict API and Sale Write access, preserve evidence and escalate for security review.
Closed tax totals changedA sale was placed into or updated during a previously reviewed period.Freeze further corrections and have the accountant reconcile the affected periods and filings.

Manager Close Checklist

  • Sale-date editing is off on every normal production outlet.
  • Every temporary enablement has approval, source evidence and a bounded list of bill numbers.
  • The switch was disabled and retested after recovery work.
  • Sale-date and updated-date reports were reconciled according to their actual filter behavior.
  • Payment settlement, tax and stock evidence agree with the approved correction record.
  • Unexpected editable dates or custom API activity were escalated rather than treated as operator error.

Related Manual Pages

Sales Create a Sale The detailed counter workflow: find or scan items, add quick lines, choose customer, edit cart, take payment, print and verify the sale. Sales Find and Read a Sale Sales History is the source list for saved sales in the active outlet. Find the exact bill with its identifier, customer, date, item count, total and status, then open the invoice pane before printing, editing, returning or collecting payment. Sales Edit a Saved Sale Editing a saved sale is a financial and inventory correction, not a display-only change. Posnic rebuilds the sale from the submitted cart, adjusts tracked stock by line differences, updates its register entry and can change the period used by reports. Settings Outlet Locale Currency, time zone and date format are branch-level settings. They change how one outlet displays money and interprets business dates, but they do not convert historical amounts or rewrite old transaction values. Settings Employees and Roles Staff access starts with named employees, branch assignment, a role or custom matrix, POS action authority, and a review habit. Reports Sales Reports Sales Reports split normal sale lines, quick sale activity and summary totals so owners can audit bills without opening every receipt. Reports Sale Payment Transactions This tab is the bill-level trail for completed and partially returned sales. Use it when a payment-method total does not match the till or external provider. Reports Sales Tax Collected Sales Tax Collected is an operational cross-check built from taxed sale-item rows. It is not a tax return, invoice register or substitute for Tax Summary and statutory GST reports. Inventory Inventory Logs Inventory Logs are the branch stock ledger. Each row opens a movement detail beside the list, where operators can inspect the reference and follow controlled links to the item, sale or purchase.