Business Central Entwicklung: Wie viel Anpassung Ihr ERP wirklich braucht

Wer im Mittelstand nach „Business Central Entwicklung“ sucht, steht meist vor derselben Frage: Wie viel muss ich anpassen, damit das ERP zu meinem Betrieb passt, und was kostet mich das später bei jedem Update? Die ehrliche Antwort lautet: so wenig wie möglich, aber so viel wie nötig. Microsoft Dynamics 365 Business Central bietet dafür mehrere Wege, die sich in Aufwand, Risiko und Pflege deutlich unterscheiden.

Die vier Ebenen der Anpassung

Bevor jemand Code schreibt, lohnt der Blick auf die Leiter der Möglichkeiten. Jede Stufe sollte erst ausgeschöpft sein, bevor Sie die nächste betreten.

Die Reihenfolge ist keine Formalität. Je weiter unten Sie in der Tabelle landen, desto mehr tragen Sie selbst: Tests, Dokumentation, Anpassung nach Versionswechseln. Mehr zum Funktionsumfang finden Sie auf der Seite zu den Business-Central-Modulen.

Stufe eins: Einrichtung vor Programmierung

Viele vermeintliche Individualwünsche sind Einrichtungsfragen. Ein anderer Belegablauf, eine zusätzliche Dimension für die Kostenstellenrechnung, ein angepasster Freigabeweg oder ein eigenes Berichtslayout lassen sich oft ohne Entwicklung abbilden. Gerade in Deutschland, wo Buchhaltung und Steuerberater eng zusammenspielen, ist das ein wichtiger Punkt: Die Finanzbuchhaltung folgt klaren Regeln, die Sie besser über saubere Konfiguration als über Sonderlogik absichern.

Für Deutschland stellt Microsoft die Lokalisierung von Business Central direkt bereit. Das heißt: Steuerlogik, Belegformate und länderspezifische Grundlagen müssen Sie nicht neu erfinden. Einzelheiten dazu finden Sie unter Business Central in Deutschland. Wer GoBD-konforme Abläufe braucht, sollte außerdem den Beitrag zu GoBD im ERP lesen, bevor er Eingriffe in Buchungs- und Archivierungslogik plant.

Stufe zwei: Erweiterungen und Apps aus dem Marketplace

Online erweitern Sie Business Central über Apps, die Sie aus Microsoft Marketplace installieren. Microsoft pflegt dafür eigene Bereiche, etwa „Connectivity Apps“ und „Banking Apps“, über die sich Verbindungen zu externen Diensten einrichten lassen, zum Beispiel für den Import von Banktransaktionen. Diese Bereiche gibt es seit der zweiten Release Wave des Jahres 2022.

Ein Beispiel aus dem Onlinehandel: Der Shopify-Connector gleicht Produkte, Bestände, Kunden, Bestellungen, Versand, Transaktionen und Auszahlungen zwischen Shopify und Business Central ab. Er kann mehrere Shops anbinden und übernimmt Bestellungen aus Onlineshops, Shopify POS und B2B. Preise werden über Kundenpreisgruppen und Rabatte gesteuert, und der Abgleich von Produkten, Beständen, Bestellungen und Versand lässt sich über die Jobwarteschlange im Hintergrund automatisieren, inklusive ausführlicher Protokolle für die Fehlersuche. Wer so etwas bauen lassen will, sollte erst prüfen, ob der fertige Connector reicht. Mehr zu diesem Thema steht im Beitrag zu Schnittstellen und Konnektoren.

Bei jeder App stellen sich vier Fragen:

• Wer pflegt die App, und wie reagiert der Anbieter auf neue Versionen?
• Deckt sie Ihren deutschen Kontext ab, etwa DATEV-nahe Abläufe oder die E-Rechnung?
• Wie sind Support und Haftung geregelt?
• Was passiert mit Ihren Daten, wenn Sie die App wieder entfernen?

Stufe drei: Der Designer für kleine Eingriffe

Der in den Client integrierte Designer erlaubt es, Seiten per Drag-and-drop zu gestalten: Felder verschieben, ergänzen und die Wirkung direkt ansehen. Für die Abteilungsleiterin, die auf ihrer Auftragsseite ein zusätzliches Feld sehen möchte, ist das oft genug. Der Vorteil: Sie bleiben in der Oberfläche und brauchen keine Entwicklungsumgebung. Der Nachteil: Auch diese Änderungen sind Teil Ihrer Lösung und gehören in die Dokumentation.

Stufe vier: Business Central Entwicklung in AL

Reicht nichts davon, kommt die eigentliche Entwicklung. Business Central wird über Erweiterungen in der Sprache AL angepasst, geschrieben in Visual Studio Code. Sie ergänzen oder verändern Tabellen, Seiten, Codeunits und Berichte, ohne den Basiscode zu ändern. Das Ergebnis wird zu einer .app-Datei kompiliert und im System installiert.

Das ist der entscheidende Unterschied zu früheren Zeiten, in denen Anpassungen direkt im Standardcode lagen und jedes Update zum Projekt wurde. Eine Erweiterung liegt neben dem Standard, nicht darin. Trotzdem bleibt eine Erweiterung Software, die jemand betreiben muss.

Typische Fälle für ein Modul nach Maß

• ein Genehmigungsablauf, der Ihre interne Organisation abbildet und mit keinem Standardworkflow gelingt
• eine branchenspezifische Kalkulation, etwa in der Fertigung oder im Handel mit komplexen Konditionen
• ein Spezialbericht für Geschäftsführung oder Steuerberater
• eine eigene API, weil eine Standard-API Ihr Feld nicht liefert

Zum letzten Punkt gehört ein wichtiger Hinweis: Business Central stellt eine REST-API in der Version 2.0 bereit, um den ERP-Kern mit Drittlösungen zu verbinden, und die APIs sind online standardmäßig aktiv. Felder zu einer Standard-API hinzuzufügen ist jedoch nicht möglich. Dafür kopieren Entwickler den AL-Code und legen eine eigene API an.

Abrufgrenzen bei Schnittstellen

Wer Daten in hoher Taktung abruft, muss die Grenzen der Online-Version kennen. Die Limits für OData-V4-Aufrufe gelten pro Benutzer: fünf gleichzeitige Anfragen, 100 Verbindungen und ein gleitendes Fenster von 6.000 Anfragen in fünf Minuten. Wird das überschritten, antwortet der Dienst mit dem HTTP-Code 429. Microsoft empfiehlt API oder OData statt SOAP, das künftig abgekündigt werden soll. Wer heute neue Anbindungen plant, sollte also nicht mehr auf SOAP setzen.

Sandbox, Tests und Bereitstellung

Sandbox-Umgebungen sind für die Entwicklung gedacht. Der Debug-Endpunkt ist dort standardmäßig geöffnet, und Sie veröffentlichen direkt aus Visual Studio Code. Ausgehende HTTP-Aufrufe von Erweiterungen sind in der Sandbox blockiert, bis Sie sie je Erweiterung freigeben. Das schützt Ihre Daten, kostet aber Zeit, wenn man es nicht einplant.

Ein Umgebungslink zur Power Platform ist ebenfalls möglich: Eine Business-Central-Umgebung kann mit einer Power-Platform-Umgebung gleichen Typs verbunden werden, also Produktion mit Produktion oder Sandbox mit Sandbox. Die Verbindung ist exklusiv und dient als Standardziel für Integrationen mit Power Platform und anderen Dynamics-365-Produkten. Wer Power Automate oder Power Apps nutzen will, sollte das früh klären.

Ein sinnvoller Ablauf sieht so aus:

1. Anforderung im Pflichtenheft festhalten, siehe ERP-Lastenheft
2. Entwicklung in der Sandbox
3. Abnahme mit den Fachabteilungen anhand echter Testdaten
4. Test gegen die neue Version vor jedem Update
5. Übergabe in die Produktion mit Rückfallplan
6. Dokumentation und Übergabe an den Support

Auswirkungen auf Updates

Business Central Online wird von Microsoft regelmäßig aktualisiert. Ihre Erweiterungen müssen mit diesen Versionen zusammenarbeiten. Je enger eine Erweiterung an Standardabläufen hängt, desto wahrscheinlicher ist Anpassungsbedarf. Wer nur eigene Objekte hinzufügt, hat weniger Reibung als jemand, der tief in bestehende Buchungsroutinen eingreift.

Planen Sie deshalb Pflege von Anfang an ein. Wer die Erweiterung betreut, ist keine Nebenfrage, sondern Teil des Vertrags, siehe Support und Wartung. Welche Versionsstände und Editionen relevant sind, erklärt die Seite zu Versionen und Editionen.

Bewährte Regeln für die Anpassung

• Standard zuerst. Jede Abweichung ist eine dauerhafte Verpflichtung. Prüfen Sie, ob Ihr Prozess nicht besser zum ERP passt als umgekehrt.
• Eine Anforderung, ein Zweck. Beschreiben Sie, welches Geschäftsproblem gelöst wird, nicht nur, welches Feld fehlt.
• Dokumentieren. Jede Erweiterung braucht eine verständliche Beschreibung: Zweck, Objekte, Abhängigkeiten, Ansprechpartner.
• Testen vor jedem Update. Automatisierte Tests für kritische Abläufe zahlen sich aus, vor allem bei Buchungen und Rechnungen.
• Kein Eingriff in Pflichtbereiche ohne Fachprüfung. Bei Belegen, Archivierung und Buchungslogik sollten Steuerberater und Integrator gemeinsam entscheiden. Für Rechnungsformate lohnt der Blick in den Beitrag zur E-Rechnung im ERP.
• Besitz klären. Wem gehört der Quellcode, wer darf ihn ändern, wo liegt er?

Was kostet eine Anpassung?

Seriös lässt sich das nur nach einer Analyse beantworten. Der Aufwand hängt vom Prozess, von der Zahl der betroffenen Objekte, von Schnittstellen und von Testumfang ab. Rechnen Sie nicht nur die Entwicklung, sondern auch Pflege, Updates und Dokumentation ein. Zu Lizenzen und Preismodellen finden Sie Hinweise auf der Seite Business Central Preise.

So prüfen Sie einen Entwickler oder Integrator

Eine gute Entwicklung beginnt mit einem guten Gegenüber. Diese Kriterien helfen Ihnen im Gespräch:

Fragen Sie außerdem nach Erfahrung in Ihrer Branche, nach der Betreuung nach dem Go-live und danach, wie mit Schnittstellen zu Fremdsystemen umgegangen wird. Eine Orientierung bietet der Beitrag Business-Central-Integrator wählen. Wie die Vermittlung bei uns funktioniert, steht unter So funktioniert es: Wir stellen den Kontakt zu einem passenden Integrator her, das Projekt selbst führt dieser durch.

Wann Anpassung der falsche Weg ist

Manchmal zeigt sich im Gespräch, dass der Wunsch nach Individualentwicklung ein Symptom ist: für ein zu enges Tarifmodell, für ein ungeklärtes Berechtigungskonzept oder für einen Prozess, den niemand hinterfragt hat. Dann hilft ein Schritt zurück. Eine saubere Einführung mit klaren Anforderungen spart oft mehr als jede spätere Erweiterung. Und wenn sich herausstellt, dass Business Central für Ihr Vorhaben nicht passt, lohnt ein Blick auf die Alternativen.

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.