← Back to catalogue
Published

Basket, checkout and sales transaction

EM-RTL-04 · em-rtl-04

Keep a complete, balanced record of every sale and its checkout path, so that revenue, tax, stock and customer questions can be answered from it.

Enterprise profiles Enterprise subject EnterpriseRTL
Bundle → Layer → Finding → QuestionsClassifiersWhat it isWhy it existsDistinguishing featuresWhat robots and AI may and may not doMoral aspectsOwnersLinks to other meta-modelsIdentity and identifiersDirect propertiesRecognitionCapabilities and actionsHazards and failure modesStandards and interfacesContext of useSources

Bundle → Layer → Finding → Questions Filled

2 bundles · 2 layers · 4 findings · 8 questions

Basket and checkout What happened before the sale.

Before the sale

Basket content, reservations and checkout outcome.

Basket

Items, prices and the fate of the basket.

  1. Which items, quantities and prices were in this basket, and was it converted, abandoned or expired?
  2. Which stock reservation, if any, was held for this basket, and for how long?

Checkout

The result of the checkout.

  1. Did this checkout produce a sales transaction or a customer order for later fulfilment?
Sales transaction The completed sale.

Lines and tenders

Balance, origin, corrections and receipts.

Balance

Lines, adjustments, taxes and tenders.

  1. Which lines, adjustments, taxes and tenders make up this transaction, and do they balance?
  2. Which selling location, device and operator recorded this transaction?

Corrections

Voids, receipts and later returns.

  1. Which lines or transactions were voided, by whom and why?
  2. Which receipt was issued for this transaction, and in which form?
  3. Which returns reference this transaction?

Classifiers Filled

Family
Enterprise profiles
Category
Enterprise subject
Entry kind
subject
Domain
EnterpriseRTL
Industry
Retail and e-commerce
Tags
EM-RTL-04W-INDsubjectBasketBasketLineCheckoutSessionSalesTransactionTenderLine

What it is Filled

An online basket or a store basket, the checkout that turns it into a sale, and the completed sales transaction with lines, applied prices, tenders, receipt and voids. Customer orders for later fulfilment and invoices are separate contours.

Why it exists Filled

Keep a complete, balanced record of every sale and its checkout path, so that revenue, tax, stock and customer questions can be answered from it.

Distinguishing features Filled

  • A basket is an intention, while a sales transaction is a completed sale.
  • Transactions balance lines, adjustments and taxes against tenders.
  • Voids are new records that reference the original.
  • Orders for later fulfilment are held in the order contour.

What robots and AI may and may not do Filled

Must not

  • Complete, void or refund transactions.
  • Capture or store payment card data.
  • Contact customers about abandoned baskets without their agreement.

Only with a human decision

  • Voids above a set limit require a supervisor.
  • Suspected fraud is investigated by authorized staff.

May

  • Explain a transaction from its lines and tenders.
  • Flag unbalanced transactions and unusual void patterns for review.
  • Remind a customer of an abandoned basket where the customer has agreed to such reminders.

Moral aspects Filled

  • Basket tracking can turn into intrusive profiling.
  • Monitoring of cashier voids and exceptions must be fair and based on evidence.

Who is affected

  • Customers
  • Cashiers and store staff
  • Payment providers

Owners Filled

Steward

The head of retail operations who answers for sales transaction records.

Master systems

  • Point of sale system
  • E-commerce platform
  • ERP

Links to other meta-models Filled

neighbor

  • EM-COM-03
  • EM-FIN-03
  • EM-RTL-01
  • EM-RTL-03
  • EM-RTL-05
  • EM-RTL-06
  • EM-FIN-07

references

  • WM-ECO-020 - conceptual-candidate
  • WM-ECO-009 - conceptual-candidate
  • WM-ECO-008 - conceptual-candidate

What else AI and robots need to interact with it Filled

Identity and identifiers required Filled

  • A sales transaction is identified by selling location, device, business day and sequence number.
  • An online basket has a session or basket identifier.

Direct properties not applicable Not applicable

Not applicable

Enterprise record contour: physical properties belong to referenced world models.

Recognition required Filled

  • Records show lines, prices, adjustments, taxes, tenders and a receipt.
  • A sales transaction must be distinguished from a customer order, an invoice and a payment.

Capabilities and actions required Filled

  • The contour supports sales reporting, tax reporting, stock deduction and customer service lookups.

Hazards and failure modes required Filled

  • Unbalanced or deleted transactions hide loss and fraud.
  • Payment data kept in the wrong system creates security and compliance risk.

Standards and interfaces optional Filled

  • The Object Management Group maintains the ARTS retail standards, including POSLog, which it took over from the National Retail Federation.
  • Schema.org defines the Order and BuyAction types, and W3C publishes the Payment Request API.

Context of use required Filled

  • The contour is used at store tills, self checkouts and online checkouts.
  • Fiscal receipt rules apply in many jurisdictions.

Sources Filled

  1. ARTS standards (OMG): POSLog for point of sale transactions
  2. schema.org: Order, BuyAction and Offer
  3. W3C Payment Request API: checkout payment interface
  4. Schema.org Order type - Checked live (HTTP 200) on 2026-10-21.
  5. W3C Payment Request API - Checked live (HTTP 200) on 2026-10-21.
  6. OMG Retail Domain Task Force - Checked live (HTTP 200) on 2026-10-21.

Open questions

  • When does a basket become a sale and when a customer order for later fulfilment?
  • How are voids recorded without deleting the transaction?
  • How are tenders split across payment methods and gift cards?
  • Settle the boundary and the reuse, extend or new decision against the current specifications.
  • Confirm the semantic crosswalk, rights and source mastership.
  • Choose immutable references and run fixture checks before claiming publication readiness.

Machine files

Card as JSON Source Card backlog vercy.card/1

Provenance

enterprise research programme · published-partial

Built from: enterprise/models/em-rtl-04/brief.json, ver-cy/world-models/card-supplements/em-rtl-04.json