Skip to main content

Changelog

This page lists relevant changes and updates in fiskaltrust's cloud services, on-premise products, and documentation.

You can subscribe to all changelogs via RSS, follow the GitHub repo, or display categories of changes by tags.

Documentation – Refunds and Voids, Error Handling, and Market Updates

· 8 min read
Documentation Team
Documentation Team
The team working on the Documentation

This release focuses on improvements to the fiskaltrust documentation experience, including content updates, navigation enhancements, usability improvements, and maintenance activities.

Added: Refunds, voids, discounts and error handling for all markets​

Three new market-independent pages in the Compliance Middleware Cash Register Integration section:

  • Refunds and Voids: how to void a receipt, refund it in full or in part, exchange goods and void single positions, using the IsVoid and IsReturn/IsRefund flags and cbPreviousReceiptReference. Covers referenced and unreferenced refunds and market-specific considerations.
  • Discounts and Extras: how to record discounts and extras (surcharges) with the Discount flag of ftChargeItemCase, including percentage discounts, discounts on several positions or the whole receipt, discounts in refunds and voids, and how discounts differ from vouchers.
  • Error Handling: how transport, HTTP and Middleware errors reach the POS system, how to evaluate ftState and error messages, and how the POS system should react.

Why it matters: Developers find the rules for corrections, price reductions and errors in one place for every market, with examples and links to the market-specific considerations.

Added: Closing Receipts section​

The Cash Register Integration page has a new Closing Receipts section. Daily, monthly and yearly closings are required independent of local regulations; shift closings only when the business works in shifts. The section describes the required order and how a due closing shows up in ftState.

Why it matters: Developers know which closings to integrate and how the Middleware signals that a closing is due.

Added: POS System API Receipt Formats and Android IPC Transport​

  • Receipt Formats: how to retrieve an issued receipt in different formats with GET /issue/{QueueId}/{QueueItemId}, selected via the HTTP Accept header. Includes the available formats, rendering width and examples.
  • Android IPC Transport: how the launcher exposes the POS System API through Android IPC instead of a network request, with a bound service and with an activity intent.

Why it matters: Developers integrating the POS System API can retrieve rendered receipts in the format they need and call the API on Android without a network request.

Added: eInvoicing buyer data and FatturaPA mapping​

  • Buyer data (cbCustomer): maps the cbCustomer fields to the buyer fields of EN 16931, including the fields for routing and buyer reference.
  • FatturaPA mapping (Italy): how an Italian invoice receipt becomes a FatturaPA document (FPR12): which receipts get one, document types, the source of every FatturaPA element, the output and the validation rules.

Why it matters: Developers see which receipt data ends up in which eInvoice field and which validation rules a receipt has to pass before it is fiscalized.

Added: Belgium Go-to-Market and Portugal Error Handling​

  • Belgium: Go-to-Market and FAQ describe the parties in the Belgian registered cash register system (RCRS) and FDM setup, where the fiskaltrust.Middleware sits, what it provides, what remains with the developer, and the onboarding steps.
  • Portugal: Error Handling lists the validation errors the Portuguese Middleware returns and how to fix a rejected request.

Why it matters: Developers entering Belgium get an overview of the setup and their responsibilities before they start; Developers in Portugal can resolve rejected requests on their own.

Updated: Market documentation​

  • Austria: The reference tables now include the v2 tables; the v0 tables and rksv.sign (retired product) were removed from the sidebar.
  • Italy: the data structures page has a new cbCustomer subsection (sent as a serialized JSON string; the codice fiscale belongs in CustomerTaxId) and a new section on how refunds and voids reference the original receipt.
  • Greece: the data structures page documents the external MARK for refunds and voids of receipts from another device or system, and has a new cbArea section (sent to myDATA as tableAA, max 50 characters). The PreviousReceiptReference section now covers follow-up documents as well as refunds and voids, and describes how cbPreviousReceiptReference maps to the myDATA fields correlatedInvoices and multipleConnectedMarks: the field is selected by the IsReturn/IsRefund flag and the myDATA type of the new document. The referenced document must be issued first.
  • Portugal: the Certification page has a new section Receipt options, configuration, and extension points for the certified document, and states that numbering series and starting numbers are set by fiskaltrust.

Why it matters: The market pages reflect the current behavior of the Middleware in each market.

Updated: InStore App and Partner guides​

  • InStore App: Available settings updated for v1.3.2, including the No printing and No payment options, the Dummy Payment Provider and a SumUp section.
  • Registration: aligned with the new registration wizard in the fiskaltrust.Portal.
  • Desktop launchers: explicit steps to download a Middleware launcher from the fiskaltrust.Portal.
  • Network requirements: the Helipad helper uploads to helipad.fiskaltrust.eu and falls back to helipad.fiskaltrust.cloud.
  • DATEV MeinFiskal: updated onboarding process.

Why it matters: The guides match the current InStore App release, the current fiskaltrust.Portal and the current network endpoints.

Improved: General data structures​

The data structures page has new sections:

The eInvoicing overview has a new section Invoices and invoice types (B2C, B2B and B2G are set by ftReceiptCase) and states that eInvoicing is only available with a cloud CashBox. The POS System API migration guide now describes ftReceiptCaseData in v2 as a plain JSON object.

Why it matters: The shared data model is described once for all markets, and the market pages only document what differs.

Improved: Navigation​

  • The Developer sidebar was restructured: a new fiskaltrust.Middleware category groups the Compliance Middleware and the Experience Middleware, and the country guides are now listed at the top level.
  • Each country guide in the Developer sidebar now shows its flag.
  • The Developer menu has a new Market Guides entry: nine flags side by side, each linking to that country's guide.
  • The Austria Introduction is now the entry point for the Austrian section, with what is required for the Austrian market and links to the pages that cover each obligation.

Why it matters: Readers reach their market's pages faster and find each topic in one place.

Improved: Discoverability with page tags​

Every documentation page now has tags. They name the topic, product, market or regulation a page covers, for example eInvoicing, InStore App, POS System API, KassenSichV or myDATA. Each tag has its own page that lists all pages with that tag; the tags overview lists all tags.

Why it matters: Readers find all pages on a topic from one place, for example the pages tagged eInvoicing, across the Developer and Partner sections and markets.