Belege buchen

 

Reihenfolge der zu buchenden Belege (Kopf, SubTransaktionen)

Folgendermaßen werden derzeit die Belege gebucht:

In der Tabelle wird abgebildet, wie gebucht wird, wenn die verschiedenen Belege (Programmteil) geändert werden (z.B. über das Makro UpdateObject). Die Zahlen zeigen die Reihenfolge. 

Programmteil Modulname Ausbuchen des Kopfes Ausbuchen der Transaktionen Einbuchen des Kopfes Einbuchen der Transaktionen Besonderheit
Lieferschein-Kopf delinedt.mod 1 2 3 4 Einbuchung des Kopfes vor Einbuchung der Transaktion
Lieferschein-Pos. delinedt.mod   1   2 Kopf wird nicht ausgebucht
Rechnungs-Kopf billiedt.mod 1   2   Transaktionen werden nicht ausgebucht
Rechnungs-Pos. invoiitm.mod   1   2 Kopf wird nicht ausgebucht
Bestell-Kopf purcoedt.mod 1 2 3 4 STANDARD
Bestell-Pos. puroiedt.mod 1 2 3 4 STANDARD

Der Stand in den Bestellmodulen soll der Standard werden.

Erläuterung zum werdenden Standard:

Belegkopf:

Wird in einem Modul über das Makro UpdateObject der Kopf verändert, so wird am Anfang des Makros erst mal der Kopf und dann alle Positionen über die entsprechenden Messages ausgebucht:

purchaseOrder (-1) SendMsg(BOOK_PURCHASE_ORDER)  ... um den Kopf auszubuchen und....

purchaseOrder (-1) SendMsg(BOOK_PURCHASE_ORDER_ITEM)   ..... um alle Transaktionen auszubuchen.

Nach der Bearbeitung des Kopfes werden über die selben Messages die Belege wieder eingebucht. Anstatt der (-1) wird nun eine 1 auf den Stack gelegt.

Belegpositionen:

In allen Fällen, in denen die Belege geändert werden, muss zuerst einmal der Belegkopf ausgebucht werden. Dann wird gezielt die eine zu ändernde Transaktion über die entsprechende Message ausgebucht.

purchaseOrder (-1) SendMsg(BOOK_PURCHASE_ORDER)  ... um den Kopf auszubuchen und....

purchaseOrderItem (-1) SendMsg(BOOK_PURCHASE_ORDER_ITEM)   ..... um die aktuelle Position auszubuchen

Nach den Änderungen (DrainWindow und Co.) müssen die Belege über die gleiche Art eingebucht werden. Anstatt der (-1) wird nun eine 1 auf den Stack gelegt.

 

Allgemeines:

Messages:

Es ist in jedem Modul, welches Belege ein- oder ausbucht, eine Message nach dem Schema BOOK_XXXXXXX oder BOOK_XXXXXX_ITEM zu definieren. Diese Messages rufen dann ein Makro zum Ausbuchen (BookByEdit[Item]Back) auf, welches die Belege ausbucht und ein Makro (BookByEdit[Item]), welches die Belege wieder einbucht.

Transaktionsbeschreibungen:

In der Transaktionsbeschreibung des Kopfes ist ein Haken bei Subtransaktionen gesetzt und der Wert "false" im nebenstehenden Feld eingetragen. Dies verhindert, dass die Transaktionsbeschreibung durch alle Unterteile läuft, was sie im Normalfall machen würde. Dieser Haken ist natürlich bei den Transaktionsbeschreibungen der Positionen nicht gesetzt.

 

Transaktionsbeschreibungen/Geschäftsprozesse

 

Transaktion mit Status (Workflow) verbinden und Status weiterschalten:

  1. Der Workflow des entsprechenden Objektes wird geholt (
    "SALES_ORDER" "uniqueID = %s" FindFirst(CX_WORK_FLOW)
  2. Dieser Workflow enthält eine oder mehrere Folgen von möglichen Stati.
    Es können, wie zum Beispiel im Auftrag, mehrere voneinander unabhängige Stati vergeben werden. Es wird nun die ID des ersten Status der ausgewählten Folge auf den Stack gelegt, und in der Monitors Collection des in Schritt 1 geholten Workflows gesucht.
    "SALES_ORDER_NOT_CONFIRMED" "uniqueID = %s" tmp FindFirst(CX_STATE_MONITOR, monitors)
  3. Nun hat man einen CX_STATE_MONITOR, den man mit dem Objekt verbinden kann.
    Hierfür muß man einen Namen vergeben, unter dem nachher diese Folge gefunden werden kann. Für dieses Beispiel eignet sich der Name „CONFIRMATION“ wohl am Besten. Dieser vorher in Schritt 2 ausgewählte Monitor wird nun mit dem Namen CONFORMATION gewrappt und in die Collection Monitors des Objektes eingefügt.
    "CONFIRMATION" order Call(ConnectStateMonitor)
  4. Der Status wird nun beim Buchen des Objektes anhand der Folgezustände, die in den Workflows festgelegt sind, über den Befehl TriggeredStateMonitor(„CONFIRMATION“) in den Transaktionsbeschreibungen weitergeschaltet. In den Klammern des Befehls TriggeredStateMonitor steht dann der Name, der vorher für den Wrapper (Schritt 3) festgelegt wurde. Dieser ist nicht fest, sondern könnte frei vergeben werden. Allerdings ist dies nur theoretisch so. Um Verwirrungen zu vermeiden, sollten bereits vorhandene Namen verwendet werden.

 

Transaktion in Vorgangsordner registrieren (über Transaktionsbeschreibungen):

  1. Zuerst wird die Transaktionsbeschreibung geöffnet oder mit dem Button „Neu“ aus der Liste angelegt und mit einer ID versehen. Die ID sollte so aussehen, wie die zum Objekt gehörende EDIT Message, bei dem Auftragspositionen-Beispiel wäre das EDIT_SALES_ORDER_ITEM.
  2. Über das Menü Bearbeiten->Dimensionen->Einfügen eine neue Position einfügen.
  3. Diese mit einem sinnvollen Namen versehen, wie „Im Vorgangsordner registrieren“.
  4. In der Combobox „Registrierung der Transaktion“ auswählen.
  5. Im Feld Dimensionen wird es nun interessant:
    {last.itemPointer.ForceMonitor("CX_PROCEEDINGS");TopTransaction().Monitor("CX_STATE_MONITOR").owner};TopTransaction().date.Year()
    Dieser String besteht aus zwei Hauptteilen, die durch ein Semikolon getrennt sind. Der erste Teil gibt an, in welchem Vorgangsordner und welchem Unterordner. Der zweite Teil gibt das für die Transaktion gültige Jahr an, welches auch als Unterordner angelegt wird. Es entspricht also folgendem Schema: "{Vorgangsordner;Unterordner};Jahr".
    Nehmen wir das ganze mal genauer unter die Lupe. 

 

Wir haben also folgendes Ergebnis dieses Dimensionen Strings:

Vorgangsordner des Teils an „last.itemPointer“ der Transaktion, in diesem Vorgangsordner den Unterordner Aufträge und in diesem Unterordner einen weiteren Unterordner mit dem Kalenderjahr des Auftrages. Hier wird man dann die über diesen Weg registrierte Transaktion wiederfinden.