Inventory management · Till · Till security

Kontor – inventory management for retail

Inventory management for a sports shop: items, customers, documents, till with TSE, ski rental, workshop, stocktaking. Replaces a twenty-year-old system with the same way of working – only with the record-keeping that applies today.

Modules The till screen Till and TSE Architecture
In development · switchover prepared, not yet carried out
ONE ENTRY POINT · 198 ROUTES ROUTE TABLE · MODULE + PERMISSION PER ADDRESS Items Customers Documents Till · TSE · DSFinV-K Rental Workshop Stocktaking Stock Reports Business logic · posting in one transaction, locked afterwards DATABASE · 92 TABLES Movement row per stock change Log row per write access BACKUP Checksum, restore test ARCHIVE CSV per table, verifiable Training mode · warning register · go-live approval · 132 test classes

The till screen

It is read standing up, at an angle from the side, and operated with a finger. The till window therefore has its own set of dimensions.

Checkout · dark theme
TILL Till 1 Timo B. 21:49 Dark Tools Scan or enter barcode — Enter Return Men's hiking boot Size 42⅔ − 1 + 149.95 € 149.95 € × Ski service, large Item — price from tag − 1 + 39.90 € 39.90 € × Running socks Size 39–41 − 1 + 14.95 € 13.46 € × −10 % discount TO PAY CHANGE 203.31 € — 3 items · 3 pcs · discount 1.49 € Keypad edits: — 789 456 123 ,0 Cash tap, then type Card (debit) tap, then type exact5 €10 € 20 €50 €100 € Check out DISCOUNT ON SELECTED LINE −5 %−10 % −15 %−20 % Ski serviceSnowboardVoucher more …
3Themes per user account
7Stages per sale
4Variants of the TSE connection

Modules

One entry point, one permission check, shared building blocks for lists, forms and printouts.

Modules by role
MASTER DATA TRANSACTIONS TILL RECORDS Items and prices Master record, price list, barcode history Customer file Addresses, phone numbers, duplicates Customer cards Issue, assignment, blocking Stock and inventory Movement row per change Product groups Tree, assignment, rules Master data and permissions Branches, tills, staff Staff and ID cards Profile, ID card printing with barcode Service catalogue Services, labour units, codes Documents AB · WE · WA · FUM · RE · INV Ski rental Availability check, calendar, contract Workshop · Tennis · Complaints shared order model Stocktaking Count sheets, interim stocktaking Vouchers Issue, redemption, expiry Trade-fair sales Branch with an end date Customer registration Form for customers, then checked Returns from mail order Reconciliation with the online system Checkout Basket, discount, parking, receipt Payment methods Cash, card, voucher, mixed End-of-day closing Z report, cash count record, difference TSE connection four drivers, one conformity verdict Checkout lock per transaction, § 146a AO Training mode without stock or reporting Order checkout Check out a workshop order directly Cash book and cash count Number, reversing entry, count DSFinV-K export 20 CSV, index.xml, DTD Process documentation maintained with the code Backup Manifest, restore test Annual archive offload, verify, restore Warning register Warnings with evidence Go-live approval Checkpoints with verdict Interface for the tills Receipt import per terminal, keys Findings log Finding with history and closure ACROSS ALL MODULES Permission level per route · log row per write access · movement row per stock change · cancellation instead of alteration · pagination in every list

Till transaction

Seven stages. Two of them – posting authorisation and signature – come from § 146a AO.

Sequence of a sale
1 · Capture Barcode, quantity, discount, sale can be parked 2 · Check price Master price against document records 3 · Checkout lock Posting authorisation per transaction 4 · Sign Start TSE transaction and finish it 5 · Post one transaction, locked afterwards Signature unit failed Failure documented, note on the receipt 6 · Print receipt Mandatory details, tax per rate, signature field 7 · Stock and queue Movement row, outbound message queued End-of-day closing Z report, cash count record, difference If the signature unit fails, checkout continues. The failure is documented and noted on the receipt.
Conformity and posting authorisation are two separate questions
QuestionAnswer comes from
Does the till comply with § 146a (1) AO? Serial number, access credentials, reachable remote endpoint, registered till. A serial number without access credentials counts as non-compliant.
May this transaction be posted? Training posting, approved emergency sale or compliant till. An approval does not change the conformity status.

Previously, eleven places in the code answered the same question, some with differing conditions. Today there is one class for each.

Cash-register law

Most of the effort goes into record-keeping, not into the checkout itself.

RequirementImplementation
Individual recording § 146a AO Every transaction signed, every call logged.
Failure documentation In the event of a fault, checkout continues and the failure is noted on the receipt.
Immutability GoBD Database triggers reject UPDATE and DELETE. Corrections only by cancellation.
Proof of integrity GoBD para. 107 ff. Hash chain over the log, position assigned by the database, with a final seal.
Cash book § 146 (4) AO Withdrawals, deposits, bank runs with their own number. Typing errors are reversed by a counter-entry.
Digital interface DSFinV-K 20 CSV files, index.xml and DTD, checked in-house before submission.
Retention Annual archive as CSV per table with record description and checksums.
Mandatory details § 14 UStG One layout for all document types. Missing details are shown on the document.
Data protection Permission levels per module, checked centrally. Empty customer records are deactivated.
Why the hash chain was built twice

Two tills posting at the same time caused the chain to fork and triggered a false alarm. That was the real danger: a check that regularly goes off for no reason stops being read. Today the database assigns the chain position, and a final seal closes the chain – which also means that cutting off the last rows is noticed.

Data quality in the inherited records

The legacy data comes from a system without input validation. The checks work in two stages: record the finding, cross-check against the document records, and correct only when the result is unambiguous.

  • Price check. Selling prices against the actual document records. Corrections are made only where they agree.
  • Impossible amounts. Barcode values in the price field, detected by their distance from the item master data.
  • Customer file. Names, addresses and phone numbers standardised, duplicates merged.
  • Warning register. All warnings in one place, each with origin, severity and evidence.
  • Training mode. Practice postings reach neither stock nor reports.

Architecture

PHP 8.1 and MySQL, rendered on the server. No framework, no build, no third-party packages. All figures describe the program code, as of 16 August 2026.

653own PHP files
232,253lines of source code
198routes with permission level
0third-party packages
service classes172
screen templates161
test classes132
versioned schema steps96
command-line tools93
tables92
controllers38
The layers in detail
Entry pointFront controller with route table. Module and permission level are attached to the address and checked centrally in the router.
CoreDatabase wrapper, login, session, CSRF protection, views, pagination, audit log, own PSR-4 autoloader.
Business logic172 service classes by subject area, from the till to the legacy data migration.
Views161 templates, every output escaped. Print views instead of PDF generation.
Database92 tables, prepared statements throughout, 96 versioned schema steps, 24 triggers against modification.
Tools93 command-line programs for migration, reconciliation, diagnostics, backup, archive and deployment.
Decisions I have to justify
  • No framework, no build. The target environment is ordinary web hosting. Without third-party packages, no dependency chain ages.
  • One write path. The checkout screen, too, posts through the same checked service as the till interface.
  • Number assignment with locking. SELECT … FOR UPDATE, so that concurrent transactions never receive duplicate document numbers.
  • Server-side pagination. 50 rows per page with a separate count query. The effort stays independent of data growth.
  • Long runs as a separate process. Backup and data checks report progress; the interface does not wait.
What is checked before anything starts
  • Go-live approval. Checkpoints covering environment, database, access, data migration and till. Read-only, each point with a measured value and a reason.
  • 132 test classes with its own test runner, no third-party packages.
  • Protection of the test environment. Three checks before the connection is made, so that no test ever touches the live data.
  • Contrast check. Both themes are calculated against WCAG 2.1, separately for body text, large text and controls.
  • Process map. All processes as a diagram; a test holds the map against reality, in both directions.

Status

Not in live operation. The switchover will take place after full go-live approval.

Foundation and modulesDone
Till security and DSFinV-KDone
Immutability in the databaseDone
Cash book, cash count, findings logDone
Till screen and design rulesDone
Data quality and training modeIn progress
Data migration from the legacy systemIn progress
Connection to the online shopOpen – the write path is deliberately closed
Connect signature unitsOpen – until then the system states that no signing takes place

This page contains no business data, no screenshots from the live records and no sales figures. All figures describe the program code. The project is shown with the consent of Muskelkater Sport Köln. The self-check in the system is not legal advice.

Who it is built for

Target groupRetailers where sales, rental and workshop come together.
StatusIn development, not in live operation.
AvailabilityNot a finished product. For a business with a similar profile, a custom implementation is conceivable.

Contact

Questions about the construction, the decisions behind it or how it could carry over to another case.

Arithmetic check Arithmetic task, shown as an image

No Google captcha, no cookies, nothing passed to third parties. Prefer e-mail? info@timobritz.de.