Kortintag som registreras av Square stämmer överens med Odoo POS-sessionen som faktiskt registrerade försäljningen, så en butik stänger med en överenskommen uppsättning siffror istället för två separata som nästan matchar.
Square och Odoo POS kan var för sig fungera som kassa, och när båda är igång har ingen nödvändigtvis bestämt vilken som är rätt. En försäljning registreras två gånger, en återbetalning visas i den ena men inte i den andra, och chefen som avslutar har en kortrapport, en kassarapport och inget sätt att avgöra vilken av dem som är rätt. Huvudkontoret väntar på siffror som ingen litar på. Att koppla samman Square och Odoo POS avgör frågan: betalningar matchar den session som registrerade dem, butik för butik, och det som inte stämmer överens flaggas som en namngiven skillnad snarare än att tyst beräknas som medelvärde.

Varje Square-betalning matchar den Odoo POS-rad som registrerade den, så en enskild transaktion slutar visas som två och dagens intäkter slutar att blåsas upp på huvudkontoret.
Det som inte stämmer överens mellan Square och Odoo POS genereras som en namngiven skillnad, så en chef kontrollerar en flaggad artikel istället för att arbeta ner en kvittospole.
En återbetalning som tas via Square är kopplad till den ursprungliga Odoo POS-sessionen, så returer minskar den handel de tillhör snarare än att ackumuleras som oförklarade negativa transaktioner.
Eftersom matchning sker allt eftersom handeln fortskrider under dagen blir stängningen av en butik en granskning av undantag snarare än en timme som läggs på att stämma av två system manuellt.
När Square registrerar en betalning matchar Alumio den med Odoo POS-raden och sessionen som registrerade försäljningen i den specifika butiken, så att de två systemen överensstämmer transaktion för transaktion snarare än bara på en daglig summa.
Vid avslutningen rapporterar Alumio vad som än stämde överens mellan Square och Odoo POS för den platsen, så chefen undersöker en kort lista med namngivna skillnader istället för att kontrollera varje enskild rad mot en utskrift.
En Square-avvecklingsbatch bryts upp mot de Odoo POS-sessioner den täcker, så beloppet som anländer till banken kan spåras till handeln som producerade den utan att någon återskapar det i ett kalkylblad.
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.
Bokföringssystemet är vanligtvis det tredje systemet. Återförsäljare som kör Square tillsammans med Odoo POS upptäcker att avstämda kassor fortfarande måste nå bokföringen, och att justera dem omintetgör poängen med automatisk matchning. Alumio håller ihop dessa kopplingar, så att huvudboken får en överenskommen siffra snarare än en kortrapport och en kassarapport som ska diskuteras.
Per plats, och endast utåt från vilket system du än har skapat kassan. Alumio matchar Square-kortbetalningar med Odoo POS-sessionen som registrerade dem, butik för butik, och rapporterar vad som inte stämmer överens. Att avgöra vilket system som är auktoritativt först är det som gör detta meningsfullt, eftersom två kassor som synkroniseras med varandra ger överensstämmelse utan noggrannhet.
Nej, matchningen konfigureras snarare än byggs. Alumio mappar Square-betalningsreferensen till Odoo POS-sessionen och raden som registrerade försäljningen, och anger när avstämningen körs, allt i gränssnittet. Där två system båda beter sig som kassor blir reglerna specifika, så kodtransformatorn finns där för att en fältmatchning inte ska uttryckas, till exempel att dela upp en betalning över två kassarader.
Välj en per plats och låt den andra vara betalningsspår. Square och Odoo POS kan båda fungera som kassa, vilket är just därför som att lämna det obestämt producerar två poster för en försäljning och en avstämning som ingen slutför. I praktiken är det systempersonalen som trycker på för att ringa försäljningen som är kassan, och den andra ska bidra med betalnings- och avräkningsdata till den, aldrig en andra försäljningspost.
Misslyckandet med att upptäcka detta är en försäljning registrerad två gånger, inte en registrerad ingenstans. Alumio tittar på varje match live och registrerar vad den jämförde, så en Square-betalning som går till två Odoo POS-rader, eller till ingen, spärras och aviseras omedelbart istället för att bokföras, med återförsök där det är konfigurerat. Anledningen ligger i transaktionen, så en butik stänger aldrig på en totalsumma som ingen kan spåra.
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.