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.

Country	Check	Description	Docs
	Sandbox fiskaltrust.Account created	An account and a POS-System (ftPosSystemId) in the sandbox fiskaltrust.Portal was created to create test Middleware instances.	Getting Started Guide
	Production fiskaltrust.Account created & partner contract signed	An account in the production fiskaltrust.Portal was created to manage POS-Systems, and the PosCreator role was activated.	Getting Started Guide
	Applying for Certification or Attestation	One 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
	API methods are implemented	The POS-System can call the Middleware's API via the protocol of choice	Function structures & Communication protocols
	Business sequences are implemented	The 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
	Receipt headers are included	The correct values are passed for ftCashBoxID, ftPosSystemId, cbTerminalID, cbReceiptReference and cbReceiptMoment.	Data structures & relevant country-specific appendices
	Special receipts are implemented	Initial 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
	Error handling is implemented	The different types of errors (Middleware not reachable & signing device/service not reachable) are properly handled by the POS software	Cash register integration & relevant country-specific appendices
	Signatures are printed onto the physical receipts	The 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
	POS-Systems are created in the production Portal	One 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
	PosDealers are invited and connected to POS-Systems	The 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
	Certification or Attestation is done	Either the certification (manadatory, if the POS-System is developed for own usage) or the attestation has successfully been finished.	Contact our experts
	(Optional): Correct usage of business cases is approved by tax consultant	A 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
	(Optional): DSFinV-K export is approved by tax consultant	A 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
	(Recommended): Open TSE transactions are properly handled	In 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)