Historisierung Offene Posten
Mit diesem Werkzeug kann die Historisierungstabelle der offenen Posten (HISTODUD) resynchronisiert werden. Diese wird aktualisiert, wenn der Aktivitätscode HDU aktiv ist und ein offener Posten geändert wird.
Die Resynchronisierung ist auf zwei Arten möglich:
- 1/ Ermittlung der Fehler zu vorhandenen Datensätzen und Korrektur derselben, jedoch keine Anlage von neuen Datensätzen. In diesem Fall werden bei der Resynchronisierung / Korrektur zwei Arten von Prüfungen durchgeführt:
- Suche nach Inkohärenzen zwischen den Daten in der Referenztabelle (GACCDUDATE) und den Daten in der Historisierungstabelle der offenen Posten (HISTODUD).
Werden Inkohärenzen gefunden, wird die Tabelle HITODUD auf Basis des Inhalts der Tabelle GACCDUDATE resynchronisiert. - Der Kohärenzprüfung der Daten in HISTODUD stützt sich auf bestimmte Regeln.
- 2/ Löschen der vorhandenen Datensätze (sofern vorhanden) und Anlage von neuen Historiendatensätzen:
- Die Zusammenstellung von Historiendatensätzen verfolgt das Ziel, die bereits vorhandenen Datensätze zu löschen und neue Datensätze anzulegen, auch wenn der Aktivitätscode HDU im Betrieb aktiviert sein sollte.
Diese Rekonstruktion der Historie stützt sich nicht auf die der Buchhaltung vorgelagerten Datenströme, sondern auf die Zuordnung(mehr darüber...).
Vorbedingungen
Siehe Dokumentation Umsetzung
Maskenverwaltung
Mit den beiden Checkboxen Resynchronisierung und Löschen kann einer dieser beiden Aktualisierungsmodi für die Tabelle HISTODUD festgelegt werden.
Über die Checkbox Erweiterte Protokolldatei steht eine Liste der von der Resynchronisierung betroffenen oder angelegten Datensätze zur Verfügung.
Mögliche Kombinationen und Auswirkungen
Resynchronisierung | Löschen | Erweiterte Protokolldatei | Auswirkungen | Beispiel für Protokolldateidaten | |
Nein | Nein | Nein | Liste von Fehlern in den vorhandenen Datensätzen. Weder Korrektur noch Anlage. | Beleg FAC FCRHDU10102VEN00001 Position 1 Offener Posten 1 (151016) | Plus Angabe der historisierten Offen-Posten-Nummer ([F:HDU]NUMHDU) sowie der Fehlerart (wie ein nicht korrektes DATEVT). |
Ja | Nein | Nein | Korrektur der in den vorhandenen Datensätzen gefundenen Fehler. Die Protokolldatei umfasst die Liste der korrigierten Fehler. | Beleg FAC FCRHDU10102VEN00001 Position 1 Offener Posten 1 (151020) |
|
Nein | Ja | Nein | Die Protokolldatei umfasst die Datensätze, die vom Werkzeug möglicherweise angelegt werden, falls der Aufruf im Produktionsmouds erfolgte (ohne Berücksichtigung der bereits vorhandenen Datensätze). | Beleg FAC FCRHDU10102VEN00001 Position 1 Offener Posten 1 | Zuletzt wird das angewandte DATEVT angegeben, sofern das Werkzeug im Produktionsmodus aufgerufen wurde. |
Nein | Ja | Ja | Die Protokolldatei umfasst die vorhandenen Datensätze, die gelöscht werden, sofern das Werkzeug im Produktionsmodus aufgerufen wurde. Die Protokolldatei umfasst die Datensätze, die vom Werkzeug möglicherweise angelegt werden, falls der Aufruf im Produktionsmouds erfolgte (ohne Berücksichtigung der bereits vorhandenen Datensätze). | *** 150983 10/02/11 Beleg FAC FCRHDU10102VEN00001 Position 1 Offener Posten 1 | Der zu löschende Datensatz ist durch seine [F:HDU]NUMHDU und DATEVT bestimmt. Zuletzt wird das angewandte DATEVT angegeben, sofern das Werkzeug im Produktionsmodus aufgerufen wurde. |
Ja | Ja | Nein | Löschen der vorhandenen Datensätze und Anlage von neuen Historiendatensätzen zu den offenen Posten. | Beleg FAC FCRHDU10102VEN00001 Position 1 Offener Posten 1 |
|
Ja | Ja | Ja | Die Protokolldatei umfasst die Liste der gelöschten Datensätze sowie der neuen, vom Werkzeug angelegten Datensätze. | Beleg FAC FCRHDU10102VEN00001 Position 1 Offener Posten 1 |
|
Erfassungsmaske
Felder
In diesem Register befinden sich die folgenden Felder :
Kopf
| Keine Feldhilfe vorhanden. |
Kriterien
| Keine Feldhilfe vorhanden. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Blocknummer 3
| Die Neusynchronisierung wird lediglich für Datensätze durchgeführt, deren Status DUDSTA den Wert 'zwei' aufweist, was einem mit einem gebuchten Dokument verbundenen Offenen Posten entspricht (im Gegensatz zu denjenigen Offenen Posten, die mit nicht gebuchten Rechnungen verbunden sind). Einige Spalten der Tabelle HISTODUD werden nicht aktualisiert:
Einige Spalten werden unter Anwendung einer Regel resynchronisiert:
|
| Die Option 'Löschen' erstellt neue Verlaufsdatensätze. Die Daten der Datei der Offenen Posten stellen den Abfahrtspunkt dieser Erstellung dar.
GRENZE Nr.1Die Neusynchronisierung mit Löschen bezieht sich nicht auf die Flüsse in den der Buchhaltung vorgelagerten Modulen, sondern auf das Buchungsereignis Zuordnung. Beispiel: GRENZE Nr.2Die Neusynchronisierung mit Löschen ermöglicht nicht die Verwaltung einer Zahlungsstornierung, die nach dieser Neusynchronisierung erfolgt. Beispiel: Durch den Neustart einer Neusynchronisierung mit Löschen für das betroffene Personenkonto werden die neuen Verlaufsdaten ohne diese Grenze wiederhergestellt. |
| Wird die detaillierte Logdatei angefragt, wird die Logdatei um die Liste der Datensätze HISTODUD ergänzt, die während des Löschvorgangs gelöscht worden sein könnten (mit oder ohne Neusynchronisierung). |
Schließen
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.
Batchaufgabe
Diese Funktion kann im Batch gestartet werden,. Zu diesem Zweck ACCRECHDU ist die Standardaufgabe vorgesehen.
Fehlermeldungen
Während der Erfassung können außer den generischen Meldungen folgende Fehlermeldungen auftreten: :
Einige Spalten, die in direkter Beziehung zur Referenztabelle GACCDUDATE stehen, werden aktualisiert. Die Fehlermeldungen entsprechen dabei denen der Offen-Posten-Resynchronisierung, d. h.:
- ACCNUM: interne Nummer nicht korrekt
- CPY: Unternehmen nicht korrekt
- FCY: Standort nicht korrekt
- CUR: Währung nicht korrekt
- SNS: Vorzeichen nicht korrekt
- SAC: Sammelkonto nicht korrekt
- BPR / BPRTYP / BPRPAY: Personenkonto nicht korrekt