Wer in einem österreichischen Betrieb Microsoft Dynamics 365 Business Central einführt, stellt früher oder später dieselbe Frage: Passt das Standardsystem, oder braucht es Business-Central-Entwicklung? Die ehrliche Antwort lautet fast immer: zuerst Konfiguration, dann eine vorhandene App, und erst danach eigener Code. Dieser Beitrag zeigt, wie Sie diese Reihenfolge einhalten, was die Personalisierung von Business Central für Ihre Updates bedeutet und wie Sie einen Entwickler oder Integrator beurteilen.
Drei Wege, Business Central anzupassen
Anpassung ist kein einzelner Schritt, sondern eine Leiter. Jede Sprosse bringt mehr Freiheit, aber auch mehr Verantwortung für Pflege und Tests.
| Weg | Was passiert | Typischer Einsatz | Aufwand für Updates |
|---|---|---|---|
| Konfiguration | Einrichtung, Rollen, Seitenlayouts, Genehmigungen | Standardprozesse abbilden | gering |
| Vorhandene App | Erweiterung aus Microsoft Marketplace installieren | Branchenfunktion, Konnektor, Bankimport | gering bis mittel |
| Individualentwicklung | Eigene Erweiterung in AL | Prozess, den es nicht fertig gibt | laufend, mit Regressionstest |
Die Reihenfolge ist zugleich eine Kostenreihenfolge. Was Sie konfigurieren können, müssen Sie später weder dokumentieren noch testen noch migrieren.
Konfiguration zuerst
Bevor jemand eine Zeile Code schreibt, sollte das Projektteam prüfen, ob Rollencenter, Seitenpersonalisierung, Dimensionen, Genehmigungsworkflows und Berichtslayouts den Wunsch bereits abdecken. Viele „Sonderwünsche“ aus dem Lastenheft erweisen sich bei genauer Betrachtung als Einrichtungsfragen. Wie Sie solche Anforderungen sauber festhalten, beschreibt unser Beitrag zum ERP-Lastenheft.
Auch der Designer im Client gehört in diese Kategorie: Er erlaubt es, Seiten per Drag-and-drop zu gestalten, Felder anzuordnen oder hinzuzufügen und das Ergebnis direkt in der Vorschau zu sehen. Daraus entsteht eine Erweiterung, ohne dass man die Oberfläche verlässt. Für einfache Anpassungen der Bildschirme ist das oft der günstigste Weg.
Vorhandene Apps nutzen
Online wird Business Central über Apps, also Erweiterungen, ergänzt, die aus Microsoft Marketplace installiert werden. Die Seiten „Connectivity Apps“ und „Banking Apps“ bieten Anwendungen für die Verbindung zu externen Diensten an, etwa für den Import von Banktransaktionen. Bei Shop-Anbindungen liefert der Shopify-Konnektor Produkte, Bestände, Kunden, Bestellungen, Lieferungen, Transaktionen und Auszahlungen im Austausch und unterstützt mehrere Shops. Der Abgleich lässt sich über die Jobwarteschlange im Hintergrund automatisieren, mit detaillierter Protokollierung für die Fehlersuche.
Das zeigt die Denkweise: Was Microsoft oder ein Anbieter als App pflegt, pflegt er auch bei neuen Versionen. Mehr dazu, wie Sie Fremdsysteme anbinden, lesen Sie unter Schnittstellen zu Business Central.
Eigene Entwicklung in AL
Erst wenn Konfiguration und App nicht genügen, kommt die Individualentwicklung ins Spiel. Business Central wird dafür mit Erweiterungen in der Sprache AL angepasst, geschrieben in Visual Studio Code. Sie ergänzen oder ändern Tabellen, Seiten, Codeunits und Berichte, ohne den Code der Basisanwendung zu verändern. Das Ergebnis wird zu einer .app-Datei kompiliert und im Environment installiert.
Dieser Aufbau ist der Kern der Update-Fähigkeit: Ihr Code liegt neben dem Standard, nicht darin. Er bleibt damit grundsätzlich austauschbar und prüfbar.
Wann sich ein eigenes Modul lohnt
Ein eigenes Modul für Business Central ist dann sinnvoll, wenn der Prozess Ihren Wettbewerbsvorteil ausmacht oder wenn der Standard ihn nicht abbilden kann und keine App ihn abdeckt. Typische Beispiele aus dem österreichischen Mittelstand:
- Fertigung und Gewerbe: Spezielle Kalkulations- oder Stücklistenlogik, die aus einem gewachsenen Prozess stammt, siehe auch Produktion in Business Central.
- Handel mit Registrierkasse: Die Verbindung zur Kasse und die Anforderungen der RKSV verlangen eine saubere Schnittstelle; prüfen Sie zuerst, was das Kassensystem anbietet. Hintergründe finden Sie im Beitrag zur Registrierkassenpflicht.
- Steuerberater und Buchhaltung: Austausch mit BMD oder anderen Systemen der Kanzlei, etwa bei Exportformaten. Die Konstellation mit BMD im Umfeld ist in Österreich häufig und gehört früh ins Gespräch.
- E-Rechnung: Ausgangs- und Eingangsrechnungen im gewünschten Format müssen zum Prozess passen; mehr dazu unter E-Rechnung und ERP.
Nicht jede dieser Aufgaben erfordert Code. Der Maßstab ist: Existiert eine Lösung, die ein Hersteller pflegt, ist sie fast immer günstiger über die gesamte Laufzeit als eine eigene.
Schnittstellen und API: was technisch möglich ist
Business Central stellt eine REST-API (Version 2.0) bereit, um den ERP-Kern mit Lösungen Dritter zu verbinden. Online sind die APIs standardmäßig aktiviert. Eine wichtige Grenze: Zu einer Standard-API lassen sich keine Felder hinzufügen. Wer zusätzliche Felder braucht, kopiert den AL-Code und baut eine eigene, benutzerdefinierte API.
Auch das Mengengerüst gehört in jedes Konzept. Die Aufruflimits für OData V4 gelten pro Benutzer: fünf gleichzeitige Anfragen, 100 Verbindungen und ein gleitendes Fenster von 6 000 Anfragen in 5 Minuten. Wird das überschritten, antwortet der Dienst mit dem HTTP-Code 429. Microsoft empfiehlt API oder OData statt SOAP, das auslaufen soll. Ein Entwickler, der Massenabgleiche plant, ohne diese Grenzen zu erwähnen, hat die Hausaufgaben nicht gemacht.
Zudem kann ein Environment mit einem Power-Platform-Environment gleichen Typs, also Produktion oder Sandbox, verknüpft werden. Diese Verknüpfung ist exklusiv und dient als Standardziel für Integrationen mit Power Platform und anderen Dynamics-365-Produkten. Das beeinflusst, wie Sie Automatisierungen und Berichte aufsetzen.
Auswirkungen auf Updates und Versionen
Der größte Irrtum bei der Anpassung lautet: „Das machen wir einmal, und dann steht es.“ Business Central entwickelt sich weiter, und jede Erweiterung muss mitziehen. Wie sich die Versionen und Editionen unterscheiden, erklärt die Seite zu Versionen und Editionen.
Aus der Praxis ergeben sich drei Konsequenzen:
- Erweiterungen statt Änderungen im Standard. Wer in den Basiscode eingreift, blockiert den Weg zu neueren Versionen.
- Tests vor jedem Wechsel. Das Sandbox-Environment ist für Entwicklung gedacht: Der Debug-Port ist standardmäßig offen, die Veröffentlichung erfolgt aus Visual Studio Code, und ausgehende HTTP-Aufrufe von Erweiterungen sind blockiert, bis sie je Erweiterung freigegeben werden. Diese Freigabe sollte im Projekt bewusst entschieden und dokumentiert werden.
- Ein Verantwortlicher für den Code. Ohne klaren Zuständigen veraltet die Erweiterung unbemerkt. Das gehört in den Wartungsvertrag, siehe Support und Wartung.
Bewährte Praxis: Standard halten, dokumentieren, testen
Die folgenden Regeln halten die Folgekosten niedrig und gelten unabhängig davon, wer entwickelt.
Beim Standard bleiben
Jede Abweichung muss einen geschäftlichen Grund haben, den Sie in einem Satz erklären können. Fragen Sie bei jedem Wunsch: Welches Problem löst das, und was passiert, wenn wir es nicht bauen? Gerade in der Einführung lohnt es sich, Prozesse an den Standard anzupassen, statt den Standard an gewachsene Gewohnheiten. Der Ablauf eines Projekts ist unter Einführung von Business Central beschrieben.
Dokumentieren
Zu jeder Erweiterung gehören eine Beschreibung des Zwecks, der betroffenen Objekte, der Abhängigkeiten, der Testfälle und des Ansprechpartners. Der Quellcode und die Dokumentation sollten Ihnen gehören, nicht nur dem Dienstleister. Das ist bei einem Wechsel des Anbieters entscheidend; wie eine Übernahme geprüft wird, zeigt der Beitrag zum Audit und zur Projektübernahme.
Testen
Legen Sie fachliche Testfälle fest, die Ihre Fachabteilung versteht, etwa „Kundenauftrag mit Rabatt, Teillieferung, Rechnung“. Diese Fälle laufen im Sandbox-Environment vor jedem Versionswechsel und nach jeder Änderung. Wo möglich, ergänzen automatisierte Tests die manuellen. Ohne Testfälle ist jede Aktualisierung ein Risiko, das am Monatsabschluss sichtbar wird.
Einen Entwickler oder Integrator beurteilen
Bei der Auswahl hilft keine Checkliste mit Schlagworten, sondern ein Gespräch mit konkreten Fragen. Achten Sie auf diese Punkte:
| Frage | Gute Antwort | Warnsignal |
|---|---|---|
| Wie gehen Sie bei einem Sonderwunsch vor? | Erst Konfiguration, dann App, dann Code | Sofort „das programmieren wir“ |
| Wo entwickeln und testen Sie? | In Sandbox-Environments, mit Versionskontrolle | Direkt in der Produktion |
| Wem gehört der Code? | Ihnen, mit Übergabe der Quellen | Unklar oder nur auf Anfrage |
| Wie überstehen Erweiterungen Updates? | Regressionstests, Vorab-Prüfung neuer Versionen | „Das passiert schon nicht“ |
| Kennen Sie den österreichischen Kontext? | E-Rechnung, RKSV, Zusammenarbeit mit dem Steuerberater | Nur allgemeine Aussagen |
Fragen Sie außerdem nach Erfahrung mit Ihrer Branche und mit Ihrer Größe. Ein Anbieter, der bei Wien nur Vertrieb macht, aber bei Ihrer Fertigung in der Steiermark keine Projekte kennt, ist nicht automatisch falsch, aber Sie sollten das wissen. Eine Orientierung nach Standort bieten unsere Seiten zu den Bundesländern.
Wer einen passenden Partner sucht, findet Kriterien unter Integrator für Business Central wählen. Beachten Sie auch den Kontext für Business Central in Österreich: Microsoft liefert die Lokalisierung für Österreich direkt, sodass viele landesspezifische Grundlagen bereits im Standard liegen und nicht eigens entwickelt werden müssen.
Die eigene Entwicklung wirtschaftlich bewerten
Die Kosten einer Erweiterung bestehen nicht nur aus der Erstellung. Rechnen Sie mit Dokumentation, Tests, Pflege bei neuen Versionen und dem Wissen, das im Unternehmen bleiben muss. Eine kleine Funktion, die einmal programmiert wird, verursacht über Jahre Aufwand, wenn niemand sie mehr versteht.
Hilfreich ist eine einfache Gegenüberstellung pro Anforderung:
- Ersparnis oder Nutzen im Alltag, ausgedrückt in Prozessschritten statt in Schätzungen.
- Lebensdauer des Prozesses: Wird er sich im Betrieb voraussichtlich ändern?
- Alternative: Gibt es eine App, eine Konfiguration oder eine Anpassung des Ablaufs?
- Risiko bei Ausfall: Hängt die Fakturierung oder der Versand an der Erweiterung?
Die Lizenzseite gehört ebenfalls dazu: Microsoft nennt für Business Central je nach Edition unterschiedliche Preise pro Benutzer und weist darauf hin, dass die tatsächlichen Preise je nach Währung, Land und Variante abweichen können. Für Ihr Budget finden Sie Details unter Preise von Business Central. Erweiterungen verändern die Lizenzfrage nicht von selbst, aber sie verändern den laufenden Betreuungsaufwand.
So gehen wir mit Ihrer Anfrage um
ERP Integrator entwickelt nicht selbst, sondern vermittelt Sie kostenlos an einen Integrator, der zu Ihrem Vorhaben passt. Beschreiben Sie in der Anfrage, was Sie anpassen möchten und was bereits im Standard funktioniert. Der Integrator schlägt Ihnen dann vor, welche Anteile Konfiguration, App oder Entwicklung sind, und begründet das. Das ist die beste Grundlage, um Angebote zu vergleichen, weil Sie dann Gleiches mit Gleichem vergleichen.
Häufige Fragen
In welcher Sprache erfolgt die Business-Central-Entwicklung?
Erweiterungen für Business Central werden in der Sprache AL geschrieben, üblicherweise in Visual Studio Code. Damit lassen sich Tabellen, Seiten, Codeunits und Berichte ergänzen oder verändern, ohne den Basiscode anzutasten. Das Ergebnis ist eine App-Datei mit der Endung .app, die in einem Environment installiert wird.
Gefährdet eine Individualentwicklung die Updates von Business Central?
Nicht, wenn sie als Erweiterung gebaut ist, denn der Standardcode bleibt unberührt. Ein Risiko entsteht, wenn die Erweiterung auf Interna des Standards aufsetzt, die sich ändern können, oder wenn sie nie gegen neue Versionen getestet wird. Planen Sie deshalb Tests im Sandbox-Environment vor jedem Versionswechsel ein.
Kann ich Felder zu einer Standard-API von Business Central hinzufügen?
Nein, in den Standard-APIs ist das Hinzufügen von Feldern nicht möglich. Der übliche Weg ist, den AL-Code der Standard-API zu kopieren und daraus eine eigene, benutzerdefinierte API zu erstellen. Für Ihr Schnittstellenkonzept sollte das früh geklärt sein.
Was kostet eine Anpassung von Business Central?
Das hängt vom Umfang, vom Abstimmungsbedarf und von der Testtiefe ab; ein Pauschalpreis wäre unseriös. Entscheidend ist, dass der Anbieter die Aufgabe in Konfiguration, App und Entwicklung trennt und jeden Teil getrennt bewertet. Die Lizenzkosten pro Benutzer finden Sie auf der Seite zu den Preisen.
Woran erkenne ich einen guten Business-Central-Entwickler?
An nachvollziehbaren Referenzen für Erweiterungen, die Updates überstanden haben, an einer klaren Testpraxis im Sandbox-Environment und an einer Dokumentation, die Ihnen gehört. Ein guter Entwickler schlägt zuerst Konfiguration oder eine bestehende App vor und programmiert erst, wenn das nicht reicht.
Quellen
- Microsoft Learn – Developing in Business Central
- Microsoft Learn – Business Central API v2.0
- Microsoft Learn – Operational limits (online)
- Microsoft Learn – Managing environments
- Microsoft Learn – Extensions and apps
- Microsoft Learn – Shopify connector overview
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.