Lagerposten gelöscht

Hallo

Bitte beim Lesen nicht lachen. Es ist kaum zu glauben, aber leider wahr.

Wir haben im Moment die Aufgabe einen Update von Navision Financials 2.0 auf NAV 5.01 durchzuführen.
Nun hat der frühere Navision-Partner des Kunden in den ersten zwei Gschäftsjahren ca. 5'000 Lagerposten gelöscht!!!!!!!!!
Gelöscht und nicht komprimiert !!!!
Wieso die gelöscht wurden, lässt sich nicht mehr feststellen.
In den Lagerausgleichsposten werden diese Lagerposten natürlich noch referenziert.
Die Lagerregulierung kann schon in der Version 2.0 nicht mehr verwendet werden.
Irgendwann erscheint die Meldung: Lagerposten xy existiert nicht.

Hat jemand Erfahrung, ob es sich überhaupt lohnt einen Gedanken an das Update zu verschwenden???
Im Moment sehe ich keine Lösung.

gruss

In den Lagerausgleichsposten werden diese Lagerposten natürlich noch referenziert.

Da die Posten unwiederbringlich weg sind, könnte man ja die Löschung der entsprechenden Lagerausgleichsposten überdenken ... theoretisch ....?

Hallo

Habe ich auch schon überlegt.
Das Problem wird vermutlich folgendes sein:
Tabelle Lagerausgleichsposten
Feld Ausgleich mit Laufnr. -> Dieser Lagerposten existiert noch
Feld Ausgleich von Laufnr. > Dieser nicht!!!

Ich befürchte, dass dieser Umstand die Berechnung des Einstandspreises auf der Artikelkarte etc. komplett verfälschen wird.
Vermutlich wird nichts anderes übrig bleiben, als das Upgrade-Toolkit laufen zu lassen und am Schluss das Ergebnis zu kontrollieren.
Leider handelt es sich hier um eine DB mit Millionen von Posten

Gruss

Hallo martinst,

ist in der 2er- DB eine Impuls- Lagerregulierung enthalten?

Gruß, Fiddi

Nein, Standard.

Wieso?

Gruss

Ich gehe mal davon aus, dass mit Lagerposten Tabelle 32 gemeint ist, die hierzulande Artikelposten heißt.

Ich befürchte, dass dieser Umstand die Berechnung des Einstandspreises auf der Artikelkarte etc. komplett verfälschen wird.
Vermutlich wird nichts anderes übrig bleiben, als das Upgrade-Toolkit laufen zu lassen und am Schluss das Ergebnis zu kontrollieren.

Die Berechnungsmethode für den Einstandspreis auf der Karte ist von Version 2 auf 3 komplett geändert worden, siehe hier.
Wenn also Posten gelöscht wurden, steht ab Version 3 keine vollständige Berechnungsbasis für den Einstandspreis zur Verfügung. So wird das neue System nie zuverlässige Werte liefern. Außerdem kracht es schon beim Upgrade, wenn Artikelposten fehlen.

Es macht absolut keinen Sinn solche verpfuschten Systeme upzugraden. Man könnte lediglich im neuen System auf die letzte oder vorletzte Inventur des Altsystems aufsetzen (wenn dort wirklich alles gezählt wurde und Bewegungen seitdem nicht gelöscht wurden), die Inventurmenge als Zugang mit dem damaligen Datum und Einstandspreis einbuchen und ab da alle Bewegungen über Artikelbuchungsblätter 1:1 einbuchen. Das sollte aber mit dem Wirtschaftsprüfer vorher abgestimmt werden.

Hallo Kowa

Ich gehe mal davon aus, dass mit Lagerposten Tabelle 32 gemeint ist, die hierzulande Artikelposten heißt.

Richtig.

Die Berechungsmethode für den Einstandspreis auf der Karte ist von Version 2 auf 3 komplett geändert worden, siehe hier.
Wenn also Posten gelöscht wurden, steht ab Version 3 keine vollständige Berechnungsbasis für den Einstandspreis zur Verfügung. So wird das neue System nie zuverlässige Werte liefern.

Genau das ist meine Befürchtung. Kann ja nie mehr stimmen.

Außerdem kracht es schon beim Upgrade, wenn Artikelposten fehlen.

Klar, deshalb auch der Gedanke, die kourrupten Lagerausgleichsposten auch zu löschen.

Es macht absolut keinen Sinn solche verpfuschten Systeme upzugraden.

Danke und Gruss

Wenn so pauschal gelöscht wurde, können die Bestände für die Artikel ohnehin nicht stimmen. Oder wurden bei den Inventuren nicht nur die Differenzen verbucht, sondern immer alles raus- und dann wieder reingebucht ?

Kowa

Kein Ahnung, wass da passiert ist.
Man ist das eine Kacke.

Gruss

Die Löschung könnte durch unvollständig deklarierte (nicht-)temporäre Recordvariablen verursacht worden sein. Aber hilft das bei der Lösung des Problems? Wohl kaum ...
Mir fällt dazu eigentlich nur noch das Thema Inventur ein - und keine alten Artikelposten übernehmen.
Ist natürlich für die Statistik ein Desaster :-/

Hallo

Die Posten wurden nicht durch TmpRec oder so gelöscht.
Die wurden bewusst gelöscht, weil anfänglich Belege falsch gebucht worden sind.
Der Entwickler (wenn man den so nennen darf) hatte dann die Idee die Posten zu löschen um das Problem zu beseitigen.
Nun 10 Jahre!!!! später stehen wir und der Kunde vor einem viel grösseren Problem.

Wir tendieren nun mittlerweile dazu, den Update zu vergessen und eine Neu-Installation zu machen.


Gruss

Die wurden bewusst gelöscht, weil anfänglich Belege falsch gebucht worden sind.

Liebe Kinder, bitte nicht nachmachen!!
Sachen gibts ...

Wir tendieren nun mittlerweile dazu, den Update zu vergessen und eine Neu-Installation zu machen.

Da wird euch wohl kaum etwas anderes übrig bleiben - viel Erfolg!

Danke für das Beileid

Existiert dann aus den Anfängen des Systems noch eine alte Sicherung bis zur dieser Löschaktion? Dann könnte man aus dieser die Artikelposten per Dataport auslesen und dann im aktuellen mit

Code:

IF Lagerposten.INSERT THEN;

die fehlenden Posten ersetzen. Das ist zwar auch nicht 100% sauber, weil sich die Betragswerte durch Regulierungen verändert haben können (unter 2.x wurde noch der ursprüngliche Posten im Wert geändert und keine neuen Posten erzeugt), aber es ist zumindest weniger katastrophal als vorher weil der Mengensaldo wieder stimmt und keine Posten mehr fehlen. Wenn das Fehlbuchungen waren, dann per Buchblatt ausbuchen. Das macht man natürlich normalerweise durch Stornierung über Belege, aber normal ist hier ja nichts mehr.

Hallo Kowa

Leider existiert aus dieser Zeit nichts mehr.
Die haben zwischenzeitlich natürlich die Backup-Software und die Medien mehrmals gewechselt.

Normal ist hier wirklich nichts!

Gruss

Wenn aus Tabelle 339 (Ausgleichsposten) nichts gelöscht wurde, dann kann man die Lager-/Artikelposten zumindest grob rekonstruieren. Dort ist die Lagerposten Lfd Nr. und die Menge (mit Vorzeichen) entnehmbar. Das könnte man als Posten mit Zugang/Abgang umsetzen und dann als Wert vorläufig den aktuellen Einstandspreis nehmen, das kann man dann später beim Feintuning noch ändern. Aber man muss davon ausgehen, dass das System so mittelfristig zum Dauerpflegefall wird, wird bis die Werte bereinigt sind. Neu aufsetzen schont die Nerven deutlich mehr.

Kowa

Welche Lösung würdest Du wählen?
Habe mit dem Kunden gesprochen und er überlegt sich nun eine Neuinstallation.
Wir werden sehen.

Gruss

Welche Lösung würdest Du wählen?
Habe mit dem Kunden gesprochen und er überlegt sich nun eine Neuinstallation.

Das wäre das sinnvollste. Nur wenn das kategorisch ausgeschlossen wird, dann kann man die Rekonstruktion versuchen (vielfach hängen auch mehrere Ausgleichsposten an einem Lagerposten, die Ausgleichsmengen müssen dann natürlich summiert werden) mit der Maßgabe, dass die Lagerwerte auch nach dem Upgrade "behandlungsbedürftig" bleiben. Wenn allerdings mehrere Lagerorte und Umlagerungen mit dabei sind, ist das Chaos kaum noch zu entwirren.

Hallo

Kunde hat sich heute zu 99% für eine Neu-Installation entschlossen.
Montag gibt er definitiv Bescheid.

Danke für alle Inputs.

Gruss Martin

Noch ein kleiner Nachtrag nur so zur Info:

Wir haben nun festgestellt, dass auch Fibuposten, MWST-Posten gelöscht worden sind.
Kein Mensch weiss, was dort noch alles gemacht worden ist.

Gruss

Wir haben nun festgestellt, dass auch Fibuposten, MWST-Posten gelöscht worden sind.
Kein Mensch weiss, was dort noch alles gemacht worden ist.

Ein weiterer Grund für einen Neuanfang, um jegliches Restrisiko auszuschließen.

ich sehe gerade den ganzen thread.

also eins muss man dem alten navisionpartner wohl zugute halten:
die Artikelposten-Komprimierung ist ein riesen X&%-haufen.

ich habe hier 30.000.000 Artikelposten.
ich habe mal aus spass die komprimierung an einem wochenende gestartet und nach einer stunde waren ca. 200 Posten komprimiert.
und die ganze zeit über konnte niemand anders buchen.#
wenn ich das also den Zeitbedarf hochrechne....lassen wirs.
und das auf einem ansonsten performanten 64-bit-system
das kanns nicht sein!
solange MS da keine akzeptable standardlösung liefert, wird es solche holzhammermethoden öfter geben.

Hallo wirtnix

Ich weiss, was Du meinst.
Ich Moment mache ich gerade ein Update von 2.6 auf 5.x
Der Kunde hat aktuell 4.5 Mio Artikelposten, x Mio Fibuposten etc. (

Laufzeit auf einem "normalen" PC -> ca. 1 Woche.

Schauen wir mal, wie lange das ganze auf einem Server dauern wird.

Gruss

die Artikelposten-Komprimierung ist ein riesen X&%-haufen.

Die Komprimierungsmöglichkeit wurde ab Version 5 ohnehin ersatzlos gestrichen. Unter einfachen Konstellationen hat die noch funktioniert, aber es gab u.a. bei Upgrades immer zusätzliche Probleme. Das pauschale Löschen von Posten ist aber unabhängig davon schon als gewaltsame Datenbankzerstörung zu werten.

Das beste ist hier nur Stammdaten zu konvertieren, und alle OP's, Salden und Artikel über Vortragsbuchblätter einzubuchen.
sonst läufst du noch jahrelang in irgendwelche unerklärlichen Probleme.