Integrationer

Banken bestämmer oftast. Host-to-host-SFTP är den vanligast erbjudna kanalen för företags betalningsfiler. EBICS är vanligt hos banker i Tyskland, Frankrike och grannländer. Bank-API:er passar för saldon i realtid och omedelbara betalningar där banken erbjuder dem. Många företag använder mer än en kanal, och integrationslagret döljer skillnaden för ERP-systemet.

Läs mer: Betalningsfiler och avstämning mellan ERP och bankLänk till den här frågan

Där banken erbjuder båda innehåller camt.053 rikare, strukturerad betalningsinformation, vilket gör automatisk matchning mer tillförlitlig. MT940 används fortfarande brett och fungerar bra i många fall. Vi kan ta emot båda, omvandla dem till samma interna modell och flytta varje bank från MT940 till camt.053 när det passar dig och banken.

Läs mer: Betalningsfiler och avstämning mellan ERP och bankLänk till den här frågan

Vanligen som händelser nära realtid, eftersom lager- och försäljningssiffrorna då är aktuella under dagen. Vissa ERP-system eller licenser gör täta bokföringar kostsamma, så lagret kan också gruppera händelser till sammanställningar per butik och period. Vi väljer tillsammans utifrån vilka beslut som behöver aktuell data och vad ERP-systemet hanterar väl.

Läs mer: Synkronisering av försäljning, lager och priser mellan POS och ERPLänk till den här frågan

Designen fungerar med alla POS-system som kan exportera transaktioner via API, händelser eller filer, och med ERP-system som SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365 Business Central och Odoo. Vi bekräftar gränssnitten i ditt specifika POS- och ERP-system i början. Att ett produktnamn nämns betyder inte att vi är partner med leverantören.

Läs mer: Synkronisering av försäljning, lager och priser mellan POS och ERPLänk till den här frågan

Acquirern är banken eller den licensierade institution som hanterar kortbetalningar åt dig och betalar ut pengarna. Gatewayen är den tekniska tjänsten framför som tar emot begäranden från terminaler och kassor, tokeniserar kort och dirigerar dem. Vissa leverantörer är båda. Designen fungerar oavsett och håller de två rollerna åtskilda.

Läs mer: KortbetalningarLänk till den här frågan

Nej. ISO 8583 definierar en struktur, och varje acquirer eller nätverk publicerar sin egen specifikation av fält, meddelandetyper och koder. Därför bygger vi utifrån acquirerns specifikation och kör dennes certifieringstester. Ett gateway-API framför acquirern döljer dessa skillnader, vilket ofta är enklare för detaljhandeln.

Läs mer: KortbetalningarLänk till den här frågan

En aggregator ger många banker genom ett API och hanterar skillnaderna mellan dem, till en kostnad per anrop eller per koppling. Direkta kopplingar ger mer kontroll och kan passa ett litet antal viktiga banker. Många produkter börjar med en aggregator och lägger till direkta kopplingar senare. Vi jämför alternativen mot de banker och länder du behöver.

Läs mer: API:er för open bankingLänk till den här frågan

Täckningen beror på reglerna i regionen och bankernas API:er. Europeiska unionen och Storbritannien har bred täckning enligt PSD2 och UK Open Banking Standard. På andra håll varierar täckningen, och aggregatorer fyller en del av luckorna. Vi kontrollerar täckningen för de banker dina kunder använder innan du binder dig till en design.

Läs mer: API:er för open bankingLänk till den här frågan

Inte för det mesta av företagens treasuryarbete. Host-to-host-kanaler hanterar betalningsfiler i bulk och fullständiga kontoutdrag för de egna kontona. Open banking passar kundvända produkter, saldon i realtid och enstaka betalningar. Många företag använder båda: host-to-host för sina egna betalningskörningar och open banking för sina kunder.

Läs mer: API:er för open bankingLänk till den här frågan

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.

Läs mer: Kopplingar mellan ERP och tredje partLänk till den här frågan

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.

Läs mer: Kopplingar mellan ERP och tredje partLänk till den här frågan

På ERP-sidan: SAP ECC, S/4HANA och BTP, Oracle Fusion Cloud ERP och NetSuite, Microsoft Dynamics 365, Odoo och Sage. För arbetsflöden och CRM: ServiceNow, Salesforce och Microsoft Power Platform. Vi arbetar också med anpassade och äldre system. Att ett system nämns betyder inte att vi har ett partnerskap med leverantören.

Läs mer: Införande och synkronisering av ERP och CRMLänk till den här frågan

Ja. Vi inventerar varje gränssnitt i ECC, avgör vilka som ska behållas, byggas om eller avvecklas och flyttar var och en till S/4HANA eller BTP med sina tester. Flödena växlar över ett i taget, så att verksamheten inte hänger på en enda övergångshelg.

Läs mer: Införande och synkronisering av ERP och CRMLänk till den här frågan

Inte alltid. Några stabila flöden mellan två system kan vara direkta API-anrop. När flera system utbyter data, eller du behöver mappning, köer och övervakning på ett ställe, lönar sig mellanprogramvara oftast. Om du redan har en bygger vi vidare på den.

Läs mer: Införande och synkronisering av ERP och CRMLänk till den här frågan

Välj det som passar dina processer, integrationer och användare. Vi jämför alternativen mot dina krav, befintliga licenser och de system CRM:t måste kopplas till och redogör skriftligt för avvägningarna. Om du redan har ett CRM granskar vi först dess uppsättning, data och integrationer, eftersom problem där är vanligare än begränsningar i produkten.

Läs mer: Införande och synkronisering av ERP och CRMLänk till den här frågan

För mycket är när uppgraderingarna blir riskfyllda och varje ändring kräver en utvecklare. Vi konfigurerar det plattformen erbjuder först och bygger anpassad kod bara där din process behöver det och det är värt att underhålla. Varje anpassad funktion dokumenteras och testas, så att uppgraderingarna förblir hanterbara.

Läs mer: Införande och synkronisering av ERP och CRMLänk till den här frågan

Fas 2, integrationsfasen, kräver att de skattskyldigas system ansluts till ZATCAs plattform FATOORA. Standardfakturor godkänns av ZATCA innan de når köparen, och förenklade fakturor rapporteras strax efter. Varje faktura bär en kryptografisk stämpel och en QR-kod, så ERP- eller POS-systemet måste ta fram dem i det format som krävs.

Läs mer: E-fakturering, skatt och digitala produktpassLänk till den här frågan

PINT-AE är Förenade Arabemiratens specifikation av det internationella PEPPOL-formatet för fakturor, som används i landets program för e-fakturering. Fakturor utbyts i detta strukturerade format via ackrediterade tjänsteleverantörer och rapporteras till Federal Tax Authority, vars plattform EmaraTax hanterar skatt i landet.

Läs mer: E-fakturering, skatt och digitala produktpassLänk till den här frågan

VAT in the Digital Age (ViDA) är EU:s paket som flyttar gränsöverskridande företagsfakturering till strukturerade e-fakturor och digital rapportering. Det påverkar varje verksamhet som fakturerar EU-kunder eller har enheter i EU, oavsett var huvudkontoret ligger.

Läs mer: E-fakturering, skatt och digitala produktpassLänk till den här frågan

Ett digitalt produktpass (DPP) är EU:s register över en produkts material, ursprung, reparerbarhet och återvinning, delat via en databärare som en QR-kod. Det införs stegvis per produktgrupp. Det bygger på leveranskedjedata som oftast finns i ERP- och tillverkningssystem.

Läs mer: E-fakturering, skatt och digitala produktpassLänk till den här frågan

Ofta är tillägget rätt utgångspunkt, och vi konfigurerar och bygger ut det i stället för att bygga runt det. Det arbete som återstår handlar vanligen om datan: fakturatyper, skattekoder, masterdata och undantag som tillägget inte täcker. POS-system och andra system som också utfärdar fakturor behöver också kopplas.

Läs mer: E-fakturering, skatt och digitala produktpassLänk till den här frågan

Ja. Vi bygger ett integrationslager med en koppling per krav. ERP-systemet tar fram en faktura, och lagret formaterar, signerar och skickar in den för varje land. Att lägga till ett land blir konfiguration, mappning och tester.

Läs mer: E-fakturering, skatt och digitala produktpassLänk till den här frågan

ISO 20022 är den internationella standarden för finansiella meddelanden. Standardens XML-meddelanden bär strukturerad data, som fullständiga namn, adresser och betalningsreferenser, som de äldre SWIFT MT-formaten inte klarar. Banker och betalningssystem har gått över till den, så betalnings- och kontoutdragsfiler som bygger på den stäms av bättre och klarar efterlevnadskontroller oftare.

Läs mer: Bank, treasury och ISO 20022-konnektivitetLänk till den här frågan

Vi använder pain.001 för betalningar, pain.002 för status, camt.052, camt.053 och camt.054 för rapporter om konton och pacs-meddelanden mellan banker. Vi läser också MT940- och MT942-utdrag som många banker fortfarande skickar. Transporten är host-to-host via SFTP, EBICS, SWIFT eller bank-API:er. Varje bank har sin egen variant av varje format, så vi bygger utifrån dess implementeringsguide.

Läs mer: Bank, treasury och ISO 20022-konnektivitetLänk till den här frågan

SAP S/4HANA, Oracle Fusion Cloud ERP och NetSuite, Microsoft Dynamics 365, Odoo och Sage, liksom treasury- och egenutvecklade system. När ERP-systemet har en egen modul för bankkommunikation konfigurerar och bygger vi ut den i stället för att bygga runt den.

Läs mer: Bank, treasury och ISO 20022-konnektivitetLänk till den här frågan

Ja, där acquirern eller processorn erbjuder det. ISO 8583 är ett ramverk snarare än ett enda format: varje acquirer publicerar sin egen specifikation av fält och meddelandetyper. Vi bygger utifrån den specifikationen, hanterar auktoriseringar, återföringar och advice-meddelanden och testar varje svarskod.

Läs mer: Betalningar, agentisk handel (AP2) och POSLänk till den här frågan

Agent Payments Protocol (AP2) är ett öppet protokoll för betalningar som AI-agenter gör. Varje köp bär signerade mandat som visar vad kunden godkände, så att handlare, kortutgivare och acquirers kan lita på och granska det. Om AI-agenter sannolikt kommer att handla hos dig kan vi göra din kassa AP2-redo vid sidan av dina nuvarande flöden.

Läs mer: Betalningar, agentisk handel (AP2) och POSLänk till den här frågan

Ja, med SoftPOS. Kontaktlösa kort och plånböcker tas emot i en telefon eller surfplatta som stöds, via en certifierad betalapp från din acquirer eller leverantör. Vi integrerar appen med dina POS-, försäljnings- och avräkningsflöden som vilken terminal som helst.

Läs mer: Betalningar, agentisk handel (AP2) och POSLänk till den här frågan

Butiken fortsätter sälja. Försäljningen lagras lokalt och skickas till ERP-systemet när anslutningen är tillbaka, varje post med en unik identifierare så att inget bokförs två gånger. Om kortbetalningar kan fortsätta offline beror på acquirerns regler och din riskaptit, och det utformar vi tillsammans med dig.

Läs mer: Betalningar, agentisk handel (AP2) och POSLänk till den här frågan

Det beror på hur många anslutningar du har och vem som ska drifta dem. En integrationsplattform som MuleSoft, Boomi eller Azure Logic Apps ger färdiga kopplingar, mappning och övervakning på ett ställe, till en licenskostnad. Egna tjänster ger full kontroll och ingen licens, men mer kod att underhålla. Vi jämför båda för ditt fall.

Läs mer: Mellanprogramvara och API-integrationLänk till den här frågan

En enterprise service bus dirigerar och transformerar meddelanden genom en central hubb. Ett event mesh distribuerar händelser genom ett nät av sammankopplade brokers, så att system i olika moln och på olika platser publicerar och prenumererar direkt. Många miljöer kör båda medan de går från det ena till det andra.

Läs mer: Mellanprogramvara och API-integrationLänk till den här frågan

Vi utformar utifrån varje partners publicerade gränser. Vi slår ihop anrop där API:et tillåter det, cachar data som sällan ändras, sprider ut schemalagda jobb och minskar takten när en gräns närmar sig. Övervakningen visar hur nära varje flöde ligger sin gräns.

Läs mer: Mellanprogramvara och API-integrationLänk till den här frågan