Skip to content
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.

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

Q: How can I handle the voiding of receipts for the german market? #4

Closed
christian-rogobete opened this issue May 20, 2020 · 3 comments
Assignees
Labels
in progress This issue is already in progress to be resolved.

Comments

@christian-rogobete
Copy link
Contributor

christian-rogobete commented May 20, 2020

There are two ways mentioned in the interface-doc:

  1. by receipt case flag ftReceiptCase : 0x0000000000040000
  2. by cancelation indicator of a new receipt that voids another previous receipt: The signs for the charge items and pay items must be reversed comparing to the receipt to be voided "ftReceiptCaseData":"{ ..., "VoidingReceipt":1, ... }" (BON_STORNO).

What is the difference, when should I use the first way and when should I use the second?

@christian-rogobete christian-rogobete added the new Q&A This issue requests to add a new Q&A set label May 20, 2020
@AxelKutschera
Copy link
Contributor

Handling cancellations (see also the attachments in languages DE and EN)

Reversal of operations and items
• Cancellation of operations
o Subsequent process cancellation (DSFinV-K 4.2.2)
 The reversal receipt is a separate receipt, which is to be identified by BON_STORNO = "1". The signs of QUANTITY, GROSS SALES, NET SALES and VAT are to be reversed.
 For unique identification cbPreviousReceiptReference is to be used accordingly.
 The new cancellation document to be created is to be marked with the ReceiptCaseFlag "reverse/voided receipt", 0x0000000000040000.
 This will mark the document in DSFinV-K with BON_STORNO = "1".
 The statement in DSFinV-K Page 80 that BON_STORNO may not be used if a negative reverse posting of the transaction has been made is correct in this respect, as this refers to the original receipt to be cancelled.
o Immediate transaction cancellation (DSFinV-K 4.2.1)
 Immediate transaction cancellation is mapped like "Subsequent transaction cancellation".
 Since fiskaltrust does not support "old" cash registers which are not connected to a TSE, the immediate transaction cancellation by subsequent marking of the data record with the cancellation flag "BON_STORNO" by the ft.Interface is NOT supported.
 The transaction category "AV document reversal" can therefore also not be used.
• Cancellation of items (DSFinV-K 4.2.3)
 As with the transaction cancellation, an additional item data record must be created. The signs of QUANTITY, GROSS SALES, NET SALES and VAT must be reversed.
 The cancellation of positions by subsequently marking the position with the cancellation flag "P_STORNO" must not be used.
DSFinV-K: https://fiskaltrust.de/dsfinv-k/
Page 33:
Presentation of special events
4.2.1 Immediate process cancellations
Immediate transaction cancellation is only possible for systems that are not connected to a TSE (e.g. cash registers that can be used with transitional regulation until 31.12.2022), if a receipt has been generated but the transaction does not take place immediately (e.g. because the customer has forgotten the money). An immediate reversal can only be carried out in these case constellations.
The mapping can be done in two ways:

  • BON_STORNO is set to "1", otherwise the data record remains unchanged (in particular, no second data record is created; only in these cases may the transaction category "AV document reversal" be used), or
  • Proceed as described below for "Subsequent transaction cancellation".
    4.2.2 Subsequent transaction cancellations
    Special rules apply to the subsequent cancellation of a transaction:
  • The original receipt remains unchanged.
  • The reversal receipt is a separate receipt, which must be identified by BON_STORNO = "1". In this case, the transaction category is to be specified with "Beleg" (analogous to the original receipt). The +/- signs are to be reversed.
    In order to enable a reference to the original transaction, special reference fields for unique identification are included in the DSFinV-K.
    From a sales tax point of view, a reversal invoice belongs to the area of invoice correctionPage just as for invoices, the legally required information according to § 14 paragraph 4 UStG also applies to invoice corrections.

PAGE 34:
4.2.3 Cancellation of items
Cancellations to be carried out at item level take place in the area of bonuses.
You must either set P_STORNO to "1" in the original item (without creating a second data row) or create an additional item data record in which QUANTITY, GROSS SALES, NET SALES and VAT are displayed with negative sign. In this case P_STORNO must not be set to "1".
As soon as the transaction is signed in the TSE, the P_STORNO field may no longer be used.

PAGE 35:
4.2.5 Transactions with negative items
If items with a negative sign occur in a receipt due to, for example, goods returns, discounts or position cancellations, they are displayed as in a normal sale. Only the sign for the field QUANTITY changes (and thus automatically the sign of POS_BRUTTO, POS_NETTO and POS_UST in the file Bonpos_UST, see 3.1.1.1).

PAGE 41:
Appendix B BON_TYP (transaction type)
The following transaction types (receipt types) are distinguished:

  • AV document cancellation

PAGE 43:
AVBelegstorno
The transaction category " AVBelegstorno" indicates all transactions that are completely reversed. It can only be used within one daily closing. The use of AVBelegstorno is dependent on the POS system and is intended for POS systems that only use a reversal indicator on the original receipt instead of an offsetting entry.
The AVBelegstorno shows a complete reversal of the original receipt so that all amounts are no longer included in the daily closing.
Note: The AVBelegstorno does not mean the negative display of a receipt. You must still use the transaction category "Beleg" with reversed +/- signs and no reversal indicator. In these cases, it should be noted that a reference to the original operation must be made.
Attention! As soon as a TSE is used at a cash register, it is technically no longer possible to use the transaction type "AVBelegstorno" correctly, as each document has already been signed by the TSE before the reversal indicator is set. In this respect, it is no longer possible to "zero" a receipt afterwards.

Page 79ff Chapter: Single Recording Module
11. file "receipt header" (transactions.csv)
Page 80:
BON_STORNO
Field type: Character
Field length: 1
Short description: The activation (value: "1") of this field marks the cancellation of a single receipt. An entry is mandatory ("0" or "1"). BON_STORNO may only be set to "1" if a complete transaction is "cancelled" immediately and without offsetting entry, but not if a negative reverse posting of the transaction is made. Cf. comments on points 4.2.1 and 4.2.2.
Page 89:
P_STORNO
Field type: Character
Field length: 1
Short description: Position reversal indicator. If the field is activated (value = "1"), the position is cancelled (immediately during data entry).
PAGE 107ff:
Annex I Definition "Type" and "Data" of the operation; QR code

  1. definition of the data structures for transfer to the security module

    Cash receipt
    processType: Cash voucher-V1
    processData: ^^
    Separator: ^ (Unicode U+005E)
    :
    The transaction type according to DSFinV-K can have the following values:
  • AV document cancellation

20200522 Storno Beleg_Porition EN.docx

20200522 Storno Beleg_Porition DE.docx

@AxelKutschera
Copy link
Contributor

Draft of a Github-PR

Reverse/Voided
https://github.com/AxelKutschera/interface-doc/blob/master/doc/general/reference-tables/reference-tables.md
0x0000000000040000 "reverse receipt" or "voided receipt"
Used to separate regular receipts from the receipts which were voided by setting the negative values for Amounts and Quantity in Chargeitems and Payitems of the receipt. The cbPreviousReceiptReference should be set to the ReceiptReference of the Receipt which should be voided.

https://github.com/AxelKutschera/interface-doc/blob/master/doc/appendix-de-kassensichv/reference-tables/reference-tables.md
0x0000000000040000 reverse/voided receipt
DSFinV-K:
• The reversal receipt is a separate receipt, which is to be identified by BON_STORNO = "1". The signs of QUANTITY, GROSS SALES, NET SALES and VAT are to be reversed.
• For unique identification cbPreviousReceiptReference is to be used accordingly.
• The new cancellation document to be created is to be marked with the ReceiptCaseFlag "reverse/voided receipt", 0x0000000000040000.
• This will mark the document in DSFinV-K with BON_STORNO = "1".
• The statement in DSFinV-K p. 80 that BON_STORNO may not be used if a negative reverse posting of the transaction has been made is correct in this respect, as this refers to the original receipt to be cancelled.overrides BON_TYP=AVBelegstorno

Handling of the cancellation flags in DE: (DRAFT)
• New minus document with flag in ftRCData - ftMW creates a document with the sent signs and the flag BON_STORNO
• New normal document (without minus) with flag (0x40000) - ftMW creates a document with opposite sign than sent in the request and the flag BON_STORNO

20200522 Github PR - Training and cancellation - Draft.docx

@christian-rogobete christian-rogobete added the in progress This issue is already in progress to be resolved. label May 25, 2020
@christian-rogobete christian-rogobete changed the title How can I handle the voiding of receipts for the german market? Q: How can I handle the voiding of receipts for the german market? May 26, 2020
@christian-rogobete
Copy link
Contributor Author

see #20

@christian-rogobete christian-rogobete removed the new Q&A This issue requests to add a new Q&A set label Jun 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in progress This issue is already in progress to be resolved.
Projects
None yet
Development

No branches or pull requests

2 participants