Spørgsmålene i denne artikel har til formål at hjælpe dig med at kontrollere, om din implementering af RetailForces Fiskal middleware opfylder kravene i den tyske kasseapparatforordning (KassenSichV).
Bemærk: Listen er ment som en vejledning til implementering og udgør ikke en fuldstændig testprotokol. Hvis du har yderligere spørgsmål, er du velkommen til at kontakte vores konsulenter
Oprettelse af dokumenter
- Når der oprettes kvitteringer, blev funktionen createDocument (til oprettelse af en transaktion på TSE) kaldt, da der blev oprettet en transaktion i dit POS-system?
Baggrund: I Tyskland er det påkrævet at starte en transaktion på TSE, når dokumentet påbegyndes (ved tilføjelse af den første vare eller kunde eller lignende aktivitet).
Dokumentoverførsel
- Er det sikret, at hvert dokument, der er påbegyndt, også er blevet overført?
- Overføres en kvitteringsannullering som en cancelDocument?
- Hvordan håndteres annullering af linjer?
- Hvordan håndteres parkerede/suspenderede kvitteringer (hvis der er nogen) ved dagens afslutning?
- Kontrolleres antallet af åbne transaktioner på TSE løbende?
-
Er det sikret, at flere processer ikke kommunikerer med én FiscalClient på samme tid?
(Flere samtidige opkald til storeDocument på den samme FiscalClient er ikke tilladt, men flere FiscalClients pr. FiscalService er tilladt).
- Hvordan blev fejlhåndtering implementeret for buffrede opkald (se også næste spørgsmål)?
-
Hvordan blev det sikret, at kun skattemæssigt relevante dokumenter overføres til skattesystemet?
- Hvad er proceduren i tilfælde af en fejl?
- Hvordan håndteres den fejlsituation, hvor tjenesten ikke er tilgængelig?
-
Er der nogen parkerede/suspenderede dokumenter, og hvis ja, er de blevet implementeret med LongTermOrder-funktionen eller med åbne transaktioner på TSE'en?
- Bemærk venligst, at forskellige TSE-producenter understøtter forskellige maksimale antal åbne transaktioner på en TSE.
- Se også: Langsigtede bestillingsprocesser i cateringbranchen.
- Blev dokumentvalideringen udført før overførslen, eller først når storeDocument-metoden genererer en fejl?
Dokumenttyper
-
Vil alle skattemæssigt relevante dokumenttyper blive overført?
- Indbetaling af byttepenge
- Salg
- Indbetaling
- Udbetaling/udtag
- Opkrævning/udbetaling
- Kontantforskel
- Kontantsaldo
-
Er BusinessTransactionType indstillet bevidst, eller forbliver den altid på standardindstillingen?
- Hvilke er der implementeret?
- Har du forretningsprocesser, der endnu ikke er tilknyttet en BusinessTransactionType?
(f.eks.: Tilskud, der bogføres via POS-systemet (tilgængeligt fra og med 1.2.11)).
- Er skattesatserne for positionerne overført korrekt?
- Er referencen overført korrekt i tilfælde af en annullering eller en returnering?
- Overføres kundedataene i tilfælde af et kundespecifikt salg?
- Overføres brugeren (ejendomsbrugeren) sammen med dokumentet?
Yderligere oplysninger: Fra og med version 1.2.11 kan du tjekke de obligatoriske og valgfri dokumenttyper og BusinessTransactionTypes for hvert land i portalen under Information.
Positions
-
Er der andre poster end varepositioner?
- Indstil vare
- Bogføringer / posteringer
- Tekstposter / tekstpositioner
- Hvordan kortlægges eventuelle kuponsalg?
- Overføres rabatter i den eksisterende struktur?
- Hvad angår NetValue/GrossValue-værdierne for en vare, overføres det faktiske salg for denne vare, inklusive alle rabatter (også kumulative rabatter / delbeløbsrabatter)?
- Overføres subtotaler?
- Er der forskellige måleenheder?
Betalingsmetoder
- Er de relevante PaymentTypes indstillet korrekt?
- Skelnes der mellem kuponer til ét formål og kuponer til flere formål?
- Overføres valutakursen og valutaen korrekt for udenlandske valutaer?
Kasseafslutning
- Er kasseafslutningen blevet gennemført?
- Hvis den forenklede kasseafslutning anvendes, hvordan afstemmes/verificeres dataene med systemet?
Udskrift
- Er QR-koden trykt på hver udskrift/kvittering?
-
Overholder udskriften de lovmæssige krav?
- Udskrives (eller udleveres elektronisk) hver enkelt kvittering og afleveres den til kunden?
- Er en eventuel TSE-fejl angivet på udskriften?
- Er PrintMessage (obligatorisk!) fra fiscalResponse implementeret på udskriften?
Drift
-
Hvordan blev det sikret, at CloudConnect kaldes, når tjenesten genstartes (og POS-applikationen ikke registrerer genstarten; kun relevant, hvis cloudarkivering er aktiv)?
- Blev responskoden (424, mislykket afhængighed) for manglende Cloud-forbindelse opfanget korrekt?
-
Hvordan sikres det, at tjenesten kører konstant?
- Er der installeret en overvågning?
-
Hvordan sikres det, at den igangværende cloudoverførsel (arkivering) kontrolleres for at se, om den kører korrekt?
- Bruges endpointet /api/v1/information/client/{clientId}/status til løbende at kontrollere de åbne cloud-overførsler?
- Er POS-systemets fysiske (lokale) nærhed til den skattemæssige tjeneste og også til TSE sikret?
Se også BSI's FAQ.
Tekniske spørgsmål/tests
-
Er der oprettet testenheder til at kontrollere integrationen?
- Hvilke testtilfælde dækkes af testenhederne?
- Hvilke forretningsscenarier dækkes af testenhederne?
- Hvilke test og testprotokoller er der oprettet?
-
Hvordan håndteres en ændring i en RetailForce-release? Genstartes testenhederne?
- Hvordan fungerer testprocessen?
- Er det sikret, at der kun anvendes produktive terminaler (konfiguration) i produktiv drift?
- Er det sikret, at det ikke er muligt at betjene kasseapparatet uden forbindelse til fiskaliseringen og/eller TSE'en?
- Er det sikret, at det ikke er muligt at afkoble kasseapparatet fra fiskaliseringen/den tekniske sikkerhedsenhed via konfigurationen?
Denne artikel er oversat automatisk.
Kommentarer
0 kommentarer
Log ind for at kommentere.