Retail self-checkout evaluation, not a local deployment claim
Self-checkout POS evaluation for Pretoria, Gauteng
Test the exact customer interaction, scan and weight paths, attendant exceptions, payment states, receipt, stock, close and restore. The location name does not establish an installed lane, provider, approval, customer result or support commitment.
What the pinned retail evidence establishes
At exact source commit b531ef4308c4dc3a25f250551a54fc5616e3b8d9, ten focused desktop test files passed 92 tests with zero failures. They cover selected item-grid barcode fields, continuous scale frames, weighed quantities, receipt and report output, named sale paths, till permissions and chart lifecycle. They do not exercise a bundled customer screen, attendant console, integrated unattended payment terminal, physical lane, anti-loss control or complete shift.
Retail foundations are evidenced
At the pinned commit, 92 focused tests cover barcode fields, scale frames, weighed quantities, receipts, reports, selected sale paths, permissions and chart lifecycle.
A complete lane is not evidenced
The review found no bundled customer self-checkout UI, attendant console, physical lane, loss-prevention control or accepted complete shift.
Payment remains an integration decision
The pinned hardware matrix says integrated card terminals are not implemented. The exact device, acquirer, states and reconciliation require acceptance.
Local readiness remains unverified
No customer deployment, installer, support commitment, accessibility result, legal-metrology approval or accepted pilot is recorded for Pretoria.
Unverified self-checkout inputs for Pretoria
Every place, currency, tax and payment value below is directory or planning context. It is not an accepted store, lane, device, provider, legal result, accessibility result, customer deployment, installer or local support commitment.
| Control | Current planning input | Evidence required before rollout |
|---|---|---|
| Search evidence | Seven query rows, 34 impressions and zero clicks | Query x Page x Country x Device evidence with date range, CTR, position and conversion before assigning demand or a location winner. The supplied query export contains none of those dimensions. |
| Market, operator and lane | Pretoria, South Africa | Named legal operator, store and lane IDs, current process, customer groups, objectives, exclusions, accountable owners and applicable local authorities. |
| Currency, tax and receipt | South African rand; VAT | Approved item, tax, discount, rounding, payment, receipt, correction, return, reporting, retention and filing cases on the exact build. |
| Payment candidates | cash, cards, contactless payments and digital wallets | Exact acquirer, merchant account, approved device, integration, authorization, decline, cancel, timeout, uncertainty, refund, settlement, security and reconciliation evidence. |
| Customer interaction | No bundled lane UI established | Versioned screen or enclosure, entry and exit, basket review, quantity, removal, help, language, timeout, abandon, completion and visible fallback behavior. |
| Barcode and item identity | No physical scan accepted | Exact scanner mode and supported one-dimensional and two-dimensional symbols; ordinary, unknown, damaged, duplicate, recalled, expired and variable-data examples; and one approved item result per scan. |
| Weighed goods | No commercial scale accepted | Exact scale, protocol, zero, stable, negative, over-range and disconnected states plus binding legal-metrology review before charging by measured quantity. |
| Attendant and restricted actions | No accepted attendant console | Authenticated help, age or regulated-item process, price query, item removal, quantity change, void, override, receipt recovery, attribution, role and audit evidence. |
| Sale, stock and receipt | No accepted end-to-end basket | One approved payment produces one durable sale, expected stock movement and searchable receipt; failed and cancelled attempts produce none; interrupted commit recovers without duplication. |
| Accessibility and assistance | No installed-system assessment | Applicable requirements, representative users and assistive needs, reach and operability, visible and audible states, focus, errors, timing, language, privacy and staffed assistance. |
| Security, privacy and loss controls | No accepted control set | Approved physical and software access, tamper response, customer-data purpose and retention, logging, alerts, item movement, exception ownership and incident process. |
| Dependency outage and fallback | No accepted failure period | Scanner, scale, printer, payment, network and POS failures exercised one at a time with customer message, staff fallback, recovery target and no unexplained financial or stock record. |
| Close, backup and restore | No accepted supervised pilot | Known baskets, sales, settlements, receipts, stock movements, interventions and exceptions reconcile; a clean restore preserves approved records; named owners approve expansion. |
Run the 24-control installed-lane acceptance path
Use synthetic customers, products and payment cases in a disposable environment first. Keep the result unverified until one supervised lane completes the agreed item mix and failure states, all independent records reconcile, a clean restore succeeds and named business, accessibility, legal-metrology, payment, security and technical owners approve the evidence.
- Record the exact Posnic build, customer interface, computer, scanner, scale, printer, payment device, network and accountable owners.
- Freeze representative ordinary, discounted, taxed, unknown, damaged-code, loose and restricted item samples.
- Run customer access, one-dimensional and two-dimensional barcode, duplicate scan, invalid weight and basket-correction cases.
- Require attributable attendant authentication for help, restricted items, voids and other approved exceptions.
- Run approved, declined, cancelled, timed-out and uncertain payment outcomes without duplicating a charge or sale.
- Review the complete installed interaction against applicable accessibility and legal-metrology requirements.
- Disconnect scanner, scale, printer, payment, network and POS dependencies separately and exercise the approved fallback.
- Reconcile sale, stock, receipt, settlement, intervention and exception records, restore cleanly and obtain named pilot approval.
Questions about self-checkout POS for Pretoria
Does Posnic v1.3.0 include a complete self-checkout lane?
No bundled customer self-checkout screen or accepted physical lane is established. The pinned release provides retail POS components that an implementation can evaluate.
What did the 92 focused tests prove?
They covered selected barcode, weighing, receipt, report, sale-path, permission and chart behavior at the pinned source commit. They did not exercise a complete customer lane or physical device set.
Can any scanner or commercial scale be assumed to work?
No. Test the exact make, model, mode, barcode symbols, scale frames and binding commercial-weighing process before purchase or rollout.
Does Posnic provide an integrated unattended payment terminal?
Not in the pinned hardware matrix. Select the exact device and acquirer path, define scope and run every payment and recovery state.
Does WCAG2ICT certify an installed lane?
No. It is informative W3C guidance for applying WCAG concepts to non-web software, including closed functionality. Applicable requirements and the installed system still need review.
Is self-checkout approved for Pretoria?
No local customer, installed lane, legal review, accessibility result, support commitment or accepted pilot is recorded on this page.
What should pass before a supervised pilot?
All 24 controls should retain observed evidence for scan, weight, attendant, payment, receipt, stock, outage, close, fallback and restore behavior with named owner approval.
Pinned Posnic product sources
These links expose the exact release, documentation and ten test files behind the 92-test result. Passing component tests and documented workflows do not prove a complete customer lane or physical device set.
Primary barcode, accessibility, payment, weighing and recovery sources
GS1 explicitly includes traditional and self-service checkout in its current retail POS guidance. WCAG2ICT is informative, PCI PTS includes unattended payment terminals as a device category, OIML R 76:2006 is a model recommendation under active revision, and NIST Handbook 44 is a US example. None certifies Posnic or replaces the binding local review.
Related location and workflow pages
These links are navigation only. They do not prove a Posnic office, customer, installed lane, hardware bundle, payment connection, accessibility result, legal approval, local support or accepted outcome.
Decision boundary for Pretoria
Posnic v1.3.0 has evidenced retail POS components, but this page does not establish a bundled customer self-checkout UI, attendant console, integrated unattended payment terminal, physical lane, anti-loss control, accessibility conformance, commercial-weighing approval, complete service period, clean restore, customer deployment or local support. Keep the result unverified until the exact installed system passes all 24 controls.
Retail self-checkout owner evidence/Country-readiness method/Support routes