Kurzantwort
Eine Tarifänderung geht erst produktiv, wenn ihr Ergebnis auf echten Stammdaten durchgerechnet und gegen eine unabhängige Handrechnung bestätigt ist. Dafür gibt es in IS-U die Simulation der Abrechnung (Transaktion EASISI für einen einzelnen Vertrag, in der Abrechnungsausführung EA00 mit der Option „Simulation“). Der Weg führt von der Entwicklung über das Testsystem in die Produktion, mit je einer Kontrolle pro Station und einer Prüfung der ersten echten Abrechnung. Wie ein Tarif angelegt wird, steht in Tarif anlegen und ändern, wie der Preiswechsel zeitlich wirkt, in Tarifwechsel, Preisänderung und Gültigkeit.
Was getestet wird
Ein Tarif besteht aus Preisen mit Gültigkeit, einer Zuordnung (welcher Vertrag bekommt welchen Tarif, siehe Tarifart, Tarif und Tariftyp und Tariffindung und Tarifierung) und einem Rechenweg aus Menge und Preis. Der Test prüft alle drei. Eine richtige Preistabelle mit zu weiter Zuordnung rechnet die falschen Kunden richtig.
Simulation: zwei Arten, ein Unterschied
Alle Simulationsarten von der Einzelsimulation bis zur Massensimulation ordnet Abrechnung simulieren und prüfen.
SAP Learning unterscheidet zwei Wege (Performing a Billing Simulation):
- Billing Simulation braucht einen fakturierbaren Abrechnungsauftrag. Damit müssen Ablesergebnisse vorliegen.
- Simulation braucht keinen Abrechnungsauftrag. Der Sachbearbeiter gibt einen Simulationszeitraum ein, und das System projiziert fehlende Ablesergebnisse aus vorhandenen Werten.
Beide Wege lassen Ablesergebnisse und Stammdaten unverändert, und der Abrechnungsauftrag bleibt bestehen. Sie erzeugen aber einen Simulationsbeleg. Er trägt eine andere Belegart und kann einen eigenen Nummernkreis haben, damit er vom echten Beleg unterscheidbar bleibt. Daraus folgt: Die Simulation mit Projektion zeigt, was das System mit vorhandenen Daten tut, aber sie deckt keinen fehlenden Ablesewert auf, weil sie ihn selbst ersetzt. Für den Preiswechsel zum Stichtag nimmst du deshalb Verträge mit vorhandenen Ablesungen und die Billing Simulation. Der Aufruf im Fiori-Launchpad heißt Billing Execution (EA00): Option „Simulation“, Zeitraum und Vertragskonto eingeben, „Bill/simulate“, danach den Beleg anzeigen.
Vor der Simulation prüft der Einzelbigcheck (EASICH) einen Vertrag gegen die Bigcheck-Regeln, etwa auf fehlende Ablesewerte oder unplausible Preise (Transaktionswerkbank). Der Massenbigcheck (EAMACH) macht das für viele Verträge in einem Lauf und liefert eine Auffälligkeitsliste.
Testklassen
Die Auswahl der Fälle entscheidet über die Qualität. Mehr Fälle in derselben Klasse bringen wenig; wichtig sind Fälle, die den Rechenweg unterschiedlich belasten. Je Klasse steht der Nachweis, der sie abnimmt:
- Normalfall, ein Preis, volle Periode. Belegbetrag gleich handgerechneter Referenz.
- Grundpreis und Arbeitspreis getrennt. Summe der Positionen gleich Belegbetrag, Zeitanteile stimmen.
- Preiswechsel in der Periode. Mengenschnitt am Stichtag stimmt auf den Tag genau.
- Abrechnungszeitraum wechselt. Vergleich mit einem realen Vorjahreszeitraum.
- Gerätewechsel in der Periode. Kein Mengenverlust und keine Doppelzählung am Wechseltag (Gerätewechsel und Tarifierung).
- Gerätewechsel mit Tarifwirkung. Alter Tarif bis zum Stichtag, neuer Tarif ab dem Stichtag.
- Messwertkorrektur nach der Abrechnung. Der Korrekturbeleg enthält nur die Differenz (Rechnungskorrektur EABICO, Abrechnungssteuerung).
- Ersatzwert. Der Wert ist als Ersatzwert erkennbar.
- Zeitumstellung und Mitternacht. Der Grenzfall liegt auf dem erwarteten Zeitstempel.
Die Klassen sind nach Rechenweg geschnitten, nicht nach Kundengruppe. Zwei Kunden mit unterschiedlichem Verbrauch prüfen dieselbe Logik.
Der Stichtagsfall
Die meisten Tariffehler entstehen an der Grenze: Preiswechsel, Gerätewechsel und Korrektur am selben Tag. Lege die Erwartung vorab fest und begründe sie aus Vertrag oder Tarifvereinbarung. Wer erst simuliert und die Erwartung aus dem Ergebnis ableitet, hat nichts geprüft. Ein zweiter Grenzfall liegt außerhalb des Systems: Über Preisänderungen ist spätestens zwei Wochen, bei Haushaltskunden spätestens einen Monat vor Eintritt der Änderung zu unterrichten (§ 41 Abs. 5 EnWG). Das Datum der Kundenmitteilung gehört deshalb zur Freigabe, nicht nur das der Preistabelle.
Transport und Produktivsetzung
Tarifdaten sind Abrechnungsstammdaten. Für den Weg zwischen den Systemen beschreibt die SAP-Hilfe den selektiven Tarif-Transport (Selective Rate Transport): Er überträgt ausgewählte Abrechnungsstammdaten zwischen Systemen, bietet Selektionskriterien, eine Statusliste der gewählten Objekte und einen simulierten Transport, und läuft in zwei Schritten: Objekte im Quellsystem herunterladen, im Zielsystem hochladen. Voraussetzung ist, dass beide Systeme denselben Releasestand und dasselbe Customizing für Abrechnungsstammdaten haben (SAP Help, Selective Rate Transport). Customizing und Entwicklungsobjekte laufen dagegen über Transportaufträge (SE09, SE10, STMS, siehe Release-Management). Welchen der beiden Wege ein Haus für Preise und Tarife nutzt, ist hier nicht belegt: Prüfe, was dein Transportkonzept festlegt, und teste im Testsystem mit genau diesem Weg.
Kontrolle der ersten echten Abrechnung
Auch nach bestandenem Test bleibt die erste echte Abrechnung ein eigener Schritt:
- Vor dem Lauf: Trefferzahl der Zuordnung gegen die Vertragsliste, Massenbigcheck (EAMACH).
- Lauf: Massenabrechnung (EA38), danach die Aussteuerungen (EA05) lesen, in denen das System auffällige Fälle zurückhält, und Stichproben-Belege ansehen (EA22).
- Nach dem Lauf: Summe über das Kollektiv gegen die erwartete Summe und Verteilung der Beträge gegen die Vorperiode.
Eine Tarifgültigkeit lässt sich zurücknehmen, bis der erste Vertrag mit ihr abgerechnet ist. Danach laufen Belege und Stammdaten auseinander. Lege deshalb einen Zeitpunkt fest, ab dem es kein Zurück gibt, und gib erst vor diesem Zeitpunkt frei.
Beispiel: Arbeitspreis zum 1. April
Vereinfachtes Beispiel mit synthetischen Zahlen: 1.450 Verträge, neuer Arbeitspreis ab 01.04., 00:00 Uhr. Getestet wird in vier Stufen: der Normalfall einmal mit altem und einmal mit neuem Preis; drei Verträge mit Abrechnungsgrenze am 31.03.; fünf Verträge mit Gerätewechsel; zwei Verträge mit nachträglicher Messwertkorrektur. Die Simulation liefert den Betrag, die Handrechnung bestätigt ihn. Für die zwei Korrekturfälle reicht die Simulation nicht: Im Echtlauf wird geprüft, dass nur die Differenz entsteht.
Fehlerfälle
- Zuordnung zu weit. Preistabelle richtig, aber mehr Verträge getroffen als geplant: viele falsche Rechnungen in einem Lauf. Erkennbar an der Trefferzahl vor dem ersten Echtlauf.
- Stichtag um einen Tag verschoben. Eine Teilstrecke rechnet mit dem alten Preis. Erkennbar nur über die vorab festgelegte Erwartung am Grenzfall.
- Korrektur als Neuberechnung. Statt der Differenz entsteht eine zweite volle Periode.
- Ersatzwert nicht erkennbar. Die Abrechnung wirkt vollständig, ihre Herkunft ist falsch ausgewiesen.
- Mitteilung zu spät. Rechenweg richtig, aber der Kunde kann den Vertrag nach § 41 Abs. 5 EnWG ohne Frist beenden.
Typische Missverständnisse
„Ein grüner Simulationslauf ist der Nachweis.“ Er zeigt das Verhalten des Rechenkerns. Erst der Vergleich mit einer unabhängigen Referenz macht daraus eine Aussage.
„Die Simulation ohne Abrechnungsauftrag ersetzt den Echtfall.“ Sie projiziert fehlende Ablesungen und kann deshalb keine fehlende Ablesung aufdecken.
„Die Simulation hinterlässt nichts.“ Sie ändert keine Stammdaten, erzeugt aber einen Simulationsbeleg mit eigener Belegart.
Offen
- Ob Preise und Tarife eines Hauses per selektivem Tarif-Transport oder per Transportauftrag ins Produktivsystem kommen, hängt vom Transportkonzept ab und ist hier nicht belegt.
- Ob EA00 mit „Simulation“ in jedem Release dasselbe liefert wie EASISI, ist nicht geprüft.
Quellen und Pflegehinweis
SAP-Aussagen aus SAP Learning (Simulation, EA00) und der SAP-Hilfe (selektiver Tarif-Transport), Transaktionen aus der Transaktionswerkbank, Rechtsstand § 41 Abs. 5 EnWG am 05.10.2026 an gesetze-im-internet.de geprüft. Die Beschreibung von EA00 in der Transaktionswerkbank als Testabrechnung ohne Beleg weicht von SAP Learning ab; hier gilt SAP Learning.