Was Sie bei der Ausgabe von E-Rechnungen mit Smartforms und SAPscript beachten sollten
Häufig erreicht mich die Frage: „Wir wollen mit SAPscript- und Smartforms-Formularen E-Rechnungen ausgeben, geht das?“ Die gute Nachricht: Grundsätzlich geht das – allerdings mit einigen Einschränkungen und Aufwand. In diesem Beitrag erfahren Sie, was Sie konkret beachten müssen, wenn Sie E-Rechnungen mit den alten Technologien ausgeben möchten und auf welche Herausforderungen wir in vergangenen Projekten gestoßen sind.
Hintergrundinformation:
Das Thema E-Rechnungen ist auf lange Sicht für alle Unternehmen relevant. Durch das E-Rechnungsgesetz werden diese erstmals für Behörden verpflichtend – der Anfang einer neuen Ära! Die Formularumstellung auf Adobe Forms wird hingegen bei vielen Unternehmen auf die lange Bank geschoben. Wie lange der Support für SAPscript– und Smartforms-Formulare noch besteht und weitere Tipps zur Formularumstellung erhalten Sie übrigens hier.
Mit welchen Einschränkungen müssen Sie bei E-Rechnungen unter den „alten“ Technologien rechnen?
Grundsätzlich lässt sich dazu sagen: Die Technologien sind nicht auf das PDF/A-Format ausgelegt und auch SAP selbst ist kein Programm zur Dokumentenkonvertierung. Daher benötigen Sie die Adobe Document Services (ADS) und das bringt einige Herausforderungen mit sich. Natürlich gibt es auch die Alternative von Drittlösungen, welche außerhalb des SAP-Systems arbeiten oder in der Cloud gehostet sind. Dabei verlassen die sensiblen Rechnungsdaten aber die eigene Infrastruktur, was für viele Kunden keine Alternative ist.
Herausforderungen bei E-Rechnungen mit SAPscript und Smartforms
Manuelle PDF-Weiterverarbeitung
Um ein PDF zu generieren, müssen die OTF-Daten abgegriffen und umgewandelt werden. Das bewirkt, dass die Weiterverarbeitung (Druck, Fax, Mail, …) unterdrückt und somit manuell nachimplementiert werden muss. Die Standarddruckprogramme in diesen Technologien bieten dafür zwar Enhancementspots, dies birgt allerdings immer wieder Gefahren und Unsicherheiten.
Versteckte und undurchsichtige Logiken
Oft versteckt sich Logik im Formular, die Sie benötigen, um Rechnungswerte – wie z. B. die Konditionen – zu bestimmen. Diese Logiken können leicht übersehen werden, was zu inkorrekten Werten in den E-Rechnungsdateien im XML führen kann. Gerade im SAPscript-Umfeld werden Druck- bzw. Formulardaten erst bei der Generierung in eingebetteten FORM-Routinen beschafft. Diese Daten können später für die XML-Generierung nicht mehr nachvollzogen oder verwendet werden. Gleiches gilt im Smartforms-Umfeld. Die Logik-Knoten sind außerhalb des Formularbausteins nicht mehr einsehbar. Hier kommt es häufiger vor, dass diese Logik zweimal durchlaufen und damit auch doppelt gewartet werden muss, damit die richtigen Daten im E-Rechnungsformat landen.
Zusammenführen von PDF und XML im SAP nur mithilfe des ADS
Das Zusammenführen von PDF und XML ist auf dem SAP-System nur mithilfe der ADS möglich. Um XML und PDF überhaupt verschmelzen zu können, benötigen Sie PDF/A-Formate. Auch das Konvertieren von PDF in PDF/A-X-Formate geht nur mit ADS. Dieser wird auch für Adobe-Formulare benötigt. Damit sind die Systemvoraussetzungen für Adobe Forms sind dann übrigens schon geschaffen und die nötigen Schritte für eine Umstellung bereits getan.
Besondere Herausforderung bei SAPscript
In SAPscript gibt es keine Standard-Datenstruktur, das bedeutet: Sie müssen sich alle Daten manuell zusammensuchen. Besonders kritisch ist dies bei Tabellen und Konditionen, da diese in SAPscript dynamisch zusammengebaut werden. Außerdem können Sie das Coding bis auf einige Ausnahmen nicht wiederwenden, da dieses nicht gekapselt ist und nicht jede Formroutine doppelt durchlaufen werden sollte.
Besondere Herausforderung bei Smartforms
Bei Smartforms gibt es zwar eine Datenstruktur, die dem Formularbaustein übergeben wird. Diese eignet sich aber vom Aufbau nicht so gut für die Übertragung auf das E-Rechnungsformat. Dadurch müssen viele Daten aus der Struktur zusammengesammelt und anders strukturiert werden, sodass sie den Anforderungen des E-Rechnungsformats entsprechen.
Das Problem mit den Schriftarten bei ZUGFeRD
Die Hybridlösung in ZUGFeRD, in der XML in PDF eingebettet wird, stellt eine zusätzliche Herausforderung dar: Die Übertragung der Schriftarten. Beim X-Rechnungsstandard hingegen wird nach aktuellem Stand nur die XML übermittelt und keine PDF benötigt – die XML kann also losgelöst vom Formular generiert werden und dazu müssen keine Fonts transferiert werden. Aber auch hier eignen sie die Adobe Forms Druckprogramme besser.
Wenn Sie mit SAPscript oder Smartforms E-Rechnungen ausgeben, haben Sie verschiedene Schriftarten (Fonts) auf einer Rechnung – es besteht also kein einheitliches Layout. Das liegt daran, dass die Fonts, die für diese beiden Technologien genutzt werden, komplett unabhängig von denen auf dem Adobe Document Service (ADS) sind. Die Fonts für SAPscript und Smartforms sind im SAP-System installiert – eigentlich können Sie damit also ohne Probleme fröhlich Ihre Formulare basteln. Durch die PDF/A-Konvertierung sind wir nun aber in der Situation, dass auch der ADS mit ins Spiel kommt und die Fonts eingebettet werden müssen. Leider sind die Schriftarten, die im SAP-System vorhanden sind, nicht auch automatisch auf dem ADS installiert. Kundeneigene Schriftarten führen hier zu zusätzlichen Herausforderungen, weil auch diese korrekt im ADS installiert werden müssen.
Kurzer Vergleich zu Adobe Forms
Ich möchte gerne an dieser Stelle erwähnen: Bei Adobe Forms sind die Schriftarten auf dem ADS kein Problem – zur Not wird die Font automatisch ersetzt, weil sie bei Adobe Forms nicht auf dem ADS selbst liegen muss. Außerdem werden Code (Logik) und Formular bei Adobe Forms klar getrennt, sodass Sie keine versteckten Logiken haben (bis auf die Code-Initialisierung). Die Druckstruktur kann größtenteils für das Mapping auf das E-Rechnungsformat wiederverwendet werden und auch die Datenbeschaffung aus dem Standard-Druckprogramm kann wiederverwendet werden. Eine detailliertere Übersicht über die Vorteile von Adobe Forms finden Sie in unserem Whitepaper.
Ist Adobe Forms vielleicht doch eine Alternative für Sie?
Zusammenfassend lässt sich sagen: Ihre Grundvoraussetzung zur Erstellung von E-Invoice aus dem SAP-System ist ein ADS. Ansonsten kann das PDF nicht in PDF/A umgewandelt und die XML nicht angehangen werden. Mit Adobe Forms hingegen können passende PDFs bereits nativ erstellt werden – es ist sogar möglich, schon bei der initialen Generierung eine PDF/A anzufordern. So wird eine spätere Konvertierung überflüssig. SAPscript und Smartforms lassen sich zwar über einfache Bausteine in PDF umwandeln, für diese gibt es allerdings keine Garantie, dass der ADS sie zu PDF/A umwandeln kann. Das Thema der Schriftarten ist dabei ein nicht zu unterschätzender Aufwandsfaktor.
Prinzipiell könnten Sie sich also dank des noch langanhaltenden Supports in Bezug auf die Formularumstellung zurücklehnen und E-Rechnungen auch mit den alten Technologien ausgeben. Ich möchte Ihnen aber ans Herz legen, dass sich diese nicht dafür eignen und die SAP dies auch nicht empfiehlt. Falls Sie sich dennoch dafür entscheiden, ist unsere E-Rechnungslösung für SAP vielleicht interessant für Sie – diese kann auch für die alten Technologien umgesetzt werden.
Langfristig sind Sie aber definitiv mit Adobe Forms besser aufgestellt.
Konnte ich Ihre Fragen beantworten? Oder haben Sie weitere Fragen, wie Sie E-Rechnungen in den alten Technologien umsetzen können? Hinterlassen Sie gerne einen Kommentar unter diesem Beitrag oder schreiben Sie eine E-Mail an info@mind-forms.de. Ich freue mich auf den Austausch mit Ihnen!
