Restaurant

Handle Changed KOTs, Reprints and Kitchen Printer Failures

The kitchen queue labels changed order states, keeps a daily local print log and supports controlled reprints. Use the KOT number, order identity and print type together so the kitchen does not prepare duplicate or cancelled items.

Menu path
Posnic desktop app -> Hardware Manager -> Multi KOT Print -> Print Logs
Verified from
Posnic demo and current POS source reviewed on 2026-09-08
Technical source evidence

src/kot-manager.js ticket classification, daily numbering, deduplication, printer fallback and logging, src/hardware-manager.html log date, detail, selection, deletion and reprint controls, src/hardware-ipc.js log and reprint handlers, POS source reviewed 2026-09-04

Confirm the order firstUse KOT History to match the order ID, table, time and status before requesting another kitchen copy.
Reconcile after recoveryCancellation and Open Item reports help managers verify kitchen exceptions at shift close.

Read the Ticket Heading Before Cooking

Ticket headingMeaningKitchen response
New OrderA newly saved KOT entered the queue.Prepare the listed quantities once.
Modified OrderA saved KOT changed after its earlier kitchen output.Compare it with the earlier ticket and action only the additions/removals shown by shop procedure.
Order CancelledThe persisted KOT was cancelled.Stop or discard preparation according to manager and waste policy.

How KOT Identity Works

  • A KOT number is assigned from a daily counter and resets for a new calendar date.
  • Edits and cancellations retain the mapped KOT number for the same order slot so staff can relate paper changes.
  • The print service deduplicates jobs using sale identity, print type, timestamps and item content.
  • A successfully processed sale is marked as kitchen printed through the POS API.
  • Always compare KOT number with order ID, table or takeaway reference, time, PAX and items; do not rely on one field alone.

Use the Daily Print Log

  1. Open Hardware Manager -> Multi KOT Print.
  2. In Print Logs, choose the service date and click Load.
  3. Find the row by time, Sale ID, table, type, KOT number, device IP and printer result.
  4. Open Details and compare items and quantities with KOT History.
  5. Read each printer result. One printer can succeed while another fails.
  6. Resolve the physical or operating-system printer problem before reprinting.
  7. Use Reprint only after telling the kitchen that the next copy is a duplicate recovery copy.
  8. Verify the paper output, then record the incident under the shop's exception process.

Reprint Rules

Reprint rebuilds the ticket from the saved log entry and sends it to the printers currently configured in Hardware Manager. It is not restricted to the printer that originally failed.

  • Confirm the exact log row before pressing Reprint.
  • Check the current selected-printer set; a reprint can go to every configured station.
  • Do not repeatedly click while a printer is slow.
  • Mark or announce duplicate paper so staff do not prepare the order twice.
  • If no printers are configured, start KOT polling with the correct printer selection first.

Recover a Printer Outage

  1. Keep the cashier and kitchen informed; switch to the restaurant's approved verbal or handwritten fallback if service cannot wait.
  2. Check printer power, paper, cover, cable or network connection and the operating-system queue.
  3. Confirm Hardware Manager still shows Polling and Last Poll is updating.
  4. Stop polling before changing the selected printers.
  5. Click Load Printers, select the recovered or replacement device and restart polling.
  6. Save one controlled test KOT and verify output.
  7. Load today's Print Logs and identify failed or missing jobs.
  8. Compare every candidate with KOT History before reprinting it.
  9. Reconcile Open Item and Cancellation reports at shift close.

Fallback and Failure Behavior

For a named printer, the desktop service first attempts silent receipt printing. If the receipt page size is rejected it retries with printer defaults, then uses PDF-based printing; if the named printer still fails on Windows it can retry the system default printer. The log result remains the operator's evidence of which destination succeeded or failed.

  • A ticket appearing on the default printer may indicate that the selected named printer failed.
  • Do not treat a polling status alone as proof of paper output.
  • Check every configured station's result in the log.
  • Correct the operating-system printer name after replacement or driver reinstall.

Log Retention and Deletion

  • Logs are stored locally by date on the kitchen computer, not as a universal cloud audit trail.
  • Date selection loads that day's local file.
  • Selected rows can be deleted, and deletion cannot be undone.
  • Restrict deletion to authorized managers and only after required reconciliation or retention.
  • Export or preserve incident evidence according to business policy before deleting anything.