Kopplingar mellan ERP och tredje part
ERP till tredje part: CRM, logistik, skatt och identitet
REST-, SOAP-, webhook- och iPaaS-kopplingar mellan ditt ERP-system och tjänsterna runt omkring, med nya försök och larm.
Ritning
Rulla i sidled för att se hela ritningen.
ERP till tredje parter: en plattform, många partner
Affärshändelser lämnar ERP en gång och integrationsplattformen levererar dem till varje partner i det format den förväntar sig. Callbacks kommer tillbaka samma väg. Ett meddelande som fortfarande misslyckas efter sina nya försök hamnar i en dead-letter-kö och utlöser ett larm med nyttolasten bifogad.
- Primärt flöde
- Asynkront
- Undantagsväg
Flödet i 9 steg
Flödet, steg för steg
- Från ERP till Integrationsplattform: Affärshändelser, över REST · OData · webhook (primärt flöde).
- Från Integrationsplattform till CRM: Kunder och order, över REST/JSON (primärt flöde).
- Från Integrationsplattform till Logistik och transportörer: Sändningar bokade, över REST/JSON (primärt flöde).
- Från Logistik och transportörer till Integrationsplattform: Spårningshändelser, över webhook (asynkront).
- Från Integrationsplattform till E-fakturerings- och skatteplattform: Fakturor för godkännande, över SOAP/XML · REST (primärt flöde).
- Från Integrationsplattform till KYC- och identitetsleverantör: Identitetskontroller, över REST/JSON (primärt flöde).
- Från KYC- och identitetsleverantör till Integrationsplattform: Kontrollresultat, över webhook (asynkront).
- Från Integrationsplattform till Dead-letter-kö och larm: Misslyckades efter nya försök, till en dead-letter-kö (undantagsväg).
- Från Dead-letter-kö och larm till Supportteam: Larm med nyttolast och fel (undantagsväg).
Översikt
Det här är flödet mellan ditt ERP-system och tjänsterna runt omkring: CRM, transportörer och logistikleverantörer, plattformar för e-fakturering och skatt samt leverantörer av identitet och KYC. Varje partner har sitt eget API, sitt eget format och sina egna fel, och varje koppling brukar bli ett eget projekt.
Referensdesignen skickar affärshändelser ut ur ERP-systemet en gång, till en integrationsplattform som levererar dem till varje partner i det format partnern förväntar sig, via REST, SOAP, webhooks eller EDI över AS2 där handelspartnerna kräver det. Återanrop, som spårningshändelser eller kontrollresultat, kommer tillbaka genom samma plattform.
Att en partner ligger nere är en normal händelse, inte en kris. Tillfälliga fel görs om. Ett meddelande som fortfarande misslyckas efter sina nya försök hamnar i en dead-letter-kö, och ett larm når supportteamet med innehållet och felet, så att det kan rättas och spelas upp igen.
Så fungerar flödet
ERP-systemet publicerar en händelse
När en kund, en order eller en faktura ändras publicerar ERP-systemet en affärshändelse till integrationsplattformen, via sitt API, OData-tjänster eller webhooks.
CRM hålls uppdaterat
Plattformen uppdaterar konton, kontakter och ordrar i CRM, så att sälj- och service team ser det ERP-systemet vet.
Sändningar bokas
Ordrar som är klara att skicka bokas hos transportören eller logistikleverantören via deras API, och etiketter och referenser kommer tillbaka.
Spårning kommer tillbaka
Transportören skickar spårnings- och leveransbekräftelser via webhook, och plattformen uppdaterar ordern i ERP-systemet.
Fakturor godkänns
Fakturor skickas till plattformen för e-fakturering eller skatt i det format myndigheten kräver, och godkännandestatusen sparas med fakturan.
Identiteter kontrolleras
Nya kunder eller leverantörer skickas till leverantören av KYC eller identitet, och resultatet kommer tillbaka via webhook innan kontot aktiveras.
När något går fel
En partner är tillfälligt otillgänglig
Anropet görs om med ökande väntetider. En idempotensnyckel på varje skrivning gör att ett nytt försök aldrig skapar en andra sändning eller faktura.
Ett meddelande misslyckas även efter nya försök
Det hamnar i en dead-letter-kö med innehållet och partnerns fel, och supportteamet larmas. När felet är rättat spelas meddelandet upp igen från kön.
En partner ändrar sitt API
Kontraktstester körs mot varje partners testmiljö och fångar ändringen. Aviserade ändringar schemaläggs och testas före partnerns deadline.
Datan avvisas
En partner som avvisar data av affärsskäl, som ett saknat skattenummer, skickar felet tillbaka till ERP-posten, där ägaren kan rätta det.
Standarder och system
- Integration
- REST
- SOAP
- Webhooks
- OpenAPI
- EDI (EDIFACT, ANSI X12)
- AS2
- MuleSoft
- Boomi
- Azure Logic Apps
- Identitet och åtkomst
- OAuth 2.0
Frågor och svar
Vilka tjänster från tredje part kan kopplas in?
Vilken tjänst som helst med dokumenterat API eller filgränssnitt. Typiska exempel är CRM-plattformar, transportörer och logistikleverantörer, marknadsplatser, plattformar för e-fakturering och skatt, lönesystem, leverantörer av KYC och identitet samt handelspartner som utbyter EDI-dokument över AS2. Vi granskar varje partners API, gränser och testmiljö innan vi binder oss till en plan.
Behövs en integrationsplattform för det här?
När flera partner är kopplade till ett och samma ERP-system håller en plattform som MuleSoft, Boomi eller Azure Logic Apps, eller en uppsättning egna tjänster på en meddelandekö, mappning, nya försök och övervakning på ett ställe. Med en eller två partner kan direkta kopplingar räcka. Vi redovisar avvägningarna, inklusive licenskostnader, för ditt fall.
Går det att ansluta till plattformar för e-fakturering och skattegodkännande?
Ja. Många länder kräver nu att fakturor utfärdas eller godkänns via en myndighetsplattform eller ackrediterad plattform i ett bestämt format. Vi integrerar ERP-systemet med den plattform ditt land kräver eller med en ackrediterad leverantör, sparar godkännandestatus och identifierare med varje faktura och hanterar avvisningar. Dina skatterådgivare bekräftar vilka regler som gäller för dig.
Hur säkras inkommande webhooks?
Varje inkommande webhook verifieras innan den behandlas: med signatur där partnern signerar sina meddelanden, och med kontroll av token, källa och tidsstämpel där den inte gör det. Innehållet valideras mot kontraktet, och händelser behandlas en gång även om partnern skickar dem flera gånger.
Vad händer när en partner har ett avbrott?
Resten av flödena fortsätter att köra. Meddelanden till den partnern görs om och köas sedan, supportteamet larmas och inget går förlorat. När partnern är tillbaka spelas köade meddelanden upp i ordning. Instrumentpanelen visar vilken partner som berörs och hur många meddelanden som väntar.
Vem äger kopplingarna som byggs?
Immateriella rättigheter till det arbete vi bygger för dig är dina från första commit, utan något överlåtelsesteg på slutet. Kopplingar levereras med källkod, tester och dokumentation, så att ditt team eller en annan leverantör kan förvalta dem. Verktyg från XSIS som fanns före projektet förblir våra och licensieras till dig. Partner-API:er och licenser för integrationsplattformen omfattas fortfarande av leverantörernas egna villkor.
Börja med ett samtal, inte ett avtal.
Berätta vad du behöver bygga, koppla samman eller skydda. En arkitekt går igenom det med dig och rekommenderar sedan var du ska börja.
Vad som händer härnäst
Vi enas om en tid
Vårt team mejlar dig för att enas om en tid för samtalet.
Förberedande samtal
En kostnadsfri förkonsultation online i 30 minuter: vi går igenom dina mål, system och begränsningar.
Mognadsgenomgång
I en kostnadsfri mognadsgenomgång på 48 timmar prövar en ledande arkitekt ditt projekt mot de sex kriterierna för Definition of Ready och rekommenderar det spår som passar.
Val av spår
Projekt med tydlig omfattning får ett bindande förslag inom 3 till 5 arbetsdagar. Projekt i konceptfasen börjar i Blueprint Studio. Ett system i drift som fallerar, är odokumenterat eller behöver integreras börjar med en diagnostik på 1 till 2 veckor. Blueprint Studio och diagnostiken har var sitt fasta pris som anges i förslaget.