Produktdatensätze, Kit-Komponenten und die Bilder, auf die jeweils ein Datensatz verweist, werden von Odoo in Inriver übertragen, sodass der Katalog beschreibt, was ein Kunde erhält, und nicht, was das Lager zufällig auswählt.
Odoo kann ein Set als ein Produkt verkaufen und es als mehrere Produkte auswählen, was für ein Lager sinnvoll, für einen Katalog aber verwirrend ist. Inriver muss entscheiden, ob der Kunde ein einzelnes Produkt mit Spezifikation oder ein Teilepaket mit eigenen Produktseiten kauft. Wird keine Entscheidung getroffen, werden beide angezeigt. Ein Käufer vergleicht ein Set mit einer seiner Einzelkomponenten, die Bilder gehören zu den Teilen und nicht zum Produkt, und die Seite, auf der der Kunde landet, ist nicht die, die veröffentlicht werden soll. Die Verbindung von Odoo und Inriver legt die Darstellung fest, bevor etwas veröffentlicht wird.

Ein Odoo-Kit gelangt als das vom Kunden gekaufte Produkt zu Inriver, wobei seine Komponenten als Beziehungen gespeichert sind, sodass der Katalog eine Seite anstatt einer Seite pro Teil anzeigt.
Bilder und Dokumente dienen eher als Referenzen denn als Kopien; daher ist das auf einer Seite angezeigte Element das von jemandem genehmigte Element, und eine Aktualisierung bedeutet nicht, dass es neu veröffentlicht wird.
Komponenten, die ein Kunde auch separat erwerben kann, behalten ihre eigenen Inriver-Datensätze, sodass ein Ersatzteil eigenständig auffindbar bleibt und nicht mit dem Kit, zu dem es gehört, konkurriert.
Da die Form vor der Veröffentlichung festgelegt wird, stellt bei der Markteinführung niemand fest, dass dasselbe physische Produkt zweimal im Katalog unter zwei verschiedenen Codes existiert.
Alumio liest ein Odoo-Kit mit seinen Komponenten und erstellt das Inriver-Produkt, das ein Kunde kauft. Dabei werden die Teile über den Beziehungstyp, den das Inriver-Modell darstellt, zusammengehalten, sodass der Katalog eine Seite mit der dahinterliegenden Komposition enthält.
Die Asset-Referenzen werden von Odoo zu Inriver übertragen, nicht die Dateien selbst. So verweist eine Seite auf das freigegebene Bild an seinem Speicherort, und ein Ersatzbild erreicht jeden Kanal, ohne dass für jeden Kanal ein zweiter Importvorgang durchgeführt werden muss.
Eine Komponente, die auch einzeln verkauft wird, behält ihren eigenen Inriver-Datensatz, der mit dem Kit verknüpft ist, sodass ein Kunde, der nach einem Ersatzteil sucht, dieses ohne das Kit findet und das Teil wie ein und dasselbe Produkt erscheint.
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.
Was der Katalog benötigt und das ERP-System nicht bereitstellen kann, ist der Leitfaden – und für die meisten Unternehmen ist das die gedruckte Version. Die Beauftragung einer Katalogproduktionsfirma ist daher üblich, da Inriver fertige Produktinhalte bereitstellt und für den Druck ein Layout und ein Korrekturabzug erforderlich sind, während Odoo dazu keine Vorgaben macht. Alumio stellt diese Verbindung ebenfalls her, sodass die gedruckte und die Online-Seite auf demselben freigegebenen Produkt basieren.
Asset-Referenzen haben Priorität, da Fehler hier eine spätere Neuveröffentlichung aller Inhalte erfordern. Alumio liest Odoo-Produktdatensätze, Kit-Komponenten und die Verweise auf die Speicherorte von Bildern und Dokumenten und schreibt diese in die Inriver-Attribute, die einen Verweis akzeptieren. So verweist eine Seite auf das gespeicherte Asset und nicht auf eine Kopie. Preise und Codes folgen gemäß Ihrem Zeitplan, und noch nicht fertige Produkte verbleiben in Inriver.
Nein, und der entscheidende Unterschied liegt in der Referenz, nicht in der Datei. Alumio speichert den Pfad zu einem Odoo-Asset, anstatt die Datei zu verschieben. Dies ist eine Konfiguration in der Benutzeroberfläche, weshalb ein ersetztes Image nicht erneut durch alle Kanäle verarbeitet werden muss. Da Inriver-Modelle implementierungsspezifisch erstellt werden, bleibt benutzerdefinierte Logik über den Code Transformer verfügbar, falls ein Beziehungstyp kein direktes Äquivalent hat.
Das Produkt, das der Kunde kauft, und die dazugehörigen Komponenten werden als Beziehungen verknüpft. Odoo kann ein Set als Einzelartikel verkaufen und es auch als mehrere Artikel auswählen. Der Katalog muss daher auswählen, welche dieser Optionen auf einer Seite beschrieben wird. Werden beide angezeigt, präsentiert Odoo dem Kunden sowohl das Set als auch seine einzelnen Komponenten. Indem Inriver als verkaufsfähiges Produkt definiert und die Komponenten verknüpft, stellt der Katalog sicher, dass der Lieferumfang mit dem tatsächlichen Produkt übereinstimmt.
Ein defekter Asset-Link ist die Ursache des Fehlers. Die Seite lädt weiter, weshalb der Fehler erst spät bemerkt wird. Der Odoo-Datensatz und die fehlerhafte Referenz bleiben erhalten, die Benachrichtigung erfolgt sofort und nennt Produkt und Fehlerursache. Konfigurierte Wiederholungsversuche werden ausgeführt. Die vorherige Referenz bleibt aktiv, sodass keine Inriver-Seite mit einem fehlenden Bild veröffentlicht wird und nichts unentdeckt 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.