Auf dieser Seite 11 Abschnitte
Kurzantwort
Ein Tarif geht erst dann produktiv, wenn seine Rechenergebnisse gegen eine unabhängig geführte Referenz nachgerechnet und je Testklasse freigegeben sind. Die Abrechnungssimulation in SAP Utilities liefert dafür den Nachweis, weil sie auf echten Stammdaten arbeitet und keinen fortgeschriebenen Beleg erzeugt. Stichtagsfälle brauchen eine eigene Klasse, weil Gerätewechsel, Preiswechsel, Messwertkorrektur und Abrechnungszeitraum an derselben Vertragsperiode hängen. Freigegeben wird ein Bündel. Es besteht aus Preistabelle, Gültigkeit, Zuordnungslogik und Rechenkern.
Einordnung: Was hier eigentlich getestet wird
Ein Tarif ist in SAP Utilities kein einzelner Datensatz. Er besteht aus einer Preistabelle mit Gültigkeiten, einer Zuordnungsregel, die festlegt, welcher Kunde welchen Tarif bekommt, und einem Rechenweg, der aus Menge und Preis einen Betrag bildet. Der Test muss alle drei Ebenen prüfen. Eine korrekte Preistabelle mit falscher Zuordnungsregel berechnet den falschen Kunden richtig.
Diese Tests liegen auf der fachlichen Ebene der Abrechnung. Der Vertrieb liefert nur die vereinbarte Produktkonfiguration. Die Abrechnungssimulation führt den Abrechnungslauf auf den bestehenden Stammdaten aus und erzeugt dabei einen Simulationsbeleg statt eines fortgeschriebenen Belegs (SAP Learning, Performing a Billing Simulation). Getestet wird also die Kette: Stammdaten und Gültigkeit, Preisfindung, Mengenermittlung, Betragsberechnung, Belegergebnis.
Rechtlich steht dahinter eine harte Anforderung. Der Vertrag muss die Preise und Preisanpassungen sowie den Zeitpunkt der Abrechnungen benennen (§ 41 Abs. 1 Nr. 5 und Nr. 7 EnWG). Die Rechnung muss unter anderem Anfangs- und Endzählerstand, den ermittelten Verbrauch und die Art seiner Ermittlung ausweisen (§ 40 Abs. 1 EnWG). Ein Tarif, der diese Angaben nicht korrekt erzeugt, ist fachlich falsch und erzeugt eine fehlerhafte Rechnung.
Zwei Simulationsarten mit unterschiedlicher Aussagekraft
SAP Utilities kennt zwei Wege, das Abrechnungsergebnis zu prüfen. Die Abrechnungssimulation verlangt einen fakturierbaren Abrechnungsauftrag. Messergebnisse müssen daher vorliegen. Die Simulation kommt ohne Abrechnungsauftrag aus: Der Sachbearbeiter gibt einen Simulationszeitraum ein, und das System projiziert fehlende Messergebnisse aus vorhandenen Werten (SAP Learning, Performing a Billing Simulation).
Beide Simulationsarten arbeiten auf Stammdaten, die tatsächlich existieren. Das ist ihr Wert und ihre Grenze. Sie zeigen, was das System mit den vorhandenen Daten tut. Sie zeigen nicht, ob die vorhandenen Daten zum Prüfzeitpunkt richtig sind. Ein Tarif kann in der Simulation korrekt rechnen und trotzdem falsch fakturieren, weil eine Gültigkeit, ein Zuordnungsmerkmal oder ein Messwert nicht dem geprüften Stand entspricht.
Praktisch wichtig sind zwei Eigenschaften. Abrechnungs- und Simulationsbelege lassen sich über Belegart und Nummernkreis trennen, sodass sie unterscheidbar bleiben und auch die spätere Archivierung leichter fällt. Und die Abrechnungssimulation erzeugt keinen fortgeschriebenen Abrechnungsbeleg, der Rechenkern wird also geprüft, ohne den Vertrag zu verändern. Ob der Simulationsbeleg in einem eigenen Nummernkreis liegt, ist eine Customizing-Entscheidung des Hauses und muss im Testbericht nachgewiesen werden, nicht unterstellt.
Testklassen von Normalfall bis Messwertkorrektur
Die Auswahl der Fälle ist der eigentliche Qualitätshebel. Eine Tarifänderung wird durch die Abdeckung der Klassen sicher, die den Rechenweg unterschiedlich belasten. Eine hohe Fallzahl in derselben Klasse bringt dagegen wenig. Tabelle 1 ordnet jeder Klasse einen Prüfschwerpunkt und ein Nachweiskriterium zu.
| Testklasse | Was diese Klasse belastet | Nachweis |
|---|---|---|
| Normalfall, ein Preis, volle Periode | Preisfindung, Mengenermittlung, Betragsberechnung | Belegbetrag gleich handgerechneter Referenz |
| Grundpreis und Arbeitspreis getrennt | Verteilung auf Preisbestandteile, Zeitanteiligkeit | Summe der Positionen gleich Belegbetrag |
| Preiswechsel in der Periode | Gültigkeitsabgrenzung auf Tag und Stunde | Mengenschnitt am Stichtag stimmt |
| Abrechnungszeitraum wechselt | Periodenbildung und Verbrauchshochrechnung | Referenz aus realem Vorjahreszeitraum |
| Gerätewechsel mit Zählerwechsel | Registerzuordnung und Zählerstandsfortschreibung | Kein Mengenverlust, keine Doppelzählung am Wechseltag |
| Gerätewechsel mit Tarifwirkung | Zuordnungsmerkmale auf Anlage und Gerät | Alter Tarif bis Stichtag, neuer Tarif ab Stichtag |
| Messwertkorrektur nach Abrechnung | Nachberechnung und Delta statt Neuberechnung | Korrekturbeleg nur mit der Differenz |
| Ersatzwert wegen fehlender Messung | Ersatzwertbildung und deren Kennzeichnung | Wert ist als Ersatzwert erkennbar und plausibel |
| Stichtag um Mitternacht, Zeitumstellung | Zeitbezug, Sommer- und Winterzeit | Grenzfall liegt auf dem erwarteten Zeitstempel |
Die Klassen sind bewusst nach Rechenweg geschnitten, nicht nach Kundengruppe. Zwei Kunden mit unterschiedlichem Verbrauch prüfen dieselbe Logik. Zwei Klassen mit unterschiedlichem Stichtagsbezug prüfen verschiedene Logik.
Für Ersatzwerte gibt es eine rechtliche Leitplanke. Kann für die Abrechnung kein wahrer Messwert innerhalb der Fristvorgaben ermittelt werden, hat der Messstellenbetreiber im Einzelfall Ersatzwerte oder vorläufige Werte nach den anerkannten Regeln der Technik zu bilden. Bei wiederkehrenden Messwertausfällen muss er unverzüglich geeignete strukturelle Verbesserungsmaßnahmen einleiten (§ 55 Abs. 2 MsbG). Ein Testfall, der einen Ersatzwert stillschweigend als echten Messwert verbucht, übersieht damit eine Pflicht. Der Datenwert allein reicht als Prüfkriterium nicht.
Der Stichtagsfall verdient eigene Aufmerksamkeit
Die meisten Tariffehler entstehen an der Grenze. Ein Gerätewechsel, ein Preiswechsel und eine Messwertkorrektur können denselben Tag betreffen. Dann entscheidet die Reihenfolge der Verarbeitung über das Ergebnis. Der Normalfall verzeiht viel, der Grenzfall nichts.
Prüfbar wird das nur mit einer klaren Erwartung. Definieren Sie für jeden Grenzfall vorab, welcher Zustand gelten soll. Begründen Sie die Entscheidung aus dem Vertrag oder der Tarifvereinbarung. Erst danach wird simuliert. Wer erst rechnet und die Erwartung aus dem Ergebnis ableitet, hat nichts geprüft.
Ein zweiter Grenzfall betrifft die Preisänderung als Kommunikationsvorgang. Ist sich der Lieferant ein Recht zur einseitigen Preisänderung vorbehalten, muss er den Kunden rechtzeitig vor Ablauf einer Abrechnungsperiode informieren. Über Preisänderungen ist spätestens zwei Wochen vorher zu unterrichten, bei Haushaltskunden spätestens einen Monat vorher (§ 41 Abs. 5 EnWG). Damit hängt die Produktivsetzung an einem Termin, nicht nur an einem Datenstand. Ein Tarifsatz, der am 15. eines Monats scharf wird, ohne dass die Mitteilung fristgerecht verschickt wurde, ist damit ein Rechtsproblem. Der Rechenweg kann dabei einwandfrei sein.
Beispiel: eine Tarifänderung zum 1. April
Das folgende Beispiel ist ein vereinfachtes Lernmodell und nutzt synthetische Werte. Ein Lieferant ändert zum 1. April den Arbeitspreis eines Tarifs. Geplant sind:
- 1.450 Verträge im neuen Preisschema (synthetische Zahl).
- Stichtag 1. April, 00:00 Uhr.
- Eine abgeschlossene Abrechnungsperiode vom 1. Januar bis 31. März.
Getestet wird in vier Stufen. Erstens der Normalfall über die volle Periode, einmal mit dem alten und einmal mit dem neuen Preis, jeweils gegen eine handgerechnete Referenz. Zweitens der Stichtagsfall: drei Verträge mit einer Abrechnungsgrenze genau am 31. März, 24:00 Uhr, also am 1. April, 00:00 Uhr. Drittens fünf Verträge mit Gerätewechsel in der Periode. Viertens zwei Verträge mit nachträglicher Messwertkorrektur, deren korrigierter Wert eine bereits erzeugte Abrechnung betrifft.
Die Abrechnungssimulation liefert den Rechennachweis, weil sie ohne fortgeschriebenen Beleg arbeitet. Für die beiden Korrekturfälle reicht die Simulation allein nicht. Dort muss zusätzlich geprüft werden, ob im späteren Echtlauf nur die Differenz gebildet wird und nicht die volle Periode erneut in Rechnung geht.
Reconciliation: gegen was nachgerechnet wird
Ein Simulationsergebnis ist noch kein Nachweis. Der Nachweis entsteht erst aus dem Vergleich mit einer unabhängigen Referenz. Drei Referenzen sind praxistauglich:
- Handrechnung je Preisbestandteil. Menge mal Preis, getrennt für Leistung und Grundpreis, mit Zeitanteilen für die Teilstrecken.
- Bestandsabrechnung vor der Änderung. Die abgerechnete Vorperiode bleibt die Referenz. Der Normalfall muss ergebnisgleich bleiben, wenn sich am Rechenweg nichts geändert hat.
- Summenprobe über das Kollektiv. Summe über alle Testverträge als eine Zahl. Das Bündel wird über die Summe rechenbar.
Reconciliation wird in zwei Richtungen gefahren. Vorwärts: aus Menge und Preis wird der Betrag nachgerechnet. Rückwärts: aus dem Betrag werden Menge und anzuwendender Preis abgeleitet und gegen die Daten geprüft. Erst wenn beide Richtungen aufgehen, ist ein Verdreher in den Preisbestandteilen ausgeschlossen.
Dazu gehört die Prüfung, ob die Preisbestandteile richtig getrennt sind. Der Tarif muss Grundpreis und Arbeitspreis getrennt ausweisen, damit die Rechnung die geltenden Preise nachvollziehbar zeigt (§ 41 Abs. 1 Nr. 5 EnWG). Die Rechnung muss zusätzlich den ermittelten Verbrauch und die Art seiner Ermittlung nennen (§ 40 Abs. 1 EnWG). Ein Tarif, der nur einen Pauschalbetrag erzeugt, ist damit nicht abnahmefähig.
Abnahmekriterien für die Freigabe
Freigegeben wird ein Paket, nicht ein Wert. Tabelle 2 listet die Kriterien, die ein Tarif vor der Produktivsetzung erfüllen muss, getrennt nach Freigabegebenden.
| Kriterium | Nachweis | Freigabe |
|---|---|---|
| Gültigkeit ab/bis stimmt mit der Ankündigung | Simulationslauf am Stichtag | Fachbereich |
| Alle Preisbestandteile getrennt ausgewiesen | Belegpositionen der Simulation | Fachbereich |
| Zuordnungsregel trifft genau die geplante Menge | Trefferliste gegen Vertragsliste | Fachbereich |
| Kundenmitteilung fristgerecht versandt | Versandprotokoll mit Datum | Recht und Kundenservice |
| Simulationsbelege vom Echtbeleg trennbar | Belegart und Nummernkreis | Betrieb |
| Rückfallweg definiert und getestet | Rücknahme der Gültigkeit plus Nachtest | Betrieb |
| Monitoring nach Go-live benannt | Kennzahl, Schwelle, Meldeweg | Betrieb |
Der Rückfallweg ist kein Nebenaspekt. Eine Tarifgültigkeit lässt sich zurücknehmen, bis der erste Vertrag tatsächlich abgerechnet wurde. Danach nicht mehr, weil sonst Belege und Stammdaten auseinanderlaufen. Deshalb gehört zur Freigabe die Angabe eines Zeitpunkts, ab dem es kein Zurück gibt.
Folgen und Fehlerfälle
Falscher Zuordnungskreis. Die Preistabelle ist korrekt, aber die Zuordnungsregel trifft mehr Verträge als geplant. Folge: eine große Zahl falscher Rechnungen in einem Lauf. Erkennbar an der Trefferzahl vor dem ersten Echtlauf, nicht danach.
Stichtagsverschiebung um einen Tag. Der Preiswechsel wirkt ab dem 2. statt ab dem 1. April. Folge: eine Teilstrecke wird mit dem alten Preis gerechnet. Erkennbar nur über eine Erwartung am Grenzfall.
Doppelte Menge am Gerätewechseltag. Alter und neuer Zähler liefern Werte für denselben Tag. Folge: erhöhter Verbrauch ohne physikalischen Grund. Erkennbar über die Summenprobe über alle Wechselfälle.
Korrektur als Neuberechnung. Eine Messwertkorrektur nach der Abrechnung erzeugt eine zweite volle Periode statt der Differenz. Folge: doppelte Belastung des Kunden und eine Gutschriftrunde. Erkennbar nur in einem Test, der den Korrekturbeleg selbst prüft.
Ersatzwert ohne Kennzeichnung. Ein fehlender Messwert wird als echter Wert gebucht. Folge: Die Abrechnung wirkt vollständig, und die Rechnung weist eine Herkunft des Verbrauchs aus, die nicht stimmt. Die Pflicht zur Ersatzwertbildung nach § 55 Abs. 2 MsbG ist damit nicht abgebildet.
Fehlende Kundenmitteilung. Rechenweg korrekt, Frist versäumt. Folge: Der Kunde kann die Änderung nicht rechtzeitig prüfen und den Vertrag zum Wirksamkeitszeitpunkt ohne Frist kündigen (§ 41 Abs. 5 EnWG). Kein Rechenfehler, aber eine Rechtsfolge.
Typische Missverständnisse
„Ein grüner Simulationslauf ist der Nachweis.“ Der Simulationslauf zeigt das Verhalten des Rechenkerns auf den eingegebenen Daten. Erst der Vergleich mit einer unabhängigen Referenz macht daraus eine Aussage.
„Die Simulation ohne Abrechnungsauftrag ersetzt den Echtfall.“ Sie projiziert fehlende Messergebnisse aus vorhandenen Werten (SAP Learning). Genau deshalb kann sie einen fehlenden Messwert nicht aufdecken.
„Preiswechsel und Gerätewechsel testet man zusammen.“ Getrennt testen, gemeinsam prüfen. Ein gemeinsamer Fall zeigt einen Fehler, aber nicht seine Ursache.
„Der Tarif muss nur rechnen, die Mitteilung ist Marketing.“ Die Mitteilungspflicht ist Teil der Wirksamkeit der Änderung (§ 41 Abs. 5 EnWG) und damit ein Abnahmekriterium.
„Die Datenaufbereitung ist Sache des Messstellenbetreibers und damit außerhalb des Tariftests.“ Für die Abrechnung zählt, ob der Wert als wahrer Wert oder als Ersatzwert ankommt. Der Messstellenbetreiber muss die Daten aufbereiten und übermitteln (§ 60 Abs. 1 MsbG). Der Tariftest prüft, ob die Abrechnung diese Herkunft richtig verarbeitet.
Quellen und Pflegehinweis
Der Artikel stützt sich auf die SAP-Hilfe zur maschinellen Abrechnung und Simulation, auf die SAP-Lerninhalte zur Abrechnungssimulation, auf die §§ 40 und 41 EnWG sowie § 60 MsbG. Die Simulationseigenschaften stammen aus der SAP-Dokumentation und gelten für die dort beschriebene Ausprägung. Ob Belegart und Nummernkreis für Simulationsbelege getrennt geführt werden, ist eine Customizing-Entscheidung des eigenen Systems und muss im Testbericht nachgewiesen werden.
Bei jeder Änderung erneut zu prüfen sind: die Mitteilungsfristen nach § 41 EnWG, die Pflichtangaben der Rechnung nach § 40 EnWG, die Vorgaben zur Ersatzwertbildung nach § 55 MsbG sowie die Dokumentationsfassung der SAP-Hilfe zum eigenen Release. Die genannten Testklassen sind fachlich geschnitten und bleiben auch bei neuen Release-Ständen gültig. Trifft ein Tarifwechsel mit einem Lieferanten- oder Messstellenwechsel zusammen, kommen die Stammdatenprozesse hinzu. Prüfen Sie dafür die zu jenem Zeitpunkt gültige Fassung der Festlegung zu den Geschäftsprozessen für die Belieferung mit Strom.
Primärquellen zum Nachlesen
- SAP Help – Maschinelle Abrechnung und Simulation (SAP S/4HANA Utilities)help.sap.com
- SAP Help – Simulation (Abrechnungssimulation, SAP S/4HANA Utilities)help.sap.com
- SAP Learning – Performing a Billing Simulationlearning.sap.com
- § 41 EnWG – Verträge über die Belieferung von Letztverbrauchern mit Energiegesetze-im-internet.de
- § 40 EnWG – Verträge mit Letztverbrauchern, Rechnungsstellunggesetze-im-internet.de
- § 60 MsbG – Datenübermittlung; sternförmige Kommunikationgesetze-im-internet.de