Schritt‑für‑Schritt‑Plan zum Aufbau einer Web‑App für Lieferanten‑Preislisten und Verträge: Importe, Genehmigungen, Verlängerungen, Prüfpfade und sichere Benutzerzugriffe.
Das meiste Chaos bei Lieferantenpreisen und Verträgen sieht gleich aus: Preislisten liegen in per E‑Mail verschickten Tabellen, „final_FINAL“‑PDFs liegen auf gemeinsamen Laufwerken, und niemand ist sich wirklich sicher, welche Bedingungen aktuell sind. Die Folgen sind vorhersehbar — veraltete Preise in Bestellungen, vermeidbare Streitigkeiten mit Lieferanten und übersehene Verlängerungen.
Eine gute Web‑App sollte die Quelle der Wahrheit für Lieferanten‑Preislisten und Verträge zentralisieren und Änderungen durchgängig nachverfolgbar machen. Sie sollte reduzieren:
Gestalten Sie das System um die Personen herum, die wöchentlich mit Preisen und Bedingungen arbeiten:
Wählen Sie einige messbare Ziele frühzeitig:
Für die erste Version streben Sie zentrale Lieferantenstammdaten, Preislisten‑Import mit Validierung, Vertragsablage mit Schlüsseldaten, einfache Genehmigungen, Suche und einen Prüfpfad an.
Spätere Iterationen können tiefere ERP‑Integrationen, Klauselbibliotheken, automatisches Rechnungsabgleich, Multi‑Entity‑Unterstützung und erweiterte Reporting‑Dashboards hinzufügen.
Bevor Sie Bildschirme oder Tabellen skizzieren, kartieren Sie, was tatsächlich passiert — vom Moment, in dem ein Lieferant eine Preisliste sendet, bis zur Bestellung. Das verhindert, dass Sie ein generisches „Dokumentenarchiv“ bauen, wenn Sie wirklich ein kontrolliertes Preis‑System brauchen.
Fangen Sie an, indem Sie ein reales Beispiel mit Beschaffung, Finanzen und Recht durchgehen. Erfassen Sie Übergaben und Artefakte in jedem Schritt:
Ein einfaches Swimlane‑Diagramm (Lieferant → Einkäufer/Beschaffung → Recht → Finanzen → Betrieb) reicht oft aus.
Listen Sie Entscheidungen auf, die Geschäftsergebnisse verändern, und weisen Sie klare Verantwortliche zu:
Notieren Sie auch, wo Genehmigungen nach Schwellenwerten unterschiedlich sind (z. B. >5% Erhöhung braucht Finanzfreigabe), damit Sie diese Regeln später kodifizieren können.
Schreiben Sie die genauen Fragen auf, die die App am ersten Tag beantworten muss:
Diese Ausgaben sollten Datenfelder, Suche und Berichte treiben — nicht umgekehrt.
Beschaffungsdaten sind unordentlich. Dokumentieren Sie ausdrücklich häufige Ausnahmen:
Behandeln Sie diese Liste als Akzeptanzkriterien für Import und Genehmigung, damit das System die Realität unterstützt statt Workarounds zu erzwingen.
Eine gute Architektur für Lieferanten‑Preislisten und Verträge reduziert vor allem Abstimmungsaufwand und lässt Raum für Wachstum — weniger Modefunktionen als Praktikabilität.
Für die meisten Teams (1–6 Entwickler) ist ein modularer Monolith der beste Start: eine deploybare App mit klar getrennten Modulen und Grenzen. Sie bekommen schnellere Entwicklung, einfacheres Debugging und weniger Betriebskomplexität.
Nur bei klaren Gründen auf Services umstellen — z. B. hohe Importlasten, mehrere Teams, die parallel arbeiten, oder strikte Isolationserfordernisse. Ein typischer Weg: modularer Monolith → Auslagerung von Import/Processing und Dokumenten in Hintergrund‑Worker → optionales Aufspalten stark frequentierter Domänen.
Wenn Sie den Prototyp (Screens, Workflows, rollenbasierter Zugriff) beschleunigen möchten, kann eine Plattform wie Koder.ai helfen, eine React + Go + PostgreSQL‑Baseline aus einer strukturierten Chat‑Spec zu generieren und dann schnell an Importen, Genehmigungen und Prüfpfaden zu iterieren. Für Beschaffungsteams bedeutet das oft, Workflows mit echten Nutzern früher zu validieren — bevor Sie zu viel bauen.
Gestalten Sie die App um einige stabile Domänen:
Halten Sie jedes Modul für seine Regeln und Datenzugriffe verantwortlich. Auch im Monolithen erzwingen Sie Grenzen im Code (Packages, Namensgebung, klare APIs).
Integrationen ändern den Datenfluss, also reservieren Sie Erweiterungspunkte:
Definieren Sie messbare Erwartungen voraus:
Ein sauberes Datenmodell erhält Vertrauen in der Beschaffung. Wenn Nutzer fragen „Welcher Preis galt am 3. März?“ oder „Welcher Vertrag regelte diesen Einkauf?“, sollte die Datenbank eindeutig antworten können.
Starten Sie mit einer kleinen Menge klarer Datensätze:
Modellieren Sie Beziehungen so, wie Einkäufer arbeiten:
Wenn Sie mehrere Liefer‑/Buchungsstellen oder Geschäftseinheiten unterstützen, denken Sie über ein Scope‑Konzept nach (z. B. Firma, Standort, Region), das an Verträge und Preislisten angehängt werden kann.
Vermeiden Sie das direkte Editieren „lebender“ Datensätze. Stattdessen:
So sind Auditfragen leicht zu beantworten: Sie können rekonstruiere n, was wann genehmigt wurde und was sich geändert hat.
Halten Sie Referenzdaten in eigenen Tabellen, um Freitext‑Müll zu vermeiden:
Erzwingen Sie Identifikatoren, um stille Duplikate zu verhindern:
Preislisten kommen meist in Spreadsheets, die nie für Maschinen gedacht waren. Ein reibungsloser Import entscheidet darüber, ob die Nutzer die App nutzen oder weiter Excel per E‑Mail verschicken. Ziel: Uploads verzeihlich, gespeicherte Daten streng.
Unterstützen Sie CSV und XLSX vom ersten Tag. CSV ist gut für ERP‑/BI‑Exporte; XLSX ist das, was Lieferanten tatsächlich senden.
Bieten Sie eine downloadbare Vorlage an, die Ihr Datenmodell widerspiegelt (und Ratespiele reduziert). Enthalten sein sollten:
Versionieren Sie die Vorlage (z. B. Template v1, v2), damit Sie sie weiterentwickeln können, ohne bestehende Prozesse zu brechen.
Definieren Sie Mapping‑Regeln explizit und zeigen Sie diese beim Upload in der UI.
Gängige Aufteilung:
Wenn Sie benutzerdefinierte Spalten erlauben, behandeln Sie diese als Metadaten und speichern Sie sie separat, damit sie das Kernpreisschema nicht verschmutzen.
Führen Sie Validierungen durch, bevor etwas gespeichert wird:
Führen Sie Zeilen‑ und Dateiebene‑Validierungen durch (diese Zeile ist falsch vs. dieser Upload widerspricht vorhandenen Datensätzen).
Eine gute Importerfahrung sieht so aus: Upload → Vorschau → Korrigieren → Bestätigen.
Auf der Vorschauseite:
Vermeiden Sie „ganze Datei wegen einer fehlerhaften Zeile ablehnen“. Lassen Sie Nutzer wählen: nur gültige Zeilen importieren oder blockieren, bis alle Fehler behoben sind, je nach Governance.
Für Auditfähigkeit und einfache Wiederverarbeitung speichern Sie:
Das schafft eine belastbare Spur für Streitfälle („was haben wir wann importiert?“) und ermöglicht Reprozesse, wenn sich Validierungsregeln ändern.
Ein Vertragsdatensatz sollte mehr sein als ein Ablagefach. Er braucht genug strukturierte Daten, um Verlängerungen, Genehmigungen und Reporting zu steuern — und gleichzeitig unterschriebene Dokumente leicht auffindbar zu halten.
Beginnen Sie mit Feldern, die die üblichen Beschaffungsfragen beantworten:
Behalten Sie Freitext für Sonderfälle, normalisieren Sie jedoch alles, wonach Sie filtern, gruppieren oder benachrichtigen möchten.
Behandeln Sie Dokumente als erstklassige Objekte, die an den Vertrag gehängt werden:
Speichern Sie Metadaten zu jeder Datei: Dokumenttyp, Wirksamkeitsdatum, Version, Uploader und Vertraulichkeitsstufe. Wenn es Aufbewahrungspflichten gibt, fügen Sie Felder wie „aufbewahren bis" und „Legal Hold" hinzu, damit die App Löschungen verhindern und Audits unterstützen kann.
Änderungen dürfen die Historie nicht überschreiben. Modellieren Sie sie als datierte Änderungen, die entweder Laufzeiten verlängern (neues Enddatum), kommerzielle Bedingungen anpassen oder Umfang ändern.
Erfassen Sie, wo möglich, Schlüsselklassen als strukturierte Daten für Warnungen und Berichte — z. B. Kündigung aus wichtigem Grund erlaubt (Y/N), Indexierungsformel, Service Credits, Haftungsbegrenzung, Exklusivität.
Wenn Sie zentral einkaufen, aber an mehreren Standorten arbeiten, unterstützen Sie das Verknüpfen eines Vertrags mit mehreren Standorten/Geschäftseinheiten, mit optionalen standortspezifischen Overrides (z. B. Rechnungsadresse, Lieferbedingungen). Ebenso erlauben Sie, dass ein Vertrag eine Mutter‑Firma und ihre Tochtergesellschaften abdeckt, und behalten dabei eine klare „vertragspartei“ für Compliance‑Zwecke bei.
Genehmigungen machen Preise und Verträge belastbar. Ein klarer Workflow reduziert „wer hat das genehmigt?“‑Debatten und schafft einen wiederholbaren Pfad von Lieferanteneingang zu verwendbaren, konformen Daten.
Nutzen Sie einen einfachen, sichtbaren Lebenszyklus für Preislisten und Vertragsdatensätze:
Draft → Review → Approved → Active → Expired/Terminated
Definieren Sie Verantwortlichkeiten in der App (nicht als implizites Wissen):
Fügen Sie policy‑getriebene Prüfungen hinzu, die zusätzliche Genehmigungen auslösen:
Jede Genehmigung/Ablehnung sollte erfassen:
Setzen Sie Service‑Level‑Erwartungen, damit Genehmigungen nicht blockieren:
Governance funktioniert am besten, wenn sie in den Workflow eingebaut ist — nicht nachträglich erzwungen.
Eine Beschaffungs‑App lebt davon, wie schnell Menschen einfache Fragen beantworten: „Was ist der aktuelle Preis?“, „Welcher Vertrag regelt das?“, „Was hat sich seit letztem Quartal geändert?“ Gestalten Sie die UI um diese Workflows, nicht um Datenbanktabellen.
Bieten Sie zwei primäre Einstiegsseiten in der Top‑Navigation an:
Auf Ergebnisseiten verwenden Sie Vertragsfilter, die zur täglichen Arbeit passen: Wirksamkeitsdatum, Vertragsstatus (Draft/Active/Expired), Geschäftseinheit, Währung und „hat ausstehende Genehmigung“. Halten Sie Filter sichtbar und als entfernbare Chips, damit nicht‑technische Nutzer sich nicht verloren fühlen.
Lieferantenprofil sollte ein Hub sein: aktive Verträge, neueste Preisliste, offene Streitfälle/Notizen und ein „letzte Aktivitäten“‑Panel.
Vertragsansicht sollte beantworten „Was dürfen wir kaufen, zu welchen Bedingungen, bis wann?“ Zeigen Sie Schlüsselklauseln (Incoterms, Zahlungsbedingungen), angehängte Dokumente und eine Timeline der Änderungen.
Preislisten‑Vergleich ist dort, wo Nutzer Zeit verbringen. Zeigen Sie aktuell vs. vorherig nebeneinander mit:
Berichte sollten handlungsorientiert sein, nicht dekorativ: „läuft in 60 Tagen aus“, „größte Preiserhöhungen“, „Artikel mit mehreren aktiven Preisen“. Bieten Sie Ein‑Klick‑Exporte nach CSV für Finanzen und PDF für Sharing/Genehmigungen mit denselben Filtern an, damit Export und Ansicht übereinstimmen.
Verwenden Sie klare Begriffe („Wirksamkeitsdatum", nicht „Validity start"), Inline‑Hilfen bei schwierigen Feldern (Einheiten, Währung) und Empty‑States, die nächste Schritte erklären („Importieren Sie eine Preisliste, um Änderungen zu verfolgen"). Ein kurzes Onboarding‑Checklist unter /help reduziert Trainingsaufwand.
Sicherheit ist am einfachsten, wenn sie vom Anfang an in den Workflow eingebaut wird. Ziel: Leute sehen/ändern nur, wofür sie verantwortlich sind, und jede wichtige Änderung ist nachverfolgbar.
Starten Sie mit kleinem, klaren Rollenmodell und mappen Sie es auf Aktionen, nicht nur auf Screens:
Berechtigungen serverseitig für jeden Endpoint erzwingen (UI‑Berechtigungen allein reichen nicht). Bei komplexeren Organisationen Scope‑Regeln (z. B. nach Lieferant/Geschäftseinheit/Region) ergänzen.
Entscheiden Sie früh, was zusätzlichen Schutz braucht:
Erfassen Sie ein unveränderbares Audit‑Log für Schlüsselentitäten (Verträge, Klauseln, Preiszeilen, Genehmigungen): wer, was (vorher/nachher), wann, und Quelle (UI/Import/API). Protokollieren Sie Importdateinamen und Zeilennummern, damit Probleme zurückverfolgt werden können.
Wählen Sie eine primäre Login‑Methode:
Fügen Sie sinnvolle Session‑Kontrollen hinzu: kurzlebige Access‑Tokens, sichere Cookies, Inaktivitäts‑Timeouts und erneute Authentifizierung für sensible Aktionen (z. B. Preis‑Export).
Zielen Sie auf praktikable Kontrollen: Least Privilege, zentrales Logging, regelmäßige Backups und getestete Restore‑Prozeduren. Behandeln Sie Audit‑Logs als Geschäftsunterlagen — löschen verhindern und Aufbewahrungsregeln definieren.
Preis ist selten „eine Zahl“. Die App braucht klare Regeln, damit Einkäufer, AP und Lieferanten dieselbe Antwort auf „Was ist der Preis heute?“ bekommen.
Speichern Sie Preise als zeitlich begrenzte Datensätze mit Startdatum und optionalem Enddatum. Erlauben Sie future‑datierte Zeilen (z. B. Preiserhöhung zum Quartalsbeginn) und definieren Sie, was „offen“ bedeutet (typischerweise: gültig bis Ersatz).
Überschneidungen sollten bewusst gehandhabt werden:
Eine praktische Regel: ein aktiver Basispreis pro Lieferant‑Artikel‑Währung‑Einheit zu einem Zeitpunkt; alles andere muss als Override markiert sein.
Wenn mehrere Kandidaten existieren, definieren Sie eine Prioritätsreihenfolge, z. B.:
Wenn Ihre Prozesse bevorzugte Lieferanten haben, fügen Sie ein Lieferanten‑Prioritätsfeld hinzu, das nur genutzt wird, wenn mehrere gültige Lieferanten für denselben Artikel existieren.
Wählen Sie, ob Sie speichern:
Viele Teams tun beides: Preis in Originalwährung plus einen „as‑of“ konvertierten Wert für Reporting.
Definieren Sie Einheitennormalisierung (z. B. Stück vs. Karton vs. kg) und halten Sie Umrechnungsfaktoren versioniert. Wenden Sie Rundungsregeln konsistent an (Dezimalstellen, minimale Preisinkremente) und legen Sie fest, wann gerundet wird: nach Mengenumrechnung, nach FX‑Konversion und/oder beim finalen Zeilensumme.
Verlängerungen sind Stellen, an denen Vertragswert gewonnen oder verloren wird: verpasste Kündigungsfristen, stille automatische Verlängerungen und Last‑Minute‑Verhandlungen führen oft zu ungünstigen Bedingungen. Ihre App sollte Verlängerungen als gesteuerten Prozess mit klaren Daten, Verantwortlichen und sichtbaren Aufgaben behandeln.
Modellieren Sie Verlängerung als Satz von Meilensteinen pro Vertrag (und optional pro Änderung):
Bauen Sie Erinnerungen um diese Meilensteine herum. Ein pragmatischer Default ist 90/60/30‑Tage‑Abstand vor der kritischen Frist (Kündigungsfrist ist meist zentral), plus ein „Tag der Frist“‑Alarm.
Starten Sie mit zwei Kanälen:
Optional: ICS‑Kalenderexport (pro Vertrag oder Nutzer), sodass Besitzer in Outlook/Google Calendar abonnieren können.
Machen Sie Benachrichtigungen handlungsfähig: Vertragsname, Lieferant, exakter Termin und Deep‑Link zum Datensatz.
Alerts gehen an:
Fügen Sie Eskalationsregeln hinzu: wenn Primärinhaber nicht innerhalb X Tagen bestätigt, benachrichtigen Sie Backup oder Manager. Erfassen Sie „Acknowledged“‑Zeitstempel, damit Alerts nicht zu Hintergrundlärm werden.
Dashboards sollten einfach, filterbar und rollenbewusst sein:
Jedes Widget verlinkt in eine fokussierte Listenansicht mit Suche und Export, sodass das Dashboard Startpunkt für Aktion ist — nicht nur Reporting.
Ein MVP für Lieferanten‑Preislisten und Verträge muss eines beweisen: Teams können Preise sicher laden, den richtigen Vertrag schnell finden und Genehmigungen sowie Prüfpfade vertrauen.
Starten Sie mit einem schlanken, durchgängigen Workflow statt vieler Einzel‑Features:
Wenn Sie schnell mit kleinem Team vorankommen wollen, ziehen Sie Koder.ai in Betracht, um das Produktgerüst (React Frontend, Go Backend, PostgreSQL) zu generieren und im „Planungsmodus“ mit Beschaffung/Recht zu iterieren. Validieren Sie Workflow (Import → Genehmigung → Prüfpfad → Verlängerungs‑Alerts), dann exportieren Sie den Quellcode zum Weiterhärten.
Konzentrieren Sie Tests auf teure Fehlerbereiche:
Nutzen Sie eine Staging‑Umgebung mit ähnlich produktionsähnlichen (sanierten) Daten. Erfordern Sie eine Checkliste: Backups aktiviert, Migrationsskripte geprobt und ein Rollback‑Plan (versionierte DB‑Migrations + Deploy‑Revert).
Fügen Sie Monitoring für Importfehler, langsame Suchabfragen und Genehmigungsengpässe hinzu.
Führen Sie eine 2–4‑wöchige Feedback‑Schleife mit Beschaffung und Finanzen: häufige Importfehler, fehlende Vertragsfelder, langsame Bildschirme. Nächste Kandidaten: ERP‑Integrationen, Lieferantenportal‑Uploads, Analytics zu Einsparungen und Compliance.
Vorgeschlagene interne Lesungen: /pricing und /blog.
Beginnen Sie damit, zwei Dinge zu zentralisieren: Preislisten‑Versionen und Vertrags‑Versionen.
Im MVP enthalten sein sollten:
Nutzen Sie für die meisten Teams (1–6 Entwickler) eine modulare Monolith‑Architektur: eine deploybare App mit klar getrennten Modulen (Lieferanten, Preislisten, Verträge, Genehmigungen, Reporting).
Schwere Aufgaben wie Importe, Dokumentenverarbeitung und Benachrichtigungen in Hintergrund‑Worker auslagern, bevor Sie auf Microservices setzen.
Modellieren Sie die Mindestmenge an Entitäten:
Wichtige Verknüpfungen:
Nicht überschreiben. Versionieren:
„Aktuell“ ist dann eine Abfrage: die neueste genehmigte Version, die auf das gewählte Datum zutrifft.
Streben Sie „verzeihliches Hochladen, strikte gespeicherte Daten“ an:
Speichern Sie die Rohdatei + Mapping + Validierungsergebnisse zur Nachvollziehbarkeit und Re‑Verarbeitung.
Gängige Regeln:
Wenn Überschneidungen erlaubt sind (Promo/Override), verlangen Sie eine Begründung und Genehmigung.
Behalten Sie einen expliziten, konsistenten Statusablauf bei:
Wenden Sie dasselbe Konzept für Preislisten und Vertragsversionen an, damit Nutzer ein einziges Muster lernen.
Beginnen Sie mit einem einfachen Rollenmodell und erzwingen Sie es serverseitig:
Fügen Sie bei Bedarf Bereichs‑/Scope‑Berechtigungen hinzu (nach Geschäftseinheit/Region/Lieferant) und behandeln Sie Vertrags‑PDFs/Bankdaten als hochsensibel mit engeren Zugriffsbeschränkungen.
Modellieren Sie Meilensteine und machen Sie Alerts handlungsorientiert:
Dashboards, die Arbeit treiben:
Jedes Widget sollte zu einer gefilterten Listenansicht mit Exportlink führen.
