Daily closing is only half-way processed when SCU is not reachable

[TSchmiedlechner]

Describe the bug

Right now, when doing a daily closing receipt in Germany and the SCU is not reachable during that time (or fails, e.g. due to timeouts, etc.) we do return a "failed receipt", but don't actually process the daily closing. This leads to some follow-up-issues, e.g.:

1. The daily closings don't show up in the receipt journal in the Portal (minor problem)
2. Automatic export ranges - like MeinFiskal and PosArchiv - are calculated based on these action journals. So when this issue happens, the daily closings will still be uploaded and trigger the export in Helipad, but the export range will be wrong (major problem)

To Reproduce

1. Start a MW, ensure everything is working
2. Unplug the TSE
3. Send a daily closing receipt

Further technical details & context

Daily closing receipt: https://github.com/fiskaltrust/middleware/blob/main/queue/src/fiskaltrust.Middleware.Localization.QueueDE/RequestCommands/DailyClosingReceiptCommand.cs

Calculation in Helipad (based on actionjournal): https://dev.azure.com/fiskaltrust/fiskaltrust/_git/fiskaltrust.space.helipad?path=/src/fiskaltrust.space.helipad.Domain/Services/TableStorage/TableStorageProvider.cs&version=GBmain&line=104&lineEnd=105&lineStartColumn=1&lineEndColumn=1&lineStyle=plain&_a=contents

[TSchmiedlechner]

I'd suggest to

1. Create the ActionJournal (with the required fields, check Helipad and Portal for those)
2. Increase queueDE.DailyClosingNumber

And, most importantly, check DSFinV-K and DFKA if this could lead to any issues.

[volllly]

We should also still update the masterdata if the scu is not reachable.

[LeilaZarban]

We have the same issue on MonthlyClosing and yearlyClosing, should we apply the changes to all of them?

[volllly]

Good catch 🙏 Yes I think so

EDIT: Add #230