Vi presenterar Alumio Route Builder
Anslut, orkestrera och styr integrationer i stor skala från ett visuellt gränssnitt
Var köparen råkade befanna sig avgör vad företaget är skyldigt i efterhand, så varje Stripe-betalning når nu Acumatica redan med de uppgifter som en senare anmälan kommer att byggas utifrån.
En Stripe-betalning registrerar ett kort, ett belopp och en plats. En skattedeklaration behöver betydligt mer: vilken myndighet försäljningen gjordes till, till vilken skattesats, mot vilken av företagets registreringar. Acumatica kan lagra allt detta, och kommer inte att lagra något av det om betalningen anländer som en klump med ett datum på. Så någon bygger om detaljerna från exporter i slutet av varje period, och rekonstruktionen är bara så bra som minnet av hur förra kvartalet genomfördes. Integrationen mellan Stripe och Acumatica bär jurisdiktionens detaljer med betalningen, så en deklaration sammanställs snarare än rekonstrueras.
DATA SOM FLÖDAR MELLAN DEM
Betalningar
Återbetalningar
Kunder
Faktureringsadresser
Skattebelopp
Utbetalningar
Varje Stripe-betalning når Acumatica med plats och skattebelopp bifogat, så en anmälan byggs utifrån vad som registrerades vid den tidpunkten snarare än från en senare rekonstruktion.
Eftersom detaljerna redan finns i Acumatica är stängning av en period en granskning av poster snarare än en övning i att räkna ut var ett kvartals försäljning faktiskt gjordes.
En Stripe-återbetalning minskar skatten som registrerats mot den ursprungliga försäljningen i Acumatica, så det som företaget rapporterar återspeglar pengar som det behöll snarare än pengar som det kortvarigt innehade.
Att sälja till en annan jurisdiktion utökar den befintliga mappningen, så Acumatica registrerar den nya skyldigheten från den första betalningen snarare än första gången någon märker det.
När Stripe bekräftar en betalning, bokför Alumio den till Acumatica med faktureringsjurisdiktionen och skattebeloppet överfört, så posten besvarar en fråga om var försäljningen gjordes utan att någon öppnade betalningsposten.
Stripes behandlingsavgifter bokförs på deras eget Acumatica-konto snarare än att minska intäktsraden, så kostnaden för att ta emot kortbetalningar är en siffra som företaget kan titta på och bestämma sig för istället för ett osynligt avdrag.
En återbetalning som utfärdats i Stripe bokförs mot försäljningen som den återför i Acumatica, inklusive den moms som registrerats på den, så en period som redan har rapporterats medför inte obemärkt en skyldighet för pengar som kunden fått tillbaka.
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.
Mer användbart än en andra betalningsmetod är den tjänst som faktiskt lämnar in deklarationen, eftersom Acumatica registrerar skulden och Stripe registrerar pengarna, och ingen av dem skickar in något. Den information som dessa tjänster behöver är den information som denna anslutning bevarar. Alumio har den anslutningen tillsammans med denna, så registreringen byggs upp från samma poster som finansavdelningen läser.
Det kan det, med jurisdiktionens uppgifter som skickas till Acumatica bredvid var och en. Alumio bokför en Stripe-betalning allt eftersom den godkänns med plats och skattebelopp bifogat, bokför avgiften separat och återför mot den ursprungliga posten när en återbetalning utfärdas. Att bokföra uppgifterna vid tidpunkten är det som tar bort rekonstruktionen vid periodens slut, eftersom ingenting behöver härledas från ett datum och en totalsumma. De tillgängliga posterna är de som Acumatica exponerar.
Nej, detta är konfigurerat snarare än kodat. Avgiftsjournalen som någon skriver varje månad följer med, tillsammans med kalkylbladet som mappar försäljning till jurisdiktioner. Vilka Stripe-värden som bokförs till vilka Acumatica-konton, och hur en faktureringsadress kopplas till en skattemyndighet, är poster i Alumio. Där en avgift måste härledas snarare än läsas, utför Code Transformer den beräkningen.
Den myndighet som försäljningen gjordes till, vilket sällan är den som företaget befinner sig i. Stripe registrerar var köparen befann sig och Acumatica registrerar vad företaget är skyldigt, och reglerna som förenar dessa två tillhör någon helt annan. Det är den andra partens faktum snarare än plattformens, så den användbara designen är att inkludera tillräckligt med detaljer med varje betalning så att vilken regel som helst kan besvaras senare utan en rekonstruktion.
En avgift som bokförts utan den betalning den tillhörde är det fel som visas vid stängning, eftersom båda posterna är individuellt giltiga och endast parningen saknas. Alumio övervakar varje postning live och registrerar Stripe-referensen med Acumatica-posten som skapades, så ett belopp som inte kan paras ihop utlöser en varning som anger både och orsaken. Återförsök körs där de är konfigurerade, så ingenting går obokat.
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)
