Einkauf ist komplex und zeitaufwendig
Und Luminovo hilft Einkäufern bei EMS oder OEMs, schneller und zu besseren Konditionen einzukaufen. Da das ERP-System das führende System für den Einkauf ist, müssen die Bestellungen im ERP-System erstellt werden, bevor sie versendet werden.
Es gibt zwei verschiedene Einkaufsszenarien, die unsere Kunden mit Luminovo abdecken können.
Projektbasierter Einkauf. Jedes Projekt wird separat eingekauft.
Konsolidierter Einkauf. Mehrere Projekte werden gebündelt und in einem Zug eingekauft.
In diesem Dokument geht es darum, beide Szenarien zu automatisieren. Alles Folgende lässt sich bereits manuell in der Luminovo-Oberfläche erledigen – ein*e Einkäufer*in kann ein Projekt öffnen, die ausgewählten Angebote, Mengen und Preise ablesen und von Hand ins ERP eintippen. Der Punkt hier ist der automatisierte Weg: diese Daten direkt zwischen ERP und Luminovo über die API auszutauschen, sodass Einkäufer*innen das manuelle Abtippen überspringen, Übertragungsfehler vermeiden und stets mit aktuellen Preisen und Verfügbarkeiten arbeiten.
Die beschriebenen API-Endpunkte sind die Bausteine für diesen automatisierten Datenaustausch.
Beide Szenarien nutzen nur die öffentliche API (https://api.luminovo.com, Doku unter docs.luminovo.com).
Die zwei Szenarien auf einen Blick
Szenario 1 – Projektbasierter Einkauf | Szenario 2 – Konsolidierter (Sammel-)Einkauf | |
Auslöser | Das Angebot eines einzelnen Projekts wird angenommen | Das ERP hat den Bedarf über viele Projekte aggregiert |
Arbeitseinheit | Ein Projekt / Sourcing-Szenario | Eine flache Liste von IPNs |
Wer das Angebot auswählt | Luminovo (die Sourcing-Auswahl im Projekt) | Das ERP, aus allen von Luminovo zurückgegebenen Angeboten |
Richtung | Die ausgewählten Beschaffungsoptionen aus dem Projekt ziehen | Aktualisieren, dann alle Angebote je IPN ziehen; das ERP entscheidet |
Kern-Endpunkte |
|
|
Ergebnis im ERP | Bestellung je ausgewähltem Angebot erstellt | Beste Preise in die Einkaufsmaske vorbefüllt; der*die Einkäufer*in entscheidet |
Beide Szenarien enden gleich: Die Bestellung wird im ERP erstellt und ausgeführt. Luminovo liefert nur die bepreisten Sourcing-Daten.
Die Automatisierungen auf Luminovo-Seite sind rein lesend. Nichts wird von Luminovo bestellt oder per E-Mail versendet. Die endgültige Einkaufsentscheidung wird immer im ERP-System getroffen.
Wie der Datenaustausch funktioniert
Wichtig zu betonen – der Austausch zwischen dem ERP-System und Luminovo läuft über die API von Luminovo. Es muss immer eine Instanz geben, die diesen Austausch initiiert (= Aufrufe an die API von Luminovo macht). Dieses System ist entweder Ihr ERP oder eine Middleware, die Sie möglicherweise betreiben. Luminovo überträgt niemals selbst aktiv Daten in Ihr ERP-System, es stellt die Daten nur bereit, jederzeit zum Laden bereit.
Szenario 1 – Projektbasierter Einkauf
Ablauf
Der Kunde fragt ein Angebot an. Das EMS erhält eine Anfrage von seinem Kunden.
Importieren Sie die BOM in ein Projekt (RfQ) in Luminovo – wird manuell von Nutzer*innen erledigt.
Bearbeiten Sie die BOM und erstellen Sie das Angebot an den Kunden. Das Sourcing läuft gegen die Lieferanten-APIs; Luminovo wählt je Position ein Angebot innerhalb des Sourcing-Szenarios des Projekts aus.
Das Angebot wird angenommen → der*die Nutzer*in löst den Abruf aus. Das ERP holt die Beschaffungsoptionen des Projekts – die einzukaufenden Mengen und das ausgewählte Angebot – und erstellt die Bestellung(en) im ERP.
Optional kann die Integration vor Schritt 4 die Lieferantenangebote aktualisieren (POST /offers/refresh, in Entwicklung) und dann die Sourcing-Auswahl erneut ausführen (POST /sourcing-scenarios/run-selection), sodass Preise/Verfügbarkeit zum Bestellzeitpunkt aktuell sind – das adressiert die Frage „Wie alt ist dieses Angebot?" (Angebote können zum Beispiel so konfiguriert werden, dass sie nach 7 Tagen als veraltet und nach 28 als abgelaufen gelten).
Endpunkte
1. GET /sourcing-scenarios/{id}/purchase-options – „ausgelegt dafür, dass ERP-Systeme Bestellungen erstellen."
Pfadparameter id = die UUID des Sourcing-Szenarios (aus dem Projekt zu beziehen über GET /rfqs/{id} oder GET /sourcing-scenarios).
Gibt purchase_options[] zurück, ein Eintrag je ausgewähltem Angebot:
Feld | Bedeutung – warum das ERP es braucht |
| Handle auf das ausgewählte Angebot. Auflösen mit |
| Anzahl der zu bestellenden Angebotseinheiten (die einzukaufende Menge). |
| Was eine Angebotseinheit ist (z. B. 1 Stück oder 5 m Kabel). |
| Komfort-Gesamtmenge in Basiseinheiten = |
| Aus der ausgewählten Preisstaffel – die Bestellung muss ≥ diesem Wert sein. |
| Die Bestellung muss ein Vielfaches davon sein. |
| Preis pro Angebotseinheit in der Originalwährung des Angebots – keine Umrechnung. |
Löst einen häufigen Währungsschmerzpunkt.
ERPs benötigen typischerweise die ursprüngliche Bestellwährung (z. B. USD für einen US-Distributor), nicht einen bereits in die Tenant-Währung (z. B. EUR) umgerechneten Wert. purchase-options gibt unit_price in der Originalwährung mit einem ISO-4217-Code zurück.
2. GET /offers/{id} (oder POST /offers/bulk für mehrere auf einmal) – löst jede offer_id in den vollständigen Datensatz auf, den das ERP auf der Bestellposition braucht:
Feld | Verwendung in der Bestellung |
| Herstellerteilenummer + Hersteller für die Bestellposition. |
| Der Lieferant und seine ERP-Vendor-Nummer – oft verwendet, um freizugeben, welche Lieferanten für die Bestellerstellung gültig sind. |
| Niederlassung / Region des Lieferanten (z. B. Europa, Asien). |
| Die eigene Teilenummer des Lieferanten zum Bestellen. |
| Angebotsreferenz des Lieferanten, zur Abstimmung. |
| ListPrice / ContractPrice / QuotePrice / kundenverhandelt. |
| Vollständige Preisstaffel-Leiter in Originalwährung. |
| Lieferzeit + Bestand für die Liefertermin-Planung. |
| Reel / Tape / Tray / Tube / Bulk … |
| Gültigkeitsfenster des Angebots – prüfen Sie vor dem Bestellen, ob der Preis noch aktuell ist. |
| NCNR / Stornofenster. |
| Werkzeug-/NRE-/Einrichtungskosten (meist Custom Parts). |
| Einheitenbasis; Custom Parts tragen die staffelweise |
Szenario 2 – Konsolidierter (Sammel-)Projekteinkauf
Ablauf
Der Bedarf wird auf der ERP-Seite aggregiert, sodass das ERP die maßgebliche Liste der einzukaufenden IPNs hält (über viele Projekte hinweg).
Das ERP löst eine Aktualisierung der Angebote für diese IPNs in Luminovo aus, sodass Lieferantenpreise/-verfügbarkeit neu abgerufen und aktuell sind.
Nach einer Verzögerung (die Aktualisierung braucht Zeit, um alle Angebote zu aktualisieren) holt das ERP alle Angebote für die angegebenen IPNs von Luminovo.
Das ERP entscheidet, welche Angebote zu bevorzugen sind, anhand benutzerdefinierter Kriterien – z. B. bester Einkaufspreis oder kürzeste Lieferzeit.
Preise werden in die Einkaufsmaske eingefügt, sodass der*die Einkäufer*in bereits die besten Preise sieht und entscheiden kann, wo eingekauft wird.
Endpunkte
1. GET /components/ipn/{ipn} – die Zuordnung IPN → Part.
Pfadparameter ipn. Gibt components[] zurück (einen je Revision), jeweils mit:
Feld | Verwendung |
| Die IPN + Revision. |
|
|
| Die Off-the-shelf-Part-ID (die „mpn_id", die den zu bepreisenden Part identifiziert) plus ihre MPN/Hersteller. Das ist die ID, die Sie in die Angebots-Endpunkte einspeisen. |
| Compliance/Lebenszyklus, falls Sie das Bestellen davon abhängig machen möchten. Diese Daten sind immer ein Aggregat aus allen verbundenen MPNs. Mehr zu den Aggregationsregeln in der API-Dokumentation. |
2. POST /offers/refresh – ruft Lieferanten-API-Angebote für die angegebenen Part(s) / mpn_id neu ab, sodass Preise und Verfügbarkeit aktuell sind.
Bauen Sie nach diesem Aufruf eine Verzögerung ein, bevor Sie abrufen – die Aktualisierung muss die Lieferanten-APIs ansprechen und alle Angebote aktualisieren; zu frühes Lesen liefert veraltete Daten. Luminovo hat noch keine Funktion, um den Status der Angebotsaktualisierung zu prüfen.
3. POST /offers/find (Doku-Titel „Get Offers By Part" – Hinweis: es ist POST, nicht GET) – der Sammel-Lesezugriff.
Request-Body = eine Menge von Part-IDs (Off-the-shelf, Custom oder IPN) – POST, damit Sie viele auf einmal übergeben können. Gibt zurück:
items[]– die Angebote (dieselbe reichhaltigeOfferResponse-Struktur wieGET /offers/{id}oben):price_breaks[](MOQ / MPQ /unit_pricein Originalwährung),availability(factory_lead_time,stock),linked_location(Lieferant + ERP-Vendor-number),supplier_part_number,price_type,valid_from/valid_until, Verpackung usw. Das ist die Liste der Angebote mit den Preisen, MOQs und Lieferzeiten, nach denen das ERP rankt.not_found_ids[]– Part-IDs, die nicht aufgelöst werden konnten (behandeln/protokollieren Sie diese).
Das Ranking in Schritt 4 (z. B. bester Preis vs. kürzeste Lieferzeit) erfolgt durch das ERP über items[] – Luminovo gibt jedes Angebot zurück; die eigenen Kriterien des Kunden bestimmen den Gewinner. Das Prinzip: Luminovo liefert die Daten; die Entscheidung und die Bestellung bleiben im ERP.
Was ein ERP braucht, um eine Bestellung zu erstellen – und woher es kommt
Konsolidierte Feldzuordnung (für eine kontierte Bestellung / „account-assigned PO"):
Bestellfeld (ERP) | Quelle in der Luminovo API | Hinweise |
Lieferant / Vendor-Nummer |
| |
Hersteller + MPN |
| |
IPN (interne Teilenummer) |
| Die eigene Materialnummer des ERP wird über die IPN zugeordnet. |
Lieferantenteilenummer (SPN) |
| |
Bestellmenge |
| |
Maßeinheit |
| |
Stückpreis + Währung |
| Originalwährung, keine Umrechnung. |
MOQ / MPQ |
| Die Bestellung muss ≥ MOQ und ein Vielfaches von MPQ sein. |
Lieferzeit |
| Für die Liefertermin-Planung. |
Angebotsgültigkeit |
| Vor dem Bestellen die Preisaktualität prüfen. |
Kontierung / Kostenstelle / Projekt | ERP-Seite | Nicht in Luminovo – vom ERP für die kontierte Bestellung bereitgestellt. |
Liefer-/Bedarfstermin | ERP-Seite (aus aggregiertem Bedarf) |
Einschränkungen, die klar benannt sein sollten
Die Bestellung wird aus dem ERP aufgegeben, niemals aus Luminovo. Auch Wareneingang und Rechnungseingang bleiben im ERP.
Keine Lieferanten-E-Mails aus Luminovo. Diese Lese-Endpunkte senden nichts – die endgültige Einkaufsentscheidung und die Bestellung bleiben im ERP.
Aktualität zählt. Führen Sie vor dem Bestellen die Auswahl erneut aus (Sz. 1) oder aktualisieren Sie die Angebote (Sz. 2); beachten Sie die Gültigkeitsdaten der Angebote.
Endpunkt-Kurzreferenz
# | Endpunkt | Methode | Szenario | Rolle |
1 |
| GET | 1 | Ausgewählte Angebote + einzukaufende Mengen für ein Projekt |
2 |
| GET / POST | 1 (+2) | Vollständige Angebotsdetails hinter einer |
3 |
| GET | 2 | IPN → Off-the-shelf-Part-ID (mpn_id) + MPN |
4 |
| POST | 2 | Lieferantenangebote neu abrufen (in Entwicklung; danach Verzögerung einplanen) |
5 |
| POST | 2 | Alle Angebote für eine Menge von Part-IDs → |
— |
| POST | 1 (opt.) | Die Sourcing-Auswahl des Projekts vor dem Bestellen aktualisieren |
Alle Aufrufe: Basis-URL https://api.luminovo.com, Bearer- (JWT-)Authentifizierung und ein datenmodellspezifischer Accept-Header je Endpunkt. Behandeln Sie stets einen "Unknown"-Fall für jedes Enum (Vorwärtskompatibilitätsregel, wie in der API-Präambel angegeben).