Rapid Start Konfigurationsvorschlag

Hallo beisammen,

wir sind im Moment dabei unser NAV auf 2013 upzugraden.

Was unser riesen Problem ist, ist die Datenübernahme die wir über RapidStart und Excel - Dateien machen.
Eine Excel Datei über einen Konfigurationsvorschlag von ca. 30000 Zeilen, dauert ca. eine halbe Stunde und dann nochmals fast so lange bis
die Daten vom Datenpaket übernommen sind.

Hat mir jemand einen Tip wie man die Perfomance noch steigern könnte?

Folgendes wurde schon gemacht:
- Virtueller Server
- StandAlone Server
- neue Instanz auf einem anderen Server installiert
- Speicher und CPU Erweiterung (schon bis 12 CPU´s und 32 GB Ram probiert)

leider bringt nichts eine wirkliche Veränderung an der Schnelligkeit.

Bei unseren Stammdaten ist dies ja noch in Ordnung, aber wir sollten dann innerhalb von einem Tag auch alle andern Bewegungsdaten ebenfalls importieren, das sind z.B. 1 Mio Zeilen.

Kann man evtl. an der Instanz noch was drehen??

Bin für jeden Tip dankbar!

Viele Grüße

Bernd

Hallo Bernd,
ich verstehs grad nicht:
Du schreibts von Upgrade, warum benutzt ihr dann nicht den vorgeschrieben Migrationspfad und die hier für vom Hersteller ausgelieferten Migrationstools??
MFG Micha

Hallo Micha,

wir haben leider noch die Version 3.7 und möchten von dieser auf die 2013 Umsteigen.
Zu uns hat es geheißen dass wir keine andere Möglichkeit haben als über den RapidStart upgraden.

Bin natürlich für jede Hilfe dankbar.

VIele Grüße
Bernd

Hallo Bernd,
ich weiß ja nicht, vom wem du diese Aussage hast, aber die ist falsch.
Es gibt keine direkte Migration von 3.70 auf 2013, das ist klar. Aber:

Der Migrationspfad ist: 3.70 => 2009 und von 2009 nach 2013.

Ich würde euch dringends, also mit Nachdruckempfehlen, diesen Weg zu beschreiten. Nur so ist sichergestellt, dass die Daten, insbsondere die Bewegungsdaten, dem neuen Datenmodell angepasst werden. (Grundsätze der ordnungsgemäßen Speicherbuchführung).

Nach dem Du hier als Endanwender gelistet bist, kann ich dir nur den Rat geben, dich an einen Partner deines Vertrauens zu wenden.

Beste Grüße und viel Erfolg dabei

Micha

Hallo Micha,

Herzlichen Dank für die Info.
Wir hatten das auch in MSDN so gelesen, also erst 2009 und dann auf 2013.

Ich werde das Thema gleich nochmals nächste Woche ansprechen.
Zudem wir sowieso bis 1.8. live gehen müssen.

Viele Grüsse und nochmals danke!
Bernd

Zudem wir sowieso bis 1.8. live gehen müssen.

D.h. ihr fahrt momentan auf der Autobahn mit 200 km/h, ausgefallener Servolenkung sowie defekten Bremsbelägen und müßt bald die nächste 90° Kurve nehmen, komme was wolle?

Kann man den 01.08. nicht verschieben, da ihr scheinbar falsch beraten wurdet?

Hallo,

ich muss meinen Vorrednern im Normalfall Recht geben, der normale Übergang von einer NAV Version zur nächsten ist der Einsatz eines oder mehrerer Durchläufe von NAV- Upgrade- Toolkits bis man die aktuelle Version erreicht hat.

Es könnte aber auch Gründe geben, warum man das gerade nicht macht.

Z.B. NAV wurde bisher als bessere Schreibmaschine benutzt, d.h. die Fibu war nicht im Einsatz, und die Bewegungsdaten in der Warenwirtschaft haben auch nicht wirklich interessiert (negative Bestände,es wurde ein Artikel eingekauft und unter einer anderen Nummer verkauft,...).
Wenn man jetzt NAV korrekt einsetzen möchte gibt es kaum eine andere Möglichkeit, als die Stammdaten und die Bewegungsdaten mit einem Stichtagswert zu übernehmen und den Rest vernünftig einzurichten.

Gerade in so einem Fall ist es allerdings sehr sportlich schon zum 1.8. Online gehen zu wollen, zumal auch noch die Reports für die Belege neu angepasst werden müssen.

Gruß, Fiddi

Hallo beisammen,

ja, wir wissen leider auch dass der 1.8. recht sportlich klingt, aber verschoben wird leider erst wenn an der 90° Kurve nicht mehr gebremst werden kann,
auch wenn jetzt die Wochenenden dafür draufgehen .

Unser NAV wird voll genützt, auch FIBU etc..., auch wurden sämtliche Features noch dazuprogrammiert z.B. für Aussendienst-Techniker im Service. Da hängt einfach alles dran.
Dann kommt noch hinschwerend dazu dass nicht alles 1:1 übernommen werden kann und die Datenstruktur z.Teil noch beim Export gemappt wurde.
Nun, alles in allem soll wohl die Standard-Migration so nicht funktionieren und sollen alles über die Konfig-Pakete importieren.
Da ich leider erst seit 1.1. diesen Jahres mit NAV überhaupt zu tun habe tu ich mir schwer die SItuation selbst einzuschätzen und befasse mich deshalb mit den Imports ins NAV2013.

Wenn die Kiste läuft dann fällt mir mal ein rießen Stein vom Herzen, aber es ist noch ein steiniger Weg und bin daher für jeden Tip dankbar der den Import beschleunigen könnte.

Vielen Dank EUch mal.

Bernd

Hallo,

ich kann nur davor warnen nicht jetzt zu bremsen... wie weit ist denn die neue Applikation? Wurde sie bereits getestet oder sind kritische Features noch in der Entwicklung? 1 Monat (in der Urlaubszeit) ist praktisch nix... reicht gerade dazu, die Migration auf die Beine zu stellen (egal wie, Upgrade Toolkit als Basis ist aber der meist beste Weg), wenn die Anwendung selbst schon steht. Wahrscheinlich ist das auch noch ein "big bang" Livegang, oder?
Ich war schon in solchen Situationen. Bremsen, reinen Wein einschenken, und nicht Live gehen ohne Rückfalloption. Und sich im Zweifelsfall schlicht weigern. Musste ich auch schon, hat mir und der Firma nicht geschadet.

LG Jens

Dann kommt noch hinschwerend dazu dass nicht alles 1:1 übernommen werden kann und die Datenstruktur z.Teil noch beim Export gemappt wurde.

Das Mapping kann aber auch mit dem Upgrade- Toolkit gemacht werden, oder schneller mit einer SQL-Server- Abfrage zur richtigen Zeit.

So eine Aktion macht man aber nur wenn man bei der Gelegenheit die Organisation ändern möchte (neuer FIBU- Kontenrahmen, neue Lagerorte, Nummernbereiche für Debitor, Artikel, Kreditor ändern), die einen erheblichen Einfluss auf die Postenstruktur hätte.

Oder steckt dahinter das Thema Dimensionen, von dehnen Ihr ein paar mehr habt, und ihr nicht wisst, wie ihr die Millionen von Dimensionsposten an einem Wochenende umstellen sollt?

Gruß, Fiddi

Hi Jens und Fiddi,

vielen Dank für Eure Tipps, aber wir müssen alles mögliche in die Wege leiten und am 1.8. "live" zu gehen. An diesem Termin hängen noch Folgeprojekte die auf NAV2013 aufsetzen und uns ansonsten Konfentionalstrafe bedeutet.
Die Programmierung der Objecte ist zu 95% fertig, Reports der Belege sind auch fast soweit. Eigentlich geht es dann 3 Wochen lang bis zum 1. 8. nur noch ums Datenschaufeln.
Aber wenn die paar Einträge der Kontakte (ca. 30000) schon 2 Stunden dauert, wie lange brauchen wir dann für den Rest?? --> klar, Stammdaten werden vorab schon gemacht, aber rein die Bewegungsdaten ist ja schon ne Menge.

Naja, hilft nix, ich brauche einfach Tips wie man die Konfig-Vorschläge noch beschleunigen könnte, oder eine alternative, außer migration über 2009.

Viele Grüße

Bernd

Hallo Bernd,

eine Migration NAV -> NAV mit kompletten Bewegungsdaten habe ich bisher eigentlich nur so gemacht:

1. Objektsatz für ein Konvertierungstool einspielen, laufen lassen

Der Objektsatz dient dazu unnötige Schlüssel abzuschalten, Felder die sich im Typ ändern umzukopieren, ggf. ganze Tabellen zu sichern, Felder die nicht übernommen werden leeren und ähnliches. Kann man auch mit RecRef/FieldRef programmieren.

2. komplette neue Applikation einlesen

Die neue Applikation muss um die zusätzlichen Felder und Tabellen, die durch 1. reingekommen sind, erweitert sein.

3. weitere Konvertierungen / Einrichtungen für die neue Applikation vornehmen

4. Alle Konvertierungstool-Reste entfernen

aber so arbeiten auch die Upgrade Toolkits... man hat zum Schluss 3 oder mehr Objektsätze die man braucht, es ist aber das "bewährte" Vorgehen. Und man vermeidet viele Datensätze durch Excel-Dateien zu schleifen.

LG Jens

Hallo Jens,

super, vielen Dank für die Info.
Das werde ich heute nun mal mit meinem Kollegen durchdiskutieren.
Werde euch auch auf dem laufenden halten.

Denke da tauchen dann noch ein paar Fragen auf

Viele Grüße

Bernd

Denke da tauchen dann noch ein paar Fragen auf

Auf jeden Fall solltest du deinen Geschäftsführer fragen, was günstiger kommt:

1. Konventionalstrafe zahlen (Konvention schreibt man mit v und nicht mit f) und GoLive verschieben.

2. Riskieren, dass durch den zu frühen GoLive das System unausgegoren läuft und ein Dominoeffekt einsetzt, der an später Stelle in Zukunft noch höhere Kosten verursacht

Diese Entscheidung zwischen 1 und 2 nennt man im Projektmanagement: "proaktives Risikomanagement". Falls man dieses Risikomanagement unterlässt, dann schlittert man früher oder später in das hektische und noch teuerere "Krisenmanagement". Siehe Buch "Bärentango" bei Amazon:

http://www.amazon.de/B%C3%A4rentango-Ri ... A4rentango

Ach ja, euer NAV-Partner reibt sich evtl. jetzt schon die Hände, nach dem 01.08. das Krisenmanagement zu übernehmen.

Dennoch drück ich euch die Daumen, dass es klappt und ihr am 01.08. erfolgreich GoingLive seid!!!

Hallo,

ich kann mir immer noch nicht ganz vorstellen, was es bringen soll, nicht das Upgradetoolkit zu benutzen.
Was setzt Ihr denn z.Zt. für eine Datenbank ein Native oder SQL?
Wie groß ist eure Datenbank z.Zt.?
Habt Ihr eure Lizenz schon auf NAV2013 umgestellt?

Es bringt im allgemeinen wenig, Gehirn durch Hardware zu ersetzen. Will sagen, manchmal ist es besser nach den Zeitfressern in der Software zu suchen und sie durch geeignete Programmierung oder passende Tools zu ersetzen.
Die Übernahme per Excel ist definitiv nicht zur Steigerung der Performance geeignet.

Zeitfresser bei einem Update sind eigentlich immer folgende Punkte:

• Bei der Umstellung auf SQL, der Fieldcheck den man unbedingt vor dem Ziehen der FBK durchführen muss. Das Standard- Tool ist nicht gerade für seine Geschwindigkeit bekannt. Hier gibt es, richtig angewendet, Alternativen. Die wenn man sie unter NAV2009 (technische Umgebung) einsetzt, doch erheblich schneller sind. Die SQL- Umstellung und technische Umstellung kann man auch schon vor der eigentlichen Umstellung auf NAV2013 durchführen, eine passende Lizenz vorausgesetzt, und es ist keine besondere extern angebundene Software vorhanden, die auf Spezialitäten der technischen Umgebung von NAV 3.7 bzw. der native DB aufsetzt. Die Umstellung auf SQL vorher hat auch den Vorteil, dass sich die Mitarbeiter und das System an die Windows- Anmeldung gewöhnen können (Rechte, wie geht man mit Arbeitsplätzen um, an denen mehrere Leute arbeiten,...)
• Nach der Umstellung auf SQL kann man sich den nächsten Schritt für ein Upgrade überlegen. Hier geht man nur deshalb den Weg über NAV 2009 weil es kein direktes UGT für NAV3.7 nach NAV2013 gibt. Es hindert einen aber niemand daran eines zu erstellen, d.h. die UGTs für NAV3.7->2009 und 2009->2013 zu kombinieren. Das spart zwei durchläufe des UGTs und den Merge einer NAV2009 Tabellenstruktur.
• Es ist zwar schön den Fortschrittsbalken des UGT zu verfolgen, mit Performace hat das aber wenig zu tun. Man muss sich überlegen, wann es sinnvoller ist, die Funktionalität und Geschwindigkeit des SQL-Servers zu benutzen, und wann man die Funktionalität der NAV Businesslogik benötigt.
• Schlüssel sind bei einem Update, wie Jens schon bemerkte, oft ein Hindernis aber selten von Nutzen. Also alle nicht unbedingt nötigen deaktivieren.
• Hat man ein paar mehr Dimensionen bzw. Dimensionsposten (>5Mio.), ist das Upgradetoolkit zu NAV 2013, trotz Nutzung der SQL-Server- Funktionalität nicht gerade der Bringer. Man kann aber mit kombinierter Nutzung von NAV und SQL das ganze von nach 20 Stunden abgebrochen auf nach 4 Stunden fertig mit dem Update bringen.
• Einen Punkt den man nur bedingt beeinflussen kann ist die Umstellung von NAV 2009 auf NAV 2013 Technik. Da hier die Umstellung auf Unicode statt findet, kann man hier nur durch Reduzierung der Daten Einsparungen bewirken, d.h. ChangeLog und alle Tabellen überprüfen die viel Text enthalten, ob man hier das Datenvolumen reduzieren oder vorübergehend auslagern kann.

Und nur hin und wieder kann man bei geeigneter Hardware auch mit einem passend ausgestattetem Notebook (SSD) bessere Performance erreichen, als mit einem noch so schnellen Server mit viel Speicher und CPU.

Gruß, Fiddi

Spätestens bei Übernahme der Bewegungsdaten (Posten) via Excel/Rapidstart das da irgendwas generell schief läuft.
Entweder man fährt ein Applikationsupdate durch um die Posten zu erhalten, oder man macht OP-Buchungen/Inventurbuchung als Neustart, aber nicht Posten kopieren. Um das dann konsistent zu haben, müsstest Du alle Beleg-/Registertabellen auch übernehmen, ansonsten (1.8. ist Geschäftsjahrbeginn?) wird der Wirtschaftsprüfer sicherlich recht komisch reagieren, wenn Bewegungsdaten vorhanden sind, aber keine Belege dazu.

Wer Postentabellen per Dataport/Report füllt, wird geteert und gefedert!
Und mit der Dimensionsumstellung erst Recht!

Jan hat vollkommen Recht, entweder Update oder OP-Übernahme über die Buchblätter.
Gibt´s dafür ein Konzept? Sonst treibt Ihr ins Chaos...

VG
Mike

Inwiefern wurde der Partner eigentlich in das Upgrade-Projekt einbezogen?
Entweder ist der Partner so inkompetent, dass dieser an Microsoft gemeldet werden sollte, oder aber ihr habt einfach am falschen Ende gespart nach dem Motto: "Kriegen wir schon selber (irgendwie) hin."

Euer Chef täte gut daran einen Freelancer für 1-2 Tage zu beordern, der das aktuelle Projekt einmal begutachtet.
Wenn euer Chef den 1.8. durchziehen will, sollte er sich nicht wundern, wenn die involvierten Leute dann wochen- oder gar monatelang ausfallen durch Krankheit/Burnout o.ä.

Dieses Forum und die Community hilft bei einzelnen Fragen/Hilfestellung, aber bietet keine Möglichkeit für irgendwelche thematische Aussagen haftbar zu machen, oder gar komplette Beratungen zu übernehmen.

Ich hab gerade noch einmal Deinen Ursprungsbeitrag gelesen:

wir sollten dann innerhalb von einem Tag auch alle andern Bewegungsdaten ebenfalls importieren, das sind z.B. 1 Mio Zeilen.

Da hilft nur noch auswandern auf einen SEHR großen Planeten, der sich SEHR langsam dreht - in einem Erdentag wird das nicht klappen. Ich habe selbst schon einige große Datenübernahmen gemacht, aber das erscheint mir unmöglich. Wie lange soll denn alleine die Verbuchung von 1 Mio Zeilen dauern?

Zeig Deinem Chef doch mal diese Diskussion - das sollte helfen... - hoffentlich...

VG
Mike

Zeig Deinem Chef doch mal diese Diskussion - das sollte helfen... - hoffentlich...

"Was nichts kostet ist nichts wert."

Hallo zusammen,

hier werden sehr viele Mutmaßungen getätigt über das was da ablaufen soll, über die uns keinerlei Informationen vorliegen. Außerdem wissen wir nicht was bei der Übernahme alles geändert werden soll.

1Mio Sachposten sind eher als Peanuts zu bezeichnen, 1 Mio. Rechnungszeilen sind da schon was anderes, weil da ein Vielfaches an Sach- und anderen Posten dahinter steckt und außerdem noch eine nahezu identische Anzahl weiterer Belege vorhanden sein dürfte.

Ich kann zwar die Aussagen von JanGD und Mike verstehen, das man so etwas eher nicht mit dem Migrationstool macht, auch habe ich an dem Zeitplan so meine Zweifel.

Um einen Partner aber deshalb als inkompetent zu bezeichnen, oder andere Aussagen zu treffen, dazu fehlen uns hier im Forum noch eine ganze Menge Informationen zu dem vorgesehenen Update.

Deshalb möchte ich doch alle bitten hier ein wenig mehr Contenance walten zu lassen.

Gruß, Fiddi

Um einen Partner aber deshalb als inkompetent zu bezeichnen, oder andere Aussagen zu treffen, dazu fehlen uns hier im Forum noch eine ganze Menge Informationen zu dem vorgesehenen Update.

Deshalb möchte ich doch alle bitten hier ein wenig mehr Contenance walten zu lassen.

Ich glaube Du hast die einleitende Frage zu meinem entsprechenden Post überlesen.
Ich habe per se keinen Partner als inkompetent bezeichnet, da es ja nicht zwingend sein Fehler ist, wenn er nicht entsprechend umfänglich in das Projekt einbezogen worden ist.