In den meisten Systemen lassen sich Rabatte, Staffeln und Boni hinterlegen. Die Frage ist nicht, ob das ERP Konditionen abbilden kann, sondern welche Art von Kondition es abbilden kann, ohne dass jemand nachhilft.
Die Grenze verläuft dort, wo eine Vereinbarung eine Bedingung enthält, die das System nicht als Feld kennt.
Was zuverlässig funktioniert
Rechnungsbezogene Konditionen sind unproblematisch. Ein Kopfrabatt von 3 Prozent auf jede Position, ein Mengenrabatt ab einer Bestellmenge, ein Skontosatz mit Frist: Das sind Felder im Kreditorenstamm oder im Einkaufsinfosatz, und sie rechnen bei jeder Bestellung mit.
Auch einfache Jahresstaffeln sind in den meisten Systemen abbildbar. Umsatz über X ergibt Bonus Y, kumuliert über die Periode. Der Standard reicht, solange die Staffel auf einer Größe beruht, die das System ohnehin führt.
Wo es aufhört
Schwierig wird es bei vier Mustern, die in Verträgen häufig vorkommen.
Bedingte Konditionen. Der Bonus steigt um einen Punkt, wenn zusätzlich eine Werbeleistung erbracht wird. Das System kennt die Werbeleistung nicht, weil sie nicht im Warenfluss entsteht.
Konditionen auf abweichender Bezugsebene. Die Staffel gilt für eine Warengruppe, die nicht mit der Warengruppensystematik des Systems übereinstimmt, sondern mit der des Lieferanten.
Zeitlich versetzte Bausteine. Eine Kondition wird rückwirkend wirksam oder erst nach Vorlage eines Nachweises. Der Standard kennt Perioden, aber keine Nachweise.
Gegenseitige Abhängigkeiten. Kondition A gilt nur, wenn Kondition B nicht gezogen wurde. Das ist eine Regel, und Regeln stehen selten in Stammdatenfeldern.
Was daraus folgt
In der Praxis entsteht eine Zweiteilung. Der rechnungsbezogene Teil läuft im System und stimmt. Der Rest wandert in Tabellen, die einzelne Personen pflegen.
Diese Zweiteilung ist der eigentliche Punkt. Sie ist nicht schlimm, solange sie bekannt ist und beide Teile zusammengeführt werden. Sie wird zum Problem, wenn niemand sagen kann, welcher Anteil des Konditionsvolumens im System rechnet und welcher nicht.
Die Frage lässt sich beantworten. Man nimmt das erwartete Konditionsvolumen einer Periode und prüft, welcher Anteil davon aus Systemfeldern stammt. Liegt er bei sechzig Prozent, sind vierzig Prozent des Volumens von Handarbeit abhängig.
Die Zwischenebene
Der Weg, der sich in der Praxis bewährt, ist weder eine Anpassung des ERP noch eine große Tabelle. Es ist eine Ebene, die auf den Bewegungsdaten des Systems aufsetzt und die Konditionslogik außerhalb davon führt.
Das ERP bleibt die Quelle für Wareneingang, Rechnung und Gutschrift. Die Konditionslogik mit ihren Bedingungen, Nachweisen und Bezugsebenen liegt daneben und greift auf diese Daten zu. Das ändert nichts am System, das ohnehin niemand wegen einer Bonusklausel umbauen will.
Was bei einem Systemwechsel passiert
Eine Migration ist der Moment, in dem die Zweiteilung sichtbar wird. Was in Systemfeldern steht, wird übernommen. Was in Tabellen steht, wird selten migriert, weil es im Migrationsumfang nicht auftaucht.
Das führt zu einem wiederkehrenden Muster: Im ersten Jahr nach der Umstellung fällt das realisierte Konditionsvolumen, ohne dass sich die Verträge geändert haben. Die Ursache ist meist nicht das neue System, sondern das Wissen, das neben dem alten lag.
Vor einer Migration lohnt sich deshalb eine schlichte Bestandsaufnahme: Welche Konditionsbausteine rechnen heute im System, welche daneben, und wer pflegt jeweils. Diese Liste gehört in den Migrationsumfang, auch wenn sie technisch nichts mit ihm zu tun hat.
Ein Einstieg
Nehmen Sie fünf Konditionsvereinbarungen und prüfen Sie Baustein für Baustein, ob er im System hinterlegt ist oder daneben geführt wird. Halten Sie fest, wer den jeweiligen Baustein berechnet.
Das Ergebnis ist eine Landkarte. Sie zeigt, welcher Teil des Konditionsvolumens von einem System abhängt und welcher von einer Person.
