Skip to main content

Integration Checklist

Integrating the fiskaltrust.Middleware involves several steps, from calling the API the right way to registering in the production fiskaltrust.Portal and connecting to Dealers. To simplify this process for POS Creators, we've composed a concise checklist that can be used to validate if all required steps were succesfully performed.

CountryCheckDescriptionDocs
All marketsSandbox fiskaltrust.Account createdAn account and a POS-System (ftPosSystemId) in the sandbox fiskaltrust.Portal was created to create test Middleware instances.Getting Started Guide
All marketsProduction fiskaltrust.Account created & partner contract signedAn account in the production fiskaltrust.Portal was created to manage POS-Systems, and the PosCreator role was activated.Getting Started Guide
FranceApplying for Certification or AttestationOne of the two confirmations must be achieved for law conformity. Either the process for certification (manadatory, if the POS-System is developed for own usage) or the attestation is started.Contact our experts
All marketsAPI methods are implementedThe POS-System can call the Middleware's API via the protocol of choiceFunction structures &
Communication protocols
All marketsBusiness sequences are implementedThe required business cases (i.e. the ftReceiptCases, ftChargeItemCases and ftPayItemCases) are implemented. Depending on the POS-System, not all cases might be required (only those which make sense for your use case).Receipt cases & relevant country-specific appendices
All marketsReceipt headers are includedThe correct values are passed for ftCashBoxID, ftPosSystemId, cbTerminalID, cbReceiptReference and cbReceiptMoment.Data structures & relevant country-specific appendices
All marketsSpecial receipts are implementedInitial operation, zero, daily-, monthly- and yearly-closing, out of operation and other special receipts are implemented (country-specific mandatory) via the respective ftReceiptCases.Receipt cases & relevant country-specific appendices
All marketsError handling is implementedThe different types of errors (Middleware not reachable & signing device/service not reachable) are properly handled by the POS softwareCash register integration & relevant country-specific appendices
All marketsSignatures are printed onto the physical receiptsThe ftSignatures returned by the Middleware are properly printed onto the physical receipts. Please note that generally all items need to printed, with some exceptions in Germany (more details available in the linked docs).Reference tables & relevant country-specific appendices
All marketsPOS-Systems are created in the production PortalOne POS-System per model (not per actual device) is created in the Portal, and its ID is used as ftPosSystemId in sign requests.Getting Started Guide
All marketsPosDealers are invited and connected to POS-SystemsThe PosDealers distributing the device are either invited by their PosCreator or created their accounts themselves, and are connected to the previously created POS-System.Getting Started Guide
FranceCertification or Attestation is doneEither the certification (manadatory, if the POS-System is developed for own usage) or the attestation has successfully been finished.Contact our experts
All markets(Optional): Correct usage of business cases is approved by tax consultantA tax expert who is familiar with the business sequences that are implemented via the Middleware approves the correct usage of receipt-, charge item- and pay item cases.Getting Started Guide
Germany(Optional): DSFinV-K export is approved by tax consultantA tax expert who is familiar with the business sequences that are implemented via the Middleware approves the content of a sample or live-data DSFinV-K export created via the Middleware or the fiskaltrust.Portal (Please note that structural integrity is already certified, and that there's the option to obtain a marketing package from Audicon. More details can be found here).Getting Started Guide
Germany(Recommended): Open TSE transactions are properly handledIn the daily business it's possible that some transactions stay open in the TSE. Most of the time this is caused by the finish-transaction not reaching the TSE. Reasons for this are often: network errors, a unplugged TSE or a power outage. If these transactions stay open at the time of the daily-closing then the Middleware won't be able to delete the exported TSE-Logs (content of the TAR-file) and therefore the size of the exported TAR grows in size every export. Since the TAR is saved in the local Middleware database, the database can reach mutliple Gigabyte in size. By law the maximum limit of open transactions is 500. When this limit is reached, the TSE won't sign any new transaction. To prevent this, we strongly recommend to implement the following process flow into your interagtion: Before sending a daily-closing-receipt... (1) send a Zero-Receipt with TSE-Info to the queue. The ftState property of the response will then contain the CurrentStartedTransactionNumbers. (2) close this array of open transactions using a Failed-Receipt(for multiple transactions)