I denne artikel får du mere at vide om mulige systemarkitekturer, som ifølge vores nuværende viden kan implementeres i Tyskland ved hjælp af RetailForce Fiskal middleware og de TSE-varianter, der er forbundet med middlewaren. Alle varianter er grundlæggende uafhængige af den valgte integrationsvariant af RetailForce Fiskal middleware. Se afsnittet Installations- og integrationsvarianter for yderligere oplysninger.

Med alle varianter arkiveres DSFinV-K-dataene i det sikre arkiv i RetailForce Cloud.

Lokale kassesystemer

Enkelt POS-system med lokal TSE

Denne variant er velegnet til individuelle kasseapparater / selvstændige POS-systemer. Her installeres RetailForce Middleware på det pågældende kasseapparat, og den certificerede tekniske sikkerhedsenhed (TSE) tilsluttes direkte til kasseapparatets hardware. 

Følgende krav gælder for denne arkitektoniske variant:

• én licens til RetailForce Middleware pr. POS-system
• én hardware TSE-enhed pr. POS-system

Centraliserede POS-systemer

For centraliserede POS-systemer er der flere varianter at vælge imellem, afhængigt af POS-systemets faktiske arkitektur.

POS-system med central filial og lokal TSE

I POS-systemer med central filial kører selve POS-applikationen enten på en server i hver filial/butik eller leveres på en backoffice-pc. De enkelte kasseapparater (= klienter) er forbundet til det centrale system via det lokale filialnetværk (LAN). Det centrale system skal installeres i hver enkelt butik.

Her installeres Fiscal Client (middleware) på det centrale system.

Her installeres Fiscal Client (Fiscal Middleware) på det centrale system.

I denne variant er TSE-enhederne forbundet direkte til den centrale filial-/butiksserver eller backoffice-pc'en.

Med denne systemarkitektur skal der skelnes mellem, om klienterne reelt kan betragtes som separate POS-systemer. Dette er tilfældet, hvis de enkelte klienter kan skelnes fra hinanden i POS-systemets database. For eksempel hvis der administreres et separat dokumentnummerinterval for hver klient. Derimod kan serveren også defineres som et kasseapparat. I dette tilfælde vil klienterne arbejde sekventielt, dvs. de vil dele et kvitterings-/dokumentnummerinterval. I dette tilfælde venter hver klient, indtil de andre klienter er færdige med at udskrive kvitteringer.

Forudsætninger for denne arkitekturvariant:

• en (central) installation af RetailForce Middleware – denne administrerer alle POS-klienter
• enten
  • én licens pr. POS-client (hvis klienterne kan arbejde parallelt) eller
  • én licens pr. centralt system (hvis dokumentbehandlingen på klienten foregår sekventielt),
• det samme gælder for TSE'en, enten
  • én hardware TSE-enhed pr. POS-client eller
  • én hardware TSE-enhed pr. filialserver eller backoffice-pc.

Centralt filial-POS-system med Cloud TSE

Som et alternativ til lokale hardware-TSE'er kan der også anvendes Cloud-TSE'er på centraliserede filial-POS-systemer til sikring af kvitteringsdokumenter.

Ligesom i den ovenfor beskrevne variant med lokalt tilsluttede hardware-TSE'er installeres RetailForce Fiscal Client også på det centrale POS-system.

Derudover skal SMAERS-delen af TSE'en (SMAERS står for Security Module Application for Electronic Record Keeping Systems) også installeres på det centrale system. SMAERS er en softwarekomponent, der opretter en sikker forbindelse til den eksterne CSP (Cryptographic Service Provider), som udgør TSE'ens signaturenhed.

Forudsætningerne for denne arkitekturvariant er:

• En (central) installation af RetailForce Middleware – der administrerer alle POS-klienter (multi-tenant-tilstand),
• en (central) installation af en TSE Cloud Connector (SMAERS),
• enten
  • én licens pr. POS-client (hvis klienterne kan arbejde parallelt) eller
  • én licens pr. centralt system (hvis dokumentbehandlingen på klienten foregår sekventielt),
• det samme gælder for TSE, enten
  • én hardware TSE-enhed pr. POS-client eller
  • én hardware TSE-enhed pr. filialserver eller backoffice-pc (hvis klienterne kan arbejde sekventielt).

Centralt POS-system med Cloud TSE

I modsætning til de to foregående varianter er det centrale system her ikke en server, der er tilgængelig for hver filial eller butikkens backoffice-pc, men en fjernserver. POS-applikationen kører på denne server. De enkelte kasseapparater får adgang til POS-serveren via internettet (WAN – Wide Area Network), f.eks. via en fjernskrivebordsforbindelse. I dette tilfælde kan kasseapparaterne ikke fungere offline og kræver en permanent onlineforbindelse til POS-serveren under betalingsprocessen. 

Ligesom med den foregående arkitekturvariant skal RetailForce Middleware og SMAERS-komponenten installeres på POS-serveren.

For at kunne anvende denne variant gælder følgende forudsætninger:

• en (central) installation af RetailForce Middleware på POS-serveren – der administrerer alle POS-klienter,
• en (central) installation af en TSE Cloud Connector (SMAERS)
• én licens til RetailForce Middleware pr. POS-client
• én Cloud TSE-licens pr. POS-client

I dette tilfælde beskrives ikke sekventielt fungerende POS-systemer, da landsdækkende versioner af disse systemer efter vores opfattelse ikke opfylder de skattemæssige krav.

Cloud-POS-system med Cloud TSE

Arkitekturen i cloudbaserede POS-systemer er i det væsentlige identisk med den i centrale POS-systemer, hvor forbindelsen mellem den centrale server og klienterne etableres via internettet.

Også her skal RetailForce Middleware og SMAERS-komponenten installeres på POS-serveren.

Det vigtige ved denne arkitekturvariant er, at de mobile klienter har brug for en regelmæssig onlineforbindelse under kasseprocessen. Klienterne må ikke have nogen eller kun begrænsede offlinefunktioner.

Krav til denne variant:

• en (central) installation af RetailForce Middleware på Cloud-serveren, der administrerer alle mobile klienter (multi-tenant-tilstand),
• en (central) installation af en TSE Cloud Connector (SMAERS), ligeledes på cloud-serveren
• én licens til RetailForce Middleware pr. Mobile POS-client
• én Cloud TSE-licens pr. Mobile POS-client

Denne artikel er oversat automatisk.