Integrationer

Det bestemmer banken som regel. Host-to-host-SFTP er den mest udbredte kanal til virksomheders betalingsfiler. EBICS er almindeligt hos banker i Tyskland, Frankrig og nabolandene. Bank-API’er passer til saldi i realtid og øjeblikkelige betalinger, hvor banken tilbyder dem. Mange virksomheder bruger mere end én, og integrationslaget skjuler forskellen for ERP-systemet.

Læs mere: Betalingsfiler og afstemning fra ERP til bankLink til dette spørgsmål

Hvor banken tilbyder begge dele, indeholder camt.053 rigere, strukturerede betalingsoplysninger, hvilket gør automatisk afstemning mere pålidelig. MT940 er stadig udbredt og fungerer godt i mange tilfælde. Vi kan modtage begge, konvertere dem til den samme interne model og flytte hver bank fra MT940 til camt.053, når det passer dig og banken.

Læs mere: Betalingsfiler og afstemning fra ERP til bankLink til dette spørgsmål

Normalt som hændelser tæt på realtid, fordi lager- og salgstal så er aktuelle i løbet af dagen. Nogle ERP-systemer eller licenser gør hyppige bogføringer dyre, så laget kan også samle hændelser i opsummeringer pr. butik og periode. Vi vælger sammen med dig ud fra, hvilke beslutninger der kræver aktuelle data, og hvad ERP-systemet håndterer godt.

Læs mere: Synkronisering af salg, lager og priser fra POS til ERPLink til dette spørgsmål

Designet fungerer med ethvert POS-system, der kan eksportere transaktioner via et API, hændelser eller filer, og med ERP-systemer som SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365 Business Central og Odoo. Vi bekræfter grænsefladerne i dit konkrete POS- og ERP-system fra starten. At vi nævner et produkt, betyder ikke et partnerskab med leverandøren.

Læs mere: Synkronisering af salg, lager og priser fra POS til ERPLink til dette spørgsmål

Indløseren er den bank eller det licenserede institut, der behandler kortbetalinger for dig og udbetaler pengene. Gatewayen er den tekniske service foran den, som modtager anmodninger fra terminaler og kasser, tokeniserer kort og dirigerer dem videre. Nogle udbydere er begge dele. Designet fungerer i begge tilfælde og holder de to roller klart adskilt.

Læs mere: KortbetalingerLink til dette spørgsmål

Nej. ISO 8583 definerer en struktur, og hver indløser eller hvert netværk udgiver sin egen specifikation af felter, meddelelsestyper og koder. Derfor bygger vi ud fra indløserens specifikation og kører dens certificeringstests. Et gateway-API foran indløseren skjuler disse forskelle, hvilket ofte er enklere for detailhandlere.

Læs mere: KortbetalingerLink til dette spørgsmål

En aggregator giver dig mange banker via ét API og håndterer forskellene mellem bankerne, til en pris pr. kald eller pr. forbindelse. Direkte forbindelser giver mere kontrol og kan passe til et lille antal vigtige banker. Mange produkter starter med en aggregator og tilføjer direkte forbindelser senere. Vi sammenligner mulighederne ud fra de banker og lande, du har brug for.

Læs mere: Open banking-API’erLink til dette spørgsmål

Dækningen afhænger af regionens regler og bankernes API’er. Den Europæiske Union og Storbritannien har bred dækning under PSD2 og UK Open Banking Standard. Andre steder varierer dækningen, og aggregatorer udfylder nogle af hullerne. Vi kontrollerer dækningen for de banker, dine kunder bruger, før du beslutter dig for et design.

Læs mere: Open banking-API’erLink til dette spørgsmål

Ikke for det meste af virksomhedernes treasuryarbejde. Host-to-host-kanaler håndterer bulkbetalingsfiler og fulde kontoudtog for dine egne konti. Open banking passer til kundevendte produkter, saldi i realtid og enkeltbetalinger. Mange virksomheder bruger begge dele: host-to-host til deres egne betalingskørsler og open banking til deres kunder.

Læs mere: Open banking-API’erLink til dette spørgsmål

Enhver service med et dokumenteret API eller en filgrænseflade. Typiske eksempler er CRM-platforme, transportører og logistikudbydere, markedspladser, platforme til e-fakturering og skat, lønsystemer, KYC- og identitetsudbydere og handelspartnere, der udveksler EDI-dokumenter via AS2. Vi gennemgår hver partners API, grænser og testmiljø, før vi forpligter os til en plan.

Læs mere: API-forbindelser fra ERP til tredjeparterLink til dette spørgsmål

Når flere partnere er forbundet med ét ERP-system, samler en platform som MuleSoft, Boomi eller Azure Logic Apps, eller et sæt specialudviklede services bygget på en beskedkø, mapping, gentagne forsøg og overvågning ét sted. Med en eller to partnere kan direkte forbindelser være nok. Vi beskriver fordele og ulemper, herunder licensomkostninger, i dit tilfælde.

Læs mere: API-forbindelser fra ERP til tredjeparterLink til dette spørgsmål

På ERP-siden: SAP ECC, S/4HANA og BTP, Oracle Fusion Cloud ERP og NetSuite, Microsoft Dynamics 365, Odoo og Sage. Til workflow og CRM: ServiceNow, Salesforce og Microsoft Power Platform. Vi arbejder også med specialudviklede og ældre systemer. At vi nævner et produkt, betyder ikke, at vi er partner med leverandøren.

Læs mere: Implementering og synkronisering af ERP og CRMLink til dette spørgsmål

Ja. Vi kortlægger hver grænseflade i ECC, beslutter, hvilke der skal bevares, genopbygges eller udfases, og flytter hver enkelt til S/4HANA eller BTP med dens tests. Flows skifter over ét ad gangen, så forretningen ikke afhænger af en enkelt weekend med overgang.

Læs mere: Implementering og synkronisering af ERP og CRMLink til dette spørgsmål

Ikke altid. Nogle få stabile flows mellem to systemer kan være direkte API-kald. Når flere systemer udveksler data, eller du har brug for mapping, køer og overvågning samlet ét sted, tjener middleware sig som regel hjem. Hvis du allerede har en, bygger vi videre på den.

Læs mere: Implementering og synkronisering af ERP og CRMLink til dette spørgsmål

Vælg det, der passer til dine processer, integrationer og brugere. Vi sammenligner mulighederne med dine krav, eksisterende licenser og de systemer, CRM-systemet skal forbindes med, og beskriver afvejningerne skriftligt. Hvis du allerede har et CRM-system, gennemgår vi først dets opsætning, data og integrationer, fordi problemer dér er mere almindelige end begrænsninger i produktet.

Læs mere: Implementering og synkronisering af ERP og CRMLink til dette spørgsmål

For meget er, når opgraderinger bliver risikable, og hver ændring kræver en udvikler. Vi konfigurerer først det, platformen tilbyder, og bygger kun specialudviklet kode, hvor din proces kræver det, og hvor det er værd at vedligeholde. Hver specialudviklet funktion er dokumenteret og testet, så opgraderinger forbliver til at håndtere.

Læs mere: Implementering og synkronisering af ERP og CRMLink til dette spørgsmål

Fase 2, integrationsfasen, kræver, at skatteydernes systemer forbindes med ZATCA’s platform FATOORA. Almindelige skattefakturaer godkendes af ZATCA, før de når køberen, og forenklede fakturaer indberettes kort efter. Hver faktura har et kryptografisk stempel og en QR-kode, så ERP- eller POS-systemet skal danne dem i det krævede format.

Læs mere: E-fakturering, skat og digitale produktpasLink til dette spørgsmål

PINT-AE er UAE’s specifikation af fakturaformatet PEPPOL International, som bruges i UAE’s e-faktureringsprogram. Fakturaer udveksles i dette strukturerede format gennem akkrediterede udbydere og indberettes til den føderale skattemyndighed, hvis platform EmaraTax håndterer skat i UAE.

Læs mere: E-fakturering, skat og digitale produktpasLink til dette spørgsmål

VAT in the Digital Age (ViDA) er EU’s pakke, der flytter grænseoverskridende fakturering mellem virksomheder over på strukturerede e-fakturaer og digital indberetning. Den berører enhver virksomhed, der fakturerer kunder i EU eller driver juridiske enheder i EU, uanset hvor hovedkontoret ligger.

Læs mere: E-fakturering, skat og digitale produktpasLink til dette spørgsmål

Et digitalt produktpas (DPP) er EU’s registrering af et produkts materialer, oprindelse, reparerbarhed og genanvendelse, delt via en databærer såsom en QR-kode. Det indfases produktgruppe for produktgruppe og afhænger af data fra forsyningskæden, som normalt ligger i ERP- og produktionssystemer.

Læs mere: E-fakturering, skat og digitale produktpasLink til dette spørgsmål

Ofte er tilføjelsesmodulet det rigtige udgangspunkt, og vi konfigurerer og udvider det i stedet for at bygge uden om det. Det arbejde, der er tilbage, handler som regel om data: fakturatyper, momskoder, stamdata og undtagelser, som modulet ikke dækker. POS og andre systemer, der også udsteder fakturaer, skal også forbindes.

Læs mere: E-fakturering, skat og digitale produktpasLink til dette spørgsmål

Ja. Vi bygger ét integrationslag med en konnektor pr. lovkrav. ERP-systemet danner én faktura, og laget formaterer, signerer og indsender den for hvert land. Et nyt land bliver et spørgsmål om konfiguration, mapping og test.

Læs mere: E-fakturering, skat og digitale produktpasLink til dette spørgsmål

ISO 20022 er den internationale standard for finansielle meddelelser. Dens XML-meddelelser indeholder strukturerede data, såsom fulde navne, adresser og betalingsoplysninger, som de ældre SWIFT MT-formater ikke kan rumme. Banker og betalingssystemer er gået over til den, så betalingsfiler og kontoudtog, der bygger på den, afstemmes bedre og består compliancekontroller oftere.

Læs mere: Bank, treasury og ISO 20022-forbindelserLink til dette spørgsmål

Vi bruger pain.001 til betalinger, pain.002 til status, camt.052, camt.053 og camt.054 til kontorapporter og pacs-meddelelser mellem banker. Vi læser også de MT940- og MT942-kontoudtog, som mange banker stadig sender. Transporten sker via host-to-host SFTP, EBICS, SWIFT eller bank-API’er. Hver bank har sin egen variant af hvert format, så vi bygger ud fra dens implementeringsvejledning.

Læs mere: Bank, treasury og ISO 20022-forbindelserLink til dette spørgsmål

SAP S/4HANA, Oracle Fusion Cloud ERP og NetSuite, Microsoft Dynamics 365, Odoo og Sage samt treasurysystemer og specialudviklede systemer. Hvor ERP-systemet har sit eget bankkommunikationsmodul, konfigurerer og udvider vi det i stedet for at bygge uden om det.

Læs mere: Bank, treasury og ISO 20022-forbindelserLink til dette spørgsmål

Ja, hvor indløseren eller processoren tilbyder det. ISO 8583 er en ramme snarere end ét format: hver indløser udgiver sin egen specifikation af felter og meddelelsestyper. Vi bygger ud fra den specifikation, håndterer autorisationer, tilbageførsler og advice-meddelelser og tester hver svarkode.

Læs mere: Betalinger, agentisk handel (AP2) og POSLink til dette spørgsmål

Agent Payments Protocol (AP2) er en åben protokol for betalinger foretaget af AI-agenter. Hvert køb har signerede mandater, der viser, hvad kunden har godkendt, så forretninger, udstedere og indløsere kan stole på købet og revidere det. Hvis AI-agenter sandsynligvis vil handle hos dig, kan vi gøre din checkout AP2-klar ved siden af dine nuværende flows.

Læs mere: Betalinger, agentisk handel (AP2) og POSLink til dette spørgsmål

Ja, med SoftPOS. Kontaktløse kort og digitale tegnebøger modtages på en understøttet telefon eller tablet via en certificeret betalingsapp fra din indløser eller udbyder. Vi integrerer appen med dine POS-, salgs- og afregningsflows som enhver anden terminal.

Læs mere: Betalinger, agentisk handel (AP2) og POSLink til dette spørgsmål

Butikken bliver ved med at sælge. Salg gemmes lokalt og sendes til ERP-systemet, når forbindelsen er tilbage, hvert med en unik identifikator, så intet bogføres to gange. Om kortbetalinger kan fortsætte offline, afhænger af din indløsers regler og din risikovillighed, og det designer vi sammen med dig.

Læs mere: Betalinger, agentisk handel (AP2) og POSLink til dette spørgsmål

Det afhænger af, hvor mange forbindelser du har, og hvem der skal drive dem. En integrationsplatform som MuleSoft, Boomi eller Azure Logic Apps giver dig færdige konnektorer, mapping og overvågning ét sted, mod en licensomkostning. Specialudviklede services giver dig fuld kontrol og ingen licens, men mere kode at vedligeholde. Vi sammenligner begge løsninger i din situation.

Læs mere: Middleware og API-integrationLink til dette spørgsmål

En enterprise service bus dirigerer og transformerer beskeder gennem en central hub. Et event mesh fordeler hændelser gennem et netværk af forbundne brokere, så systemer i forskellige cloudmiljøer og på forskellige lokationer udgiver og abonnerer direkte. Mange systemlandskaber kører begge dele, mens de går fra det ene til det andet.

Læs mere: Middleware og API-integrationLink til dette spørgsmål

Vi designer ud fra hver partners offentliggjorte grænser. Vi samler anmodninger i batches, hvor API’et tillader det, cacher data, der sjældent ændres, spreder planlagte jobs og sænker tempoet, når en grænse nærmer sig. Overvågningen viser, hvor tæt hvert flow kører på sin grænse.

Læs mere: Middleware og API-integrationLink til dette spørgsmål