Frågorna i denna artikel är avsedda att hjälpa dig att kontrollera att din implementering av RetailForces Fiskal middleware uppfyller kraven i den tyska kassasäkerhetsförordningen (KassenSichV).
Observera: Listan är avsedd som en vägledning för implementeringen och utgör inte ett fullständigt testprotokoll. Om du har ytterligare frågor är du välkommen att kontakta våra konsulter
Dokumentgenerering
- När kvitton skapades, anropades funktionen createDocument (för att skapa en transaktion på TSE) vid skapandet av en transaktion i ditt kassasystem?
Bakgrund: I Tyskland är det obligatoriskt att starta en transaktion på TSE när dokumentet påbörjas (vid tillägg av den första varan, kunden eller liknande aktivitet).
Dokumentöverföring
- Har ni säkerställt att varje dokument som har påbörjats också har överförts?
- Överförs en kvittostornering som ett cancelDocument?
- Hur hanteras radannulleringar?
- Hur hanteras eventuella parkerade/avbrutna kvitton vid dagens slut?
- Kontrolleras antalet öppna transaktioner på TSE löpande?
-
Har man säkerställt att inte flera processer kommunicerar med en och samma FiscalClient samtidigt?
(Flera samtidiga anrop av storeDocument på samma FiscalClient är inte tillåtna, men flera FiscalClients per FiscalService är tillåtna).
- Hur har felhanteringen implementerats för buffrade anrop (se även nästa fråga)?
-
Hur säkerställdes det att endast skatterelevanta dokument överförs till skattesystemet?
- Vilket förfarande gäller vid ett fel?
- Hur hanteras felsituationen där tjänsten inte är tillgänglig?
-
Finns det några parkerade/avbrutna dokument, och i så fall, har de implementerats med funktionen LongTermOrder eller med öppna transaktioner på TSE?
- Observera att olika TSE-tillverkare stöder olika maximalt antal öppna transaktioner på en TSE.
- Se även: Processer för långsiktiga beställningar inom restaurangbranschen.
- Kallades dokumentvalideringen före överföringen eller endast när metoden storeDocument ger ett fel?
Dokumenttyper
-
Kommer alla skatterelevanta dokumenttyper att överföras?
- Inbetalning av växel
- Försäljning
- Inbetalning
- Utbetalning/uttag
- Avgift/uttag
- Kontantskillnad
- Kontantsaldo
-
Är BusinessTransactionType avsiktligt inställd eller lämnas den alltid på standardvärdet?
- Vilka har implementerats?
- Har ni affärsprocesser som ännu inte är kopplade till en BusinessTransactionType?
(t.ex.: Bidrag som bokförs via kassasystemet (tillgängligt från och med version 1.2.11)).
- Överförs skattesatserna för positionerna korrekt?
- Överförs referensen korrekt vid en annullering eller en retur?
- Överförs kunduppgifterna vid en kundidentifierad försäljning?
- Överförs användaren (fastighetsanvändaren) tillsammans med dokumentet?
Ytterligare information: Från och med version 1.2.11 kan du kontrollera de obligatoriska och valfria dokumenttyperna samt BusinessTransactionTypes för varje land i portalen under ”Information”.
Positioner
-
Finns det några andra poster än artikelpositioner?
- Ange artikel
- Bokningar
- Textposter / textpositioner
- Hur kartläggs eventuella försäljningar via kuponger?
- Överförs rabatter i den befintliga strukturen?
- När det gäller värdena för NetValue och GrossValue för en artikel, överförs då den faktiska försäljningen för denna artikel, inklusive alla rabatter som beaktats (även kumulativa rabatter och delsummerabatter)?
- Överförs delsumman?
- Finns det olika måttenheter?
Betalningssätt
- Är lämpliga PaymentTypes korrekt inställda?
- Görs det någon åtskillnad mellan kuponger för ett enda ändamål och kuponger för flera ändamål?
- För utländska valutor: överförs växelkursen och valutan korrekt?
Kassaavslut
- Har kassastängningen genomförts?
- Om den förenklade kassastängningen används, hur stäms/verifieras uppgifterna mot systemet?
Utskrift
- Finns QR-koden utskriven på varje utskrift/kvitto?
-
Uppfyller utskriften de lagstadgade kraven?
- Skrivs varje kvitto ut (eller tillhandahålls elektroniskt) och överlämnas till kunden?
- Noteras eventuella TSE-fel på utskriften?
- Har PrintMessage (obligatoriskt!) från fiscalResponse implementerats på utskriften?
Drift
-
Hur säkerställdes det att CloudConnect anropas när tjänsten startas om (och POS-applikationen inte märker omstarten, endast relevant om molnarkivering är aktiv)?
- Har svarskoden (424, misslyckad beroende) för saknad Cloud-anslutning fångats upp på rätt sätt?
-
Hur säkerställs det att tjänsten körs kontinuerligt?
- Finns det en övervakning installerad?
-
Hur säkerställs det att den pågående Cloud-överföringen (arkiveringen) kontrolleras för att se om den fungerar som den ska?
- Används slutpunkten /api/v1/information/client/{clientId}/status för att kontinuerligt kontrollera de pågående molnöverföringarna?
- Säkerställs den fysiska (lokala) närheten mellan kassasystemet och skattetjänsten samt till TSE?
Se även BSI:s vanliga frågor.
Tekniska frågor/tester
-
Har testenheter skapats för att kontrollera integrationen?
- Vilka testfall omfattas av testenheterna?
- Vilka affärsscenarier omfattas av testenheterna?
- Vilka tester och testprotokoll har skapats?
-
Hur hanteras en releaseändring i RetailForce? Startas testenheterna om?
- Hur fungerar testprocessen?
- Är det säkerställt att endast terminaler i produktiv drift (konfiguration) används i den produktiva driften?
- Är det säkerställt att det inte går att använda kassan utan anslutning till fiscaliseringsenheten och/eller TSE?
- Är det säkerställt att det inte går att enkelt koppla bort kassan från fiscaliseringsenheten/den tekniska säkerhetsenheten via konfigurationen?
Den här artikeln har översatts automatiskt.
Kommentarer
0 kommentarer
logga in för att lämna en kommentar.