Von 'Madeira' nach 'Tenerife', NAV 2018, D365FOBE, D365BC

Der Lösungsraum wird extrem kleiner. Wie kann sowas eigentlich überhaupt das erste Meeting überleben?

Das kann folgendermaßen passieren:
Dazu muss ich ein wenig ausholen:

Als Version 0.1 von NAV entstand, wurde das System wahrscheinlich von ein paar wenigen Leuten entwickelt, die den Funktionsumfang des kompletten Systems überblickten, und auch direkt mit den - ganz wichtig - Anwendern sprachen. Die Entwickler wahren wahrscheinlich auch Leute, die die nötigen Fachkenntnisse hatten, um die Aussagen der Anwender zu beurteilen und einzuordnen (Buchhaltung,ERP,...)
Dadurch ist nur das in das System programmiert worden, was nötig war, unter der Berücksichtigung aller Eckpunkte wie Salden, Lagerwerte,... Deshalb gab es z.B. auch keine Funktion um den Lagerbestand direkt auf der Artikelkarte zu ändern, weil allen Beteiligten klar war, dass das so nicht funktioniert. (MS war in der ersten Versionen von NAV2017 anderer Meinung, und egal mit wem man gesprochen hat der schon etwas länger mit NAV arbeit, der hat sich an den Kopf gefasst )

Heute läuft das ganze so (und MS ist da nicht alleine):
Ein Anwender der die Zusammenhänge evtl. nicht kennt sagt seinem Vorgesetzten, der nur die Hälfte versteht, weil er selbst nicht damit arbeitet, dass eine Funktionalität benötigt wird, die sagen wir mal: "Der Bestand soll auf der Artikelkarte änderbar sein" heißt. Diese Funktionalität wird an den Vertriebler des Partners gemeldet, der das erst 1 Jahr macht, und auch die Zusammenhänge nicht kennt. Der Wiederum sagt es seinem Chef, der weil er sich nur mit der Orga im Haus beschäftigt, nicht im Bilde ist, warum man das in NAV nicht macht. Aber da er schon zig mal von ebenso ahnungslosen (wichtigen!?) Kunden gefragt wurde, gibt er das an MS weiter. Da bei MS aber leider auch keine Leute mehr sitzen, die ein wenig mehr Erfahrung haben, geschweige denn die Zusammenhänge verstehen, wird das an einen Programmierer weitergeben, der gerade mal weiß wie er ein Artikelbuchblatt füllt und bucht, aber nicht was er damit anrichtet.

Lange Rede kurzer Sinn:
Wir haben heute in den Unternehmen immer weniger Leute, die den Überblick über das ganze haben. Jeder wird in seinem stillen Kämmerlein gehalten. Die Programmierer haben solche Ideen, weil sie keine Ahnung vom Leben draußen beim Kunden haben, die Chefs der Programmierer haben keine Ahnung von der Programmierung, und können nicht beurteilen, was das bedeutet, was die Programmierer da vorschlagen.
Und dann kommen da noch die obersten Chefs und die Marketingabteilung, die dann auch noch Ihre Ideen verwirklicht haben wollen, aber von den Zusammenhängen auch keine Ahnung haben.
Wir haben also sehr viele Spitzenkräfte, die auf Ihrem Gebiet absolute Fachleute sind, aber niemanden, der das ganze zusammenhält, überblickt, und sagen kann, das kann man machen oder nicht.

Und am Ende kommt dann BER, Stuttgart21 oder Windows Phone dabei raus.

Gruß Fiddi

So makaber es klingen mag, aber ich muss Fiddi leider recht geben.
In meinen 20 Jahren NAV-Erfahrung habe ich leider schon sehr häufig völlig unsinnige Anforderungen gehört bzw. zur Umsetzung auf dem Schreibtisch gehabt.
Wenn der Consultant es sich dann einfach macht oder nicht die erforderliche Fachkenntnis in dem Bereich hat (z. B. ein Fibu-Consultant, der Logistik-Anforderungen vom Kundentermin mitbringt), dann wandern solche Anforderungen ungeprüft in eine Design-Specification.
Wird dann auch noch auf das 4-Augen-Prinzip verzichtet (bei dem dann wenigstens nochmal ein Entwickler drüber schaut), dann hat der Kunde diese unsinnige Specification unterschrieben bevor der Entwickler sie zu Gesicht bekommt.
Wenn der Entwickler den Blödsinn dann auf dem Tisch hat und umsetzen soll, wird er möglicherweise sein Veto einlegen.
Häufig kommt dann vom Consultant nur noch die Aussage "aber der Kunde hat das schon genau so unterschrieben und beauftragt, da können wir nichts mehr ändern."

Bei einigen Vollkatastrophen habe ich mich aber dennoch strikt geweigert und darauf verwiesen, dass ich mich strafbar machen würde, wenn ich das genau so umsetze, wie es spezifiziert wurde.
Meistens gab es dann ein Einsehen, und ich durfte direkt mit dem Kunden die Anforderung besprechen.
Leider kenne ich auch mindestens einen Fall, bei dem sich der Projektleiter dann einfach einen anderen Entwickler gesucht hat, der es dann doch einfach genau so umgesetzt hat, wie es ursprünglich spezifiziert wurde, obwohl ich schon drei alternative Lösungsvorschläge mitgeteilt hatte.

Das ist der Nachteil, wenn die Anwendung sehr komplex ist, die (wichtigen) Kunden Druck ausüben (schnell und billig muss es sein), und bei den Partnern sich keiner traut "Nein" zu sagen.

Aber Vorsicht:
Ich kenne auch einige Kunden, die stellen absichtlich bescheuerte Anforderungen, die auf den ersten Blick sinnvoll erscheinen, um damit das Projekt-Team zu testen!
Sie wollen damit herausfinden, ob die Anforderung inhaltlich auch gegengeprüft wird.
Wird die Anforderung dann ungefragt angenommen, dann darf sich der Projektleiter einige unangenehme Fragen des Kunden anhören.
Diese Kunden wirken auf den ersten Blick sehr anstrengend, aber in Wirklichkeit sind das die besten, denn sie wissen genau, was sinnvoll ist, und wo überall Fehler passieren können.
Mit diesen Kunden kann man in aller Regel auch ganz offen reden, und auch deren Anforderungen mal hinterfragen, umspezifizieren oder gar ganz ablehnen, sie sind einem dafür dann sogar noch dankbar.

Zwei typische Beispiele für moderne Softwareentwicklung

http://scottpantall.com/wp-content/uploads/2014/09/comics-software-development-485346.png

https://stevemiles70.files.wordpress.com/2008/11/software_treeswing.jpg

Gruß Fiddi

Das sind übrigens alles Gründe warum ich nicht mehr wirklich für einen Partner arbeiten wollen würde.
Ich bin Softwareentwickler aus Leidenschaft und ich liebe komplexe Probleme. Als Inhouse Consultant lebt man die Prozesse mit und kann die perfekte Lösung für das Unternehmen finden, ohne sich diesen Zeitdruck und Lösungszwang ausgesetzt zu sehen. Ich hab auch genug Zeit um meine Entwicklungen zu refactoren und empfinde diesen Punkt auch als super wichtig, denn der nächste der den Code angucken wird, werde höchstwahrscheinlich ich selbst sein.
Es fällt einem dann auch nicht so schwer "Nein" zu sagen, wenn irgend ne "witzige" Idee kommt oder es gegen die Philosophie von NAV verstößt.

Aber mal zum VSCode Thema:

Wenn dein Kunde aber z.B. beim Buchen- Knopf möchte (um Fehlerquellen zu reduzieren), dass der Default nicht "Liefern u. Fakturieren" sei, sondern nur "Liefern", oder das bestimmte Anwender nur Liefern dürfen, und nicht fakturieren, dann war das bisher nur eine kleine Änderung in CU 81 oder 91, die auch beim Merge keinen Ärger gemacht hat.

Derzeit kannst du das nur lösen in dem du CU81 kopierst, anpasst und dann deine CU beim "Buchen drücken" aufrufst.

Microsoft muss aber definitiv noch irgendwas einbauen damit komplette Funktionen überschreiben oder -sprungen werden können. Tabellenfelder kann man ja immerhin schon modifizieren.
Wenn ich allerdings eine OnValidate - Funktion einfüge wird diese Zusätzlich und nicht stattdessen ausgeführt.

Hallo,

Das mit dem Austauschen hat nur einen Haken, wenn ich nicht weiß was in der CU passiert, kann ich Sie nicht kopieren (Closed Source) und wenn ich dann noch mehrere ISV- Lösungen drin habe, und alle die gleiche Idee hatten, weil Sie noch was anderes machen wollen oder müssen, dann habe ich die sog. A..- Karte gezogen.

Manchmal frage ich mich auch, um Jens zu zitieren, wie solche Ideen die erste Sitzung der Programmierer überstanden haben. Manche Erweiterungen erfordern eben, dass Sie an einer bestimmten Stelle im Buchungsvorgang und in einer bestimmten Reihenfolge durchgeführt werden, und da kann man mit Events und Hooks nichts werden.
Einfaches Beispiel aus der Praxis: Man nehme NAV mit einer Handels- Branchenlösung, einer Zahlungsverkehr- ISV- Lösung, und einer WebShop- ISV- Lösung.

Die Webshop- Lösung kann eigentlich damit umgehen, dass die Kunden Zahlungen auf Aufträge leisten können, da Vorauszahlungsrechnungen hier einfach zu umständlich sind. Dazu hat der Webshop die Standard- Buchblätter um die Möglichkeit erweitert, bei Debitoren- Zahlungen und nur da, die Belegart Auftrag zu nutzen und als Belegnummern die Auftragsnummern zu verwenden. Der Zahlungsverkehr meint jetzt, seine Buchblätter in eigene Tabellen kopieren zu müssen. Damit der Webshop damit auch funktioniert, muss ich als Partner des End- Kunden jetzt dem Zahlungsverkehr beibringen, auch Zahlungen auf Aufträge zu verarbeiten. Das kann ich aber nur, wenn ich an den gleichen Stellen mitten im Code des ZV die gleichen Anpassungen mache wie der Webshop im Standard- NAV. Mit Extensions und Events wäre das nicht möglich, da es irgendwann so viele Events geben müsste für alle Kombinationen von ISV- Lösungen, das niemand mehr durchblickt.

Gruß Fiddi

Kleines Bonmot dazu: TAP-Programm für Madeira, ich telefonisch mit im Meeting als dieses neue Feature vorgestellt wurde. Meine erste Frage war: "Execution order for several subscribers?" "No, not determined." "What else is it good for than sending a mail?" Der Rest ist Geschichte. Microsoft hatte sehr schnell Rückmeldung das das vielleicht nicht die beste Idee ist. Ich werde nicht mehr zu solchen Meetings eingeladen...

Auch ich sehe die Entwicklung von NAV hin zu einem Cloud-Produkt kritisch.
So wie ich die Quellen verstanden habe, bekommen NAV-Partner mit Branchenlösungen weiterhin die Möglichkeit umfangreich in das System einzugreifen. Das ist gut.
Das heißt ein Partner erstellt für sich eine Standarddatenbank und für den Kunden können dann Extensions einfach dazu eingebunden werden.

Es werden hier viele Entscheidungen getroffen, welche in anderen Programmen auch getroffen werden. Bei denen interessiert es bloß weniger Leute, weil die Anpassungsfähigkeit nicht gegeben ist.
Man kann nur hoffen, dass (so wie beim RTC und Office 2007) Microsoft Recht behält und es wirklich ein gute Lösung ist.

P.S. Wer das Projekt Redmine kennt, dem ist die Logik, welche Microsoft verfolgt nicht neu. Auch da kann ich Plugins schreiben, welche umfangreiche Änderungen haben können.
Bestimmte Änderungen können trotzdem auch im Quelltext gemacht werden. Diese sind aber nach einem Standard Update wieder weg.

wenn ich nicht weiß was in der CU passiert, kann ich Sie nicht kopieren (Closed Source)

So ein Add-On haben wir auch in unserer NAV 2017 Datenbank.
Schaut man in die Codeunit rein, sieht man zwar ganz viele Funktionen, deren Namen sind aber verschlüsselt, und der Programmcode ist durch "Protected" ersetzt.
Wenn ich in dieser Codeunit jetzt eine Funktion kopieren müsste, um die Funktionalität auch in die zusätzlichen Tabellen der von uns eingesetzten Branchenlösung zu implementieren, dann habe weder ich, noch unser Partner eine Möglichkeit.

wenn ich dann noch mehrere ISV- Lösungen drin habe, und alle die gleiche Idee hatten, weil Sie noch was anderes machen wollen oder müssen,

"Kleines" Beispiel aus der Praxis:
In unserer NAV 2017 Datenbank treffen 17 (in Worten: "siebzehn") ISV-Lösungen aufeinander.
Eine Branchenlösung und 16 Add-Ons, dessen Funktionalität natürlich auch in den Objekten der Branchenlösung zur Verfügung stehen muss.
Einige (Standard-)Objekte sind von 6 oder mehr Add-Ons angepasst worden.
Und dann kommen wir natürlich noch mit unseren Individualanpassungen oben drauf.

In diesem Video wird gesagt: Aus Dynamics NAV wird Dynamics 365

https://www.youtube.com/watch?v=sZhMNGWD0oU&t=4s

So ein Add-On haben wir auch in unserer NAV 2017 Datenbank.
Schaut man in die Codeunit rein, sieht man zwar ganz viele Funktionen, deren Namen sind aber verschlüsselt, und der Programmcode ist durch "Protected" ersetzt.

Das mit dem Protected gab es ja auch schon im CC, da konnte man das auch machen.

Wenn der Anbieter des Addons dann keine Lust mehr hat, oder Pleite ist, kommst du u.U. nicht mal mehr an die Daten des Addons, weil auch die in irgendwelchen obskuren Tabellen verschwinden. Was nützt es dir, wenn du das Addon einfach deinstallieren kannst. Wenn deine Branchenlösung darauf zugreift, oder gar noch steuerlich/Zoll- relevante Daten enthalten sind, bekommst du u.U. richtig Probleme.

Gruß Fiddi

So ein Add-On haben wir auch in unserer NAV 2017 Datenbank.

Was passiert denn, wenn du das Debugst?

Gruß Fiddi

Wenn der Anbieter des Addons dann keine Lust mehr hat, oder Pleite ist, kommst du u.U. nicht mal mehr an die Daten des Addons, weil auch die in irgendwelchen obskuren Tabellen verschwinden.

In unserem konkreten Fall ist das jetzt kein Problem, da das Addon keine relevanten Daten in eigenen Tabellen speichert, sondern nur Konfigurations-Informationen in seinen eigenen Tabellen vorhält.
Die dadurch gesteuerten Daten landen ausschließlich in den Standard-Tabellen bzw. den Tabellen, die wir dort eingetragen haben.
Und wenn der Anbieter mal insolvent sein sollte, so funktioniert das NAV-AddOn ja noch weiter, nur gäbe es dann keine Updates und keinen Support mehr.

Was passiert denn, wenn du das Debugst?

Das sieht dann genauso kryptisch aus wie im C/AL-Editor.

Und wenn der Anbieter mal insolvent sein sollte, so funktioniert das NAV-AddOn ja noch weiter, nur gäbe es dann keine Updates und keinen Support mehr.

Was mach ein Cloud- Anwender, bei dem MS ein Update gemacht hat in dem Fall?

Gruß Fiddi

Und wenn der Anbieter mal insolvent sein sollte, so funktioniert das NAV-AddOn ja noch weiter, nur gäbe es dann keine Updates und keinen Support mehr.

Was mach ein Cloud- Anwender, bei dem MS ein Update gemacht hat in dem Fall?

Gute Frage!
Wenn die Apps/AddOns/Extensions weiterhin in der Cloud verbleiben (und nur keine Updates mehr erhalten), können sie doch hoffentlich noch solange verwendet werden, bis sie nicht mehr kompatibel sind.
Aber sollte zufällig mit dem nächsten auf die Insolvenz folgenden Cumulative Update das AddOn nicht mehr kompatibel sein, dann sehe ich hier sehr wohl ein großes Problem.

Man denke einfach an die zahlreichen Firefox-AddOns, welche plötzlich mit einem Update von FF deaktiviert werden, weil sie nicht zur aktuellen Version kompatibel sind.
Gibt es dann kein Update für das AddOn, dann ist "Schicht im Schacht".

Wenn die Apps/AddOns/Extensions weiterhin in der Cloud verbleiben (und nur keine Updates mehr erhalten), können sie doch hoffentlich noch solange verwendet werden, bis sie nicht mehr kompatibel sind.

Hier stellt sich für mich die Frage, wie sich das mit cfmd-zertifizierten AddOns verhält, wenn diese Zertifizierung erneuert werden sollte, was dann ja aber keiner mehr tut, wenn es den Anbieter nicht mehr gibt. Dann fliegt das AddOn irgendwann aus der Lizenz?

Man denke einfach an die zahlreichen Firefox-AddOns, welche plötzlich mit einem Update von FF deaktiviert werden, weil sie nicht zur aktuellen Version kompatibel sind.
Gibt es dann kein Update für das AddOn, dann ist "Schicht im Schacht".

Das haben wir doch gerade bei NAV: Es wird in Zukunft nur noch Extension V2 akzeptiert. In wieweit alte Extensions dann noch weiter verwendet werden dürfen/können!??

Gruß Fiddi

Das haben wir doch gerade bei NAV: Es wird in Zukunft nur noch Extension V2 akzeptiert. In wieweit alte Extensions dann noch weiter verwendet werden dürfen/können!??...

Hier steht was anderes.

Standard Solution

Microsoft Dynamics 365 is the standard business edition. It is updated regularly by Microsoft and you can add apps developed by Microsoft or its partners from AppSource.
In Dynamics 365 you can see which apps are available on AppSource and you can choose to install or remove apps depending on your needs.
These apps are developed as extension which means that they do not change the source code in Dynamics 365.

Industry Solution

Industry solutions, such as the TRIMIT solution for fashion, furniture and manufacturing, are developed by Microsoft partners.
Microsoft wants partners to continue the development of industry solutions. It can be challenging for a partner to move its old industry solution to extension in Dynamics 365. Microsoft recognizes that it will take some time and therefore gives the partners the opportunity to move their industry solutions to Dynamics 365 without using extensions. This way, the partners will get a separate area in Dynamics 365 where they can add their code.
As a customer, you get a proven industry solution and the benefits from the new Microsoft Dynamics 365. But the solution cannot automatically be updated by Microsoft. The partner is responsible for the updates. And you cannot install apps from AppSource until the partner has tested that they work with your industry solution.

Hallo,

Frage ist, wie alt ist die Aussage?

Mein Kenntnisstand ist, das zumindest neue Apps im Appstore nur noch als Extension V2 (ab Frühjahr 2018!?) akzeptiert werden. In wieweit dann noch alte Apps installiert und benutzt werden können, weiß ich nicht.

Gruß Fiddi

@fiddi:

Lange Rede kurzer Sinn:

...aber niemanden, der das ganze zusammenhält, überblickt, und sagen kann, das kann man machen oder nicht.

Soeben erschien mir die Abkürzung F355.

.....

DANKE für diese Worte, das vergoldet mir das Wochenende.

Mein Kenntnisstand ist, das zumindest neue Apps im Appstore nur noch als Extension V2 (ab Frühjahr 2018!?) akzeptiert werden.

Meiner auch, Extensions V1 sind nur noch bei Ende des Monats zugelassen (Aussage MS).

Ein spezieller "How Do I"-Artikel von Marije Brummel.
How Do I – Move Away from NAV (Artikel wurde später wieder gelöscht)

Die Browser updaten sich allerdings auch ständig (meist wegen Sicherheitslücken), und das kann auch dazu führen, dass im Zusammenspiel mit NAV auf einmal Probleme da sind, die vorher nicht vorhanden waren.

Dazu ein aktuelles Beispiel hier:
https://twitter.com/TobiasFenster/statu ... 0186659840

Die NAV 2018 DK-Version enthält eine Besonderheit. Es ist die erste Länderversion, bei der MS die vormals konventionell programmierte Localization bis NAV 2017 nun teilweise über Extensions umgesetzt hat.

NAV2018DKext.png

In der DE-Version aktuell noch nichts derartiges in Sicht, dürfte aber wohl nicht lange auf sich warten lassen.

Extensions2018DE.png

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

In der DE-Version aktuell noch nichts derartiges in Sicht, dürfte aber wohl nicht lange auf sich warten lassen.

Bei MS wird angedacht, ELSTER zukünftig als Extension abzubilden. Wer dabei mitdiskutieren möchte, damit eine unserer lokalen Sonderlocken gut abgebildet wird, ist hierzu eingeladen:
https://www.yammer.com/dynamicsnavdev/# ... =999985958
Die Gruppe dazu:
DE: Electronic Submission of Sales VAT Advance Notifications to ELSTER

[Edit 15.01.18]
Abstimmung, ob es reicht, wenn die XML-Datei manuell hochgeladen werden würde (keine automatische Übertragung)
https://www.yammer.com/dynamicsnavdev/# ... 1006767779

Grundlagen
How to report VAT

Hallo,

gibt es bei den Extensions eigentlich die Möglichkeit Objekte zu kopieren und die daran hängenden Extensions mit zu nehmen?

Beispiel: Man benötigt eine spezielle Page für die Auftragserfassung (z.B. Kasse), die man mit der normale Page nicht hin bekommt, aber man benötigt eine Extension, die z.B. ein EC- Terminal anbindet?

Wie mache ich das eigentlich bei einem Merge, wenn das System im wesentlichen auf Extensions beruht. Wie bekomme ich mit welche Objekte sich geändert haben, und wo ich eingreifen muss, damit das ganze noch zusammenspielt?

Gruß Fiddi