Wer nach SAP Business One Entwicklung sucht, steht meist vor derselben Frage: Lässt sich das System an unsere Abläufe anpassen, ohne dass wir uns eine Sonderlösung einhandeln, die jedes Update bremst? Die kurze Antwort lautet: ja, aber in Stufen. Zwischen einem zusätzlichen Feld auf dem Kundenstamm und einem eigenen Add-on liegen Welten, was Aufwand, Risiko und Folgekosten angeht.
Diese Seite ordnet die Möglichkeiten für Mittelständler in Deutschland: Was bringt der Standard mit, wann lohnt die Personalisierung von SAP Business One, wie entsteht ein individuelles Modul für SAP Business One, und worauf achten Sie bei der Auswahl des Entwicklers?
Der Grundsatz: so viel Standard wie möglich
SAP Business One ist als ERP-Kern gedacht, der erweitert wird. SAP Learning beschreibt das System genau so: als Kern, der sich mit KI, maschinellem Lernen und Cloud-Diensten der SAP Business Technology Platform (BTP) ausbauen lässt, mit Vorlagen für intelligente Automatisierung über den Business Accelerator Hub und SAP Build. Anpassung ist also vorgesehen, sie sollte aber geordnet erfolgen.
Eine bewährte Reihenfolge, von günstig und sicher bis aufwendig:
- Prozess ändern: Manchmal ist der Standardablauf besser als die gewachsene Gewohnheit. Das kostet nichts und altert nicht.
- Paramétrage und Benutzerdefinition im System selbst.
- Fertige Erweiterungen von Partnern, besonders für Branchen und Länder.
- Integrationsszenarien für die Anbindung anderer Systeme.
- Individualentwicklung mit SDK und Service Layer.
Jede Stufe darf erst genommen werden, wenn die vorherige nachweislich nicht reicht. Dieses Prinzip schützt Ihr Budget und Ihre Updatefähigkeit.
Stufe 1: Anpassung im System ohne Programmierung
Das Einführungsmaterial von SAP Learning nennt als Werkzeuge der Anpassung benutzerdefinierte Felder (UDF), Tabellen (UDT), Objekte (UDO) und Werte (UDV) sowie SQL-Abfragen, Alerts und Workflows für Freigaben. Damit lässt sich in der Praxis erstaunlich viel erledigen.
| Werkzeug | Typischer Einsatz | Eingriffstiefe |
|---|---|---|
| Benutzerdefinierte Felder (UDF) | Zusatzinformationen auf Stammdaten und Belegen, etwa Projektnummer, Kundenreferenz, Chargenhinweis | gering |
| Benutzerdefinierte Werte (UDV) | Auswahllisten und vorbelegte Werte, damit Erfassungen einheitlich bleiben | gering |
| Benutzerdefinierte Tabellen (UDT) | Eigene Datensammlungen, die der Standard nicht kennt, zum Beispiel Prüfprotokolle oder Zuordnungstabellen | mittel |
| Benutzerdefinierte Objekte (UDO) | Eigene Stammdaten- oder Belegarten mit Maske und Verknüpfung | mittel |
| SQL-Abfragen | Auswertungen und Hilfsansichten, die Anwender direkt im System aufrufen | gering |
| Alerts | Benachrichtigung bei Schwellen, Fristen oder Ausnahmen | gering |
| Freigabe-Workflows | Genehmigungsstufen für Bestellungen, Rabatte, Zahlungen | gering bis mittel |
Der Vorteil dieser Stufe: Sie arbeitet mit Bordmitteln, die SAP selbst vorsieht. Wer hier sauber vorgeht, bleibt nahe am Standard. Ein Beispiel aus dem deutschen Mittelstand: Ein Großhändler will auf jeder Auftragsbestätigung eine Zusatzinformation für die Spedition führen und Aufträge über einer bestimmten Rabattgrenze vom Vertriebsleiter freigeben lassen. Beides ist mit Feldern und einem Workflow lösbar, ohne eine Zeile Code.
Die fachliche Seite gehört dazu: Wer festlegt, welche Felder es gibt und wie sie heißen? Ohne ein klares Datenmodell wuchern UDFs. Ein Verantwortlicher aus Ihrem Haus, häufig aus dem Controlling, sollte jede Neuanlage freigeben.
Stufe 2: Fertige Erweiterungen statt Eigenbau
Bevor jemand programmiert, lohnt der Blick auf das Angebot der Partner. SAP nennt für SAP Business One mehr als 500 Erweiterungen für Branchen und Länder, vertrieben über 850 Partner (SAP, Dezember 2025). Auch die Präsentation zum Integration Framework spricht von mehr als 500 Partnerlösungen für Branchenerweiterungen.
Was Sie bei fertigen Add-ons prüfen sollten:
- Deckt das Add-on Ihren Prozess wirklich ab oder nur ungefähr?
- Wird es für Ihre Version und Ihren Datenbanktyp gepflegt?
- Wer liefert Updates, und wie schnell folgen sie auf neue Versionen von SAP Business One?
- Was passiert, wenn der Anbieter das Produkt einstellt?
Ein gekauftes Add-on ist kein Freibrief. Es bleibt Teil Ihrer Systemlandschaft und muss in Testläufe einbezogen werden. Es ist aber meist günstiger und besser abgesichert als ein Eigenbau, weil sich die Pflege auf mehrere Kunden verteilt. Welche Branchenlösungen es gibt, zeigt die Seite SAP Business One für Ihre Branche; einen Überblick über den Funktionsumfang gibt Module von SAP Business One.
Stufe 3: Individualentwicklung mit SDK und Service Layer
Wenn Standard, Paramétrage und fertige Add-ons nicht genügen, kommt die eigentliche Entwicklung. SAP stellt dafür mehrere technische Zugänge bereit.
Software Development Kit und SDK Tools
Das SDK ist die klassische Grundlage für Erweiterungen, die sich in die Oberfläche einfügen oder Belege programmatisch anlegen. Praktisch: Laut SAP-Lizenzleitfaden enthalten die Benutzerlizenzen das Software Development Kit in der Implementierungsversion, die SDK Tools, die SAP AddOns, die Kompatibilitätslizenz für Add-ons und den Workflow automatisch, ohne gesonderte Anfrage. Für das Werkzeug fällt also keine eigene Lizenzposition an; Ihr Intégrateur bestätigt, was für Ihren Vertrag gilt.
Service Layer: die moderne Schnittstelle
Der Service Layer ist eine REST-basierte Erweiterungs-API auf Grundlage von HTTP und OData, der Datenaustausch erfolgt im JSON-Format. Nach dem Leitfaden von SAP (Stand 27. Juli 2026) unterstützt er OData v3 über /b1s/v1/$metadata und OData v4 über /b1s/v2/$metadata. Er läuft unter SUSE Linux Enterprise und Microsoft Windows (seit 10.0 PL01), nutzt den Apache-Server als Lastverteiler und kann integriert oder verteilt betrieben werden. Mit der DI API teilt er sich dieselben Objektdefinitionen über die Komponente DI Core.
SAP Learning ergänzt: Der Service Layer setzt die Authentifizierungsschemata Basic und OAuth um und soll die Entwicklung von Web- und Mobilanwendungen für SAP Business One erleichtern.
Für Sie als Auftraggeber heißt das: Eine Webanwendung für Außendienst, Kundenportal oder Shopanbindung muss nicht in die Datenbank greifen. Sie spricht über eine dokumentierte Schnittstelle mit dem System. Das ist die Voraussetzung für Updatefähigkeit. Mehr zur Anbindung anderer Systeme finden Sie unter Schnittstellen und Konnektoren von SAP Business One.
Integration Framework
Die SAP-Präsentation vom April 2020 beschreibt das Integration Framework als festen Bestandteil von SAP Business One, nutzbar vor Ort wie in der Cloud. Es dient als Entwicklungs- und Laufzeitumgebung für Integrationsszenarien: Dashboards, mobile Anwendungen, ausgelagerte Lohnabrechnung, automatisierte Preisanfragen, SAP Customer Checkout, Webservices sowie SAP- und Nicht-SAP-Anwendungen. Wenn Ihr Bedarf vor allem im Datenfluss zwischen Systemen liegt, ist diese Stufe oft sinnvoller als ein eigenes Modul.
Erweiterung außerhalb des Kerns
Mit SAP BTP lassen sich Funktionen neben dem Kern aufbauen, statt in ihn hinein. Das hält den Kern sauber und vereinfacht Versionswechsel. Ob dieser Weg für Ihr Projekt Sinn ergibt, hängt von Betriebsmodell und Anforderungen ab; klären Sie das früh, am besten gemeinsam mit der Frage nach Hosting und Cloud.
Was Anpassung für Updates bedeutet
Die zentrale Frage jeder Individualentwicklung lautet: Was passiert beim nächsten Versionswechsel? Einen pauschalen Wert nennt niemand seriös; entscheidend ist die Art des Eingriffs.
| Art der Anpassung | Risiko bei Updates | Was zu tun ist |
|---|---|---|
| Felder, Werte, Abfragen, Alerts | niedrig | nach dem Update stichprobenartig prüfen |
| Workflows und Freigaben | niedrig bis mittel | Freigabewege nach dem Update durchspielen |
| UDT und UDO | mittel | Masken und Verknüpfungen testen |
| Add-on über SDK | mittel bis hoch | Kompatibilität vorab klären, Testlauf in separater Umgebung |
| Anwendung über Service Layer | mittel | Schnittstellenversion und Authentifizierung prüfen |
| Direkter Eingriff in Datenbanktabellen | hoch | vermeiden |
Zwei Regeln helfen im Alltag. Erstens: Aktualisieren Sie nie zuerst im Produktivsystem. Ein Testmandant mit realistischen Daten gehört zum Projekt. Zweitens: Legen Sie vor dem Versionswechsel fest, wer welche Anpassung verantwortet. Mehr zu Releases und Ausbaustufen lesen Sie unter Versionen und Editionen.
Bewährte Praxis für Anpassungen
Standard zuerst. Jede Abweichung ist ein dauerhaftes Versprechen, sie zu pflegen. Fragen Sie bei jedem Wunsch: Welches Problem löst das, und wer merkt es, wenn wir es nicht bauen?
Dokumentieren. Zu jeder Anpassung gehören ein Zweck, ein Verantwortlicher, die betroffenen Belege und Felder sowie die Abhängigkeiten. In deutschen Unternehmen kommt ein weiterer Grund hinzu: Die Verfahrensdokumentation im Sinne der GoBD sollte auch Änderungen am System nachvollziehbar erfassen, vor allem wenn eine Anpassung buchungsrelevante Daten berührt. Stimmen Sie das mit Ihrem Steuerberater ab. Zum Thema steht mehr im Ratgeber zu GoBD und ERP.
Testen. Fachanwender prüfen Szenarien aus dem Tagesgeschäft, nicht nur den Idealfall: Storno, Teillieferung, Gutschrift, abweichende Währung. Der Entwickler testet technisch, der Fachbereich testet inhaltlich, und beides wird festgehalten.
Quelltext und Rechte klären. Wem gehört der Code? Erhalten Sie ihn, falls der Entwickler ausfällt? Das gehört in den Vertrag.
Wartung festlegen. Ein Add-on ohne Betreuer ist ein Risiko ab dem Tag der Abnahme. Klären Sie, wer Fehler behebt und Anpassungen nach Versionswechseln übernimmt, und halten Sie es im Support- und Wartungsvertrag fest.
So bewerten Sie Entwickler und Intégrateur
Entwicklung für SAP Business One ist Vertrauenssache, denn Sie binden sich an jemanden, der Ihren Prozess und Ihre Daten kennt. Diese Fragen trennen gute von schwachen Anbietern:
- Beratung vor Programmierung: Fragt der Anbieter nach dem Prozess und schlägt zuerst Standard oder ein fertiges Add-on vor? Wer sofort ein Angebot für Code schreibt, verdient mehr daran als Sie.
- Saubere Technik: Arbeitet er über SDK, Service Layer oder Integration Framework, statt direkt in der Datenbank zu schreiben?
- Nachweise: Kann er ein vergleichbares Projekt beschreiben, mit einem Referenzkunden, den Sie selbst ansprechen dürfen?
- Testkonzept: Gibt es eine Testumgebung, Testfälle und eine Abnahme, die Sie mitzeichnen?
- Dokumentation: Erhalten Sie eine verständliche Beschreibung für Fachbereich und IT?
- Updatezusage: Wer prüft und passt Anpassungen nach neuen Versionen an, und wie ist das vertraglich geregelt?
- Deutscher Kontext: Kennt er E-Rechnung, GoBD, DATEV-Schnittstellen und die Abstimmung mit dem Steuerberater? Gerade bei Anpassungen an Belegen und Buchungen ist das kein Nebenthema. Hinweise zur Rechnungspflicht gibt der Ratgeber zur E-Rechnung im ERP.
- Aufwand transparent: Gibt es eine Aufwandsschätzung mit klar abgegrenztem Umfang und einem Verfahren für Änderungswünsche?
Wenn Sie ein bestehendes System übernehmen oder eine frühere Entwicklung beurteilen lassen wollen, hilft ein unabhängiger Audit und eine Projektübernahme. Allgemeine Auswahlkriterien für Anbieter finden Sie unter Intégrateur für SAP Business One wählen.
Wie wir Ihnen helfen
ERP Integrator ist ein kostenloser Vermittlungsservice. Wir entwickeln nicht selbst und sind an keinen Hersteller gebunden. Sie beschreiben Ihr Vorhaben, wir stellen den Kontakt zu einem passenden SAP-Business-One-Intégrateur her, der das Projekt umsetzt. Wenn Sie Anpassungen schon in der Einführung planen, beginnen Sie mit dem Überblick zur Einführung von SAP Business One und halten Sie Ihre Sonderwünsche getrennt nach Muss und Kann fest. Das erleichtert jedem Angebotsvergleich.
Häufige Fragen
Wann lohnt sich die Entwicklung eines eigenen Moduls für SAP Business One?
Dann, wenn ein Prozess Ihr Geschäft von Mitbewerbern unterscheidet und weder Paramétrage noch ein fertiges Branchen-Add-on ihn abdeckt. Prüfen Sie zuerst Felder, Abfragen, Alerts und Freigabe-Workflows. Eine Individualentwicklung ist der letzte Schritt, nicht der erste.
Welche Werkzeuge gibt es für die Entwicklung rund um SAP Business One?
Für Anpassungen im System stehen benutzerdefinierte Felder, Tabellen, Objekte und Werte, SQL-Abfragen, Alerts und Workflows bereit. Für Programmierung bietet SAP das Software Development Kit, den Service Layer als REST-Schnittstelle auf Basis von OData und das Integration Framework. Mit SAP Business Technology Platform lassen sich außerdem Erweiterungen außerhalb des Kerns bauen.
Gefährdet eine Anpassung die Updates von SAP Business One?
Nicht zwangsläufig, aber das Risiko steigt mit der Tiefe des Eingriffs. Felder und Abfragen sind in der Regel unkritisch; ein Add-on, das auf Schnittstellen und Objekte zugreift, muss nach jedem Versionswechsel getestet werden. Klären Sie vertraglich, wer diese Tests übernimmt.
Brauche ich für Entwicklung eine zusätzliche Lizenz?
Laut SAP-Lizenzleitfaden enthalten die Benutzerlizenzen von SAP Business One automatisch das Software Development Kit in der Implementierungsversion, die SDK Tools, die SAP AddOns, die Kompatibilitätslizenz für Add-ons und den Workflow. Welche Lizenzen Ihr konkretes Projekt braucht, bestätigt Ihr Intégrateur anhand Ihres Vertrags.
Woran erkenne ich einen guten SAP-Business-One-Entwickler?
Er fragt zuerst nach dem Prozess und prüft, ob der Standard genügt. Er arbeitet mit dokumentierten Schnittstellen statt mit Eingriffen in die Datenbank, legt Testfälle und Dokumentation vor und benennt, wer Ihr Add-on nach Updates betreut. Lassen Sie sich ein vergleichbares Projekt zeigen und sprechen Sie mit dem Kunden.
Quellen
- SAP Learning – Implementing SAP Business One
- SAP Help Portal – SAP Business One License Guide
- SAP Help Portal – Working with SAP Business One Service Layer
- SAP Learning – Exploring the Service Layer API Architecture and Capabilities
- SAP Help Portal – Integration Framework for SAP Business One
- SAP Learning – Introducing SAP Business One
- SAP News – Global Success of SAP Business One
Die genannten Softwarenamen sind Marken der jeweiligen Hersteller und dienen ausschließlich der Information. Diese Website ist unabhängig und steht in keiner Verbindung zu den Herstellern.