Skip to main content

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

Special consideration​

Simplified invoices are essentially streamlined sales receipts that contain minimal information. Unlike a standard invoice, which lists comprehensive customer details such as name, billing address, and VAT number, a simplified invoice requires only a VAT number or Fiscal ID. This type of invoice is permissible only when the total order amount remains below a certain threshold. For Poland, a simplified invoice would be issued when the order amount is 450 Zloty or below and a NIF/VAT is set.

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 in case of a phased go live or country level for a big bang go live.

DEFAULT on Ecom organisations like DGC, SOS & Consumer app in that country.		Sets the certified aspects.

Poland will result in an audit file for that OU, while Default will not.
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 close 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
Checking missed configuration(s)

Once you're done with all configuration steps. Make sure to use the Validate audit configuration button to check if any compliance-related configurations or data is missing or successfully configured.

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
  • TaxOfficeNumber
  • 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 setup instructions and additional information on Certified Invoices, please visit the Stencils for certified countries documentation page. To attach a certified invoice to an email, a separate stencil is necessary. You can find the configuration details for this stencil on the same page.

Sample PDF and Thermal Receipts

You can generate a preview of your PDF invoice or Thermal Receipt using the Stencil chapter. Remember, the order details in the preview will be substituted with the actual order information. Additionally, we advise printing a real PDF invoice and thermal receipt during your testing, and to not rely solely on this preview feature.

Stencil Preview Feature

Below is an example of the CertifiedInvoice template preview found in the Stencil chapter of Admin Suite.

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.

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

X/Z reports​

Reports are essential for daily financial reconciliation, inventory management, and ensuring accuracy in sales tracking and reporting.

In EVA we make the differentiation between two types of reports: X report and Z report.

  • X report (Middle of Day report): Summary statement of the day's sales totals without any notion of closing or generation of cumulative data.

    • X reports can be generated at any time during the day without affecting the ongoing totals.
    • It provides a snapshot of sales, VAT collected, breakdown of payment methods, date and time, without resetting counters.
    • It is not possible to re-generate a specific X report as they are snapshots of the current state.
    • The X report is station specific.

  • Z report (End of Day report): Definitive summary statement of sales totals associated with a daily closing and the generation of daily cumulative data.

    • Z reports are generated by closing of the financial period in EVA, typically at the end of a business day.
    • Summaries of certain data, and therefore don't contain any detailed data at transactions level. The Z total reports and all data supporting the reports will need to be retained.
    • It provides a summary of total sales, VAT collected, the breakdown of payment methods, date, time and sequential number
    • The Z report is station specific.

How to generate the reports​

EVA can generate a daily X and Z reports by closing the Financial Period, or via the terminal report service: GenerateTerminalReport. The Event ledger in EVA will show all the generated reports.

Each report will be tagged with a unique, sequential identification number that follows a chronological order. It maintains a database of these reports for the current year (or financial period) and archives the data from the six preceding years (or financial periods) that have been concluded.

How to set-up the TerminalReport stencil​


Sample stencil

<report>
    <scope bold="true" align="center">
        {{>Document.Type == 0 ? 'X Report' : 'Z Report'}} {{if Number && Number > 0}}#{{>Number}}{{/if}}
    </scope>
    
    <feed amount="32" />
    
    {{if Document.Supplier}}
        <scope align="center">
            {{>Document.Supplier.Name}}
            
            {{if Document.Supplier.Address}}
                 {{>Document.Supplier.Address.Address1}} {{>Document.Supplier.Address.Number}}
                 {{>Document.Supplier.Address.Address2}}
            {{/if}}
            
            {{>Document.Supplier.PhoneNumber}}
            {{>Document.Supplier.Email}}
            
            {{if Document.Supplier.EstablishmentNumber }}
                Establishment number {{>Document.Supplier.EstablishmentNumber}}
            {{/if}}
            
            {{if Document.Company}}
                {{if Document.Company.RegistrationNumber}}
                    Registration number: {{>Document.Company.RegistrationNumber}}
                {{/if}}
                
                {{if Document.Company.IndustryCode}}
                    Industry code: {{>Document.Company.IndustryCode}}
                {{/if}}
                
                {{if Document.Company.TaxRegistrationNumber}}
                    VAT number: {{>Document.Company.TaxRegistrationNumber}}
                {{/if}}
            {{/if}}
        </scope>
        
        <feed amount="32" />
    {{/if}}
    
    
    <feed amount="32"/>
    
    Date: {{:~date(Document.Date, 'DD.MM.YYYY', 'nl-NL', 'Europe/Amsterdam')}}
    Hour: {{:~date(Document.Date, 'HH:mm:ss', 'nl-NL', 'Europe/Amsterdam')}}
    
    <feed amount="32"/>

    <grid positions="0, 30">
        <row>
            <col width="20">
                <bold>Change</bold>
            </col>
            <col>{{:~currency(Document.Change, ~root.CurrencyID)}}</col>
        </row>
        <row>
            <col width="20">
                <bold>Cash drawer openings</bold>
            </col>
            <col>{{>Document.CashDrawerOpenings}}</col>
        </row>

        <row>
            <col width="20">
                <bold>OpeningAmount</bold>
            </col>
            <col>{{>Document.OpeningAmount}}</col>
        </row>

        <row>
            <col width="20">
                <bold>ClosingAmount</bold>
            </col>
            <col>{{>Document.ClosingAmount}}</col>
        </row>

        <row>
            <col width="20">
                <bold>CashDepositsTotalAmount</bold>
            </col>
            <col>{{>Document.CashDepositsTotalAmount}}</col>
        </row>

        <row>
            <col width="20">
                <bold>Payments</bold>
            </col>
            <col>{{: Document.Payments ? Document.Payments.length : 0}}</col>
        </row>

        {{for Document.Payments}}
        <row>
            <col width="20">
                {{>Type.Name}} ({{>Count}})
            </col>
            <col>{{:~currency(Amount, ~root.CurrencyID)}}</col>
        </row>
        {{/for}}

        <row>
            <col width="20">
                <bold>Taxes</bold>
            </col>
            <col>{{: Document.Taxes ? Document.Taxes.length : 0}}</col>
        </row>   

        {{for Document.Taxes}}
        <row>
            <col width="20">
                {{>Name}} ({{:~rateToPercentage(Rate)}})
            </col>
            <col>{{:~currency(Amount, ~root.CurrencyID)}}</col>
        </row>        
        {{/for}}

        <row>
            <col width="20">
                <bold>Payments per employee</bold>
            </col>
            <col>{{: Document.PaymentsPerUser ? Document.PaymentsPerUser.length : 0}}</col>
        </row>

        {{if Document.PaymentsPerUser}}
        {{for Document.PaymentsPerUser}}
        <row>
            <col width="20">
                Employee(s) {{>UserID}} ({{>Count}})
            </col>
            <col>{{:~currency(Amount, ~root.CurrencyID)}} ({{>Description}})</col>
        </row>
        {{/for}}    
        {{/if}}

        <row>
            <col width="20">
                <bold>Product groups</bold>
            </col>
            <col>{{>Document.ProductGroups.length}}</col>
        </row>

        {{for Document.ProductGroups}}
        <row>
            <col width="20">
                {{>Code}} ({{>Count}})
            </col>
            <col>{{:~currency(Amount, ~root.CurrencyID)}}</col>
        </row>
        {{/for}}

        <row>
            <col width="20">
                <bold>Number of discounts</bold>
            </col>
            <col>{{>Document.DiscountCount}}</col>
        </row>
        <row>
            <col width="20">
                <bold>Total discounts</bold>
            </col>
            <col>{{:~currency(Document.TotalDiscounts, ~root.CurrencyID)}}</col>
        </row>     

        <row>
            <col width="20">
                <bold>Number of returns</bold>
            </col>
            <col>{{>Document.ReturnCount}}</col>
        </row>
        <row>
            <col width="20">
                <bold>Total of returns</bold>
            </col>
            <col>{{:~currency(Document.TotalReturnsAmount, ~root.CurrencyID)}}</col>
        </row> 

        <row>
            <col width="20">
                <bold>Number of duplicate receipts</bold>
            </col>
            <col>{{>Document.CopyReceiptsPrinted}}</col>
        </row>
        <row>
            <col width="20">
                <bold>Total receipts</bold>
            </col>
            <col>{{:~currency(Document.TotalCopyReceiptsAmount, ~root.CurrencyID)}}</col>
        </row>      

        {{* Grand totals *}}
        <row>
            <col width="20">
                <bold>Grand total (cash payment)</bold>
            </col>
            <col>{{:~currency(Document.GrandTotalCash, ~root.CurrencyID)}}</col>
        </row>
        <row>
            <col width="20">
                <bold>Grand total</bold>
            </col>
            <col>{{:~currency(Document.GrandTotal, ~root.CurrencyID)}}</col>
        </row>        
        <row>
            <col width="20">
                <bold>Grand total (returns)</bold>
            </col>
            <col>{{:~currency(Document.GrandTotalReturns, ~root.CurrencyID)}}</col>
        </row>        
        <row>
            <col width="20">
                <bold>Grand total (excluding tax)</bold>
            </col>
            <col>{{:~currency(Document.GrandTotalNet, ~root.CurrencyID)}}</col>
        </row>        
    </grid>

    <feed amount="32"/>
    
    Terminal: {{>TerminalCode}}
    StationID: {{>StationID}}
    Station name: {{>StationName}}
    
    <feed amount="16"/>

    <scope align="center">
        <qrcode data="{{:ZippedSignature}}" size="6"/>
    </scope>

    <feed amount="16"/>
</report>

Automated printing Z report(s)​

When the setting Auditing:PrintTerminalReport is enabled and you have set the stencil TerminalReport we will automatically print the Zreport when you close your financial period. If you have multiple stations on your store, we will print all the Z reports on the stations that you are logged into when closing your financial period.

Printer

Be aware that this station needs to have a printer otherwise the Zreports will not be printed.

Fiscal archiving & audit files​

There are no compulsory regulations set by the authorities in this country when it comes to creation of Audit files. However, tax registered entites are obligated to maintain comprehensive records. This includes the retention of detailed information regarding all goods and services rendered to taxable parties.

To facilitate swift retrieval of such records for submission to tax Authority (if needed), our white label audit files can be used. The audit file(s) include an overview of underlying tax information/operations readily available upon any requests from the authorities (file is in JSON format).

More on generating Audit files can be found here.

Automate generation of audit files​

The CreateFinancialPeriodAuditTask could be configured to trigger generation of audit files at specific date/time. This task will basically do an automated generation of the audit files mentioned above in the start of step 9, which depicts the manual triggering of these audit files.

The following can be configured from the Scheduled tasks chapter, while filling in the fields as follows:

Type: EVA.Auditing.Tasks.CreateFinancialPeriodAuditTask

  • Name: Any unique name you want
  • Schedule: a cron value example, 0 4 2 * * . Test what you want your cron to look like here, then specify the exact value in this field i.e. the recurring point of time that would trigger this task.
  • Settings
    • Type: can be left blank
    • Organization unit: the ID of the country that this report would pertain to i.e. The Polish organization unit type store.
    • Email address: In case of task failures the email address you mention here will receive a notification. This is an optional field but quite handy.

NTH integration and digital email receipts​

When making use of the NTH integration in Poland, you can optionally configure EVA to send consumers in Poland their digital receipts via email for e-commerce orders.

Configuration
  • Setting: EVA can send digital receipts by email based on a new setting Auditing:Poland:NTH:MailEReceiptToCustomer. By default, this setting is false. When set to true, EVA will email the receipt to the customer's email address.
  • Email Template: The email uses the ElectronicReceipt stencil template, which needs to be set up and maintained by you. The eReceipt will be included as an attachment.
  • SMTP Settings: These need to be configured at the root level since there is no middleware context.
  • Template Hierarchy: The ElectronicReceipt stencil should be set for the specific Organization Unit (OU) where the order was made. If not found, EVA will search up the OU hierarchy and use the default stencil message if necessary.
  • Disable Emails Setting: Ensure DisableEmails is set to false on the webshop or inherited from the root.

Regarding errors

  • Failure Case: The only failure scenario is if the ElectronicReceipt stencil is explicitly disabled.
  • Failure notifications: NTH Rejection/Failure Notification Emails now use a new NTHRejectionNotification stencil template for further customization.