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 die eingesetzte Konfiguration abbildet, ohne dass jemand nachhilft.
Die Grenze verläuft dort, wo eine Vereinbarung eine Bedingung enthält, die das System in dieser Einrichtung nicht kennt.
Was zuverlässig funktioniert
Rechnungsbezogene Konditionen sind in der Regel 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.
Fehlerfrei sind sie damit nicht. Ein veralteter Satz im Stamm, eine falsch gepflegte Frist oder eine Bestellung, die am Infosatz vorbeigeht, erzeugen eine falsche Rechnung, die niemand prüft, weil das System ja rechnet.
Auch Jahresstaffeln sind in vielen Systemen abbildbar, und in einigen deutlich weiter, als der Ruf es vermuten lässt. SAP etwa führt Konditionsverträge mit wahlweise Wareneingangs- oder Rechnungsbasis, mit Selektionskriterien, Abgrenzungen sowie Teil- und Schlussabrechnungen. Zeitversetzte Konditionen liegen also nicht grundsätzlich außerhalb des ERP.
Wo es aufhört
Was die eingesetzte Konfiguration nicht abdeckt, lässt sich nur am konkreten System prüfen. Vier Muster führen dabei besonders häufig zu einer Lücke.
Bedingte Konditionen. Der Bonus steigt um einen Punkt, wenn zusätzlich eine Werbeleistung erbracht wird. Die Werbeleistung entsteht nicht im Warenfluss und ist deshalb selten ein Feld.
Konditionen auf abweichender Bezugsebene. Die Staffel gilt für eine Warengruppe, die nicht mit der eigenen Warengruppensystematik übereinstimmt, sondern mit der des Lieferanten.
Nachweisgebundene Bausteine. Eine Kondition wird erst nach Vorlage eines Nachweises wirksam. Perioden kennt der Standard, Nachweise selten.
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. Ein Teil der Konditionen rechnet ohne Zutun, der Rest hängt an Tabellen, die einzelne Personen pflegen.
Diese Zweiteilung ist der eigentliche Punkt. Sie ist beherrschbar, solange sie bekannt ist und beide Teile zusammengeführt werden. Sie wird zum Problem, wenn niemand sagen kann, welcher Anteil des Konditionsvolumens von selbst rechnet und welcher nicht.
Beantworten lässt sich das, allerdings nicht über die Systemgrenze. Erfassen Sie je Konditionsbaustein zwei Dinge getrennt: wo die Regel geführt wird, und wie sie verarbeitet wird, also automatisch, mit manuellen Eingriffen oder vollständig von Hand.
Beides fällt nicht zusammen. Eine angebundene Konditionslösung neben dem ERP kann vollständig automatisch rechnen, und ein gepflegtes ERP-Feld belegt umgekehrt keine durchgängige Automatisierung, wenn die Abrechnung am Ende doch jemand von Hand anstoßen muss. Gewichtet werden die drei Gruppen mit dem erwarteten Konditionsvolumen.
Drei Wege, eine Lücke zu schließen
Zeigt die Bestandsaufnahme eine Lücke, stehen drei Wege offen, und keiner ist grundsätzlich der richtige.
Der erste ist die Standardfunktion, die bisher nicht genutzt wird. Sie kostet Einrichtung und keine zusätzliche Software, deckt aber nur ab, was das Produkt vorsieht.
Der zweite ist eine Erweiterung im System. Sie passt genau, bindet aber Entwicklung und muss jeden Versionswechsel mitgehen.
Der dritte ist eine Ebene daneben, die auf den Bewegungsdaten des Systems aufsetzt und die Konditionslogik außerhalb führt. Das ERP bleibt die Quelle für Wareneingang, Rechnung und Gutschrift.
Kostenlos ist auch der dritte Weg nicht. Er braucht eine Schnittstelle, eindeutige Belegidentitäten und Kontrollen gegen Doppelbuchungen, und die Ergebnisse gehören regelmäßig gegen das Hauptbuch abgestimmt. Die Wahl fällt nach der Größe der Funktionslücke und den Gesamtkosten über die Laufzeit.
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.
Aus Migrationsprojekten wird daher immer wieder dasselbe berichtet: Im ersten Jahr nach der Umstellung fällt das realisierte Konditionsvolumen, ohne dass sich die Verträge geändert haben. Belastbare Zahlen zur Häufigkeit gibt es nicht. Wo der Effekt auftritt, liegt die Ursache selten am neuen System und meist an dem Wissen, das neben dem alten lag.
Vor einer Migration lohnt sich deshalb eine schlichte Bestandsaufnahme: Welche Konditionsbausteine rechnen heute ohne Eingriff, welche nicht, 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 halten Sie Baustein für Baustein zwei Angaben fest: wo die Regel geführt wird und wie die Abrechnung ausgelöst wird.
Das Ergebnis ist eine Landkarte. Sie zeigt, welcher Teil des Konditionsvolumens ohne Eingriff rechnet und welcher an einer Person hängt, unabhängig davon, in welchem System die Regel steht.
