Simplify SCU switch in Germany

[TSchmiedlechner]

Hey folks,
with the latest advancements about the CryptoVision v2 (#146), the SCU switch again became an important factor. From what i got from our users, this often leads to issues due to complex nature of the operation (configuration can go wrong, SCUs might not properly initialize because of that, etc.)

Hence i was wondering if we can try to collect the problems we have observed in the last months, and make this any simpler for our users. Downwards compatibility on implementation side (start/finish SCU switch receipts) is IMO a crucial thing we need to keep in mind here, but we could either optimize/simplify:

• The flows in the Portal to configure the switch
• The receipts we need to send to the MW to trigger the switch
• The behavior of the Middleware when e.g. multiple SCUs are in a CashBox and a switch is configured, etc.

@saschaknapp @mijomilicevic I guess you were both involved in several SCU switch scenarios now, do you have any insights what the biggest problems were?

[TSchmiedlechner]

👀 @StefanKert

[volllly]

One thing that we have on the road map is a force flag for the initscu switch receipt which skips the check for a daily closing and starts the process in any case.

There is a chance this might be abused but we need functionality like that fore certain edge cases (e.g. GetTseInfo responds but the SCU cannot sign anymore. We've experienced that with SwissbitCloud/Deutsche Fiskal) to perform the switch.

Maybe this will also come in handy for CryptoVison v2 switch.

[mijomilicevic]

@volllly you mean the flag would skip the check for a signed daily closing correct? It still would be necessary to send a closing before the initiate-scu-switch receipt, right?

[volllly]

Yes I think that would make sense 😅