NAV17 Update zu BC14

Hallo,
wir sind gerade dabei unser NAV17 auf BC14 zu migrieren. Nun sind die Tabellen und Codeunits bereits von unserem Partner aktualisiert geworden.
Pages,Reports usw. wollen wir selber machen.
Wir haben bei den Standard Objekte einiges geändert. Wie sollte man das am besten machen.
Habe z.B. die Artikelkarte mal von NAV17 und BC14 als Text exportiert und mit einen Merge-Tool angesehen. Da ist ziemlich viel rot (also unterschiedlich).
Wenn ich das alles manuell machen muss, dann wird das lustig.

Wie macht ihr das?
Besten Dank
stony

Zuletzt geändert von stony am 15. Oktober 2020 18:08, insgesamt 1-mal geändert.

Ich vermute es ist ein Tippfehler dass du mal BC14 und mal BC17 schreibst, du solltest natürlich die gleiche Version verwenden.

Ansonsten solltest du NAV 2017 angepasst gegen Standard (mit gleichem CU-Stand) vergleichen um zu sehen was ihr alles angepasst habt. Eine angepasste Version 10 mit Standard Version 14 (oder 17) zu vergleichen macht ja wenig Sinn.

Ein paar Dinge in Pages kann man ja recht einfach machen mit dem Page Designer im Client, der daraus dann eine Page Customization macht.

Ansonsten solltest du NAV 2017 angepasst gegen Standard (mit gleichem CU-Stand) vergleichen um zu sehen was ihr alles angepasst habt. Eine angepasste Version 10 mit Standard Version 14 (oder 17) zu vergleichen macht ja wenig Sinn.

dann hab ich das über die ganzen Jahre immer falsch gemacht^^
klar, der Vergleich NAV17_modified mit NAV17_std zeigt dir, was angepasst ist, aber sorry - das zeigt mir doch auch der Vergleich NAV17_Mod mit BC17_Std (ist ja eh alles ordentlich dokumentiert *hust hust*)
es ist natürlich ein Unterschied, ob ich die Anpassungen direkt sauber als Extension umsetze, oder wie bisher einfach nur stupide reinmerge.
Wenn ich direkt eine Extension daraus mache, macht der Vergleich NAV17_modified mit NAV17_std schon Sinn, denn ich hab dann in BC17 sowieso die StandardPage
aber wenn nicht, dann Vergleiche ich NAV17_mod mit BC17_Std ....von mir aus auch über einen 3Wege-Vergleich (noch mit NAV17_Std)

Da wir auch gerade ein Migrations-Projekt von NAV2017 zu BC14 haben:

Wir nutzen die Chance und versuchen, alle Individualanpassungen aus NAV2017 als App für BC14 zu realisieren.
Wir sind uns bewusst, dass wir nicht alle Anforderungen als App abbilden können, aber nur so sammeln wir Erfahrungen in der App-Entwicklung.
Bei kleinere Report-Layoutanpassungen (Spalten zu schmal, ...) gehen wir aber noch den klassischen Weg und passen den Original-Report an, da es etwas übertrieben wäre, deswegen eine Kopie im 50.000er-Bereich anzulegen.
Ab BC15 bleibt uns natürlich kein anderer Weg, aber solange wir es noch vermeiden können, tun wir es auch.

Wenn wir einen Report "komplett auf links krempeln" wollen, dann haben wir auch schon unter NAV2017 eine Kopie vom Original angelegt und diese dann umgebaut.

Bei jeder neuen NAV-Version haben wir die Chance genutzt und alle Individualanpassungen grundsätzlich erstmal in Frage gestellt.
Brauchen wir diese Anpassung noch?
Passt sie noch zu den aktuellen Anforderungen/Geschäftsprozessen/...?
Können wir die Anpassung optimieren, um neue Technologien zu nutzen?

Manche Anpassungen wurden aufgrund dieser Fragen komplett neu entwickelt und haben (technisch betrachtet) nichts mehr mit der alten Lösung zu tun.
Manche Anpassungen wurden zwar neu entwickelt, jedoch konnten viele Funktionen aus der alten Version mit nur geringfügigen Anpassungen übernommen werden.
Manche Anpassungen waren schon in der alten Version so gut durchdacht, dass man den Programmcode quasi 1-zu-1 in AL-Code umwandeln und weiterverwenden konnte. (Abgesehen von ein paar kleineren "kosmetischen" Korrekturen.)

dann hab ich das über die ganzen Jahre immer falsch gemacht^^
klar, der Vergleich NAV17_modified mit NAV17_std zeigt dir, was angepasst ist, aber sorry - das zeigt mir doch auch der Vergleich NAV17_Mod mit BC17_Std (ist ja eh alles ordentlich dokumentiert *hust hust*)

Dann hast du das wohl:
Nee, der Vergleich NAV17_mod zu BC17_Std zeigt dir nur Blödsinn, denn das eine ist C/SIDE und das andere AL.

Aber mal Scherz beiseite. Wenn ich das so lese, dann hast du noch nie wirklich mit einem 3-Wege- Merge gearbeitet oder? Der würde sogar funktionieren, um von C/SIDE nach AL- Base- App zu mergen.

Gruß Fiddi

@Timo:

wie schätzt du die Zeitaufwands- Unterschiede ein:

• Aufwand APP- Entwicklung normale C/SIDE- Entwicklung
• Aufwand für Support/Debugging
• Wie schnell geht Bugfixing (C/SIDE: Objekt ändern,AL:??)
• Weiterentwicklung (Änderungen von MS in der eigenen App- Entwicklung nachhalten, da die App ja völlig vom Quelltext des Standards entkoppelt ist)

Gruß Fiddi

@fidii,

ich bin zwar nicht Timo, aber ich antworte mal aus meiner Erfahrung (bisher nur mit BC14 ....BC15++ nur in der Cloud - darüber reden wir mal nicht xD):

Aufwand APP- Entwicklung normale C/SIDE- Entwicklung
--> am Anfang vll. so Faktor 2-3

Aufwand für Support/Debugging
--> im Rahmen, aber defintiv höher (Debugging)

Wie schnell geht Bugfixing (C/SIDE: Objekt ändern,AL:??)
--> Am Anfang viel länger, aber wenn man sich eingerichtet hat, klappt das recht fix - wir haben ein eigenes Tool, mit dem auch der "normale" Consultant die Extensions ohne Powershell einspielen/updaten kann
--> die Herausforderung ist aus meiner Sicht, dass wir "früher" fix mal eine Änderung an z.B. Pages/Codeunits machen konnten - jetzt muss halt wieder die Extension rein - wobei der User dann eine Meldung ins Gesicht bekommt
--> daher spielen wir die normalerweise immer erst Abends ein

Weiterentwicklung (Änderungen von MS in der eigenen App- Entwicklung nachhalten, da die App ja völlig vom Quelltext des Standards entkoppelt ist)
--> schwieeeerig zu sagen

Und was ist es für ein Aufwand die App immer aktuell halten zu müssen?

Den größten Aufwand hatten wir im Vorfeld, weil wir uns intensiv Gedanken zu Nummernbereichen (Objekte, Feldnummern) sowie der Aufteilung auf verschiedene Apps gemacht hatten.
Dabei konnten wir davon profitieren, dass wir uns diese Gedanken auch schon bei der Umstellung von NAV 5.0 auf NAV2017 gemacht hatten, und brauchten jetzt quasi nur noch etwas "optimieren" und die App-Aufteilung klären.

Da wir aktuell vier NAV-Datenbanken (DE, NL, PL sowie eine L+G-Datenbank) haben, haben wir jetzt auch eine W1-Version in der Entwicklung eingeführt.
Einige Funktionen werden in allen Datenbanken benötigt, einige nur in den "Auslands-Datenbanken", und die meisten nur in der DE-Datenbank.
Dies haben wir bei den Nummernbereichen sowie der App-Aufteilung berücksichtigt.

Und dann kamen die Objekt-IDs für die Table- und Page-Extensions, die unser Konzept der Nummernbereiche mal eben komplett gesprengt hatten.
Eine Funktionalität, welche selber nur eine Tabelle, eine Page und eine Codeunit benötigt (also einen sehr kleinen Nummernbereich belegt), kann aber in gefühlt hunderten Standard-Tabellen und -Pages implementiert werden. (*Glaskugel polier*)
Also haben die Funktionalitäten entsprechend ihrem Bedarf klassische Nummernbereiche erhalten und davon unabhängig für die Extensions ganz andere Bereiche.
Wichtigstes Kriterium bei der Zuordnung der Funktionalitäten auf die einzelnen Apps war, dass wir möglichst wenig Abhängigkeiten produzieren und in unserer "Basis-App" zukünftig so wenig Anpasungen/Erweiterungen vornehmen müssen wie irgendwie möglich.

Am Anfang war die AL-Entwicklung natürlich komplettes Neuland (und ist es irgendwie immer noch), so dass sich der Entwicklungsaufwand für dieselbe Anforderung vervielfacht hat.
Aktuell dürfte der Aufwand wohl "nur noch" um den Faktor 3-4 höher sein, mit der Hoffnung, dass er noch weiter sinkt.

Wenn man zu jeder Datenbank auch einen WebClient hat, dann ist das Debuggen nicht aufwändiger als in der C/SIDE-Umgebung, nur halt anders (gewöhnt man sich aber recht schnell dran).

Aktuell sind wir mit BC14 noch nicht live, so dass wir noch die Möglichkeiten haben, unser Konzept zu optimieren (was wir an einigen Stellen auch schon gemacht haben und die bisherigen Objekte in den bereits erstellten Apps entsprechend umnummerieren mussten).

Inwiefern unsere Überlegungen und unser Konzept zukunftsfähig sind, können wir natürlich nicht sagen, jedoch sind wir sehr guter Dinge, dass es unseren Anforderungen auch in der Zukunft gerecht wird.
Im Gegensatz zu den Systemhäusern brauchen wir unsere Apps nicht für jedes CU und/oder BC-Release upgraden, da wir ja nur für unsere eigenen Bedürfnisse entwickeln.
Da wir schon in NAV2017 den Standard möglichst nur über Events erweitert haben, und das jetzt mit den Extensions sogar noch intensiver nutzen können, sehen wir (unter BC14) sehr große Vorteile. (BC15 ff. sind für uns zur Zeit überhaupt keine Option, da es einige Anforderungen bei uns gibt, die sich nicht nur mit Extensions und Events abbilden lassen.)

Updates gab es bei uns schon immer nur einmal wöchentlich abends nach regulärem Feierabend. (Die Systemintegratoren und Entwickler kommen an diesem Tag entsprechend später ins Büro - manche sogar erst gegen Mittag.)
Einzige Ausnahme: Dringende Fehlerkorrekturen (also echte Fehler und nicht das, was der einfache Anwender als "Fehler" bezeichnet) werden notfalls auch mitten im laufenden Betrieb in die Produktiv-Datenbank eingespielt.
Aufgrund unseres Change-Management-Konzeptes kommt das aber nur sehr sehr selten vor und zeigt sich dann auch nur bei sehr ungewöhnlichen Datenkonstellationen.
Dieses Konzept sieht ein 6-Augen-Test vor, bevor eine Anpassung in die Produktiv-Datenbank übertragen wird. (Entwickler, Consultant, Key-User)

Danke dir für deine ausführliche Info.

Was ich mich frage ist nur, ob sich der 3 bis 4 fache Aufwand in Zukunft für ISV's rechnet, die eine App entwickeln, die sicherlich mit weniger Ertrag verbunden ist.

Außerdem erfordert die auch noch den erheblich höheren Aufwand bei der erforderlichen Aktualisierung der Apps mit jedem CU und mit jeder neuen Version zwei mal im Jahr.

Spätestens bei der neuen BC- Version fängt der Aufwand richtig an, da hier wieder ein Merge durchgeführt werden muss, um die Unterschiede zwischen den Versionen zu lokalisieren, und die eigene Entwicklung anzupassen.
Durch die Events sieht man aber nicht mehr sofort, ob eigener Code betroffen ist, da dieser nicht an der Stelle im Quelltext sichtbar ist (direkt aufgerufen wird).

Gruß Fiddi

Der aktuell höhere Aufwand ist größtenteils der mangelnden Kenntnisse und fehlenden Routine geschuldet.
Zum Vergleich: Wie lange habt ihr an euren ersten RDLC-Reports "gebastelt" und wie lange braucht ihr heute für dieselbe Aufgabe?
Ja, RDLC-Reports sind aufwändiger als Classic-Reports, aber man braucht heute nicht mehr soviel Zeit, wie noch 2009/2010.

Und so wird es wohl auch bei der AL-Entwicklung aussehen.
Die Entwicklungszeiten werden sich durch die aufkommenden Kenntnisse und Routine verkürzen, jedoch immer noch höher bleiben als unter C/AL.
Diese höheren Kosten werden dann direkt oder indirekt (zumindest zu einem Teil) an den Endkunden weitergereicht.
Stundensätze steigen, Aufwandschätzungen steigen, Modul-Preise steigen.

Wer hier die steigenden Kosten mit Fingerspitzengefühl auf "Fortbildungskosten" und "Investitionskosten" umverteilen kann, der hat entsprechend geringere Kostensteigerungen an den Kunden weiterzugeben.

Kostensteigerungen gab es aber schon immer und wird es auch immer geben.
Damit müssen - vor allem wir Endanwender - wohl oder übel leben.

...erheblich höheren Aufwand bei der erforderlichen Aktualisierung der Apps mit jedem CU...
Spätestens bei der neuen BC- Version fängt der Aufwand richtig an, da hier wieder ein Merge durchgeführt werden muss, um die Unterschiede zwischen den Versionen zu lokalisieren, und die eigene Entwicklung anzupassen.
Durch die Events sieht man aber nicht mehr sofort, ob eigener Code betroffen ist, da dieser nicht an der Stelle im Quelltext sichtbar ist (direkt aufgerufen wird).

Ich denke da müssen einige ISVs noch sehr viel dazu lernen.
Sie müssen mehr in Automatisierte Tests und standardisierte Entwicklung investieren.
Nicht mehr jedem Kunden sein eigenes Brötchen backen.
Jeder Android-/iOs-/App-/Web- Entwickler muss genau das selbe tun, weil die sich ständig ändernden Systeme das erfordern. Und die haben wesentlich weniger Zeit.

Mir ist auch wohl bewusst, dass das nicht einfach ist und viel Hinrschmalz braucht. Am Ende kann diese Art der Entwicklung auch ein Vorteil sein.

Hallo,

Nicht mehr jedem Kunden sein eigenes Brötchen backen.

Kannst du mir mal sagen, wie das funktionieren soll?

Ich habe gerade ein Projekt, da ist folgendes anzubinden:
1. Ein externes Lagerverwaltungssystem.
2. EDI, das sowohl Daten aus BC als auch aus dem LVS via BC verschickt.
3. diverse externe Partner, die nicht über EDI angebunden werden (können) z.B. Speditionen.
4. Ein Kunde, der durch sein spezielles Business sehr spezielle Anforderungen an das System hat.

So etwas kann man nicht mit ein paar Apps aus dem Appstore zusammen klicken. Da muss man schon etwas mehr Gehirnschmalz investieren. Und es kommt garantiert in dieser Konstellation nur bei diesem Kunden vor.

Entschuldige bitte, aber ich finde diese (nicht nur) deine Aussage ziemlich Ahnungslos.

Den Rest kann ich allerdings so unterschreiben, wenn auch vielleicht anders als du es meinst.

Das ISV's oder Partner Ihre Geldbringer (Individualisierungen) einfach so aus dem Fenster werfen (können), und glauben, dass sie mit erheblich höherem Aufwand und weniger Ertrag pro Installation mehr Geld verdienen, glaube ich persönlich nicht.
Und das jeder Entwickler in anderen System das auch tun muss ist schon O.K. Aber wer eine App oder ein Plugin für eines deiner Systeme programmiert, muss die nur kompatibel zu dem Standard dieses Systems sein (wenn der Standard einen Kalender hat, kann ich ihn nutzen, ansonsten lass ich es einen Kalender anzusteuern).
In einem ERP ist mit einem Addon auch ein Workflow verbunden, der von Rest des Systems verarbeitet werden können muss. Wenn z.B. per EDI eine Bestellung mit einer speziellen Referenz kommt (um später die EDI-Lieferavis zuzuordnen), weil der jeweilige EDI- Standard das so erfordert, dann musst du das durch das komplette System schleppen, und alle Addons die damit zu tun haben (z.B. der ausgedruckte Lieferschein) müssen das verarbeiten, auch wenn Sie nicht von diesem EDI- Modul wissen.
Ein Plugin für ein CMS (Joomla, Drupal,..) wird nur den Standard des Systems nutzen, aber nie weitere Addons, weil man die ganzen möglichen Kombinationen gar nicht abbilden könnte, in einem ERP aber müsste.

Gruß Fiddi
Gruß Fiddi

Ja, den Wunsch nach "zurück zum Standard" oder "näher an den Standard" habe ich bisher bei so ziemlich jedem Projektbeginn gehört.
Wenn dann der Echtstart bevorsteht, stellt man fest, dass die Realität irgendwie ganz anders aussieht.
Und schaut man sich das System dann 12 bzw. 24 Monate später nochmal an, dann ist von "Standard" kaum noch was übrig.

Das "Problem" ist, dass NAV/BC nur eine "gute Ausgangsbasis", jedoch kein "allumfassendes ERP-System" ist.
Soweit nicht weiter schlimm, es gibt ja die AddOns der Drittanbieter.
Also kauft man z. B. eine Anbindung an ein DMS-System von dem einen Anbieter, eine automatisierte Rechnungseingangsverarbeitung von einem anderen Anbieter und steht dann vor der Herausforderung, wie die automatisiert eingelesene Eingangsrechnung an das DMS-System weitergereicht wird.
Ebenso benötigt man eine Personalzeiterfassung hier und eine Lohn-Modul dort, aber wie bekommt das Lohnmodul nun die Arbeitszeiten aus der Personalzeiterfassung des anderen Anbieters?

In einer OnPrem-Version bekommt man das ja noch gelöst, aber wie würde man diese "Herausforderungen" in einer SaaS-Lösung abbilden?

Und dann gibt es noch individuelle Anforderungen, für die es einfach keine AddOns von Drittanbietern gibt.
Gerade der Mittelstand ist für seine Flexibilität bei den sich ständig ändernden Marktanforderungen bekannt. Die finden relativ schnell einen passenden Prozess, um sich am Markt einen Wettbewerbsvorteil zu verschaffen oder gar eine Marktlücke zu besetzen, jedoch gibt es für diesen Prozess kein AddOn, also müssen sie sich selber etwas programmieren.
Wenn sich dieser innovative Prozess im Laufe der Zeit im Markt durchsetzt, wird es sicherlich auch den ein oder anderen Anbieter geben, der dafür das passende AddOn anbieten kann, solange kann der Mittelstand aber nicht darauf warten.

dem ist nichts hinzuzufügen!!

Gruß Fiddi