Vad en Dolibarr-installation faktiskt innehåller bestäms av de moduler som någon har aktiverat, så WordPress-beställningar dirigeras endast till de som detta företag kör snarare än till en standarduppsättning.
Två företag som kör Dolibarr kan nästan inte ha någonting gemensamt, eftersom systemet är sammansatt av moduler och var och en väljer sina egna. En har fakturering och lager, en annan har projekt och lite annat, och en tredje aktiverade kundmodulen förra året och har aldrig använt den. Så en WordPress-webbplats som matar in order i Dolibarr kan inte anta var något hör hemma, och det vanliga resultatet är ett plugin som skriver till det som utvecklaren hade aktiverat vid den tidpunkten. Att koppla samman WordPress och Dolibarr börjar med vad den här installationen faktiskt har, så en order skapar de register som företaget faktiskt för.

WordPress-beställningar når de Dolibarr-moduler som detta företag faktiskt aktiverade, så ingenting skrivs till en del av systemet som ingen här någonsin har öppnat eller underhållit.
En WordPress-köpare blir först en tredje part hos Dolibarr och sedan beställningen, så dokumentet pekar på någon snarare än att bara ha ett namn i en textrad någonstans.
När verksamheten aktiverar ytterligare en Dolibarr-modul utökas WordPress-flödet för att nå den, så att växa in i systemet innebär inte att integrationen måste driftsättas igen.
Mappningen mellan WordPress och Dolibarr finns i Alumio snarare än i kod som någon skrev en gång, så den finns kvar sedan personen som ursprungligen skapade webbplatsen lämnade.
En beställning betalas på WordPress och Alumio skapar de Dolibarr-register som företaget för, vilken tredje part och vilken dokumenttyp som faktiskt används, så beställningen arkiveras på det sätt som företaget arkiverar saker snarare än ett standardsätt.
Produktpriser och lagerhållning hos Dolibarr publiceras på matchande WordPress-sidor i den cykel du väljer, så att butiken anger vad företaget kommer att fakturera istället för en siffra som angavs när sidan först skapades.
När någon som har köpt tidigare beställer igen på WordPress, hittar Alumio den befintliga Dolibarr-tredjeparten och använder den, så historiken lagras på en enda post istället för att skapa en andra för samma person och adress.
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.
Börja med varhelst årsslutet faktiskt förbereds, eftersom det för de flesta företag som kör Dolibarr inte är Dolibarr. Bokföringsprogrammet som en revisor arbetar i innehåller den version av räkenskaperna som lämnas in, och idag exporterar och formaterar någon om för att komma dit. Alumio har den kopplingen bredvid denna, så det som WordPress sålde når båda utan att behöva skrivas in en tredje gång.
Ja, och ordningen i vilken saker skapas spelar större roll än schemat. Alumio löser eller skapar Dolibarr-tredjeparten först, sedan ordern eller fakturan mot den, så ett dokument lämnas aldrig kvar som pekar mot en kund som inte existerar. Produkter och lager färdas åt andra hållet i den cykel du anger, eftersom ett pris på en WordPress-sida kan vänta en timme och en order inte kan. Att skapa den tredje parten och dokumentet håller sig inom vad Dolibarr accepterar.
Nej, detta är konfigurerat snarare än kodat. Det det ersätter är ett formulärtillägg som någon installerat en gång, vilket fungerar tills företaget aktiverar en Dolibarr-modul som tillägget inte vet någonting om och ingen kan säga varför de nya ordrarna ser annorlunda ut. Vilka WordPress-fält som matar vilka Dolibarr-poster lagras i Alumio. Där en installation har utökats på sitt eget sätt täcker Code Transformer det steget.
Det gör du, och det är värt att göra innan något byggs snarare än att upptäcka det efteråt. Dolibarr lagrar bara det som har slagits på, så en beställning kan komma som behöver en dokumenttyp som den här installationen inte har, och integrationen har då ingenstans att placera den. Att lista vilka moduler som är live, och vilka av dem en WordPress-beställning ska beröra, tar en eftermiddag och avgör alla frågor som följer.
En andra kopia av samma order, skapad när någon försökte igen, är det fel som är värt att designa mot här, eftersom båda posterna ser helt giltiga ut. Alumio tittar på varje skrivning live och registrerar WordPress orderreferens mot det som skapades i Dolibarr, så ett upprepat försök känns igen snarare än dupliceras, och allt som vägras utlöser en varning med orsaken. Återförsök körs där de är konfigurerade, så ingenting går i tysthet förlorat.
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.