Ein Gespräch über KSeF, das polnische E-Rechnungssystem, im Online-Shop beginnt fast immer mit der Frage „welches Plugin sollen wir installieren”. Eine Frage nach dem Werkzeug, gestellt in einem Moment, in dem noch niemand die Fragen zum Prozess beantwortet hat. Aus meiner Sicht, als jemand, der seit Jahren Shops mit Finanzsystemen verbindet, ist das Plugin das letzte Teil in diesem Puzzle. Nicht das erste. Und die Dinge, die später am meisten kosten, entstehen aus Entscheidungen, die lange getroffen wurden, bevor überhaupt jemand den Integrationscode angefasst hat.
Inhaltsverzeichnis
Ein Plugin ist eine Schnittstelle, kein Rechnungsprozess
Eine Shop-Erweiterung baut das Dokument und schickt es an das Gateway. Schön und gut. Sie entscheidet nur nicht, wann dieses Dokument überhaupt entstehen soll, und genau darum geht es bei der Umsetzung. Im E-Commerce sind die Bestellung, die Verbuchung der Zahlung und die Warenausgabe drei getrennte Ereignisse, zeitlich auseinandergezogen und mit völlig unterschiedlichen Risiken behaftet.
Der häufigste Fehler? Der Shop stellt die Rechnung im Moment der Bestellung aus, die Überweisung kommt nie an, und im Register liegt bereits ein Dokument, das korrigiert werden muss. Das andere Extrem, also erst nach dem Versand zu fakturieren, kann bei Bestellungen um den Monatswechsel herum die Abrechnungsperioden durcheinanderbringen.
Die sinnvolle Entscheidung besteht darin, den Auslöser für die Rechnungsstellung in der Geschäftslogik zu definieren, serverseitig, mit ausdrücklich aufgeschriebenen Ausnahmen: Vorkasse, Nachnahme, Zahlungsziel, teilweise ausgeführte Bestellung. Die Einstellungen des Plugins bilden diese Entscheidung dann ab, statt sie für uns zu treffen. Erst an diesem Punkt ist die Anbindung des Shops an KSeF keine Frage der Konfiguration mehr, sondern eine Frage des Entwurfs.
Kundendaten: woher soll der Shop wissen, an wen er fakturiert
Das System bedient den Handel zwischen Unternehmen, und der Verkauf an Verbraucher folgt einer anderen Logik. Der Shop muss diese Wege bereits auf Ebene des Warenkorbs trennen, bevor der Kunde auf „bestellen” klickt. Eine Steuernummer nachträglich an eine abgeschlossene Bestellung zu heften, ist der direkte Weg zu Fehlern und Korrekturen.
Ein NIP-Feld im Formular allein? Zu wenig. Nötig sind eine Prüfung von Format und Prüfsumme, eine Länderprüfung und die Stimmigkeit mit den übrigen Adressdaten, denn ein Kunde, der eine Firmennummer zu einer privaten Lieferadresse einträgt, ist Alltag. Dazu kommen ausländische Kunden, EU-Umsatzsteuer-Identifikationsnummern, das OSS-Verfahren und der Verkauf über Marktplätze. Jede dieser Zuordnungen legt noch etwas obendrauf.
Ein eigenes Thema, meist deutlich unterschätzt: Konten, die vor Jahren angelegt wurden, mit unvollständigen oder veralteten Daten. Bei der Migration müssen sie ergänzt, markiert oder bewusst von der automatischen Rechnungsstellung ausgenommen werden. Sonst erzeugt die Automatik einen Stapel Dokumente, die später niemand verteidigen kann.
KSeF im E-Commerce und die Systeme, die Sie bereits haben
Der Shop ist selten der einzige Ort, an dem eine Rechnung entsteht. Daneben laufen das Lager, ein ERP, ein Rechnungsprogramm und das Steuerbüro, und jedes dieser Systeme durfte historisch ein Dokument ausstellen. Nach dem Anschluss an das zentrale Register hört diese Mehrgleisigkeit auf, eine kleine Unbequemlichkeit zu sein, und wird zu einem echten Risiko.
Die klassische Störung bei der Umsetzung ist der doppelte Versand. Dasselbe Dokument geht aus dem Shop und aus dem Lagersystem an das Gateway, weil niemand festgelegt hat, wer die Quelle der Wahrheit ist. Das kommt meist im Nachhinein heraus, beim Abgleich der Umsätze für den Zeitraum. Derselben Frage entkommt man auch bei Projekten wie der Anbindung an Subiekt und Optima nicht, bei der die Dokumentennummerierung einen einzigen Eigentümer haben muss.
Die architektonische Entscheidung klingt banal und tut organisatorisch weh: ein einziger Punkt, an dem Dokumente ausgegeben werden, alle übrigen Systeme übernehmen ausschließlich Nummer und Status. Die Integration stützt sich besser auf eine Ereigniswarteschlange als auf einen synchronen Aufruf, denn der Abschluss einer Bestellung darf nicht auf die Antwort eines externen Gateways warten. Der Kunde soll die Kaufbestätigung sehen, unabhängig davon, was im Hintergrund weiter passiert.
Störungen, Limits und Sicherheit auf der Serverseite
Das Gateway ist manchmal nicht erreichbar, und der Shop darf deswegen den Verkauf nicht anhalten. Nötig sind eine dauerhafte Dokumentenwarteschlange, Wiederholungen mit wachsendem Abstand und ein deutlicher Status „wartet auf Versand”, sichtbar für das Team und nicht nur in einem technischen Log irgendwo auf dem Server.
Was tatsächlich überwacht werden muss
- Dokumente, die länger als eine festgelegte Schwelle in der Warteschlange liegen,
- Dokumente, die bei der Strukturprüfung abgelehnt wurden, samt gespeichertem Fehlertext,
- bevorstehender Ablauf von Tokens, Zertifikaten und Sitzungen,
- die Verzögerung zwischen dem Erstellen einer Rechnung und der Vergabe ihrer Nummer im System,
- Abweichungen in der Anzahl der Dokumente zwischen Shop und Finanzsystem für denselben Zeitraum.
Ohne Benachrichtigungen fällt jedes dieser Probleme erst beim Monatsabschluss auf. Also genau dann, wenn Korrekturen am teuersten sind und unter Zeitdruck gemacht werden.
Zugangsdaten in einer öffentlich erreichbaren Anwendung
Der Zugang zum System bedeutet echte Berechtigungen für die Dokumente des Unternehmens. Ihn in der Optionstabelle im Klartext aufzubewahren, ist eine Zeitbombe. Ein Shop ist eine Anwendung, die der Welt ausgesetzt ist und täglich gescannt wird, ein völlig anderes Risikoprofil als ein internes ERP hinter einer Firewall.
Ein vernünftiges Muster verlagert den Umgang mit Zugangsdaten in eine Zwischenschicht in einer vertrauenswürdigen Umgebung. Der Shop veröffentlicht dann nur das Geschäftsereignis und kennt keinerlei Geheimnisse. Bei höherem Verkehr und umfangreicher Logik endet das mitunter in der Entscheidung für den Umstieg auf ein eigenes Backend. Aufbewahrung der Logs und Archivierung der Dokumente werden getrennt entworfen, denn das sind Anforderungen, die kein Plugin für jemanden erledigt.
Korrekturen, Retouren und Reklamationen, also der Shop-Alltag
Eine Warenrücksendung im Onlinehandel ist die Regel, kein Zwischenfall. Wenn das so ist, muss das Korrigieren genau im selben Maß automatisiert sein wie das Ausstellen. Sonst landet die gesamte Ersparnis aus der Automatisierung auf dem Schreibtisch der Buchhaltung.
Eine Korrektur verweist auf die Nummer des ursprünglichen Dokuments, also muss diese Nummer dauerhaft mit der Bestellung in der Datenbank des Shops verknüpft sein. Nicht im Integrationslog, das nach einem Monat rotiert wird. Ich habe das ein paar Mal gesehen – die Lücke zeigt sich erst bei der ersten ernsthaften Retoure, und dann ist es bereits unangenehm.
Teilretouren, Warentausch und nach dem Verkauf gewährte Rabatte erfordern die Abbildung der Bestellpositionen, nicht nur des Gesamtbetrags. Eine misslungene Umsetzung erkenne ich an einem Symptom: Korrekturen werden von Hand in einem anderen Programm erstellt und kehren nie in den Shop zurück. Die Daten an beiden Orten beginnen dann, ein Eigenleben zu führen.
Kostenstruktur von Umsetzung und Betrieb
Die Plugin-Lizenz ist hier der kleinste Posten und zugleich der am lautesten diskutierte. Das Budget treiben drei andere Dinge: die Zahl der anzubindenden Systeme, die Qualität der historischen Daten und die Zahl der Ausnahmen im Verkaufsprozess, also alles, was von einer gewöhnlichen, im Voraus bezahlten Bestellung abweicht.
Der Betrieb kostet im Rhythmus der Änderungen, nicht gleichmäßig. Aktualisierungen des Dokumentenschemas, Änderungen an der Schnittstelle des Gateways, Shop-Migrationen, der Wechsel von Zahlungsanbietern, Aktualisierungen der Plugins selbst – jede dieser Sachen kann die Integration genau dann stören, wenn niemand damit rechnet.
Deshalb sind eine Testumgebung und ein wiederholbares, reproduzierbares Deployment kein Luxus, sondern der Weg dahin, dass eine einzelne Änderung den Verkauf nicht für mehrere Stunden stoppt. Und der größte versteckte Kostenblock bleibt ohnehin die Handarbeit der Buchhaltung in einer Situation, in der die Automatik ausschließlich den glücklichen Pfad bedient und alle Abweichungen bei Menschen landen.
Fazit: das Plugin am Ende, nicht am Anfang
Die Reihenfolge, die sich bewährt, ist der intuitiven entgegengesetzt. Zuerst die Karte des Verkaufsprozesses und die Festlegung der Quelle der Wahrheit für Dokumente, dann der Entwurf von Integration und Fehlerbehandlung, und das konkrete Werkzeug wählen wir am Ende, wenn bereits klar ist, was es tun soll.
Die Anzeichen, dass ein Projekt in die falsche Richtung läuft, sieht man früh: niemand ist auf der Geschäftsseite Eigentümer des Prozesses, es gibt weder Monitoring noch Benachrichtigungen, Korrekturen entstehen außerhalb des Systems. Jedes dieser Symptome lässt sich beheben. Nur ist es billiger, das vor dem Start zu tun als nach dem ersten Monatsabschluss.
Bei Web Systems entwerfen wir seit 2006 Integrationen, Automatisierungen und B2B-Systeme rund um Online-Shops. Wenn Sie die Umsetzung eines Online-Shops planen, Ihren Dokumentenfluss ordnen oder über die Modernisierung Ihres Shops und der Systeme darum herum nachdenken, schreiben Sie uns und lassen Sie uns über den Umfang sprechen.
