SAP Business One automatisieren und anbinden: was laut SAP geht

Was lässt sich an SAP Business One automatisieren?

An SAP Business One lassen sich Belegfreigaben, Benachrichtigungen, Feldvorbelegungen, Datenimporte und der Austausch mit anderen Systemen automatisieren. Ein Teil davon ist Standard und wird nur eingerichtet. Der andere Teil läuft über die Programmierschnittstellen, die SAP für Partner und Kunden dokumentiert.

Die Unterscheidung ist wichtig, weil sie über Aufwand und Betrieb entscheidet. Eine Genehmigungsvorlage richtet Ihr Team oder Ihr Partner in der Administration ein. Ein Abgleich mit dem Webshop oder ein Rechnungseingang aus dem Postfach braucht dagegen ein Programm außerhalb von SAP Business One, das über eine Schnittstelle schreibt.

Service Layer oder DI API: welche Schnittstelle passt?

Für neue Anbindungen ist der Service Layer der naheliegende Weg, die DI API bleibt für bestehende Add-ons und Sonderfälle. SAP beschreibt den Service Layer als neue Generation der Erweiterungsschnittstelle. Er arbeitet über HTTP und OData, OData V3 unter /b1s/v1 und OData V4 unter /b1s/v2.

Beide Wege greifen auf denselben Kern zu. Laut SAP nutzt der Service Layer intern den DI Core, also dieselbe Komponente wie die DI API. Objekte und Felder sind daher gleich definiert, und die Geschäftslogik wie Steuerberechnung und Buchung läuft in beiden Fällen im System.

Bis Release 10.0 PL01 lief der Service Layer nur mit der Version für SAP HANA. Seitdem unterstützt er laut SAP auch SAP Business One auf Microsoft SQL Server. Wer noch eine ältere Version betreibt, prüft deshalb zuerst den Versionsstand.

Laut SAP sind neu angelegte benutzerdefinierte Felder, Tabellen und Objekte im Service Layer erst nach einem Neustart des Service Layer verfügbar. Planen Sie das bei jeder Feldänderung ein.

Wie arbeitet eine Anbindung über den Service Layer im Betrieb?

Eine Anbindung meldet sich mit Firmendatenbank, Benutzer und Passwort an und arbeitet dann mit einer Sitzung. Der Service Layer gibt dafür das Cookie B1SESSION zurück, das bei jeder weiteren Anfrage mitgeschickt wird. Die Antwort auf die Anmeldung enthält einen Wert für das Sitzungs-Zeitlimit, im Beispiel der SAP-Dokumentation 30. Danach antwortet der Service Layer mit dem Fehler „Invalid session or session already timeout“. Seit 10.0 FP 2305 ist laut SAP auch die Anmeldung mit einem Windows-Domänenkonto möglich.

Mehrere Schritte lassen sich in einer Batch-Anfrage bündeln. Eine Transaktion reicht aber nie über mehrere Anfragen hinaus. Wer etwa einen Auftrag anlegt und danach in einer zweiten Anfrage eine Anzahlung bucht, muss den Fall abfangen, dass nur der erste Schritt gelingt.

Für gleichzeitige Änderungen gibt es seit 10.0 FP 2102 ein ETag. Es verhindert laut SAP, dass ein Programm blind die Änderung eines anderen überschreibt. Das ist wichtig, sobald Ihr Team im Client und ein Programm über die Schnittstelle am selben Beleg arbeiten.

• Anmeldung mit eigenem Benutzer je Anbindung, nicht mit dem Benutzer „manager“
• Sitzung wiederverwenden und bei Ablauf neu anmelden, statt für jeden Datensatz neu einzuloggen
• Fehlerantworten mit Code und Text protokollieren, damit Ihr Team sieht, welcher Beleg hängt
• Rechte des Benutzers auf die Belegarten begrenzen, die der Ablauf wirklich braucht

Webhooks: SAP Business One meldet Änderungen selbst

Ab SAP Business One 10.0 FP 2602 kann der Service Layer andere Systeme per Webhook benachrichtigen, wenn ein Beleg angelegt oder geändert wird. Vorher mussten Anbindungen regelmäßig nachfragen, ob sich etwas getan hat. Die Zustellung übernimmt laut SAP ein eigener Dienst, der Webhook Messenger Service.

Webhooks sind je Firma standardmäßig ausgeschaltet und werden laut SAP über die Firmeneinstellung EnableWebhook eingeschaltet. Ausgelöst werden sie auch durch Belege, die im Client, im Web Client oder über die DI API entstehen. Welche Ereignisse es gibt, liefert der Ereigniskatalog. Er umfasst Systemobjekte sowie benutzerdefinierte Objekte und Tabellen, bei Aufträgen etwa Anlegen, Ändern, Löschen, Schließen, Stornieren und Wiedereröffnen.

• Die Ziel-URL muss HTTPS nutzen, das Zertifikat muss zum Hostnamen passen.
• Der Empfänger muss standardmäßig innerhalb von 10 Sekunden antworten.
• Bei Fehlern versucht der Dienst es bis zu fünfmal mit wachsendem Abstand von 2 bis 32 Sekunden, danach gilt die Meldung als fehlgeschlagen.
• Doppelte Meldungen sind nach Wiederholungen möglich. SAP empfiehlt, sie über die Ereignis-ID zu erkennen.
• Kommen Meldungen aus mehreren Firmendatenbanken, ist die Reihenfolge laut SAP nicht garantiert.

Ein fehlgeschlagener Webhook wird nicht weiter zugestellt. Ein regelmäßiger Abgleich als Sicherheitsnetz gehört deshalb in jede Anbindung, die sich auf Webhooks stützt.

Genehmigungen, Warnungen und benutzerdefinierte Werte: was der Standard schon kann

Viele Abläufe brauchen keine Schnittstelle, sondern nur die richtige Einrichtung im Standard. Genehmigungsverfahren gibt es laut SAP für Verkaufs-, Einkaufs- und Bestandsbelege. Erfüllt ein Beleg die Bedingung einer Genehmigungsvorlage, wird er als Entwurf mit dem Status „Ausstehend“ geparkt. Die festgelegten Genehmigenden erhalten eine Anforderung, auf Wunsch auch per E-Mail, und können stufenweise oder gesammelt im Entscheidungsbericht freigeben.

Warnungen beruhen auf gespeicherten Abfragen. Sie legen fest, welche Benutzer die Meldung erhalten, mit welcher Priorität und wie oft sie wiederholt wird.

Benutzerdefinierte Werte, früher Formatted Search genannt, füllen ein Feld aus einer gespeicherten Abfrage. Seit Release 10.0 kann ein Feld laut SAP bei Änderungen in bis zu fünf anderen Feldern neu berechnet werden. Zusammen mit benutzerdefinierten Feldern lassen sich so eigene Prüf- und Vorschlagslogiken abbilden, ohne Programmcode im Client.

Belege, die über die Schnittstelle angelegt werden, laufen nur dann durch das Genehmigungsverfahren, wenn in den allgemeinen Einstellungen auf der Registerkarte Geschäftspartner zusätzlich die Option „Enable Approval Process in DI“ gesetzt ist. Der Service Layer meldet dann im Antwortkopf, welcher Entwurf entstanden ist. Ohne diesen Haken bucht eine Anbindung an der Freigabe vorbei.

E-Rechnung und DATEV: was SAP Business One mitbringt

Für Deutschland bringt SAP Business One einen Import-Assistenten für elektronische Eingangsbelege und eine DATEV-FI-Schnittstelle mit. SAP nennt XRechnung und ZUGFeRD als gängige Formate und verweist für die Pflicht zum Empfang elektronischer Rechnungen auf das Wachstumschancengesetz. Die Einrichtung läuft laut SAP über die Belegeinstellungen, den Electronic Document Service und den Electronic Document Import Wizard.

Der Import-Assistent erzeugt aus XML-Dateien Entwürfe für Eingangsrechnungen, Gutschriften, Anzahlungsrechnungen, Wareneingänge und Bestellungen. Er sucht dabei nach der zugehörigen Bestellung und, wenn diese bereits per Wareneingang geschlossen ist, nach dem Wareneingang. ZUGFeRD-PDFs mit eingebettetem XML liest er laut SAP ab 10.0 FP 2502 direkt ein. Für PDF-Rechnungen ohne XML gibt es den SAP-Dienst Document Information Extraction als Quelle für denselben Assistenten.

Die DATEV-FI-Schnittstelle exportiert Buchungen, Ausgangs- und Eingangsrechnungen sowie Sachkonten, Kunden und Lieferanten, mit Vorlagen für SKR03 und SKR04 und einer Zuordnung der Steuerschlüssel. Sie bietet zwei Varianten: alle Buchungen eines Zeitraums, wenn die Buchhaltung in SAP Business One läuft, oder nur ausgewählte Buchungen, wenn die Steuerberatung in DATEV bucht. Der Export erfolgt laut SAP immer als Bruttobuchung.

• Prüfpunkt Version: Welche XRechnung-Version unterstützt wird, nennt SAP im Hinweis 2957995.
• Prüfpunkt Rückweg: Buchungen, die die Steuerberatung in DATEV erfasst, müssen laut SAP für den Abschluss manuell in SAP Business One nachgebucht werden.
• Prüfpunkt Stammdaten: Exportiert werden nur neue oder geänderte Stammdaten, bei denen das benutzerdefinierte Feld „BD: Primary input Yes/No“ auf Ja steht.
• Ob Ihr Ablauf steuerlich passt, stimmen Sie mit Ihrer Steuerberatung ab.

Welcher Weg passt zu welchem Ablauf?

Die Wahl hängt davon ab, ob der Ablauf im System bleibt oder ein anderes System beteiligt ist. Die Tabelle zeigt typische Abläufe im Mittelstand und den Weg, den die SAP-Dokumentation dafür hergibt.

Mehrere Firmen und Lizenzen: die zwei Prüfpunkte vor dem Start

Arbeiten die Gesellschaften einer Gruppe in getrennten Firmendatenbanken, nennt SAP für die Vorgänge zwischen ihnen eine eigene Intercompany Integration Solution. Sie verbindet laut einer SAP-Produktunterlage von 2020 mehrere SAP-Business-One-Datenbanken und automatisiert konzerninterne Vorgänge wie die Verteilung von Stammdaten und die Konsolidierung. Ob die Lösung für Ihre Version und Lokalisierung verfügbar ist und was sie kostet, klären Sie mit Ihrem SAP-Partner.

Die zweite Frage ist die Lizenz. SAP Business One wird laut SAP nach Named User lizenziert. Ein Named User ist jede Person, die direkt oder indirekt auf die Software zugreifen darf. Benutzernamen dürfen nicht geteilt werden, und die Anmeldebeschränkung gilt laut Lizenzleitfaden auch für die DI API und für Lizenzen mit indirektem Zugriff.

Für eine Anbindung heißt das: Jedes Programm meldet sich mit einem SAP-Business-One-Benutzer an und braucht eine passende Lizenz. Ob Personen, die nur über ein Portal oder eine Freigabe-App mit dem System arbeiten, eigene Lizenzen benötigen, regelt Ihr Vertrag. Diese Frage gehört vor den Bau, nicht danach.

Eine Lizenz ist laut SAP nicht an eine Firmendatenbank gebunden. Wer mehrere Gesellschaften anbindet, zählt deshalb Benutzer und nicht Datenbanken.

Wo die Grenzen liegen und wann der Partner oder ein Add-on besser passt

Eine eigene Anbindung ersetzt nicht die Arbeit Ihres SAP-Partners. Lokalisierung, Updates, Lizenzen und die Einrichtung von Genehmigungen, DATEV-Export und E-Belegen liegen beim Partner. Eine Anbindung von außen lohnt sich dort, wo Daten aus anderen Systemen kommen oder Menschen ohne SAP-Client beteiligt sind.

Ein fertiges Add-on ist oft die bessere Wahl, wenn viele Unternehmen genau denselben Ablauf haben und das Add-on für Ihre Version freigegeben ist. Eine eigene Anbindung passt besser, wenn der Ablauf mehrere Systeme berührt, Ihre Regeln speziell sind oder Sie die Logik beim nächsten Versionswechsel nicht neu kaufen wollen.

• Die DTW übernimmt laut SAP keine abgeschlossenen Vorgänge, sondern nur Stammdaten, offene Belege und Eröffnungssalden.
• Der Service Layer kennt keine Transaktion über mehrere Anfragen.
• Neue benutzerdefinierte Felder erfordern einen Neustart des Service Layer.
• Webhooks gibt es erst ab 10.0 FP 2602, ältere Stände brauchen einen zeitgesteuerten Abgleich.
• Die DI API ist eine Windows-Bibliothek ohne Multithreading und eignet sich schlecht für viele parallele Anfragen.

Ablauf in 7 Schritten

1. 01
   Version und Datenbank feststellen

   Release, Feature Package, SQL Server oder SAP HANA und Lokalisierung im Info-Fenster ablesen. Davon hängen Service Layer, Webhooks und E-Beleg-Import ab.

2. 02
   Einen Ablauf auswählen

   Den Ablauf mit der meisten Handarbeit und klaren Regeln wählen, etwa Eingangsrechnungen oder Aufträge per E-Mail.

3. 03
   Standard zuerst prüfen

   Mit Ihrem Partner klären, ob Genehmigungsvorlage, Warnung, benutzerdefinierter Wert oder Import-Assistent den Ablauf schon abdecken.

4. 04
   Lizenz und Benutzer klären

   Technischen Benutzer, Lizenztyp und Rechte festlegen und die Frage nach Personen ohne eigene Lizenz mit dem Vertrag abgleichen.

5. 05
   Prototyp in der Testfirma

   Den Ablauf in einer Kopie der Firmendatenbank auf echten Daten bauen, mit Entwürfen statt direkter Buchung.

6. 06
   Fehlerfälle und Überwachung

   Abgebrochene Batch-Anfragen, doppelte Webhooks und abgelaufene Sitzungen testen und eine Meldung an Ihr Team einrichten.

7. 07
   Betrieb übernehmen

   Vor jedem Update von SAP Business One die Anbindung in der Testfirma prüfen, Feldänderungen mit Neustart des Service Layer planen.

Häufige Fragen