↓

Entwicklung und Anpassung von SAP Business One

Die Entwicklung für SAP Business One reicht vom Zusatzfeld bis zum eigenen Modul. Hier lesen Sie, welche Stufe wann passt, was Updates bedeuten und woran Sie gute Entwickler erkennen.

Aktualisiert am 28. Oktober 2026

Wer SAP Business One einführt, stellt früher oder später dieselbe Frage: Passt das System zu unseren Abläufen, oder passen wir die Abläufe an das System an? Die Entwicklung für SAP Business One ist die Antwort auf den Teil, den der Standard nicht abdeckt. Sie ist aber kein Selbstzweck. Jede Zeile eigener Code will gepflegt, getestet und bei einem Versionswechsel erneut geprüft werden.

Diese Seite ordnet die Möglichkeiten nach Aufwand und Risiko. Sie zeigt, wie sich SAP Business One personalisieren lässt, wann ein Modul nach Maß sinnvoll ist und worauf Sie bei der Auswahl eines Entwicklers achten sollten.

Die vier Stufen der Anpassung

SAP Business One ist als Kern konzipiert, der sich erweitern lässt. SAP Learning beschreibt das System als ERP-Kern, der durch KI, maschinelles Lernen und Cloud-Dienste der SAP Business Technology Platform (BTP) ergänzt wird. Automatisierungsvorlagen stehen dafür im Business Accelerator Hub und in SAP Build bereit. Für die Praxis in einem österreichischen Mittelstandsbetrieb lassen sich vier Stufen unterscheiden.

Stufe Was dahintersteckt Eingriff in den Standard Typischer Einsatz
Konfiguration Einstellungen, Berechtigungen, Kontenrahmen, Belegvorlagen Keiner Grundaufbau jedes Projekts
Benutzerdefinierte Objekte Felder, Tabellen, Objekte und Werte, dazu Abfragen, Alerts, Freigabe-Workflows Gering Zusatzdaten, Kontrollen, Genehmigungen
Bestehende Erweiterungen Fertige Add-ons und Branchenlösungen von Partnern Mittel, vom Hersteller des Add-ons gepflegt Branchenspezifische Funktionen
Individuelle Programmierung Eigene Add-ons, Anwendungen und Schnittstellen über SDK, Service Layer und Integration Framework Je nach Design hoch Prozesse, die kein Produkt abdeckt

Die Reihenfolge ist zugleich eine Empfehlung: Gehen Sie von oben nach unten und steigen Sie erst eine Stufe tiefer, wenn die vorherige nachweislich nicht reicht.

Stufe eins und zwei: Anpassen ohne Programmieren

Viele Wünsche, die zunächst nach Entwicklung klingen, lassen sich ohne Code lösen. Das Implementierungsmaterial von SAP nennt dafür ausdrücklich benutzerdefinierte Felder (UDF), Tabellen (UDT), Objekte (UDO) und Werte (UDV) sowie SQL-Abfragen, Alerts und Freigabe-Workflows.

Ein paar Beispiele aus dem österreichischen Alltag:

  • Zusatzfelder für Debitoren: Eine Kennung für die Kommunikation per E-Rechnung an Bundesstellen oder die interne Zuständigkeit im Außendienst.
  • Eigene Tabellen: Eine Stammdatenliste, die Ihr Steuerberater für die Abstimmung mit der Buchhaltung braucht, etwa Zuordnungen zu Erlöskonten.
  • Abfragen: Offene Posten nach Bundesland, Lieferanten ohne hinterlegte Bankverbindung oder Artikel unter Mindestbestand.
  • Freigabe-Workflows: Einkaufsbestellungen ab einem bestimmten Betrag müssen von der Geschäftsführung bestätigt werden. Den Betrag legen Sie intern fest.

Der Vorteil dieser Stufe: Sie ist Teil des Systems, wird bei Updates mitgeführt und kann von geschulten Anwenderinnen und Anwendern teilweise selbst gepflegt werden. Eine passende Schulung zu SAP Business One lohnt sich deshalb schon vor dem Go-live.

Stufe drei: bestehende Erweiterungen nutzen

Bevor Sie etwas neu bauen, lohnt der Blick auf den Markt. SAP gibt an, dass SAP Business One über 850 Partner vertrieben wird und dass mehr als 500 Branchen- und Länderlösungen als Erweiterungen verfügbar sind. Wer Fertigung, Großhandel oder Dienstleistung betreibt, findet dort oft eine Basis, die sich anpassen lässt, statt bei null zu beginnen.

Für den Einkauf einer Erweiterung gelten dieselben Fragen wie für jede Software:

  • Wird das Add-on für Ihre Version und Ihre Datenbank freigegeben und aktiv weiterentwickelt?
  • Wer bietet Support, und wie ist die Zuständigkeit geregelt, wenn Add-on und SAP Business One gleichzeitig betroffen sind?
  • Deckt es österreichische Anforderungen ab, etwa Rechnungsformate, die Registrierkasse oder die Schnittstelle zur Lohnverrechnung?

Gerade bei Lohn und Personal sowie bei der Registrierkasse hängt vieles von der österreichischen Praxis ab. Wie das zusammenspielt, behandeln wir auf den Seiten zu Lohn und Personal und zur Registrierkassenpflicht.

Stufe vier: individuelle Programmierung

Wenn weder Konfiguration noch ein Add-on reichen, kommt die eigentliche Entwicklung ins Spiel. Die technische Grundlage ist breit.

SDK, Service Layer und Integration Framework

Die Benutzerlizenzen von SAP Business One enthalten laut Lizenzleitfaden automatisch und ohne gesonderten Antrag das Software Development Kit in der Implementierungsversion, die SDK Tools, die SAP AddOns, die Kompatibilitätslizenz für Add-ons und den Workflow, jeweils für eine Nutzerzahl von 99 999. Das senkt die Einstiegshürde, ersetzt aber keine Prüfung Ihres Vertrags.

Der Service Layer ist die moderne Schnittstelle für Erweiterungen. Es handelt sich um eine REST-API auf Basis von HTTP und OData, die Daten im JSON-Format austauscht. Laut Handbuch von SAP unterstützt sie OData in zwei Varianten, erreichbar über getrennte Metadaten-Adressen. Er läuft auf SUSE Linux Enterprise und auf Microsoft Windows, nutzt den Apache-Server als Lastverteiler und kann integriert oder verteilt betrieben werden. Mit der DI API teilt er sich über die Komponente DI Core dieselben Objektdefinitionen. SAP Learning nennt als Authentifizierungsverfahren Basic und OAuth und als Ziel die einfachere Entwicklung von Web- und Mobilanwendungen.

Für Entwickler heißt das konkret: Sie können mit gängigen Web-Technologien arbeiten, statt an eine einzelne Programmierumgebung gebunden zu sein.

Das Integration Framework ergänzt das Bild. SAP beschreibt es als Bestandteil von SAP Business One, nutzbar vor Ort wie in der Cloud, und als Entwicklungs- und Laufzeitumgebung für Integrationsszenarien. Genannt werden unter anderem Dashboards, mobile Anwendungen, ausgelagerte Lohnverrechnung, automatische Preisanfragen, SAP Customer Checkout und Webservices zu SAP- und Nicht-SAP-Anwendungen. Mehr zu Anbindungen finden Sie auf der Seite zu den Schnittstellen von SAP Business One.

Wofür sich ein Modul nach Maß wirklich lohnt

Ein eigenes Modul oder Add-on rechtfertigt sich, wenn drei Bedingungen zusammentreffen: Der Prozess ist für Ihr Geschäft zentral, er wird häufig ausgeführt, und kein vorhandenes Produkt bildet ihn ab. Beispiele sind eine kundenspezifische Kalkulation in der Fertigung, ein Portal für Händler oder ein Abgleich mit einem Branchensystem, das nur Sie einsetzen.

Wenig sinnvoll ist Entwicklung dort, wo man nur an Gewohnheiten festhält. Wer ein altes Excel-Layout eins zu eins nachbauen lässt, zahlt dauerhaft für etwas, das der Standard besser kann.

Updates und Wartung: der unterschätzte Teil

Die Frage, die Geschäftsführer und Finanzleiter zu spät stellen, lautet: Was passiert mit unseren Erweiterungen, wenn SAP Business One aktualisiert wird? Die ehrliche Antwort ist, dass es von der Art des Eingriffs abhängt.

  • Konfiguration und benutzerdefinierte Objekte gehören zum System und werden mitgeführt. Prüfen sollten Sie sie trotzdem.
  • Fertige Add-ons hängen am Hersteller. Fragen Sie vor dem Versionswechsel nach der Freigabe.
  • Eigene Programme über SDK oder Service Layer müssen Sie selbst oder Ihr Integrator testen. Je mehr Standardobjekte beteiligt sind, desto größer der Testumfang.

Details zu Versionen und Ausführungen finden Sie unter Versionen und Editionen. Wie ein laufender Betrieb organisiert wird, zeigt die Seite zu Support und Wartung.

Bewährte Praxis: Standard halten, dokumentieren, testen

Aus vielen Projekten lassen sich einige Regeln ableiten, die den Unterschied zwischen einer wartbaren und einer schwer zu pflegenden Lösung machen.

  1. Im Standard bleiben, wo es möglich ist. Jede Abweichung ist eine Verpflichtung für die Zukunft. Fragen Sie bei jedem Wunsch zuerst: Welches Problem löst das, und gibt es dafür eine Standardfunktion?
  2. Das Lastenheft zuerst. Ohne klare Anforderungen wird Entwicklung teuer und unscharf. Ein sauberes Lastenheft für Ihr ERP-Projekt trennt Muss von Wunsch.
  3. Dokumentieren. Zu jeder Erweiterung gehören Zweck, betroffene Objekte, Zuständigkeit und Testfälle. Das Wissen darf nicht nur in einem Kopf liegen.
  4. Getrennte Umgebungen. Entwickeln und testen Sie nie im Produktivsystem. Eine Testfirma mit realistischen Daten ist Pflicht.
  5. Rollen und Berechtigungen mitdenken. Jede neue Funktion braucht eine Berechtigungslogik, schon wegen der Nachvollziehbarkeit bei Betriebsprüfungen.
  6. Ergebnis abnehmen, nicht nur Code. Abgenommen wird, was die Fachabteilung im Alltag durchspielen kann.
  7. Gesetzliche Anforderungen im Blick behalten. E-Rechnung, Aufbewahrung und Registrierkasse ändern sich. Eigenentwicklungen in diesen Bereichen brauchen einen klaren Pflegeplan.

Entwickler und Integrator prüfen: Fragen für das Gespräch

Entwicklung für SAP Business One wird in Österreich von Integratoren, spezialisierten Softwarehäusern und freien Entwicklern angeboten. Die Qualität unterscheidet sich stark. Diese Fragen helfen bei der Einordnung:

Zum Vorgehen

  • Wird zuerst der Prozess verstanden und der Standard geprüft, oder wird sofort programmiert?
  • Welche der vier Stufen schlägt der Anbieter für Ihr Problem vor, und warum?
  • Wie werden Anforderungen festgehalten und abgenommen?

Zur Technik

  • Welche Schnittstelle kommt zum Einsatz, und wie bleibt die Lösung bei einem Versionswechsel lauffähig?
  • Gibt es eine Testumgebung, und wer führt Regressionstests durch?
  • Wie wird die Lösung dokumentiert, und wem gehört der Quellcode?

Zur Zusammenarbeit

  • Wer ist bei Störungen zuständig, wenn Standard und Erweiterung zusammenwirken?
  • Ist die Betreuung langfristig gesichert, und was passiert, wenn der Entwickler ausfällt?
  • Kennt das Team österreichische Besonderheiten wie die Zusammenarbeit mit dem Steuerberater oder den Abgleich mit BMD?

Bitten Sie um Referenzen aus vergleichbaren Betrieben und sprechen Sie mit diesen Kunden direkt. Ein seriöser Anbieter nennt nachvollziehbare Referenzen, ohne Garantien zu versprechen, die er nicht halten kann. Vertiefende Hinweise bietet die Seite Integrator für SAP Business One wählen.

Übernahme bestehender Anpassungen

Viele Unternehmen kommen nicht mit einem leeren Blatt, sondern mit einem System, das über Jahre gewachsen ist. Dann steht zuerst eine Bestandsaufnahme an: Welche Felder, Abfragen, Add-ons und Programme gibt es, wer hat sie gebaut, und was ist dokumentiert? Ein Audit und die Projektübernahme schaffen diese Transparenz, bevor weitere Entwicklung beauftragt wird.

Wie wir Sie unterstützen

Wir entwickeln selbst nichts und führen kein Projekt durch. ERP Integrator ist ein kostenloser Vermittlungsservice: Sie beschreiben Ihr Vorhaben, und wir stellen den Kontakt zu einem Integrator her, der zu Ihrem Bedarf passt. Wie das abläuft, erklärt die Seite So funktioniert es. Je genauer Ihre Beschreibung der gewünschten Anpassung, desto besser lässt sich ein passender Partner finden.

Wenn Sie noch grundsätzlich zwischen Systemen abwägen, finden Sie auf der Übersicht zu SAP Business One und im Vergleich mit anderen Lösungen weiterführende Informationen.

Häufige Fragen

Was ist der Unterschied zwischen Anpassung und Entwicklung bei SAP Business One?

Anpassung nutzt Werkzeuge, die im System bereits enthalten sind: eigene Felder, Tabellen, Abfragen, Alerts und Freigabe-Workflows. Entwicklung bedeutet dagegen Programmcode, etwa ein Add-on oder eine Anwendung auf Basis des Service Layer. Beginnen Sie immer mit der Anpassung und entwickeln Sie nur, was sich damit nicht abbilden lässt.

Brauche ich für die Entwicklung eine zusätzliche Lizenz?

Laut Lizenzleitfaden von SAP umfassen 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 Bedingungen für Ihren Vertrag konkret gelten, klären Sie mit dem Lizenzgeber und Ihrem Integrator.

Gefährden Eigenentwicklungen die Updates von SAP Business One?

Das hängt vom Eingriff ab. Eigene Felder und Abfragen sind in der Regel unkritisch, Add-ons und Integrationen müssen nach einem Versionswechsel getestet werden. Je enger eine Erweiterung an Standardobjekte gekoppelt ist, desto sorgfältiger muss der Test ausfallen. Eine Testumgebung und eine saubere Dokumentation sind deshalb Pflicht.

Sollte ich ein fertiges Branchen-Add-on oder eine Eigenentwicklung wählen?

Prüfen Sie zuerst, ob eine bestehende Lösung Ihren Bedarf abdeckt. SAP nennt mehr als fünfhundert Erweiterungen für Branchen und Länder, die über Partner angeboten werden. Eine Eigenentwicklung lohnt sich vor allem dort, wo Ihr Prozess ein echtes Alleinstellungsmerkmal ist und kein Produkt ihn abbildet.

Woran erkenne ich einen guten Entwickler für SAP Business One?

Er fragt zuerst nach dem Prozess und nicht nach der Technik, schlägt wenn möglich den Standard vor und nennt Referenzen im Gespräch, die Sie selbst prüfen können. Außerdem liefert er Dokumentation, Testprotokolle und einen klaren Plan für Updates und Support. Wie Sie dabei vorgehen, beschreibt unser Beitrag zur Auswahl eines Integrators.

Quellen

  1. SAP News – Global success of SAP Business One
  2. SAP Help Portal – License Guide SAP Business One
  3. SAP Help Portal – Working with SAP Business One Service Layer
  4. SAP Learning – Leveraging the SAP Business One Service Layer
  5. SAP Learning – Implementing SAP Business One
  6. SAP Learning – Introducing SAP Business One
  7. SAP Help Portal – Integration Framework for 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.