Fiscal Requirements
The EFR serves as a supplementary subsystem to an existing POS application to fulfill the NF525 requirements for systems of category B and C. Follow the rules here and at chapter "Application Requirements". Also, see "Infocert" for distinct responsibilities of the frontend application.
INFOCERT / LNE
EFR serves as a permanent and instant archive according to the fiscal regulations, recording format is standard JSON. Transactions are signed and chained, and so are the journal archive files .jou. Local data storage is monitored and data manipulations are detected and logged.
In Online systems cloud storage serves as a long term archive for 10 years.
If EFR runs in Offline mode (configured in EFR Profile), periodic data backup (usually quarterly) onto an external device is required. See EFR additional functions Maintanance /backup web API for details. In offline mode, no automatic data purge is performed during the retention period.
The combination of frontend POS application and fiscal module (EFR) has to be certified by an officially approved company. Different rules are applied during audit in detail, so for LNE certification the attribute Fiscal_Rules=LNE has to be set in http://localhost:5618/profile.
| Institute | City | Homepage | Attribute |
|---|---|---|---|
| INFOCERT | Saint Jean / Toulouse | https://infocert.org | (default) |
| LNE | Paris | https://www.lne.fr | Fiscal_Rules=LNE |
Details are described in chapters INFOCERT and LNE.
Configuration
NF525 7.1.1.1 regulates the availability of header fields within EFR, the logging of value changes and the administration of historical data.
For centralized administration, base data can be set per cash register terminal (EFR) using the efsta cloud portal, with the data being replicated to the EFR instances.
Alternatively you can supply the header fields with POST http://localhost:5618/cfg.
It is recommended to POST configuration on every program startup before issuing /register. Further details for /cfg can be found in Configuration.
Manual Configuration
Navigate to http://localhost:5618 in your browser and open "Donneés de base" (base data). Enter the field values required, with the data being replicated to efsta cloud.
Field reference
| Element | Attribute | Description | FIDELE label |
|---|---|---|---|
| Cmp | Company header | ||
| Nam | Company name | ENC-TIK-SOC-ETS | |
| Ctry | Country | ENC-TIK-SOC-PAY | |
| TaxId | Intra-Community VAT identifier | ENC-TIK-SOC-TVA | |
| FR_NAF | code NAF / APE Nomenclature d'activités française | ENC-TIK-SOC-NAF | |
| FR_SRN | Business Register Identifier | SOC-SIREN | |
| FR_RCS | City of Registration + Category | SOC-RCS | |
| FR_TYPE | Legal Form | SOC-TYPE | |
| FR_CAPITAL | Social Capital | SOC-CAPITAL | |
| Loc | Location (store) header | ||
| TL | Transaction Location correlating ESR.TL | ||
| Adr | Address | ENC-TIK-SOC-ADR | |
| Zip | PostCode | ENC-TIK-SOC-CCP | |
| City | City | ENC-TIK-SOC-VIL | |
| FR_SIR | SIRET code wikipedia.org | ENC-TIK-SOC-SIR | |
| Trm | Terminal | ||
| TT | Transaction Terminal correlating ESR.TT | ENC-TIK-CAI-NID | |
| SW | Software and Version | ENC-TIK-TAG-VER |
VAT Handling
Following rates are used by default if only TaxG is delivered, but no tax rate in the TaxA element:
| Tax group | TaxG | Tax rate |
|---|---|---|
| Normal | A | 20% |
| Intermédiare | B | 10% |
| Réduit | C | 5,5% |
| Super réduit | D | 2,1% |
| Zero | E | 0% |
Specifics
Document Types
Different fiscal document types can be registered with EFR by specifying the tag <ESR DT="XXX">. For each document type, a separate Document Number DN will be issued and a signature chain will be created. Recommended values include bill, invoice and ticket, but you may use any document denomination you require and are not limited to these.
Transactions without DT are marked as "TIK" ("Ticket") in the signature payload. NF and NFS are considered to be non-fiscal = not to be included in the system's grand totals.
Invoice
An example for invoices can be found in the business case Invoice. Following fields are required to be included in the signature payload:
| Ctm Attribute | Description | FIDELE Label |
|---|---|---|
| Nam | Company name (B2B) or Customer name (B2C) | TAG-FAC-CLI-NOM |
| Zip | Customer postcode | TAG-FAC-CLI-CCP |
| TaxId | Intra-community VAT identifier (B2B) / empty (B2C) | TAG-FAC-CLI-TVA |
If all fields are missing on registration, a warning #MISS ESR.Ctm FACT will be returned.
| Element | Name | Mandatory | Description | Example |
|---|---|---|---|---|
| Ctm | Customer | Yes | Customer data for fiscal invoice | |
| Ctm.Nam | Name | Yes | Customer or Company Name | "Victor HÙGO" |
| Ctm.Nam2 | Name 2 | No | Name Extension | |
| Ctm.Adr | Address | No | Customer or Company Address within City | "123 bis Rue de Trey" |
| Ctm.Adr2 | Address 2 | No | Address Extension | |
| Ctm.Zip | Postal Code | Yes | according to national rules without country prefix | "25000" |
| Ctm.City | City | No | City Name | "Besançon" |
| Ctm.Ctry | Country | No | Country ISO 3166 ALPHA-2 | "FR" |
| Ctm.TaxId | VAT Number | Yes | Company VAT Number including eventual country prefix | "FR-12345678901" |
| Ctm.FR_SIR | SIRET | Yes | for B2B invoices, see NF525 1.7.3 | "732 829 320 0007" |
| Ctm.FR_NAF | NAF/APE | No | "47.11D" |
All fields are datatype text. As with other ESR structures, additional <Ctm> fields may be specified having names longer than 4 characters.
Voucher Handling
Basically there are two types of vouchers:
- "Single-purpose voucher" for specific services or goods, containing VAT at time of voucher sale
- "Multi-purpose voucher" for indifferent goods, showing VAT 0%, as the VAT rate is not yet defined
An example can be found in the business cases Voucher.
Since multi-purpose vouchers have 0% VAT, the sales amount is not added to the total field GT, but in the separate field GTvou.
Variant
In NF525, the sale of multi-purpose vouchers is seen as a treasury transaction, marked non-fiscal NFS="Vou". The usage of the voucher can then be sent as payment <Pay/> since the sale is not regarded in the Grand Totals.
Training Receipts
An example can be found in the business cases Training. Fiscal regulations require the ID of the trainer/supervisor to be stored with the training transaction, use field name FR_Trainer.
Training printouts may not show any amounts and have to be marked by NON VALABLE POUR ENCAISSEMENT.
Periodic Closing / Z Report
According to NF525, periodically closing of the "till" is required, usually once per opening day. An example can be found in the business cases Z-Report.
Transaction totals of the day per VAT rate are delivered in element <Z> along with:
| Element | Description |
|---|---|
| Per | Closure Period (month) |
| ZI | Incremental Z report Index |
| LastD | Last closure Date |
| LastSQ | Internal SeQuence number of last closure; to fetch the transactions included use GET http://localhost:5618/retrieve?_=Tra&last={LastSQ} |
Month/Year Closure
Month and year closures are requested by the French fiscal regulations. They are automatically recorded (in .jou journal file and dat/bal.dat) on the first closure opening a new month. With each month's closure, a year's closure covering the last 12 months is performed as well (if data for more than one month is available). This is especially useful if a company's fiscal year differs from the calendric year.
Period reports (monthly and annual) are stored locally and can be fetched by requests:
GET http://localhost:5618/control/totalGET http://localhost:5618/control/bal
Reprint / Printing Duplicates
Reprints of fiscal documents have to contain a duplicate counter and a signature. Depending on whether your software handles reprints as transaction (journalized and having a Transaction Number TN) there are two ways of signing:
/registera non-fiscal transaction markedNFS="DUP"/jou/reprintcntget duplicate number and signature
- The validity of the transaction reference (by FN or TL/TT/TN) is not checked
- On a multiclient EFR (profile attribute RN_TT is set) counters for cross referenced transactions (registration and reprint done on different terminals) are handled
- Else, counters cannot be shared between EFR instances
- The frontend application is responsible for providing the data of the original transaction. EFR journal commands (
/findor/retrieve; see EFR API Journal) can be used
POST /register
An example can be found in the business cases Reprints.
POST /jou/reprintcnt
| Element | Description |
|---|---|
| Request | /jou/reprintcnt |
| Method | POST |
| Header | Accept: text/xml (optional for XML response) |
| Query | RTL, RTT, RTN Id of transaction RFN Fiscal Number opr Id of the operator requesting the reprint RN in multi-client mode |
| Body | Empty |
Example
- http://localhost:5618/jou/reprintcnt?RFN=FACT:001/1/1&opr=1&RN=001_1
- http://localhost:5618/jou/reprintcnt?RTL=001&RTT=1&RTN=1&opr=1&RN=001_1
Response
<ReprintC SQ="18" RFN="TIK:001/1/1" Cnt="1" DN="5" DT="DUP">
<Cfg FR_LOG="EFR"/>
<Result RC="OK"/>
<Fis>
<Payload>DUP:001/1/5,TIK,1,,20210623111146,TIK:001/1/1,O,__LWtmZ...</Payload>
<Signature>B_ULuvuuexG...</Signature>
<Tag Label="Numéro original:" Value="TIK:001/1/1" Name="RFN"/>
<Tag Label="Code original:" Value="B0000 YYYY" Name="RSec"/>
<Tag Label="Duplicata:" Value="1" Name="ReprintCnt"/>
<Tag Label="Numéro:" Value="DUP:001/1/5" Name="FN"/>
<Tag Label="Code:" Value="B0000 XXXX (NF525)" Name="Sec"/>
</Fis>
</ReprintC>
The incremental count value is delivered in Cnt.
EFR tries to retrieve the original transaction content (ESR) from local storage or cloud, whereas the data objects are included in the response and can be used for printing. A timeout of 8 secs is used for cloud access to ensure a valid response within request timeout (10 secs).
The current reprint count for a document can be retrieved with http GET, although only the count integer field is responded.