[Gelöst] Datumskomprimierung Kreditorenposten

[Anke S.]

Hallo Zusammen,

ich komme zum ersten Mal mit einer NAV Datenbank in Berührung, in der sich Einzelposten ab dem Jahr 1990 befinden. Daher für mich ein neues Thema: Datumskomprimierung umsetzen

Akut müssen wir mit den Kreditorenposten beginnen, da es bei aktuellen Belegnummern der Belegart Rechnung/Gutschrift zu Dubletten kommt (Belegnummer bereits im Jahr 1998 gebucht).
Die Option, eine andere Belegnummer zu verwenden entfällt. Daher wollen wir zeitnah eine Datumskomprimierung der alten Kreditorenposten durchführen, außer die Posten der letzten 10 Wirtschaftsjahre.
Und dadurch wäre das Dubletten-Problem dann gelöst.

Mir ist bewusst, dass man eine Datumskomprimierung nicht rückgängig machen kann. Zudem sollten auch währenddessen die Kreditorenposten nicht aktiv in Nutzung sein (inkl. der detaillierte Posten).

Kennt Ihr einen Grund / besteht ein anderes Risiko bei der Datumskomprimierung, außer dass man sie nicht rückgängig machen kann ?

Freue mich über euer Feedback!
VG
Anke

Zuletzt geändert von Anke S. am 19. Oktober 2021 14:44, insgesamt 1-mal geändert.

Spontan fällt mir folgendes ein:

Ich würde das erstmal in einer Testdatenbank machen. Eine Sicherung der DB bzw. des Mandanten vor Komprimierung würde ich ohnehin aufbewahren.

Nach der Komprimierung wird Navigate auf Altposten natürlich nicht mehr alles sinnvoll zusammenfinden, Transaktion stornieren könnte Probleme machen, Ausgleiche ändern geht nicht mehr (inkl. automatischer Buchungen wie Skonto). Aber das ist alles ja nicht relevant in über 10 Jahre alten Posten.

Gemacht habe ich sowas aber tatsächlich noch nie.

Hallo,

ich weiß nicht wie gut die Komprimierungsroutinen bei den Kreditorenposten sind.
Ich habe vor einiger Zeit einen Heiden Spaß mit eine NAV5- Artikelpostenkomprimierung gehabt. Das hat uns mehrere Tage Arbeit gekostet,um das zumindest einigermaßen wieder in Ordnung zu bringen.

Ich persönlich halte nichts von den Komprmierungsroutinen.

Ich würde eher die Methode Löschen bevorzugen (ist allerdings auch nicht ohne, und macht keine Nummernbereiche frei)
Dazu würde ich mir Kreditoren suchen, die seit mindestens 10 Jahren nicht mehr bebucht wurden Danach würde ich mir alle referenzierenden Daten suchen und diese löschen (das können auch Artikel sein, die seit 10 Jahren keinen Bestand mehr haben bzw. bewegt wurden).

Gruß Fiddi

Das mit den Belegnummer kann ich schon nachvollziehen. Wenn man ursprünglich zu wenig Stellen vorgesehen hatte dann ist das schon doof. Meine Kunden mit solchen Themen haben aber rechtzeitig Fusionen und ähnliches vorgenommen so dass sich das Thema dadurch erledigt hatte.

Ich habe vor einiger Zeit einen Heiden Spaß mit eine NAV5- Artikelpostenkomprimierung gehabt.

In NAV 5 wurde die Artikelpostenkomprimierung aus dem Standard entfernt, aus gutem Grund. Von der sollte man grundsätzlich die Finger lassen.

Bei Kreditoren- und Debitorenposten sehe ich aber keine Probleme bei uralten Schätzchen, die jenseits der gesetzlichen Aufbewahrungsfristen liegen. Im Vergleich zu der Komplexität der Lagerbewertung sind diese ja eher simpel gestrickt.

Testen sollte man das natürlich sowieso, aber vor der Komprimierung im Echtsystem auch noch mal eine separate Datensicherung erstellen und diese auf einer externe Festplatte in den Firmensafe legen, damit man darauf zurückgreifen kann, falls sich doch noch mal jemand für Posten aus der Ära Kohl oder Schröder interessiert. Die Wahrscheinlichkeit würde ich als sehr gering einstufen, aber vielleicht kommt ja irgendwann ein Archäologe vorbei .

Hallo,

ich hab mir jetzt die Kreditorenpostenkomprimierung nicht ganz genau angesehen, aber ich befürchte das die durch die Komprimierung gelöschten Belegnummern nicht aus den anderen Postentabellen (Sach-.Wert-, Artikelposten) entfernt werden.
Ein Navigate in den Postentabellen könnte dann recht unübersichtlich werden, wenn die Belegnummern wieder benutzt werden (es werden alte Sach-,Wert- und Artikelposten gefunden, die nichts mit dem aktuellen Beleg zu tun haben)

Gruß Fiddi

Hallo Zusammen,

DANKE für die vielen tollen Antworten und Hinweise ! Vielen Dank explizit an Kowa für den Tipp mit dem Archäologen - ich geb es intern gerne zu Bedenken

NAV wird bei uns nur in der Buchhaltung genutzt, daher gibt es keine Auswirkungen auf Artikel/Lager/Bewertung etc. NAVIGATE wird vom Anwender eher immer nur vom Posten heraus aufgerufen, dabei zieht sich die Funktion auch immer das Buchungsdatum des Posten gleich mit. Der Sachposten findet dann seinen Kreditorenposten nicht mehr,das ist uns bewusst.
Und Transaktionen stornieren dürften wir sowieso nicht machen, das geht ja nur zum Ursprungsbuchungsdatum.

Getestet habe ich die Komprimierung auch schon mit 1 Kreditoren in unserer Test-DB: ca. 1.800 Posten komprimieren hat nur 4 min gebraucht
(das liegt aber an der Test-Umgebung, in der LIVE-DB sollte das schneller laufen). Ich sollte vielleicht aber noch nachsehen, was mit den detaillierten Kreditorenposten bei der Datumskomprimierung geschehen ist.

Noch eine kurze Frage an Euch, da ich ja keine Entwicklerin bin: Könnte eventuell irgendein Flowfield / ein Standardbericht ein Problem mit den fehlenden laufenden Nummern in der Kreditorenpostentabelle bei der Berechnung von Werten bekommen? Oder schauen die normalerweise "dumm" Richtung "Buchungsdatum"?

LG
Anke

Mir ist keine Stelle bekannt wo was mit der Lfd. Nr. der Kreditorenposten gemacht wird. Die wird ja nicht fortlaufend vergeben sondern korrespondierend mit der Lfd. Nr. des zugehörigen Sachpostens.

FlowFields sind sicher kein Problem da diese nur das Feld Betrag oder Betrag (MW) summieren und dabei Datumsfilter usw. berücksichtigen. Einen Saldo zum Stichtag kann man nach Komprimierung natürlich nicht mehr ermitteln, aber das ist 10 Jahre in der Vergangenheit dann auch nicht mehr nötig. Dafür würde ich mir ja den Mandant mal sichern und beiseite legen. Standard-Reports machen auch sicher keine Probleme.

Ich gehe mal davon aus dass nicht nur die Kreditorenposten sondern auch die Detaillierten Kreditorenposten komprimiert werden, würde sonst wenig Sinn machen.

Vielen Dank an Alle - ich stelle das Thema mal auf [Gelöst] Sollte es zu unerwarteten Problemen bei der Umsetzung kommen, hört ihr sowieso wieder von mir

Sollte es zu unerwarteten Problemen bei der Umsetzung kommen, hört ihr sowieso wieder von mir

Dann bitte auch MS hier davon hören lassen : Manage Storage by Deleting Documents or Compressing Data

Kleines Update - keine Probleme, aber bei dem ersten Kreditor lief die Komprimierung in der LIVE -Datenbank ausgeführt über den Windows-Client rund 10 Stunden -

Daher haben wir an dem Wochenende nur bei drei Kreditoren die Datumskomprimierung erledigt, die Restlichen folgen nur bei Bedarf.
VG
Anke