Historisierte Fristenliste

Vorbedingungen

Wenn die Ausgabe mit der Ausgabe der Hilfssaldenliste des Hilfshauptbuchs verglichen werden soll, muss das Kriterium "nicht freigegebene Zahlungen" auf "Nein" gesetzt werden.

 Die aktiven Simulationsbelege werden systematisch berücksichtigt, die inaktiven Simulationsbuchungen niemals.

Kriterienliste

Technische Grundlagen für die Aktualisierung der Historisierungstabelle für die

Die Historisierungstabelle für die offenen Posten HISTODUD wird von den Anzeigefunktionen der Fristenliste (CONSBAH et CONSBAHF) sowie von der Ausgabe der historisierten Fristenliste BALAGEHIST verwendet.
Diese Tabelle wird immer dann aktualisiert, wenn ein offener Posten angelegt oder aktualisiert wird.

Es werden nicht alle Felder zu den offenen Posten historisiert. Beispielsweise werden die Zahlungsart, die Zahlscheinebene und die Erinnerungsdaten bei Aktualisierungen nicht historisiert.

Die wichtigsten verwendeten Felder der Tabelle HISTODUD sind:

• Ereignisdatum (DATEVT) = Buchungsdatum des Ereignisses
• Fälligkeitsdatum (DUDSTA), durch das festgelegt ist, ob ein offener Posten mit einem gebuchten Beleg oder lediglich mit einem erfassen Dokument (z. B. erfasste, aber nicht gebuchte Rechnung) verbunden ist.
• DUDSTA = 2: Der offene Posten ist mit einem gebuchten Beleg verbunden.
• DUDSTA <> 2: Der offene Posten ist mit einem nicht gebuchten Beleg verbunden. Personenkonto und Sammelkonto zum offenen Posten (BPR und SAC), welche das Personenkonto und das Sammelkonto enthalten, zu denen der offene Posten gebucht wird.
• Das Feld Abgeschlossen (FLGCLE) beschreibt den Saldo des offenen Postens und kann folgende Werte annehmen:
• FLFCLE = 1: Der offene Posten ist nicht beglichen / abgeschlossen oder nur teilweise beglichen / abgeschlossenen.
• FLFCLE = 2: Der offene Posten ist endgültig beglichen / abgeschlossen (Offen-Posten-Betrag AMTCUR = beglichener und gebuchter Betrag PAYCUR und AMTCUR <> 0; oder AMTCUR = 0 und Offen-Posten-Betrag AMTLOC = beglichener und gebuchter Betrag PAYLOC).
• FLFCLE = 3: Der historisierte offene Posten wird gelöscht.
• FLGCLE = 4: Der offene Posten ist vorübergehend beglichen / abgeschlossen (Offen-Posten-Betrag AMTCUR = zum offenen Posten PAYCUR beglichener und gebuchter Betrag + vorläufig beglichener Betrag zum offenen Posten TMPCUR).

Erläuterungen zum Ereignisdatum

A - Bei Rechnungsbuchungen entspricht das Ereignisdatum dem Buchungsdatum der Rechnung.

B - Bei vollständiger oder teilweiser Zuordnung von beglichenen offenen Posten (über Direktbelastung einer Zahlung zum offenen Posten oder über buchhalterische Zuordnung) entspricht das Ereignisdatum dem aktuellsten Buchungsdatum in der Beleggruppe zum Zeitpunkt der Zuordnung.

Beispiel:

• Zum Buchungsdatum T1 wurde eine Anzahlung geleistet,
• zum Buchungsdatum T2 wurde eine Rechnung gebucht,
• zum Buchungsdatum T3 wurde die Anzahlung berücksichtigt.

Dann werden die Belege der Gruppe zum aktuellsten Buchungsdatum DATEVT als abgeschlossen betrachtet. Dabei handelt es sich um T3.

Im Falle eines teilweise oder vollständig und endgültig abgeschlossenen offenen Postens (zu dem also eine Buchungsposition mit Zuordnungscode in Klein- oder Großbuchstaben vorhanden ist), entspricht das Ereignisdatum bei den Zuordnungen dem aktuellsten Buchungsdatum der Belege in der Zuordnungsgruppe (d. h. MTCDATMAX in GACCENTRYD).

 Die Belegung der Tabelle HISTODUD und des Ereignisdatums richten sich nach dem Zuordnungsverfahren.

Beispiel:
Eine Rechnung über 1.000 € wurde zum Datum T1 gebucht. Zu den Daten T2 und T3 erfolgte jeweils eine Zahlung:

• T2: 600 €
• T3: 400 €

Es sind zwei Fälle zu unterscheiden:

• Die Rechnung wird zunächst teilweise beglichen (600 € mit Buchungsdatum T2) und dann mit der Zahlung in Höhe von 400 € (zum Buchungsdatum T3) abgeschlossen.
• Die drei Belege werden getrennt gebucht, und die Zuordnung wird erst nachträglich mit der entsprechenden buchhalterischen Zuordnungsfunktion durchgeführt (LETTRAGE oder LETTRAUTO).

Im ersten Fall spiegelt die Historisierung den Zuordnungsverlauf wider:

• Zum Referenzdatum T1 beläuft sich die Rechnung über ihren Gesamtbetrag
• Zum Referenzdatum T2 beläuft sich die Rechnung auf 400 €
• Zum Referenzdatum T3 wird die Rechnung nicht mehr angezeigt

Im zweiten Fall werden die drei Buchhaltungsbelege manuell zugeordnet. Auch in diesem Fall ist das Ereignisdatum das aktuellste Buchungsdatum, das Ergebnis weicht jedoch von Fall 1 leicht ab:

• Zum Referenzdatum T1 beläuft sich die Rechnung über ihren Gesamtbetrag
• Zum Referenzdatum T2 beläuft sich die Rechnung über ihren Gesamtbetrag von 1.000 €, und die Zahlung von 600 € wird angezeigt
• Zum Referenzdatum T3 werden Rechnung und Zahlung nicht mehr angezeigt.

  Das Ergebnis des ersten Szenarios wird ebenfalls erzielt, wenn die Rechnung und die Zahlung in Höhe von 600 € in einem ersten Schritt zugeordnet werden. Es wird dann in einem zweiten Schritt die aus zwei Belegen bestehende Zuordnungsgruppe der Zahlung von 400 € zugeordnet. 
Voraussetzung für diese Schritte ist, dass der Benutzer mithilfe der Zerlegung der manuellen Zuordnungsschritte die Zuordnungshistorie wiederhergestellt hat.

C - Im Falle eines Sammelkontentransfers wird kein neuer Datensatz angelegt, da die vorherigen Datensätze für das Sammelkonto aktualisiert wurden und sich das Ereignisdatum nicht ändert.

D -  Bei Personenkontenzusammenführungen entspricht die Vorgehensweise der des Sammelkontentransfers: In der Tabelle HISTODUD wird kein neuer Datensatz angelegt. Es werden lediglich die vorhandenen Datensätze aktualisiert. Das Ereignisdatum bleibt unverändert.

Beschreibung des Berichts