Point of sale
The record of what was actually sold, in store, at the moment it happened.
01 What it holds
The data inside it
Line-level transactions by store, terminal, hour and operator, plus tender, discount and void events that describe how the sale was made.
Transaction / Check, Line item, Store, Terminal, Operator, Tender, Discount, Void, Daypart
02 Getting the data out
Extraction, and the keys that decide whether it joins
Batch end-of-day files remain common; modern estates stream per transaction. Store connectivity is the constraint, so late and replayed files are normal operating conditions.
Transaction identifiers are usually unique only within a store and a business date. Business date is not calendar date once trading passes midnight, and getting that wrong shifts a night's trade into the wrong day.
03 What goes wrong
The failures that look like success
Each of these produces a number that is plausible, reconciles to something, and is wrong. They are worth reading before the first extract, not after the first dispute.
Business date versus calendar date
Late-night trading is booked to the previous business day. Ignoring it makes weekend comparisons meaningless.
Store files arrive late or twice
Any pipeline must be idempotent and must report which stores have not reported, or like-for-like sales quietly understate.
Discounts and voids carry the story
Operator-level discounting and void patterns are both a margin issue and a loss prevention signal, and they are usually discarded during extraction.
Item identity differs from the master
Store-level buttons and local items drift from the article master, so category reporting silently loses lines.
04 Joins that matter
What this system is worth joining to
| Join to | What it lets you answer |
|---|---|
| ERP / merchandising | sell-through against cost price and margin plan |
| WMS and replenishment | availability at the shelf rather than stock at the depot |
| Loyalty | attaching a transaction to a known customer |
05 Metrics it feeds
The numbers that come out of it
06 Questions
Frequently asked
Why join POS to stock data rather than reporting each separately?
Because the biggest loss in retail — the sale that did not happen — has no transaction. It can only be inferred from expected sell-through against actual, at store and article level.
Is per-transaction detail worth keeping?
Yes. Basket composition, daypart and operator behaviour are only available at line level, and they are exactly the analyses that change merchandising and loss prevention.
Connect this system without replacing it
SCIKIQ reads it in place, resolves the entities inside it and governs what the fields mean.