Skip to main content

๐Ÿ‡ต๐Ÿ‡ฑ Poland

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

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.

SettingValueOrganization unitDescription
Auditing:ProviderPOLAND or DEFAULTPOLAND 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:WelcomeMessageAs you pleaseRoot level or container levelThis message is shown on the CFD of the Poland Printer.
UseInvoiceOutputFacadetrueRoot level or container levelAttaches 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.
UseLegacyReceiptPrintingBehaviortrueRoot level or container levelTrigger the POS and/or Companion App to use ProduceDocuments with an InvoiceID instead of an OrderID.
Auditing:UseInvoiceCloningtrueRoot level or container levelUsed to toggle automatic creation of clones, for unique sequence numbers, on and off (experimental)
App:Documents:DefaultPrintReceiptfalseRoot level or container levelDetermines if the print receipt checkbox after payment should be default checked or not.
CashDrawer:CashDrawerBlockingRequesttrueRoot level or container levelLet EVA know it needs to wait for the cash drawer to open before commencing with the receipt print.
UniqueInvoiceNumberSequencetrueRoot level or container levelMakes sure the invoice number sequence is unique. Otherwise, issues might occur when syncing invoices between EVA and the fiscal printer.
Auditing:DailyConsolidation:MailToinput desired email addressContainer levelThe email address that would be receiving the reports from the report task called DailyConsolidationReportTask

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.

Further, please make sure to fill all the auditing fields for your respective Polish OU's.

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 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.

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.

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).

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) with Purchase (GWP) is given 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 gift card sales. The sale of gift cards 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 gift card sales. However, the redeeming (actual use of the gift card 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 EVA Admin to Fiscal Archiving โ†’ Archive.

In the top-left corner, click Create audit, then choose the applicable organization unit and specify the fiscal period.

When no fiscal period is specified, the audit file will contain all events from the creation of the last audit file up to the current point in time.

note

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

Preview modeโ€‹

In the pop-up window, there is an option to select Preview (this is selected by default).

When the preview mode is turned on, you would be able to preview/verify the audit file without generating the actual file. When the preview mode is turned off, an actual audit file will be generated. The audit file will contain all the events recorded since the last time an audit file was generated. This would result in having multiple audit files when there would have already been a file generated in the same fiscal period. Therefore, having preview mode turned on will ensure that only one audit file will be generated per fiscal period.

Once an audit file is generated, it cannot be deleted. If one file is needed for a full fiscal period where multiple audit files have been created, then the generated files would need to be merged manually.

Audit files will show up in the Archive, where it can then be downloaded. In the Preview column it is specified whether the preview mode was turned on during the creation of the file or not.