Business Central AL Extension entwickeln lassen
Schneller, direkter, wartbar
Business Central AL Extension entwickeln lassen: upgrade-sichere Extensions ohne Systemhaus-Overhead. Schnellere Lieferung, direkter Ansprechpartner.
Business Central deckt viel ab — aber nicht alles. Es gibt Prozesse, die zu spezifisch für den Standard sind: eine Preislogik, die Sonderkonditionen nach Kombinationsregeln berechnet, die BC nicht kennt. Ein Genehmigungsworkflow, der unternehmensinternen Hierarchien folgt, die sich nicht in Standard-Genehmigungseinrichtungen abbilden lassen. Eine Schnittstelle zu einem Drittanbieter, für den es keine fertige Anbindung gibt.
An diesem Punkt gibt es zwei Wege: Workarounds, die den Prozess an den Standard anpassen — oder eine Extension, die den Standard an den Prozess anpasst.
Workarounds kosten Anwenderzeit und produzieren Fehler. Extensions, wenn richtig entwickelt, lösen das Problem dauerhaft. Der entscheidende Unterschied zwischen einer guten und einer schlechten Extension: Eine schlechte Extension funktioniert beim ersten Release. Eine gute Extension funktioniert noch beim vierten Release danach.
Ich entwickle BC-Extensions in AL — upgrade-sicher, nach Microsoft AppSource-Standards, direkt für euren Anwendungsfall.
AL (Application Language) ist die einzige von Microsoft unterstützte Entwicklungssprache für Business Central. C/AL — die Sprache von Classic Navision und NAV — existiert in BC nicht mehr. Wer noch C/AL-Anpassungen aus einer Navision-Installation hat, braucht eine Neuentwicklung in AL, keine Portierung.
Was macht eine Extension "upgrade-sicher"? Das ist keine Marketingaussage, sondern eine konkrete Architekturentscheidung:
Das ist der Unterschied zwischen einer Extension, die sechs Monate nach Übergabe bei einem BC-Update zerbricht, und einer, die drei Jahre läuft.
Extensions für Microsoft AppSource müssen deutlich strengere Anforderungen erfüllen als On-Premise-Extensions: automatisierte Testabdeckung, definierte Berechtigungssätze, Lokalisation, keine hardcodierten Werte. Ich entwickle beides — AppSource-konforme Extensions für Unternehmen, die ihre Lösung veröffentlichen wollen, und On-Premise-Extensions für firmeninterne Anpassungen.
Für interne Extensions gelten nicht alle AppSource-Anforderungen zwingend — aber die Architekturprinzipien (Event Subscriptions, Table Extensions, keine Basis-Modifikationen) gelten immer.
Bevor eine Extension entwickelt wird, kläre ich: Löst eine Extension das Problem, oder gibt es eine bessere Antwort im BC-Standard, die bisher übersehen wurde? Wenn eine Extension der richtige Weg ist: Wie muss sie architektonisch aufgebaut sein, damit sie die Anforderungen erfüllt und beim nächsten Update stabil bleibt?
Diese Konzeptionsphase ist kurz — aber sie verhindert, dass eine Extension nach vier Wochen Entwicklung am falschen Ansatz hängt.
Ich übergebe keinen Code ohne Dokumentation. Jede Extension bekommt eine technische Dokumentation: welche Objekte wurden angelegt, welche Events werden abonniert, was tut die Extension, was tut sie nicht. Das ist die Grundlage für Wartbarkeit — auch wenn jemand anderes später an der Extension weiterarbeitet.
Ihr sucht AL-Extension-Entwicklung, wenn ihr:
Ein Systemhaus, das einen Mittelstandskunden betreut, liefert eine AL-Extension für einen Rabattberechnungsprozess — geplante Entwicklungszeit: sechs Wochen. Der Zeitplan verschiebt sich: Die erste Version wird nach neun Wochen geliefert. Beim nächsten BC-Update vier Monate später bricht die Extension, weil sie direkte Tabellenmodifikationen enthält. Reparaturauftrag: zwei Wochen. Gesamtzeit bis zur stabilen Lösung: über vier Monate.
Das ist kein Ausnahmefall — das ist das strukturelle Problem bei Systemhäusern mit mehreren parallelen Projekten, Projektmanagement-Overhead und wechselnden Entwicklern. Ein Freelancer ohne diese Struktur liefert typischerweise in einem anderen Zeitrahmen: Erstversion in drei bis vier Wochen, direkte Kommunikation ohne Projektleiter-Schicht, kein Handover zwischen Entwicklern.
Konkret: Bei einer Extension mittlerer Komplexität — eigene Berechnungslogik, ein zusätzlicher Report, eine Schnittstelle zu einem Drittsystem — rechne ich mit drei bis fünf Wochen von Konzeption bis Abnahme. Bei einem Systemhaus, das dasselbe Projekt als eines von zehn parallelen bearbeitet, sind sechs bis zehn Wochen realistisch. Der Unterschied ist kein Qualitätsunterschied — er ist ein Fokusunterschied.
Was ist der Unterschied zwischen AL und dem alten C/AL?
C/AL ist die Programmiersprache von Classic Navision und NAV — objektbasiert, monolithisch, kein Extensions-Modell. AL ist die moderne Entwicklungssprache für Business Central — extension-basiert, cloud-kompatibel, mit strikten Architekturvorgaben. C/AL-Code kann nicht direkt in BC genutzt werden. Wer NAV-Anpassungen nach BC überführen will, braucht eine Neuentwicklung in AL — das ist keine Portierung, sondern echte Entwicklungsarbeit.
Kann ich einen Freelancer beauftragen, wenn ich schon ein Systemhaus für BC-Betreuung habe?
Ja, das ist ein häufiges Setup. Unternehmen beauftragen mich parallel zu ihrem Systemhaus für spezifische Extensions, die das Systemhaus nicht entwickelt, zu lange braucht oder zu teuer anbietet. Ich übergebe sauber dokumentierten Code und kommuniziere bei Bedarf direkt mit dem betreuenden Systemhaus. Zuständigkeiten bleiben klar getrennt.
Wie stellt ihr sicher, dass Extensions bei BC-Updates stabil bleiben?
Durch Architektur: Event Subscriptions statt direkter Modifikation, Table Extensions statt Tabellenänderungen, kein Zugriff auf interne Microsoft-Funktionen. Das sind keine optionalen Best Practices — das ist der einzige Weg, der bei Microsoft's halbjährigem Release-Zyklus langfristig funktioniert. Ich teste Extensions zusätzlich gegen BC Beta-Releases, wenn ein Major Update ansteht.
Ich habe eine bestehende Extension, die ständig Probleme macht — kann das analysiert werden?
Ja. Eine Analyse bestehender Extensions ist ein eigener Leistungsbereich: Ich schaue mir die Architektur an, identifiziere kritische Stellen, und gebe eine ehrliche Einschätzung, ob Refactoring sinnvoll ist oder ob eine Neuentwicklung günstiger ist. Das dauert in der Regel ein bis zwei Tage und gibt eine klare Entscheidungsgrundlage.
Wie läuft das Erstgespräch ab?
30 Minuten. Du schilderst mir das Problem, ich sage dir ob und wie ich helfen kann — direkt, ohne Präsentation. Danach bekommst du eine schriftliche Einschätzung mit Aufwand und Vorgehen. Erst dann entscheidest du ob wir starten.
Anforderung besprechen — Einschätzung innerhalb von 24 Stunden.
Kein Jahresvertrag. Kein Mindestvolumen. Du zahlst für das gelöste Problem.
Weitere Themen: BC-Erweiterungen AL-Entwicklung · AL Code Review Business Central
Über mich
Freiberuflicher BC-Entwickler und Consultant aus Bochum. Ich arbeite direkt mit eurem Fachbereich — ohne Agentur-Overhead, ohne Account-Staffelung. Remote und vor Ort in NRW verfügbar.
Mehr über mich und meine LeistungenSchreib mir eine Nachricht oder ruf direkt an.
