Außer dem „Standard“ Detail (mit Read, Insert, Update, Delete) gibt es noch die Möglichkeit, ein „Buchung“ Detail zu nutzen. Hier wird beschrieben, welche Besonderheiten dabei zu beachten sind.

Idee: Anders als bei normalen Details soll es bei Buchungen nicht möglich sein, einen Datensatz nachträglich zu ändern oder zu löschen. Stattdessen muss immer ein Storno- (und Korrektur-)Satz erstellt werden.

Es gibt folgende Knöpfe in der Buchungs-Toolbar:

• Buchen/Korrigieren (Icon und Tooltipp ändert sich entsprechend): Bucht den Datensatz (entspricht dem Speichern im Standard), bzw. erstellt eine Korrektur (Für den bestehenden Datensatz wird ein Storno-Satz erstellt. Außerdem wird ein neuer Datensatz mit den Änderungen angelegt). Beim Korrigieren wird der neue Datensatz ins Detail geladen.
• Neu: Leert das Detail, damit ein neuer Datensatz erfasst werden kann (wie im Standard)
• Stornieren: Storniert den Datensatz, es wird also ein neuer Datensatz angelegt, mit den gleichen Mengen nur „negativ“. Dieser Storno-Satz wird ins Detail geladen.
• Verwerfen: Verwirft Änderungen am Datensatz (wie im Standard)
• Zum Original-Satz: Lädt den Original-Satz ins Detail
• Zum Storno-Satz: Lädt den Storno-Satz ins Detail
• Zum Korrektur-Satz: Lädt den Korrektur-Satz ins Detail
• Detailsatz drucken: Druckt das Detail (muss in der xbs entsprechend konfiguriert werden, wie im Standard)
• Optimieren: Passt die Breite des Details an (wie im Standard)

Um die Buchungs-Toolbar zu aktivieren, muss in der entsprechenden Maske type="booking" gesetzt werden.

Beispiel:

<detail procedure-prefix="xpcor" procedure-suffix="AFISBookingShipment" type="booking" id="ShipmentDetail">

Außerdem sind die folgenden Felder notwendig:

• IsBooked (boolean): true, wenn der Datensatz verbucht wurde
• IsCanceled (boolean): true, wenn der Datensatz storniert wurde
• OriginalKey (int): der Key des Original-Datensatzes
• CorrectedKey (int): der Key des Korrektur-Datensatzes
• CanceledKey (int): der Key des Storno-Datensatzes

Diese Felder sollten read-only sein, da sie nur über die Prozeduren angepasst werden können.

Sie können in einem Debug-Abschnitt versteckt werden, um Verwirrung zu vermeiden:

<page text="Debug" id="Debug" icon="Warning.ico" visible="false">
	<field name="IsBooked" text="@Booked" sql-index="53" read-only="true">
		<boolean/>
	</field>
	<field name="IsCanceled" text="@IsCanceled" sql-index="54" read-only="true">
		<boolean/>
	</field>
	<field name="OriginalKey" text="@OriginalKey" sql-index="50" read-only="true">
		<number/>
	</field>
	<field name="CorrectedKey" text="@CorrectedKey" sql-index="51" read-only="true">
		<number/>
	</field>
	<field name="CanceledKey" text="@CanceledKey" sql-index="52" read-only="true">
		<number/>
	</field>
</page>

Statt der normalen Prozeduren Read, Insert, Update, Delete sind für Buchungs-Masken folgende Prozeduren notwendig:

• Read: Liest alle Detailfelder aus, wie bei normalen Masken.
• Insert: Speichert den Datensatz initial, wie bei normalen Masken.
• Correct: Ersetzt die Update Prozedur. Ist der Datensatz bereits verbucht, darf er nicht mehr verändert werden. Entsprechend muss ein Storno- und ein Korrektur-Satz erstellt werden.
• Cancel: Ersetzt die Delete Prozedur. Ist der Datensatz bereits verbucht, darf er nicht mehr gelöscht werden. Entsprechend muss ein Storno-Satz erstellt werden, der die Mengen in „negativ“ enthält. Anders als bei der Delete Prozedur werden hier ALLE Argumente übergeben, nicht nur die KeyLongs.

Bei den Prozeduren Correct und Cancel muss darauf geachtet werden, dass die Felder OriginalKey, CorrectedKey und CanceledKey in allen betroffenen Datensätzen (Original, Korrektur, Storno) korrekt gesetzt werden, damit das Springen zwischen den Datensätzen funktioniert.

Im Normalfall sollte ein Datensatz verbucht werden, sobald der Datensatz zum ersten Mal gespeichert wird. Damit muss bei jedem Aufruf der Cancel und Correct Prozedur ein Storno- (und Korrektur-)Satz angelegt werden.

Teilweise ist dies aber nicht erwünscht. In AFIS und DISPO gilt ein Datensatz erst als verbucht, wenn er in einem Tagesabschluss enthalten ist. Damit muss die Correct Prozedur überprüfen, ob dies schon geschehen ist. Wenn ja, wird wie gewohnt ein Storno- und Korrektur-Satz angelegt. Wenn nein, wird stattdessen der bestehende Datensatz wie bei einem Aufruf der „normalen“ Update Prozedur bearbeitet. Genauso muss die Cancel Prozedur prüfen, ob ein Storno-Satz erstellt werden muss, oder ob der Datensatz gelöscht werden darf.

Anmelden/Announce ist noch nicht implementiert, siehe #1457.