.jpeg)
Stammdaten von Lieferanten: Wessen Aufgabe ist es in einer Restaurantgruppe?
Lieferanten werden zentral im ERP einer Gruppe angelegt, dann manuell in den Filialen erneut erfasst und lokal angepasst, sobald sich Preise oder Gebindegrößen ändern. Das zentrale Ziel des ERP-Rollouts – ein maßgeblicher Lieferantendatensatz – geht in der doppelten Dateneingabe unter, die er eigentlich beseitigen sollte. Die Lösung liegt nicht im Kauf eines anderen Tools, sondern darin, vier Einrichtungsfragen zu klären, bevor die beiden Plattformen miteinander kommunizieren.
Legen Sie die Datenquelle fest, und sperren Sie die andere Seite
Die Quelldatenbank eines Lieferanten ist das einzige System, in dem neue Lieferantendaten und Änderungen eingetragen werden dürfen; jedes andere System konsumiert diesen Datensatz nur lesend. In einer Restaurantgruppe, die sowohl ein ERP als auch eine Betreiberplattform betreibt, muss diese Entscheidung ausdrücklich getroffen werden. Geschieht das nicht, nehmen beide Systeme Änderungen an, beide laufen auseinander, und die doppelte Dateneingabe wiederholt sich Filiale für Filiale.
Drei Konfigurationen sind möglich. Nur die ersten beiden funktionieren.
| Konfiguration | Neue Lieferanten angelegt in | Preis- und Gebindeänderungen in | Filialnutzer können bearbeiten |
|---|---|---|---|
| ERP als Quelldatenbank | ERP | ERP | Nein |
| Plattform als Quelldatenbank | Betreiberplattform | Betreiberplattform | Nein |
| Keine Seite gesperrt | Beide | Beide | Ja |
Hält das ERP die finanzseitigen Lieferantendaten (Zahlungsbedingungen, Steuerregistrierung, Bankdaten), ist es die Quelldatenbank und die Betreiberplattform der Konsument. Hält die Betreiberplattform die einkaufsseitigen Daten (Artikelnummern, Gebindegrößen, Stückpreise, Filialabdeckung), kann die Plattform die Quelldatenbank sein und das ERP konsumiert sie. Die ungeklärte dritte Konfiguration ist kein Mittelweg – es ist der Zustand, den die Eigentümerfrage beseitigen sollte.
Passen Sie das Lieferantenkatalogschema an die ERP-Daten an
Ein Lieferantendatensatz, der als einzelne Zeile aus dem ERP eingeht, ist in der Filiale nicht verwendbar. Die Filiale muss in einer bestimmten Gebindegröße bestellen, nach einer bestimmten Maßeinheit einbuchen und eine bestimmte Artikelnummer auf der Rechnung ausweisen. Der Datensatz muss in einer Form ankommen, die all diese Felder trägt – sonst fügt die Filiale sie manuell hinzu, was die doppelte Dateneingabe in anderer Form ist.
| Feld | Inhalt | Warum die Filiale es braucht |
|---|---|---|
| Artikelcode | Die Basiskennung der Zutat im Gruppenkatalog | Verbindet die Lieferanten-SKU mit einer einzigen Rezeptkostenstelle |
| Maßeinheit | Zähleinheit am Regal (kg, Liter, Stück) | Inventur und Wareneingangsbuchungen müssen in dieser Einheit erfolgen |
| Verpackungsformat | Wie der Lieferant den Artikel verkauft (Karton, Tablett, Fass) | Bestellungen werden in Gebinden aufgegeben, nicht in Roheinheiten |
| Umrechnungsfaktor | Anzahl Zähleinheiten pro Gebinde | Wandelt einen Gebindepreis automatisch in Stückkosten um |
| Verfügbarkeitsstatus | Ob der Lieferant die SKU aktuell liefern kann | Verhindert Bestellungen, die nicht erfüllt werden |
| Lieferantencode | Die eigene Artikelnummer des Lieferanten | Gleicht die Rechnungszeile beim Wareneingang mit der Plattform-SKU ab |
Jede Lieferanten-SKU ist in der Filiale ein eigener Artikel mit eigener Maßeinheit, Verpackung, Umrechnungsfaktor, Verfügbarkeitsstatus und Lieferantencode – verknüpft mit dem entsprechenden Basiszutat im zentralen Katalog der Gruppe. Das macht den Lieferantendatensatz des ERP in der Filiale nutzbar, statt ein Name zu sein, den die Filiale bei jeder Bestellung neu interpretieren muss.
Schreibschutz für Filialen durch rollenbasierte Berechtigungen
Filialnutzer bearbeiten Lieferantendatensätze lokal selten, weil sie die Quelldatenbank ändern wollten. Sie tun es, weil die Plattform ihnen den Button gibt. Die Lösung ist kein Nutzerschulung – es ist, den Button für Rollen auszuschalten, die ihn nicht brauchen, und gleichzeitig jedem, der Preise und Gebindegrößen im Regal sehen muss, die Sicht zu erhalten.
Die rollenbasierte Berechtigungssteuerung arbeitet als granularer Berechtigungsbaum pro Modul. Standardrollen werden nur-lesend ausgeliefert und können nicht verändert werden; Administratoren erstellen aus dem Baum angepasste Rollen, und Berechtigungsabhängigkeiten werden automatisch erzwungen, sodass eine Rolle keine nachgelagerte Aktion erhalten kann ohne die vorgelagerte Voraussetzung. Die Konfiguration, die Eigentümerschaft sicherstellt, ist eine benutzerdefinierte Filialrolle mit Lesen im Lieferantenmodul und keinerlei Schreibzugriff.
API-Richtung konfigurieren: ERP schreibt ein, Plattform liest zurück
Ist das ERP die Quelldatenbank, ist die Integration nicht einseitig. Zwei Kanäle müssen separat und in entgegengesetzter Richtung eingerichtet werden; ihre Verwechslung ist der Grund, warum Stammdaten auch nach „Integration" noch auf beiden Seiten neu erfasst werden.
Upstream fließen neue Lieferanten und Änderungen vom ERP über die Lieferantenendpunkte der Plattform in die Betreiberplattform, sodass ein in der Finanzabteilung angelegter Lieferant ohne erneute Erfassung in jeder Filiale erscheint. Downstream stellt die Offene API der Betreiberplattform detaillierte Bestelldaten (Lebenszyklushistorie, bestätigte und eingegangene Mengen, angereicherte Lieferanteninformationen) bereit, damit das ERP nachvollziehen kann, was gegen jeden eingespeisten Lieferantendatensatz geschah. Dieses Downstream-Lesen schließt den Kreis; ohne es hat das ERP keine Sicht darauf, ob seine Lieferantendatensätze genutzt werden, und keine Grundlage, die Ausgaben je Lieferant abzustimmen.
Datensatz intakt halten, wenn sich das Filialnetz ändert
Lieferanteneigentümerschaft ist leicht stabil zu halten, wenn das Filialnetz konstant ist. Sie wird fragil, wenn ein Standort eröffnet, schließt, eine Marke wechselt oder die Zentralküche wechselt, aus der er beliefert wird – denn die meisten Systeme führen „welche Lieferanten sind wo aktiv" als manuell gepflegte Liste je Standort.
Ändert sich die Filialstruktur einer Markeneinheit in der Betreiberplattform, berechnet die Plattform automatisch neu, welche Lieferanten für jeden Artikel an jedem Standort aktiv sind – ohne standortspezifische Neuerfassung des Lieferantendatensatzes. Die einmal zentral getroffene Eigentümerschafsentscheidung überlebt die Reorganisation. Erfordert Ihre Integration die Neuzuweisung von Lieferanten bei jeder Standortänderung, liegt das nicht an einem Netzwerkproblem – es ist ein Zeichen, dass die Neuberechnung noch manuell im ERP erfolgt und nie ein maßgeblicher Zentraldatensatz existiert hat.
Wo Sie bei Ihrer eigenen Einrichtung beginnen sollten
Klären Sie diese vier Fragen, bevor ERP und Betreiberplattform verbunden werden. Ist eine Antwort unklar oder lautet sie „beide", ist genau dort die doppelte Dateneingabe, die zurückkommt.
Vier Einrichtungsfragen. Beantworten Sie jede, bevor die Integration beginnt:
- Welches System ist die Quelldatenbank? Benennen Sie es. Überall sonst in der Gruppe ist der Lieferantendatensatz nur lesbar.
- Passt das Datensatzschema? Artikelcode, Maßeinheit, Verpackung, Umrechnungsfaktor, Verfügbarkeitsstatus, Lieferantencode – mindestens sechs Felder.
- Sind Filialnutzer vom Bearbeiten ausgesperrt? Standardmäßig nur-lesend. Benutzerdefinierte Rollen aus dem Berechtigungsbaum. Kein Schreibzugriff unterhalb der Zentrale.
- Ist die API-Richtung in beiden Richtungen konfiguriert? Das ERP schreibt Lieferanten ein. Die Plattform liest Bestelldaten zurück. Separate Kanäle, beide erforderlich.
Ist eine Antwort unklar oder lautet sie „beide", ist genau dort die doppelte Dateneingabe, die zurückkommt.
- Welches System ist die Quelldatenbank? Benennen Sie es. Überall sonst in der Gruppe ist der Lieferantendatensatz nur lesbar.
- Passt das Datensatzschema? Die empfangende Seite benötigt Maßeinheit, Verpackung, Umrechnungsfaktor, Verfügbarkeitsstatus und Lieferantencode, damit der Datensatz in der Filiale verwendbar ist – nicht nur Lieferantenname und Zahlungsbedingungen.
- Sind Filialnutzer vom Bearbeiten ausgesperrt? Standardrollen nur-lesend, benutzerdefinierte Rollen aus dem Berechtigungsbaum, kein Bearbeitungsrecht im Lieferantenmodul unterhalb der Zentrale.
- Ist die API-Richtung in beiden Richtungen konfiguriert? ERP schreibt ein, Plattform liest zurück, auf separaten Kanälen, beide erforderlich.
Das Lieferantenverwaltung-Modul von Supy führt jede Lieferanten-SKU als eigenen Artikel mit eigener Maßeinheit, Verpackung und Umrechnungsfaktor; die Offene API liest detaillierte Bestelldaten je Lieferant zurück, sodass das ERP abgleichen kann, was gegen jeden eingespeisten Datensatz geschah. Kombiniert mit rollenbasierten Berechtigungen, die standardmäßig nur-lesend ausgeliefert werden, überlebt die einmal zentral getroffene Eigentümerschafsentscheidung jede Standortänderung und jeden Filialwechsel. Wenn Sie das in einem laufenden Rollout durcharbeiten, deckt unser Leitfaden zur Beschaffungssoftware für Restaurants den weiteren Beschaffungsbereich ab; der kostenlose ROI-Rechner kann die Argumentation für die zentrale Sperrung von Lieferantendaten unterstützen.
