From da1f917aaa85fbba0d05c2bd0b58cbc0bd2226c3 Mon Sep 17 00:00:00 2001 From: deboragracio Date: Tue, 12 May 2026 17:18:38 +0200 Subject: [PATCH 1/6] Created first draft https://github.com/fiskaltrust/engineering/issues/1124 --- .../experience-middleware/delivery.md | 90 +++++++++++++++++++ poscreators/toc.js | 1 + 2 files changed, 91 insertions(+) create mode 100644 poscreators/middleware-doc/experience-middleware/delivery.md diff --git a/poscreators/middleware-doc/experience-middleware/delivery.md b/poscreators/middleware-doc/experience-middleware/delivery.md new file mode 100644 index 0000000..303df7d --- /dev/null +++ b/poscreators/middleware-doc/experience-middleware/delivery.md @@ -0,0 +1,90 @@ +--- +title: Delivery +slug: /poscreators/experience-middleware/delivery +--- + +# Delivery + +The **Delivery** component of the Experience Middleware defines the formats and channels through which receipts and invoices generated at the point of sale are transmitted to consumers and business customers. + +While fiscalization ensures that every transaction is securely recorded and legally compliant, **delivery** governs how the resulting document is transferred to its recipient — whether on paper, on a screen, in a digital wallet, or directly into an accounting system. + +## Supported Delivery Formats + +**fiskaltrust** supports a range of delivery formats that can be combined depending on merchant configuration, market requirements, and customer preference. + +### Printed Receipt + +The traditional paper receipt issued at the point of sale. + +- Generated by the POS system and printed on a connected receipt printer. +- Still required or expected in many markets and use cases. +- Fully compatible with the **fiskaltrust** fiscalization flow: the printed document carries the fiscal data (signatures, QR codes, sequence numbers) required by local regulation. + +### Digital Receipt + +An electronic version of the receipt delivered to the consumer through a digital channel after the transaction has been fiscalized. + +- Delivered via QR code, HTTPS link, SMS, email, or the [InStore App](https://docs.fiskaltrust.cloud/docs/poscreators/middleware-doc/instore-app/introduction). +- Linked to the underlying fiscal receipt so that the digital and fiscal documents always correspond. +- Reduces paper consumption and enables downstream interactions such as loyalty, returns, or feedback collection. + +Digital receipts are generated by the fiskaltrust.Middleware after the receipt has been signed and journaled. They are stored in fiskaltrust's backend infrastructure and optionally exposed to the customer through the following mechanisms: + +- A secure QR code or URL embedded in the physical or on-screen receipt. +- API access using a receipt ID or transaction hash, enabling frontend applications, digital wallets, and loyalty programmes to retrieve and display receipts programmatically. + +For implementation details, see the [Digital Receipt](../digital-receipt/introduction.md) section. + +### Structured Invoice + +A machine-readable invoice containing standardized data fields in addition to the human-readable representation. + +- Used primarily for **business-to-business (B2B)** transactions where the recipient needs to import the invoice into an accounting or ERP system. +- Carries the same fiscal guarantees as a regular receipt while including structured data (item lines, tax breakdowns, buyer information) in a defined format. +- Can be issued alongside or instead of a printed or digital receipt, depending on the customer's request at checkout. + +### E-invoicing + +The electronic exchange of invoices in a structured format between businesses, and increasingly between businesses and tax authorities. + +- Several European markets are introducing or extending mandatory e-invoicing requirements (for example for B2B and B2G transactions). +- fiskaltrust is extending the Experience Middleware to support these flows from the point of sale, enabling merchants to issue compliant e-invoices through the same integration already used for fiscalization and digital receipts. + +> **Note:** E-invoicing support in the Experience Middleware is **work in progress**. Country-specific availability, supported formats, and integration details will be documented as the feature becomes available. + +## Delivery from a Point-of-Sale Perspective + +From the POS perspective, delivery is the final step of the checkout flow. After items have been entered, the receipt has been fiscalized, and payment has been processed, the POS triggers the appropriate delivery channel(s). + +A typical flow: + +1. The POS sends the receipt to the fiskaltrust.Middleware for fiscalization. +2. The Middleware returns a fiscalized receipt with all required fiscal data. +3. Depending on the customer's selection and the merchant's configuration, the POS triggers one or more delivery options: + - Print the receipt on the connected printer. + - Generate a digital receipt and present it as a QR code, link, or message, or deliver it via the InStore App. + - Issue a structured invoice for a business customer. + - Submit an e-invoice through the relevant national or European channel (where supported). +4. The POS records which delivery options were used so that the transaction is fully traceable. + +The POS integrates once with fiskaltrust to access all supported delivery formats, and selects the format appropriate for each transaction. + +## Delivery from a General Perspective + +From a broader perspective, the delivery layer provides consumers and business customers with a consistent, standards-based mechanism to receive proof of purchase, while keeping merchants compliant with local fiscal and invoicing rules. + +- **Consumers** can select between paper and digital receipt formats, and interact with the digital receipt after the transaction (for example to access warranty information or initiate a return). +- **Business customers** can request a structured invoice or e-invoice for direct import into their accounting system. +- **Merchants** benefit from a single integration covering all delivery formats, eliminating the need for separate per-channel or per-market solutions. +- **Tax authorities** receive fiscally guaranteed documents regardless of the delivery channel used. + +By consolidating these formats under a single delivery layer, the Experience Middleware supports both current paper and digital receipt scenarios and future structured invoice and e-invoicing requirements through one coherent integration. + +## Intended Audience for Delivery Integration + +Delivery integration is primarily relevant for: + +- **PosCreators** who want to offer merchants a complete set of receipt and invoice delivery options without implementing each format independently. +- **PosDealers** who configure delivery channels for merchants across different markets and customer segments. +- **PosOperators** who need to provide flexible, compliant checkout experiences across paper, digital, and structured document formats. \ No newline at end of file diff --git a/poscreators/toc.js b/poscreators/toc.js index 5bce370..07fa58b 100644 --- a/poscreators/toc.js +++ b/poscreators/toc.js @@ -386,6 +386,7 @@ module.exports = [ "poscreators/middleware-doc/experience-middleware/introduction", "poscreators/middleware-doc/experience-middleware/terminology", "poscreators/middleware-doc/experience-middleware/payment", + "poscreators/middleware-doc/experience-middleware/delivery", { type: "category", collapsed: true, From 7105cd12ef4b3edf3a1bdfb7d644b6e5b42ee6e2 Mon Sep 17 00:00:00 2001 From: deboragracio Date: Wed, 20 May 2026 18:13:38 +0200 Subject: [PATCH 2/6] Changes after review --- .../experience-middleware/delivery.md | 215 +++++++++++++++++- 1 file changed, 207 insertions(+), 8 deletions(-) diff --git a/poscreators/middleware-doc/experience-middleware/delivery.md b/poscreators/middleware-doc/experience-middleware/delivery.md index 303df7d..216e069 100644 --- a/poscreators/middleware-doc/experience-middleware/delivery.md +++ b/poscreators/middleware-doc/experience-middleware/delivery.md @@ -3,7 +3,7 @@ title: Delivery slug: /poscreators/experience-middleware/delivery --- -# Delivery +# Delivery (/issue) The **Delivery** component of the Experience Middleware defines the formats and channels through which receipts and invoices generated at the point of sale are transmitted to consumers and business customers. @@ -40,18 +40,217 @@ For implementation details, see the [Digital Receipt](../digital-receipt/introdu A machine-readable invoice containing standardized data fields in addition to the human-readable representation. -- Used primarily for **business-to-business (B2B)** transactions where the recipient needs to import the invoice into an accounting or ERP system. +- Used for **business-to-business (B2B)**, **business-to-government (B2G)**, and - in some countries - **business-to-consumer (B2C)** transactions where the recipient needs to import the invoice into an accounting or ERP system. - Carries the same fiscal guarantees as a regular receipt while including structured data (item lines, tax breakdowns, buyer information) in a defined format. - Can be issued alongside or instead of a printed or digital receipt, depending on the customer's request at checkout. -### E-invoicing - -The electronic exchange of invoices in a structured format between businesses, and increasingly between businesses and tax authorities. +#### Structured Invoice Payload Examples + +The following examples show structured invoice requests for different transaction types. + +##### B2B Invoice + +```json +{ + "ftReceiptCase": 35184372092930, + "cbReceiptReference": "1234-a6aa5439-5553-4779-a972-259867986a39", + "cbReceiptMoment": "{{$isoTimestamp}}", + "cbCustomer": { + "CustomerVATId": "026883248", + "CustomerName": "Πελάτης A.E.", + "CustomerStreet": "Κηφισίας 12", + "CustomerZip": "12345", + "CustomerCity": "Αθηνών", + "CustomerCountry": "GR" + }, + "cbChargeItems": [ + { + "Quantity": 1, + "Description": "Couch", + "Amount": 1200, + "VATRate": 20, + "ftChargeItemCase": 35184372088851, + "VATAmount": 200 + } + ], + "cbPayItems": [ + { + "Description": "Cash", + "Amount": 1200, + "ftPayItemCase": 35184372088833 + } + ] +} +``` + +##### B2C Invoice + +```json +{ + "ftReceiptCase": 35184372092929, + "cbReceiptReference": "invoice-12345-1a4dbda8-9a40-4011-8cad-0139d2545bd5", + "cbReceiptMoment": "{{$isoTimestamp}}", + "cbCustomer": { + "CustomerName": "Sepp Steiner", + "CustomerId": null, + "CustomerType": "B2C", + "CustomerStreet": "Alpenstraße 99", + "CustomerZip": "5020", + "CustomerCity": "Salzburg", + "CustomerCountry": "AT" + }, + "cbChargeItems": [ + { + "Quantity": 3, + "Description": "Beer 0.3l", + "Amount": 13.8, + "VATRate": 20, + "ftChargeItemCase": 35184372088867 + }, + { + "Quantity": 4, + "Description": "Coffee", + "Amount": 9.2, + "VATRate": 20, + "ftChargeItemCase": 35184372088867 + }, + { + "Quantity": 2, + "Description": "Lunch menu", + "Amount": 31.8, + "VATRate": 20, + "ftChargeItemCase": 35184372088867 + }, + { + "Quantity": 2, + "Description": "Standard room 06.07. - 08.07.2025", + "Amount": 300, + "VATRate": 20, + "ftChargeItemCase": 35184372088867 + } + ], + "cbPayItems": [ + { + "Description": "Accounts Receivable", + "Amount": 354.8, + "ftPayItemCase": 35184372088841 + } + ] +} +``` -- Several European markets are introducing or extending mandatory e-invoicing requirements (for example for B2B and B2G transactions). -- fiskaltrust is extending the Experience Middleware to support these flows from the point of sale, enabling merchants to issue compliant e-invoices through the same integration already used for fiscalization and digital receipts. +### E-invoicing -> **Note:** E-invoicing support in the Experience Middleware is **work in progress**. Country-specific availability, supported formats, and integration details will be documented as the feature becomes available. +The electronic exchange of invoices in a structured format across **B2B**, **B2G**, and **B2C** transactions, and increasingly between businesses and tax authorities. E-invoicing is built into the fiskaltrust.Middleware's core process — any merchant already integrated with `/sign` is ready to use it, with support available directly through the POS system API. + +#### E-invoice Payload Examples + +The following examples show e-invoice requests for different transaction types. + +##### B2B E-invoice + +```json +{ + "ftReceiptCase": 35184372088836, + "cbReceiptReference": "Ecomm-B2B-IC-001-866afb78-b77c-46d2-b77c-3d4756884409", + "cbReceiptMoment": "{{$isoTimestamp}}", + "cbCustomer": { + "CustomerVATId": "DE123456789", + "CustomerName": "EU Buyer GmbH", + "CustomerStreet": "Sample Street 1", + "CustomerZip": "12345", + "CustomerCity": "Berlin", + "CustomerCountry": "DE" + }, + "cbChargeItems": [ + { + "Quantity": 10, + "Description": "Electronic Gadgets", + "Amount": 500, + "VATRate": 0, + "ftChargeItemCase": 35184372093208, + "ftChargeItemCaseData": { + "GR": { + "exemptionReason": 2 + } + } + } + ], + "cbPayItems": [ + { + "Quantity": 1, + "Description": "Non-cash Payment", + "Amount": 500, + "ftPayItemCase": 35184372088834 + } + ], + "ftReceiptCaseData": { + "GR": { + "mydataoverride": { + "invoice": { + "invoiceHeader": { + "deliveryMethod": 2, + "currencyCode": "EUR", + "otherInvoiceHeader": { + "thirdPartyVATId": "DE123456789" + }, + "invoiceType": "1.1" + } + } + } + } + } +} +``` + +##### B2C E-invoice + +```json +{ + "ftReceiptCase": 35184372088836, + "cbReceiptReference": "Ecomm-B2C-001-866afb78-b77c-46d2-b77c-3d4756884409", + "cbReceiptMoment": "{{$isoTimestamp}}", + "cbCustomer": { + "CustomerVATId": "", + "CustomerName": "John Doe", + "CustomerStreet": "", + "CustomerZip": "", + "CustomerCity": "", + "CustomerCountry": "GR", + "CustomerEmail": "john.doe@example.com" + }, + "cbChargeItems": [ + { + "Quantity": 1, + "Description": "Software License", + "Amount": 100, + "VATRate": 22, + "ftChargeItemCase": 35184372088851 + } + ], + "cbPayItems": [ + { + "Quantity": 1, + "Description": "Non-cash Payment", + "Amount": 124, + "ftPayItemCase": 35184372088834 + } + ], + "ftReceiptCaseData": { + "GR": { + "mydataoverride": { + "invoice": { + "invoiceHeader": { + "deliveryMethod": 1, + "currencyCode": "EUR", + "invoiceType": "11.1" + } + } + } + } + } +} +``` ## Delivery from a Point-of-Sale Perspective From 3134ced0ba2c519e5bffca6d5573b06759d15e9f Mon Sep 17 00:00:00 2001 From: deboragracio <63159404+deboragracio@users.noreply.github.com> Date: Wed, 20 May 2026 16:21:57 +0200 Subject: [PATCH 3/6] Update poscreators/middleware-doc/experience-middleware/delivery.md Co-authored-by: Stefan Kert --- poscreators/middleware-doc/experience-middleware/delivery.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/poscreators/middleware-doc/experience-middleware/delivery.md b/poscreators/middleware-doc/experience-middleware/delivery.md index 216e069..76ec559 100644 --- a/poscreators/middleware-doc/experience-middleware/delivery.md +++ b/poscreators/middleware-doc/experience-middleware/delivery.md @@ -25,7 +25,7 @@ The traditional paper receipt issued at the point of sale. An electronic version of the receipt delivered to the consumer through a digital channel after the transaction has been fiscalized. -- Delivered via QR code, HTTPS link, SMS, email, or the [InStore App](https://docs.fiskaltrust.cloud/docs/poscreators/middleware-doc/instore-app/introduction). +- Delivered via QR code, HTTPS link, SMS, email, or the [InStore App](https://docs.fiskaltrust.eu/docs/poscreators/middleware-doc/instore-app/introduction). - Linked to the underlying fiscal receipt so that the digital and fiscal documents always correspond. - Reduces paper consumption and enables downstream interactions such as loyalty, returns, or feedback collection. From 559711781690bbcef5570f9a2a0c46bb20a61032 Mon Sep 17 00:00:00 2001 From: deboragracio Date: Fri, 22 May 2026 14:11:23 +0200 Subject: [PATCH 4/6] Changes after review --- .../experience-middleware/delivery.md | 124 ++++++------------ .../data-structures/data-structures.md | 2 +- 2 files changed, 39 insertions(+), 87 deletions(-) diff --git a/poscreators/middleware-doc/experience-middleware/delivery.md b/poscreators/middleware-doc/experience-middleware/delivery.md index 76ec559..11f5395 100644 --- a/poscreators/middleware-doc/experience-middleware/delivery.md +++ b/poscreators/middleware-doc/experience-middleware/delivery.md @@ -3,7 +3,7 @@ title: Delivery slug: /poscreators/experience-middleware/delivery --- -# Delivery (/issue) +# Delivery (/issue Endpoint) The **Delivery** component of the Experience Middleware defines the formats and channels through which receipts and invoices generated at the point of sale are transmitted to consumers and business customers. @@ -36,113 +36,50 @@ Digital receipts are generated by the fiskaltrust.Middleware after the receipt h For implementation details, see the [Digital Receipt](../digital-receipt/introduction.md) section. -### Structured Invoice +### Structured Invoice & E-invoicing A machine-readable invoice containing standardized data fields in addition to the human-readable representation. -- Used for **business-to-business (B2B)**, **business-to-government (B2G)**, and - in some countries - **business-to-consumer (B2C)** transactions where the recipient needs to import the invoice into an accounting or ERP system. +A structured invoice (also known as e-invoice) describes data available in a structured form rather than just as a visual representation (e.g. PDF). All subsequent processing is simply a conversion of that data — the fiskaltrust.Middleware already outputs data in a [structured format](https://docs.fiskaltrust.eu/docs/poscreators/middleware-doc/general/data-structures). + +E-invoicing is the electronic exchange of invoices across **B2B**, **B2G**, and **B2C** transactions, and increasingly between businesses and tax authorities. It is built into the fiskaltrust.Middleware's core process — any merchant already integrated with `/sign` is ready to use it, with support available directly through the POS system API. + +- Used for **business-to-business (B2B)**, **business-to-government (B2G)**, and — in some countries — **business-to-consumer (B2C)** transactions where the recipient needs to import the invoice into an accounting or ERP system. - Carries the same fiscal guarantees as a regular receipt while including structured data (item lines, tax breakdowns, buyer information) in a defined format. - Can be issued alongside or instead of a printed or digital receipt, depending on the customer's request at checkout. -#### Structured Invoice Payload Examples - -The following examples show structured invoice requests for different transaction types. +#### Simplified Invoice / POS Receipt Example -##### B2B Invoice +The following example shows a structured invoice request for a simplified invoice or POS receipt transaction. ```json { - "ftReceiptCase": 35184372092930, - "cbReceiptReference": "1234-a6aa5439-5553-4779-a972-259867986a39", - "cbReceiptMoment": "{{$isoTimestamp}}", - "cbCustomer": { - "CustomerVATId": "026883248", - "CustomerName": "Πελάτης A.E.", - "CustomerStreet": "Κηφισίας 12", - "CustomerZip": "12345", - "CustomerCity": "Αθηνών", - "CustomerCountry": "GR" - }, + "ftCashBoxID": "00000000-0000-0000-0000-000000000000", + "ftPosSystemId": "00000000-0000-0000-0000-000000000000", + "cbTerminalID": "1", + "cbReceiptReference": "SIMP-0001", + "cbReceiptMoment": "2024-01-01T10:00:00.000Z", "cbChargeItems": [ { - "Quantity": 1, - "Description": "Couch", - "Amount": 1200, - "VATRate": 20, - "ftChargeItemCase": 35184372088851, - "VATAmount": 200 + "Quantity": 1.0, + "Description": "Product A", + "Amount": 12.50, + "VATRate": 20.0, + "ftChargeItemCase": "0x0000000000000001" } ], "cbPayItems": [ { + "Quantity": 1.0, "Description": "Cash", - "Amount": 1200, - "ftPayItemCase": 35184372088833 - } - ] -} -``` - -##### B2C Invoice - -```json -{ - "ftReceiptCase": 35184372092929, - "cbReceiptReference": "invoice-12345-1a4dbda8-9a40-4011-8cad-0139d2545bd5", - "cbReceiptMoment": "{{$isoTimestamp}}", - "cbCustomer": { - "CustomerName": "Sepp Steiner", - "CustomerId": null, - "CustomerType": "B2C", - "CustomerStreet": "Alpenstraße 99", - "CustomerZip": "5020", - "CustomerCity": "Salzburg", - "CustomerCountry": "AT" - }, - "cbChargeItems": [ - { - "Quantity": 3, - "Description": "Beer 0.3l", - "Amount": 13.8, - "VATRate": 20, - "ftChargeItemCase": 35184372088867 - }, - { - "Quantity": 4, - "Description": "Coffee", - "Amount": 9.2, - "VATRate": 20, - "ftChargeItemCase": 35184372088867 - }, - { - "Quantity": 2, - "Description": "Lunch menu", - "Amount": 31.8, - "VATRate": 20, - "ftChargeItemCase": 35184372088867 - }, - { - "Quantity": 2, - "Description": "Standard room 06.07. - 08.07.2025", - "Amount": 300, - "VATRate": 20, - "ftChargeItemCase": 35184372088867 + "Amount": 12.50, + "ftPayItemCase": "0x0000000000000001" } ], - "cbPayItems": [ - { - "Description": "Accounts Receivable", - "Amount": 354.8, - "ftPayItemCase": 35184372088841 - } - ] + "ftReceiptCase": "0x0000000000000001" } ``` -### E-invoicing - -The electronic exchange of invoices in a structured format across **B2B**, **B2G**, and **B2C** transactions, and increasingly between businesses and tax authorities. E-invoicing is built into the fiskaltrust.Middleware's core process — any merchant already integrated with `/sign` is ready to use it, with support available directly through the POS system API. - #### E-invoice Payload Examples The following examples show e-invoice requests for different transaction types. @@ -280,6 +217,21 @@ From a broader perspective, the delivery layer provides consumers and business c By consolidating these formats under a single delivery layer, the Experience Middleware supports both current paper and digital receipt scenarios and future structured invoice and e-invoicing requirements through one coherent integration. +### e-Delivery + +e-Delivery refers to having a defined digital channel for communicating and exchanging documents such as invoices and receipts. + +There are various channels that can be used for document delivery — email, for example, is a widely adopted digital channel based on a defined protocol. In some countries, however, regulatory mandates dictate how documents must be delivered. Historically, this has meant physical printing, but regulations evolve: a market may require email delivery today, a specific network protocol tomorrow, and something else entirely in the future. + +A well-known example of a mandated delivery channel is **Peppol**, a standardised network used across several countries for B2B and B2G document exchange. + +The key distinction here is between: +- **Format** — the structured data representation of a document (e.g. e-invoice). +- **Delivery** — the channel through which that document reaches the recipient. +- **Mandate** — the local regulatory requirement that defines which channel must be used. + +fiskaltrust supports the creation and conversion of structured document formats across markets. Delivery, however, is governed by local regulation — each market may mandate a different channel for different invoice types. While fiskaltrust can produce the correct format, the actual delivery to the recipient is handled outside the Middleware, in line with the applicable local requirements. + ## Intended Audience for Delivery Integration Delivery integration is primarily relevant for: diff --git a/poscreators/middleware-doc/general/data-structures/data-structures.md b/poscreators/middleware-doc/general/data-structures/data-structures.md index c4b5989..df88944 100644 --- a/poscreators/middleware-doc/general/data-structures/data-structures.md +++ b/poscreators/middleware-doc/general/data-structures/data-structures.md @@ -7,7 +7,7 @@ title: Data Structures This chapter outlines several data structures, which are used in the communication with the fiskaltrust.Middleware. -## Receipt Request +## ReceiptRequest The cash register transfers the data of an entire receipt request to **fiskaltrust.Middleware** using the `ReceiptRequest` data structure. The details of the fields supported by this structure are outlined in the following table. From 4e2842eb34ab8d4c473815103654bf6931c2306b Mon Sep 17 00:00:00 2001 From: deboragracio Date: Fri, 22 May 2026 14:19:48 +0200 Subject: [PATCH 5/6] refined text --- .../experience-middleware/delivery.md | 15 ++++----------- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git a/poscreators/middleware-doc/experience-middleware/delivery.md b/poscreators/middleware-doc/experience-middleware/delivery.md index 11f5395..6056690 100644 --- a/poscreators/middleware-doc/experience-middleware/delivery.md +++ b/poscreators/middleware-doc/experience-middleware/delivery.md @@ -219,18 +219,11 @@ By consolidating these formats under a single delivery layer, the Experience Mid ### e-Delivery -e-Delivery refers to having a defined digital channel for communicating and exchanging documents such as invoices and receipts. +e-Delivery refers to having a defined digital channel for communicating and exchanging documents such as invoices and receipts. Common channels include email — a widely adopted digital protocol — or regulated networks such as **Peppol**, mandated in several countries for B2B and B2G document exchange. -There are various channels that can be used for document delivery — email, for example, is a widely adopted digital channel based on a defined protocol. In some countries, however, regulatory mandates dictate how documents must be delivered. Historically, this has meant physical printing, but regulations evolve: a market may require email delivery today, a specific network protocol tomorrow, and something else entirely in the future. +It is important to distinguish between the **format** (the structured data representation), the **delivery channel** (how the document reaches the recipient), and the **mandate** (the local regulatory requirement defining which channel must be used). A market may require physical printing today, email tomorrow, or a specific network protocol in the future — delivery rules evolve with local regulation. -A well-known example of a mandated delivery channel is **Peppol**, a standardised network used across several countries for B2B and B2G document exchange. - -The key distinction here is between: -- **Format** — the structured data representation of a document (e.g. e-invoice). -- **Delivery** — the channel through which that document reaches the recipient. -- **Mandate** — the local regulatory requirement that defines which channel must be used. - -fiskaltrust supports the creation and conversion of structured document formats across markets. Delivery, however, is governed by local regulation — each market may mandate a different channel for different invoice types. While fiskaltrust can produce the correct format, the actual delivery to the recipient is handled outside the Middleware, in line with the applicable local requirements. +fiskaltrust supports the creation and conversion of structured document formats across markets. The actual delivery to the recipient, however, is handled outside the Middleware in line with the applicable local requirements. ## Intended Audience for Delivery Integration @@ -238,4 +231,4 @@ Delivery integration is primarily relevant for: - **PosCreators** who want to offer merchants a complete set of receipt and invoice delivery options without implementing each format independently. - **PosDealers** who configure delivery channels for merchants across different markets and customer segments. -- **PosOperators** who need to provide flexible, compliant checkout experiences across paper, digital, and structured document formats. \ No newline at end of file +- **PosOperators** who need to provide flexible, compliant checkout experiences across paper, digital, and structured document formats. From 9a198822a820565f6cba135488fa6a8fe6274c71 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Fri, 22 May 2026 14:40:21 +0000 Subject: [PATCH 6/6] fix: allow Copilot user in CLA assistant allow list Agent-Logs-Url: https://github.com/fiskaltrust/docs/sessions/694d47d7-d7a1-41d3-9e0b-94deffe92915 Co-authored-by: deboragracio <63159404+deboragracio@users.noreply.github.com> --- .github/workflows/cla.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/cla.yml b/.github/workflows/cla.yml index 5a3097c..efa660f 100644 --- a/.github/workflows/cla.yml +++ b/.github/workflows/cla.yml @@ -36,4 +36,4 @@ jobs: claDocumentFile: "https://github.com/fiskaltrust/.github/blob/main/CLA.md" claSignatureRepoPath: "cla-signatures" prNumber: "${{ github.event.pull_request.number || github.event.issue.number }}" - allowList: "ReleaseBot" + allowList: "ReleaseBot,Copilot"