The questions listed in this article are intended to help you check your implementation of RetailForce's Fiskal Middleware for the fulfilment of the German Cash Register Security Ordinance (KassenSichV) in Germany.
Attention: The list is intended as a guide to implementation and is not a complete test protocol. If you have any further questions, please do not hesitate to contact our consultants
Document creation
- When creating receipts, was the CreateDocument function (to create a transaction on the TSE) called when creating a transaction in your POS system?
Background: In Germany it is required to start a transaction on the TSE when starting the document (adding the first item or customer or similar activity).
Document transmission
- Has it been ensured that every document which has been started has also been transmitted?
- Is a receipt cancellation transmitted as a CancelDocument?
- How are line cancellations handled?
- How are parked /suspended receipts (if any) handled at the end of the day?
- Is the number of open transactions on the TSE checked on an ongoing basis?
- Has it been ensured that several processes are not talking to one FiscalClient at the same time?
(Multiple simultaneous calls of StoreDocument on the same FiscalClient are not allowed, but multiple FiscalClients per FiscalService are allowed).
- How was error handling implemented for buffered calls (see also next question)?
- How was it ensured that only fiscally relevant document are being transmitted to the fiscal system?
- What is the procedure in the event of an error?
- How is the error situation that the service is not available dealt with?
- Are there any parked / suspended documents and if so, have they been implemented with the LongTermOrder function or with open transactions on the TSE?
- Please note that different TSE manufacturers support different maximum open transactions on a TSE.
- See also: Long-term ordering processes in the catering industry.
- Was document validation called before transmission or only when the StoreDocument method throws an error?
Document types
- Will all fiscally relevant document types be transmitted?
- Deposit of change
- Sale
- Deposit
- Disbursement/withdrawal
- Levy/withdrawal
- Cash difference
- Cash balance
- Is the BusinessTransactionType deliberately set or always left default?
- Which ones have been implemented?
- Do you have business processes that are not yet mapped by a BusinessTransactionType?
(e.g.: Grants that are posted via the POS system (available with/as of 1.2.11)).
- Are the tax rates for the positions transferred correctly?
- Is the reference correctly transferred in the case of a cancellation or a return?
- Are the customer data transmitted in the case of a customer-identified sale?
- Is the user (property user) transmitted with the document?
Additional information: As of version 1.2.11, you can check the mandatory and optional document types and BusinessTransactionTypes for each country in the portal under Information.
Positions
- Are there any items other than item positions?
- Set item
- Postings / booking
- Text items / text positions
- How are possible voucher sale being mapped?
- Are discounts transmitted in the existing structure?
- For the NetValue/GrossValue values on an item, are the actual sales achieved for this item transmitted, including all discounts taken into account (also cumulative discounts / subtotal discounts)?
- Are subtotals being transmitted?
- Are there different units of measure?
Payment methods
- Are the appropriate PaymentTypes set correctly?
- Is a distinction being made between single-purpose and multi-purpose vouchers?
- For foreign currencies, are the conversion rate and currency correctly transferred?
Cash closing
- Has the cash closure been implemented?
- If the simplified cash closure is being used, how is the data reconciled/verified with the system?
Printout
- Is the QR code printed on every printout / receipt?
- Does the printout comply with the legal requirements?
- Is each receipt printed (or provided electronically) and handed over to the customer?
- Is a possible TSE failure noted on the printout?
- Has the PrintMessage (mandatory!) of the FiscalResponse been implemented on the printout?
Operation
- How was it ensured that CloudConnect is called when the service is restarted (and the POS application does not notice the restart, only relevant if cloud archiving is active)?
- Was the response code (424, failed dependency) for missing cloud connection intercepted accordingly?
- How is it ensured that the service is running constantly?
- Is a monitoring installed?
- How is it ensured that the ongoing cloud transfer (archiving) is checked to see if it is running properly?
- Is the endpoint /api/v1/information/client/{clientId}/status used to continuously check the open cloud transfers?
- Is the physical (local) proximity of the POS system to the fiscal service and also to the TSE ensured?
See also FAQ's BSI.
Technical questions/tests
- Have test units been created to check the integration?
- Which test cases are covered by the test units?
- Which business cases are covered by the test units?
- Which tests and test protocols were created?
- How is a RetailForce release change handled? Are the test units restarted?
- How does the test process work?
- Is it ensured that only productive terminals (configuration) are used in productive operation?
- Is it ensured that it is not possible to operate the cash register without the connection to the fiscalisation and/or the TSE?
- Is it ensured that it is not possible to easily detach the cash register from the fiscalisation / technical security device by configuration?
Comments
0 comments
Please sign in to leave a comment.