Skip to content

Reference Tables improvements (country-specific) #53

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
deboragracio merged 8 commits into from
Jun 26, 2026
Merged

Reference Tables improvements (country-specific) #53

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
6dc72e1
AT/BE
deboragracio Jun 10, 2026
8ac0f7b
DE
deboragracio Jun 10, 2026
99806d6
ES
deboragracio Jun 10, 2026
38420eb
FR/GR
deboragracio Jun 11, 2026
baeb7ab
IT/PT
deboragracio Jun 11, 2026
ca7a93f
Merge branch 'main' into reference-tables-improvements
deboragracio Jun 17, 2026
b0b0608
Applied changes to AT, DE, FR
deboragracio Jun 25, 2026
ec96d2e
Merge branch 'main' into reference-tables-improvements
deboragracio Jun 26, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
302 changes: 155 additions & 147 deletions poscreators/middleware-doc/middleware-at-rksv/reference-tables/reference-tables.md
View file
Open in desktop

Large diffs are not rendered by default.

22 changes: 14 additions & 8 deletions poscreators/middleware-doc/middleware-be/reference-tables/reference-tables.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,9 +5,15 @@ title: Reference Tables

# Reference Tables

This chapter expands on the reference tables covered in [Reference Tables in General Part](../../general/reference-tables/reference-tables.md), with country-specific information applicable to the Belgian market. The respective tables can be found in the following sub-sections.
This page expands on the reference tables covered in the [Reference Tables](../../general/reference-tables/reference-tables.md) of the Compliance Middleware, with country-specific information applicable to the Belgian market. The respective tables can be found in the following subsections.

As the Middleware abstracts processes and data over multiple markets/countries, there is a specific mapping for Belgian market. This mapping is based upon the overall tagging system which gives the additional benefit of giving all receipts, chargeitems and payitems also a semantical value. The following section describes the overall format.
:::info POSSystem API v2 Reference

The Compliance Middleware [Reference Tables](../../general/reference-tables/reference-tables.md) contain the core POSSystem API v2 tagging structure used across all markets and should be your primary reference.

:::

As the Middleware abstracts processes and data over multiple markets/countries, there is a specific mapping for the Belgian market. This mapping is based upon the overall tagging system which gives the additional benefit of giving all receipts, chargeitems and payitems also a semantical value. The following section describes the overall format.

## Format

Expand All @@ -19,9 +25,9 @@ _4245_2000_0010_0001

_CCCC_vIII_gggg_xxxx

| **Value** | **Description** |
|----------------------|-----------------------------------------------------------------------------------------------------|
|CCCC|(e.g 4245): ASCII of two letter ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1) (e.g. BE = 4245) |
|vIII|(e.g. 2000): This section is for versioning the tagging system (currently v2) and for future use |
|gggg|(e.g. 0010): These items are used for flags. Flags can change the basic behavior of a given type, but will leave the overall semantical meaning of a type the same. (e.g. voiding of a receipt)|
|xxxx|(e.g. 0001): The last category is usually case specific but always consists of 4 numbers |
| **Value** | **Description** |
| --------- | ----------------|
| CCCC | (e.g 4245): ASCII of two letter ISO country code (https://en.wikipedia.org/wiki/ISO_3166-1) (e.g. BE = 4245) |
| vIII | (e.g. 2000): This section is for versioning the tagging system (currently v2) and for future use. |
| gggg | (e.g. 0010): These items are used for flags. Flags can change the basic behavior of a given type, but will leave the overall semantical meaning of a type the same. (e.g. voiding of a receipt). |
| xxxx | (e.g. 0001): The last category is usually case specific but always consists of 4 numbers. |
28 changes: 14 additions & 14 deletions ...reators/middleware-doc/middleware-be/reference-tables/service-status-ftstate.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,22 +13,22 @@ _CCCC_vlll_gggg_gggg_
version 2

#### gggg_gggg - global tagging/flag
| **Value** | **Description** | **Middleware Version** |
|----------------------|-----------------------------------------------------------------------------------------------------|---------------------|
| `0000_0001 ` | **Security Mechanism is out of Operation** <br />Queue is not started or already stopped. | 1.3.45 |
| `0000_0002 ` | **SCU (Signature Creation Unit) temporary out of service**<br />For at least one receipt, it was not possible to receive the signature from an allocated SCU, therefore the security mechanism has been put into "signature creation device out of service" mode. Regardless of whether an allocated SCU is available again or not, the mode remains in place until a ZeroReceipt cleans up the state and takes the market specific action required.| 1.3.45 |
| `0000_0008 ` | **Deferred Queue Mode / Late Signing Mode is active**<br />When the cash register doesn’t reach the queue, it queues up the receipt requests while continuing to do business. Also, with a major failure of the cash register or a power outage, handwritten paper receipts are queued up while continuing to do business. After getting back to a full functional state, these queued-up ReceiptRequests are sent to the queue, having the original cbReceiptMoment of the business case and ReceiptCase tagged/flagged with 0001 (Deferred Queue / Late Signing) or 0008 (Handwritten). <br />A result of this is a marker within the ftState, which can be resolved via ZeroReceipt. The reason for the marker is a mismatch between processed time along the receipt chain and a manual event to clean up the state and maybe notify 3rd parties of an outage. | 1.3.45 |
| `0000_0040 ` | **Message Pending** <br />Middleware/Queue is a headless background service, but there are situations where communication with the cashier/operator or the cash register is necessary. For example, if the last daily closing was missed or if a special condition related to the signature creation unit or service happened. This is the moment when the message pending flag is set by the middleware, which should be signalled to the cashier by the POS system. By executing a ZeroReceipt, the cashier can read the message or instruction on the printed or displayed receipt.<br />Related to local regulations, this receipt may be stored/archived with/for bookkeeping purposes; if this is the case, this is also visualized. | 1.3.45 |
| `0000_0100 ` | **DailyClosing due** <br />When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done. <br />DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClosing to clear persistent changes in business data and also changes in the business period. | 1.3.45 |
| `EEEE_EEEE ` | **Error** <br />Something went wrong while processing the last request. QueueItem exists but didn’t reach the state of a ReceiptItem and didn’t consume a ftReceiptNumber within the chain. Error reason is shown within the responded ftSignatureItems. <br />This happens, for example, if the ReceiptCase is not recognized or is wrong. | 1.3.45 |
| `FFFF_FFFF ` | **Fail** <br />Something went wrong while processing the last request, and nothing persisted within the Queue. Fail reason is shown within the responded ftSignatureItems. <br />This happens, for example, when the flag ReceiptRequest is used after a communication outage, and no properly processed item is found. | 1.3.45 |

| **Value** | **Description** | **Middleware Version** |
| --------- | --------------- | ---------------------- |
| `0000_0001` | **Security Mechanism is out of Operation**<br />Queue is not started or already stopped. | 1.3.45 |
| `0000_0002` | **SCU (Signature Creation Unit) temporary out of service**<br />For at least one receipt, it was not possible to receive the signature from an allocated SCU, therefore the security mechanism has been put into "signature creation device out of service" mode. Regardless of whether an allocated SCU is available again or not, the mode remains in place until a ZeroReceipt cleans up the state and takes the market specific action required. | 1.3.45 |
| `0000_0008` | **Deferred Queue Mode / Late Signing Mode is active**<br />When the cash register doesn’t reach the queue, it queues up the receipt requests while continuing to do business. Also, with a major failure of the cash register or a power outage, handwritten paper receipts are queued up while continuing to do business. After getting back to a full functional state, these queued-up ReceiptRequests are sent to the queue, having the original cbReceiptMoment of the business case and ReceiptCase tagged/flagged with 0001 (Deferred Queue / Late Signing) or 0008 (Handwritten).<br />A result of this is a marker within the ftState, which can be resolved via ZeroReceipt. The reason for the marker is a mismatch between processed time along the receipt chain and a manual event to clean up the state and maybe notify 3rd parties of an outage. | 1.3.45 |
| `0000_0040` | **Message Pending**<br />Middleware/Queue is a headless background service, but there are situations where communication with the cashier/operator or the cash register is necessary. For example, if the last daily closing was missed or if a special condition related to the signature creation unit or service happened. This is the moment when the message pending flag is set by the middleware, which should be signalled to the cashier by the POS system. By executing a ZeroReceipt, the cashier can read the message or instruction on the printed or displayed receipt.<br />Related to local regulations, this receipt may be stored/archived with/for bookkeeping purposes; if this is the case, this is also visualized. | 1.3.45 |
| `0000_0100` | **DailyClosing due**<br />When the first cbReceiptMoment used since the last DailyClosing and the current/latest cbReceiptMoment in the ReceiptRequest have a date-gap of more than two days (for example, the first since the last daily closing is 24/08 and the current is 26/08), then this state indicates, a Daily Closing should be done.<br />DailyClosing is an essential part of the security mechanism and also executes additional market-specific cleanup tasks. Therefore, each queue should do a DailyClosing to clear persistent changes in business data and also changes in the business period. | 1.3.45 |
| `EEEE_EEEE` | **Error**<br />Something went wrong while processing the last request. QueueItem exists but didn’t reach the state of a ReceiptItem and didn’t consume a ftReceiptNumber within the chain. Error reason is shown within the responded ftSignatureItems.<br />This happens, for example, if the ReceiptCase is not recognized or is wrong. | 1.3.45 |
| `FFFF_FFFF` | **Fail**<br />Something went wrong while processing the last request, and nothing persisted within the Queue. Fail reason is shown within the responded ftSignatureItems.<br />This happens, for example, when the flag ReceiptRequest is used after a communication outage, and no properly processed item is found. | 1.3.45 |

#### llll -local flags

cba c=reserved; b=reporting; a=scu related
#### llll - local flags

| **Value** | **Description** | **Middleware Version** |
|----------------------|-----------------------------------------------------------------------------------------------------|---------------------|
|TBD|TBD|TBD|
cba c=reserved; b=reporting; a=scu related

| **Value** | **Description** | **Middleware Version** |
| --------- | --------------- | ---------------------- |
| TBD | TBD | TBD |
8 changes: 4 additions & 4 deletions .../middleware-doc/middleware-be/reference-tables/type-of-journal-ftjournaltype.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,8 +5,8 @@ title: 'Type of Journal: ftJournalType'

# Type of Journal: ftJournalType

This table expands on the values provided in table of Chapter ["Type of Journal: ftJournalType"](../../general/reference-tables/reference-tables.md#type-of-journal-ftjournaltype) of the General part with values applicable to the Belgian market.
This table expands on the values provided in the [Type of Journal: ftJournalType](../../general/reference-tables/reference-tables.md#type-of-journal-ftjournaltype) reference table of the Compliance Middleware with values applicable to the Belgian market.

| **Value** | **Description** | **Version** |
|----------------------|--------------------------------|-------------|
| `000` | Status Information QueueBE | 1.3.45 |
| **Value** | **Description** | **Middleware Version** |
| --------- | --------------- | ---------------------- |
| `000` | Status Information QueueBE | 1.3.45 |
66 changes: 34 additions & 32 deletions .../middleware-doc/middleware-be/reference-tables/type-of-payment-ftpayitemcase.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,48 +5,50 @@ title: 'Type of Payment: ftPayItemCase'

# Type of Payment: ftPayItemCase

This table expands on the values provided in table [ftPayItemCase in General Part](../../general/reference-tables/reference-tables.md#type-of-payment-ftpayitemcase) with values applicable to the Belgian market.
This table expands on the values provided in the [Type of Payment: ftPayItemCase](../../general/reference-tables/reference-tables.md#type-of-payment-ftpayitemcase) reference table of the Compliance Middleware with values applicable to the Belgian market.

## Format

_CCCC_vlll_gggg_xxPP_
_CCCC_vlll_gggg_xxPP_

#### v - version
version 2

#### PP - payment type
| **Value** | **Description** | **Middleware version** |
| -------------------- | ---------------------------------------------------------------------------------------------- | ---------------------- |
| `00` | **Unknown payment type for BE**<br />This is handled like a cash payment in national currency. | 1.3.45 |
| `01` | **Cash payment**<br />cash | 1.3.45 |
| `02` | **NonCash**<br />cash | 1.3.45 |
| `03` | **Crossed cheque**<br />cash | 1.3.45 |
| `04` | **Debit card payment**<br />cash | 1.3.45 |
| `05` | **Credit card payment**<br />cash | 1.3.45 |
| `06` | **Voucher payment (coupon) - voucher by money value**<br />cash | 1.3.45 |
| `07` | **Online payment**<br />noncash | 1.3.45 |
| `08` | **Loyalty program Customer card payment**<br />|1.3.45|
| `09` | **Accounts receivable**<br />| 1.3.45 |
| `0A` | **SEPA transfer**<br />| 1.3.45 |
| `0B` | **Other Bank transfer**<br />| 1.3.45 |
| `0C` | **Transfer to Cashbook / Vault / Owner / Employee**<br />Positive (+) amount contributes to cashbox/vault. This higher the amount in cashbox/vault.<br />Negative (-) amount lowers the amount in cashbox/vault. |1.3.45|
| `0D` | **Internal / Material consumption**<br />| 1.3.45|
| `0E` | **Grant**<br />| 1.3.45|
| `0F` | **Ticket Restaurant / (Sodexo, edenred, usw.)**<br />| 1.3.45|

| **Value** | **Description** | **Middleware version** |
| --- | --- | --- |
| `00` | **Unknown payment type for BE**<br />This is handled like a cash payment in national currency. | 1.3.45 |
| `01` | **Cash payment**<br />cash | 1.3.45 |
| `02` | **NonCash**<br />cash | 1.3.45 |
| `03` | **Crossed cheque**<br />cash | 1.3.45 |
| `04` | **Debit card payment**<br />cash | 1.3.45 |
| `05` | **Credit card payment**<br />cash | 1.3.45 |
| `06` | **Voucher payment (coupon) - voucher by money value**<br />cash | 1.3.45 |
| `07` | **Online payment**<br />noncash | 1.3.45 |
| `08` | **Loyalty program Customer card payment** | 1.3.45 |
| `09` | **Accounts receivable** | 1.3.45 |
| `0A` | **SEPA transfer**<br /> | 1.3.45 |
| `0B` | **Other Bank transfer** | 1.3.45 |
| `0C` | **Transfer to Cashbook / Vault / Owner / Employee**<br />Positive (+) amount contributes to cashbox/vault. This higher the amount in cashbox/vault.<br />Negative (-) amount lowers the amount in cashbox/vault. | 1.3.45 |
| `0D` | **Internal / Material consumption** | 1.3.45 |
| `0E` | **Grant** | 1.3.45 |
| `0F` | **Ticket Restaurant / (Sodexo, edenred, usw.)** | 1.3.45 |

#### v - version
version 2

#### gggg - global tagging/flag
| **Value** | **Description** | **Middleware version** |
| -------------------- | ---------------------------------------------------------------------------------------------- | ---------------------- |
| `0001` | **IsVoid**<br />Marks PayItem as Void previous position. Quantity and amount are inverted, related to original item. <br />IsVoid is used in cases where the exchange of money has not been executed yet. | 1.3.45|
| `0002` | **IsReturn/IsRefund**<br />Marks PayItem as Return of good or service. Quantity and amount are inverted, related to original item.<br />IsReturn/IsRefund is used in cases where the exchange of money has been executed already.| 1.3.45|
| `0004` |**(reserved)**<br />| 1.3.45|
| `0008` |**Downpayment**<br />Marks PayItem as a downpayment. <br />Positive (+) amount is reduction of downpayment. <br/>Negative (-) amount is creation of downpayment.| 1.3.45|
| `0010` | **IsForeignCurrency**<br />Amount is still in EUR, at the moment of acceptance. ftPayItemData requires two data elements with “foreignCurrencySymbol” and “foreignCurrencyAmount” to persist data for daily closing and later bookkeeping transactions| 1.3.45|
| `0020` | **IsChange**<br />Usually contains a negative (-) amount.<br /> (IsVoid => can be inverted)| 1.3.45 |
| `0040` | **IsTip**<br />Must be a negative (-) amount to flow out of payment method.<br />ShowInChargeItems flag can be used to raise the total amount by the tip amount, to have a more convenient visualization.| 1.3.45 |
| `0080` | **IsDigital/IsElectronic**<br />Electronic money, digital money | 1.3.45 |
| `0100` | **IsInterface/AmountVerified**<br />Was verified by interface, automated amount transfer | 1.3.45 |
| `8000` | **ShowInChargeItems**<br />Visualize the item before Total Amount. This inverts amount and does include the amount into the visualized total amount on the receipt. |1.3.45|

| **Value** | **Description** | **Middleware Version** |
| --- | --- | --- |
| `0001` | **IsVoid**<br />Marks PayItem as Void previous position. Quantity and amount are inverted, related to original item. <br />IsVoid is used in cases where the exchange of money has not been executed yet. | 1.3.45 |
| `0002` | **IsReturn/IsRefund**<br />Marks PayItem as Return of good or service. Quantity and amount are inverted, related to original item.<br />IsReturn/IsRefund is used in cases where the exchange of money has been executed already. | 1.3.45 |
| `0004` | **(reserved)**<br /> | 1.3.45 |
| `0008` | **Downpayment**<br />Marks PayItem as a downpayment. <br />Positive (+) amount is reduction of downpayment. <br/>Negative (-) amount is creation of downpayment. | 1.3.45 |
| `0010` | **IsForeignCurrency**<br />Amount is still in EUR, at the moment of acceptance. ftPayItemData requires two data elements with “foreignCurrencySymbol” and “foreignCurrencyAmount” to persist data for daily closing and later bookkeeping transactions | 1.3.45 |
| `0020` | **IsChange**<br />Usually contains a negative (-) amount.<br /> (IsVoid => can be inverted) | 1.3.45 |
| `0040` | **IsTip**<br />Must be a negative (-) amount to flow out of payment method.<br />ShowInChargeItems flag can be used to raise the total amount by the tip amount, to have a more convenient visualization. | 1.3.45 |
| `0080` | **IsDigital/IsElectronic**<br />Electronic money, digital money | 1.3.45 |
| `0100` | **IsInterface/AmountVerified**<br />Was verified by interface, automated amount transfer | 1.3.45 |
| `8000` | **ShowInChargeItems**<br />Visualize the item before Total Amount. This inverts amount and does include the amount into the visualized total amount on the receipt. | 1.3.45 |
Loading
Loading