Wie funktioniert ein B2B-Kundenportal mit Business Central?

Ein B2B-Kundenportal ersetzt Microsoft Dynamics 365 Business Central nicht. Es gibt Kunden und berechtigten Nutzern eine passende Oberfläche für ausgewählte Abläufe, während Business Central für die relevanten Stamm- und Auftragsdaten das führende System bleibt.

Das klingt zunächst einfach: Artikel anzeigen, Warenkorb füllen, Bestellung übertragen. Für einen verlässlichen Prozess müssen die Zuständigkeiten zwischen Portal und ERP jedoch bewusst festgelegt werden. Dieser Beitrag zeigt die wichtigsten Bausteine und die Fragen, die vor einer Umsetzung geklärt werden sollten.

Welche Aufgabe übernimmt das Portal?

Das Portal bildet den Teil des Prozesses ab, den externe oder interne Besteller selbst nutzen sollen. Je nach Anwendungsfall gehören dazu:

• Anmeldung und Berechtigungsprüfung
• Produktkatalog, Suche und Filter
• kundenspezifische Preise und verfügbare Artikel
• Warenkorb und Checkout
• Bestellhistorie und Statusinformationen
• Verwaltung von Nutzern und Rollen

Business Central bleibt dagegen die Quelle für die Daten und Regeln, die bereits dort gepflegt werden. Dazu können Artikel, Debitoren, Preise, Einheiten, Verfügbarkeiten und Verkaufsaufträge gehören. Welche Informationen tatsächlich benötigt werden, wird pro Projekt entschieden.

Der Datenfluss vom ERP bis zum Verkaufsauftrag

Ein typischer Ablauf lässt sich in fünf Schritte gliedern.

1. Business Central stellt die benötigten Daten bereit

Das Portal benötigt nur die Daten, die für den vorgesehenen Prozess relevant sind. Diese werden über definierte APIs oder einen abgestimmten Synchronisationsweg bereitgestellt. Ob eine Information direkt abgefragt oder zwischengespeichert wird, hängt von Aktualität, Datenmenge und Betriebsmodell ab.

Wichtig ist eine klare Datenhoheit: Wenn Business Central für einen Wert führend ist, sollte derselbe Wert nicht unabhängig im Portal gepflegt werden.

2. Der Nutzer arbeitet in einer passenden Oberfläche

Das Portal zeigt den jeweils berechtigten Nutzern den vorgesehenen Katalog und die für sie relevanten Informationen. Die Oberfläche kann dadurch einfacher und zielgerichteter sein als der direkte Zugriff auf das ERP.

3. Die Bestellung wird fachlich geprüft

Vor der Übergabe müssen die für den Auftrag wichtigen Angaben vollständig und plausibel sein. Welche Regeln im Portal und welche Regeln in Business Central geprüft werden, sollte ausdrücklich festgelegt werden. Dazu zählen beispielsweise Kunde, Lieferadresse, Artikel, Menge und Einheit.

4. Die API legt den Auftrag in Business Central an

Nach dem Checkout übergibt das Portal strukturierte Bestelldaten. Business Central verarbeitet sie nach der abgestimmten Logik und legt den Verkaufsauftrag an. Für den produktiven Betrieb müssen auch Rückmeldungen und Fehlerfälle definiert sein: Eine Bestellung darf weder unbemerkt verloren gehen noch versehentlich doppelt angelegt werden.

5. Relevante Informationen fließen zurück

Je nach Prozess kann das Portal Bestellnummern, Bearbeitungsstände oder weitere Informationen anzeigen. Dabei sollte nur zurückgespielt werden, was Kunden tatsächlich benötigen und was Business Central verlässlich bereitstellen kann.

Wie bleiben kundenspezifische Preise konsistent?

Die sichtbare Preislogik gehört zu den wichtigsten Integrationsfragen. Ein einzelner Artikelpreis reicht häufig nicht aus. Abhängig vom vorhandenen BC-Setup können unter anderem Preislisten, Rabatte, Einheiten, Währungen, Steuerlogik und Gültigkeitszeiträume eine Rolle spielen.

Deshalb sollte das Portal keine zweite, losgelöste Preiswelt aufbauen. Stattdessen wird festgelegt, wie die für den angemeldeten Kunden gültigen Preise aus Business Central ermittelt und im Portal angezeigt werden. Bei der Analyse gehört auch die Frage dazu, zu welchem Zeitpunkt ein Preis nochmals geprüft wird.

Benutzer, Rollen und Freigaben

Ein Firmenkunde kann mehrere Portalnutzer haben. Nicht jede Person soll automatisch dieselben Rechte erhalten. Typische Fragen sind:

• Wer darf Nutzer für ein Kundenkonto einladen oder sperren?
• Wer darf bestellen und wer darf nur Artikel ansehen?
• Gibt es unterschiedliche Lieferadressen oder Sortimente?
• Werden Bestellgrenzen oder interne Freigaben benötigt?
• Welche Aktionen müssen für Support und Nachvollziehbarkeit protokolliert werden?

Die Antworten bestimmen nicht nur die Oberfläche, sondern auch Datenmodell, Authentifizierung und Schnittstellen.

Was muss vor dem Projektstart geklärt sein?

Für eine belastbare erste Architektur reichen meist konkrete Antworten auf diese Punkte:

1. Nutzer und Zielprozess: Wer bestellt heute wie, und welches Ergebnis soll in Business Central entstehen?
2. Führende Datenquellen: Welche Daten kommen aus Business Central, welche entstehen im Portal?
3. Preis- und Sortimentslogik: Was darf ein angemeldeter Kunde sehen und zu welchen Konditionen?
4. Auftragsübergabe: Welche Felder, Prüfungen und Rückmeldungen sind für einen gültigen Verkaufsauftrag nötig?
5. Fehlerbehandlung: Was geschieht bei nicht erreichbaren Systemen, ungültigen Daten oder wiederholten Anfragen?
6. Betrieb und Datenschutz: Wer betreibt das Portal, wer erhält Zugriff und welche Daten werden wo gespeichert?

Diese Klärung verhindert, dass ein optisch fertiger Shop entsteht, dessen Übergabe an das ERP im Alltag unzuverlässig bleibt.

Ein produktives Beispiel

CentraFlow hat ein B2B-Bestellportal umgesetzt, das bei einem deutschen Profifußballverein produktiv eingesetzt wird. Artikel, Preise, Kunden und Verfügbarkeiten kommen aus Business Central. Abgeschlossene Bestellungen werden über eine direkte API als Verkaufsauftrag angelegt, ohne diesen Übergabeschritt nochmals manuell zu erfassen.

Die anonymisierte Referenz trennt belegte Projektangaben bewusst von fiktiven Demo-Daten. Dort sind der umgesetzte Bestellprozess, die ERP-Integration, Administration und technische Aspekte im Zusammenhang beschrieben.

Der sinnvolle nächste Schritt

Ein Portalprojekt beginnt nicht mit einer möglichst langen Funktionsliste. Sinnvoller ist ein abgegrenzter Prozess: Nutzer, Daten, Bestellung und gewünschtes Ergebnis in Business Central. Daraus lässt sich ableiten, welche Portaloberfläche, APIs und Betriebsbausteine tatsächlich gebraucht werden.

Mehr zum möglichen Leistungsumfang steht beim B2B-Kundenportal für Business Central. Wer die Umsetzung plant, kann die Arbeitsweise von Marcus Graff kennenlernen oder direkt eine erste Einschätzung anfragen.