Integrasjoner

Banken bestemmer vanligvis. Host-to-host over SFTP er den mest utbredte kanalen for bedrifters betalingsfiler. EBICS er vanlig hos banker i Tyskland, Frankrike og nabolandene. Bank-API-er passer for sanntidssaldo og sanntidsbetalinger der banken tilbyr det. Mange selskaper bruker mer enn én, og integreringslaget skjuler forskjellen for ERP-systemet.

Les mer: Betalingsfiler og avstemming mellom ERP og bankLenke til dette spørsmålet

Der banken tilbyr begge, har camt.053 rikere strukturerte remitteringsopplysninger, som gjør automatisk avstemming mer pålitelig. MT940 er fortsatt mye brukt og fungerer godt i mange tilfeller. Vi kan ta imot begge, konvertere dem til samme interne modell og flytte hver bank fra MT940 til camt.053 når det passer deg og banken.

Les mer: Betalingsfiler og avstemming mellom ERP og bankLenke til dette spørsmålet

Vanligvis som hendelser nær sanntid, fordi lager- og salgstall da er oppdaterte i løpet av dagen. Enkelte ERP-er eller lisenser gjør hyppige posteringer kostbare, så laget kan også gruppere hendelser i sammendrag per butikk og periode. Vi velger sammen med deg ut fra hvilke beslutninger som trenger oppdaterte data, og hva ERP-en håndterer godt.

Les mer: Synkronisering av salg, lager og priser fra POS til ERPLenke til dette spørsmålet

Løsningen fungerer med alle POS-systemer som kan eksportere transaksjoner via et API, hendelser eller filer, og med ERP-er som SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365 Business Central og Odoo. Vi bekrefter grensesnittene til din POS og ERP i starten. At et produkt nevnes, betyr ikke at det er et partnerskap med leverandøren.

Les mer: Synkronisering av salg, lager og priser fra POS til ERPLenke til dette spørsmålet

Innløseren er banken eller den konsesjonsbelagte institusjonen som behandler kortbetalinger for deg og utbetaler pengene. Betalingsgatewayen er den tekniske tjenesten foran som tar imot forespørsler fra terminaler og kasser, tokeniserer kort og ruter dem. Noen leverandører er begge. Designet fungerer uansett og holder de to rollene tydelig atskilt.

Les mer: KortbetalingerLenke til dette spørsmålet

Nei. ISO 8583 definerer en struktur, og hver innløser eller kortnettverk publiserer sin egen spesifikasjon av felt, meldingstyper og koder. Derfor bygger vi ut fra innløserens spesifikasjon og kjører sertifiseringstestene deres. En gateway-API foran innløseren skjuler disse forskjellene, noe som ofte er enklere for detaljhandelen.

Les mer: KortbetalingerLenke til dette spørsmålet

En aggregator gir deg mange banker gjennom ett API og håndterer forskjellene mellom bankene, til en kostnad per kall eller per tilkobling. Direkte tilkoblinger gir mer kontroll og kan passe for et lite antall viktige banker. Mange produkter starter med en aggregator og legger til direkte tilkoblinger senere. Vi sammenligner alternativene mot bankene og landene du trenger.

Les mer: Open banking-API-erLenke til dette spørsmålet

Dekningen avhenger av reglene i regionen og bankenes API-er. EU og Storbritannia har bred dekning under PSD2 og UK Open Banking Standard. Andre steder varierer dekningen, og aggregatorer fyller noen av hullene. Vi sjekker dekningen for bankene kundene dine bruker før du bestemmer deg for en løsning.

Les mer: Open banking-API-erLenke til dette spørsmålet

Ikke for det meste av treasury-arbeidet i bedrifter. Host-to-host-kanaler håndterer store betalingsfiler og fullstendige kontoutskrifter for egne kontoer. Open banking passer for kundevendte produkter, sanntidssaldoer og enkeltbetalinger. Mange virksomheter bruker begge: host-to-host for egne betalingskjøringer og open banking for kundene sine.

Les mer: Open banking-API-erLenke til dette spørsmålet

Enhver tjeneste med et dokumentert API eller filgrensesnitt. Typiske eksempler er CRM-plattformer, transportører og logistikkleverandører, markedsplasser, e-fakturering og avgiftsplattformer, lønn, KYC og identitetsleverandører, og handelspartnere som utveksler EDI-dokumenter over AS2. Vi gjennomgår hver partners API, grenser og testmiljø før vi forplikter oss til en plan.

Les mer: API-tilkoblinger fra ERP-systemet til tredjeparterLenke til dette spørsmålet

Når flere partnere er koblet til ett ERP-system, holder en plattform som MuleSoft, Boomi eller Azure Logic Apps, eller et sett med skreddersydde tjenester bygget på en meldingskø, mapping, nye forsøk og overvåking på ett sted. Med én eller to partnere kan direkte tilkoblinger være nok. Vi legger frem avveiningene, inkludert lisenskostnader, for din situasjon.

Les mer: API-tilkoblinger fra ERP-systemet til tredjeparterLenke til dette spørsmålet

På ERP-siden: SAP ECC, S/4HANA og BTP, Oracle Fusion Cloud ERP og NetSuite, Microsoft Dynamics 365, Odoo og Sage. For arbeidsflyt og CRM: ServiceNow, Salesforce og Microsoft Power Platform. Vi arbeider også med skreddersydde og eldre systemer. Å nevne et produkt betyr ikke et partnerskap med leverandøren.

Les mer: Implementering og synkronisering av ERP og CRMLenke til dette spørsmålet

Ja. Vi kartlegger hvert grensesnitt på ECC, avgjør hvilke som skal beholdes, bygges på nytt eller avvikles, og flytter hvert av dem til S/4HANA eller BTP med testene sine. Flytene skiftes over én om gangen, slik at virksomheten ikke er avhengig av én helg med overgang.

Les mer: Implementering og synkronisering av ERP og CRMLenke til dette spørsmålet

Ikke alltid. Noen få stabile flyter mellom to systemer kan være direkte API-kall. Når flere systemer utveksler data, eller du trenger mapping, køer og overvåking på ett sted, lønner middleware seg vanligvis. Har du allerede en, bygger vi på den.

Les mer: Implementering og synkronisering av ERP og CRMLenke til dette spørsmålet

Velg det som passer prosessene, integrasjonene og brukerne dine. Vi sammenligner alternativene mot kravene dine, eksisterende lisenser og systemene CRM-systemet må kobles til, og legger avveiningene frem skriftlig. Har du allerede et CRM-system, går vi gjennom oppsettet, dataene og integrasjonene først, fordi problemer der er vanligere enn begrensninger i produktet.

Les mer: Implementering og synkronisering av ERP og CRMLenke til dette spørsmålet

For mye er når oppgraderinger blir risikable og hver endring krever en utvikler. Vi konfigurerer det plattformen tilbyr først, og bygger skreddersydd kode bare der prosessen din trenger det og det er verdt å vedlikeholde. Hver skreddersydde funksjon dokumenteres og testes, så oppgraderingene forblir håndterbare.

Les mer: Implementering og synkronisering av ERP og CRMLenke til dette spørsmålet

Fase 2, integrasjonsfasen, krever at skattebetaleres systemer kobles til ZATCAs FATOORA-plattform. Standard skattefakturaer godkjennes av ZATCA før de når kjøperen, og forenklede fakturaer rapporteres kort tid etter. Hver faktura har et kryptografisk stempel og en QR-kode, så ERP-systemet eller POS-systemet må produsere dem i riktig format.

Les mer: E-fakturering, skatt og digitale produktpassLenke til dette spørsmålet

PINT-AE er De forente arabiske emiraters spesifikasjon av PEPPOLs internasjonale fakturaformat, brukt i landets e-faktureringsprogram. Fakturaer utveksles i dette strukturerte formatet gjennom akkrediterte tjenesteleverandører og rapporteres til Federal Tax Authority, hvis EmaraTax-plattform håndterer skatt i De forente arabiske emirater.

Les mer: E-fakturering, skatt og digitale produktpassLenke til dette spørsmålet

VAT in the Digital Age (ViDA) er EUs pakke som flytter fakturering på tvers av landegrenser til strukturerte e-fakturaer og digital rapportering. Den påvirker alle virksomheter som fakturerer EU-kunder eller driver EU-enheter, uansett hvor hovedkontoret ligger.

Les mer: E-fakturering, skatt og digitale produktpassLenke til dette spørsmålet

Et Digital Product Passport (DPP) er EUs registrering av et produkts materialer, opprinnelse, reparerbarhet og gjenvinning, delt via en databærer som en QR-kode. Det innføres gradvis per produktgruppe. Det avhenger av forsyningskjedens data, som vanligvis ligger i ERP- og produksjonssystemer.

Les mer: E-fakturering, skatt og digitale produktpassLenke til dette spørsmålet

Ofte er tillegget riktig utgangspunkt, og vi konfigurerer og utvider det i stedet for å bygge rundt det. Det som gjenstår, er vanligvis dataene: fakturatypene, skattekodene, masterdataene og unntakene tillegget ikke dekker. POS-systemer og andre systemer som også utsteder fakturaer, må også kobles til.

Les mer: E-fakturering, skatt og digitale produktpassLenke til dette spørsmålet

Ja. Vi bygger ett integreringslag med én kobling per mandat. ERP-systemet produserer én faktura, og laget formaterer, signerer og sender den inn for hvert land. Å legge til et land blir konfigurasjon, mapping og tester.

Les mer: E-fakturering, skatt og digitale produktpassLenke til dette spørsmålet

ISO 20022 er den internasjonale standarden for finansielle meldinger. XML-meldingene bærer strukturerte data, som fulle navn, adresser og betalingsinformasjon, som de eldre SWIFT MT-formatene ikke kan. Banker og betalingssystemer har gått over til den, så betalings- og kontoutskriftsfiler bygget på den avstemmes bedre og består etterlevelseskontroller oftere.

Les mer: Bank, treasury og ISO 20022-tilkoblingLenke til dette spørsmålet

Vi bruker pain.001 for betalinger, pain.002 for status, camt.052, camt.053 og camt.054 for kontoutskrifter, og pacs-meldinger mellom banker. Vi leser også MT940- og MT942-kontoutskrifter som mange banker fortsatt sender. Transport er host-to-host SFTP, EBICS, SWIFT eller bank-API-er. Hver bank har sin egen variant av hvert format, så vi bygger ut fra dens implementeringsveiledning.

Les mer: Bank, treasury og ISO 20022-tilkoblingLenke til dette spørsmålet

SAP S/4HANA, Oracle Fusion Cloud ERP og NetSuite, Microsoft Dynamics 365, Odoo og Sage, samt treasury og skreddersydde systemer. Der ERP-systemet har egen bankkommunikasjonsmodul, konfigurerer og utvider vi den i stedet for å bygge rundt den.

Les mer: Bank, treasury og ISO 20022-tilkoblingLenke til dette spørsmålet

Ja, der innløseren eller prosessoren tilbyr det. ISO 8583 er et rammeverk snarere enn ett format: hver innløser publiserer sin egen spesifikasjon av felt og meldingstyper. Vi bygger fra den spesifikasjonen, håndterer autorisasjoner, tilbakeføringer og advis-meldinger, og tester hver svarkode.

Les mer: Betalinger, agentisk handel (AP2) og POSLenke til dette spørsmålet

Agent Payments Protocol (AP2) er en åpen protokoll for betalinger utført av KI-agenter. Hvert kjøp har signerte mandater som viser hva kunden autoriserte, slik at forhandlere, utstedere og innløsere kan stole på og revidere det. Hvis KI-agenter sannsynligvis vil handle hos deg, kan vi gjøre kassen din AP2-klar sammen med dagens flyter.

Les mer: Betalinger, agentisk handel (AP2) og POSLenke til dette spørsmålet

Ja, med SoftPOS. Kontaktløse kort og lommebøker tas imot på en støttet telefon eller nettbrett gjennom en sertifisert betalingsapp fra innløseren eller leverandøren din. Vi integrerer den appen med POS-, salgs- og oppgjørsflytene dine som enhver annen terminal.

Les mer: Betalinger, agentisk handel (AP2) og POSLenke til dette spørsmålet

Butikken fortsetter å selge. Salg lagres lokalt og sendes til ERP når forbindelsen er tilbake, hvert med en unik identifikator slik at ingenting posteres to ganger. Om kortbetalinger kan fortsette offline avhenger av innløserens regler og risikoviljen din, og det designer vi sammen med deg.

Les mer: Betalinger, agentisk handel (AP2) og POSLenke til dette spørsmålet

Det avhenger av hvor mange tilkoblinger du har og hvem som skal drifte dem. En integrasjonsplattform som MuleSoft, Boomi eller Azure Logic Apps gir deg ferdige koblinger, mapping og overvåking på ett sted, mot en lisenskostnad. Skreddersydde tjenester gir deg full kontroll og ingen lisens, men mer kode å vedlikeholde. Vi sammenligner begge for din situasjon.

Les mer: Middleware og API-integrasjonstjenesterLenke til dette spørsmålet

En enterprise service bus ruter og transformerer meldinger gjennom en sentral hub. Et hendelsesmesh fordeler hendelser gjennom et nettverk av tilkoblede meglere, slik at systemer i ulike skyer og på ulike steder publiserer og abonnerer direkte. Mange miljøer kjører begge mens de går fra det ene til det andre.

Les mer: Middleware og API-integrasjonstjenesterLenke til dette spørsmålet

Vi designer rundt hver partners publiserte grenser. Vi samler forespørsler i batcher der API-et tillater det, cacher data som sjelden endres, sprer planlagte jobber og venter lenger når en grense er nær. Overvåking viser hvor nær hver flyt er grensen.

Les mer: Middleware og API-integrasjonstjenesterLenke til dette spørsmålet