Lagerverwaltung ohne Code bauen: die eigene Inventar-App
Lagerverwaltung ohne Code bauen
Eine eigene Inventar-App entsteht bei Zugo als mehrseitige Anwendung aus einer Beschreibung: Artikelstamm, Buchungen, Lagerorte und eine Übersicht mit Meldebeständen. Die Daten liegen in Supabase, das über eine Änderung angebunden wird. Der Aufbau kostet 12 Credits für die ersten drei Seiten und 3 je weiterer Seite.
Der Text geht der Reihe nach durch: wann sich der Eigenbau lohnt, welche Bildschirme nötig sind, wie Artikel erfasst werden, wie der Prompt aussieht, was es kostet und wo eine selbst gebaute Lösung schlechter ist als eine gekaufte.
Wann lohnt sich eine eigene Inventar-App statt einer Tabelle?
Sobald mehr als eine Person bucht. Eine Tabelle funktioniert erstaunlich lange, sie scheitert aber immer an derselben Stelle: zwei Leute öffnen sie gleichzeitig, eine Version überschreibt die andere, und niemand kann später sagen, welcher Stand stimmte.
| Tabelle | Eigene App | Warenwirtschaft | |
|---|---|---|---|
| Start | sofort | ein Aufbau plus einige Änderungen | Einführungsprojekt |
| Mehrere Personen gleichzeitig | unzuverlässig | sauber getrennt | sauber getrennt |
| Anpassung an eigene Abläufe | frei, aber fehleranfällig | frei, selbst zu formulieren | begrenzt auf vorgesehene Felder |
| Anbindung an Kasse, Shop, Buchhaltung | keine | müsste gebaut werden | meist vorhanden |
| Historie der Bewegungen | selten gepflegt | von Anfang an | von Anfang an |
| Laufende Kosten | keine | Tarif des Builders plus Datenbank | pro Arbeitsplatz und Monat |
Der Eigenbau lohnt sich in drei Fällen. Erstens, wenn Ihr Bestand anders gezählt wird als in Standardsoftware vorgesehen, etwa in Metern, Gebinden oder halben Paletten. Zweitens, wenn Sie nur einen kleinen Ausschnitt brauchen und der Rest einer Warenwirtschaft ungenutzt mitbezahlt würde. Drittens, wenn Ihr Lager an einem Ort ohne stabile Anbindung an vorhandene Systeme steht, etwa eine Werkstatt oder ein Außenlager.
Welche Bildschirme braucht eine Lagerverwaltung wirklich?
Vier. Alles Weitere entsteht später aus echten Problemen und nicht aus einer Wunschliste.
| Bildschirm | Aufgabe | Wichtigste Felder |
|---|---|---|
| Artikel | Was gibt es überhaupt | Nummer, Bezeichnung, Einheit, Lagerort, Meldebestand, Lieferant |
| Buchung | Was hat sich bewegt | Artikel, Menge, Richtung, Grund, Person, Zeitpunkt |
| Lagerorte | Wo liegt es | Bereich, Regal, Fach, Bemerkung |
| Übersicht | Was ist heute wichtig | unter Meldebestand, Zugänge der Woche, Artikel ohne Bewegung |
Die zweite Zeile enthält die wichtigste Entwurfsentscheidung des ganzen Projekts: Der Bestand wird nie direkt bearbeitet, sondern ergibt sich aus Buchungen. Wer die Bestandszahl von Hand überschreibbar macht, hat nach vier Wochen Zahlen, die niemand erklären kann. Eine Korrektur ist dann eben auch eine Buchung, mit Grund und Namen.
Der Meldebestand ist die zweite Stelle, an der sich Aufwand auszahlt. Ohne ihn ist die App ein Nachschlagewerk, mit ihm ein Werkzeug, das morgens sagt, was bestellt werden muss.
Funktioniert das Scannen mit dem Telefon?
Teilweise, und die Einschränkung sollte man vorher kennen. Die Kamera eines Telefons kann Barcodes im Browser lesen, das funktioniert bei QR-Codes gut und bei schmalen Strichcodes auf glänzender Folie oder bei schlechtem Licht deutlich schlechter. Für gelegentliche Erfassung reicht es, für hundert Positionen am Stück ist es zäh.
Der praktikable Weg im Alltag ist ein Bluetooth-Handscanner. Solche Geräte melden sich am Telefon oder Tablet als Tastatur an und schreiben den gelesenen Code in das gerade aktive Feld. Ihre App muss dafür nichts Besonderes können, sie braucht nur ein Suchfeld, das nach dem Scan sofort den passenden Artikel zeigt und den Fokus behält.
Wenn Sie mit eigenen Etiketten arbeiten, verwenden Sie QR-Codes statt Strichcodes. Sie sind unempfindlicher gegen Knicke und werden auch aus schrägem Winkel gelesen.
Wie sieht der Prompt für eine Inventar-App aus?
Beschreiben Sie Ihr Lager, nicht die Software. Der Builder kann aus einem beschriebenen Ablauf Felder ableiten, aber nicht raten, wie in Ihrem Betrieb gezählt wird.
Erstelle eine mehrseitige Anwendung: eine Lagerverwaltung für einen
Elektrobetrieb mit einem Hauptlager und drei Servicefahrzeugen.
Seiten: Übersicht, Artikel, Buchungen, Lagerorte, Einstellungen.
Artikel: Artikelnummer, Bezeichnung, Einheit (Stück, Meter, Rolle), Lagerort,
Meldebestand, Lieferant, Einkaufspreis, Notiz.
Buchungen: Artikel, Menge, Richtung (Zugang, Abgang, Umbuchung, Korrektur),
Grund, Person, Zeitpunkt automatisch. Bestand wird nur aus Buchungen berechnet
und ist nirgends direkt editierbar.
Lagerorte: Hauptlager mit Regal und Fach, dazu drei Fahrzeuge als eigene Orte.
Übersicht: Artikel unter Meldebestand, Zugänge der letzten sieben Tage,
Artikel ohne Bewegung seit 180 Tagen.
Suchfeld auf jeder Seite, das auf Artikelnummer und Bezeichnung sucht und
nach einem Scan sofort den Treffer zeigt.
Anmeldung mit E-Mail und Passwort. Bedienung auf dem Telefon muss mit einer
Hand funktionieren, große Schaltflächen.
Zwei Sätze darin sind wichtiger, als sie aussehen. Der Satz über die nicht editierbare Bestandszahl legt das Datenmodell fest. Und die Bemerkung zur Einhandbedienung sorgt dafür, dass die Buchungsmaske im Lager benutzbar ist und nicht nur am Schreibtisch aussieht.
Wozu wird eine Datenbank gebraucht?
Eine Oberfläche ohne Datenbank ist eine Attrappe: Beim Neuladen ist alles weg. Supabase liefert die drei Bausteine, die eine Lagerverwaltung braucht. Die Datenbank hält Artikel und Buchungen dauerhaft, die Anmeldung sorgt dafür, dass nur Ihr Team bucht, und der Dateispeicher nimmt Lieferscheine und Fotos auf.
Angebunden wird Supabase über eine Änderung am Projekt. Praktisch heißt das: erst das Gerüst bauen, prüfen, ob die Bildschirme passen, und dann die Datenbank anhängen. Umgekehrt zahlen Sie jede Strukturänderung doppelt. Der Ablauf steht ausführlich in KI-App-Builder mit Supabase, und die grundsätzliche Frage beantwortet Kann KI eine App mit Datenbank bauen.
Was kostet die eigene Inventar-App in Credits?
Abgerechnet wird pro Aktion, was die Kalkulation vor dem Start überschaubar macht.
| Aktion | Credits | Im Hi-Fi-Modus |
|---|---|---|
| Änderung an einem Projekt | 3 | 6 |
| Frischer Build | 6 | 12 |
| Mehrseitige Plattform | 12 für die ersten drei Seiten, dann 3 je weiterer Seite | doppelt |
Fünf Bildschirme kosten 12 für die ersten drei und 6 für die restlichen zwei, zusammen 18 für den Aufbau. Für die Datenbank, die Buchungslogik und den Feinschliff an der Suche kommen etwa acht bis zehn Änderungen dazu, also ungefähr fünfzig verbrauchte Credits bis zur benutzbaren Fassung.
Die Tarife: Free gibt 5 Credits, Pro kostet 25 $ im Monat mit 200 Credits, Business 99 $ im Monat mit 800 Credits. Zweihundert Credits entsprechen etwa 16 mehrseitigen Plattformen, 33 Builds oder 66 Änderungen.
Was ist mit Aufbewahrung und Nachvollziehbarkeit?
Sobald Ihre Bestandsführung steuerlich relevant ist, gelten die Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, kurz GoBD. Für den Bau bedeuten sie vor allem drei Dinge.
Nachvollziehbarkeit: Jede Bewegung braucht Zeitpunkt, Person und Grund. Genau deshalb ist die Buchungstabelle das Herz der App und nicht ein Nebenbildschirm.
Unveränderbarkeit: Eine falsche Buchung wird nicht gelöscht, sondern durch eine Gegenbuchung ausgeglichen. Das ist ein Satz im Prompt und erspart später unangenehme Fragen.
Dokumentation: Wie Ihr System arbeitet, sollte in wenigen Seiten beschrieben sein. Ob Ihre selbst gebaute Lösung die Anforderungen in Ihrem Fall erfüllt, klärt Ihre Steuerberatung und kein Builder.
Wo stößt eine selbst gebaute Lagerverwaltung an Grenzen?
Vier Punkte, die man vorher wissen sollte statt im dritten Monat zu entdecken.
Es gibt keinen Offline-Betrieb. Ohne Netz im Keller oder in der Halle wird nicht gebucht. Wer dort arbeitet, braucht entweder WLAN oder eine Zettelroutine für den Ausnahmefall.
Es gibt keine fertige Anbindung an Kasse, Onlineshop oder Buchhaltung. Solche Verbindungen sind Sonderarbeit über mehrere Änderungen, und bei vielen Schnittstellen ist eine gekaufte Warenwirtschaft am Ende günstiger.
Sehr spezifische Fachlogik braucht Geduld: Chargenverfolgung mit Mindesthaltbarkeit, Seriennummern über den gesamten Lebenszyklus oder mehrstufige Stücklisten entstehen schrittweise und nicht aus einem Prompt.
Vor der Übergabe prüft eine Sandbox, ob das Projekt startet: was nicht öffnet, wird nicht ausgeliefert. Ob Ihre Buchungslogik betriebswirtschaftlich richtig ist, prüft sie nicht. Bei einem komplexen Produkt ersetzt ein Builder kein Entwicklungsteam.
Wie läuft die erste Inventur mit der eigenen App?
Zählen Sie nicht das ganze Lager an einem Samstag. Nehmen Sie eine Warengruppe, zählen Sie sie, und tragen Sie die Differenzen als Korrekturbuchungen mit Grund ein. Danach wissen Sie, wie genau Ihre Stammdaten sind, und das ist die eigentliche Information.
Führen Sie eine einfache Zählliste in der App: Artikel, Sollbestand ausgeblendet, Feld für die gezählte Menge. Wer den Sollwert sieht, zählt ihn unbewusst nach.
Und legen Sie danach eine feste Runde fest, etwa eine Warengruppe pro Monat. Diese permanente Zählweise ist im Alltag deutlich weniger schmerzhaft als der Stichtag im Dezember, und die Zahlen sind das ganze Jahr über brauchbar. Wenn aus dem Bestand später Rechnungen entstehen sollen, hilft Rechnungs-App ohne Code erstellen beim nächsten Schritt.
Die einfache Sammlung entsteht in etwa einer Minute, die mehrseitige Anwendung braucht ein paar Minuten. Wer anfangen möchte, findet den Einstieg auf zugo.dev, und nach dem ersten Durchlauf sehen Sie, ob Ihre Beschreibung des Lagers so eindeutig war, wie Sie dachten.