indicates the corresponding country.

If the fiscalCountryProperties are queried via GET /api/v1/information/client/{clientId}/ countryProperties, the country assigned to the respective client is specified.

Specifies whether certification of a fiscalisation component is required in a country, or what needs to be certified.

"mandatory" - Certification of the upstream system (e.g. cash register) is mandatory. In this case, the cash register must undergo a certification or approval process.

"miniPOS" - Certification is mandatory, but is fulfilled by an already certified component that may be integrated into the RetailForce middleware.

"notNecessary" - No certification of the previous system required.

"true" - in the respective country, data must be sent line by line e.g. to a fiscal printer.

• currently not supported

"false" - Document-based interface (no line-by-line printing).

• Implementation between upstream system and Fiscalisation Service is based on standard API endpoints.

Specifies the type of fiscalisation.

"fiscalPrinter" - Fiscalisation is based on a certified fiscal printer or a certified fiscal cash register system.

• This means that, in addition to the RetailForce system, a fiscal printer is required. This may need to be purchased from a local supplier.

"online" - Fiscalisation via online systems of the local tax authorities.

• no additional hardware component requried.

"signature" - Fiscalisation by signing receipt data using a digital certificate stored in the fiscalisation service.

• In some countries, it may be necessary to obtain a qualified digital certificate provided by a CA (Certificate Authority).

"signatureWithOnline" - Fiscalisation by creating signatures and transmitting data online to the tax authorities.

• Combination of the two aforementioned types.

Specifies which environment is supported:

"local" - local installation of the fiscal middleware (local on the POS system, on the store server, etc.)

• API calls can be made to the locally installed fiscalisation service:
  • http://localhost:7678/ in the case of REST implementation, or
  • method call in the case of nuget implementation.

"cloud" - fiscal middleware is available as a hosted cloud service at https://fiscalisation.retailforce.cloud/.

• API calls can be made to the Cloud Fiscalisation Service.

Specifies which operating systems/platforms are supported.

"linux"

• via Docker container (REST implementation)

"windows"

• via Windows Service (REST implementation), or
• via nuget implementation

"ios"

• via nuget implementation

"android"

• via nuget implementation, or
• android Service (REST implementation)

Specifies which legal requirements are supported and their versions.

E.g. for Greece: "myData v1.x.x"

Document types that are to be "fiscalised" in the respective country. For example, they must be processed by the prescribed hardware component, signed, etc.

"documentTypes" listed under "fiscalDocumentTypes" are automatically processed (e.g. signed) in the respective country by the fiscalisation service in accordance with fiscalisation laws.

These document types MUST be transmitted to the fiscalisation service in the respective country, provided that the upstream system ("cash register") supports them.

List of document types supported in each country.

In addition to the "fiscalDocumentTypes", the document types listed under "supportedDocumentTypes" CAN be transmitted to the fiscalisation service.

These document types are so-called "non-fiscal" documents, i.e. those that are not "fiscalised" (e.g. signed).

List of document types not supported in the respective country.

"DocumentTypes" listed under "notSupportedDocumentTypes" cannot be transmitted to the fiscalisation service in the respective country.

Reasons for this may be technical impossibility or country-specific regulations/laws.

If a "notSupportedDocumentType" is sent to the fiscalisation service, it will respond with an error message ("documentType not supported!").

The upstream system should not allow these document types in the relevant country.

List of payment methods supported (accepted) in the respective country.

These payment methods can be used in the respective country.

The upstream system should only offer the cash register user supported payment methods in the respective country.

List of payment methods that are not supported (or not permitted) in the respective country.

The upstream system should suppress not supported payment methods in the respective country.

List of payment methods (paymentTypes) for which overpayment of the amount owed is not permitted in the country concerned.

Examples:

Receipt total = EUR 38.50

• The customer pays EUR 50 by debit card because they would like the change in cash.
• The customer pays EUR 50 in cash and receives EUR 11.50 in change (change given).

These transactions are not permitted in some countries (meaning, cannot be sent to the fiscalization system).

This means that payment amounts ("payment.amount") must always correspond to the gross total of the items ("grossValue" of all "positions") and no negative payment amounts may be transferred.

List of business case types supported in each country.

These business cases can be used in the respective country, unlike notSupportedBusinessTransactionTypes.

List of business case types that are not supported (or are not permitted) in the respective country.

These business cases cannot be used in the respective country and should be suppressed by the source system and not transmitted to the fiscalisation service.

Detailed information on the VAT rates supported in each country.

This array contains the following information:

• VAT rate: "vatPercent" / "vatPercent2"
• Internal ID used to map the respective VAT rate: "vatIdentification"
• Name of the VAT rate: "caption" / "caption_EN"
• Historical VAT rates with validity details ("validFrom" - "validTo")

"not mandatory" - Customer display is not required (no obligation).

"mandatory (no-RF)" - Customer display is mandatory, but is not controlled via RetailForce Middleware. Control is carried out automatically by the respective fiscalisation system (e.g. automatically by the fiscal printer).

"mandatory (RF)" - It is mandatory to use a customer display must and it is controlled via the RetailForce middleware.

• The customer display is controlled via the function: POST /api/v1/transactions/display/{clientId}

"not allowed" - Use of a customer display is prohibited in this country.

Specifies whether input devices must be registered in the respective country ("true" / "false").

Input devices are not stand-alone recording systems. For more information, see: Architectures of electronic recording systems (EAS)

"true" - in the respective country there is a requirement to keep a technical journal (audit log) (in this case included in the RF licence).

• In this case, technical event entries must be sent to the fiscalisation service via
  • POST /api/v1/transactions/auditlog, or
  • POST /api/v1/transactions/storeDocument ("documentType": "[1002] = AuditLog")

"false" - there is no requirement to keep a technical journal (not included in licence).

• Technical events MAY be recorded, but do not have to be.

"true" - in the corresponding country, the reprint of a document must be recorded obligatorily.

• Call of either:
  • PUT /api/v1/transactions/reprintDocument/ {clientId}/{documentGuid}, or

  • PUT /api/v1/transactions/reprintDocument

    mandatory.

"false" - Reprinting of a document does not have to be recorded as mandatory.

"terminal" - A document may only be reprinted on the same cash register on which the original document was issued.

"store" - Reprints of a document may only be made within the same branch /store where also the original document was issued.

• The reprint function across multiple branches must be implemented by the upstream system.

"all" - Reprinting of a document may be done on another cash register as well as in another branch / store of the same company.

• The reprint function across multiple branches must be implemented by the upstream system.

"true" - a daily closing (Z-report) must be generated once a day.

• daily closing
  • POST /api/v1/transactions/storeDocument
  • "documentType": "[99] = EndOfDay"

"false" - no requirement for a daily closing.

Indicates the period of time since the cash register daily opening within which a daily closing must take place (e.g. within 24h).

"-1" - not set.

Specify whether sales and returns may be recorded simultaneously on a receipt (document).

"oneReceiptAllowed" - allowed (sales and returns can be shown mixed on one receipt).

• Sales:
  • "positions" (Type 0 oder 1) with positive values,
• Returns:
  • "positions" (Type 0 oder 1) with negative values and
  • "documentReference" set.

"oneReceiptAllowedVat" - as long as the VAT amount remains positive, sales and returns can be recorded on a single (the same) receipt.

"multiReceipt" - Sales and returns must be recorded on different receipts.

• Before transmitting data to the fiscalisation service, the upstream system must automatically split sales and returns into different transactions.

"NoReturnAllowed" - in the respective country, returns processing via the fiscalization system is not possible. In these countries, returns are often handled via special forms or similar in the accounting department.

Where may purchased items be returned?

"terminal" - Items may only be taken back at the same cash desk (voucher issue) at which the original sale was made.

"store" - Items may only be returned to the same branch /store (voucher issue) where the original sale was made.

"all" - Items may also be returned to different branches of the same company.

Document reference for returns

"single" - in the case of returns, reference may only be made to ONE previous document (sales document of the returned services or goods).

• "documentReference" only permitted for a single preliminary document, or
• reference at item level ("positionReference") only permitted for a single preliminary document.

"multiple" - in case of returns, references to multiple previous documents (multiple sales receipts if multiple services or goods from multiple purchases are returned) may be made. 

• "documentReference" to multiple previous documents, or
• reference to the corresponding previous document via "positionReference" on the individual returns item.

Specifies whether the "fiscalDocumentNumber" element of the "fiscalResonse" of the corresponding country must be printed on documents.

• Document numbers transferred from the upstream system are ignored. The fiscal system (e.g. printer) assigns the respective document number/document ID autonomously.

"true" - in the respective country, surcharges on goods or services are permitted.

• surcharges:
  • "positions.discounts" with NEGATIVE values

"false" - Price surcharges are not allowed.

Indicates whether a training / demo mode of the cash register is permitted in the respective country

"true" - allowed.

• Trainingmode:
  • "isTraining": true

"false" - Cash register must not have a training / demo mode.

"true" - The sum of the individual items is calculated based on the net amount (netValue) (e.g. Québec/Canada).

"false" - The sum of the individual items is calculated based on the gross amount (grossValue) (default).

"true" - Items that have been entered but are not subsequently included in the document must be transmitted in the payload (JSON).

"false" - Items that have been entered but are not subsequently included in the document do not need to be transmitted.

Specifies the type of start document in the relevant country.

Only relevant if the upstream system does NOT use the function GET /api/v1/transactions/document/{clientId}/start during initialisation and generates the respective start document itself.

List of payout types supported in the relevant country.

The items listed under "supportedPayOutTypes" can/must be specified for payouts ("documentType": "[10] = PayOut" and "businessTransactionType": "[10] = PayOut").

Indicates whether the VAT rates are calculated by the respective fiscalisation module of the country.

"true" - Fiscalisation module calculates VAT rates.

"false" - cash register must calculate VAT rates.

Specifies whether and how many decimal places must be included in the JSON-document to the Fiscal Middleware when sending amounts / totals.

Applies to all value specifications in the payload ("GrossValue"," NetValue", "TaxValue", "Amount", etc.)