Måttenheter och paketkonfigurationer som lagras i Oracle anländer till Akeneo redan konverterade, så en ärendekvantitet publiceras aldrig i ett attribut som ska beskriva en enda enhet.
Oracle registrerar vad ett företag köper, innehar och säljer, vilket ofta är tre olika enheter för samma produkt: en pall inkommande, en låda i lagret, en styck vid försäljningsstället. Akeneo publicerar till kanaler som antar en. När konverteringen sker i ett kalkylblad, eller i någons huvud, landar en ärendesiffra så småningom i ett fält som betyder styck, och produktsidan läses som fel snarare än som trasig. Integrationen från Oracle till Akeneo gör konverteringen i flödet, så varje kanal får den enhet den förväntar sig och beräkningen sker en gång istället för per person.

Pack-to-piece-aritmetik körs i flödet snarare än i ett kalkylblad, så varje kanal som läser Akeneo arbetar från samma konvertering av samma Oracle-siffra.
Måttvärden når typade Akeneo-attribut med den enhet de tillhör, så en vikt eller volym lagras som en kvantitet och en enhet snarare än som ett rent tal.
Eftersom paketkonfigurationer kommer från Oracle uttrycks det en kund beställer med samma termer som lagret plockar in, och färre beställningar anländer som behöver en diskussion.
Nya Oracle-objekt landar i Akeneo med sina koder, enheter och kategorier redan ifyllda, och återvänder till eftermiddagen som en produktchef brukade spendera med att återskapa dem för hand.
En artikel som lagras i fodral i Oracle når Akeneo med både fodralkonfigurationen och styckekvivalenten, så en handelskanal och en konsumentkanal får var och en den siffra som är rimlig för de personer som köper från dem.
Vikter och dimensioner från Oracle fyller i matchande typade attribut i Akeneo, så en fraktberäkning eller ett butiksfilter fungerar utifrån verkliga värden snarare än från ett textfält som någon knappat in för hand.
Ett objekt som skapats i Oracle visas i Akeneo, klart för innehåll, med dess enheter och paketkonfiguration inställda, så produktteamet börjar från en post som redan är korrekt istället för en som någon måste sätta ihop för hand först.
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.
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.
En syndikeringskanal för distributörer är ofta nästa steg, eftersom produktdatan som uppfyller din egen butiks behov också är vad återförsäljare fortsätter att efterfråga i sitt eget format. Alumio hanterar dessa kopplingar centralt och återanvänder den Akeneo-mappning som redan är konfigurerad, så ett distributörsflöde är en ny utdata på befintlig data snarare än en andra katalog att underhålla.
Ja, och konverteringen är den intressanta delen snarare än överföringen. Alumio beräknar i flödet, så en paketkvantitet från Oracle kan publiceras som både ett ärende och ett stycknummer i Akeneo-attributen som förväntar sig var och en. Aritmetiken konfigureras en gång och gäller för varje artikel, vilket är skillnaden mellan en regel och en vana.
Nej, detta är konfigurerat snarare än kodat. Enhetskonverteringar, paketstorlekar och de typade Akeneo-attributen som de fyller i konfigureras i ett formulär och återanvänds i hela katalogen, vilket ersätter uppslagstabellen som för närvarande finns i ett delat kalkylblad. För en konverteringsregel som är tillräckligt udda för att konfigurationen inte kan hantera den, använder kodtransformatorn anpassad logik i det steget.
Vilken än kanalen köper in, och poängen är att Akeneo kan hålla båda. Dess attribut är typade och bär enheter, så en fallfigur skriven i en attributbetydelsesdel är ett giltigt värde som helt enkelt är osant, och ingenting kommer att avvisa det. Att publicera försäljningsenheten per kanal, konverterad i flödet, undviker att be en person komma ihåg vilken som är vilken.
En packfigur som sitter i ett piece-attribut är det fel som gör ont, eftersom det publiceras tydligt och läses som ett fynd. Alumio validerar mot den enhet som varje Akeneo-attribut förväntar sig, övervakar varje uppdatering live och behåller det som skickades, så ett värde som inte uppfyller regeln sparas och varnas med det namngivna objektet och attributet. Återförsök körs automatiskt där det är konfigurerat, så inget fel går tyst till en kanal.
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.