
Detaljhandel og omnikanal
Butikker, nettbutikker og ERP-en er enige om hvert salg og hver vare, i sanntid.
Hvorfor butikker, nettsalg og ERP-en kommer i utakt
Detaljhandelen drives av mange systemer som må stemme overens: kasser, nettbutikker, lagre, betalingsleverandører og ERP-en. Når de kommer i utakt, blir lageret feil, prisene varierer mellom kanaler, og økonomiavdelingen bruker dager på avstemming.
Satsvise synkroniseringer over natten
Kasser, nettbutikker og ERP utveksler data timer for sent, så lageret overselges i toppperioder.
Tregt oppgjør
Kortoppgjør hos flere innløsere avstemmes sent, og avvik koster penger.
Topper som bryter kassen
Kampanjer og høytider gir trafikk som trege systemer ikke takler.
Det som endres
Én versjon av hvert salg
Butikkterminaler, nettkasse og ERP-hovedboken stemmer overens i sanntid.
Lager du kan stole på
Varenivåer synkroniseres mellom butikker og nettbutikker når de endres.
Oppgjør avstemt
Oppgjørsfiler leses inn og gebyrer revideres automatisk.
Hvor vi arbeider
Det vi bygger
- POS-utvidelser, backoffice-apper og butikkdashbord
- Offline-sikker synkronisering mellom butikkservere og hovedkontor
Det vi bygger
- Netthandelsfrontender og ordretjenester
- Klikk og hent, returer og ordresporing
Typiske integrasjoner
- Netthandelsplattformer, markedsplasser, transportører og ERP
Det vi bygger, kobler sammen og sikrer
POS- og ERP-integrasjon
Salg, returer og dagssluttotaler posteres til ERP, mens priser, kampanjer og varer sendes tilbake til hver butikk.
Lageroversikt
Én oversikt over lager på tvers av butikker, lagre og netthandel, oppdatert når salg og leveranser skjer.
Netthandel og mobilhandel
Nettbutikker og apper som deler produkter, priser og lager med butikkene.
Lojalitet og kampanjer
Lojalitetsprogrammer, kuponger og kampanjeregler som virker likt i alle kanaler.
Verktøy for butikkdrift
Apper for varetelling, overføringer, leveranser og oppgaver for ansatte, laget for bruk i butikken.
Superapper og enhetlig handel
Én app med høy samtidighet for handel, betaling og lojalitet på tvers av merkevarer.
POS-plattformer
Kasser og POS-skytjenester, gjennom API-ene deres, eksportfiler eller butikkservere.
Kortbetalinger
Terminaler, betalingsgatewayer og innløsere, med oppgjørsfiler avstemt mot salg.
ERP
SAP S/4HANA, Microsoft Dynamics 365, Oracle NetSuite, Odoo og andre, for varer, lager og økonomi.
Lagre og transportører
Lagersystemer og transportør-API-er for ordreplukk, leveranser og returer.
Kortdata utenfor omfanget
Vi lar kortdata ligge hos betalingsleverandøren, gjennom tokenisering og punkt-til-punkt-krypterte terminaler der det er tilgjengelig, noe som holder PCI DSS-omfanget lite.
Kundedata
Lojalitets- og ordredata samles inn med samtykke, oppbevares bare så lenge det er nødvendig, og behandles etter GDPR og gjeldende lokale lover.
Fiskale regler og avgiftsregler
Der et land krever fiskale kvitteringer eller e-fakturering, kobler vi til de sertifiserte enhetene eller plattformene det pålegger, og oppbevarer dokumentasjonen det krever.

Slik arbeider vi
Vi kobler disse systemene sammen slik at salg, lager, priser og betalinger flyttes pålitelig mellom dem, og vi bygger kundeappene og backoffice-verktøyene rundt dem. Butikkene fortsetter å selge når nettet svikter, og henter seg inn igjen når det kommer tilbake.
Kartlegg flytene
Salg, returer, priser, lager og betalinger, mellom alle systemer.
Erstatt satsvis kjøring
Hendelser strømmer mellom POS, nettbutikker og ERP, med en dead-letter-kø for feil.
Bevis det ved topplast
Lasttester med festivaltrafikk før idriftsettelse.
Rull sidelengs for å se hele tegningen.
POS til ERP: hvert salg posteres én gang
Salgsflyten fra kassene til ERP som hendelser, og priser og lager flyter tilbake. En butikk som går offline, fortsetter å selge og tar igjen det tapte. En postering som feiler, forsøkes på nytt og overleveres deretter til en person.
- Hovedforløp
- Asynkron
- Unntaksbane
Forløpet i 8 steg
Forløpet, steg for steg
- Fra POS-terminaler til Butikk- eller POS-skyserver: Salg, returer og annulleringer (hovedforløp).
- Fra Butikk- eller POS-skyserver til Integreringslag: Salgshendelser og dagssluttotaler, gjennom en hendelseskø, over REST/JSON (asynkron).
- Fra Integreringslag til ERP: Salgs- og lagerbevegelser postert, over OData · REST/JSON (hovedforløp).
- Fra ERP til Integreringslag: Priser, kampanjer og varedata, via API eller fileksport, over REST/JSON (hovedforløp).
- Fra Integreringslag til Butikk- eller POS-skyserver: Pris- og lageroppdateringer, over REST/JSON (hovedforløp).
- Fra Integreringslag til Kø for nye forsøk: Postering feilet (unntaksbane).
- Fra Kø for nye forsøk til Integreringslag: Forsøkt på nytt (unntaksbane).
- Fra Kø for nye forsøk til Butikkdriftsteam: Feiler fortsatt: varsel med detaljene (unntaksbane).
Rull sidelengs for å se hele tegningen.
Kortbetalinger: autorisert i kassen, gjort opp senere, avstemt i ERP
Terminalen eller kassen spør betalingsgatewayen, betalingsgatewayen spør innløseren, og innløseren ruter til kortordningen og utstederen. Oppgjørsfiler kommer senere og avstemmes mot salg og gebyrer i ERP. En tidsavbrudd utløser en tilbakeføring, slik at kunden aldri belastes to ganger.
- Hovedforløp
- Asynkron
- Unntaksbane
Forløpet i 8 steg
Forløpet, steg for steg
- Fra EMV-terminal eller nettkasse til Betalingsgateway: Autorisasjonsforespørsel, over EMV · REST/JSON (hovedforløp).
- Fra Betalingsgateway til Innløser: Autorisasjon, over ISO 8583 (hovedforløp).
- Fra Innløser til Kortordning og utsteder: Rutes til utsteder, over ISO 8583 (hovedforløp).
- Fra Innløser til Betalingsgateway: Godkjent eller avvist, over ISO 8583 (asynkron).
- Fra Innløser til Integreringslag: Oppgjørs- og gebyrfiler, over SFTP (asynkron).
- Fra Integreringslag til ERP: Oppgjorte salg, gebyrer og utbetalinger, over REST/JSON (hovedforløp).
- Fra Betalingsgateway til EMV-terminal eller nettkasse: Ingen respons i tide: automatisk tilbakeføring, over ISO 8583 0400 (unntaksbane).
- Fra Integreringslag til Betalingsteamet: Avstemmingsavvik eller tilbakeføring (unntaksbane).
Erfaring
Utvalgte merkevarer for virksomheter representerer historiske og pågående systemer, plattformer og digitale produkter som XSIS, KONG GROUP, vår administrerende direktør og våre ledende ingeniører har arkitekert eller levert gjennom karrieren. Alle tredjepartsvaremerker tilhører sine respektive eiere og er navngitt kun for faktisk identifikasjon av porteføljen.
Slik starter du
Hva skjer videre
Avtale tid
Teamet vårt sender deg en e-post for å avtale tid til samtalen.
Forhåndssamtale
En gratis forhåndssamtale på 30 minutter på nett: vi går gjennom målene, systemene og begrensningene dine.
Modenhetsvurdering
I en gratis modenhetsvurdering innen 48 timer kontrollerer en ledende arkitekt prosjektet ditt mot definisjonen av klar (6 punkter) og anbefaler sporet som passer.
Valg av spor
Prosjekter med definert omfang får et bindende forslag innen 3 til 5 virkedager. Prosjekter i konseptfasen starter i Blueprint Studio. Et system i drift som svikter, er udokumentert eller trenger integrasjon, starter med en diagnose på 1 til 2 uker. Blueprint Studio og diagnosen har hver en fastpris som angis i forslaget.
KI-innfødte produkteam
Forvaltede, tverrfaglige team av erfarne ingeniører, utstyrt med agentiske rammeverk for koding og kvalitetssikring.
Prosjekter med fast resultat og forvaltede tjenester døgnet rundt
Leveranse med fast omfang og milepæler, med navngitte leveranseledere, og forvaltede applikasjonstjenester døgnet rundt under SLA-styring.
Den raskeste veien inn er Sprint for pålagt e-fakturering og ERP-beredskap-pakken, en av våre pakker for rask oppstart.
Hvor du starterSpørsmål og svar
Hva skjer når en butikk mister forbindelsen?
Butikken fortsetter å selge. Salg lagres lokalt og sendes når forbindelsen kommer tilbake, hvert med en unik identifikator slik at ingenting posteres to ganger. Pris- og lageroppdateringer legges i kø på samme måte. Drift kan se hvilke butikker som ligger etter og hvor mye, slik at en lang driftsstans oppdages med en gang, ikke ved månedsslutt.
Hvilke POS-systemer kan dere integrere?
Vi integrerer POS-plattformer gjennom det de tilbyr: sky-API-er, butikkservere, databaseeksport eller filer. Før vi anslår, går vi gjennom POS-dokumentasjonen og et utvalg av dataene, fordi det avgjør tilnærmingen. Å nevne en POS-plattform eller et ERP-system på dette nettstedet betyr ikke et partnerskap med leverandøren.
Hvorfor stemmer aldri lageret mellom ERP og butikkene?
Vanligvis fordi systemene er uenige om tidspunkt, enheter eller hva som regnes som en bevegelse. Returer, overføringer, skadde varer og salg under en varetelling er vanlige årsaker. Vi sporer avvikene, blir enige om én regel for hver type bevegelse, og bygger synkroniseringen slik at den registrerer hver endring med kilden. Gjenværende avvik går til en gjennomgangsliste i stedet for å hope seg opp.
Hva driver kostnaden ved en detaljhandelsintegrasjon?
Antall systemer, butikker og kanaler, hvor godt POS-systemet og ERP-systemet eksponerer dataene sine, og hvor mange unntak som trenger regler, som returer på tvers av kanaler eller delte betalinger. Utrulling butikk for butikk gir også mer testarbeid. Vi estimerer etter å ha gjennomgått systemene og et utvalg av reelle transaksjoner.
Kan dere rulle ut uten å stenge butikker?
Ja. Vi går i drift i trinn, med en pilotbutikk først, og kjører den nye integrasjonen parallelt med dagens prosess til totalene stemmer. Endringer i butikkene planlegges utenfor åpningstid der det er mulig, og hvert trinn har en vei tilbake hvis noe ikke fungerer som planlagt.
Hvem støtter integrasjonen etter idriftsettelse?
Vi kan overvåke og støtte den under en støtteavtale, eller overlevere den til teamet ditt med dokumentasjon, varsler og en driftshåndbok. Uansett havner en mislykket melding i en kø med årsaken, slik at den kan rettes og kjøres på nytt i stedet for å gå tapt.
Start med en samtale, ikke en kontrakt.
Fortell oss hva du trenger å bygge, koble sammen eller sikre. En arkitekt går gjennom det med deg og anbefaler deretter hvor du bør starte.


