Der Meldebestand steht längst im System. Was fehlt, ist der Moment, in dem jemand danach handelt – und genau den übernimmt AutoFlow.
Der Meldebestand ist gepflegt, der Bestellvorschlag ist eingerichtet, und trotzdem steht regelmäßig jemand vor einem leeren Fach. Nicht weil die Zahlen falsch sind, sondern weil zwischen „Bestand unterschritten“ und „Bestellung geschrieben“ ein Mensch sitzt, der die Liste öffnen muss.
An guten Tagen passiert das morgens. In der Woche vor dem Urlaub, im Krankheitsfall oder wenn drei dringendere Dinge dazwischenkommen, passiert es Tage später – und niemandem fällt auf, dass es nicht passiert ist.
Ein Artikel, der nicht lieferbar ist, wird selten später gekauft. Er wird woanders gekauft. Bei Verbrauchsmaterial und Handelsware entscheidet die Verfügbarkeit den Auftrag, nicht der Preis – und der Kunde, der einmal ausweichen musste, prüft beim nächsten Mal zuerst dort.
Was zu spät bemerkt wird, wird zur Eilbestellung: kleinere Menge, schlechterer Preis, Expressversand, dazu ein Anruf beim Lieferanten und einer beim Kunden. Der Aufschlag steht in keiner Auswertung, weil er sich über Versandkosten, Rabattstufen und Arbeitszeit verteilt.
Der andere Fehler geht in die Gegenrichtung. Zwei Leute sehen dieselbe Unterdeckung, keiner sieht die Bestellung des anderen, und der Artikel kommt zweimal. Das Geld liegt dann im Lager statt auf dem Konto – und bei Artikeln mit Haltbarkeit liegt es dort, bis es abgeschrieben wird.
Bei zweihundert Artikeln funktioniert die Liste. Bei zweitausend funktioniert sie nur noch, wenn jemand sie zur Hauptaufgabe macht. Wachstum bedeutet dann nicht mehr Umsatz bei gleichem Aufwand, sondern eine weitere halbe Stelle – und die Abhängigkeit davon, dass genau diese Person da ist.
Frag jemanden aus dem Einkauf, wie Nachbestellen geht, und Du bekommst vier Sätze: Bestand zu niedrig, schauen ob schon was unterwegs ist, Bestellung beim üblichen Lieferanten schreiben, Bescheid sagen. Genau diese vier Sätze klickst Du in AutoFlow zusammen. Keine Programmierung, keine Erweiterung, kein Entwicklungsauftrag.
Der erste lauffähige Stand entsteht an einem Nachmittag, in der Sandbox, gegen Deine echten Artikel. Du siehst, was er vorschlagen würde, bevor irgendetwas produktiv passiert.
Sinkt der Bestand unter den Meldebestand, läuft der Ablauf los – ohne dass jemand eine Liste öffnet.
Läuft für den Artikel schon eine Bestellung, passiert nichts. Das ist die Prüfung, die von Hand am ehesten ausfällt.
Beim hinterlegten Lieferanten, mit der hinterlegten Menge – fertig zur Freigabe, nicht bereits verschickt.
Eine Nachricht pro Lauf mit allem, was ausgelöst wurde. Kein Postfach voller Einzelmeldungen.
Der Ablauf ist an einem Nachmittag gebaut und getestet. Danach kostet er nichts mehr – keine Wartung, keine Erinnerung, keine Übergabe an den Urlaubsvertreter. Er ist genau dann fleißig, wenn gerade niemand hinschaut.
Der Flow bereitet vor, der Einkauf entscheidet. Wer mehr automatisieren will, hängt den Buchungsschritt an.
Gebaut wird im grafischen Editor. Wer den Ablauf fachlich erklären kann, kann ihn auch bauen.
Kein AL-Code, keine Objekterweiterung. Das nächste BC-Update geht daran vorbei.
Zweitausend Artikel kosten den Flow genauso viel Zeit wie zweihundert.
Nicht an einer Zahl im Dashboard, sondern daran, dass zwei Gespräche aufhören: das über den Artikel, der schon wieder alle ist, und das über die Bestellung, die zweimal rausging. Wenn Dir beides in einem Quartal je einmal erspart bleibt, hat der Nachmittag sich getragen.
Auslöser, zwei Abfragen, die Bestellung, die Mail an den Einkauf. Mehr Schritte hat der Ablauf nicht, und keiner davon ist Code.
Der Ablauf selbst: ja. Was länger dauern kann, sind die Stammdaten – wenn Meldebestand, Bestellmenge oder Lieferant nicht überall gepflegt sind, findet der Flow das sofort und Du hast erstmal eine Liste zu klären. Das ist unangenehm, aber es ist Arbeit, die Du ohnehin vor Dir herschiebst.
Nein. Gebaut wird grafisch, mit fertigen Bausteinen – kein AL, keine Extension, kein Deployment. Wer in Business Central zu Hause ist und den Ablauf fachlich beschreiben kann, baut ihn. Für den ersten Flow sitzen wir auf Wunsch dabei.
Nichts. Die Logik liegt nicht als Objekterweiterung im BC-Kern, sondern als Konfiguration daneben – es gibt nichts, was beim Update neu kompiliert werden müsste. Genau das ist der Unterschied zu einer PTE, die bei jedem Release wieder Deine Aufmerksamkeit braucht.
Für geplante Artikel eher nicht – da hast Du schon einen Taktgeber. Der Ablauf lohnt sich für die Artikel, die einfach nach Meldebestand laufen: C-Teile, Verbrauchsmaterial, Handelsware. Erfahrungsgemäß ist das der größere Teil der Positionen und der kleinere Teil der Aufmerksamkeit.
Ja, und wir empfehlen es. In der Sandbox läuft er gegen echte Daten, ohne dass etwas entsteht. Produktiv kannst Du ihn zunächst nur melden lassen, was er bestellen würde, und erst nach zwei Wochen scharf schalten – dann weißt Du, ob seine Vorschläge Deinen entsprechen.
Dann legt der Flow nichts an, sondern setzt den Artikel auf die Ausnahmeliste der Laufmeldung. Raten wäre hier die schlechtere Option: Eine Bestellung beim falschen Lieferanten kostet mehr Zeit, als sie spart.
In der Sandbox kannst Du unbegrenzt bauen und testen, so lange Du willst. Und im Produktivmandanten bleiben zwei aktive Flows dauerhaft kostenlos – kein Testzeitraum, der abläuft.
Beim Buchen einer Verkaufsrechnung erzeugt AutoFlow das PDF, legt es im richtigen SharePoint-Ordner ab und schreibt den Link zurück an den Beleg.
Anwendungsfall lesen
Ein Ticket im Fremdsystem erzeugt per Webhook einen Serviceauftrag in Business Central – mit Zuordnung des Debitors und Prüfung des Vertrags.
Anwendungsfall lesen