Preisgültigkeit modellieren: Warum zwei richtige Datensätze zusammen widersprüchlich sein können
Ein Preissatz kann formal vollständig und numerisch korrekt sein und trotzdem zu einem falschen Ergebnis führen. Das passiert beispielsweise, wenn zwei Preise für denselben Artikel, Kundenkreis und Zeitraum gelten. Der Fehler liegt dann zwischen den Datensätzen. Eine Prüfung jeder einzelnen Zeile reicht nicht aus, um diesen Widerspruch zu erkennen.
Gültigkeit als Intervall verstehen
Ein Preis braucht einen Beginn und ein definiertes Ende seiner Gültigkeit. Ebenso wichtig ist die Frage, ob beide Grenzen eingeschlossen sind. Endet ein Preis am Monatswechsel und beginnt dort ein neuer, können uneinheitliche Grenzregeln einen doppelten Treffer oder eine Lücke erzeugen. Häufig sind Intervalle sinnvoll, die den Beginn einschließen und das Ende ausschließen. Entscheidend ist weniger die gewählte Konvention als ihre einheitliche Anwendung in Datenhaltung, Schnittstellen und Berechnung.
Alle Preisdimensionen beachten
Ein Überschneidungstest darf nicht nur Artikelnummer und Datum vergleichen. Währung, Mengeneinheit, Staffel, Kundengruppe und weitere tatsächlich verwendete Dimensionen können einen eigenen Preisraum bilden. Zwei überlappende Intervalle sind nur dann widersprüchlich, wenn sie innerhalb desselben relevanten Geltungsbereichs konkurrieren. Umgekehrt können zu wenige Vergleichsmerkmale eine echte Doppelbelegung übersehen. Der fachliche Schlüssel des Preises muss deshalb gemeinsam mit den Regeln für Priorität und Ausnahmen festgelegt werden.
Paralleländerungen mitdenken
Prüft eine Anwendung erst auf Überschneidung und speichert anschließend, können zwei gleichzeitig laufende Vorgänge jeweils einen freien Zeitraum sehen. Beide speichern dann einen konkurrierenden Preis. Eine belastbare Lösung benötigt zusätzlich eine passende Transaktions- oder Datenbankabsicherung. Der konkrete Mechanismus hängt vom eingesetzten System ab. Wichtig ist, dass die Integritätsregel auch unter Parallelität gilt und nicht ausschließlich in einer Eingabemaske geprüft wird, die andere Importwege umgehen können.
Historie und Auswertung unterscheiden
Für eine frühere Bestellung kann relevant sein, welcher Preis damals galt oder welcher Preis zum damaligen Bearbeitungszeitpunkt im System bekannt war. Diese Fragen sind nicht identisch. Korrekturen sollten deshalb nachvollziehbar bleiben. Ein guter Testbestand enthält angrenzende Intervalle, echte Überlappungen, rückwirkende Korrekturen und gleichzeitige Importe. Erwartete Ergebnisse werden aus der vereinbarten Fachregel abgeleitet. Eine automatisch ausgewählte „neueste Zeile“ ist nur dann eine Lösung, wenn genau diese Priorität fachlich beabsichtigt ist.
Auch eine leere Gültigkeitsgrenze benötigt eine definierte Bedeutung. „Unbegrenzt gültig“ ist etwas anderes als „Enddatum noch nicht erfasst“. Diese Unterscheidung verhindert, dass unvollständige Daten versehentlich dauerhaft wirksame Preise erzeugen.
Modelling price validity: Why two valid records can still contradict each other
A price record can contain every required field and a numerically correct value while still producing the wrong result. One example is two prices applying to the same item, customer scope and period. The error exists between records rather than inside either record. Checking each row in isolation cannot reliably detect this contradiction.
Treat validity as an interval
A price needs a start and a clearly defined end of validity. Whether those boundaries are inclusive is equally important. If one price ends at the turn of a month and another starts there, inconsistent boundary conventions can produce either two matches or a gap. An interval that includes its start and excludes its end is often useful. The central requirement is consistent interpretation in storage, interfaces and calculations, rather than a particular convention chosen without reference to the business process.
Include every relevant price dimension
An overlap check cannot always compare only item number and date. Currency, unit of measure, quantity break, customer group and other dimensions actually used by the business may define separate price scopes. Two intervals conflict only when they compete within the same relevant scope. Conversely, omitting an important scope dimension may hide a real duplicate assignment. The business key for a price therefore needs to be agreed together with explicit rules for precedence and permitted exceptions.
Account for concurrent changes
If an application checks for overlaps and saves afterwards, two concurrent processes may both see an apparently available period. Each can then save a competing price. A robust design also needs appropriate transactional or database protection. The precise mechanism depends on the system. What matters is that the integrity rule remains effective during concurrency and does not exist only in an entry form that a separate import process or integration interface can bypass.
Distinguish history from interpretation
For an earlier order, users may need to know which price was valid at the time, or which price the system knew about when the order was processed. Those are different questions. Corrections should therefore remain traceable. A useful test set includes adjacent intervals, actual overlaps, retrospective corrections and simultaneous imports. Expected outcomes follow the agreed business rule. Automatically choosing the newest row is a solution only when that precedence is explicitly intended, rather than a convenient way to conceal conflicting records.
An empty validity boundary also needs a defined meaning. “Valid indefinitely” differs from “end date not yet recorded”. Keeping those meanings separate prevents incomplete data from accidentally creating prices that remain effective without an intended end.