Funktionen · Plattform & Betrieb
Hier geht es darum, wie Daten zwischen der Kasse im Betrieb und der DiKAS-Cloud hin- und herwandern, wie sie gesichert werden und wie ein neuer Kunde seine Daten aus einem alten System mitbringt. Die Kasse vor Ort arbeitet auch ohne Internet weiter und gleicht sich ab, sobald die Verbindung wieder da ist; umgekehrt reicht die Cloud Dinge, die nur vor Ort passieren können — Bondruck, Beleg signieren — an die Maschine im Laden durch. Die Sicherung läuft automatisch im Hintergrund über die Cloud, es gibt nichts herunterzuladen und nichts zu verwalten. Für versehentlich gelöschte Artikel, Warengruppen und Kunden gibt es einen Papierkorb im Programm. Und wer von einem anderen Kassensystem kommt, wird durch einen Umzugs-Assistenten geführt, der den gesetzlich vorgeschriebenen Datenexport des Altsystems einliest.
Sicherungen kontrolliert wiederherstellen.
Echte Oberfläche
Keine Stockmotive: Die Aufnahmen stammen aus den reproduzierbaren DiKAS-Demos und zeigen die jeweilige Funktion im Produkt.
Vollständiger Überblick
Alle folgenden Punkte stammen aus dem gegen den Programmcode geprüften Funktionskatalog.
Nimmt Fehler-Batches von Appliances an und schreibt sie nach Loki. Frische Zeitstempel bleiben unverändert; Ereignisse außerhalb des Loki-Aufnahmefensters erhalten für die Einspeisung die Empfangszeit und behalten den echten Zeitpunkt als originalTimestamp, damit ein alter Store-and-Forward-Batch nicht dauerhaft mit 503 festhängt
Beantwortet „alle Buchungen zu DIESER Rechnung", „alle Journalzeilen zu DIESEM Bankumsatz", „alle offenen Bons DIESES Tisches / DIESES Lieferauftrags" über einen Index statt über einen Vollscan. CouchDB: View byfield (Schlüssel [DocumentType, Feld, Wert]), SQL: Spaltenfilter. Abfragbar sind nur die deklarierten Felder aus IndizierteFelder — ein anderes Feld wird mit ArgumentException abgewiesen, weil der View es nicht indiziert und die Antwort sonst still leer wäre
Jede Änderung an IndizierteFelder ändert den Map-Text und braucht deshalb ein Hochzählen von CouchDbInitService.ByFieldDesignDocVersion — sonst bleibt der alte Index stehen und die neu deklarierte Frage liefert still nichts. Stand 7 (v1: BankTransaction.InvoiceId/StatementId, PaymentJournal.BankTransactionId · v2: OpenBon2/OpenBon mit TableId→SourceId und DeliveryOrderId · v3: DeliveryOrder.ExternalOrderId · v4: OpenBon2/OpenBon zusätzlich mit DepositForBonId und BonId · v5: CustomerInvoice.InvoiceNumber, beim Zusammenführen der Wellen 8 und 9 von 4 auf 5 gehoben — zwei Zweige führten die Zahl unabhängig auf 4 · v6: StockTake.StockId und StockBooking2/StockBooking mit SourceId, Etappe L2 des Lager-Konzepts — erster Stock-Typ im Index überhaupt · v7: SerializedItem mit SerialNumber und ArticleId, Etappe W3, beim Zusammenführen der Welle 19 von 6 auf 7 gehoben — L2 und W3 führten die Zahl unabhängig auf 6, wie schon die Wellen 8/9 auf 4). Im selben Zug ging ByStatusDesignDocVersion von 1 über 2 und 3 auf 4 (v2: StockBooking2/StockBooking mit Status, Etappe L2 — die erste Änderung dieser Map, seit sie aus IndizierteFelder erzeugt wird; v3: SerializedItem.Status, Etappe W3, in Welle 19 aus demselben Grund von 2 auf 3 gehoben; v4: DeliveryNote.Status, Etappe W4, in Welle 20 von 3 auf 4 gehoben — der Zweig liess die Zahl bewusst auf seiner Basis 2 stehen, weil Welle 19 sie schon auf 3 zog und zwei Anhebungen derselben Zahl in zwei Zweigen wieder 3 ergeben hätten; die Lieferscheinliste fragt ohne Filter über bystatus und wäre sonst lautlos leer). Ein Deploy kostet damit den Reindex von zwei kleinen Design-Dokumenten. Der Zustand eines Geräts läuft über bystatus und nicht über byfield: dessen Map emittiert nur bei if (doc.<Feld>), und AufLager ist 0 — ausgerechnet der Bestand wäre lautlos aus dem Index gefallen. Der Sprung kostet ein Reindex nur des byfield-Index, je Mandanten-DB, in maindb und gastrocurrent; die Großen n-data-Views bleiben unberührt. Bis der Index steht, greift der Rückfall GetAllAsync + Filter — korrekt, nur langsam. Führen zwei Zweige dieselbe Zahl, geht der Merge eine höher — sonst bekommt eine der beiden Feldlisten keinen Index und antwortet still leer.
Beantwortet die vier Zählfragen der Lizenz-/Kontingentwächter — wie viele Belege, wie viele Verkaufsbelege, wie viele Rechnungen im Fenster, wie viele Anhangs-Bytes —, ohne die gezählten Dokumente zu laden: _sum-Reduce der kontingent-View (_design/kontingent, v1) auf CouchDB, COUNT() auf dem DbContext bei SQL. Der RepositoryKontingentZähler (Vollscan) ist Referenz und Rückfall. Bewusst ein eigenes Design-Dokument und bewusst kein Warmup: CouchDB baut einen View erst bei der ersten Abfrage, und die stellt nur ein Mandant, den einer der vier Wächter betrifft — eine lizenzierte POS-Installation zahlt dafür nichts. Neue Zählfrage ⇒ Fachregel in RepositoryKontingentZähler, COUNT() im SqlKontingentZähler, Schlüssel in der Map, KontingentDesignDocVersion hoch, Paritätstest.
IndizierteFelder führt je Feld beide Namen: Eigenschaft ist der C#-Name — damit fragen die Aufrufer, damit filtern SqlRepository (EF.Property) und der In-Memory-Rückfall, und unter ihm steht das Feld im View-Schlüssel; JsonFeld ist der Name, unter dem der Wert im CouchDB-Dokument wirklich liegt, und nur den liest die View-Map. Nötig, weil OpenBon.TableId im Dokument SourceId heißt (dikas3-Vokabular)
Der Zeitraumweg liefert seit 06.09.2026 nur die AKTIVEN Dokumente — derselbe Massstab wie GetAllAsync (Owner-Entscheid 10.07.2026). Wer die soft-gelöschten ausdrücklich braucht, nimmt GetByBusinessDateRangeAndDeletedAsync, das Gegenstück zu GetAllAndDeletedAsync (heute ohne Produktionsaufrufer). Gefiltert wird im Repository, nicht in der View-Map: bybizdate emittiert weiterhin auch Gelöschte, damit der AndDeleted-Weg etwas zu liefern hat und kein Reindex nötig wird ()
IndizierteFelder sagt, welches Feld bei welchem Dokumenttyp der „Status" ist (CustomerInvoice.Status, BankTransaction.MatchStatus). Daraus wird die JavaScript-Map des bystatus-Views erzeugt, und daraus lesen SQL-Filter und In-Memory-Rückfall denselben Namen
Schalter je Registry-Zeile: der Dokument-Cache gibt bei diesen Typen eine Kopie statt der geteilten Instanz heraus, und ein Speichern legt ebenfalls eine Kopie ab. Damit greift die optimistische Sperre auch innerhalb EINES Pods — zwei gleichzeitige Vorgänge halten nicht mehr dasselbe Objekt, der zweite bekommt den Konflikt (409) statt lautlos zu überschreiben. An für: Beleg, Rechnung, Kunde (Saldo), Zahlung, Kundenkonto-Buchung, Gutschein, offener Bon, Abo. Standard ist aus — bewusst je Typ und nicht global (eine Kopie kostet gemessen 17,6 µs bei einem Kunden und 104 µs bei einem Beleg mit 30 Positionen, bei 1 313 GetByIdAsync-Aufrufstellen)
Zählt je Dokumenttyp, wie oft der Cache getroffen und wie oft aus der Datenbank gelesen wurde (prozessweit, alle Mandanten dieses Pods summiert, ohne Protokollzeile je Zugriff). Exponiert auf /metrics als dikas_repo_cache_hits_total{type=…} und dikas_repo_cache_misses_total{type=…}. Zählweise: EINE Nachfrage am Cache = EINE Zählung (der Listen-Cache wird einmal befragt, nicht einmal je Dokument)
Führt jeden Endpunkt, der ohne Anmeldung erreichbar ist, mit Route, Verben, Riegel, Zweck, Grund und Prüfstelle — Stand 07.09.2026: 298 in 78 Controllern, 159 davon schreibend. Die Liste wird per Reflexion über die Controller-Assemblies GEMESSEN, nicht gesammelt; der Wächter hält sie deckungsgleich mit dem Code, sodass ein neuer anonymer Endpunkt rot wird, bis jemand Riegel und Grund hinschreibt. Riegel aus geschlossenem Vokabular (drossel:, modul:, schalter:, apikey, geheimnis:, signatur:, herkunft:, sperre:konto, freigabe:admin, zustand:, lesen-öffentlich, offen:); alles, was ein Attribut IST, wird in beide Richtungen geprüft. Ein schreibender anonymer Endpunkt ohne Riegel geht nicht durch — offene Fälle tragen offen:<nr>, stehen als Owner-Frage in der Datei und sind gedeckelt
X-Content-Type-Options: nosniff, Referrer-Policy: no-referrer, Permissions-Policy (Standort, Mikrofon, USB, Serial, Blütooth, Sensoren aus), CSP als Report-Only (Erzwingen über Security:ContentSecurityPolicy:Enforce), X-Frame-Options: DENY nur im Erzwingen-Modus, X-Robots-Tag: noindex nur auf Testauftritten. CORS: Standard-Politik nur konfigurierte Ursprünge mit Zugangsdaten, OnlineShop jeder Ursprung ohne Zugangsdaten, PartnerDirectory gezielte Liste, nur GET. HSTS setzt die Anwendung bewusst NICHT — die Appliance liefert auf ihrem internen Port planmässig HTTP aus; die Kopfzeile gehört an den Ingress. Der Wächter hält die Abwesenheit fest, damit die Entscheidung sichtbar bleibt
Hält ausgewählte Datenarten zwischen lokaler Datenbank und zentraler Cloud-Datenbank gleich; Konflikt: die jüngere Änderung gewinnt
Hält pro Mandant genau eine Standort-CA unter local-site-pki; CA-Key AES-256-GCM-verschlüsselt, DEK per HKDF aus dem SyncKey gewrappt, 30-Tage-Übergang beim Rewrapping. Paralleles Erzeugen übernimmt immer das vorhandene Gewinner-Dokument. Signiert nur lokale Namen (einlabelig, .local, private/Loopback-Adressen; sonst 400); neue CAs tragen kritische Name Constraints + pathLen 0 (Status nameConstrained). Seit 28.08.2026: Sync-Key-Wechsel (Aktivierung, Offline-Lizenzcheck) wrappt den DEK über ISyncKeyChangeHandler VOR dem Speichern um; Status trägt dekReadable/dekProblem; import-classic mit replace + replaceGenerationId ersetzt die vorhandene CA im selben Dokument (neue Generation, sonst 409)
Artikelbilder, Bon-Logo, Rechnungsvorlage und Personalfotos wandern mit dem zugehörigen Dokument in beide Richtungen
Dauerhafte Push-/Pull-Replikation der lokalen CouchDB gegen die Cloud (Alternative zum Poll-Sync, nur Einzelplatz-Installation). Bei einer migrierten, lokal schreibenden dikas-next-Kasse ist Push+Pull zwingend; ein alter Sync__PullOnly=true-Override wird automatisch ignoriert
Zustand, letzter Lauf, LAN-Nachbarn; Sync von Hand auslösen
Prüft beim Start DIKAS_REPLICAS/Hosting:Replicas gegen DistributedLock:RedisConnection, SignalR:RedisConnection und (seit 07.09.2026) Idempotenz:Speicher=Redis; bei >1 ohne jeden gemeinsamen Speicher eine LogCritical-Zeile plus Console mit der vollständigen Liste der dann wirkungslosen Mechanismen, Kennzahl dikas_next_process_local_state_risk (1/0). Seit 07.09.2026 zusätzlich eine LogWarning im Zwischenzustand: replicas > 1, ein Teil geteilt, der Rest nicht — vorher schwieg der Wächter dort vollständig, und dikasnext-test fällt genau darunter (SignalR-Backplane seit 11.07.2026 gesetzt). Die Zahl der noch prozesslokalen Mechanismen steht als dikas_next_process_local_state_pending auf /metrics und sinkt mit jedem der vier Redis-Züge
Der Speicher hinter der Idempotenz-Middleware ist seit 07.09.2026 austauschbar: ohne Konfiguration prozesslokal wie bisher (Appliance, Windows-Kasse, jede Einzel-Replika unverändert), mit Idempotenz:Speicher=Redis + Redis:ConnectionString prozessübergreifend. Reserviert wird atomar in einem Lua-Skript (Nachsehen und Belegen in EINEM Redis-Aufruf); die Antwort wird byte-genau abgelegt, sodass auch eine PDF-/ZIP-Antwort unbeschädigt zurückgespielt wird. Zwei Fristen: fertige Antwort 1 h, offene Reservierung 10 min (ein abgestürzter Pod blockiert seinen Schlüssel sonst eine Stunde mit 409). Fällt Redis aus, gibt es keine 503, sondern einen Rückfall auf den prozesslokalen Speicher — mit Warnung (gedrosselt auf eine Zeile je 30 s) und ungedrosselten Zählern dikas_next_idempotenz_redis_erreichbar (1/0), dikas_next_idempotenz_rückfall_total{vorgang}. Der Doppelbuchungsschutz gilt dann nur noch je Pod; bei replicas: 1 ist das folgenlos. Eine Fehlkonfiguration (Speicher=Redis ohne Verbindung) bricht dagegen den Start ab
Prüft Erreichbarkeit und Zugangsdaten der Cloud-Datenbank, bevor umgestellt wird
Jede View-Abfrage, die die Schwelle reisst, erhöht dikas_couchdb_slow_queries_total{view="<designDoc>/<viewName>"} — gesetzt an beiden Stellen des Clients (Map- UND Reduce-Pfad). EINE Schwelle für Protokollzeile und Zähler, damit die beiden nicht auseinanderlaufen; ab Werk 1000 ms (der Wert, der bis zum 07.09.2026 fest im Code stand), auf einer langsamen Kundenbox höher setzbar ohne Codeänderung, 0 schaltet beides ab. Das Label trägt nur designDoc/viewName, nie die URL — die enthält Mandanten-Präfix und Schlüssel und würde die Zeitreihe sprengen (dieselbe Regel wie beim stelle-Label der stillen Fehler); die vollständige URL steht weiterhin daneben in der Logzeile
dikas_email_outbox_älteste_sekunden (Maximum über alle Mandanten DIESES Pods, je Lauf neu ermittelt, damit der Wert auch wieder fällt) und dikas_hintergrunddienste_gestartet / _angemeldet / _übersprungen. Program.cs legt beide Reihen beim Hochlauf mit 0 an (BetriebsMetrik.ReiheAnlegen()): eine Prometheus-Reihe entsteht sonst erst beim ersten Schreibzugriff, dikas_hintergrunddienste_gestartet gäbe es dann genau im Alarmfall NICHT — auf eine fehlende Reihe kann keine Regel zeigen, sie bliebe still. 🪤 Beim Outbox-Alter zählt jede offene Mail, auch eine mit Backoff in der Zukunft: eine Mail im vierten Wiederholungsfenster wartet nicht, weil alles in Ordnung ist, sondern weil vier Zustellversuche gescheitert sind. Gemessen wird vor dem Zustellversuch — danach wäre im Erfolgsfall immer 0 zu messen. 🪤 Der Worker läuft seit der Führungswahl je Datenbank genau einmal, die Zahl schreibt also nur der führende Pod fort (für max by (pod) richtig, für eine Summe über Pods falsch)
Zählt die Stellen, an denen ein Hintergrund-/Startdienst einen mit Umsatz wachsenden Dokumenttyp per GetAllAsync komplett lädt — eine andere Klasse als ein Vollscan in einer Maske: der Dienst läuft im Takt und beim Hochlauf, und niemand wartet davor, es fällt also nie jemandem auf. Gemessener Stand 07.09.2026: 10 vorher, 9 nachher, jede verbliebene Stelle mit Begründung im Test. Zwei Eigenschaften, ohne die er den gemessenen Fall NICHT gefunden hätte: er geht eine Ebene tief durch MediatR (die teure Zeile stand im Handler des Kommandos, nicht im Dienst) und er löst using-Aliasse auf (using InvoiceEntity = …CustomerInvoice)
Die Kennzahlen antworten nur noch, wenn die Anfrage keinen Weiterleitungs-Header trägt (X-Forwarded-For, -Host, -Proto, -Port, X-Real-IP, Forwarded) — also cluster-intern über die Pod-IP, wie Prometheus scrapt — oder ein Scrape-Geheimnis mitbringt (Metrics:ScrapeToken als Authorization: Bearer, zeitkonstanter Vergleich). Sonst 404 ohne Rumpf, nicht 401/403: ein 401 wäre die Auskunft, dass es den Endpunkt gibt. Die Middleware steht vor UseForwardedHeaders — die verbraucht die Header, dahinter wäre der Riegel da und wirkungslos
/healthz bleibt Liveness (dependency-frei, damit ein DB-Ausfall keinen Neustart auslöst). /readyz führt alle Health-Checks mit dem Merkmal ready: database, startbereitschaft (ist die einmalige Start-Saat durch?), feature-module (kein Modul beim Registrieren gescheitert), hintergrunddienste (Startmeldung der Fabrik gelaufen) und — nur mit DemoTenant:Enabled — demo-masters-warm. 🪤 Degraded ⇒ 503 steht ausdrücklich am MapHealthChecks, weil das Framework sonst auf 200 abbildet und der Hochlauf genau Degraded ist. /ready bleibt als älterer Name derselben Wache bestehen. Gesundheitspfade sind in TenantMiddleware mandantenfrei (exakter Pfadvergleich) und von der Lizenzsperre ausgenommen
Adresse, Zugangsdaten, Intervall und Datenarten lesen und ändern (Neustart nötig)
Die Cloud reicht Vorgänge an die Maschine im Laden durch: Online-Bestellung, Lieferauftrag, offener Bon, Beleg-Signatur, A4-Druck
Liefert die Monatszahlen dieser Instanz an die Filialzentrale
Sicherung der Mandanten-Datenbanken läuft außerhalb des Betriebs; im Programm gibt es keinen Download und keine Backup-Verwaltung
Stösst vor einer Appliance→Cloud-Migration eine Sicherung der betroffenen Datenbanken an
Liest eine Sicherung (inkrementelle Blöcke + Anhänge) ein, wahlweise nur ausgewählte Kategorien
Gelöschte Artikel, Warengruppen und Kunden ansehen und zurückholen
Alle Artikel, alle Warengruppen, alle Kunden oder nur verwaiste Kunden endgültig löschen
Wird ein Dokument endgültig gelöscht (Bereinigung, Aufräum-Läufe), verschwinden auch seine Bilder und PDFs — auf beiden Datenbank-Arten gleich
Wird ein Dokument endgültig gelöscht, hält eine Grabstein-Spur das fest, damit der Abgleich die Löschung an die Cloud melden kann
Der Abgleich meldet vorgemerkte Löschungen an die Cloud. Wurde das Dokument dort zwischenzeitlich bearbeitet, bleibt es erhalten und die Vormerkung wird verworfen
Führt durch Quellsystem-Wahl, Export-Anleitung und Umzugs-Checkliste; seit 2026-07-08 in den kombinierten Einrichtungs-Assistenten (/admin/compliance-setup) eingebettet, keine eigene Route mehr
Liest den gesetzlichen DSFinV-K-Export fremder Kassensysteme (ZIP oder TAR) und rekonstruiert daraus Artikelliste, Steuersätze und Zahlarten
Direkter Wechsel von ready2order: entweder CSV-Export einlesen oder Artikel und Kunden live über deren Schnittstelle abholen
Gemeinsamer vierstufiger Import-Assistent mit Spaltenerkennung und Vorschau; Zielweg auch für alle Migrations-Quellen
Wandelt Alt-Dokumente in das neue Format: Tische, Artikel und Gruppen, Kunden, Extras, Belege, Gutscheine. Der schreibende Legacy-Migrator läuft ausschließlich in ausdrücklich gestarteten Migrations-, Restore- und Couch-to-SQL-Pfaden, nicht beim normalen Lesen von Stammdaten oder Belegen
Zieht alle Dokumente aus einer CouchDB in die lokale SQL-Datenbank (Umstieg auf Einzelplatz/Windows; auf Android derselbe Weg beim „Kasse installieren")
Markiert nicht migrierte Alt-Dokumente in der Cloud als gelöscht, ohne die Datenbank zu löschen
Prüft, ob die Cloud-Datenbank noch nicht migrierte Alt-Daten enthält, und meldet den Befund (nur lesend)
Faltet die zweite Datenbank (gastrocurrent) in die Hauptdatenbank; nur für Bestandskunden, ausdrücklich ausgelöst
Ergänzt je Mandanten-Datenbank die fehlende Rolle, damit mandantenbezogene Zugriffe greifen
Von der Kassen-Appliance angestossene Migration der Altdaten in die Cloud, mit Fortschritts-Abfrage
Nach der Konvertierung werden die Alt-Dokumente gelöscht (Bons, Schichten, Kassenbücher, konvertierte Stammdaten, Alt-Views) und die Datenbank kompaktiert, damit der Platz auch frei wird. Seit Task 6 (Owner-Audit 2026-08-15) je Legacy-Typ bedingt: ein Typ mit Konvertierungsfehlern in Phase 3 wird NICHT gelöscht (alle Dokumente des Typs bleiben stehen, nicht nur die gescheiterten)
Auf einem Deployment mit Fiscal:Country=CH liefern basic/gastro/delivery/club/friseur/full Schweizer Profile: DemoCatalogCh (CHF, MWST 8,1/2,6/3,8, Schweizer Gerichte, Coiffeur-Wording, kein „ß"), Schweizer Stammkunden, MainCurrency=CHF, CashRoundingUnit=0.05. Details in 12 Fiskal ES & International
Vorführinstanz Fahrradwerkstatt: Ersatzteillager mit Bestand, Aufträge in allen sieben Stati, taller-Rechnungen mit Zahlungen, Kostenvoranschläge, Annahmetermine
Vorführinstanz Kulturhaus/Studentenclub: Eintrittsgruppen einer Abendkasse (Abendkasse/Ermässigt/Mitglied/Studi-Abend/Gästeliste), Tresen-Katalog, Garderobe mit Bügelnummer, anwesende Gäste, Nachtabrechnung, Tagesberichte
Vorführinstanz Motorgeräte-, Garten- und Forsttechnik-Fachhandel: Theke plus Werkstatt, Kunden sind Bauhof/GaLaBau/Forst, Aufträge in allen sieben Stati, überfällige B2B-Rechnung auf Mahnstufe 1
Vorführinstanz Campingplatz-Kiosk: Kiosk-Theke und Platz-Bistro auf einer Kasse, Brötchen-Vorbestellung, Pfand-Warengruppe, Verleih, Dauercamper mit Guthaben und Karte, Saisonkurve mit Winterpause
Vorführinstanz Craft-Brauerei: Taproom-Tischplan, Hofverkauf mit Kisten und Pfand, Führungen und Braukurse als Artikel, B2B-Kunden mit Zahlungsziel
Vorführinstanz Edelbrand-/Obstbrennerei: Flaschen in drei Grössen je Sorte, Verkostungsraum und Brennstube als Ressourcen mit Terminen, eigene Hofverkaufszeiten, B2B-Kunden
Kein Treffer in diesem Bereich. Gesamte Website durchsuchen
Oft gesucht
Marketing-Cookies erlauben?
Wir würden gerne mit Google Ads messen, welche Anzeigen zu einer Anmeldung führen. Dafür werden Cookies gesetzt und Daten an Google (USA) übertragen — nur mit deiner Einwilligung. Unsere anonyme Reichweitenmessung (Matomo) läuft davon unabhängig. Details und Widerruf in der Datenschutzerklärung.
