Fiscal Requirements
Implementation of "Act on Registration of Sales No. 112/2016"
Minimum Requirement for the Cash Register Application
After finishing positions and payment registration, the cash register application provides the EFR with the transaction data to be signed and then prints the sales slip, including the signature.
Access to the configuration to respectively control functions of the EFT is to be provided via web-browser locally http://localhost:5618/config or from a back-office PC.
Non-fiscal Transactions
In addition to revenues, all other non-fiscal postings like operator log in / log out, cash deposits / withdrawals, closure and so on may be registered using the EFR, marked by NF=. Thus, the journal kept in combination with cloud storage fulfills the requirements for consistent, coextensive archiving. Representation in XML is formless, but it is recommended to use predefined tags like <Pay> for payments / withdrawals nonetheless.
Functions of the EFR
The EFR fulfills the following functions:
- Fiscal message generation upon ESR data delivered
- Local message signature using the Fiscal Certificate
- Request to the fiscal system EET over HTTPS TLS 1.2
- Response to the cash register application
- Transaction protocol
- Protocol of Grand Totals per tax group
- Retry handling according to regulations in case of network failure
- Tamper-proof archiving (encrypted cloud-storage)
Registration with the Fiscal Portal
Before starting to report to the productive fiscal system, the company has to register with the Czech Fiscal Portal. There the fiscal certificate can be obtained.
Also, the location of the store(s) has to be entered and the message to the Fiscal System has to refer to the corresponding Business premises ID "id_provoz" (Označení provozovny), which is NOT identical with the ESR.TL (Transaction Location) field.
The field id_provoz for the message can be assigned using different methods:
Field ESR.CZ_id_provoz
Value is determined by cash register software
Profile config id_provoz
Value can be specified in EFR configuration's profile form as:
| Element | Example |
|---|---|
| Value | 1-999999 |
TL | id_provoz = ESR.TL |
(TL=id_provoz) | CZ-001=101 CZ-002=102 |
The business premises ID and the number the cash register terminal have to be printed on the receipt:
<Tag Label="provoz/pokl" Value="141/1" Name="TLT"/>
ESR Format
Transaction data is sent to EFR as XML or JSON web request. See request and response format.
The following fields have specific meaning when generating the message to the fiscal system:
| Attribute | Name | Message fields affected |
|---|---|---|
| ESR.D | Date Time | dat_trzby |
| ESR.TT | Transaction Terminal | id_pokl |
| ESR.TN | Transaction Number | porad_cis |
| ESR.T | Total | celk_trzba |
| ESR.CZ_id_provoz | See chapter id_provoz | id_provoz |
| Pos.CZ_field Pay.CZ_field | CZ detail field | See chapter Detail Fields |
As the underscore sign "_" is used as signature payload field separator, you may not use it in fields TL, TT, TN; any occurrence will be replaced by "/" within EFR.
Offline Transactions
If the fiscal acknowledge cannot be obtained within the timespan defined (5000 ms by default), the registration response is sent from EFR to the cash register software with an empty fiscal (FIK) tag. It is marked with Errorcode="#OFFLINE", contains a Sign/PKP tag instead of Fiscal/FIK, and the operator is informed with UserMessage="Systémem EET offline" during the first offline transaction (not to interfere with cashier actions).
The offline transaction is stored in a separate folder and an automatic retry is performed after a delay.
Retry Handling
Automatic retry is performed for all offline transactions, whereas the retry interval is increased up to one hour as long as the fiscal system is not accessible. The final, successful fiscal retry is logged into the fiscal journal file, so the whole transaction is tracked. If retries remain unsuccessful, EFR returns a UserMessage once a day.
According to fiscal law, network repair has to be performed within 48 hours.
VAT Handling
For signature purposes, single receipt/control positions are to be assigned to the following tax groups:
| Tax group | TaxG | Tax rate |
|---|---|---|
| základní sazbou DPH | A | 21% |
| první sníženou sazbou DPH | B | 15% |
| druhou sníženou sazbou DPH | C | 10% |
| Celková částka plnění osvobozených od DPH, ostatních plnění | Z | 0% |
This is achieved either by directly expressing TaxG="A" (A-F) or by matching of value if the percent value is denoted.
Turnovers not fitting into one of the predetermined tax groups (eg. Prc="25%" or TaxG="N") will show in "basic VAT rate" (TaxG="A").
Detail Fields (CZ_field)
The record sent to the fiscal system contains some detail fields besides the transaction totals.
| Item Name (CZ) | Item Name (EN) | XML name | Field No. |
|---|---|---|---|
| Celková částka v režimu DPH pro cestovní službu | Total amount under the VAT scheme for travel service | cest_sluz | 19 |
| Celková částka v režimu DPH pro prodej použitého zboží se základní sazbou | Total amount under the VAT scheme for the sale of used goods ‐ basic VAT rate | pouzit_zboz1 | 20 |
| Celková částka v režimu DPH pro prodej použitého zboží s první sníženou sazbou | Total amount under the VAT scheme for the sale of used goods ‐ first reduced VAT rate | pouzit_zboz2 | 21 |
| Celková částka v režimu DPH pro prodej použitého zboží s druhous níženou sazbou | Total amount under the VAT scheme for the sale of used goods ‐ second reduced VAT rate | pouzit_zboz3 | 22 |
| Celková částka plateb určená k následnému čerpání nebo zúčtování | Total amount of payments intended for subsequent drawing or settlement | urceno_cerp_zuct | 23 (see 3.10.1) |
| Celková částka plateb, které jsou následným čerpáním nebo zúčtováním platby | Total amount of payments which are payments subsequently drawn or settled | cerp_zuct | 24 (see 3.10.1) |
If the transaction contains positions of this kind, mark them with attribute CZ_field, e.g: <Pos ... CZ_field="19" />
The transaction sum will be calculated considering effective subsequent discounts (<Mod>) for position, subtotal or total.
CZ_field="24" (coupon redemption) usually affects a payment element: <Pay Dsc="kupón" Amt="1000.00" CZ_field="24" />
Meaning of CZ_field 23 and 24
Total amount of payments intended for subsequent drawing or settlement shall be loaded in data item 23. The amount shall be stated in the Czech crown. This item is stated in the data message in specific cases. This amount is stated in case of charging (purchase) of various electronic purses, cards, coupons, vouchers and other similar instruments used for subsequent drawing or settlement. A taxpayer is obligated to state this item in case of charging and subsequent drawing is put into effect/realized by the same taxpayer (under the Section 4 of Act on Registration of Sales, both of these transactions are registered sales on condition of accomplishing formal characteristics according to Section 5 Act on Registration of Sales), due consideration of duplicate registration of the same income under the analysis. If the charging or drawing is realized by two different taxpayers, this item (23) doesn't have to be stated in the data message, however it's stating will not be questioned by the authorities that verify or has verified compliance with the obligations under this Act.
Total amount of payments which are payments subsequently drawn or settled shall be loaded in data item 24. The amount shall be stated in the Czech crown. This item is stated in the data message in specific cases. This amount is stated in case of drawing the amount from various electronic purses, cards, coupons, vouchers and other similar instruments which are payments subsequently drawn or settled. A taxpayer is obligated to state this item (as in case of Section 19 paragraph 2 a) of Act on Registration of Sales in case of charging and drawing is realized by the same taxpayer (under the Section 4 of Act on Registration of Sales both of these transactions are registered sales on condition of accomplishing formal characteristics according to Section 5 Act on Registration of Sales) due consideration of duplicate registration of the same income under the analysis. If the charging or drawing is realized by two different taxpayers, this item (24) doesn´t have to be stated in the data message, however it's stating will not be questioned by the authorities that verify or has verified compliance with the obligations under this Act.
Test/Playground Environment
For testing, transactions should be fiscalized against the playground system. Therefore the profile has to be set to fiscal test mode.
Please set this attribute and confirm with Save.
Fiscal Certificate Handling
By law, receipts have to be digitally signed. The certificate used (company specific containing the TaxId DIČ) is issued via the fiscal authority's online system. Certificate file (xxx.p12) and password are confidential. On page http://localhost:5618/control you can upload the certificate file:
The certificate was installed correctly if the green OK bar is shown.
Windows
The certificate is kept in the Windows Certificate Store (non exportable). It can be uploaded locally using the EFR web interface or distributed within a company network using Microsoft administrative tools. In that case, please make sure that the EFR service has sufficient rights to use the fiscal certificate for signatures.
Linux
The certificate files are kept locally in directory EFR/cer/CZ
Certificate assignment
As long as only one fiscal certificate is installed or the TaxId of all certificates installed is unique, this TaxId is automatically assigned to the transaction protocol and the appropriate certificate (test/productive) is used ('no touch installation').
If TaxId of the installed certificates is not unique, or if multiple companies are registering over one EFR instance (e.g. running as cloud service), TaxId has to be specified in client profile http://localhost:5618/profile
Network Access
The Czech fiscal law stipulates online registration of each sale transaction via web request. The resulting transaction acknowledge (FIK) has to be printed on the receipt. Therefore, the machine running EFR must be granted access to the fiscal system EET. Network devices (Router, Firewall) have to be configured accordingly unless a web proxy is used.
The hosts for the firewall settings can be found in chapter firewall setting.
A proxy can be defined in the default profile at http://localhost:5618/profile
The connection can be tested using the "Echo"-feature on http://localhost:5618/control
Specifics
Rounding of Payment Amount
see Business Case Rounding