Salta ai contenuti

FAQ

Trova le risposte a 13 domande frequenti su DSFinV-K, organizzate per argomento.

Cash Point Closing (10)
In which cases can a CashPointClosing be deleted?

A CashPointClosing can be deleted if it was successfully created (status COMPLETED) but is incorrect or was submitted more than once.

This typically happens due to incorrect data mapping or duplicate transmissions caused by technical issues.

Deleting sets the status to DELETED, ensuring that the CashPointClosing is excluded from DSFinV-K exports.

The CashPointClosing remains available via the retrieveCashPointClosing endpoint and is not physically removed.

To delete a CashPointClosing, use the deleteCashPointClosing endpoint.

Why can a CashPointClosing with status ERROR not be deleted?

A CashPointClosing with status ERROR is not included in DSFinV-K exports by design.

Deleting a CashPointClosing only changes its status to DELETED, which is used to explicitly exclude entries from exports. Since a CashPointClosing in status ERROR is already ignored, deleting it would have no additional effect and is therefore not supported.

A CashPointClosing in status ERROR can still be retrieved via the retrieveCashPointClosing endpoint.

What should the cash_point_closing_export_id contain?

The field cash_point_closing_export_id corresponds to the field Z_NR in the official DSFinV-K documentation and is described as follows:

 

*The cash register closing is created for a cash register once or multiple times a day; *it can also be created for more than one calendar day. Each cash register has a “Z_NR”, a cash register closing number. This number is ascending and consecutive and cannot be reset.

 

Useful examples and descriptions of the different fields and business cases are given in the DSFinV-K documents of the Federal Central Tax Office (Bundeszentralamt für Steuern):  

DSFinV-K 2.3, (new version) (EN) DSFinV-K 2.3, Stand März 2022 (DE).

What should the lineitem_export_id contain?

The field lineitem_export_id corresponds to the field POS_ZEILE of the DSFinV-K legal documentation and is described as follows:

POS_ZEILE

Position number within a slip (must be unique and consecutive).

 

Good examples and explanations of the different fields and business cases can be found in the DSFinV-K documents of the Federal Central Tax Office (Bundeszentralamt für Steuern):  

DSFinV-K 2.3, (new version) (EN) DSFinV-K 2.3, Stand März 2022 (DE).

What should the transaction_export_id contain?

The field transaction_export_id corresponds to the field BON_ID of the DSFinV-K legal documentation and is described as follows:

The BON_ID is a unique identifier for all processes. It is issued by the cash register being used and is always consecutive. The BON_ID must be issued in an automated and unalterable way for each individual slip in the cash register. It should be issued in a numerically ascending form.

 

Please note that the field should not contain the tx_id of the transaction from SIGN DE.

 

The field first_transaction_export_id corresponds to Z_START_ID of the DSFinV-K (i.e. BON_ID of the first transaction of the cashPointClosing).

 

The field last_transaction_export_id corresponds to Z_ENDE_ID of the DSFinV-K (i.e. BON_ID of the last transaction of the cashPointClosing).

 

Good examples and explanations of the different fields and business cases can be found in the DSFinV-K documents of the Federal Central Tax Office (Bundeszentralamt für Steuern):  

DSFinV-K 2.3 (EN) DSFinV-K 2.4 (DE).

DSFINVK DE - How to deal with unsigned transactions in the daily closing (CashPointClosing)?

Transactions that could not be signed via SIGN DE must still be recorded via DSFINVK DE in the daily closing (insertCashPointClosing).

For this purpose, please use the error_message field with the corresponding error message instead of the transactions[].security.tss_tx_id field.

 

 

 

The UUID for the transactions[].head.tx_id field should be newly generated by you in this case.

What is the process of the field / schema validation of the insertCashPointClosing endpoint?

In order to avoid that heavy loaded requests to the insertCashPointClosing endpoint run into a timeout, the fields validation is done in a separate process.

Due to this, the retrieveCashPointClosing endpoint should be called to check whether a Cash Point Closing has been successfully processed after a certain time.

In case of an incorrect body schema, the response to an insertCashPointClosing request will return the HTTP status code 200 OK first.

However, after validating the schema, the status of the Cash Point Closing will switch to ERROR instead of COMPLETED. This status can be retrieved via the retrieveCashPointClosing endpoint.

The "error" object in the response should contain a more detailed error description.

How long does a Cash Point Closing take until the status is COMPLETED?

A cash point closing can take a few seconds to a few minutes (maximum probably 2-3 hours) until the status COMPLETED is reached. The duration can generally not be precised as it depends on individual factors.  For example, if you transmit a large amount of cash point closings at the same time, the status of individual cash point closings may remain on PENDING for some time.   If you are currently dealing with a cash point closing that remains in status PENDING for an extended period of time, please send us a message at dev-support@fiskaly.com.

What are the steps necessary to create a Cash Point Closing?

It is helpful to get familiar with the DSFinV-K documentation provided on the Bundeszentralamt für Steuern (BZSt) - the German Federal Central Tax Office’s official site. These documents are accessible in both English and German, though it’s worth noting that certain sections may be missing from the English versions.

Note: Exports can be triggered and downloaded via the fiskaly Dashboard.

Is it possible to insert a cash point closing without any transaction?

It is now also possible to transfer a daily closing (cashPointClosing) without transactions to the DSFinV-K API.

The objects cash_statement and transactions are no longer required and are not to be used in this case.

The body of the insertCashPointClosing request therefore reflects this example:

`{
    "head": {
        "first_transaction_export_id": null,
        "last_transaction_export_id": null,
        "export_creation_date": {{$timestamp}}
    },
    "client_id": "{{client_id}}",
    "cash_point_closing_export_id": {{Z_NR}}
}`

 

Please note: fiskaly is not allowed to provide tax advice. Please contact your tax advisor, tax auditor or lawyer for tax-related questions.

Exports (2)
Why is my DSFinV-K export empty when I open the zip file?

If you are using Windows and notice that your DSFinV-K export files seem empty after unpacking, it might be related to the used zip software. Trying a different archive extractor e.g. 7zip, WinRAR, PeaZip, or Bandizip may resolve the issue. These programs can be downloaded via the official websites or other trusted sources.

What steps are necessary to create a DSFinV-K export?

Please read the following official DSFinV-K documents provided by the German Federal Central Tax Office (Bundeszentralamt für Steuern) - download link DSFinV-K 2.4.  

Cash Register (1)
Do I need to create a Cash Register via the DSFinV-K API even though I have already created a client via the Sign DE API?

Yes. Via the SIGN DE API only the client_id and the serial_number of the POS device are submitted. In the DSFinV-K, however, additional information about the POS device is needed (brand, software, …). Therefore, a cash register must also be created via the DSFinV-K API with the same client_id that was used in the SIGN DE.

Was this page helpful?