Vi presenterar Alumio Route Builder
Anslut, orkestrera och styr integrationer i stor skala från ett visuellt gränssnitt
Produktregister, kitkomponenter och bilderna som var och en pekar på transporteras från Odoo till Inriver, så katalogen beskriver vad en kund får snarare än vad lagret råkar plocka.
Odoo kan sälja ett kit som en produkt och välja det som flera, vilket är rimligt för ett lager och förvirrande för en katalog. Inriver måste bestämma om kunden köper en sak med en specifikation eller ett paket med delar med egna sidor, och om ingen bestämmer sig visas båda. En kund jämför ett kit med en av dess egna komponenter, bilderna tillhör delarna snarare än produkten, och sidan en kund landar på är inte den sida som någon avsedd att publicera. Genom att koppla samman Odoo och Inriver avgörs formen innan något publiceras.
DATA SOM FLÖDAR MELLAN DEM
Produktposter
Satskomponenter
Artikelkoder
Försäljningspriser
Tillgångsreferenser
Produktrelationer
Ett Odoo-kit når Inriver som den produkt en kund köper, med dess komponenter hållna som relationer, så katalogen visar en sida istället för en sida per del.
Bilder och dokument används som referenser snarare än som kopior, så den resurs som en sida visar är den resurs som någon har godkänt och att uppdatera den innebär inte att publicera om den.
Komponenter som en kund också kan köpa separat behåller sina egna Inriver-register, så en reservdel kan fortfarande hittas utan att konkurrera med den sats den tillhör.
Eftersom formen bestäms före publicering upptäcker ingen vid lanseringen att samma fysiska produkt finns två gånger i katalogen under två olika koder.
Alumio läser ett Odoo-kit med dess komponenter och skapar den Inriver-produkt som kunden köper, genom att hålla delarna genom den relationstyp som Inrivers modell exponerar, så att katalogen innehåller en sida med kompositionen bakom sig.
Resursreferenser färdas från Odoo till Inriver snarare än filerna själva, så en sida pekar på den godkända bilden på den plats den finns och en ersättning når varje kanal utan att en andra import körs för var och en.
En komponent som också säljs separat har sin egen Inriver-post kopplad till satsen, så en kund som letar efter en reservdel hittar den utan att satsen och delen ser ut att vara en och samma produkt.
Alumio fungerar som en central integrationsplattform mellan försäljningskanaler och logistiksystem. Order dirigeras, transformeras och valideras, samtidigt som statusuppdateringar skickas tillbaka till varje kanal.
Autentisera dina system med Alumios färdiga kopplingar. Välj bland över 200 kopplingspaket i vår marketplace, utöver obegränsade anpassade integrationer.
Definiera hur datafält mappas mellan system i ett visuellt gränssnitt. Justera format, berika poster och tillämpa affärslogik – helt utan behov av anpassad kod.
Konfigurera flöden så att de körs i realtid baserat på händelser, enligt ett schema eller både och. Minska manuell datainmatning och låt Alumio hantera förflyttning och transformering mellan system.
.svg){kind=icon}
När din första integration är live, ansluter du enkelt ditt ERP, PIM, WMS eller CRM till samma hubb. Befintliga flöden fortsätter att köras. Ingen ombyggnad från grunden krävs.
Det katalogen behöver och ERP-systemet aldrig kommer att innehålla är guiden, och för de flesta företag är det den tryckta versionen. Ett katalogproduktionshus är det vanliga tillägget, eftersom Inriver har färdigt produktinnehåll och en tryckt upplaga behöver det layoutat och korrekturläst, medan Odoo inte har någon åsikt om någondera. Alumio har den kopplingen vid sidan av denna, så den tryckta sidan och onlinesidan är byggda av samma godkända produkt.
Referenser till tillgångar kommer först, eftersom felaktiga referenser innebär att allt måste publiceras om senare. Alumio läser Odoo-produktposter, kitkomponenter och referenserna till var bilder och dokument lagras, och skriver dem till Inriver-attributen som accepterar en referens, så att en sida pekar på den lagrade tillgången snarare än en kopia. Priser och koder följer det schema du anger, och produkter som ännu inte är klara stannar kvar i Inriver.
Nej, och den användbara skillnaden är en referens snarare än en fil. Alumio skriver pekaren till var en Odoo-tillgång finns istället för att flytta filen, vilket är konfigurationen i gränssnittet, och det är därför en ersatt bild inte kräver en andra passage genom varje kanal. Eftersom Inriver-modeller byggs per implementering förblir anpassad logik tillgänglig via Code Transformer där en relationstyp inte har någon direkt motsvarighet.
Produkten som kunden köper, med delarna som relationer bakom den. Odoo kan sälja ett kit som en enda artikel och välja det som flera, så katalogen måste välja vilken av dessa en sida beskriver, och publicering placerar både ett kit och sin egen komponent framför samma kund. Att besluta att Inriver innehåller den säljbara produkten och länka komponenterna gör att katalogen matchar det som anländer i lådan.
En länk till tillgången som gick sönder är felet här, och sidan fortsätter att laddas, vilket gör det långsamt att upptäcka den. Både Odoo-posten och referensen som misslyckades behålls, varningen är omedelbar, med produkten och orsaken angiven, och försöken körs där de är konfigurerade. Den tidigare referensen förblir aktiv, så ingen Inriver-sida publiceras med en saknad bild och ingenting går oregistrerat.
Prata med en integrationsspecialist på Alumio. Vi tar fram rätt arkitektur för dina system, i rätt skala, så att din verksamhet förblir stabil genom alla förändringar.
.svg)
