POS register, basket and tendered sales

Enter POS customer contact details

Record valid customer name/email/phone values. The guide then takes you through the correct route, the checks to complete before making changes, the workflow in order, and the evidence to review afterwards.

Audience: Cashiers and authorised supervisorsPermission: Enterprise POS: SellModule v1.0.0 · code-inspected
Jump to steps
Where to goEnterprise POS → Register

What you’ll accomplish

Record valid customer name/email/phone values. This section covers the staff register flow, exact tender rules, customer details and idempotent order commit.

Follow these steps

  1. Go to Enterprise POS → Register and open the workflow that matches “Enter POS customer contact details”. Confirm the page or record context before making a change.
  2. Go to an active shift for the chosen register.
  3. Go to Enterprise POS → Register and select the register.
  4. Search or scan active products.
  5. Add valid quantities and review discounts, tax and total.
  6. Enter customer details when needed.
  7. Select cash, external card terminal or bank transfer and add a reference when operationally required.
  8. Submit once and verify the completed order.

Fields and options to review

  • Guide focus: Record valid customer name/email/phone values.
  • Register and open shift
  • Product ID and quantity
  • Customer/client/contact identity
  • Cash, external card terminal or bank tender
  • Tender amount and reference
  • Coupon
  • Sale notes
  • Idempotency key

Rules the system enforces

  • An active register with the current staff member’s open shift is required.
  • The basket must contain valid sellable products and quantities.
  • Captured tenders must exactly equal the sale total.
  • The browser UI submits one tender; the service supports an array for mixed tenders.
  • A valid idempotency key prevents duplicate commits.
  • POS orders commit as completed, fulfilled and paid.

How to confirm it worked

  • The specific outcome described by this guide is visible and remains tenant-scoped.
  • One order, line snapshots, payment rows, stock movements, audit events and webhook events are committed together.
  • Repeating the same completed idempotent request returns the same order instead of creating another.

Safety checks and troubleshooting

  • Do not retry with a new idempotency key after an uncertain response until the existing reference is checked.
  • Never enter raw card details; use an external terminal and record only the approved reference.
  • Count cash through the shift workflow.
Stay within the supported module flow

Use the supplied UI, host module lifecycle and documented endpoints. Do not bypass tenant filters, permissions, CSRF, idempotency, rate limits, audit evidence or transaction checks. A stored table or field does not imply that version 1.0.0 exposes a management screen for it.