Individualprogrammierung und Einspielung von Updates

Hallo,

ich bin ein wenig irritiert. Ich bin der Meinung dass man Individualprogrammierungen in Dynamics NAV vornehmen kann und diese nach einem Update bzw. Versionswechsel Bestand haben und nicht neuprogrammiert werden müssen. Klar, Anpassungen kann es geben, aber die dürften sich vom Aufwand stark im Rahmen halten.

Klar, wenn man Programmänderungen direkt in die Buchungsroutinen oder sonstigen Kernroutinen vornimmt, können diese bei Updates überschrieben werden. Aber meines Erachtens gibt es ähnliche Einsprungpunkte wie in SAP die Updates möglich machen

Ein Dienstleister meinte, dass dies nicht so möglich ist und Änderungen nach jedem Update neu programmiert werden müssen. Deshalb empfiehlt dieser den Standard soweit wie möglich orignal zu belassen und keine Programmierungen hinzufügen.

Das führt doch das Konzept ad absurdum

Sorry, ich kann das nicht glauben.

Wer kann mir mehr Infos dazu geben!?

Danke für die Hilfe..

Wahr: Je weniger Individualanpassungen, desto leichter und kostengünstiger das Update. Deswegen so nah wie möglich am Standard bleiben.

Wenn es nun aber Anpassungen gibt, dann müssen die natürlich auch in das Update eingebunden werden. Hierzu müssen wir Partner die Objekte "mergen". Das heißt: Ich habe (pro Objekt!) zwei Textdateien (ein Objekt alte Version mit Anpassung, ein Objekt neu ohne Anpassung) und bilde daraus per Hand eine Schnittmenge.
Hierfür gibt es Tools, die uns diesen Merge vereinfachen, aber nie abnehmen.
Das heißt: Mergen ist Aufwand, und das je nach Anpassungsgrad nicht zu knapp.

Hallo Natalie,

danke für die Info.

Was mich verwundert: wie machen größere Firmen das denn.. die z.B. komplette Branchenlösungen als Module entwickeln..
Bei jedem kleinen Update wird da immer rumgemerged!?
Das ist doch ein immenser Aufwand?ODer hält sich das doch in Grenzen? Oder frieren die Ihre Softwarestände ein oder machen die Updates nicht mehr mit?

Danke noch mal

Was mich verwundert: wie machen größere Firmen das denn.. die z.B. komplette Branchenlösungen als Module entwickeln..

Sobald es ein neues Servicepack von NAV gibt, aktualisieren sie die Branchenlösung, sodass es neue Branchenobjekte gibt.
Durch diese neuen Branchenobjekte wird dem mergenden Programmierer die Arbeit erleichtert.

Bei jedem kleinen Update wird da immer rumgemerged!?

Was verstehst du unter einem kleinen Update?
Bei Navision-Servicepacks und erst recht bei neuen Releases (5.0 statt 4.0 SP3 z.B.) ändert sich der zu mergende Objektstand z.T ernorm.

Das ist doch ein immenser Aufwand?ODer hält sich das doch in Grenzen? Oder frieren die Ihre Softwarestände ein oder machen die Updates nicht mehr mit?

Ein Update einer nicht-Standard-Datenbank ist IMMER ein Aufwand.
Es kann durchaus sein, dass manche Kundendatenbanken kein Update mehr erhalten, weil der Aufwand in keiner vernünftigen Relation zu dem Nutzen steht.
Oft geht man dann auch den Weg eines "Neustarts": Neue NAV-Version nehmen, alte, ausgesuchte Anpassungen darauf programmieren, Altdaten importieren und los.

Nochmals danke große Hilfe!

Mit welcher Häufigkeit kommen denn Service Packs raus? Kann man dazu eine pauschale Aussage treffen?

Ist es denn ohne größere Nachteile möglich einfach auf Updates verzichten? Oder ist das ein nicht zu empfehlendes Szenario.

Angenommen eine Individual-Programmierung in der Ersterstellung kostet ca. 10.000€. Mit was für Kosten müsste man bei einem Release-Wechsel rechnen? 1,2, 5 oder gar 10T€?
Gibt es ungefähre Hinweise aus der Erfahrung heraus!?

Thanks again

Sorry, bei Zahlen muss ich passen.
Ich berichte dir das nur aus Sicht einer Programmiererin, die es einfach macht, wenns beauftragt worden ist

Mag sich vielleicht jemand anderes zu dem Thema noch äußern?

Angenommen eine Individual-Programmierung in der Ersterstellung kostet ca. 10.000€. Mit was für Kosten müsste man bei einem Release-Wechsel rechnen? 1,2, 5 oder gar 10T€?
Gibt es ungefähre Hinweise aus der Erfahrung heraus!?

Also, meine Glaskugel sagt dazu, daß die Updates der Anpassungen 'billiger' sind als deren Entwicklung, da 'nur' auf Kollisionen zwischen neuem Std. und Anpassungen geachtet werden muß.

Markus

alles andere hätte mich auch geschockt! also das klingt ja doch nach relativ aufwandsarm! hat damit keiner genauere erfahrung in welchem verhältnis sowas steht!?

alles andere hätte mich auch geschockt! also das klingt ja doch nach relativ aufwandsarm! hat damit keiner genauere erfahrung in welchem verhältnis sowas steht!?

Die Frage wird sich kaum pauschal beantworten lassen. Bei einem Upgrade von 2.x muss tatsächlich vieles neu programmiert werden, weil ab 3.x die Codesprache ( Felder , Funktionen, Variablen) von Deutsch auf Englisch gewechselt hat.

Grundsätzlich ist es immer möglich, dass Änderungen am Standard alte Individualprogrammierungen überflüssig machen oder aber durch diese Konflikte entstehen, die es vorher nicht gab.
Wenn mehrere Major Releases überbrückt werden müssen, weil Upgrades ausgelassen wurden (z.B. von 2.6 auf 4 oder gar 5 (das erfordert 2 Upgrade Toolkits)) wird die Wahrscheinlichkeit, dass es mit einfachem Objektmergen nicht mehr getan ist, immer größer.

Es gibt z.B. Änderungen, die sind banal , aber trotzdem zeitaufwendig, dazu zählen z.B. extrem stark veränderte Forms (neue Farben, verschobene Felder,Hinweistexte, Fettdruck etc.). Notfalls kann nach dem Upgrade hier mit normalen Forms gestartet werden und diese dann nach und nach vom Kunden wieder selber umgebaut werden.

Andere greifen tief in die Buchungssystematik ein und offenbaren ihr Konfliktpotenzial erst, wenn sie im Zusammenhang von Objekt zu Objekt betrachtet werden.

Aufwandsarm ist es jedenfalls nie, nur der technische Teil des Upgrades ist schnell erledigt.