Wechsel von NAV 2017, auf was?

Hallo zusammen,

wir setzen aktuell NAV 2017 ein und wollen nächstes Jahr auf eine "neuere" Version wechseln. Da wir einen sehr speziellen Vertrag mit MS haben und damit selbst Partner sind, ohne eigentlich als Partner auf dem Markt tätig zu werden, müssen wir die Migration selbst vornehmen und können auch nicht wirklich jemanden fragen. Daher stelle ich die Frage mal an Euch... Danke schon mal im Voraus für alle Hilfen!

Aktuell setzen wir noch keine Extensions ein, sprich unsere kompletten Codeänderungen und eigenen Programmierungen sind in den Objekten direkt drin, über die alte Weise

Wir könnten nun die aktuellste Version von NAV 2018 einsetzen. Der Sprung ist zu unserer, nehme ich mal an, nicht so gewaltig. NAV 2018 wird sicher auch noch eine Weile mit regelmäßigen CUs von MS versorgt, so dass dieser Schritt uns Zeit verschaffen könnte.

In die Cloud können und wollen wir aus verschiedenen Gründen auf keinen Fall. Also blieb dann noch der Wechsel auf Business Central in der On-Premises Variante. Mir fehlen hier aber die Informationen, wie genau diese Migration laufen würde und ob entsprechend die Voraussetzung ist, dass alles in Extensions ist. In der Migration komplett auch auf Extensions zu migrieren, hat natürlich ein höheres Risiko. Uns wäre da ein 2-Step-Szenarion wahrscheinlich lieber.

Was sind Eure Empfehlungen oder Erfahrungswerte?

Gruß
sas_fisch

Dyn365BC OnPrem kann man normal in C/SIDE programmieren. Manches wird als Extension geliefert (MwSt), aber das wars dann auch. Wenn man tatsächlich drüber nachdenkt so einen kleinen Schritt zu machen, dann wäre es wohl NAV2017 -> Dyn365BC OnPrem. Gefühlt ist das aber eine Menge Aufwand für nix. Okay, ein bischen Performance evtl. Alte durch neue Fehler ersetzen. Sowas in der Art.

Hi,
https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/upgrading-to-business-central
Die Migration zu BC onPrem läuft aus meiner Sicht genau wie immer.
Du musst nichts als Extension machen, da ja noch die Möglichkeit besteht, die Anpassungen in die "normalen" nav-Objekte (für BC) einzumergen.
Einiges ist umgebaut worden, aber das sollte nicht das Problem sein.
Wir gehen so vor - Upgrade auf BC ohne Extensions - schrittweise Migration der Codeanpassungen auf Extensions.
Wenn Ihr die Kapazitäten habt, könnt Ihr natürlich gleich voll auf Extensions gehen

Dyn365BC OnPrem kann man normal in C/SIDE programmieren. Manches wird als Extension geliefert (MwSt), aber das wars dann auch. Wenn man tatsächlich drüber nachdenkt so einen kleinen Schritt zu machen, dann wäre es wohl NAV2017 -> Dyn365BC OnPrem. Gefühlt ist das aber eine Menge Aufwand für nix. Okay, ein bischen Performance evtl. Alte durch neue Fehler ersetzen. Sowas in der Art.

Der Schritt ist alles anderes als klein. Allein schon durch den Wechseln des Lizenzmodells und die Umstellung auf AL.
Geht man nach der Roadmap wird zudem der Windows Client und C/AL 2020 abgeschaltet. https://totovic.com/2018/10/04/dynamics-365-business-central-updated-roadmap/. Wenn man auf Business Central wechselt sollte man alles in Extensions abbilden. Ansonsten macht man sich keinen Gefallen.

Solange man BC OnPrem benutzt hat man die C/SIDE. So gesehen ist der Schritt zwischen NAV2017 und BC OnPrem eher klein, weil man seine eigenen C/SIDE Änderungen in eine neue Codebasis tut. Man bekommt das gleiche wie vorher mit einer anderen Versionsnummer und einem etwas schnelleren Windows Client. Dafür steckt man aber gefühlt eine Menge Energie rein, ausser einer vertraglichen Verpflichtung wo das Brechen viel Geld kostet würde ich keinen Grund sehen diesen Aufwand zu treiben. sas_fisch hat ja gesagt, Cloud ist anscheinend keine Option. Ein Standpunkt der durchaus seine Gründe haben kann.

Wenn man auf Business Central wechselt sollte man alles in Extensions abbilden.

Das sehe ich ganz anders. Extensions können einiges, aber bestimmt nicht alles, was mit C/AL machbar ist, z.B. Funktionen im Standard umgehen und durch eigene ersetzen ist derzeit nicht machbar, und von MS wohl auch gar nicht gewünscht.
AL kann derzeit nur für Extensions genutzt werden, aber das soll ja nicht so bleiben, nach der Abschaltung von C/SIDE muss da auch konventionell alles mit machbar sein.

Macht es jetzt eigentlich noch Sinn den Application Builder für BC zu kaufen?

Hallo,

ich muss Kai da Recht geben. Extensions können z.Zt. eine Lösung für vieles aber nicht für alles sein.

Z.Zt. kann eine einzige Zeile Code verhindern, das man eine Erweiterung als Extension implementieren kann.

Das generelle Problem bei Extensions ist die Sichtweise der Entwickler. Eine App/Extension für eine bestimmte Funktion zu schreiben, ist kein großes Problem.

Der Entwickler der Zahlungsverkehrs- Erweiterung erstellt eine Extension, die mit dem Standard funktioniert. Da er nicht alles mit den Standardevents und -Code von BC lösen kann, kopiert er sich die Tabellen und anderen nötigen Objekte in seinen eigenen Nummernbereich und passt sie so an, dass sie funktionieren. Das machen die Entwickler anderer Erweiterungen wie z.B. Logistik, Online-Shop, Zoll, Spedition,... auch so.

Jetzt kommen wir zum Kunden, der in seiner Lösung den Zahlungsverkehr, die Logistik- Erweiterung, das Speditions- und auch den Online- Modul einsetzen will.
Die Online- Lösung, die auf das Buchen der Zahlungseingänge per Eventsubscriber in den Standardobjekten reagiert wartet jetzt vergeblich auf den Aufruf seiner Funktionen, da das ja im Zahlungsverkehr, von dem es nichts weiß passiert. Genauso kann das Online- Modul keine Bestände aus der Logistik anzeigen, da das Logistikmodul seine Daten in eigenen Tabellen pflegt, auf die das Online- Modul keinen Zugriff hat. Zum Schluss kommt das Versender- Modul, das zwar von Paketdaten weiß, die aber da sie unverantwortlicher Weise mehrere Pakete pro Lieferung versenden kann, die nicht im Lieferschein vermerkt. Das Online- Modul steht jetzt aber auf dem Schlauch, da es sehr zeitnah die Paketdaten an eBay oder Amazon melden muss, damit man dort nicht seinen Status verliert.

Das Problem ist, das eine heutige ERP- Lösung ein Team aus vielen Erweiterungen ist, die sich, wie es sich für ein gutes Team gehört, miteinander unterhalten und Informationen austauschen.
Die heutigen Extensions sind aber so ausgelegt und meist auch programmiert, dass jede Erweiterung sich in Ihr stilles Kämmerlein verzieht, und dort vor sich hin werkelt.
Jeder Entwickler einer Erweiterung wird jetzt dem Kunden sagen: Ich weiß nicht was du willst? Meine App funktioniert, und ist getestet worden. Warum behauptest du, das sie nicht unbrauchbar ist. Ganz einfach: Weil sie nicht teamfähig ist.

Jetzt möge der Einwand kommen, das man ja abhängige Apps benutzen kann. Wie soll das funktionieren? Wie viele Kombinationen aus abhängigen Apps soll ein Entwickler berücksichtigen?

Gruß Fiddi

Das Problem ist, das eine heutige ERP- Lösung ein Team aus vielen Erweiterungen ist, die sich, wie es sich für ein gutes Team gehört, miteinander unterhalten und Informationen austauschen.
Die heutigen Extensions sind aber so ausgelegt und meist auch programmiert, dass jede Erweiterung sich in Ihr stilles Kämmerlein verzieht, und dort vor sich hin werkelt.
Jeder Entwickler einer Erweiterung wird jetzt dem Kunden sagen: Ich weiß nicht was du willst? Meine App funktioniert, und ist getestet worden. Warum behauptest du, das sie nicht unbrauchbar ist. Ganz einfach: Weil sie nicht teamfähig ist.

Könnte es sein, dass Microsoft mit Business Central einen ähnlichen Fehler begeht wie mit der ersten Xbox One, bei welcher sie alle User zwingen wollten diesen Sensor mit integrierter Kamera zu benützen?

Sie haben irgendwann gecheckt, dass sich die PS 4 drastisch besser verkauft und mussten letztendlich alles umkrempeln, um nicht gegen Sony alles zu verlieren.

Irgendwie hat momentan anscheinend niemand bei MS den Gesamtblick auf das Thema ERP?

Man will NAV und AX auf Teufel komm raus in kleinste Teile schneiden und dem Kunden einen "neuen" Friss-oder-stirb Standard aufzwingen.

Macht es jetzt eigentlich noch Sinn den Application Builder für BC zu kaufen?

Was du hast kann man dir schwerer nehmen. Wir haben uns 2011 für die C/AL Lizenz entschieden und haben es mehr als eingespielt.Im ersten Jahr.

Wenn man auf Business Central wechselt sollte man alles in Extensions abbilden.

Das sehe ich ganz anders. Extensions können einiges, aber bestimmt nicht alles, was mit C/AL machbar ist, z.B. Funktionen im Standard umgehen und durch eigene ersetzen ist derzeit nicht machbar, und von MS wohl auch gar nicht gewünscht.
AL kann derzeit nur für Extensions genutzt werden, aber das soll ja nicht so bleiben, nach der Abschaltung von C/SIDE muss da auch konventionell alles mit machbar sein.

Auf der Directions EMEA hatten sie die komplette W1 als eine große Extension präsentiert. Im C/SIDE waren nur die Systemtabellen vorhanden. Also kein C/AL mehr, sondern tatsächlich alles in AL. Denkt man hier einen Schritt weiter, hat man wahrscheinlich über eine Anpassung einer späteren Base-Extension die gleichen Möglichkeiten Standard-Code zu ändern wie vorher. Allerdings über AL & Extensions und nicht mehr über C/AL und C/SIDE.

Wenn man sich die Geschwindigkeit ansieht, mit der Microsoft derzeit Business Central und AL weiterentwickelt ist es sehr wahrscheinlich, dass 2020 C/SIDE und der Windows Client Geschichte sind.
Was machst du dann, wenn du alles in C/AL abgebildet hast? Nicht mehr updaten oder alles umbauen? Erst dann mit der Technologie beschäftigen? Oder nur noch um Bestandskunden mit NAV kümmern?

Im Prinzip stimme ich dir zu. Und auch die Argumente von fiddi sind auch alle durchweg schlüssig.
Doch das ist letzten Endes egal, weil Microsoft die Rahmenbedingungen vorgibt.

Und wenn auf der Directions, den Techdays und den üblichen Blogs dir jeder gebetsmühlenartig erzählt, dass Extensions DER Weg in Business Central sind und nur noch sein werden, ist es meiner Meinung nach fahrlässig zu denken "Ach lass die alle mal labern. Ich mach einfach weiter wie bisher. Da wird schon nix passieren".

Doch das ist letzten Endes egal, weil Microsoft die Rahmenbedingungen vorgibt.

Hallo,

ich finde das ist nicht egal.
Wir als Partner - und zwar nicht nur die, die Extensions entwickeln, sondern auch die, die Module beim Kunden integrieren sollen und müssen - müssen MS in die richtige Richtung schieben, damit wir unser Geschäft auch in Zukunft noch zu aller Zufriedenheit erledigen können.
Es muss also unser Ziel sein, das MS die Rahmenbedingungen weiter in einer Richtung anpasst, die ein vernünftiges Arbeiten erlaubt.
Das ist ja auch schon in der Vergangenheit mehrfach passiert (OnPrem, Full- Source in AL,... )



Gruß Fiddi

Typischer Abnutzungskampf. Das einzige was Microsoft von ihrem Weg abbringen kann ist Geld, besser gesagt das Fehlen von Geld. Da aber Microsoft meint mit dem bisherigen Modell nicht genug zu verdienen... Hmm. Ob dabei irgendwas oder wer draufgeht ist glaube ich eher egal.

Hallo,

es dauert halt etwas länger, wenn man mit einem Ruderboot als Schlepper die Richtung eines Supertankers ändern will.

Wenn man allerdings mit vielen Ruderbooten daran arbeitet, ist auch das zu schaffen.

Gruß Fiddi

... die Richtung eines Supertankers ändern will.
Wenn man allerdings mit vielen Ruderbooten daran arbeitet, ist auch das zu schaffen.

Aber nur wenn der Tanker noch nicht Leck geschlagen hat.

Aber nur wenn der Tanker noch nicht Leck geschlagen hat.

Deshalb sollten wir alle aufpassen, dass das nicht passiert bzw. das Leck nicht noch größer wird.

Gruß Fiddi

Ich sehe es ein wenig wie Markus, aber dazu später mehr. Zunächst einmal, aus meiner Sicht ist das alles Teil eines großen Umbruchs, der schon vor Jahren angekündigt und in Gang gesetzt wurde. Die Frage, die da letztendlich hintersteckt, mit der sich MS schon ewig beschäftigt, lautet doch wie immer: Wie bekomme ich meine Business Applications gestreamlinet? Dahinter steckt natürlich der Gedanke der Effizienzsteigerung, aber natürlich auch immer noch die Idee eine ernstzunehmende Konkurrenz für SAP im Big Business Market zu schaffen. Da ist ein Billion Dollar Market, von dem MS derzeit so gut wie nichts abbekommt, schon seit Jahren. Es geht also wie immer bei MS ums Geld.

So etwas kann man natürlich nicht von heute auf morgen umsetzen. Wenn man diesen Langzeitplan also verwirklichen möchte, dann muss man ihn in einzelne Schritte aufteilen. Jetzt ist gerade mal NAV mit einem dickeren Schritt in der Technologie dran. Das hat zur Folge, dass es natürlich noch keine Antworten auf alle Fragen geben wird, da es ja ein echter Technology Change ist und ein neuer Ansatz niemals so ausgereift sein kann, wie ein Ansatz, der schon über viele Jahre am Markt gereift ist. Aus meiner Sicht ist das nichts anderes als der Wechsel von nativer auf SQL Datenbank vor fast 15 Jahren.

Die Technologie ist in dem Fall nichts anderes als der Initiator und im weiteren Verlauf auch der Katalysator für einen Umbruch in der Denk- und Arbeitsweise. MS betreibt hier Change Management natürlich ein wenig nach der Friss-oder-stirb-Methode, aber am Ende des Tages ist es nichts anderes als deren Art und Weise Veränderungen in bestehende globale Strukturen einzubringen. Und natürlich werden sich da einige am Anfang wehren, weil Veränderungen auch immer mit Unsicherheiten verbunden sind. Denn wer stürzt sich schon gerne in Unsicherheiten, wenn er gerade ein funktionierendes und lukratives Geschäftsmodell hat?!

Nichtsdestotrotz, wer MS kennt, der weiß, diese Veränderungen werden kommen. Auf die ein oder andere Weise. Daher, und da bin ich wieder bei Markus, sollte man sich jetzt damit beschäftigen, was nach aktuellem Stand die Vorgabe von MS sein wird. Nicht weil jetzt schon klar ist, dass es genauso kommen wird. Ich denke, daran werden noch viele Anpassungen stattfinden. Sondern weil die Grundausrichtung die richtige ist und diese auch nicht von MS geändert werden wird, weil sie Teil eines größeren Plans ist. Daher sind beide Überlegungen zwingend notwendig aus meiner Sicht.

• Was funktioniert in der neuen Technologie nicht im Vergleich zu dem, was ich jetzt habe, und wie sieht eine mögliche Lösung oder ein Workaround aus? Auf dieses Feedback ist MS auch einfach angewiesen, um die Technologie zu verbessern.
• Was bringt die neue Technologie an Neuerungen/Änderungen mit, die ich für mich nutzbar machen kann?