Documentation on Strichliste ‒ The Tally Sheet Replacement for Your Organization

Configuration

Fri, 12 Jun 2026 09:00:00 +0200

All application-level behavior is configured in one file, config/strichliste.yaml, under the parameters.strichliste key. The same values drive the web UI and are exposed verbatim to API clients via GET /api/settings.

Applying changes:

Bare metal: edit the file, then php bin/console cache:clear.
Docker: bind-mount your copy into the app service — the entrypoint recompiles the cache on every boot, so a restart applies it. See the README section “Settings without rebuilding” for the exact snippet.

Two recurring datatypes:

Console commands

Fri, 12 Jun 2026 09:00:00 +0200

Run with php bin/console … — inside Docker:

docker compose exec app php bin/console …

Command	Purpose
`app:import <file>`	Import a strichliste 1 `database.sqlite`. Wipes the target database first.
`app:user:status <user> <true\|false>`	Enable/disable an account by name or id.
`app:user:cleanup`	Bulk-disable accounts inactive for longer than an interval.
`app:retire-data`	Delete transactions older than an interval — the data-privacy tool.
`app:ldapimport`	Create/update users from an LDAP directory (cron-able).
`cache:clear`	Apply `strichliste.yaml` changes (bare metal; the Docker entrypoint does this on boot).
`doctrine:migrations:migrate`	Apply schema migrations (automatic in Docker).

Import a strichliste 1 database

php bin/console app:import database.sqlite

This wipes the target database first — all existing users, transactions and articles are deleted — so only run it on a fresh install. It imports users and transactions; the product list is entered by hand afterwards. After the import the terminal outputs “Import done!”.

REST API

Fri, 12 Jun 2026 09:00:00 +0200

The /api/* endpoints are stable — existing clients keep working unchanged. The API is documented as an OpenAPI 3 specification served by the application itself:

/api/doc — interactive Swagger UI on your own instance (browse endpoints, try requests — mind that “Try it out” executes real bookings).
/api/doc.json — the raw OpenAPI document, ready for code generators or Postman/Insomnia import.

Essentials

Amounts are integer cents; timestamps are YYYY-MM-DD HH:MM:SS.
Request bodies may be JSON or form-encoded. JSON bodies require Content-Type: application/json — without it the body is silently ignored and you get a confusing “parameter missing” error.
Errors use one envelope, where class is the PHP exception class name clients switch on:

{"error": {"class": "App\\Exception\\TransactionBoundaryException",
           "code": 400, "message": "Transaction boundary reached"}}

Pagination is uneven (kept for compatibility): /api/transaction, /api/user/{id}/transaction and /api/article accept ?limit=…&offset=… with a default limit of 25 — forget limit and you silently see only 25 rows. GET /api/user ignores both and always returns all users. The /search endpoints accept limit only.
No idempotency mechanism: retrying a timed-out POST …/transaction books twice. Reconcile via GET /api/user/{id}/transaction after network errors.
No webhooks/push: to watch for new bookings, poll GET /api/transaction.
User routes accept a numeric id or the exact name (GET /api/user/alice); the transaction routes take numeric ids only.
There is no authentication — the API trusts the network like the kiosk trusts the room. CORS is deliberately wide open and there are no rate limits. Both are consistent with the trusted-network model — and more reasons not to expose it publicly.

The two calls every integration makes

# deposit 1.00 € with a comment
curl -X POST http://server/api/user/4/transaction \
  -H 'Content-Type: application/json' \
  -d '{"amount": 100, "comment": "cash box"}'

# buy an article (server computes the price; amount must be omitted
# or negative — sending a positive amount with articleId is rejected)
curl -X POST http://server/api/user/4/transaction \
  -H 'Content-Type: application/json' \
  -d '{"articleId": 3, "quantity": 1}'
# → {"transaction": {"id": …, "amount": -150, "article": {…}, …}}

The scanner-script recipe (e.g. for a serial scanner or vending machine): GET /api/article?barcode=<scan> → take articles[0].id → POST /api/user/{id}/transaction with {"articleId": …}.

The screen by the fridge

Fri, 12 Jun 2026 09:00:00 +0200

The server is half the job — the other half is the screen by the fridge. strichliste’s part is ready: big touch buttons, works without JavaScript on weak hardware, a dark theme that follows the device, and a screen that returns to the user list when idle. Setting up the device itself is up to you.

Hardware

A Raspberry Pi 4/5 with a 64-bit OS runs server and fullscreen browser at once (4 GB RAM comfortably; 2 GB if the server runs elsewhere). Older 32-bit Pis: run the server elsewhere and use the Pi only as a browser terminal. Any old tablet pointed at the server works too — the UI works without JavaScript, so even ancient browsers hold up.