How to Guide - Fiscal Poland

Fiscal Overview

Fiscalisation is a legal requirement imposed by the Tax Authorities (TA) of an increasing number of countries, but particularly prevalent in the European Union. The common reason, between countries, for fiscal legislation is to record sales in such a way that an inalterable record of each transaction and the VAT due is available to the TA.

Enactor have fiscal solutions available for the majority of European Fiscal countries and continue to work on additional country solutions both inside and outside Europe. Enactor found that a common complaint from retailers was POS providers and Fiscal Software Solutions providers blaming each other when things went wrong. Enactor’s approach to fiscal is to avoid reliance on third parties wherever possible. This allows Enactor to provide solutions that do not have hidden third-party software costs and also ensure customers have a single point of contact.

Whilst Enactor have avoided relying on software partners to provide pre-packed solutions, we recognise the importance of in country experts. We have therefore built a network of partners that both help us initially understand legislation and technical requirements for each country but are also kept on retainer to inform us of any legislation changes and guide us through their implementation. This allows us to keep our solutions up to date and compliant, in what is often a fast-changing area in terms of legislation.

While the reasons for Fiscal legislation are common between countries, unfortunately the approach taken differs from one to the next. Although, there are a number of common patterns outlined below:

Device Based

When each transaction is finalised, it is also sent to physical device which records the transaction in an inalterable way. In some countries, the device also functions as a printer; in others it is USB or network connected device.

Devices contain a fiscal module which will both sign and record each transaction in a write once read many, fiscal memory. The signature produced by the device is usually printed on the receipt so that the customer, or a TA inspector, can see the transaction has been recorded properly. Devices will also have some mechanism to provide the data held to the TA, commonly one of:

• Extract in a defined format, tiggered by the POS

• Internal GPRS connections

• Device requires an ethernet internet connection

• Memory Card that can be given to the TA on request

These Fiscal Devices are certified by the TA and this usually, although not always, means that the POS solution does not need certification.

Service Based

Transactions are sent to an online service provided by the TA which will record the transaction detail and provide a signature back as part of the response. This signature is usually required to be printed on the receipt, in some countries in the form of a QR code. Some TA’s offer an incentive where retail customers can scan the QR code to be entered in a regular lottery, thus encouraging reporting of retailers who are not compliant.

Each country has its own provisions for how to deal with a loss of connection to the service, but it is usual to permit offline sales which, must either be manually recorded or electronically submitted to the TA within a defined timeframe.

Signature Based

In this type of scheme, it becomes the responsibility of the POS to record the transactions in an inalterable way and provide a record of the transactions to the TA. The usual approach is to sign and record each transaction, including the signature of the previous transaction as part of the signed data. This has the effect of producing a chain of signed transactions where a transaction modified at a later date would be detectable, as either the altered transaction or all subsequent transactions would have incorrect signatures.

The second requirement of this type of solution is for the POS solution to be able to provide the transaction data, including signatures, to the TA. This data is usually provided in an XML file often in the common SAF-T format.

Again, it’s common for the signature, or part of it, to be printed on the customer receipt.

Clearly this type of solution requires the TA to have a certain level of trust in the POS provider that they will, properly protect the private key used to sign the transactions and that they will not provide the retailer with a mechanism to alter transactions. It is therefore common for these types of solution to require either a declaration of conformity or formal certification process.

Other Requirements

As well as the above each country has a number of other fiscal requirements that must be adhered to, some of which are common between countries, for example:

• Sales and Returns are not permitted in the same transaction

• Transaction value must be positive

• Ability to produce X and Z reports in a prescribed manner

• Items may not be discounted to zero or negative values

• Particular handling of deposit and balance transactions

• Requirement to produce invoices for transactions that meet particular criteria, over a set value, B2B

• Particular handling of tax for bottle returns

Polish Introduction

The fiscal approach in Poland is based around the use of Fiscal Printers. Enactor have already integrated to the UUPOS FP-20 and FP-T88 FVA devices in this market. These fiscal printers contain a write once read many fiscal memory, which is used to store the values for each transaction. However, the fiscalisation approach is currently in the process of change in Poland. Presently it is possible to use either the old system where transactions are recorded only on a fiscal memory in the printer or the new system where transactions must also be submitted to the authorities online. It will be possible to purchase the old style of offline printer until the end of 2022 after which time only the new online version will be available. Although, old-style printers can be used until there fiscal memory is exhausted.

UUPOS offer an online version of both the FP-20 and the FP-T88 FVA and since the online communication is handled solely by the printer it is expected that the work required on the Enactor side to support these devices will be minimal.

In Poland the fiscal printers must be certified but there is no requirement to certify the POS or the overall solution.

The fiscal printer memory has a number of limits and after one of these is reached the printer is EOL and will need to be replaced.

• 2,100 Closed Fiscal Days

• 30 Tax Rate Changes

• 350,000 Unique Products Ever Sold

Each fiscal transaction on the POS will result in the printing of a fiscal receipt which must contain the fiscal mark. The format of the receipt is defined in the legislation and can only be altered in limited ways by including custom headers, footers and a logo at the start of the receipt. The receipt must contain an identifier for the operator although this can be an ID rather than their name; this should be considered when setting up Polish users.

It is possible to discount items at the time of sale or to change the price of items, but the total of the receipt must always be positive. For this reason, returns and like for like exchanges are handled as non-fiscal receipts. The accounting of tax for returns must be manually handled by the retailers accounting department.

As well as printing fiscal receipts the printer can also be used to print non-fiscal receipts in the same way as any normal thermal receipt printer. The only requirement of a non-fiscal receipt is that it must not contain the fiscal mark and it has text in Polish (NIEFISKALNY) to announce that it is a non-fiscal receipt at the beginning and the end. These non- fiscal receipts can be used for things like printing cash management slips since cash management transactions are non-fiscal in Poland. Receipt Copies are also non-fiscal receipts and should not contain the fiscal mark.

It is necessary to be able to print a number of reports, X, Y and Periodic. The production of these reports is handled by the printer but triggered by the POS, in the case the of the Periodic report the POS also supplies the from and to dates to the printer, after capturing them from the operator. Of these reports the only one which must be produced is the Z report. The Z report must be produced at least once every 24-hour period and the report receipt must be kept by the retailer for 5 years. For this reason, it is recommended to link the production of this report to the day end process.

In the case of an invoice being issued, the fiscal receipt must also contain the tax id of the customer, this will be captured on the POS when requesting an invoice, and the invoice number. Invoice fiscal receipts contain a more detailed tax breakdown than normal fiscal receipts. The retailer is also free to print an additional non-fiscal invoice document as well as the fiscal receipt. Additional receipts can be printed on either the fiscal printer or some other printer, for example, an A4 laser printer.

When taking a deposit for an item, a fiscal receipt must be issued for the value of the deposit. When the customer returns and pays the balance a second fiscal receipt should be issued for the full amount but with a discount of the original amount paid as a deposit.

Configuration Overview

The following configuration changes are required and should be broadcast to all Polish devices in preparation for go live.

POS Terminal Template

The POS Terminal Template used by all devices in Poland should be configured to have the fiscalisation Type set to Poland. Currency should be set to Polish Zloty and Locale to Polish (Poland).

The receipts should be set to the standard 42 col width versions.

Within the Tax section the Tax Region should be set to Poland and the Tax Scheme to the Polish tax scheme, the configuration of these will be described in a following section.

Location

There are no required configurations for the location but the header, footer and logo for the receipt will be picked up from here if they are configured.

The logo should satisfy the following conditions:

• Width - maximum of 360

• Height - maximum of 256

• Width and Height should be multiples of 8

• The image must be a monochrome bitmap

Tax Groups

The following tax groups should be configured and broadcast to the appropriate Polish devices.

Tax Group ID	Description
PL_0	Liable for no tax
PL_1	Liable for full tax
PL_2	Liable for reduced tax
PL_3	Liable for reduced tax

Tax Scheme

The following tax scheme should be configured and broadcast to the appropriate Polish devices.

Tax Scheme ID	Description	Price Include Tax
PL	PL VAT	TRUE

Tax Rates

The following tax rates should be configured and broadcast to the appropriate Polish devices. Products to be sold in Poland should have the relevant Tax Rate configured against them.

Tax Group ID	Description	Tax Group ID	Description	Tax Group ID		Description	Tax Group ID
PL_0	Liable for no tax	PL_0	Liable for no tax		PL_0	Liable for no tax	PL_0
PL_1	Liable for full tax	PL_1	Liable for full tax		PL_1	Liable for full tax	PL_1
PL_2	Liable for reduced tax	PL_2	Liable for reduced tax		PL_2	Liable for reduced tax	PL_2
PL_3	Liable for reduced tax	PL_3	Liable for reduced tax		PL_3	Liable for reduced tax	PL_3

Tax Group Tax Methods

The following tax group tax methods should be configured and broadcast to the appropriate Polish devices.

Tax Group	Tax Region	Tax Scheme	Tax Rate
PL Liable for no tax	Poland	PL VAT	Liable for no tax
PL Liable for full tax	Poland	PL VAT	Liable for full tax
PL Liable for reduced tax	Poland	PL VAT	Liable for reduced tax
PL Liable for reduced tax	Poland	PL VAT	Liable for reduced tax

Privileges

The following privileges will need to be configured and broadcast to the appropriate Polish devices.

Privilege ID	Package
enactor.pos.fiscal.SetHeaderAllowed	POS Fiscalisation
enactor.pos.fiscal.AuthorisesSetHeader	POS Fiscalisation
enactor.pos.fiscal.SetFooterAllowed	POS Fiscalisation
enactor.pos.fiscal.AuthorisesSetFooter	POS Fiscalisation
enactor.pos.fiscal.SetLogoAllowed	POS Fiscalisation
enactor.pos.fiscal.AuthorisesSetLogo	POS Fiscalisation
enactor.pos.PrintFiscalReportsAllowed	POS Fiscalisation
enactor.pos.fiscal.SyncVATAllowed	POS Fiscalisation
enactor.pos.fiscal.AuthorisesSyncVAT	POS Fiscalisation
enactor.pos.fiscal.SyncTimeAllowed	POS Fiscalisation
enactor.pos.fiscal.AuthorisesSyncTime	POS Fiscalisation
enactor.pos.RequestSimpleFiscalInvoiceAllowed	Enactor POS
enactor.pos.ChangeFiscalInvoiceNumberAllowed	POS Fiscalisation

Menus

At an appropriate point within your Polish POS menu structure, suggested on the Admin menu, a fiscalisation menu with the following 5 items will need to be configured and broadcast the Polish POS devices.

Event	ID	Button Label	Data Name	Data Type	Data Value
Fiscal_Set_Header	Fiscal_Set_Header	Set Header	ConfigType	String	SET_HEADER
Fiscal_Set_Footer	Fiscal_Set_Footer	Set Footer	ConfigType	String	SET_FOOTER
Fiscal_Set_Logo	Fiscal_Set_Logo	Set Logo	ConfigType	String	SET_LOGO
Fiscal_Sync_VAT	Fiscal_Sync_VAT	Sync VAT	ConfigType	String	SYNC_VAT
Fiscal_Sync_Time	Fiscal_Sync_Time	Sync Time	ConfigType	String	SYNC_TIME

The following items also need to be configured at a convenient point in the sales menu.

Event	ID	Button Label	Data Name	Data Type	Data Value
RequestSimpleFiscalInvoice	RequestSimpleFiscalInvoice	Request Simple Fiscal Invoice
Fiscal_Print_Receipt_Copy	Fiscal_Print_Receipt_Copy	Fiscal Receipt Copy
Fiscal_PrintReports_X	Fiscal_PrintReports_X	Fiscal X Report	ReportType	String	X
Fiscal_PrintReports_Z	Fiscal_PrintReports_Z	Fiscal Z Report	ReportType	String	Z
Fiscal_PrintReports_Periodic	Fiscal_PrintReports_Periodic	Fiscal Periodic Report	ReportType	String	Periodic