Lückenlose Rechnungsnummern - Bug oder Feature Request?
Immer wieder wird an uns die Anforderung gestellt, unbedingt lückenlose Rechnungsnummern erzeugen zu müssen, wenn der Webshop automatisch PDF-Rechnungen erzeugt und die Rechnungen direkt an den Käufer versendet. Nicht selten führen Lücken bei den Rechnungsnummern auch zu Diskussionen im Projekt. Es stellt sich die Frage, ob es sich dabei um einen Bug oder um einen kostenpflichtigen Feature Request handelt.
Denn gerade wenn es um die individuelle Anbindung von Online-Zahlungsanbietern geht, lassen sich Lücken nur mit zusätzlichem Entwicklungsaufwand vermeiden.
Wann ist eine Bestellung eine Bestellung?
Zuerst einmal stellt sich die Frage, wann eine Bestellung als abgeschlossen gilt und ab wann sie als verbindlich betrachtet wird. Nach der Auftragsbestätigung? Oder gibt es erstmal nur eine unverbindliche Auftragseingangsbestätigung? Nach erfolgreicher Zahlung? Wie sieht eigentlich der Checkout-Prozess im Projekt aus? Diese Fragen sind manchmal nur vom Kunden zu beantworten und von Projekt zu Projekt unterschiedlich.
Die Abgabe einer Bestellung führt nicht immer direkt zu einem verbindlichen Auftrag.
Szenario 1: Bestellung abgeschlossen, Zahlung nachgelagert
Der einfachste Fall für den lückenlosen Nummernkreis, weil eine Bestellung auch dann zustande gekommen ist, wenn der Zahlungsvorgang abgebrochen wurde oder aber die Zahlung verweigert wird. Das kann vorkommen, wenn die Kreditkarte des Bestellers nicht ausreichend gedeckt ist oder aber der Payment Provider das Zahlungsausfallsrisiko im konkreten Fall anhand des Scorings als zu hoch erachtet. Der Besteller bekommt seine Rechnung in jedem Fall. Der Shopbetreiber hat aber unter Umständen dann das Problem, die Zahlung auf anderem Wege zu veranlassen, was in jedem Fall zu Mehraufwänden führt und nicht selten auch zu einer stornierten Rechnung.
Szenario 2: Bestellung erst abgeschlossen wenn Zahlung erfolgt ist
In diesem Fall wird die Bestellung erst dann als solche verbucht, wenn die Online-Zahlung erfolgreich abgeschlossen wurde. Folglich wird die Rechnung auch erst dann erzeugt. Damit sind zwar die Rechnungsnummern lückenlos, allerdings bleiben abgebrochene Bestellungen hängen und müssen explizit bearbeitet werden, wenn der Online-Händler nicht auf seinen Umsatz verzichten will. Auch hier entsteht damit wieder ein vermeidbarer Mehraufwand beim Shopbetreiber.
Erschwerend kommt hinzu, dass nicht alle Online Payment Provider eine nachträgliche aktualisierung des Zahlungsvorgangs ermöglichen: damit Bestellung und Zahlungsvorgang eindeutig zugeordnet werden können, muss die Bestellnummer der Transaktion übergeben werden. Dies ist lösbar, wenn eine Referenznummer vor der Zahlung erzeugt wird, bedeutet aber Mehraufwand bei der Implementierung.
Szenario 3: Bestellung angelegt, Zahlung nachgelagert, Rechnungserstellung nachgelagert
Der Kompromiss der beiden vorhergehenden Zahlungs-Szenarien, der allerdings mit einem erhöhten Entwicklungsaufwand verbunden ist.
Es wird in jedem Fall eine Bestellung angelegt mit einem vorläufigen Status, die Online-Zahlung wird nachgelagert. Bei erfolgreicher Zahlung (Kreditkarte, PayPal, Sofortüberweisung o.ä.) wird die Rechnung erzeugt und die Bestellung mit der Zahlungsreferenz aktualisiert. Damit ist sowohl am Datensatz des Zahlungsanbieters die Bestellnummer vorhanden, als auch in der Bestellung die Transaktionsummer der Zahlung.
Für den Fall, dass die Online-Zahlung abgelehnt wird, muss im Webshop ein erweiterter Checkout-Prozess ausglöst werden. Der Kunde muss jetzt eine alternative Zahlart wählen können. Das kann potentiell die Gesamtkosten und das ursprünglich geplante Handling der Bestellung beeinflussen, beispielsweise durch Nachnahmegebühren oder durch Lieferung erst nach Zahlungseingang bei Zahlart Vorkasse.
Erst wenn der vollständige Bezahlprozess mit allen Alternativen erfolgreich durchlaufen wurde, wird die Bestellung aktualisiert und eine Rechnung erstellt.
In jedem der 3 Szenarien muss jedoch ein eigener Rechnungsnummernkreis mitgepflegt werden (Achtung: beim hochzählen in der Datenbank auf Transaktionssicherheit und Write-Lock achten).
Könnte es nicht einfacher sein?
Es kann. Denn es ist eine Mär, dass Rechnungsnummern lückenlos vergeben sein müssen.
Es spricht überhaupt nichts dagegen, beispielsweise die Bestellnummer als Basis für die Rechnungsnummer zu nehmen, was auch insgesamt das Handling des Bestellprozesses vereinfacht.
Für abgebrochene Zahlungen kann sich dann jeder Shopbetreiber für die jeweils sinnvollste Lösung entscheiden. Stornierte Rechnungen wird es ohnehin geben, alleine schon durch das Widerrufsrecht für Endverbraucher nach dem Fernabsatzgesetz muss sich der Online-Händler auf Retouren vorbereiten, sowohl Mental als auch von den Abläufen her.
Was genau alles in einer Rechnung stehen muss und welche Pflichtangaben es wirklich gibt, hat die IHK Region Stuttgart zusammengefasst. Dort steht auch wörtlich:
"Nach einer Rundverfügung der OFD Koblenz vom 11. Februar 2008 ist zudem keine zahlenmäßige Abfolge der ausgestellten Rechnungsnummern zwingend, da es lediglich um die Einmaligkeit der erteilten Rechnungsnummer gehe."
Fazit: It's a feature, not a bug ;-)