Zum Inhalt

Geschäftsregeln

Expecto validiert Daten auf zwei Ebenen, und es hilft, sie auseinanderzuhalten.

Entity-Validierungsregeln

Eine Entity trägt Validierungsregeln auf Zeilenebene. Jede Regel ist ein Ausdruck, den jede Zeile erfüllen muss; Zeilen, die scheitern, werden als Verstöße (Violations) gemeldet. Regeln kompilieren zu einer DuckDB-Verletzungsabfrage der Form SELECT ... WHERE NOT (expression).

Regeln unterstützen:

  • Operatoren: ==, !=, >, <, and, or, not.
  • Feldreferenzen: d.field_name für die geprüfte Zeile, c.context_field für Session-Kontext.
  • Katalog-Lookups: die Kataloge der Session stehen als Tabellen cat_<name> bereit (cat_<name>__org, cat_<name>__project, cat_<name>__provider je nach Scope) — dieselben Namen wie in Transformern und Geschäftsregeln; z. B. ein Steuerkennzeichen melden, das im cat_steuerkennzeichen__provider des Lieferanten fehlt.
  • Lookups in Kontexttabellen: Tabellen im Session-Kontext (_tables, z. B. per Context Source geholt) stehen als ctx_<name> bereit — wieder dieselben Namen wie in Transformern und Geschäftsregeln.
  • Funktionen: len(), matches(), in(), is_empty(), abs(), nz(), round() und mehr.
  • Schweregrad: ERROR, WARNING oder INFO.
  • Vorbedingungen und lokalisierte Meldungen (Text je Locale).

Bearbeiten in der Oberfläche. Der Editor für Entity-Regeln ist dieselbe SQL-Werkbank wie bei den Projekt-Geschäftsregeln: Links listet der Schema-Explorer data mit den Spalten der Entity sowie die Kataloge und Kontexttabellen, die die Projekte der Entity sehen (cat_*, ctx, ctx_<name>); der Editor vervollständigt ihre Namen automatisch. Ein Klick auf eine Tabelle oder Spalte fügt sie an der Cursorposition ein.

Projekt-Geschäftsregeln

Ein Projekt trägt übergreifende Geschäftsregeln in einer eigenen Tabelle (nicht JSONB). Jede ist entweder ein Ausdruck oder eine SQL-Regel, ist geordnet und aktivierbar. Diese decken Prüfungen ab, die die Lieferung statt einer einzelnen Zeile betreffen — einschließlich entity-übergreifender Reconciliation:

  • Keyed Reconciliation — ein FULL OUTER JOIN über einen Gruppierungs- schlüssel (z. B. muss eine Buchungsdatei je Konto gegen eine Summendatei ausgeglichen sein).
  • Global Reconciliation — ein CROSS JOIN skalarer Aggregate.

Das not_applicable-Ergebnis

Eine Regel kann statt pass/fail zu not applicable auflösen, wenn ihre Vorbedingungen für eine Lieferung nicht gelten — etwa eine Regel über eine VAT-Source, wenn diese optionale Source nicht geliefert wurde. Bevorzugen Sie dieses semantische Ergebnis gegenüber einem technischen Fehler (wie „unknown table"): es sagt dem Prüfer, dass die Regel schlicht nicht zutraf, statt wie ein Fehlschlag auszusehen.

Schweregrad und Blockieren

Der Blocking-Schweregrad eines Projekts entscheidet, welche Verstöße eine Freigabe der Session verhindern. WARNING- und INFO-Verstöße werden zur Prüfung angezeigt, ohne zwingend zu blockieren; ERROR-Verstöße blockieren typischerweise bis zur Behebung.

Verwandt