1. Repository klonen
Klone das öffentliche Repository und prüfe die Beispielkonfiguration, bevor du Dienste startest.
Das kleinste Setup besteht aus dem Next.js-Dienst und PostgreSQL in Docker Compose. Für den produktiven Betrieb kommen persistenter Speicher, TLS, Backups und getestete Wiederherstellungen dazu.
Klone das öffentliche Repository und prüfe die Beispielkonfiguration, bevor du Dienste startest.
Setze die öffentliche AUTH_URL, ein eigenes AUTH_SECRET sowie Datenbank und Speicher. Externe KI-Provider werden nur benötigt, wenn du die optionalen Funktionen aktivierst.
Nutze lokale Passwörter, Auth0 oder einen OpenID-Connect-Provider wie Supabase oder Keycloak. Rollen und Organisationszugriffe bleiben in Open Inventory.
Seite öffnenBaue und starte den Compose-Stack. Prüfe anschließend den Health-Endpunkt und lege das erste Konto an.
PostgreSQL-Daten und Uploads gehören auf dauerhafte Volumes oder in einen ausdrücklich konfigurierten Objektspeicher.
Beende TLS an einem Reverse Proxy und beschränke Datenbank und Speicher auf vertrauenswürdige Netze.
Ein Backup ist erst belastbar, wenn die Wiederherstellung mit der betriebenen Anwendungsversion getestet wurde.
Zielvarianten bauen, Einzelbestände und Familiensummen lesen und Fertigartikel über die API ausbuchen.
Seite öffnenAnwendung · Varianten & Fertigung
Jede Variante ist ein eigener Inventareintrag mit eigener Ressourcen-ID, SKU, Barcode und eigenem Bestand. Die Varianten sind mit einem Hauptartikel zu einer Produktfamilie verbunden. So bleiben etwa OpenPaper L Weiß und Schwarz auch nach der Fertigung getrennt buchbar.
Lege die Varianten am Hauptartikel an, verbinde vorhandene Einträge oder erzeuge sie aus Optionsgruppen. Varianten übernehmen die Stückliste des Hauptartikels; abweichende Komponenten legst du in der jeweiligen Variante fest, zum Beispiel einen weißen statt eines schwarzen Rahmens.
Wähle beim Bauen am Hauptartikel unter „Fertigartikel / Zielvariante“ die gewünschte Variante. Das Formular lädt deren Stückliste und Bestandsdaten. Ein Build von einem weißen Gerät verbraucht dessen Platine und weißen Rahmen und erhöht nur den Fertigbestand der weißen Variante. Komponentenverbrauch und Fertigungszugang werden gemeinsam gebucht oder vollständig zurückgerollt.
Öffne den Bestand der verkauften Variante und buche dort den Warenausgang. Nur diese Variante verliert Bestand; die Familiensumme sinkt entsprechend. Platine und Rahmen werden dabei nicht noch einmal abgebucht.
Am Hauptartikel siehst du die Varianten mit ihren Einzelbeständen. Die Bestandsansicht zeigt zusätzlich den unzugeordneten Bestand des Hauptartikels und die Summe der Familie. Beispiel nach einem Build der weißen Variante:
| Bestand | Menge |
|---|---|
| OpenPaper L Weiß | 1 |
| OpenPaper L Schwarz | 0 |
| Unzugeordnet am Hauptartikel | 2 |
| Gesamtbestand | 3 |
Gesamtbestand = Summe aller Variantenbestände + unzugeordneter Bestand
GET /api/v1/resources/{primaryId}/stock liefert family.variants mit quantity je Variante und family.summary mit totalQuantity, variantQuantity und primaryQuantity. resource.quantity bleibt der eigene, unzugeordnete Bestand des Hauptartikels. Zähle ihn nicht erneut zur Familiensumme hinzu. Alle Werte dieser Antwort stammen aus demselben Datenbank-Snapshot. Zum Lesen der Familie brauchst du stock.read-Zugriff auf alle Mitglieder.
Ersetze die Platzhalter durch deine Ressourcen-UUIDs und dein API-Token. Verwende für jeden neuen Vorgang einen eigenen Idempotency-Key; bei einer Wiederholung desselben Requests bleibt der Schlüssel gleich. Beim Build ist dieser Header erforderlich.
POST /api/v1/resources/{primaryId}/stock/builds
Authorization: Bearer <API_TOKEN>
Content-Type: application/json
Idempotency-Key: <unique-build-key>
{
"quantity": 1,
"outputResourceId": "<whiteVariantId>"
}outputResourceId muss die aufgerufene Ressource oder eine ihrer direkten Varianten sein. Alternativ kannst du direkt POST /api/v1/resources/{whiteVariantId}/stock/builds mit quantity aufrufen. Für bewusst unzugeordneten Fertigbestand gibst du die ID des Hauptartikels als outputResourceId an.
Bei einem Aufruf über den Hauptartikel kannst du outputResourceId weglassen, wenn componentResourceSelections die stabile Stücklisten-Slot-ID auf die gewählte Komponenten-ID abbildet und die gesamte resultierende Stückliste genau einer Endproduktvariante entspricht. Gewählte Komponenten müssen die jeweilige Stücklistenkomponente oder eine ihrer direkten Varianten sein. Gibt es keinen oder mehrere Treffer, antwortet die API mit HTTP 422; wähle dann die Zielvariante ausdrücklich.
POST /api/v1/resources/{whiteVariantId}/stock/movements
Authorization: Bearer <API_TOKEN>
Content-Type: application/json
Idempotency-Key: <unique-issue-key>
{
"delta": -1,
"type": "issue",
"note": "Order #1234"
}Die Varianten-ID steht im Ressourcenpfad. Der Request verwendet delta und type; ein zusätzliches variant_id-Feld oder ein separater Legacy-Varianten-Endpunkt wird nicht verwendet. Ein negativer delta-Wert reduziert den Bestand.
Ist „Negativbestand erlauben“ ausgeschaltet (allowNegativeStock = false), lehnt die API eine Ausbuchung unter null mit HTTP 409 ab. Ist die Einstellung eingeschaltet, darf Mengenbestand unter null sinken; auch die Familienübersicht zeigt diese negativen Werte. Serialisierte Einheiten benötigen weiterhin konkrete verfügbare Einheiten. Ein bereits negativer Bestand kann bei aktiviertem Schutz durch Zugänge wieder ausgeglichen werden.
Vollständige API-Referenz öffnenOpen Source als Grundlage
Repository, Migrationen, API-Beschreibung und iOS-App stehen gemeinsam unter der MIT-Lizenz.