Die in Sage noch zu kodierenden Transaktionsbeschreibungen werden dem Benutzer von OpenAI als Vorschläge präsentiert. So wird ihm der mühsame Teil der Arbeit abgenommen, nicht aber die Entscheidung.
Der größte Teil der Buchhaltungszeit entfällt auf die wiederholte Zuordnung von Transaktionen zu Konten, selbst bei scheinbar identischen Einträgen. Ein Modell liefert zwar gute Lösungsvorschläge, ist aber nicht immer zuverlässig. Solange keine Buchungen automatisch erfolgen, ist diese Kombination jedoch praktikabel. Die OpenAI-Sage-Integration funktioniert genau nach diesem Prinzip: Vorschläge werden zu bereits in Sage vorhandenen Transaktionen generiert, von einem Benutzer bestätigt oder geändert, und erst die Bestätigung wird verbucht. Da Sage kein einheitliches Produkt ist, hängt die verwendete Schnittstelle davon ab, welches Sage-System Sie nutzen.

Die Transaktionen werden mit bereits zugeordnetem Kontovorschlag übermittelt, sodass die Arbeit darin besteht, einen Vorschlag zu überprüfen, anstatt mehrmals im Monat von Grund auf neu entscheiden zu müssen.
Ein Vorschlag ist nur ein Vorschlag, bis ihn jemand bestätigt. Deshalb wurde das Konto, auf dem eine Transaktion letztendlich landet, immer von einer Person ausgewählt, die später dazu befragt werden kann.
Transaktionen, bei denen das Modell unsicher ist, werden von den Routinetransaktionen getrennt, sodass die Aufmerksamkeit dort gelenkt wird, wo tatsächlich ein Urteil erforderlich ist, anstatt gleichmäßig verteilt zu werden.
Da die Vorschläge darauf basieren, wie ähnliche Dinge zuvor codiert wurden, landet die gleiche Transaktion nicht mehr auf drei verschiedenen Konten, je nachdem, wer sie verarbeitet hat.
Transaktionen, die noch kodiert werden müssen, werden an ein vorgeschlagenes Konto weitergeleitet, und die Vorschläge werden jeweils mit den entsprechenden Konten zurückgesendet, sodass der Buchhalter eine geprüfte Liste durcharbeitet, anstatt mit einer völlig leeren Liste beginnen zu müssen.
Jemand akzeptiert oder ändert jeden Vorschlag, und nur die bestätigte Antwort wird an Sage zurückgeschrieben, sodass der Prüfpfad die Entscheidung einer Person zeigt und nicht eine automatisierte Vermutung, die sich im Unternehmen nie jemand angesehen hat.
Wenn eine Beschreibung zu wenig Anhaltspunkte liefert, wird die Transaktion zurückgestellt, anstatt eine plausible Erklärung abzugeben, damit die Fälle, die eine echte Entscheidung erfordern, sichtbar bleiben und nicht unter den mehreren hundert einfachen Fällen untergehen.
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.
Ein Bankfeed ist die übliche Ergänzung, da die Beschreibung, auf der ein Modell basiert, in der Regel von der Bank und nicht von Sage stammt. Alumio verbindet sich über die Schnittstelle, die Ihre Version bereitstellt, mit Sage – wie mit jedem erreichbaren System – und hält die Bankverbindung parallel aufrecht, sodass Vorschläge auf Basis der vollständigsten verfügbaren Beschreibung erfolgen.
Vorschläge können automatisch generiert werden. Buchungen hingegen nicht. Alumio sendet Transaktionen für einen Vorschlag und übermittelt die zugehörigen Antworten. Anschließend wartet das Unternehmen, da die Bestätigung der entscheidende Schritt und kein Hindernis ist. Sobald ein Batch bestätigt wurde, erfolgt die Übertragung an Sage ohne weiteren Aufwand.
Nein, allerdings gibt es eine Entscheidung, die sorgfältig überlegt werden sollte: Was gilt als ausreichend sicher, um überhaupt einen Vorschlag zu unterbreiten? Dieser Schwellenwert und das Verhalten aller Werte darunter werden in einem Formular festgelegt und im Laufe der Zeit angepasst. Alles andere ist normales Mapping. Der Code-Transformator kommt zum Einsatz, falls sich eine Regel für Ihre eigenen Konten nicht auf diese Weise beschreiben lässt.
Dass sich jemand das angesehen hat und die besonders verdächtigen Fälle markiert wurden. Ein Modell liefert eine überzeugende Antwort für eine Transaktion, für die es keine wirkliche Grundlage hat, und diese Antwort liest sich genau wie eine plausible. Ein sinnvolles Design besteht also nicht in einem clevereren Vorschlag, sondern in einem Prüfschritt, den niemand überspringen kann, und einer klaren Trennung zwischen Routine und Zweifelsfällen.
Das eigentliche Risiko besteht darin, eine Reihe von Vorschlägen ungelesen zu akzeptieren. Dies ist eher ein Prozessfehler als ein technischer. Technisch gesehen werden Schreibvorgänge in Echtzeit überwacht und jede Transaktion protokolliert. Bei Ablehnung wird umgehend eine Begründung angegeben, und gegebenenfalls werden Wiederholungsversuche durchgeführt. Unbestätigte Vorschläge werden niemals stillschweigend im Hintergrund veröffentlicht.
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.