Wir stellen vor: Der Alumio Route Builder
Integrationen zentral über eine visuelle Oberfläche steuern
Ein namentlich genannter Kunde wird in SAP als Verkauf über sein eigenes Konto erfasst, sodass ein gewerblicher Käufer, der seine Ware im Geschäft abholt, gemäß seinen Zahlungsbedingungen in Rechnung gestellt wird, anstatt als Laufkundschaft abgerechnet zu werden.
Eine Kasse ist so konzipiert, dass sie an jeden verkauft, der davorsteht. SAP bucht jedoch keine Verkäufe an Kunden, die nicht bereits als Geschäftspartner geführt werden. Ein Händler, der in einem Geschäft einkauft, wird daher als Barverkäufer erfasst, und die vereinbarten Zahlungsbedingungen, Kontodaten und Preise gelten überall außer an dem Ort, an dem er tatsächlich erschienen ist. Jemand aus der Finanzabteilung rekonstruiert den Vorgang später anhand eines Belegs – sofern dieser überhaupt noch gefunden werden kann. Die Verbindung von SAP und Odoo POS schließt diese Lücke: Die Kasse kann einen bereits in SAP vorhandenen Kunden identifizieren, und der Verkauf wird diesem Kunden zugeordnet.
DATEN, DIE ZWISCHEN IHNEN FLIESSEN
Geschäftspartner
Kundenpreise
POS-Transaktionen
Zahlungszeilen
Produktdatensätze
Filialstandorte
Ein Kunde, der bereits in SAP existiert, kann an der Odoo POS-Kasse identifiziert werden, sodass eine Zahlung im Geschäft seinem Konto gutgeschrieben wird und nicht als anonymer Barverkauf verbucht wird.
Da der Verkauf mit dem zugehörigen Kunden in SAP eingeht, entfällt für die Finanzabteilung die mühsame Suche nach dem zu welchem Konto gehörenden Beleg aus einem Stapel Papier am Monatsende.
Die Transaktionen im Shop erscheinen im selben Kontoverlauf wie alle anderen Einkäufe des Kunden, sodass Anfragen zu Lieferungen und Abholvorgängen von einem einzigen Ort aus beantwortet werden.
Anonyme Verkäufe werden weiterhin in der für eine Warteschlange erforderlichen Geschwindigkeit abgewickelt, da die Identifizierung eines Kunden ein Schritt ist, den der Kassierer nur dann unternimmt, wenn ein Kunde identifiziert werden muss.
Alumio verbindet sich über seine verfügbare API mit Odoo POS, wie es bei jedem erreichbaren System der Fall wäre, sodass eine Kasse einen bereits in SAP vorhandenen Kunden suchen und den Verkauf dem Konto zuordnen kann, anstatt ihn als Barzahlung zu verbuchen.
Die von SAP für diesen Kunden hinterlegten Preise werden in die Odoo POS-Sitzung übernommen, sodass einem Händler, der seine Ware im Geschäft abholt, der Preis berechnet wird, der in seinem Konto angegeben ist, und nicht der Regalpreis, den der Kassierer zufällig auf dem Bildschirm vor sich sieht.
Anonyme und identifizierte Verkäufe werden über dieselbe Kasse in einem einzigen Prozess verarbeitet, und Alumio leitet jeden einzelnen zur richtigen Bearbeitung in SAP weiter, sodass ein Geschäft nicht zwei Kassen oder zwei Prozesse benötigt, um beide Kundentypen zu bedienen.
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.
.svg){kind=icon}
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.
Eine Filiale benötigt etwas, das die Zentrale nicht benötigt, und so kommt üblicherweise die dritte Verbindung zustande. Sobald ein Odoo-POS-Verkauf einen Kunden erfasst, lohnt sich der Versand des Belegs. Daher ist ein digitaler Belegservice eine gängige Ergänzung, denn ein namentlich genannter Kunde hat eine Adresse, und ein Papierbeleg geht bei einer Rückgabe häufig verloren. Alumio hält diese Verbindung parallel zur SAP-Verbindung aufrecht, sodass Beleg und gebuchter Verkauf dieselbe Transaktion beschreiben.
Der Kunde muss identifiziert werden, bevor Buchungen vorgenommen werden können. Diese Reihenfolge ist hier entscheidend. Alumio ermittelt den in SAP hinterlegten Geschäftspartner. Sobald dieser im Kassensystem verfügbar ist, wird jede abgeschlossene Odoo-POS-Transaktion mit den zugehörigen Zahlungszeilen dem entsprechenden Konto zugeordnet. Verkäufe ohne identifizierten Kunden wurden wie gewohnt verbucht, sodass die Kasse die für eine Warteschlange erforderliche Geschwindigkeit beibehält.
Nein, und die Version, die ein Filialleiter erkennt, ist die richtige: Welches Feld der Odoo-POS-Kassierer ausfüllt, was passiert, wenn ein Kunde nicht gefunden wird und ob der Verkauf verzögert oder anonym abgeschlossen wird. Das sind Einstellungen in Alumio und keine Logik in einem Skript. Die Partnerstrukturen von SAP variieren je nach Unternehmensstruktur, daher bleibt benutzerdefinierte Logik über den Code Transformer verfügbar, wenn eine Suchregel nicht als Mapping ausgedrückt werden kann.
Ein bereits existierender Geschäftspartner muss vorhanden sein, da ein Kassensystem keinen für SAP akzeptablen Partner anlegen kann. SAP verwaltet Kunden als Partnerdatensatz mit den Rollen und Kontenstrukturen, die die Buchung eines Verkaufs bestimmen. Daher muss eine Odoo-POS-Transaktion auf einen bestehenden Partner verweisen, anstatt eine Person zu beschreiben. Durch die Konfiguration des Kassensystems, sodass es einen vorhandenen Partner sucht und Transaktionen anonym abwickelt, falls kein Partner vorhanden ist, bleiben beide Verkaufsarten möglich.
Ein Verkauf, der niemandem zugeordnet ist, ist ein zu beachtendes Ergebnis, da er trotzdem ausgeglichen ist. Schlägt die Kundensuche fehl, wird die Odoo-POS-Transaktion als Barverkauf in SAP verbucht, ohne dass sie im Handelskonto erfasst wird und in nachgelagerten Prozessen keine Meldung erscheint. Alumio überwacht jede Überweisung in Echtzeit und protokolliert die Transaktion sowie den Suchversuch. Bei einem fehlgeschlagenen Abgleich wird sofort eine Warnung mit der Begründung ausgegeben, gegebenenfalls werden Wiederholungsversuche durchgeführt, und nicht aufgelöste Verkäufe bleiben in der Liste, anstatt stillschweigend abgeschlossen zu werden.
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.
.svg)
