🇵🇱 Poland

This document describes all necessary configuration for a compliant setup in Poland.

Local mode support

Local mode is currently not supported. Activating local mode is done at your discretion and risk. We strongly recommend conducting thorough testing of local mode before going live to ensure it aligns with your expectations.

If you require support for local mode in compliance countries, please submit a JIRA development ticket, namely a request for change.

Configuration

In order to configure your store in Poland to be compliant, the following configurations need to take place.

Settings

All settings below should be set on the most convenient level possible. In other words, if your organization structure has a country organization which houses all Polish stores, then that's where they should go.

Setting	Value	Organization unit	Description
Auditing:Provider	POLAND or DEFAULT	POLAND on store OU's when phased go live or country level when big bang go live. DEFAULT on Ecom organisations like DGC, SOS & Consumer app in that country.	Sets the certified aspects
Auditing:Poland:WelcomeMessage	As you please	Root level or container level	This message is shown on the CFD of the Poland Printer.
UseInvoiceOutputFacade	true	Root level or container level	Attaches the certified invoice PDF when emailing the invoice from POS and/or Companion App. This setting enables the use of the CertifiedInvoice stencil with destination Mail.
UseLegacyReceiptPrintingBehavior	true	Root level or container level	Trigger the POS and/or Companion App to use ProduceDocuments with an InvoiceID instead of an OrderID.
Auditing:UseInvoiceCloning	true	Root level or container level	Used to toggle automatic creation of clones, for unique sequence numbers, on and off (experimental)
App:Documents:DefaultPrintReceipt	false	Root level or container level	Determines if the print receipt checkbox after payment should be default checked or not.
CashDrawer:CashDrawerBlockingRequest	true	Root level or container level	Let EVA know it needs to wait for the cash drawer to open before commencing with the receipt print.
UniqueInvoiceNumberSequence	true	Root level or container level	Makes sure the invoice number sequence is unique. Otherwise, issues might occur when syncing invoices between EVA and the fiscal printer.
Auditing:DailyConsolidation:MailTo	input desired email address	Container level	The email address that would be receiving the reports from the report task called DailyConsolidationReportTask

Checking missed configuration(s)

Once you're done with all configuration steps. Make sure to run the service: AuditingValidateConfiguration which should return any step(s) that you may have missed or possibly undocumented.

Company

When configuring your Polish organization unit(s), a company needs to be attached. If there isn’t a Polish company present yet, a new one can be created within Admin Suite under the Companies chapter. The following fields need be filled:

• Name
• VatNumber
• RegistrationNumber
• Address (VisitorAddress)
  • Street
  • HouseNumber
  • ZipCode
  • City
  • CountryID

Organization units

Once a company is in place, you need to attach it to an organization unit.

Make sure the following fields are filled when creating an organization unit:

• Name
• BackendID (store number)
• BranchNumber
• Address
  • Street
  • ZipCode
  • City
  • CountryID
• CompanyID

note

It is crucial that you have the CompanyID field filled when creating the organization unit. You can retrieve this ID from the Polish company you created/have. This is the legal entity under which this OU/store is operating and will be referred to when filling in the details on the invoices and receipts.

Stations

You can find steps on adding a new station here.

When creating a station, make sure the following fields are filled in:

• Station name.
• The checkmark This station is a fiscal station and will be used for transactions needs to be checked.

note

• All payment types must have a category, otherwise the payment can't be correctly mapped, and Ship Orders would fail.
• The Thermal Fiscal Printer and the Cash Drawer should both have Assembly name UPos.
• Station must be added in Live Guard first without devices, then use the ProxyID in the URL of Live Guard to add a station with a FiscalID (3 numbers) via CreateStation in Dora.

Tasks

In order to create a reconciliation report and spot any differences between the Poland fiscal printer and EVA at financial period closure, the following task can be set up from Admin 1.0 under Management → Tasks:

The task is called EVA.Auditing.Tasks:DailyConsolidationReportTask, once set up it will run every day at 23:55. It will consolidate all ledgers of DailyTotalsConsolidation and place them in an Excel called report.xslx and email that file to you.

The email will be sent to the address specified in the setting called Auditing:DailyConsolidation:MailTo. You will also need SMTP settings, and a Stencil with the following configuration:

• Type: Template
• Organization: Leave empty
• Name: DailyConsilidation
• Country: None
• Language: Emptry
• Layout: None
• Destination: Email
• Content: As you wish

The reconciliation report sending task pertaining to EVA.Auditing.Tasks:DailyConsolidationReportTask (referred to above), is triggered only at financial period closure. Thus, if a financial period for a store was not closed, the report will not generate.

note

Using a setting Auditing:AuditGeneratorName with value DOCUMENT_STORE_AUDIT_GENERATOR allows for an optimized audit file generation.

To make sure that such incidents do not occur, a task called EVA.Core.Tasks.ShopOpenClosingEvents can be created which would basically check if there are any open financial periods that are missed for closure.

• The task runs every hour.
• If there are any open financial periods 3 hours before the store opening hours an email notification will be sent to the email address specified in the Auditing:DailyConsolidation:MailTo setting.
• If there are no opening hours specified for the store, no email will be sent.
• SMTP settings, and a Stencil with the same configuration as mentioned above, except for the name (name should read: UnprocessedFinancialPeriod).

Stencil

Stencils are only synced after financial period closure.

Due to Polish hardware requirements, adjustments to printing templates like receipts and invoices can only be made when the printers are in a non-fiscal state and that occurs only when financial period is closed. Therefore, updates to stencils should be performed only after the closing of a financial period.

Certified invoices

For configuration and more details about Certified Invoices please refer to the general concepts section under Certified invoice stencil for thermal &/or PDF . A separate stencil is required to set up the email in which a certified invoice would be attached to. Configurations for such stencil can be found under Email invoice stencil.

Sample PDF and thermal receipts

• Sample PDF invoice

Updating the printer firmware

For some cases the printers need to run on the latest software version. For example to support a 100% discount on a product, firmware version 3.02 is the minimum version.

Fiscal Printer from Exorigo-Upos

The FP-T88FVA fiscal printer from Exorigo-Upos is used in Poland for recording the turnover from sale of goods and services, and the respective amount of due tax.

For the fiscal printer to perform this function, a computer with a sales and electronic copy archiving program must be connected.

Fiscal mode

For this mode of operation, the printer passes through a qualified service technician’s fiscalization. User's NIP (Tax ID No.) is printed on the header and fiscal logo is printed on the footer.

The most important rule in this fiscal printer mode is to store fiscal information about sales and taxes that occurred in a fiscal period. This is a permanent record where such information can be retrieved at a later point in time.

note

In instances where receipts were issued to the printer however, unfinished prior to the fiscal period closure would impact the stored/recorded values of the respective fiscal period.

VAT invoice printing principles

• There is no possibility of giving an increase to the sales line as it happens during receipt printing. However, it is possible to grant a discount or a discount correction (decrease).
• During a sale it is not possible to cancel the sale of a single article but rather the entire invoice.
• Any entire invoice can be canceled at any time during the sale however, must be before a sale is concluded.
• It is the seller's responsibility to check if there is no paper in the station and whether a correct print of the original and the invoice copy is performed or not.
• Invoice printing is only possible on transactions conducted where a company name or a customer NIP (Tax ID No.) is present.
• In a return order flow, a receipt/invoice (PDF) print would not be possible if one was already issued at the time the sales transaction took place.
• Whenever an A4/paper version of a corrective invoice for return orders is being printed, the print would be made twice to comply with regulations (one for the customer and one for the stores archives).

Anonymous receipt print upgrade to invoice (amended behavior)

When an anonymous order is placed, an automatic non-fiscal part is included in the issued fiscal receipt (Paragon Fiskalny). E-mailing an invoice becomes available however, once a customer is attached. In such scenario, the Paragon Fiskalny will be upgraded to a PDF invoice and will bear a new invoice number. The invoice number will reference the original Paragon Fiskalny number. Previously, the issued PDF invoice did not reference the fiscal receipt (Paragon Fiskalny) number.

To turn on this referencing behavior, the setting Auditing:UseInvoiceCloning needs to be set to true.

Minimum unit price and total amount

The minimum value for an order line set on the fiscal printer is 0.01 PLN. This means that a 100% discount on a line is not possible since any line should have that minimum value. This automatically implies that the minimum total order value should also never be lower than the 0.01 PLN.

note

For the sake of compliance to this requirement, sale of zero priced articles (if any) can be prevented on both POS and Companion App using a setting called Sellability:MinimumSalePrice and thus a value of 0.01 is assigned to zero priced articles. A zero priced article can in this case be a promotion where a gift(s) is given with a purchase if certain order criteria are met. In absence of the setting any zero priced items are not sent to the fiscal printer and are not part of the JPK files.

Giftcard sales through the fiscal printer

The specific fiscal printer that is used in Poland does not allow giftcard sales. The sale of giftcards in Poland is only possible through a non-fiscal printer - the Epson T-30 for example. As a result, audit files created will not include giftcard sales. However, the redeeming (actual use of the giftcard value to make a purchase) part is what counts as the regular underlying sales and accordingly, is what shows up in the respective financial period audit files.

JPK Reporting (SAF-T)

Poland introduced the Standard Audit File for Tax (SAF-T) on 1 July 2016 for large taxpayers and became compulsory for all taxpayers as of 1 January 2018. The term JPK stands for "Jednolity Plik Kontrolny".

"SAF-T" replaced "VAT returns" in Poland from 1 October 2020. In EVA, the creation of two JPK files is possible, the JPK_V7M for the monthly VAT returns and the JPK_FA for details regarding VAT invoices.

JPK_V7M & JPK_FA

JPK_V7M

Formerly known as JPK_VAT, the JPK_V7M is a file that needs to be submitted for the monthly VAT returns. This file keeps full records of sales and purchases and should be sent by the 25th of each month. The JPK_V7M is an extensive form which includes classifications of transaction types and codes to identify certain types of goods and services. There are also document types that identify certain transactions. The type of document(s) should also be reported.

For EVA, the generated JPK_V7M contains only sales data (no purchasing data). Transaction types: B2B, B2C, and anonymous sales with all available payment methods are included in the file.

Two main document types are discerned in the file : RO and FP.

The RO is a collective internal document containing information on cash register sales. In the file the total sales value and the total VAT is depicted (returns are not accounted for or depicted in the RO file). This value is a daily total. If a line in the file has the FP attribute, it would imply a reference to invoices of type B2B or B2C transactions. Like the RO document type, each FP invoice depicts the total value and the total VAT. Also, the name of the customer, and in the case of a B2B invoice, the VAT number of the customer. The main use of these files are for VAT declaration purposes.

JPK_FA

JPK_FA(4) files are an extensive structure which contains all details about the invoices issued. It is an extension of the FP document type in the JPK_V7M file. In the JPK_V7M file only basic invoice information is shown: customer VAT number, customer name, date of issuance, total invoice value, total VAT value (according to rates), and currency.

The JPK_FA however, would also contain information on specific types of transactions documented by a given invoice, such as the use of the cash, debit-and credit card, split payment or credit notes, products or services provided, the quantity, and the unit price.

Unlike the JPK_V7M, the JPK_FA does not have to be submitted periodically. This is only at the request of the Polish tax authority. Once requested, a 3-day time window is given to deliver the JPK_FA file.

To sum up, the JPK_V7M file is the file used for the monthly VAT declarations. It contains information on all sales - not only the registered invoices but also anonymous transactions. Information regarding the issued invoices is limited to the name of the customer, VAT number, total amount and total VAT. The JPK_FA on the other hand, provides information regarding the invoices, but in more detail. This file contains additional information regarding the quantities, the products or services provided, and the unit prices. The purpose of these file is to shorten the inspection time for the Polish tax authority.

Creation of the JPK files in EVA

To generate the JPK files in EVA, please follow the following steps:

File generation

To generate an audit file, navigate in the Audit files chapter of Admin Suite.

note

The OU should always be Poland, as the files are generated for all OU’s within the country OU (Poland).