Der von Oracle für jede Filiale verwaltete Lagerbestand wird an die entsprechenden Lightspeed POS-Kassen übertragen, und jeder Verkauf wird dem jeweiligen Standort zugeordnet, sodass das Regal einer Filiale niemals stillschweigend als das einer anderen Filiale gezählt wird.
Oracle verwaltet den Lagerbestand standortspezifisch, während die Kassen einer Kette den zuletzt erfassten Bestand anzeigen. Daher unterscheiden sich die beiden Systeme donnerstags deutlich in der Darstellung desselben Geschäfts. Die Zentrale sieht einen Wert, der eine wegen Umbauarbeiten geschlossene Filiale beinhaltet, die Filiale hingegen einen Wert, der seit Montag nicht mehr aktualisiert wurde. Einem Kunden wird etwas versprochen, das sich in einer drei Orte entfernten Filiale befindet. Die Mitarbeiter vertrauen den Bildschirmdaten nicht mehr und rufen stattdessen in der Filiale an. Die Verbindung von Oracle und Lightspeed POS verknüpft jede Kasse mit dem zugehörigen Standort. So reduziert ein Verkauf den Lagerbestand dort, wo er tatsächlich stattgefunden hat, und der Kassenbestand entspricht dem Bestand, mit dem die gesamte Kette arbeitet.

Die Kassensysteme von Lightspeed POS werden mit dem Oracle-Lagerbestand des jeweiligen Geschäfts, in dem sie sich befinden, gespeist, sodass niemand einem Kunden etwas verspricht, das sich in einer zwei Stunden entfernten Filiale befindet.
Jeder Verkauf an einem Lightspeed-POS-System ruft die Daten des entsprechenden Oracle-Standorts ab, sodass das Bild der Kette vom tatsächlichen Warenstandort während des gesamten Handelstages korrekt bleibt.
Die von Oracle veröffentlichten Produkte und Preise werden gleichzeitig an alle Lightspeed POS-Kassen übermittelt, sodass eine neue Zeile an einem zentralen Ort eingerichtet wird, anstatt dass ein Manager an jeder Kasse einzeln eingreift.
Ein neuer Lightspeed POS-Standort wird mithilfe des bereits vorhandenen Musters mit seinem Oracle-Pendant verbunden, sodass der Shop vom ersten Tag an korrekt funktioniert.
Alumio liest den Oracle-Lagerbestand für jeden Standort aus und sendet ihn an die Lightspeed-POS-Kassen in diesem Geschäft, sodass das, was ein Kollege auf dem Bildschirm sieht, tatsächlich das ist, was sich im Regal hinter ihm befindet.
Nach Abschluss eines Handelstages bucht Alumio die Lightspeed POS-Verkäufe und -Rückerstattungen an den Oracle-Standort, an dem sie erfasst wurden, sodass die Leistung eines einzelnen Geschäfts für sich steht und nicht Teil einer regionalen Gesamtleistung ist, die niemand aufschlüsseln kann.
Ein Kunde holt eine Bestellung im Geschäft ab, das Kassensystem von Lightspeed erfasst dies, und Alumio entfernt den entsprechenden Bestand aus dem Oracle-Lager, sodass im Geschäft kein Artikel mehr angezeigt wird, den bereits jemand mitgenommen hat.
Alumio fungiert als zentrales Integrations-Backbone zwischen Vertriebskanälen und Fulfillment-Systemen. Bestellungen werden weitergeleitet, transformiert und validiert, während Status-Updates an jeden Kanal zurückgemeldet werden.
Authentifizieren Sie Ihre Systeme mit den vorgefertigten Connectoren von Alumio. Wählen Sie aus über 200 Connector-Paketen im Marketplace oder erstellen Sie unbegrenzt viele individuelle Integrationen.
Definieren Sie in einer visuellen Oberfläche, wie Datenfelder zwischen Systemen zugeordnet werden. Passen Sie Formate an, reichern Sie Datensätze an und wenden Sie Geschäftslogik an – ganz ohne eigenen Programmcode.
Konfigurieren Sie Abläufe so, dass sie in Echtzeit bei bestimmten Ereignissen, nach einem Zeitplan oder beidem ausgeführt werden. Reduzieren Sie die manuelle Dateneingabe und überlassen Sie Alumio den Datentransfer und die Transformation zwischen Ihren Systemen.
Sobald Ihre erste Integration live ist, können Sie Ihr ERP, PIM, WMS oder CRM einfach an denselben Hub anschließen. Bestehende Abläufe laufen nahtlos weiter. Kein Neuerstellen von Grund auf.
Die zweite Verbindung, die die meisten Ketten herstellen, ist die zu den Mitarbeitern im App Store, mit denen Abholbestellungen zusammengestellt werden. Oracle weiß, dass eine Bestellung vorliegt, und Lightspeed POS weiß, dass die Filiale ausgelastet ist. Beide Systeme geben jedoch keine Auskunft darüber, welches Paket abgeholt werden soll. Alumio hält diese Verbindung parallel aufrecht und nutzt die bereits eingerichtete Standortzuordnung, sodass eine Abholung für dieselbe Filiale erfolgt, aus der die Ware stammt.
Beide Abläufe sind automatisch und laufen bewusst auf unterschiedlichen Taktraten. Verkäufe und Rückerstattungen werden von Lightspeed POS in Echtzeit verarbeitet, da der Lagerbestand eines Shops sofort nach dem Überspringen einer Transaktion nicht mehr korrekt ist. Produkte und Preise hingegen werden von Oracle nach einem Zeitplan veröffentlicht, sodass Änderungen gleichzeitig an allen Kassen verfügbar sind. Beide Prozesse werden pro Ablauf individuell konfiguriert, anstatt einheitlich für alle. Die Kassen können nur die von Oracle bereitgestellten Daten zurückmelden; die Routen werden entsprechend angepasst.
Nein, das ist konfiguriert, nicht programmiert. Die ersetzte Routine ist die, bei der ein Manager eine Preisänderung in jede Kasse eingibt und anschließend jemand anderes die Tageseinnahmen von Lightspeed POS in Oracle eingibt. Welche Filiale zu welchem Standort gehört und welche Preisliste jeweils verwendet wird, sind Einträge in Alumio. Falls eine Kette eine ungewöhnliche Werbeaktion durchführt, die sich nicht durch eine Zuordnung abbilden lässt, übernimmt der Code Transformer diese Logik.
Die Daten werden zum Zeitpunkt des Verkaufsabschlusses übermittelt, nicht erst nach Sitzungsschluss – eine bewusste Entscheidung. Wartet man bis zum Handelsschluss, verbringt Oracle die Handelszeit damit, einen nicht mehr existierenden Shop zu beschreiben, genau dann, wenn ein Kunde die Verfügbarkeit prüft. Durch die Übermittlung jedes Lightspeed-POS-Verkaufs in Echtzeit bleibt der Status aktuell, und der Sitzungsschluss dient lediglich der Überprüfung des Tagesstatus, anstatt die erste Meldung zu übermitteln.
Jedes Lightspeed-POS-Kassensystem meldet die gesendeten Daten, und Alumio erfasst den Empfängerort in Echtzeit. So wird im Nachhinein kein Handelstag rekonstruiert. Ein Verkauf, der einen bereits von Oracle außer Betrieb genommenen Shop belastet, erscheint auf beiden Seiten korrekt, obwohl nur die Zählung abweicht. Daraufhin wird sofort eine Warnung mit Angabe der Kasse und des Grundes ausgelöst. Konfigurierte Wiederholungsversuche werden durchgeführt, sodass keine Einnahmen verloren gehen.
Sprechen Sie mit einem Alumio-Integrationsspezialisten. Wir entwerfen die passende Architektur für Ihre Systeme und die richtige Skalierung, damit Ihre Betriebsabläufe bei jeder Veränderung zuverlässig bleiben.