Webshop-Bestellungen und Abrechnungen von Lightspeed eCommerce werden in Oracle als Buchungen erfasst, mit denen die Finanzabteilung den Monat abschließen kann, und nicht als Bericht, der am Ende jedes Monats von Hand abgeglichen wird.
Ein Onlineshop generiert den ganzen Tag über Umsätze, die die Finanzabteilung als Buchungssätze benötigt – im richtigen Unternehmen und auf den richtigen Konten. Oracle akzeptiert keine Umsätze ohne Angabe des zugehörigen Geschäftsbereichs. Daher muss dies in der Regel am Monatsende anhand einer undurchsichtigen Tabelle für jede Bestellung einzeln festgelegt werden. Die Integration von Lightspeed eCommerce in Oracle trifft diese Entscheidungen einmalig und wendet sie auf alle Bestellungen an. Jede Bestellung ist bereits zugeordnet, und die Tageseinnahmen stimmen mit den tatsächlichen Auszahlungen des Zahlungsdienstleisters überein.

Die Bestellungen werden bei Oracle dem richtigen Geschäftsbereich zugeordnet, sobald sie eingehen. Der Monatsabschluss ist daher eher eine Überprüfung als eine Woche, in der man herausfinden muss, wo die Dinge hingehören.
Zahlungen und Rückerstattungen erfolgen zusammen mit den zugehörigen Bestellungen, sodass der Betrag auf dem Bankkonto und der Betrag auf den Konten ohne manuellen Abgleich abgeglichen werden können.
Eine im Webshop gewährte Rückerstattung wird bei Oracle als Minderung erfasst, sodass die Buchhaltung den tatsächlich einbehaltenen Betrag anzeigt und nicht eine Umsatzzahl, die später jemand aus dem Gedächtnis anpasst.
Die Stunden, die für das Übertragen der Webshop-Verkäufe in die Buchhaltung aufgewendet wurden, zahlen sich aus, denn jede Bestellung kommt mit ihrem Kunden, ihren Positionen und Summen bereits in der vom Hauptbuch gewünschten Form an.
Bei Lightspeed eCommerce wird eine Bestellung aufgegeben, und Alumio erstellt den entsprechenden Eintrag in Oracle für den Geschäftsbereich, der den Verkauf getätigt hat. So bleiben die Konten stets aktuell, ohne dass jedes Mal jemand entscheiden muss, wo der Eintrag hingehört.
Die Bestellungen, Zahlungen und Rückerstattungen des Tages treffen alle gleichzeitig ein, sodass die Finanzabteilung den Gesamtbetrag in Oracle mit der Auszahlung des Zahlungsdienstleisters abgleichen und sofort erkennen kann, ob die beiden Beträge aus irgendeinem Grund nicht übereinstimmen.
Einem Kunden wird im Webshop eine Rückerstattung gewährt, und Oracle erhält die Differenz, sodass am Quartalsende niemand feststellt, dass die ausgewiesenen Umsätze immer noch Geld enthalten, das bereits vor einigen Wochen an einen Kunden zurückgezahlt wurde.
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.
Sobald ein Shop international verkauft, wird häufig ein Steuerdienst hinzugefügt, da der anzuwendende Steuersatz vom Standort des Kunden und den gekauften Artikeln abhängt. Weder der Webshop noch das Buchhaltungssystem möchten diese Logik selbst verwalten. Da beide Systeme an einem Ort angesiedelt sind, wird beim Checkout der vom Buchhaltungssystem erwartete Steuersatz angewendet.
Ja, und der entscheidende Punkt ist, wann eine Bestellung als Buchungseintrag erfasst wird. Ein Warenkorb ist noch kein Verkauf, und auch eine versendete Bestellung ist es manchmal nicht. Daher handelt Alumio in dem Moment, den Sie als endgültig betrachten, in der Regel die Zahlung, und übermittelt die Bestellung, ihre Positionen und die Zahlung zusammen. Rückerstattungen erfolgen auf demselben Weg, sodass keine manuellen Korrekturen vorgenommen werden.
Nein, und die Person, die dies normalerweise einrichtet, ist im Finanz- oder operativen Bereich tätig, nicht in einem Entwicklungsteam. Sie legt fest, welche Bestellungen wohin gehen, und ändert die Zuordnung selbstständig, wenn das Unternehmen ein neues Land oder eine neue Marke hinzufügt, ohne auf andere zu warten. Für die wenigen Fälle, in denen ein Formular die Regel nicht abbilden kann, steht der Code Transformer zur Verfügung.
Sobald Sie sich dafür entschieden haben, sollten Sie dies bewusst festlegen. Manche Unternehmen erfassen einen Verkauf bei Zahlungseingang, andere erst beim Versand. Der Unterschied zeigt sich anschließend in jedem Monatsabschlussvergleich. Oracle muss außerdem wissen, zu welchem Geschäftsbereich der Verkauf gehört, bevor er überhaupt erfasst wird. Daher wird diese Zuordnung einmalig festgelegt und nicht für jede Bestellung einzeln diskutiert.
Die fehlende Abstimmung der Konten, abgesehen von der Gebühr des Zahlungsdienstleisters, ist der Knackpunkt, der uns einen ganzen Nachmittag kostet, denn obwohl alle Aufträge vorliegen, stimmt die Summe trotzdem nicht. Alumio verfolgt jede Transaktion live und speichert die zugehörigen Zahlen. Wenn Oracle eine Transaktion nicht akzeptiert, wird umgehend jemand benachrichtigt und über den Grund informiert. Falls konfiguriert, werden Wiederholungsversuche durchgeführt, sodass kein Verkauf unbemerkt bleibt.
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.