EFR Guide [AT] - Efstaefsta.org/wp-content/uploads/2016/11/EFR_Guide_AT_0.9.2_en.pdf · EFSTA Programming Interface 11/23/2016 Revision 1.08 6 2. First steps 2.1 EFR Installation

EFR Guide [AT]

Implementation Details Austria

Author: EXT2

Date: 11/23/2016

Revision: 1.08

Copyright: © efsta 2016

This document amends "EFR Reference"

It refers to EFR version 0.9.2

EFSTA IT grants usage of this document under development license that you agreed

to by downloading this file.

For latest information look at forum.efsta.net

EUROPEAN FISCAL STANDARDS ASSOCIATION

EFSTA Programming Interface 11/23/2016 Revision 1.08 2

Index Index ..................................................................................................................................... 2

1. Introduction .................................................................................................................... 4

1.1 The EFSTA System ................................................................................................. 4

1.2 System Requirements ............................................................................................. 4

1.3 Functional requirements .......................................................................................... 4

1.3.1 Smartcard signature ......................................................................................... 4

1.3.2 HSM signature ................................................................................................. 5

2. First steps....................................................................................................................... 6

2.1 EFR Installation ....................................................................................................... 6

2.2 Activate Smartcard .................................................................................................. 6

2.3 Test-Transaction ..................................................................................................... 7

3. Country specific Implementation AT ............................................................................... 9

3.1 Minimum Requirement for the Cashier Application .................................................. 9

3.2 Optional Book Entries .............................................................................................. 9

3.3 Functions of the EFR ............................................................................................... 9

3.4 Signature Generation and Expression ....................................................................10

4. Transaction examples ...................................................................................................11

4.1 Normal Sales Receipt .............................................................................................11

4.2 Minimal Receipt Data .............................................................................................11

4.3 Automatic Value Assignment D and TN ..................................................................11

4.4 Automatic Tax Computation ...................................................................................11

4.5 Signature Device Failed (AT) .................................................................................12

4.6 Error at registration.................................................................................................12

4.7 Zero-Amount Receipts ...........................................................................................13

4.8 Nonfiscal Receipts..................................................................................................13

4.9 Training Receipts (AT) ...........................................................................................13

4.10 Return of Goods-Positions, Reversal Receipts .......................................................14

4.11 Assigning turnover to turnover tax classes (AT) .....................................................14

5. ESR Format ..................................................................................................................15

5.1 Transaction Sample XML .......................................................................................15

5.2 Transaction Sample JSON .....................................................................................16

6. Appendix .......................................................................................................................17

6.1 Glossary and Abbrevations ....................................................................................17

6.2 Revisions ...............................................................................................................17

6.3 Software Change Log .............................................................................................17



1. Introduction

1.1 The EFSTA System

serves as middleware to fulfil country specific fiscal requirements for POS systems using a

unified interface.

To achieve this the cash register application submits data of a completed transaction to the

EFR (EFSTA Fiscal Register) service and receives the fiscal signature, which has to be

printed on the receipt.

Furthermore the EFR offers the gateway function to the EFSTA Cloud, where the transaction

optionally is archived (according to "Bundesabgabenordnung BAO"), communicated to the

consumer by ways of a digital receipt, and provided to the fiscal authority in case of an audit.

The cloud component also provides maintenance, update and management functionalities

for the system.

1.2 System Requirements

EFR is executed locally for fail-safety reasons

Windows XP SP3 or higher, Linux, OS-X

node.js as basic framework, minimum version 0.8, correct architecture (32bit/64bit)

Typically 1 GB hard disk space reserved, minimal 100 MB

Administration rights during installation

Internet access for cloud services

1.3 Functional requirements

According to the Austrian law the EFR has to be provided with a source for a signature

creation.

1.3.1 Smartcard signature

If it is intended to do this locally (i.e. on the very machine EFR is running on) it has to be

ensured that a smartcard reader and an appropriate smartcard containing a hardware

certificate, as required by RKSV, is installed.

Appropriate drivers for the intended system architecture have to be installed and functional.

Special care has to be taken that the all drivers are conformant with intended system

architecture.

The smartcard driver has to support the internal operating system and operating system

version of the smartcard used.

If these parameters are not met, the EFR may be operational, but will be unable to fulfil its

intended role.

Smartcards supported:

A-Trust (old version and cardOS 53)

Global-Trust (cardOS 50 and 53)

Prime-Sign (under development, available 12/2016)


1.3.2 HSM signature

For details connecting an internal (within company) or external (webserver) HSM see EFR

Reference / Profile / Sign_require. Supported:

A-Trust a.sign RK ONLINE

A-Trust a.sign RK HSM

Prime-Sign HSM signature (evaluation, production 12/2016)


2. First steps

2.1 EFR Installation

Windows: MSI

Linux: install with preferred packet installer or build from source

node.js: download from https://nodejs.org/en/download/

version "Recommended for Most Users"

currently V4.5.0 LTS for Windows (x64)

Basic execution tracking can be examined via web access http://localhost:5618/config:

EFR Configuration via Browser

Note: Install issues, workarounds, as well as the latest installation packages are discussed in

the EFSTA Support Forum: http://forum.efsta.net

When installed the register is already fully functional. Activation of cloud-communication is a

separate step (see Cloud Activation).

2.2 Activate Smartcard

Connect the Smartcard to the computer (attach smartcard reader, and put in smartcard

respectively plug in USB Smartcard)

https://nodejs.org/en/download/

http://localhost:5618/config

http://forum.efsta.net/


EFR settings are checked via a browser-window by opening http://localhost:5618/config or

http://localhost:5618/smartcard directly.

Note: Windows 7 64bit may show unexpected behaviour at this point by expecting and trying

to install a separate driver for the smartcard. Specification-compliant smartcards do not

require such a driver, however. Consequently, driver installation fails and an error is

displayed. Preliminary testing shows that the card will usually function normally. Display of

the false installation error can be disabled by deactivating the smartcard in the device

manager. This should have no impact on the functionality of the card itself, which should

answer normally, even if disabled in this way. This erroneous behaviour is a specific

Win7.64bit problem. Please look into forum.efsta.net for the latest solution for this problem.

Smartcasrd-Configuration

Enter PIN and test connection. If ok [save] the configuration.

2.3 Test-Transaction

The cashier software communicates with the EFR via REST Webservice.

You can simulate this behaviour in your browser even before beginning to implement the

actual interface. To do this please install a REST client of your choice, for example

"Advanced REST client" for Google Chrome.

Parameters for the Web request are:

URL: http://localhost:5618/register

Method: POST

Headers: Content-Type: application/vnd.efsta.efr.v1+xml

Payload: Transaction data as XML, e.g.:

<Tra> <ESR D="2016-02-01T09:28:00" TT="01/1" TN="2053" T="12.35"> <TaxA> <Tax TaxG="A" Amt="3.49" /> <Tax TaxG="B" Amt="6.63" /> <Tax TaxG="C" Amt="2.23" /> </TaxA> </ESR> </Tra>

http://localhost:5618/configV

http://localhost:5618/smartcard

http://localhost:5618/register


Test-registration via "Advanced Rest Client Application"

Click on [Send]: the transaction is registered. The returned answer you provides you with the

http state and the ResultCode RC:

<TraC SQ="2345"> <Result RC="OK"/> <Fis> <Code>_R1-AT2_01/1_2053_2016-02-01T09:28:00_3,49_6,63_2,23_...==</Code> <Link>EFSTA.NET#35424655090786385905</Link> </Fis> </TraC>

Registration has been successful: RC = "OK", the tag <Code> contains the fiscal signature.


3. Country specific Implementation AT For Austria RKSV (Cash Register Security Ordinance) is valid starting with April 1st, 2017.

3.1 Minimum Requirement for the Cashier Application

After finishing positions and payment registration cashier application provides the

EFR with the transaction data to be signed, and then prints the sales slip including

the signature in the form of a QR-code or a signature-dependent link.

Storno-receipts (Return receipts) are to be marked with a tag AT_Storno="1".

According to the Ordinance training receipts are to be signed and printed as well, and

are to be marked by attribute NFS="TRAINING" (nonfiscal signed):

<Tra>

<ESR D="2016-02-01T19:03:16" TT="01/1" TN="2158" T="12.00" NFS="TRAINING">

<PosA>

<Pos Dsc="Nudelsieb" TaxG="A" Amt="12.00"/>

</PosA>

</ESR>

</Tra>

Access to the configuration respectively control functions of the EFT is to be provided

via a web-browser (either locally or from a back-office PC)

http://localhost:5618/config respectively.

http://localhost:5618/control

3.2 Optional Book Entries

In addition to revenue and training book entries all other non-fiscal till book entries,

like operator log in/log out, cash deposits/withdrawals, closure a.s.o., may be

registered using the EFR, marked for example by NF=”Anmeldung” (log in). If

combined with cloud-storage the thus kept journal fully fulfills the requirements of

BAO §131 (consistent coextensive archiving).

Representation in XML is formless, yet it is recommended to use predefined tags like

<pay> for payments/withdrawals.

Till closures should be registered "nonfiscal signed". If printed these receipts fulfill

regulations as starting receipt, monthly respectively yearly statement.

Example:

<Tra>

<ESR D="2016-02-01T19:03:16" TT="01/1" TN="2158" NFS="TagesEnde">

<PayA>

<Pay Dsc="Bar" KassenSoll="1251.66" KassenIst="1251.16"/>

</PayA>

</ESR>

</Tra>

Tags "KassenSoll" (till debit) a.s.o. have been added for content display,

denominantion is form-free.

3.3 Functions of the EFR

Signature generation

Chaining of receipts

Management of totals and Encryption of the same

http://localhost:5618/config



Automatic generation of status receipts (starting receipt, monthly/yearly statement

receipt, closure receipt)

DEP-Export according to RKSV (Cashier Security Ordinance) directly at till

respectively per data ticket out of cloud storage.

Automatic generation of mandatory reports to the treasury

(Startup, yearly statement receipt, closure vouche)

Tamper-proof archiving

(encrypted in cloud-storage, only entrepreneur possesses key)

Fulfilment of mandatory archivation regulation according to BAO §131 ff

(10-year archiving)

3.4 Signature Generation and Expression

Locally via Smartcard

At facility via Sign-Server (eg. Smartcard via LAN on Raspberry PI)

Central Sign-Server with Smartcard(s)

HSM

The ordinance requires printing of the signature on the sales slip in the form of a QR-code

("machine-readable code" within tag <Code> in result-XML <TraC>)

Alternatively a "signature dependent link" may be printed, via which the whole signature can

be retrieved.

This is provided in the tag <Link>, requires only one line of print, and the receipt number can

be displayed as Code128.

Examples:

EFSTA.NET#12345678901234567890

EFSTA.NET

When the link is entered in a web-browser address field the signature respectively QR Code

is displayed.


4. Transaction examples

4.1 Normal Sales Receipt

Cashier application transmits position and payment data after finishing transaction: <Tra> <ESR D="2016-03-01T09:28:00" TL="01" TT="1" TN="2073" T="1.99"> <PosA> <Pos PN="1" IN="4012345678901" Dsc="Hesp.-Essig" TaxG="B" Amt="1.99"/> </PosA> <PayA> <Pay Dsc="Bar" Amt="1.99"/> </PayA> <TaxA> <Tax TaxG="A" Amt="1.99"/> </TaxA> </ESR> </Tra>

4.2 Minimal Receipt Data <Tra> <ESR D="2016-03-01T09:32:17" TL="01" TT="1" TN="2076" T="3.49"> <TaxA> <Tax TaxG="A" Amt="3.49"/> </TaxA> </ESR> </Tra>

If minimal mandatory receipt data is provided, all requirements of the RKSV are fulfilled, the

requirements of BAO § 131 concerning coextensive archivation are not, however.

In this case the cashier application has to meet this requirement, namely saving the receipt-

signature in the transaction log and providing tamper-proof archivation.

4.3 Automatic Value Assignment D and TN <Tra> <ESR T="1.49"> <PosA> <Pos PN="1" IN="4012345678901" Dsc="Hesp.-Essig" TaxG="B" Amt="1.99"/> <Mod PN="1" Dsc="Aktionsnachlass" Amt="-0.50"/> </PosA> <TaxA> <Tax TaxG="B" Prc="10" Net="1.35" TAmt="0.14" Amt="1.49"/> </TaxA> </ESR> </Tra>

If not provided by the cash register application, Date D (system time) and receipt number TN (serial number, on change of year beginning with 1) are generated automatically by the EFR and returned within the response: <TraC SQ="1234"> <Result RC="OK"/> <ESR D="2016-03-01T14:46:43" TN="39"/> …

4.4 Automatic Tax Computation

If element TaxA is omitted, it is computed from Pos and Mod elements.

<Tra> <ESR D="2016-03-01T09:28:00" TL="01" TT="1" TN="2071"> <PosA> <Pos PN="1" IN="4012345678901" Dsc="Hesp.-Essig" TaxG="B" Amt="1.99"/> <Mod PN="1" Dsc="Aktionsnachlass" Amt="-0.50"/> <Pos PN="2" IN="9023456789001" Dsc="Katzenfein" TaxG="C" Amt="1.49"/> <Pos PN="3" IN="9023456789001" Dsc="Katzenfein" TaxG="C" Amt="1.49"/> <Pos PN="4" IN="4198765432109" Dsc="Glasreiniger" TaxG="A" Amt="3.49"/> <Pos PN="5" Dsc="Emmentaler" TaxG="B" Amt="5.14" Qty="0.252" QtyU="kg" Pri="21.90"/>


<Lin LAmt="----------"/> <Lin Dsc="Zwischensumme" LAmt="13.10"/> <Mod PN="2 3" Dsc="-25% Tiernahrung" Amt="-0.75"/> </PosA> <PayA> <Pay Dsc="Bar" Amt="15.00"/> <Pay Dsc="Rückgeld" Amt="-2.65"/> </PayA> </ESR> </Tra>

Block TaxA is returned: <TraC SQ="2345"> <Result RC="OK"/> <ESR T="12.35"> <TaxA> <Tax TaxG="A" Prc="20" Net="2.91" TAmt="0.58" Amt="3.49"/> <Tax TaxG="B" Prc="10" Net="6.03" TAmt="0.60" Amt="6.63"/> <Tax TaxG="C" Prc="13" Net="1.97" TAmt="0.26" Amt="2.23"/> </TaxA> …

4.5 Signature Device Failed (AT) <Tra> <ESR D="2016-03-01T17:36:27" TL="01" TT="1" TN="2264" T="12.35"> …

response: <TraC SQ="2345"> <Result RC="OK"> <ErrorCode>#SIGNDEV_BROKEN</ErrorCode > <UserMessage>Sicherheitseinrichtung ausgefallen</UserMessage> </Result> <Fis> <Code>_R1-AT2_01/1_2264_2016-03-01T17:36:27_3,49_6,63_2,23_0,00_0,00_V8WmZ6Bt_126998300223988602076447748182_btEC7xqxak0=_U2ljaGVyaGVpdHNlaW5yaWNodHVuZyBhdXNnZWZhbGxlbg==</Code> <Link>EFSTA.NET#33700384003797881019</Link> <Tag Name="Info" Value="Sicherheitseinrichtung ausgefallen" Label=""/> </Fis> </TraC>

RC="OK"

Transaction has been received properly, and has been signed according to RKSV using a substitute signature. Monitoring has been started, and will result in automatic notification of the Treasury Service if the security device is not restored within 48 hours.

<ErrorCode>#SIGNDEV_BROKEN</ErrorCode>

Information only, since Registration was successful (RC="OK").

<UserMessage>Sicherheitseinrichtung ausgefallen</UserMessage> Translation: Security device failed

UserMessage is to be shown to the system operator (Message-Box). As long as the failure isn’t corrected, this error is displayed every day on the first receipt.

<Code>…_U2ljaGVyaGVpdHNlaW5yaWNodHVuZyBhdXNnZWZhbGxlbg==</Code> Within the signature compliant to regulation the notification „Sicherheitseinrichtung ausgefallen“ is contained (base64-encoded).

<Tag Name="Info" Value="Sicherheitseinrichtung ausgefallen" Label=""/> Upon the actual receipt the <Tag>-elements have to be printed, in this case the string

"Sicherheitseinrichtung ausgefallen".

4.6 Error at registration <Tra> <XXXXXXXXXXXXXX/> </Tra>

response:


<TraC> <Result RC="BAD"> <ErrorCode>ERROR</ErrorCode> <Warning>e-TypeError: Cannot read property "D" of undefined ESR ESR/Normalize</Warning> </Result> </TraC>

http-Status: 400 = Bad Request

RC="BAD"

The transaction couldn’t be registered, the receipt must be discarded.

<Warning>e-TypeError:… Warning-Elements contain more details on the type of error.

4.7 Zero-Amount Receipts

Besides sales transaction non-fiscal receipts (eg. Daily closures) may be signed. Only receipt

headers are transmitted (no amount information T=, no TaxA-element):

<Tra> <ESR D="2016-03-01T19:03:48" TL="01" TT="1" TN="2303" /> </Tra>

Note: The zero-amount receipts required by RKSV (start-, monthly, yearly, closure, grand total following security device failure receipt) are generated and saved, respectively checked as required by the EFR automatically. They can be reviewed at any time via web-browser at http://localhost:5618/control.

4.8 Nonfiscal Receipts

Within a cashier application usually there are receipts necessary for orderly cashier

management, but not relevant for the grand total: payments/withdrawals, closure, operator

login/logout, and so on.

RKSV does not require these receipts, but BAO requires complete and gap-less

documentation for which these should be registered. Denomination is non-fiscal using the NF

or NFS attribute.

<Tra> <ESR D="2016-03-01T11:12:43" TL="01" TT="1" TN="2089" NF="Auszahlung"> <PosA>

<Lin Dsc="Postgebühren" LAmt="5.30"/>

</PosA>

<PayA> <Pay Dsc="Bar" Amt="-5.30"/> </PayA> </ESR> </Tra>

response: <TraC SQ="2345"> <Result RC="OK"/> <Fis> <Tag Name="NF" Value="Auszahlung" Label="Nicht fiskal"/> </Fis> </TraC>

4.9 Training Receipts (AT)

When training transactions are generated and printed on a cashier system, they have to be

signed and stored. Denomination of training transactions is the attribute NFS="TRAINING":

Example Training-receipt: <ESR D="2015-07-01T13:45:38" TL="01" TT="1" TN="2073" T="1.99" NFS="TRAINING"> …



4.10 Return of Goods-Positions, Reversal Receipts

A registered receipt cannot be changed, that is a basic rationale of accounting

documentation.

Consequently, when a receipt position is to be reversed (e.g. return of goods) a new receipt

with a reversal position (minus-signed quantity, amount) is to be generated. Alternatively, the

whole original receipt may be reversed and a new, corrected receipt may be issued. All of

these transaction have to be registered.

Example Reversal of one position: <ESR D="2016-03-01T15:03:17" TL="01" TT="1" TN="2093" T="-3.49"> … <PosA> <Pos PN="1" IN="4198765432109" Dsc="Glasreiniger" TaxG="A" Amt="-3.49" Qty="-1" RTL="01" RTT="1" RTN="2071" RPN="4"/> </PosA> <PayA> <Pay Dsc="Bar" Amt="-3.49"/> </PayA> <TaxA> <Tax TaxG="A" Prc="20" Net="-2.91" TAmt="-0.58" Amt="-3.49"/> </TaxA> … </ESR>

4.11 Assigning turnover to turnover tax classes (AT)

For signature purposes single receipt/control positions are to be assigned to the following tax groups

Tax group (de) Tax group (en) TaxG Tax rate

Normal Normal A 20%

Ermässigt-1 Reduced-1 B 10%

Ermässigt-2 Reduced-2 C 13%

Null Null D 0%

Besonders Special E 19%

This is achieved either by directly expressing TaxG="A" (A-E) or, if the percent value is

denoted, by matching of value.

Examples: <Tax TaxG="B" Amt="11.00" /> Enter tax group "Ermässigt-1"

<Tax Prc="20%" Amt="12.00" /> Enters tax group "Normal", irrespective of TaxG

notation.

Turnovers not fitting into one of the predetermined tax groups (eg. Prc="15%" or TaxG="N")

are, according to RKSV, entered into group "Null" (TaxG="D").


5. ESR Format Transaction data is sent to EFR as XML or JSON web request. See EFR Reference for ESR

(EFSTA Simple Receipt) request and response format.

The following fields have specific meaning generating the message to the fiscal system:

Element Attribute Name Message fields affected

ESR D Date Time

Seconds have to be specified according to fiscal law

TL Transaction Terminal

"KassenID"

Has to be unique within a company.

For fiscal signature [ TL + / ] + TT is used Default value used for fiscal signature: "1"

TT Transaction Terminal

TN Transaction Number

"Belegnummer" Serial number of receipt If omitted TN is incremented automatically starting with "1"; TN is reset if year in D changes.

NFS Nonfiscal Signed

Corresponds NF except that the transaction

is signed (Total=0).

Required for training transactions (according to RKSV) and recommended for "Balance"/"EndOfDay" procedures or "Training" receipts

AT_ Storno

Void Transaction

AT_Storno="1" denominates reversal receipts as specified by RKSV

5.1 Transaction Sample XML <Tra>

<ESR D="2015-07-01T09:28:00" TT="01/1" TN="2071" T="12.35">

<Head>

<Txt>Es bediente Sie Frau Gabriele</Txt>

</Head>

<PosA>

<Pos PN="1" IN="4012345678901" Dsc="Hesp.-Essig" TaxG="B" Amt="1.99"/>

<Mod PN="1" Dsc="Aktionsnachlass" Amt="-0.50"/>

<Pos PN="2" IN="9023456789001" Dsc="Katzenfein" TaxG="C" Amt="1.49"/>

<Pos PN="3" IN="9023456789001" Dsc="Katzenfein" TaxG="C" Amt="1.49"/>

<Pos PN="4" IN="4198765432109" Dsc="Glasreiniger" TaxG="A" Amt="3.49"/>

<Pos PN="5" Dsc="Emmentaler" TaxG="B" Amt="5.14" Qty="0.252" QtyU="kg" Pri="21.90"/>

<Lin LAmt="----------"/>

<Lin Dsc="Zwischensumme" LAmt="13.10"/>

<Mod PN="2 3" Dsc="-25% Tiernahrung" Amt="-0.75"/>

</PosA>

<PayA>

<Pay Dsc="Bar" Amt="5.00"/>

<Pay Dsc="Bankomat" Amt="7.35" UID="17075378 004704 004518"/>

<Lin Dsc="Maestro"/>

<Lin Dsc="B E Z A H L T EUR 7,35"/>

</PayA>

<TaxA>

<Tax TaxG="A" Prc="20" Net="2.91" TAmt="0.58" Amt="3.49" />

<Tax TaxG="B" Prc="10" Net="6.03" TAmt="0.60" Amt="6.63" />


<Tax TaxG="C" Prc="13" Net="1.97" TAmt="0.26" Amt="2.23" />

</TaxA>

<Foot>

<Txt>

Danke für Ihren Einkauf

</Txt>

</Foot>

</ESR>

</Tra>

5.2 Transaction Sample JSON

Instead of XML receipt data may as well be registered in JSON format (XML data are

transformed into JSON for internal logging and display of a digital). If registration is done in

JSON, response is JSON as well.

{"Tra":

{"ESR":{"D":"2016-02-01T09:28:00","TT":"01/1","TN":"2071","T":"12.35",

"Head":{

"Txt":["Es bediente Sie Frau Gabriele"]

},

"PosA":[

{"_":"Pos","PN":"1","IN":"4012345678901","Dsc":"Hesp.-Essig","TaxG":"B","Amt":"1.99"},

{"_":"Mod","PN":"1","Dsc":"Aktionsnachlass","Amt":"-0.50"},

{"_":"Pos","PN":"2","IN":"9023456789001","Dsc":"Katzenfein","TaxG":"B","Amt":"1.49"},

{"_":"Pos","PN":"3","IN":"9023456789001","Dsc":"Katzenfein","TaxG":"B","Amt":"1.49"},

{"_":"Pos","PN":"4","IN":"4198765432109","Dsc":"Glasreiniger","TaxG":"C","Amt":"3.49"},

{"_":"Pos","PN":"5","Dsc":"Emmentaler","TaxG":"B","Amt":"5.14","Qty":"0.252","QtyU":"kg","Pri":"21.90"}

,

{"_":"Lin","LAmt":"----------"},

{"_":"Lin","Dsc":"Zwischensumme","LAmt":"13.10"},

{"_":"Mod","PN":"2 3","Dsc":"-25% Tiernahrung","Amt":"-0.75"}

],

"PayA":[

{"_":"Pay","Dsc":"Bar","Amt":"5.00"},

{"_":"Pay","Dsc":"Bankomat","Amt":"7.35","UID":"17075378 004704 004518"},

{"_":"Lin","Dsc":"Maestro"},

{"_":"Lin","Dsc":"B E Z A H L T EUR 7,35"}

],

"TaxA":[

{"_":"Tax","TaxG":"A","Prc":"20","Net":"2.91","TAmt":"0.58","Amt":"3.49"},

{"_":"Tax","TaxG":"B","Prc":"10","Net":"6.03","TAmt":"0.60","Amt":"6.63"},

{"_":"Tax","TaxG":"C","Prc":"13","Net":"1.97","TAmt":"0.26","Amt":"2.23"}]},

],

"Foot": {

"Txt":["Danke für Ihren Einkauf<br/>www.markt.at"]

}

}

}

}


6. Appendix

6.1 Glossary and Abbrevations

The terms “voucher”, “(sales) slip” and “receipt” are used synonymously in this document.

6.2 Revisions

Revision Date Changes

1.00 3/3/2016 Initial Version EXT2

1.01 3/7/2016 Preliminary EXT2

1.02 4/26/2016 Amendment ESR.Pos.ID EXT2

1.03 6/2/2016 Additional ErrorCodes EXT2

1.04 6/6/2016 New attributes ESR.NFS, TraC.SQ

Sample Code VBA

EXT2

1.05 7/18/2016 Amendment preliminary functions CZ JMM

1.06 11/11/2016 adopted to software version 0.8.9 EXT2



6.3 Software Change Log

Version Date Module Changes

0.9.0 11/18/2016 A-Trust a.sign RK HSM Fiscal 'Startbeleg' must not be 'Training'

Fiscal Attribute Fis_OCR

Abkürzung Bedeutung

BAO Bundes-Abgabenordnung federal levy regulation

EFR EFSTA Fiscal Register = Local Registration Service

EFSTA European Fiscal Standards Association (see www.efsta.org)

HSM Hardware Security Module Secure signature unit according to signature regulation 2008

HTML Hypertext Markup Language Markup Language for display of digital documents

JSON JavaScript Object Notation Data Exchange Standard; see also: XML

RKSV Registrierkassensicherheits-Verordnung 2015 Cash Register Security Ordinance 2015

UID VAT ID Number, for Austria in the format AT-U99999999

XML eXtended Markup Language common formatting standard for data exchangeweit verbreiteter see also: JSON

XSL Definition of layouts für XML documents

XSLT XSL Transformation Programming language for transformation of XML documents

DEP 'Datenerfassungsprotokoll' denominates the mandatory journal required by BAO § 131. It can be kept using EFR, in which case all information required by said paragraph must be provided. Alternatively it can be kept within the cashier log, or appropriate documentation methods.

http://www.efsta.org/


Update bugfix

0.9.1 11/22/2016 Normalize async formal check PosA whenever supplied

Normalize bugfix warning TaxG

0.9.2 11/23/2016 Fiscal bugfix 'Belegverkettung'

Fiscal 'Summenzähler' may get negative

TaxG remove warning on <Tax> Prc="7%"

A-Trust a.sign RK ONLINE

EFR Guide [AT] - Efstaefsta.org/wp-content/uploads/2016/11/EFR_Guide_AT_0.9.2_en.pdf · EFSTA Programming Interface 11/23/2016 Revision 1.08 6 2. First steps 2.1 EFR Installation

Documents