Web‑App zur Verwaltung von Lieferanten‑Preislisten und Verträgen

Was die App lösen soll (und für wen)

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.

Die zu behebenden Geschäftsprobleme

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:

• manuelles Kopieren zwischen Tabellen, ERPs und Postfächern
• Preisfehler durch veraltete Versionen
• verpasste Verlängerungen und Kündigungsfristen
• Zeitaufwand für das Finden des aktuell unterschriebenen Dokuments oder einer Änderung

Für wen die App gedacht ist

Gestalten Sie das System um die Personen herum, die wöchentlich mit Preisen und Bedingungen arbeiten:

• Beschaffung: importiert Preislisten, verhandelt Anpassungen, verfolgt Wirksamkeitsdaten
• Finanzen/Accounts Payable: validiert fakturierte Preise, prüft Währungen, Einheiten, Steuern/Gebühren
• Recht/Compliance: speichert unterschriebene Vereinbarungen, Änderungen, erforderliche Klauseln
• Genehmiger (Management): prüft und genehmigt Preis‑/Bedingungsänderungen
• Admins: verwalten Nutzer, Rollen, Lieferanten‑Stammdaten, Vorlagen

Erfolgskennzahlen, die zeigen, dass es funktioniert

Wählen Sie einige messbare Ziele frühzeitig:

• Zeit bis zur Veröffentlichung einer Preisanpassung (z. B. von 2 Tagen auf 2 Stunden)
• Import‑Fehlerrate und Anzahl manueller Korrekturen pro Upload
• Trefferquote für Verlängerungs‑Erinnerungen (z. B. % Verträge mit Warnungen vor Frist)
• Preisabweichungsrate (Rechnung/PO‑Abweichungen bezogen auf Preisgültigkeit)

Was „fertig“ bedeutet: Erstes Release vs. spätere

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.

Anforderungen und Abbildung des Workflows

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.

Den aktuellen Workflow (Ist‑Zustand) abbilden

Fangen Sie an, indem Sie ein reales Beispiel mit Beschaffung, Finanzen und Recht durchgehen. Erfassen Sie Übergaben und Artefakte in jedem Schritt:

• Preisliste erhalten (E‑Mail, Portal, Tabelle, EDI) → Empfangsdatum und Quelle protokollieren
• Prüfen und verhandeln → Fragen, Gegenangebote und vereinbarte Änderungen erfassen
• Preise und Bedingungen genehmigen → Entscheidungs‑ und Unterschriftsstellen identifizieren
• Vertrag unterschreiben und ablegen → Bedingungen mit der wirksamen Preisliste verknüpfen
• Operativ arbeiten und verlängern → Abläufe, Preisänderungen und Ausnahmen überwachen

Ein einfaches Swimlane‑Diagramm (Lieferant → Einkäufer/Beschaffung → Recht → Finanzen → Betrieb) reicht oft aus.

Schlüsselentscheidungen und Rollen identifizieren (wer darf was)

Listen Sie Entscheidungen auf, die Geschäftsergebnisse verändern, und weisen Sie klare Verantwortliche zu:

• Wer darf eine neue Preisliste genehmigen vs. einen Vertragszusatz?
• Wer darf Preisfelder bearbeiten (Währung, Einheiten, MOQ, Lieferzeit) und wer nur Änderungen anfragen?
• Wer darf sensible Vertragsklauseln sehen (Zahlungsbedingungen, Haftungsklauseln) und wer soll eingeschränkt sein?

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.

Benötigte Ausgaben definieren (was die Nutzer am ersten Tag beantwortet bekommen müssen)

Schreiben Sie die genauen Fragen auf, die die App am ersten Tag beantworten muss:

• „Was ist der aktuelle Preis für Artikel X vom Lieferanten Y, gültig heute?“
• „Welche Verträge laufen in den nächsten 60/90 Tagen aus und wer ist für die Verlängerung verantwortlich?“
• „Wo haben wir Ausnahmen: abgelaufene Preise, fehlende MOQs, Währungsabweichungen?“

Diese Ausgaben sollten Datenfelder, Suche und Berichte treiben — nicht umgekehrt.

Schmerzpunkte und Randfälle früh erfassen

Beschaffungsdaten sind unordentlich. Dokumentieren Sie ausdrücklich häufige Ausnahmen:

• Teilweise Updates (Lieferant aktualisiert 20 SKUs, nicht den gesamten Katalog)
• Mehrere Währungen und FX‑Annahmen
• MOQs, Verpackungsgrößen, Einheiten (Stück vs. Karton) und Rundungsregeln
• Überschneidende Wirksamkeitszeiträume oder nachträgliche Korrekturen

Behandeln Sie diese Liste als Akzeptanzkriterien für Import und Genehmigung, damit das System die Realität unterstützt statt Workarounds zu erzwingen.

Architektur auf hoher Ebene und Modulaufteilung

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.

Bauansatz: klein anfangen, gezielt weiterentwickeln

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.

Kernmodule (die Mindestmenge, die verständlich bleibt)

Gestalten Sie die App um einige stabile Domänen:

• Lieferanten: Lieferantenprofil, Kontakte, Identifikatoren, Status
• Katalog (Artikel/Materialien): eigener Artikelstamm und Zuordnung zu Lieferantenartikeln
• Preislisten: Header (Lieferant, Gültigkeitszeitraum) und Zeilen (Preise, Einheiten, Währungen), plus Importhistorie
• Verträge: Vertragsdatensätze, verknüpfte Lieferanten, abgedeckte Artikel/Kategorien, Schlüsseldaten und zugehörige Dokumente
• Genehmigungen & Governance: Prüfschritte, Freigaben, Kommentare und Entscheidungs‑Historie
• Reporting: Suche, Exporte, Ausgaben/Preis‑Ansichten und operative Snapshots

Halten Sie jedes Modul für seine Regeln und Datenzugriffe verantwortlich. Auch im Monolithen erzwingen Sie Grenzen im Code (Packages, Namensgebung, klare APIs).

Integrationen früh planen (auch wenn Sie sie nicht sofort bauen)

Integrationen ändern den Datenfluss, also reservieren Sie Erweiterungspunkte:

• SSO (SAML/OIDC) für Authentifizierung und Nutzerprovisionierung
• ERP/Finanzsysteme für Lieferanten‑IDs, Artikelstamm und Übertragung freigegebener Preise
• E‑Mail/Kalender für Verlängerungs‑Erinnerungen und Genehmigungsnachrichten
• Dokumentenunterschrift (optional) zur Finalisierung von Änderungen und neuen Vereinbarungen

Nicht‑funktionale Anforderungen (Ziele vor dem Launch setzen)

Definieren Sie messbare Erwartungen voraus:

• Performance: häufige Suchen in <2 Sekunden; Importe asynchron mit Fortschrittsanzeige
• Verfügbarkeit: klares Uptime‑Ziel und geplante Wartungsfenster
• Backups & Recovery: automatisierte Backups, Restore‑Drills und Aufbewahrung gemäß Policy
• Prüfbarkeit: unveränderbare Ereignishistorie für Importe, Genehmigungen und Vertragsänderungen mit Nutzer‑ und Zeitstempel

Datenmodell: Entitäten, Beziehungen und Versionierung

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.

Kernentitäten (die Mindestmenge)

Starten Sie mit einer kleinen Menge klarer Datensätze:

• Lieferant: Lieferantenkonto (Name, Lieferantencode, Status, Standardwährung, Zahlungsbedingungen)
• Kontakt: Ansprechpartner beim Lieferanten (mehrere pro Lieferant)
• Artikel/SKU: was Sie kaufen (Artikelcode, Beschreibung, Kategorie, Maßeinheit)
• PriceList: vom Lieferanten gelieferte Liste oder vereinbarter Tarif (Name, Wirksamkeitsdaten, Währung, Dateiquelle, Status)
• PriceLine: Zeilen innerhalb einer Liste (Artikel, Stückpreis, Staffel/MOQ, Steuerkennzeichen)
• Vertrag: kommerzielle Vereinbarung (Vertragsnummer, Lieferant, Start/Enddatum, Verlängerungseinstellungen, Status)
• Klausel (Term): strukturierte Klauseln (Lieferzeit, Gewährleistung, Lieferung, Servicelevels) für Suche/Reporting

Beziehungen, die alles verbinden

Modellieren Sie Beziehungen so, wie Einkäufer arbeiten:

• Lieferant → Verträge: ein Lieferant kann viele Verträge haben
• Lieferant → Preislisten: ein Lieferant kann über die Zeit viele Preislisten liefern
• Vertrag → Preislisten (optional, aber nützlich): verknüpfen Sie einen Vertrag mit den Preislisten, die er regelt
• Artikel/SKU → PriceLines: ein Artikel kann in vielen Preiszeilen auftauchen (verschiedene Lieferanten, Währungen, Wirksamkeitsdaten)

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.

Versionierung: Historie nicht überschreiben

Vermeiden Sie das direkte Editieren „lebender“ Datensätze. Stattdessen:

• Preislisten‑Versionierung: jeder Import erzeugt eine neue PriceList‑Version (oder einen neuen PriceList‑Eintrag mit gemeinsamer Familien‑ID). Vorherige Versionen schreibgeschützt halten.
• Vertragsänderungen: jede Änderung als neue Version mit eigenem Wirksamkeitsdatum und verknüpften Dokumenten speichern. Die „aktuelle“ Vertragsansicht ist die zuletzt genehmigte Version.

So sind Auditfragen leicht zu beantworten: Sie können rekonstruiere n, was wann genehmigt wurde und was sich geändert hat.

Referenzdaten und Eindeutigkeitsregeln

Halten Sie Referenzdaten in eigenen Tabellen, um Freitext‑Müll zu vermeiden:

• Währung, Maßeinheit, Steuercode, ggf. Incoterms

Erzwingen Sie Identifikatoren, um stille Duplikate zu verhindern:

• Lieferantencode eindeutig im System
• Artikelcode eindeutig (oder eindeutig pro Katalog/Quelle)
• Vertragsnummer eindeutig pro Lieferant (oder global — wählen und durchsetzen)

Preislisten‑Import: Vorlagen, Validierung und Fehlerbehandlung

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ützte Formate und herunterladbare Vorlage

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:

• Erste Zeile mit exakten Spaltennamen
• Eine Beispielzeile mit gültigen Werten (Währung, Einheit, Datum)
• Optionales „Notes“-Sheet (für XLSX), das jede Spalte erklärt

Versionieren Sie die Vorlage (z. B. Template v1, v2), damit Sie sie weiterentwickeln können, ohne bestehende Prozesse zu brechen.

Mapping‑Regeln: Pflicht vs. optional

Definieren Sie Mapping‑Regeln explizit und zeigen Sie diese beim Upload in der UI.

Gängige Aufteilung:

• Pflichtspalten: Lieferanten‑Identifier, Artikel/SKU, Preis, Währung, Maßeinheit, Wirksamkeits‑Startdatum
• Optionale Spalten: Wirksamkeits‑Enddatum, Mindestbestellmenge, Lieferzeit, Verpackung, Incoterms, Kommentare
• Standardwerte (pro Lieferant oder Upload): Währung, Einheit, Startdatum „heute“, Enddatum leer

Wenn Sie benutzerdefinierte Spalten erlauben, behandeln Sie diese als Metadaten und speichern Sie sie separat, damit sie das Kernpreisschema nicht verschmutzen.

Validierungsregeln, die schlechte Daten verhindern

Führen Sie Validierungen durch, bevor etwas gespeichert wird:

• Numerische Formate: nicht numerische Preiszellen ablehnen; Tausendertrennzeichen normalisieren; nicht‑negative Preise erzwingen
• Währungscodes: gegen ISO 4217 validieren (z. B. USD, EUR)
• Datumsbereiche: Startdatum erforderlich; Enddatum muss nach Startdatum liegen; Überschneidungen verhindern, wenn Ihre Regeln Exklusivität verlangen
• Duplikatzeilen: identische Schlüssel erkennen (z. B. Lieferant + SKU + Startdatum + Währung + Einheit). Entscheiden Sie, ob Duplikate Fehler sind oder „letzter gewinnt" (Fehler ist konservativer)

Führen Sie Zeilen‑ und Dateiebene‑Validierungen durch (diese Zeile ist falsch vs. dieser Upload widerspricht vorhandenen Datensätzen).

Fehlerbehandlung: Vorschau, zeilenweises Feedback und Reupload

Eine gute Importerfahrung sieht so aus: Upload → Vorschau → Korrigieren → Bestätigen.

Auf der Vorschauseite:

• Zeigen Sie eine Tabelle mit markierten Zellen und klaren Meldungen (z. B. „Ungültiger Währungscode: US$“)
• Ermöglichen Sie den Download eines Fehlerberichts (CSV) mit einer zusätzlichen Spalte „error"
• Bieten Sie einen Fix‑und‑Reupload‑Flow an, der die letzten Mapping‑Einstellungen behält

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.

Roh‑Uploads für Nachvollziehbarkeit speichern

Für Auditfähigkeit und einfache Wiederverarbeitung speichern Sie:

• Die originale Rohdatei (exakte Bytes) mit Checksum und Uploader‑Identität
• Geparste Zeilen und Validierungsergebnisse (inkl. Fehler)
• Importkonfiguration (Vorlagenversion, Spaltenmapping, Standardwerte)

Das schafft eine belastbare Spur für Streitfälle („was haben wir wann importiert?“) und ermöglicht Reprozesse, wenn sich Validierungsregeln ändern.

Vertragsdatensätze: Bedingungen, Dokumente und Änderungen

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.

Kernvertragsfelder (strukturierte Felder)

Beginnen Sie mit Feldern, die die üblichen Beschaffungsfragen beantworten:

• Vertragsbeginn und Vertragsende
• Verlängerungstyp (automatisch, feste Laufzeit, evergreen) und Verlängerungsdauer
• Kündigungsfrist (z. B. „60 Tage vor Ende") und wer benachrichtigt werden muss
• Zahlungsbedingungen (Net 30/45/60, Skonto) und Rechnungsregeln
• Vertragsverantwortlicher, Lieferantenkontakt und interne Stakeholder

Behalten Sie Freitext für Sonderfälle, normalisieren Sie jedoch alles, wonach Sie filtern, gruppieren oder benachrichtigen möchten.

Dokumente, Anhänge und Aufbewahrung

Behandeln Sie Dokumente als erstklassige Objekte, die an den Vertrag gehängt werden:

• Unterschriebene Vereinbarung (PDF)
• Änderungen/Appendices
• Leistungsbeschreibungen, Preislisten, Versicherungsnachweise, Compliance‑Dokumente

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 und Klausel‑Tracking

Ä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.

Ein Vertrag, viele Standorte oder Lieferanten

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.

Genehmigungsworkflow und Governance

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.

Statusfluss (explizit halten)

Nutzen Sie einen einfachen, sichtbaren Lebenszyklus für Preislisten und Vertragsdatensätze:

Draft → Review → Approved → Active → Expired/Terminated

• Draft: vom Einreicher editierbar; nicht für Beschaffung nutzbar.
• Review: nur über Änderungsanforderung editierbar; Reviewer prüfen Vollständigkeit und Policy‑Konformität.
• Approved: Entscheidung protokolliert; kann gemäß Datum aktiviert werden.
• Active: gültig für Bestellungen; Änderungen erfordern neue Revision und Genehmigung.
• Expired/Terminated: schreibgeschützt; für Reporting und Prüfung aufbewahrt.

Rollen und Verantwortlichkeiten

Definieren Sie Verantwortlichkeiten in der App (nicht als implizites Wissen):

• Einreicher (Beschaffung/Lieferantenmanager): lädt Preislisten hoch, erstellt Vertragsentwürfe, beantwortet Review‑Kommentare
• Reviewer (Kategorie/Finance): prüft Preise, Einheiten, Währungen und kommerzielle Ausrichtung
• Genehmiger (Budgetverantwortlicher): endgültige Entscheidung bei kommerzieller Relevanz
• Legal: erforderlicher Reviewer/Genehmiger für Vertragsformulierung, Dokumente und Änderungen
• Admin: konfiguriert Schwellenwerte, Routing‑Regeln und verwaltet Berechtigungen — sollte standardmäßig nicht Geschäftsinhalt genehmigen

Regeln für Preisänderungen (stille Kostensteigerung verhindern)

Fügen Sie policy‑getriebene Prüfungen hinzu, die zusätzliche Genehmigungen auslösen:

• Schwellen‑Genehmigungen: z. B. jede Positionserhöhung >5% oder Gesamtauswirkungsgrenze >10.000$ routet an einen höheren Genehmiger
• Kategorie‑Routing: strategische Kategorien (IT, Logistik) benötigen immer Legal + Budgetverantwortlichen
• Ausnahmebehandlung: Overrides nur mit verpflichtender Begründung und Anhang zulassen

Prüfbereite Entscheidungen: Kommentare, Gründe und Belege

Jede Genehmigung/Ablehnung sollte erfassen:

• Entscheidung (Genehmigt/Ablehnt/Änderungen angefordert)
• Grundcode + Freitexterklärung
• Zeitstempel, Akteur und betroffene Revision
• Verknüpftes Beweismaterial (E‑Mail‑PDF, Lieferanten‑Schreiben, Meeting‑Notizen)

Eskalation, Timeouts und Verantwortlichkeit

Setzen Sie Service‑Level‑Erwartungen, damit Genehmigungen nicht blockieren:

• automatische Erinnerungen nach 24/48 Stunden
• Eskalation an Stellvertreter nach konfigurierter Zeitüberschreitung
• Sichtbarkeit via „Meine ausstehenden Genehmigungen“ und einem Überfälligen‑Bericht

Governance funktioniert am besten, wenn sie in den Workflow eingebaut ist — nicht nachträglich erzwungen.

Benutzererlebnis: Screens, Suche und Reporting

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.

Schnell finden: Suche und Filter

Bieten Sie zwei primäre Einstiegsseiten in der Top‑Navigation an:

• Lieferantensuche (Name, Steuer‑ID/Lieferantencode, Status, Kategorie)
• Artikelsuche (SKU/Teilenummer, Beschreibung, Hersteller, Einheit)

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.

Schlüsselseiten zuerst gestalten

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:

• Wirksamkeitsdaten (inkl. zukünftiger Preise)
• Deltas pro Artikel (absolut und in %)
• Hervorhebung neuer/entfernter Artikel

Reporting und Exporte

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.

Einfach und selbsterklärend bleiben

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, Berechtigungen und Prüfpfad

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.

Rollen und Berechtigungen (Least Privilege)

Starten Sie mit kleinem, klaren Rollenmodell und mappen Sie es auf Aktionen, nicht nur auf Screens:

• Viewer: Lesezugriff auf genehmigte Preislisten und aktive Verträge
• Editor: Drafts erstellen, Dokumente hochladen, Importe vorbereiten, Validierungsfehler beheben
• Approver: genehmigen/ablehnen, Wirksamkeitsdaten sperren, Änderungen signieren
• Admin: Nutzer, Rollen, Referenzdaten und Systemeinstellungen verwalten

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.

Umgang mit sensiblen Daten

Entscheiden Sie früh, was zusätzlichen Schutz braucht:

• Vertragsdateien (PDFs, Scans): ruhend verschlüsseln, Download einschränken, optional Wasserzeichen
• Bankdaten: getrennt und stärker eingeschränkt speichern; Sichtbarkeit nur für enge Finanzrolle
• Preis‑Sichtbarkeit: denken Sie daran, Margen oder spezielle Preise vor breiter Anzeige zu schützen; unterstützen Sie „intern vs. lieferanten‑sicht“ falls nötig

Prüfpfad: wer hat was wie geändert

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.

Authentifizierung und Session‑Basics

Wählen Sie eine primäre Login‑Methode:

• SSO (SAML/OIDC) für Enterprise‑Nutzer oder Passwort + MFA für kleinere Teams

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).

Compliance‑Basics (ohne Überversprechen)

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.

Preisregeln: Wirksamkeitsdaten, Währungen und Einheiten

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.

Wirksamkeitsdatierung (Start/Ende, zukünftige Preise, Überschneidungen)

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:

• Standard: Überschneidungen ablehnen beim Import (gute Governance)
• Erlauben mit Priorität, wenn nötig (z. B. Promotion), aber mit Pflichtfeld Begründung + Genehmigung

Eine praktische Regel: ein aktiver Basispreis pro Lieferant‑Artikel‑Währung‑Einheit zu einem Zeitpunkt; alles andere muss als Override markiert sein.

Definition des „aktuellen Preises"

Wenn mehrere Kandidaten existieren, definieren Sie eine Prioritätsreihenfolge, z. B.:

1. Vertragsgedeckter Preis (wenn Vertrag aktiv und Artikel umfasst)
2. Genehmigter Override (Promo/Ausnahme) innerhalb des Datumsbereichs
3. Standardlieferanten‑Preisliste innerhalb des Datumsbereichs
4. Fallback oder „kein Preis“ Zustand (benötigt Nutzeraktion)

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.

Multi‑Währungs‑Strategie

Wählen Sie, ob Sie speichern:

• FX‑Rate pro Preisdatensatz (besser für Audit; reproduziert historische Entscheidungen)
• Live‑FX‑Konvertierung (für Dashboards nützlich; Originalwährung trotzdem speichern)

Viele Teams tun beides: Preis in Originalwährung plus einen „as‑of“ konvertierten Wert für Reporting.

Rundung und Mengenumrechnung

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, Alerts und operative Dashboards

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.

Verlängerungszeitachse und Erinnerungen

Modellieren Sie Verlängerung als Satz von Meilensteinen pro Vertrag (und optional pro Änderung):

• Enddatum (Ablauf)
• Kündigungsfrist‑Deadline (spätester Termin zum Kündigen/Neuverhandeln)
• Start des Verlängerungsfensters (wann Sourcing beginnen sollte)

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.

Benachrichtigungskanäle und Zustellung

Starten Sie mit zwei Kanälen:

• In‑App‑Benachrichtigungen für tägliche Workqueues
• E‑Mail für zeitkritische Erinnerungen

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.

Ownership und Eskalation

Alerts gehen an:

• Vertragsinhaber (primär)
• Kategorie‑Owner (sekundär, falls abweichend)
• Backup‑Owner (für Abdeckung)

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.

Operative Dashboards, die Arbeit treiben

Dashboards sollten einfach, filterbar und rollenbewusst sein:

• Bald auslaufende Verträge (30/60/90 Tage, inkl. Kündigungsfrist‑Deadlines)
• Verträge mit überfälligen Verlängerungsaufgaben (nicht bestätigt oder Meilenstein verpasst)
• Preislisten, die auf Genehmigung warten (Alter, Inhaber, Lieferant)

Jedes Widget verlinkt in eine fokussierte Listenansicht mit Suche und Export, sodass das Dashboard Startpunkt für Aktion ist — nicht nur Reporting.

MVP‑Plan, Tests und Rollout‑Checkliste

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.

MVP‑Scope (Must‑haves)

Starten Sie mit einem schlanken, durchgängigen Workflow statt vieler Einzel‑Features:

• Lieferanten‑ + Artikelstamm Grundlagen: Lieferanten, Produkte/Dienstleistungen, Einheiten, Währungen
• Preislisten‑Import: ein oder zwei Vorlagen (CSV/XLSX), Vorschau, Mapping (falls nötig), Validierung und Fehlerbericht
• Vertragsdatensatz: Schlüsseldaten (Start/Ende, Kündigungsfrist, Verlängerungstyp), Anhänge, Verknüpfung zu Lieferant und relevanten Preislisten‑Versionen
• Genehmigungen: ein einfacher Workflow (Draft → Review → Approved) mit rollenbasierten Berechtigungen und Audit‑Log
• Suche + Reporting: globale Suche (Lieferant, SKU, Vertrags‑ID) und ein „aktuelle genehmigte Preise“ Export

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.

Testplan (was in der Praxis schiefgeht)

Konzentrieren Sie Tests auf teure Fehlerbereiche:

• Import‑Validierungstests: fehlende Pflichtspalten, ungültige Währungen/Einheiten, Duplikate, Datumsüberschneidungen, negative Preise, gemischte Dezimaltrennzeichen
• Berechtigungstests: wer darf importieren, genehmigen, nach Genehmigung bearbeiten und sensible Anhänge sehen
• Workflowtests: Re‑Genehmigung nach Änderungen, verpflichtende Ablehnungsgründe, Audit‑Einträge für jeden Statuswechsel

Rollout und Deployment

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.

Nach dem Launch iterieren

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.