Daten Übernahme aus NAV2009

Hi,

endlich wurde beschlossen dass wir Updaten von 2009 CC auf 2018
... allerdings auch dass ich den meisten Teil davon machen soll.... das wird noch ein lernreiches und arbeitsintensives Jahr ...

Wir wollen eine Saubere Nav2018 DB Branchenlösung aufsetzen.
Debitorenposten, Artikelposten... und anderes Gerümpel sowie unsere Eigenprogrammierungen soll nicht übernommen werden.
Lediglich die Stammdaten sollen rüber.

Nun Frage ich mich wie ich am besten die Datenübernahme der Stammdaten anstelle.

Überlegt habe ich mir:
- Excel Export aus 2009 und in 2018 import über rapid startservices
oder
- T-SQL direkt aus der einen DB in die neue.

Vor/Nachteile? Was würdet Ihr machen?

Danke

Bevor du mit der technischen Seite beginnst, solltest du dir inhaltliche Gedanken machen.
Also, wie sehen deine Stammdaten aus? Welche Attribute kamen im alten System hinzu, die nicht zum Standard gehören.
Hat NAV diese Felder mittlerweile im Standard usw.

Technisch bietet sich tatsächlich RapidStart an.
Oder XmlPorts, falls du mehr Logik brauchst.

T-SQL würde ich von abraten, da du hier genau wissen musst, was du tust.
Du hast hier auch keine Möglichkeit, deine Werte vernünftig zu validieren.

Der Validate-Trigger wird bei Rapidstart auch nicht ausgeführt, oder irre ich mich da?

Hallo,

Wir wollen eine Saubere Nav2018 DB Branchenlösung aufsetzen.
Debitorenposten, Artikelposten... und anderes Gerümpel sowie unsere Eigenprogrammierungen soll nicht übernommen werden.
Lediglich die Stammdaten sollen rüber.

Das hört sich nach einer typischen Kundenumstellung an.

Kunde beim Gespräch zum Update:"Wir wollen nur den Standard, keine Änderungen".

Kunde während des Projekts: "Also wie das hier gelöst ist, damit können wir nicht leben, das müssen wir ändern." (und das schon bei Kleinigkeiten).

Wenn ihr eure Software nicht komplett auf links dreht, d.h. alles neu macht inklusive einer oder mehrerer neuer Branchenlösungen, würde ich mir die Arbeit mit dem Update machen.
Du hast später weniger Probleme, wenn z.B. das Finanzamt zu Prüfung kommt.

Und ohne zumindest eines Teils der Posten wirst du bei der Umstellung nicht auskommen, da du ja sicherlich offene Posten hast, die mal irgendwann bezahlt werden, wie willst du das in der Fibu machen, wie willst du mahnen,....

Aber ob und wie das sinnvoll ist, muss man sich individuell anschauen, das hängt auch ein wenig von der Größe der Datenbank ab, und seit wann die Lösung im Einsatz ist.

Allerdings solltest du bei einer größeren Datenbank und einem Update von 2009 auf 2018 keine Angst vor T-SQL haben. Das schafft dir einen so erheblichen Zeitgewinn, den du mit keiner C/AL- Programmierung aufholen kannst.

Gruß Fiddi

Hi,

ja, ich bin dabei mir Gedanken zu machen, und Ideen am Sammeln, um das ganze in ein geordneten Ablauf zu bekommen.

Klar, die Anfangszahlen/Salden müssen rüber. Habe so verstanden dass es unser Partner macht, und ich nur die Stammdaten. Sollte aber noch geklärt werden.
Ich soll mir jetzt grob Gedanken machen wie ich mir den Ablauf vorstelle. Dann ist ein Gespräch mit dem Partner geplant wegen der Vorgehensweise und Abstimmung mit der Entwicklungsabteilung des Partner.

Beim letzten mal lief es so, wir bekamen die Branchen DB, ich implementierte unsere Änderungen, Reports Anpassung, usw.. und das ganze wurde dann mit dem Partner abgeglichen.
Wie das jetzt in NAV18 laufen wird weiß ich noch nicht, aber man will mir noch zeigen wie ich bei der Entwicklung vorgehen soll damit diese nach Updates möglichst einfach übernommen werden kann.

Daten schleppen wir jetzt seit NAV 2.60 mit,dann kam 3.70, dann NAV2009 CC, mit Branchenlösung immer, da sind einige altlasten in der DB vorhanden, Daten als auch Programmierung.
Von 2009 auf 2018 geht ja auch nicht ohne Zwischenschritt über eine andere NAV Version. Die Empfehlung kam auch vom Partner. Das ganze Update würde zu Aufwendig sonst.

Kunde während des Projekts: "Also wie das hier gelöst ist, damit können wir nicht leben, das müssen wir ändern." (und das schon bei Kleinigkeiten).

Dafür bin ich ja hier Und will Nav2018 nutzen um mal einige Sachen auszumisten, und wollen auch nicht alle Individuelle Sachen übernommen,
erstmal schauen ob es Lösungen mit neuen Bordmittel gibt, und ob man hier oder da die User auf einen anderen Ablauf/Prozess "umerziehen" kann.
Und alles was vermisst wird oder gebraucht wird, wird nach und nach neu hinzuprogrammiert.

Unsere Datenbank ist 120 GB. Die fehlende Validierung über T-SQL fehlt natürlich, aber Frage wäre auch was muss bei Stammdaten eigentlich validiert werden?

Hallo,

der Zwischenschritt besteht bei einer angepassten Konvertierung eigentlich nur aus einer Konvertierung der Datenbank mit dem Client, es werden keine Updates durchgeführt, außer in 2009 CC und in 2018.

Wenn ich so ein Update mache, fange ich immer erst bei den Feldern an. Ich schaue mir an, welche von den nicht Standardfeldern ich noch benötige. Dazu exportiere ich mir die Tabelle Field aus meiner Kundenlösung und vergleiche Sie mit einer Standard- NAV-DB oder meiner Branche, ggf. auch der neuen Lösung wenn die 2018- Branchenlösung weiter entwickelt wurde. Bei unterschieden muss ich überlegen, was ich damit anfange:
1. Das Feld ist überflüssig, dann kommt es in ein T-SQL- Script, das dieses Feld in der Tabelle in allen Mandanten löscht.
2. Das Feld gibt es noch, dann bleibt es so wie es ist.
3. Das Feld wurde in der Tabelle verschoben, dann kommt in die alte Version schon das neue Feld, und die Daten werden per T-SQL verschoben.
4. Das Feld gibt es noch, aber woanders, dann wird es in eine neue Updatetabelle verschoben, mit Schlüsseln natürlich
5. die Ganze Tabelle gibt es nicht mehr, wohl aber die Daten, dann lässt man die Tabelle halt stehen, und konvertiert die Daten in 2018 in die neue Struktur.

Ob ein Feld übrflüssig ist, merkt man auch daran, ob es in der jeweiligen Tabelle leer ist.

Was du bei dieser Analyse sehr genau erfährst, ist welche zusätzliche Daten seit Jahren in deiner DB rum schwirren, an die du schon gar nicht mehr gedacht hast. Was bei der Gelegenheit gleich mit entsteht, sind Upgrade- Skripte und Programme.

Wenn du jetzt die überflüssigen Felder aus deinen Tabellen in der Testdatenbank raus geworfen hast, kannst du mal einen CompileAll machen, der wird dir dann auch den Code bereinigen, und damit den Merge einfacher machen.

Einige Dinge solltest du auch überlegen:
1. Wenn du deinen Anwendern sagen kannst, das was du benutzt funktioniert noch genauso wie vorher, nur die Tasten sind andere und die Funktionen sind jetzt nur an anderer Stelle, dann kannst du damit deinen Anwendern schon mal die Angst vor der neuen Oberfläche nehmen. => Einfach an das neue Programm ran setzten, und tun, das hilft.
2. Daten die du einmal gelöscht hast, bekommst du nur schwer wieder.
3. Die Anwender wollen bestimmt nicht ohne Historie leben, und die Arbeit mit zwei Clients ist mühsam und Auswertungen über Datenbankgrenzen nur schwer möglich.
4. Du hast Aufbewahrungspflichten, im Zweifel 10 Jahre, die du so das alte System noch am Laufen halten müsstest. Kein Mensch kann dir garantieren, das es dann noch irgendetwas gibt mit dem man auf das alte System zugreifen kann, wenn du die Daten nicht übernimmst.

Und 120 GB auf einem halbwegs aktuellen Server sind sicherlich an einem Wochenende zu aktualisieren.

Solltet ihr ausgiebig mit Dimensionen gearbeitet haben, solltet ihr euch vorher noch mal die entsprechenden Update- Routinen zu Gemüte führen, die sind im Standard u.U. etwas langsam. Aber gerade dann werdet ihr auf die historischen Daten nicht verzichten wollen.

Gruß Fiddi

...Die fehlende Validierung über T-SQL fehlt natürlich, aber Frage wäre auch was muss bei Stammdaten eigentlich validiert werden?

Das ist nicht schlimm. Wenn die Daten heute bereits in NAV vorliegen, passen auch die Formate (Text usw.).
Die größte Schwierigkeit für mich war tatsächlich der Abgleich der Tabellen. Im neuen gibt es andere (weniger/mehr) Felder als im alten. Und da NAV auf SQL Ebene jedes Feld mit "Not NULL" markiert, muss auch jedes Feld angegeben werden.

Guten Morgen,

danke fiddi für die ausführliche Beschreibung.
Dann sollte ich wegen der Datenübernahme der Posten nochmal Gespräch suchen beim Partner.
Klar wäre schöner wenn alle Daten in einer Quelle verfügbar wären.
Ansonsten wäre meine Idee gewesen den NAV2009 laufen lassen, einige WebServices Veröffentlichen um an die Daten zu kommen, und dann mittels Addin In / Plugin oder sonstwie in NAV 18 die Daten zur Verfügung stellen.
Da besteht schon noch Gesprächsbedarf bevor irgendwas gemacht wird.

Die größte Schwierigkeit für mich war tatsächlich der Abgleich der Tabellen. Im neuen gibt es andere (weniger/mehr) Felder als im alten. Und da NAV auf SQL Ebene jedes Feld mit "Not NULL" markiert, muss auch jedes Feld angegeben werden.

Ja. das war auch mein erster Stolperstein, wollte mal eine Übernahme testen, DebitorNr, und DebitorName... und die darf nicht NULL sein hörte gar nicht auf

Erinnere mich immer gerne wieder an letztes Jahr, als hier O365 ausgerollt wurde, inkl. neuen Windows Client, sagte ein Mitarbeiter "Ich kann damit nicht arbeiten, das Blau ist mir zu Blau" (Solang es nur das Blau ist ... )
Angst vor der neuen Oberfläche ist die größte Sorge der Anwender... Aber irgendwann muss ja mal was neues her. Und ich denke wenn Nav2018 erstmal im Einsatz ist, gibt es viel mehr Möglichkeiten auf User Wünsche einzugehen als wie es mit 2009 CC war/ist.

Ansonsten wäre meine Idee gewesen den NAV2009 laufen lassen, einige WebServices Veröffentlichen um an die Daten zu kommen

Wie groß ist der (Kosten-) Aufwand dafür das zu programmieren, damit die Standardberichte wieder laufen?

Und ich denke wenn Nav2018 erstmal im Einsatz ist, gibt es viel mehr Möglichkeiten auf User Wünsche einzugehen als wie es mit 2009 CC war/ist.

wie kommst du darauf?

Gruß Fiddi

Ansonsten wäre meine Idee gewesen den NAV2009 laufen lassen, einige WebServices Veröffentlichen um an die Daten zu kommen

Wie groß ist der (Kosten-) Aufwand dafür das zu programmieren, damit die Standardberichte wieder laufen?

Und ich denke wenn Nav2018 erstmal im Einsatz ist, gibt es viel mehr Möglichkeiten auf User Wünsche einzugehen als wie es mit 2009 CC war/ist.

wie kommst du darauf?
Gruß Fiddi

Auswertung über Reports/Berichte benutzen wir sehr selten bis gar nicht.
An Historie interessiert die User eher so Sachen wie Einkauf Historie, wann hat ein Kunde zuletzt Artikel XYZ gekauft,.... so Sachen sind bei uns entweder eine Tabellenansicht, oder eine Form welche irgendwelche Daten zusammenfasst bzw. rechnet.

Weiß nicht wie ich darauf komme, Wunschdenken? Hängt natürlich auch von der Akzeptanz der User ab.
Ich erhoffe mir halt etwas mehr Flexibilität beim Umsetzen von Anforderungen als wie wir es in NAV 2009 CC haben.
Da sind so einige Sachen wo ich denke dass wir das in NAV2018 besser gelöst bekommen als wie es momentan der Fall ist. Deswegen vielleicht.

Ich stehe vor der gleichen Thematik. Allerdings habe ich vor, die Gelegenheit konsequent zu nutzen.
-Indi-Felder in Standard-Feldern unterbringen
- Branchenlösung statt "Mit der Hand am Arm".
Flexibilität meint nach meiner bisherigen Erfahrung eher Disziplin- und Planlosigkeit. Ist so ähnlich wie agile Projektmethoden.
Also: Indi-Felder und Indi-Programmierung auf den Prozess hin betrachten. Hinterfragen JEDEN speziellen Prozesses (geschäftlicher Nutzen oder "weil schon immer so").
Daten im Altsystem bereinigen auf das gesetzlich zu Bewahrende und sinnvolle Statistiken. die Verkaüfe von vor 3 Jahren interessieren NIEMANDEN ernsthaft. Falls doch: Firma wechseln.

die Verkaüfe von vor 3 Jahren interessieren NIEMANDEN ernsthaft. Falls doch: Firma wechseln.

Doch, das Finanzamt, und die können ernsthaft böse werden, wenn die anfangen zu schätzen.

Flexibilität meint nach meiner bisherigen Erfahrung eher Disziplin- und Planlosigkeit. Ist so ähnlich wie agile Projektmethoden.
Also: Indi-Felder und Indi-Programmierung auf den Prozess hin betrachten. Hinterfragen JEDEN speziellen Prozesses (geschäftlicher Nutzen oder "weil schon immer so").

Ja und Nein.
Generell gebe ich dir recht, aufräumen ist immer gut. Denn was nicht da ist, kann auch keine Fehler verursachen
Aber es gibt manchmal oft nur kleine Anpassungen die passen eben nur für die Abläufe in dem Unternehmen, und mit dessen Strukturen, sparen dort aber immens Zeit und Ressourcen.
Die sollte man dann schon behalten. Und gut strukturiert eingebaut machen die auch bei einem Update, selbst mit Textmerge keine Probleme.

Gruß Fiddi