Mikro Farm verkauft Tierfutter, Tierarzneimittel, Saatgut, Pestizide und Dünger — kiloweise, sackweise, containerweise. Der Inhaber hatte jeden Standard-POS ausprobiert: Keiner trennte Lager vom Ladenregal, keiner passte Preise an, wenn Lieferanten nachjustierten, und keiner zeigte dem Kunden, was auf dem Regal lag, bevor er eine Stunde fuhr. Also haben wir einen gebaut, der das kann.
Bevor wir eine einzige Zeile schrieben, hat uns der Inhaber denselben Samstag fünf Mal erklärt. Das sind die Stellen, die immer wieder aufgetaucht sind.
Der Laden liegt weit von den meisten Landwirten entfernt. Wenn das Gesuchte nicht vorrätig ist, war die Fahrt umsonst — und das Vertrauen gleich mit.
Laufkundschaft kommt ohne Plan in einen überfüllten Laden — steht vor dem Regal und liest Etiketten, während zehn andere warten. Das Ergebnis: Personalzeit geht für Beratung drauf.
Lager und Ladenregal sind räumlich getrennt, aber jeder Standard-POS wirft beides zusammen. Das System zeigt 40 Säcke, das Regal hat 3 und hinten stehen 37 — niemand merkt es, bis ein Kunde fragt.
Jeden Freitag zählt jemand. Manuell. Mit dem Auge. Fehler zeigen sich zwei Wochen später, wenn eine Bestellung mit weniger ankommt, als tatsächlich gebraucht wurde.
Hier geht es nicht um sackweise Mengen. Eine einzelne Lieferantenbestellung ist ein Container Futter. Zu wenig — ein Monat ohne Ware. Zu viel — Kapital gebunden, Verfallsdaten bei Medikamenten und Saatgut rücken heran.
Was wir als Erstes gebaut haben, ist nicht für das Personal. Es ist ein öffentlicher, wissensorientierter Katalog, den der Kunde öffnet, bevor er ins Auto steigt. Jedes Produkt zeigt den Live-Bestand je Standort, Dosierungshinweise für Medikamente und Saatgut sowie einen „Reservieren / Bestellen"-Button, damit der Sack bereits bereitgelegt ist, wenn der Kunde eintrifft.
Das Regalrätsel löst sich von selbst: Wer zuhause bereits gewählt hat, muss in der Warteschlange keine Etiketten mehr lesen. Das Fahrtenproblem löst sich von selbst: Ist es rot, fährt man nicht.
Jeder Artikel hat einen zentralen Datensatz, aber zwei Bestandszeilen — eine für das Lager, eine für das Ladenregal. HPP wird ebenfalls je Standort erfasst, sodass ein Transfer die Kosten unverändert mitführt und Margenberichte korrekt bleiben.
Verkäufe ziehen zuerst vom Toko ab. Reicht der Toko nicht, wechselt das System ohne Bestätigung auf den Gudang — protokolliert den Zugriff aber, damit die Nachbestellberechnung weiß: das Regal muss aufgefüllt werden, nicht nur das Lager.
Mindestbestandswarnungen laufen je Standort, nicht aggregiert. Der „Was kaufen"-Tab ist dieselbe Logik, die früher freitags per Hand erledigt wurde — nur dass er sich nie verzählt und Artikel nach Dringlichkeit sortiert, nicht alphabetisch.
Verfallsdatumkategorien (Medikamente, Saatgut, Pestizide) erhalten einen zweiten Durchlauf: Alles, was in weniger als 60 Tagen abläuft, erscheint im selben Tab und kann noch verkauft oder umgelagert werden, bevor es wertlos wird.
| Artikel | Ort | Vorrat | Min | Aktion |
|---|---|---|---|---|
| Pakan Ayam Petelur 50kg | Toko | 3 | 10 | Pindah |
| Pupuk Urea 50kg | Gudang | 82 | 120 | Nachbestellen |
| Vit. B-Complex 1L (exp 09/26) | Toko | 2 | 4 | Zuerst verkaufen |
| Decis 100ml | Gudang | 26 | 50 | Nachbestellen |
Für einen Einzelhandel im Sackbereich reicht „mehr bestellen, wenn knapp." Für Mikro Farm lautet die Frage: Wie viele Säcke füllen einen 20-Fuß-Container, ohne sechs Monate Bedarf zu überschreiten. Nachbestellen ist also keine Schaltfläche — sondern ein Kalkulator, den der Inhaber übersteuern kann.
Das System rollt die letzten 12 Wochen Umsatz auf, multipliziert mit der Lieferantenlaufzeit und rundet das Ergebnis auf die MOQ und die nächste Containerfülllinie. Der Inhaber sieht die Rechnung, nicht nur das Ergebnis, und kann nachjustieren, bevor er abschickt.
Jeder Wareneingang berechnet den gewichteten HPP je Standort neu. Überschreitet der neue HPP den Aufschlagsbereich, den der Inhaber festgelegt hat, wird der Verkaufspreis automatisch aktualisiert und protokolliert — sowohl im POS als auch im kundenseitigen Katalog.
Der Inhaber sieht einen einzigen Feed aller Bewegungen: was sich geändert hat, warum und um wie viel. Kein „Moment, warum ist die Marge diesen Monat gesunken" mehr.
Wir haben nicht bei null angefangen. Das POS-Grundgerüst stammt aus unserem eigenen Floural-Template — Verkäufe, Ausgaben, Anwesenheit, Zahlungen. Die Maßarbeit lag im Lager: aufteilen, kalkulieren, sichtbar machen.
Inventarmodell auf Papier, bevor eine einzige Codezeile geschrieben wurde. Jede Kategorie, jede Einheit (kg / sak / Liter / Stk.), jede Lieferanten-MOQ, jede verfallsdatumspflichtige SKU erfasst.
inventory_items + inventory_stock-Verbindung gebaut (ein Master, Menge & HPP je Standort). Gewichteten Durchschnittskosten bei jedem Wareneingang verdrahtet. Transfer-Flow („Pindah ke Toko") in derselben Woche ausgeliefert.
Verkäufe treffen jetzt zuerst den Toko, fallen durch zum Gudang, fotografieren den HPP auf die Bestellzeile. Mindestbestandswarnungen und „Was kaufen"-Tab aus Live-Joins gespeist.
Kundenseitige PWA liest dieselbe Bestandstabelle, in die das POS schreibt. Nachbestellrechner mit Containerfüllrundung. Preisticker aus Wareneingängen gespeist.
Eine volle Woche lang wurde jede Zählung sowohl im System als auch mit dem Klemmbrett durchgeführt. Am Ende abgeglichen. Abweichungen → Fehler → behoben → Übergabe.
Keine erfundenen Monatszahlen — das System ist frisch. Das sind die Abläufe, die von Papier und aus dem Kopf des Inhabers in das System gewandert sind.
Gudang und Toko haben jeweils eigene Menge und HPP. Verkäufe fallen sauber durch. Transfers tragen die Kosten.
Jeder Wareneingang berechnet HPP neu und passt den Verkaufspreis an den Aufschlagsbereich des Inhabers an. Der Katalog übernimmt es sofort.
Ein Tab, nach Dringlichkeit sortiert, inklusive bald ablaufender Artikel. Ersetzt die Freitagsrunde mit dem Klemmbrett.
Der öffentliche Katalog liest dieselbe Tabelle, in die das POS schreibt. Kein Staging, keine Cache-Verzögerung.
Nachbestellvorschläge runden auf MOQ und Containerfüllung. Inhaber sieht die Rechnung, kann nachjustieren, dann abschicken.
Ersetzt jeden Play-Store-POS-Versuch, der nicht gepasst hat. Vollständig im Eigenbesitz. Läuft auf einem kleinen VPS.
Läuft auf dem Android-Tablet des Personals an der Kasse. Offline-first über einen Queue-Sync-Store — die Kasse nimmt weiter Verkäufe an, wenn das WLAN abbricht, und spielt sie wieder ein, wenn es zurückkommt. OTA-Updates, damit wir reine JS-Fixes ausliefern, ohne Neuinstallation.
Eine Datei pro Domain, ?action=-Routing, reines PDO. JWT-Authentifizierung. Audit-Log bei jeder Mutation, damit sich jede Bestandsänderung auf eine Person und einen Zeitpunkt zurückverfolgen lässt.
Öffentliche Browser-App. Liest dieselbe inventory_stock-Tabelle, in die das POS schreibt — kein separater Sync. Wissensorientiert: Jedes Produkt trägt eine „Warum dieses"-Notiz für Cross-Selling-Kontext.
Eine inventory_items-Zeile pro SKU. Zwei inventory_stock-Zeilen (Gudang, Toko) nach (item_id, location) gegliedert. Jeder Wareneingang löst gewichteten Durchschnitts-HPP und optional eine Verkaufspreisanpassung aus.
Kostenloses Erstgespräch. Wir sagen Ihnen, was wirklich passt — und was es kostet.