Hopp til innhold
XSIS
En kunde betaler i en selvbetjeningskasse

Bransjer

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

  1. Én versjon av hvert salg

    Butikkterminaler, nettkasse og ERP-hovedboken stemmer overens i sanntid.

  2. Lager du kan stole på

    Varenivåer synkroniseres mellom butikker og nettbutikker når de endres.

  3. 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.

En hånd holder en trådløs bankterminal, nærbilde

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.

  1. Kartlegg flytene

    Salg, returer, priser, lager og betalinger, mellom alle systemer.

  2. Erstatt satsvis kjøring

    Hendelser strømmer mellom POS, nettbutikker og ERP, med en dead-letter-kø for feil.

  3. Bevis det ved topplast

    Lasttester med festivaltrafikk før idriftsettelse.

POS til ERP: hvert salg posteres én gangSalgsflyten 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.POSPOS-terminalerHver kasse i hverbutikkDatalagerButikk- ellerPOS-skyserverFortsetter å selgeofflineXSISIntegreringslagHendelseskø,mapping,duplikatbeskyttelseERPERPSalg, lager ogøkonomiTjenesteKø for nye forsøkNye forsøk medøkende ventetid,deretter endead-letter-køPersonerButikkdriftsteam12REST/JSON3OData · REST/JSON4REST/JSON5REST/JSON678

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

  1. Fra POS-terminaler til Butikk- eller POS-skyserver: Salg, returer og annulleringer (hovedforløp).
  2. Fra Butikk- eller POS-skyserver til Integreringslag: Salgshendelser og dagssluttotaler, gjennom en hendelseskø, over REST/JSON (asynkron).
  3. Fra Integreringslag til ERP: Salgs- og lagerbevegelser postert, over OData · REST/JSON (hovedforløp).
  4. Fra ERP til Integreringslag: Priser, kampanjer og varedata, via API eller fileksport, over REST/JSON (hovedforløp).
  5. Fra Integreringslag til Butikk- eller POS-skyserver: Pris- og lageroppdateringer, over REST/JSON (hovedforløp).
  6. Fra Integreringslag til Kø for nye forsøk: Postering feilet (unntaksbane).
  7. Fra Kø for nye forsøk til Integreringslag: Forsøkt på nytt (unntaksbane).
  8. Fra Kø for nye forsøk til Butikkdriftsteam: Feiler fortsatt: varsel med detaljene (unntaksbane).
Kortbetalinger: autorisert i kassen, gjort opp senere, avstemt i ERPTerminalen 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.POSEMV-terminal ellernettkasseBrikke, berøringsfri ognetthandelGatewayBetalingsgatewayTokenisering og rutingBankInnløserAutorisasjon ogoppgjørTredjepartKortordning ogutstederGodkjenner elleravviserERPERPSalg, gebyrer ogutbetalingerXSISIntegreringslagParsing ogavstemming avoppgjørPersonerBetalingsteametAvvik, tvister ogtilbakeføringer1EMV · REST/JSON2ISO 85833ISO 85834ISO 85835SFTP6REST/JSON7ISO 8583 04008

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

  1. Fra EMV-terminal eller nettkasse til Betalingsgateway: Autorisasjonsforespørsel, over EMV · REST/JSON (hovedforløp).
  2. Fra Betalingsgateway til Innløser: Autorisasjon, over ISO 8583 (hovedforløp).
  3. Fra Innløser til Kortordning og utsteder: Rutes til utsteder, over ISO 8583 (hovedforløp).
  4. Fra Innløser til Betalingsgateway: Godkjent eller avvist, over ISO 8583 (asynkron).
  5. Fra Innløser til Integreringslag: Oppgjørs- og gebyrfiler, over SFTP (asynkron).
  6. Fra Integreringslag til ERP: Oppgjorte salg, gebyrer og utbetalinger, over REST/JSON (hovedforløp).
  7. Fra Betalingsgateway til EMV-terminal eller nettkasse: Ingen respons i tide: automatisk tilbakeføring, over ISO 8583 0400 (unntaksbane).
  8. Fra Integreringslag til Betalingsteamet: Avstemmingsavvik eller tilbakeføring (unntaksbane).

Erfaring

  • Logoen til Landmark Group (UAE)
  • Logoen til Nike
  • Logoen til Victoria’s Secret
  • Logoen til M·A·C Cosmetics

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

  1. Avtale tid

    Teamet vårt sender deg en e-post for å avtale tid til samtalen.

  2. Forhåndssamtale

    En gratis forhåndssamtale på 30 minutter på nett: vi går gjennom målene, systemene og begrensningene dine.

  3. 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.

  4. 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.

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 starter

Spø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.