Vi presenterar Alumio Route Builder
Anslut, orkestrera och styr integrationer i stor skala från ett visuellt gränssnitt
Mellan en Odoo-produktmall och Akeneo-familjen som beskriver den ligger ett beslut om varianter, och att koppla samman de två gör det beslutet en gång snarare än en gång per produktlansering.
Odoo lagrar inte varianter, det genererar dem. En mall innehåller de attribut som en produkt varierar med, och kombinationerna framträder utifrån det, vilket är effektivt tills katalogen måste beskrivas. Akeneo fungerar tvärtom, med en familj som definierar vad en produkt måste ha och variationer byggs på valda axlar. Om de lämnas okopplade, plattar någon ut Odoos genererade lista till ett kalkylblad och bygger om strukturen för hand, olika varje säsong. Integrationen mellan Odoo och Akeneo mappar mall till familj och genererad variant till variation en gång, så katalogen levereras med sin form redan intakt.
DATA SOM FLÖDAR MELLAN DEM
Produktmallar
Produktvarianter
Attribut
Variationsaxlar
Kategorier
Försäljningspriser
Odoo-mallar och de varianter som genereras från dem landar på matchande Akeneo-familjer och axlar, så ingen bygger om formen på ett intervall för hand i början av varje säsong.
Eftersom variationen sitter på valda axlar i Akeneo, når text som skrivs vid föräldern varje Odoo-variant under den istället för att upprepas för varje storlek och färg.
Produktdata flyttas från Odoo till Akeneo enligt ett schema snarare än genom en export, så ett nytt intervall behöver inte vänta på den som vanligtvis formar kalkylbladet.
När Odoo börjar variera ett intervall med något nytt, utökas Akeneo-arrangemanget snarare än skrivs om, så att lägga till en dimension är en förändring snarare än ett projekt.
Alumio läser en Odoo-produktmall med vad den varierar med och skapar eller uppdaterar den matchande Akeneo-familjen och dess variationsaxlar, så att intervallet anländer strukturerat istället för som en platt lista som någon måste sätta ihop igen.
En beskrivning som skrivs en gång på föräldernivå i Akeneo gäller för varje variant som genereras från den Odoo-mallen, så ett intervall på fyrtio varianter skrivs upp en gång snarare än fyrtio gånger av den som drog det kortaste strået.
Reapriser från Odoo uppdaterar matchande Akeneo-produkter medan beskrivningarna förblir som katalogteamet skrev dem, så en prisändring skriver aldrig tyst över en hel vecka av någon annans redaktionella arbete.
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.
Två saker måste till innan en sida kan publiceras, och bara en av dem kommer inifrån företaget. Fotograferingen och produktionen av material ligger hos en studio, och Akeneo har produkten som väntar på den, medan Odoo inte vet något om någon av dem. Alumio har den kopplingen bredvid denna, så bilderna hamnar mot samma produkthistorik som katalogteamet redan berikar.
Ja, och fullständigheten avgör vad som lämnar Akeneo snarare än vad som kommer in i det. Alumio tar in Odoo-mallar, varianter, attribut och priser enligt det schema du anger, och Akeneo håller sedan tillbaka en produkt från kanalerna som läser den tills familjens krav är uppfyllda. Det håller ett halvskrivet sortiment utom synhåll utan att någon behöver komma ihåg att dölja det.
Nej, detta är konfigurerat snarare än kodat. Detta ersätter kalkylarket som brukade ligga i en delad mapp, det där någon registrerade vilket Odoo-värde som blir vilken del av en Akeneo-produkt och sedan behöll en andra kopia för de områden som beter sig annorlunda. Det blir poster i Alumio. Där en variationsregel inte kan uttryckas som konfiguration tar Code Transformer den.
På de variationsaxlar du nominerar, vilket är ett beslut snarare än en automatisk översättning. Odoo genererar varianter från attributkombinationer, så att det kan producera en lång lista som inte har någon inneboende gruppering, medan en Akeneo-familj förväntar sig att variationen ska sitta på valda nivåer. Att bestämma vilka Odoo-attribut som blir axlar och vilka som förblir vanliga värden är det som gör att berikning sker en gång överst istället för per kombination.
En produkt som publiceras innan dess familj var nöjd leder till att den inte fångas, och att vägra den är ett bättre resultat även om det känns som ett hinder. Alumio övervakar varje överföring live och loggar Odoo-mallen och vad den innehöll, så en Akeneo-familj som inte accepterar en produkt utlöser en varning som anger artikeln och orsaken, vanligtvis ett krav som familjen har och som produkten inte har uppfyllt. Återförsök körs där de är konfigurerade, så ingenting tas bort i tysthet.
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)
