Vilket företag en Shopware-order tillhör kvittas innan den når Microsoft Dynamics 365 F&O, så en försäljning anländer till den juridiska enhet som fakturerar den snarare än den den flyttades till senare.
Microsoft Dynamics 365 F&O bokför allt i en juridisk enhet. En Shopware-butik har ingen sådan, så någonstans mellan kassan och försäljningsordern bestämmer någon vilket företag försäljningen tillhör. I en grupp som driver två eller tre operativa företag bakom en butik fattas det beslutet ofta en månad senare av en ekonomiansvarig som flyttar poster mellan företag. Genom att koppla Shopware och Microsoft Dynamics 365 F&O blir det en regel som tillämpas vid ordern: vad köptes, varifrån det skickas och vem det skickas för att avgöra vilket företag, och försäljningen anländer till det företag som ska fakturera den.

En Shopware-order innehåller vad som köptes och varifrån den skickas, och regeln du anger omvandlar det till den juridiska enheten Microsoft Dynamics 365 F&O innan försäljningen skapas.
Ingen bokför om Shopware-försäljning mellan företag i efterhand, eftersom varje försäljning skapades i rätt företag, så de företagsinterna transaktioner som skrivits för att korrigera det slutar existera.
En grupp behöver inte en Shopware-butik per företag för att hålla ordning och reda i Microsoft Dynamics 365 F&O, eftersom uppdelningen sker i regeln snarare än i butiken som kunden ser.
Lager och pris som publiceras tillbaka till Shopware kommer från det Microsoft Dynamics 365 F&O-företag som skulle uppfylla beställningen, så butiken ger aldrig en offert från en som inte skickar den.
När en beställning görs i Shopware, löser Alumio upp den juridiska personen från den regel du anger och skapar försäljningsordern i det Microsoft Dynamics 365 F&O-företaget, så att ingen i efterhand behöver räkna ut vems försäljning det var.
När ett operativt företag går med i gruppen börjar samma Shopware-butik att mata den genom att utöka regeln snarare än att bygga en andra anslutning till Microsoft Dynamics 365 F&O, så själva butiken ändras inte.
När Microsoft Dynamics 365 F&O har samma vara i mer än ett företag publicerar Alumio positionen för den som skulle leverera till den kunden, så att butiken visar en siffra som någon faktiskt kan uppfylla.
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.
Ja, och i en grupp behöver nästa system vanligtvis samma svar som detta. Ett lager eller en PIM som läggs till senare måste veta vilket företag en order tillhör innan den kan göra något användbart med den. Alumio har den kopplingen vid sidan av denna och entitetsregeln är redan definierad, så det andra systemet ärver den istället för att få sin egen version att drifta från.
Ja, med entiteten löst innan något skrivs. Alumio skapar varje Shopware-order i Microsoft Dynamics 365 F&O-företaget, regeln returnerar och skickar tillbaka tillgänglighet, pris och leveransstatus enligt det schema du anger för varje order. Det som kan skapas på det sättet är det som Microsoft Dynamics 365 F&O exponerar för den, så det är det som måste bekräftas först.
Nej. Entitetsregeln är konfiguration precis som allt annat: vilket Shopware-fält eller leveransvillkor som pekar på vilket Microsoft Dynamics 365 F&O-företag är en post som du kan läsa och ändra, vilket spelar roll eftersom den regeln ändras när gruppen gör det. Där delningen beror på något som konfigurationen inte kan formulera, uttrycker Code Transformer den enda regeln.
Ingenting i själva beställningen, vilket är anledningen till att det måste bestämmas på vägen. En Shopware-kassa känner till artiklarna, leveransadressen och leveransmetoden, och regeln du konfigurerar förvandlar dessa till ett företag: ett varumärke som endast säljs av en enhet, ett land som betjänas av en annan, ett lager som tillhör en tredje. Alumio tillämpar den regeln och skapar försäljningsordern i det företag som returneras, så svaret görs en gång snarare än per beställning.
Felet som är värt att upptäcka här är inte en saknad order utan en som skickats till fel företag, eftersom den ser lyckad ut och dyker upp vid konsolideringen. Alumio övervakar varje överföring live och registrerar den enhet som löstes tillsammans med ordern, så beslutet är granskningsbart snarare än antaget. En order som Microsoft Dynamics 365 F&O vägrar genererar en varning som anger ordern och orsaken, försöken körs där de är konfigurerade och ingenting tas bort tyst.
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.