Wie lasse ich Lieferanten Daten erfassen, ohne dass jeder Microsoft 365 braucht?

Von /

Ein Lieferant meldet seinen Liefertermin per Mail. Jemand tippt ihn ab. Beim nächsten kommt ein Fax, beim dritten ein Anruf auf die Mailbox, der erst zwei Tage später gehört wird. Du willst eigentlich nur eins: dass eine überschaubare Zahl von Lieferanten ihre Ist-Termine und Mengenabweichungen selbst einträgt, damit deine Disposition früh weiß, wenn etwas rutscht. Und dann liegt ein Angebot für ein Lieferantenportal auf dem Tisch, das jeden deiner Lieferanten zum lizenzierten Nutzer machen will.

Die Frage im Titel ist deshalb keine technische, sondern eine kaufmännische. Du willst Lieferanten Daten erfassen lassen, ohne pro Lieferant eine Lizenz in deiner Microsoft-365-Welt zu bezahlen. Das geht. Der teurere Fehler steckt an einer ganz anderen Stelle.

Das Problem ist nie das Portal, sondern die zweite Datenbank dahinter

Der erste Reflex im Mittelstand ist ein WordPress-Plugin oder ein externes SaaS-Portal. Beides funktioniert auf den ersten Blick. Beides legt deine Daten aber ein zweites Mal ab, meistens in einer MySQL-Datenbank, die nichts mit deinem ERP zu tun hat.

Ab da hast du zwei Wahrheiten und musst sie abgleichen. Die Bestellungen wandern aus dem ERP nach draußen, die Lieferantenmeldungen müssen wieder zurück. Der Weg nach draußen ist harmlos. Jede Nacht einmal die offenen Bestellungen aus dem SQL Server abgreifen und ins Portal schieben, das läuft.

Der Rückweg ist die heikle Stelle. Die vom Lieferanten erfassten Daten aus der MySQL-Datenbank zurück in den SQL Server zu schreiben, das ist der Punkt, an dem es leise kaputtgeht: Dubletten, wenn ein Lieferant denselben Termin zweimal meldet. Halbe Datensätze, wenn der nächtliche Abgleich klemmt. Und ein Schreibzugriff von außen auf eine Datenbank, die eigentlich dein ERP versorgt.

Ich habe so ein Plugin selbst gebaut. Es lief. Aber der Rück-Sync in den SQL Server war die Stelle, an der ich nicht ruhig geschlafen habe. Aus heutiger Sicht war nicht das Portal das Problem, sondern dass es überhaupt eine zweite Datenbank gab.

Der Trick: die zweite Datenbank weglassen

Microsoft Power Pages ist der Teil der Power Platform, der für genau diesen Fall gebaut ist: eine Webseite mit Anmeldung, an der externe Nutzer arbeiten, ohne Teil deiner internen Mannschaft zu sein. Drei Dinge machen den Unterschied zum selbstgebauten Plugin.

Externe Anmeldung statt Lizenz pro Kopf. Der Lieferant bekommt einen Link, meldet sich über einen Anmeldeanbieter an, sieht genau seine Bestellungen und nichts sonst. Ein authentifizierter Nutzer ist in Power Pages jemand, der sich an der Webseite anmeldet, gezählt einmal pro Person und Monat, egal wie oft er sich einloggt. Lizenziert wird das auf deiner Seite, nicht beim Lieferanten: entweder als Kapazitätspaket oder als Pay-as-you-go über deine Azure-Subscription, zuletzt in der Größenordnung von rund vier US-Dollar je aktivem Nutzer und Monat. Bei einer zweistelligen Lieferantenzahl reden wir über einen niedrigen zweistelligen Betrag im Monat, nicht über dreißig zusätzliche Microsoft-365-Postfächer.

Eine Wahrheit statt zwei. Hier liegt der eigentliche Hebel. Eine Virtual Table zeigt deine SQL-Server-Tabelle in Power Pages so, als wäre sie eine Dataverse-Tabelle, ohne die Daten zu kopieren. Der SQL-Server-Virtual-Connector liest und schreibt direkt gegen deinen Bestand. Kein zweites Datenmodell, kein nächtlicher Abgleich, kein Rück-Sync. Die zweite Datenbank, die in meinem alten Plugin der Stein des Anstoßes war, fällt ersatzlos weg.

Die Datenbank bleibt der Türsteher. Jetzt der wichtige Teil, den die Hochglanz-Demos überspringen: Lass das Portal nicht direkt in deine ERP-Tabellen schreiben. Lass es an die Tür klopfen. Du legst eine eigene Eingangstabelle an, in die der Lieferant meldet. Erst deine eigene, geprüfte T-SQL-Logik übernimmt von dort in den ERP-Kontext, innerhalb eines einzigen SQL Servers. Damit ist der riskante Schreibweg von draußen kein Sprung über eine Datenbankgrenze mehr, sondern eine kontrollierte Tür, an der die Datenbank selbst entscheidet, was reinkommt.

So eine Eingangstabelle ist schnell gebaut. Wer es selbst anpackt, findet hier das Muster, alle anderen springen zum nächsten Abschnitt.

-- Eingangstabelle fuer Lieferantenmeldungen. Das Portal schreibt nur hierhin,
-- niemals direkt in die ERP-Tabellen. Constraints sind der Tuersteher.
CREATE TABLE stg.tblLieferMeldung
(
     idLieferMeldung      INT IDENTITY(1,1) NOT NULL
    ,fiLmBestellposition  INT               NOT NULL
    ,strLmLieferantKennung VARCHAR(50)      NOT NULL  -- ID des angemeldeten Lieferanten
    ,dtmLmIstTermin       DATE              NULL
    ,decLmIstMenge        DECIMAL(18,3)     NULL
    ,strLmAbweichungsgrund VARCHAR(255)     NULL
    ,dtmLmEingang         DATETIME2(0)      NOT NULL CONSTRAINT dfLmEingang DEFAULT SYSDATETIME()
    ,bitLmVerarbeitet     BIT               NOT NULL CONSTRAINT dfLmVerarbeitet DEFAULT 0
    ,tsLm                 ROWVERSION
    ,CONSTRAINT pkLieferMeldung PRIMARY KEY (idLieferMeldung)
    ,CONSTRAINT ckLmMengePositiv CHECK (decLmIstMenge IS NULL OR decLmIstMenge >= 0)
);
GO

-- Dubletten-Tuersteher: pro offener Bestellposition und Lieferant nur eine
-- unverarbeitete Meldung. Eine zweite Meldung prallt am Index ab, nicht erst
-- im naechtlichen Abgleich.
CREATE UNIQUE INDEX uaLmBestellposLieferant_F
    ON stg.tblLieferMeldung (fiLmBestellposition, strLmLieferantKennung)
    WHERE bitLmVerarbeitet = 0;
GO

Der entscheidende Punkt steht nicht im Portal, sondern im UNIQUE INDEX und im CHECK: Eine doppelte Meldung wird abgewiesen, eine negative Menge auch, und zwar in dem Moment, in dem der Lieferant auf „Speichern“ klickt. Was früher der nächtliche Rück-Sync mühsam aufräumen musste, lehnt die Datenbank jetzt sofort ab. Das Übernehmen der geprüften Meldungen in die ERP-Tabellen erledigt danach eine ganz normale Stored Procedure, die du kennst und kontrollierst.

Wo der Ansatz an Grenzen stößt

Virtual Tables können nicht alles, was native Dataverse-Tabellen können. Eingebaute Dublettenerkennung, Change Tracking und Spaltensicherheit fehlen. Genau deshalb gehören die Prüfregeln in den SQL Server, als Constraint und Stored Procedure. Für einen Datenbank-Menschen ist das eher Vorteil als Mangel, aber man muss es vorher wissen, nicht hinterher.

Kostenlos ist das Ganze nicht. Eine Power-Pages-Umgebung mit Dataverse und die Nutzer-Kapazität kosten Geld. Der Unterschied zur Lizenz pro Lieferant ist: Diese Kosten fallen auf deiner Seite an, sind planbar und steigen nicht mit jedem neuen Postfach. Subscription-Pakete starten bei 100 Nutzern beziehungsweise mindestens 25 authentifizierten Nutzern pro Webseite. Für eine Handvoll Lieferanten ist Pay-as-you-go der ehrlichere Weg.

Und der Zuschnitt muss passen. Power Pages ist für eine überschaubare, angemeldete Nutzerschar gedacht, nicht für ein öffentliches Massenportal mit Hunderttausenden anonymen Besuchern. Für deine zweistellige Lieferantenzahl sitzt es genau richtig.

Was das für die Geschäftsführung heißt

Du musst dafür keinen einzigen Prozess umbauen. Du gibst einer kleinen Gruppe externer Partner einen kontrollierten Zugang zu genau den Feldern, die sie befüllen dürfen, und der Rest bleibt, wo er ist.

Praktisch bedeutet das drei Dinge. Erstens: eine Wahrheit. Der vom Lieferanten gemeldete Termin steht sofort dort, wo deine Disposition ihn sieht, nicht erst nach dem nächtlichen Abgleich. Zweitens: früher Alarm. Wenn ein Liefertermin rutscht oder eine Menge nicht stimmt, weißt du es, wenn der Lieferant es meldet, und nicht erst beim Wareneingang, wenn die Linie schon steht. Drittens: keine Lizenz pro Lieferant. Du zahlst für ein Portal, nicht für dreißig zusätzliche Plätze in deiner Microsoft-365-Welt.

Wenn du das einmal durchrechnen willst

Der Beitrag ist die Detailansicht zu einer größeren Frage, nämlich wann dein Bestand aus Access und SQL Server reicht und wo eine Power-Platform-Ergänzung sich lohnt. Die Lieferanten-Erfassung ist nur einer von acht Fällen dort.

Wer sich anschauen lassen möchte, ob das für die eigene Lieferantenschar trägt, erreicht mich über das kostenlose Erstgespräch. Dreißig Minuten reichen, um zu sortieren, ob Power Pages der richtige Weg ist oder ob in deinem Fall etwas Einfacheres genügt.

Quellen

Hinweis zu Preisen: Microsoft passt Lizenzmodell und Tarife regelmäßig an. Der genannte Pay-as-you-go-Satz ist der zuletzt veröffentlichte Richtwert und vor einer Kalkulation tagesaktuell zu prüfen.

Über Sönke Schäfer

Sönke Schäfer berät seit über 25 Jahren KMU im norddeutschen Raum bei Datenbank-Anwendungen mit Microsoft Access und SQL Server. Ein wiederkehrender Fall ist die Anbindung externer Partner an ein bestehendes SQL-Server-Backend, früher per WordPress-Plugin, heute pragmatischer über die Microsoft Power Platform, ohne die Stammdaten zu verdoppeln. Büro in Sierksdorf, Ostholstein, erreichbar für Unternehmen in Lübeck, Kiel, Hamburg und im gesamten norddeutschen Raum.

Ähnliche Beiträge

Nach oben scrollen