Haupt-Oberfläche (Web)
Kasse, Backoffice und Admin im Browser; im Server-Abbild unter /admin ausgeliefert
Funktionen · Plattform & Betrieb
Plattformen & Deployment
DiKAS ist dieselbe Software auf sehr verschiedenen Geräten: im Browser auf jedem Rechner oder Tablet, als Android-App, die die Kasse komplett auf dem Gerät mitbringt, als fertige Box beim Kunden im Laden und als Mietbetrieb in der Cloud. Wer im Browser arbeitet, spricht mit einem Server — der steht entweder im eigenen Betrieb oder im Rechenzentrum. Wer die Android-App im Vollbetrieb nutzt, hat den Server im Handy oder Tablet, mit eigener Datenbank, und braucht dafür kein Netz. Dazu kommt die Auslieferungsseite: aus einem einzigen Bauvorgang entstehen das Server-Abbild für die Cloud, das Paket für die Box und die App für das Android-Gerät — und es gibt getrennte Umgebungen zum Testen, zum Vorführen und für den echten Betrieb: Backend, Website und Dokumentation laufen je auf einem eigenen Teststand, der den jeweils neuesten Bauvorgang zeigt, wechseln aber nur nach einer bewussten Freigabe auf die Produktionsseite. Seit der Windows-Version v1 (29./30.07.) läuft dieselbe Software zudem nativ auf einem Windows-Kassen-PC: als Vollinstallation mit eigenem Server oder als reiner Client an einer Hauptkasse — beides über eigene NSIS-Installer.
40 geprüfte Funktionen
Funktionsstand 07.09.2026
Den passenden Betriebsmodus konfigurieren.
Echte Oberfläche
Plattformen & Deployment in DiKAS
Keine Stockmotive: Die Aufnahmen stammen aus den reproduzierbaren DiKAS-Demos und zeigen die jeweilige Funktion im Produkt.
Vollständiger Überblick
Was DiKAS in diesem Bereich kann
Alle folgenden Punkte stammen aus dem gegen den Programmcode geprüften Funktionskatalog.
Kundenportal / öffentliche Seite
Zweite Oberfläche für Konto, Bestellstrecke und Onboarding; im Server-Abbild unter /
Abbild trägt seinen Commit
Die Laufzeit-Stufe des Dockerfile setzt LABEL org.opencontainers.image.revision aus dem Build-Arg GIT_REVISION; die CI füllt es mit $CI_COMMIT_SHA. Damit ist von aussen beantwortbar, welcher Stand in :latest/:live steckt — dikas-ceo/04-infra-scaling/deploy-live.sh --go verlangt seit 07.09.2026 --sha <commit> und vergleicht ihn mit diesem Label (Manifest ⇒ .config.digest ⇒ Blob ⇒ .config.Labels). Bei einem Bau von Hand ohne Arg bleibt es leer, das Skript meldet dann „nicht prüfbar" statt durchzuwinken. ARG gilt nur bis zur nächsten Stufe: liegt zwischen ARG und LABEL ein FROM, bleibt das Label leer, ohne dass der Bau fehlschlägt
Abhängigkeits-Audit im CI (blockierend ab „high")
Zwei Jobs bei jedem Push: dependency-audit fährt dotnet list Dikas.Api/Dikas.Api.slnx package --vulnerable --include-transitive, dependency-audit-npm fährt npm audit --audit-level=high in dikas-next. Beide hängen im needs des Bau-Jobs — eine hohe oder kritische Lücke hält Abbild-Push, Arch-Upload und die vier Neustarts an. Der Weg daran vorbei ist eine begründete Zeile in scripts/audit-ausnahmen.txt (paket | kennung | grund | ablauf=JJJJ-MM-TT), nicht allow_failure; eine abgelaufene Ausnahme rötet den Lauf, auch wenn sich an der Lücke nichts geändert hat. Lokal: bash scripts/dependency-audit.sh --nuget bzw. --npm. Zwei Jobs und nicht einer, weil die Werkzeuge in verschiedenen Abbildern leben (buildnext/dotnet-sdk hat kein npm, buildnext/frontend kein dotnet) — ein Job, der die Hälfte seiner Arbeit still auslässt, wäre genau die grüne Meldung, gegen die das gebaut ist
Android-App mit eingebautem Server
Die App hostet die komplette API auf dem Gerät (EmbedIO) samt eigener Datenbank
Betriebsrolle beim App-Start
Startdialog: Vollkasse mit Lizenz, Client an einem Server, Demo oder Blütooth-Kundendisplay
Andere Geräte am App-Server
Weitere Geräte im WLAN verbinden sich per Browser auf den App-Server
Server-Suche in der Android-Client-App
Der Verbindungsdialog kombiniert lokale Avahi/mDNS-Treffer (_dikas._tcp) mit den für das aktuelle Standortnetz von dikasvpn gemeldeten Servern. Beide Quellen werden nach IP dedupliziert; Registry-Antworten ohne gültige IP werden verworfen. Bei Fehlern bleiben Avahi, Cloud-Fallback und manuelle Adresse verfügbar.
Disco-Kunden-Checkout (Gästestrecke)
Öffentliche, anonyme Ausgangs-Strecke für Disco-Gäste: Ausgangs-QR, Web-NFC-Kartenlesung (Chrome/Android), Stripe-Restzahlung und Freigabe erst nach finaler Serverantwort. Läuft in dikas-web; die frühere getrennte Capacitor-App apps/disco-checkout ist am 20.08.2026 entfernt worden (siehe Falle in Disco & Club).
Client-Shell (Android)
Schlanker WebView-Client auf einen externen Server, mit NFC-Brücke ins Web
Geräte-Agent (Android/iOS)
Begleit-App für Kamera-Scan, Standort, Kompass — als eigenständiges Projekt obsolet, Rollen sind in die Haupt-App gewandert
Server-Abbild (Container)
Ein Abbild mit beiden Oberflächen und dem Backend; Grundlage für Cloud und Testsysteme
Appliance-Paket (Box/ISO)
Aus demselben Abbild gebautes Systempaket, läuft als Dienst auf Port 3040. Das optionale lokale Demo-Seed-Modul wird aus dem Paket entfernt: „DiKAS testen“ in dikasarch verwendet einen frischen Cloud-Testmandanten; lizenzierter Lokalbetrieb und Sync brauchen das Modul nicht. Der Abbild-Bau entfernt außerdem den eingecheckten alten SPA-Stand aus dem temporären Backend-Publish, bevor Portal und Kasse frisch hineinkommen.
Windows-Dienst
Dasselbe Backend läuft als Windows-Dienst; Browser-Autostart nur bei interaktiver Sitzung
Windows-Installer (Vollinstallation)
DiKAS-Setup.exe (NSIS, unsigniert): registriert dikascore als Dienst „DikasNext" (HTTPS 443, intern 3040), startet ihn auf einer Frischinstallation aber erst nach erfolgreicher Lizenzierung; Hardware-Agent „DikasArch" + Electron-Shell laufen für die Lizenzmaske. Daten unter %ProgramData%\dikas; Ja/Nein-Abfrage aktiviert den Faktura-Offline-Modus.
Windows-Erstimport aus dem Kundenbestand
Nach der Lizenzierung wird eine neue SQLite-DB zuerst im Nur-Download-Modus aus der lizenzierten Cloud-CouchDB befüllt. Lokale Baseline und Zufalls-Admin bleiben dabei aus; erst nach nachgewiesenem Pull wird der normale bidirektionale Sync freigegeben. Ohne Erst-Sync-Marke gilt die Installation nicht als fertig.
Windows-Client-Setup (Thin-Client)
DiKAS-Client-Setup.exe (NSIS): nur die Electron-Shell mit Verbinden-Dialog (manuelle Adresse, Merken, Trennen); lädt nur echte DiKAS-Server — Gate GET /version als Portierung der MAUI-Prüfung
Windows-Releaseverwaltung
Baut Master und optional Thin-Client aus temporären DiKAS-/DikasArch-Worktrees, prüft Setup, ASAR, Feed-Signatur und Hash und verbucht den Versionsstand je Version mit Kanal (beta/main) ausschließlich im DiKAS-Repo. Zweistufig seit 28.08.2026: beta (Build + Upload nur in den Beta-Kanal) und promote (Beta -> main ohne Neubau, mit Kanalprüfung); release = beide ohne Soak. Der Upload-Key geht per curl --config - auf stdin, nicht als Argument. Vorprüfung verlangt DiKAS-HEAD == origin/main und sauberes Arbeitsverzeichnis (--allow-local als sichtbarer Override); die öffentlichen Downloads werden erst nach der Kanalprüfung kopiert. Vorher ist ein dokumentierter Audit aller nicht gemergten DiKAS-/DikasArch-Branches Pflicht; die Kundenfreigabe verlangt zusätzlich einen echten Windows-Lauf.
NFC im Windows-Client (Electron, T12)
Die Client-Shell exposed per Preload-Bridge window.dikasNfc (Push via IPC): Karten-ID und Leser-Status kommen vom Main-Prozess — Baltech seriell aktiv, PC/SC erst ab T8 (Windows-Runner-Build); im Frontend konsumiert sie der NfcService (Block 2.6) — ohne Bridge bleibt alles beim HTTP-Pfad
Lokales HTTPS auf Box und Windows (443)
Standort-CA zehn Jahre, Serverzertifikat 90 Tage, Erneuerung ab 30 Tagen oder sofort bei SAN/IP/CA-Wechsel oder wenn cert.pfx nicht von der Standort-CA stammt (Self-signed-Fallback). Linux aktiviert Generationen atomar für Nginx; Windows lädt Kestrel dynamisch neu und installiert die CA in LocalMachine\Root. Bestehende Nginx-Protokolle/Cipher bleiben für Altgeräte unverändert
Zertifikats-Einrichtung
Öffentliche Seite mit QR-Code, CA-/Apple-Profil-Download, Fingerprints, SANs und HTTPS-Test; DikasArch-Einstellungen zeigen Status und erlauben den lokalen manuellen Abgleich
Vertrauen mehrerer Betriebe im Electron-Client
Speichert Standort-CA-Fingerprints pro Betrieb; Erstkontakt und Änderung erfordern sichtbare Bestätigung, andere Betriebe bleiben erhalten. Altserver ohne CA-Endpunkt nutzen befristet den Legacy-Fallback
Bauen & Ausliefern (CI)
Ein durchgehender Release-Job: beide Frontends im Docker-Build testen, genau diesen Stand als Abbild bauen und pushen, daraus das Appliance-Paket erzeugen und hochladen, danach Testsysteme neu starten; Backend-Vollsuite bewusst lokal vor dem Merge
Zwei-Stand-Modell (:latest/:live)
Jeder Bauvorgang auf dem Hauptzweig ist sofort auf den Testsystemen sichtbar (:latest); die Produktion bleibt auf einem manuell bestätigten Stand (:live) stehen, bis eine bewusste Freigabe sie umzieht
Getrennter Vorschau-Betrieb für Dokumentation
Ein eigener Teststand zeigt den jeweils neuesten Dokumentationsstand, bevor er für Kunden sichtbar wird — vorher lief ein einziger Betrieb, jede Änderung war sofort live
Demo-Startseite
Der Vorführbetrieb ist neben den Subdomains je Vorlage auch direkt über eine eigene Startseite erreichbar
Feature-Module zur Laufzeit
Zusatzmodule werden als DLL bzw. .feature-Paket geladen, nicht mitkompiliert
Alle Zusatzmodule kommen ins Server-Abbild
Der Abbild-Bau liest die Modulprojekte aus dem Quellbaum, statt eine Liste zu pflegen — ein neues Modul ist damit automatisch beim Kunden
Modul-Auskunft an die Oberfläche
Sagt dem Frontend, welche Module wirklich geladen sind; abgeschaltete verschwinden
Modul-Schalter im Server
Zentraler Hebel: disabledModules sowie Umgebungsschalter für Lizenz-, Ketten- und Tabellen-Modul
Domain-/Umgebungs-Konfiguration
Mandanten- und Gäste-Domain deploymentweit konfigurierbar (Prod dikas.de, Test nx9.de)
Testauftritte aus dem Suchindex (X-Robots-Tag)
Jede Antwort an nx9.de/.nx9.de trägt seit 28.08.2026 X-Robots-Tag: noindex, nofollow; weitere Testinstanzen ohne nx9-Adresse setzen Hosting__NoIndex=1 am Deployment. Bewusst eine Positivliste, kein „alles außer dikas.de" — sonst fielen dikas.ch/dikas.es beim nächsten Start still aus dem Index. Der Header hängt NICHT am CSP-Schalter der Sicherheitsheader
Hintergrunddienst anlegen (Mandantenmodus)
Jeder Hintergrunddienst wird über EINE Fabrik registriert und sagt dabei, wie er zur Mehrmandanten-Cloud steht: JeMandant, NurEinMandant(grund) oder MandantenfreiGlobal(grund). Ein Ein-Mandant-Dienst läuft auf einer Cloud-Instanz gar nicht erst und steht dort namentlich als „übersprungen" im Startprotokoll
Umgebung erkennen
GET /version liefert Version, Umgebung, Datenbanktyp, Demo-Kennzeichen und Fiskalland
Lebendigkeits-/Bereitschaftsprüfung
GET /healthz und GET /ready für den Betrieb im Cluster
Demo-Umgebung je Subdomain
Pro Demo-Subdomain eine eigene Datei-Datenbank aus einem Vorlagen-Stand, automatisch aufgeräumt; der Branchenwechsel behält auch beim Einstieg über die nackte Basisdomain die Testumgebung (test.dikas.de → <branche>-<id>.test.dikas.de)
Cloud-Zusatzdienste
Geokodierung und Routing als eigene Container neben dem Hauptdienst
Route-Gleichstand Cloud ↔ Gerät
Prüft, dass jede Server-Route auch auf dem Gerät existiert oder bewusst als „nur Cloud" eingetragen ist
Entwickler-/Testbetrieb lokal
Backend und Oberfläche lokal starten, Demo-Kasse mit Datei-Datenbank
Aufräumen der Bau-Registry
Nicht mehr gebrauchte Container-Abbilder aus früheren Bauvorgängen werden aus der internen Registry entfernt, damit dort dauerhaft Platz für neue Abbilder bleibt
Kein Treffer in diesem Bereich. Gesamte Website durchsuchen
Oft gesucht
Begriffe rund um Plattformen & Deployment
noindexX-Robots-TagSuchindexGooglePlattformAppAndroidAndroid-AppAPKAABPlay StoreiOSWindowsWindows-DienstWebBrowserSPATablet