@Harry55 Da die "Transaktion-Nummer" nicht unter den Dir bekannten Größen aufgelistet ist, frage ich mal ketzerisch:
Ist dieese Nummer vorhanden, wenn die Rechnung nicht gesplittet wird?
Ansonsten ist der Hintergrund des Zustandes / Vorhabens zu wenig beleuchtet.

@Harry55 Das ist jetzt eher eine juristische Angelegenheit, da das Finanzamt da ggf. mit reinspielt.
Muss da ggf. eine neue Transaktionsnummer generiert werden?

@Harry55 Wie wird das denn anderswo gehandhabt?
====
Mit dem vorhandenen Code und einer exakten Aufgabenstellung ist das alles kein Problem.

@Harry55

Die Finanz hat erst später festgestellt, dass das mit lang anhaltenden Bestellvorgängen (so nennt man das in der Gastronomie) technisch nicht so einfach zu lösen ist, ist aber nicht von der "Technik" abgerückt.

Ich habe das ganze mit einer Middleware umgesetzt und die haben ein lokales Webservice dem man alle Daten übermittelt und das dann vieles regelt.

Aus Copyright-Gründen darf ich Dir hier nicht den ganzen Text und Grafik posten, aber ein Ausschnitt hilft Dir sicher die richtigen Informationen im Netz zu finden:

Wir empfehlen Nutzung der Abläufe der Erleichterungsregelungen, da das XXXXX dadurch viele Abläufe übernehmen kann, die sonst von der Kasse erfüllt werden müssten.
...

Für lang anhaltende Bestellvorgänge müsste ein /updateTransaktion aufgerufen werden. Als Erleichterung kann man wie in der Abbildung gezeigt wird statt einem Update auch ein /finishTransaction mit Typ "Bestellung" senden (xxxx).
Vorteile: Die Updates entfallen, somit muss sich die Kasse keine Transaktions ID speichern. Es können gesplittete Rechnungen dargestellt werden.
Voraussetzung: Zusätzlich muss der Startzeitpunkt (xxxx) der ersten "Bestellung" am Bon gedruckt werden.

Wenn mans selbst (ohne Middleware) programmiert, dann vielleicht folgender Tipp:

Update transaction nach jeder Änderung der Tischbuchung.
Splittrechnung unterscheiden sich nicht von normalen Rechnungen.
Im DSFinVK Export kann man Splittrechnungen durch die einheitliche Zuordnung zur Tischnummer erkennen.
Die Splittrechnungen haben den selben Start-Transaction Zeitpunkt wie die erste Bestellung am Tisch.

Erst wenn die letzte Position abgerechnet wurde, und der Tisch dann für den nächsten Gast bebucht wird, dann setzt man wieder eine neue Start-Transcaction.

Fazit: Man muss im DSFinVK Export eindeutig erkennen, welche Transaktionen zu einer langanhaltenden Bestellung alles dazugehören.

Ein Sonderfall ist z.B. wenn ein Produkt von einem Tisch auf einen anderen transferiert wird.
Dann gibts am Quelltisch ein Transaction-Update und am Zieltisch ebenfalls ein Transaction-Update. Ausser dort war vorher noch nichts gebucht, dann muss dort ein Transaction-Start generiert werden.

Alles nicht so trivial und SEEEEEEHR viel Arbeit.

Dann einfach die Produkte die getrennt abgerechnet werden wie eine "neue Tischbuchung" anlegen (also neue Buchung mit Start-Transaktion) und die dann abrechnen. Beim vorhandenen Tisch (also von wo die Artikel weggebucht werden), die Artikel rausnehmen und mit TransaktionUpdate signieren.
Also erzeugt jede Splittbuchung einen eigenen Start/End Vorgang als wäre es ein eigener Beleg. Die "Verbindung" zwischen den Buchungen stellt die Tischnummer dar, die immer gleich sein sollte. Somit kann man später bei einer Prüfung auch sehen, dass das Storno in eine Splittbuchung geflossen ist und nicht einfach so storniert wurde.

@Harry55

So wie es dort steht machen: ".. ein zusätzlicher Positionsdatensatz ist zu erstellen bei dem Menge, Brutto, Netto und UST mit negativen Vorzeichen dargestellt werden.

Das mit dem P_STORNO kann man ignorieren wenn mans mit negativen Werten macht.

Aber genau das ist der Grund warum ich das mit der Middleare von EFSTA mache. Da brauche ich mich um sowas gar nicht zu kümmern. Ich aktualisiere einfach ohne einen vorher gebuchten Artikel, schon wird er durch die Middleware automatisch finanztechnisch korrekt storniert.