Business Central Entwickler Dortmund
Business Central Entwickler in Dortmund: AL-Entwicklung, Schnittstellen und BC-Implementierung. Freelancer ohne Overhead — remote und vor Ort im Ruhrgebiet.
Dortmund ist Logistikstandort mit Substanz: größter Binnenhafen Europas, dichte Lager- und Distributionszentren, Speditionen und Fulfillment-Dienstleister, die täglich Tausende von Bewegungen abwickeln. Das ERP-System steht dabei unter einem Druck, den andere Branchen kaum kennen: Bestandsdaten müssen in Echtzeit stimmen, Versandprozesse müssen automatisch anlaufen, und wenn mehrere Lager mit unterschiedlichen Systemen arbeiten, ist manuelles Zusammenführen keine Option — es ist ein tägliches Fehlerrisiko.
Als Business Central Entwickler Dortmund löse ich genau diese Klasse von Problemen. Nicht mit generischen Systemhaus-Paketen, sondern mit Extensions, die auf euren Lagerprozess zugeschnitten sind — WMS-Anbindungen, Versandautomatisierung, Multi-Lager-Setups. Ihr erklärt mir euren Prozess einmal. Ich analysiere, wo BC heute endet und wo die manuelle Arbeit anfängt, und entwickle die Verbindung, die fehlt.
Erste Diagnose in 48 Stunden — weil ihr direkt mit dem Entwickler sprecht, nicht mit einem Account-Manager, der das Gespräch intern weiterdelegiert.
Anbindung eures Lagerverwaltungssystems an Business Central — bidirektional, ereignisgesteuert, ohne manuelle Bestandsübertragungen. Typische Setups: WMS sendet Wareneingang, BC bucht ihn automatisch. Bestandskorrekturen aus dem WMS landen sofort in BC. Tagesverzögerungen beim Bestandsabgleich entfallen.
Automatische Versandaufträge aus BC-Verkaufsbelegen, Tracking-Nummern zurück in BC, Versandbestätigung an den Kunden ohne manuellen Eingriff. Für Carrier-Anbindungen (DHL, DPD, UPS) und individuelle Versandsoftware.
BC-Konfiguration und Extensions für Unternehmen mit mehreren Standorten oder Mandanten: standortübergreifende Umlagerungen, lagerübergreifende Verfügbarkeitsabfragen, konsolidierte Bestandsauswertungen.
Erweiterungen für Lager, Disposition und Faktura — gebaut in AL, upgrade-sicher, nach Microsoft AppSource-Standards. Kein Code, der beim nächsten BC-Update neu geschrieben werden muss.
Bestehende NAV-Installationen analysieren, Anpassungen als moderne BC-Extensions neu entwickeln, Daten sauber migrieren. Mit klarem Übergabedokument und Code, den jeder BC-Entwickler versteht.
Ein Dortmunder Logistikdienstleister betreibt drei Lagerhallen mit unterschiedlichen WMS-Instanzen. Business Central ist als ERP im Einsatz, aber der Bestandsabgleich zwischen WMS und BC läuft manuell: Lagermitarbeiter exportieren täglich eine CSV aus dem WMS, ein Mitarbeiter in der Buchhaltung überträgt die Differenzen in BC. Lieferverzögerungen entstehen nicht im Lager, sondern daran, dass BC-Bestände am nächsten Morgen einen Tag hinterherhinken.
Das Problem ist nicht komplex — es ist ungelöst. Ich analysiere zunächst die WMS-API-Schnittstelle: welche Endpoints stehen zur Verfügung, welche Ereignisse werden gefeuert, welches Format liefern die Bestandsdaten. Dann entwickle ich eine BC-Extension, die WMS-Ereignisse abonniert und Bestandsbuchungen in BC automatisch auslöst. Das Ergebnis: Bestände in BC und WMS sind synchron — ohne Tagesverzug, ohne Übertragungsfehler, ohne Personalzeit für manuelle Abgleiche.
Projekte dieser Art sind in acht bis zwölf Wochen produktiv — inkl. Testphase direkt mit eurem Lagerpersonal.
Die Situation, die ich am häufigsten sehe: Business Central ist eingeführt, aber Lagerprozesse laufen an BC vorbei. Bestände werden außerhalb gepflegt, Versand läuft über eine separate Anwendung, Schnittstellen zwischen WMS und BC existieren nicht — oder sind seit dem letzten Update instabil.
Das trifft auf euch zu, wenn ihr:
Typische Kunden: Logistikdienstleister, Fulfillment-Betriebe, Distributions- und Handelsunternehmen mit 20 bis 300 Mitarbeitern im Raum Dortmund, Ruhrgebiet und NRW.
Dortmund hat viele Logistikbetriebe mit eigenen WMS — funktioniert eine BC-Anbindung auch für weniger verbreitete Systeme?
In der Regel ja. Entscheidend ist, ob das WMS eine REST-API oder Webhook-Unterstützung mitbringt — das ist heute bei den meisten Systemen Standard. Bei älteren Systemen ohne API gibt es Alternative: Datei-basierte Übergaben (CSV, XML) lassen sich ebenfalls automatisieren, auch wenn das elegantere Lösung eine direkte API-Anbindung wäre. Ich schaue mir euer WMS im Erstgespräch an und sage euch ehrlich, was technisch machbar ist.
Wir haben mehrere Lager mit unterschiedlichen Systemen — ist das ein Problem?
Nein, sondern der Normalfall in Dortmunder Logistikbetrieben. BC ist für Multi-Lager-Setups ausgelegt, und Extensions lassen sich so bauen, dass sie mit mehreren WMS-Instanzen gleichzeitig kommunizieren. Wichtig ist eine saubere Planung der Datenflüsse — welches System ist Master für welche Daten, wie werden Konflikte aufgelöst. Das ist Teil der Analyse, bevor ich mit der Entwicklung anfange.
Wie upgrade-sicher sind AL-Extensions wirklich?
Extensions, die nach Microsoft AppSource-Standards entwickelt werden — mit Event Subscriptions statt Basistabellen-Modifikation — bleiben bei Major Releases in der Regel ohne Anpassung lauffähig. Ich halte mich strikt an diese Standards und liefere Code, der auch dann noch funktioniert, wenn euer Systemhaus wechselt.
Wie schnell könnt ihr mit einem Projekt starten?
Nach dem ersten Gespräch bekommt ihr eine schriftliche Einschätzung zu Aufwand und Vorgehen — meistens innerhalb von 48 Stunden. Projektstart je nach Umfang in der Regel innerhalb von zwei bis vier Wochen.
Kein Jahresvertrag. Kein Mindestvolumen. Erste Diagnose in 48 Stunden.
Weitere Themen: Business Central Entwickler NRW · BC-Schnittstellen-Entwicklung
Ü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.
