[gelöst]RTC RDL und NAV7

[rainergaiss]

Diese Frage richtet sich an alle, die schon NAV7-Luft schnuppern durften:

Wir haben einige Kunden, die zur Zeit auf RTC upgraden (wollen). Gerade mit dem Report Design gehen wir durch alle Höhen und (vor allem) Tiefen. Nun ist es ja, wie man hört, so, dass in NAV 7 die Mehrzahl der Unzulänglichkeiten wohl behoben sein wird. Wird mir das als 2009-Nutzer eigentlich auch etwas bringen, d.h. kann ich die neuen Möglichkeiten dann auch noch irgendwie in 2009 nutzen? Ich mache doch jetzt keinen Upgrade auf 2009 und programmier mir dabei einen Wolf, wenn ich das alles in NAV7 viel einfacher haben kann. Andererseits werde ich nicht auf NAV7 upgraden, wenn ich gerade erst auf 2009 "upgegradet" habe. Also werde ich wohl oder übel, wenn ich auf 2009 bleibe, zumindest mit den Belegen auf dem CC bleiben, was dann wiederum eine Super-Krampflösung ist.

Mein Wunsch wäre eigentlich nur ein ganz einfacher Übergang.

Gibt es den?

Zuletzt geändert von rainergaiss am 13. Februar 2012 12:18, insgesamt 1-mal geändert.

d.h. kann ich die neuen Möglichkeiten dann auch noch irgendwie in 2009 nutzen?

Meines Wissens nach nicht.
Diese neuen Funktionalitäten rühren nicht auf dem NAV-Update, sondern einem Update der RDLC-Umgebung (von 2008 auf 2010). Und NAV 2009 ist für Report Layout 2010 nicht kompatibel. Es sei denn, in ferner Zukunft gibts ein technisches Update für 2009 ...

Heißt das, wir haben mal wieder die berühmte A....-Karte?

Viele Grüße

Rainer

Heißt das, wir haben mal wieder die berühmte A....-Karte?

Hellsehen kann ich nicht, und bei MS arbeiten tu ich auch nicht
Letzlich ist aber das RDLC-Reportdesign nur Übungssache. Wenn man erst einmal Routine hat, geht es eigentlich - vielleicht nicht das, was du hören wolltest

Heißt das, wir haben mal wieder die berühmte A....-Karte?

Hellsehen kann ich nicht, und bei MS arbeiten tu ich auch nicht
Letzlich ist aber das RDLC-Reportdesign nur Übungssache. Wenn man erst einmal Routine hat, geht es eigentlich - vielleicht nicht das, was du hören wolltest

Ist RDLC nicht dieselbe Sprache, die MS beim SQL-Server für dei SSRS verwendet? Der SQL-Server hat doch auch Reports, die aber in Visual Studio programmiert werden?

Ausschließen kann man nichts. Aber es ist ein Spiel der Wahrscheinlichkeiten, Anforderungen des Marktes und wie einfach sich ein Feature quasi aus dem aktuellen Entwicklungsstrang herauslösen lässt, Stichwort: PDF im Druckdialog. Dieses Feature ist eine Rückportierung von NAV "7".

In NAV "7" gibt es kein Classic Layout (als Datenquelle für RDLC), sondern nur die nackten Datenfelder, einen komplett anderen Report Designer und andere Strukturen, obendrein, wie Natalie schon schrieb, basierend auf RDLC 2008 (VS 2010) im Gegensatz zu RDLC 2005 unter NAV 2009. Die Wahrscheinlichkeit ist aus jetziger Sicht mehr als gering.

@freestyler: RDLC und RDL sind übrigens zwei verschiedene Paar Schuhe. RDL verantwortet das SQL Server Team, RDLC (C = Client) das Visual Studio Team.

Aber weiter im Text: Upgrade-Pfade (Applikation) sind, soweit ich mich erinnere, nur von NAV 2009 (SP1) auf NAV "7", 2009 Hybrid Reports sollen zu einem hohen 90er-Prozentsatz 1:1 automatisch transformiert werden.

Und nun zu einer meiner Lieblingssprachen: Tacheles. Deshalb möchte ich eben zu dieser Sprache wechseln:

Der "Übergang" war mit erscheinen von NAV "7" dann fast 4! Jahre lang, wenn ich nur SP1 zähle, dann 3. Es ist sicherlich nicht alles einfach und es bestehen teilweise Unterschiede, verglichen mit den Classic Features, keine Frage. Sich neue Technologien anzueignen, sich in den Classic-Produkt-Stack einzuleben und diesen (mit) zu nuzten war eines der Ziele dieses Übergangs. Das Ziel, speziell der Hybrid-Reports, WAR der Übergang! Damit parallel Classic und RTC zu unterstützen um dann "ganz einfach" über den genannten Upgrade-Pfad, auf "7" zu kommen.

Wie Natalie bestätigen kann, und auch ich aus eigener Erfahrung weiß, ist es ein Herangehen, Lernen und Machen. Lernen das "unabwendliche Neue" zu nutzen. Ist in 3 Jahren zu schaffen. Wer bis jetzt noch keine oder wenig Erfahrungen mit dem RTC, Pages und RDLC-Reports hat, wird es, später und auch jetzt schon, mehr als schwer haben.

Cheers
Carsten

P.S.: This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft or its employees.

Eine Ergänzung vielleicht noch. Soweit ich weiß, korrigiert mich, wenn ich was falsches sage, gibt es in NAV 7 keine klassischen Forms und Reports und somit auch keine Form- und Report-Transformation mehr. D.h., wenn man seine Forms und Reports nicht neu gestalten, sondern "in etwa" übernehmen möchte, bleibt einem gar keine andere Wahl, als über 2009 die Transformation durchzuführen und dann mit NAV 7 von RDL Pre-VS2010 auf das RDL VS2010 Format zu konvertieren. Oder man macht jeden Report von Grund auf neu direkt im RDLC VS2010.

Das ist sicherlich für jeden Kunden individuell an einer Kosten-/Nutzenanalyse und dessen persönlichen Neigungen und Vorstellungen zu entscheiden. Ist aber definitiv kein einfaches Thema.

Eine Ergänzung vielleicht noch. Soweit ich weiß, korrigiert mich, wenn ich was falsches sage, gibt es in NAV 7 keine klassischen Forms und Reports und somit auch keine Form- und Report-Transformation mehr. D.h., wenn man seine Forms und Reports nicht neu gestalten, sondern "in etwa" übernehmen möchte, bleibt einem gar keine andere Wahl, als über 2009 die Transformation durchzuführen und dann mit NAV 7 von RDL Pre-VS2010 auf das RDL VS2010 Format zu konvertieren. Oder man macht jeden Report von Grund auf neu direkt im RDLC VS2010.

Meiner Meinung und Erfahrung nach ist es zu empfehlen seine Datenbank jetzt auf 2009 R2 zu bringen, wenn man zeitnah nach dem Release von 7 updaten möchte.
Durch den Hybridbetrieb von Form/Page und CC/RTC-Reports hat man jetzt die Möglichkeit fliessend alles was nicht Standard ist auf den neuen Stand der Technik zu bringen.
Die Boardmittel von NAV7 helfen dann dabei mit möglichst wenig Zusatzaufwand die "2009-RTC Objekte" für NAV7 zu konvertieren.
Wer versucht von einer Version vor 2009, oder einer 2009-Installation mit reinen CC-Reports seine Individualprogrammierung in eine NAV7-Umgebung zu bringen wird sich schwer tun.

Hallo Carsten,

deine Antwort in Ehren und im Großen und Ganzen auch durchaus meine Zustimmung. Leider ist sie nicht die Antwort auf meine Frage. Die geht schlicht und einfach dahin, ob es möglich sein wird, die kommenden Features, die den RDLC erst zu einem sinnvollen Werkzeug machen, so rückwärts zu implementieren, dass man dann wieder einen vernünftigen Upgrade-Pfad hat.

Und auch zu dem Thema "alte und neue Technologien" habe ich meine eigenen Gedanken. Es gibt durchaus Kunden, auch neue ohne NAV-Background, die sich noch heute bewusst und vorbehaltlos für den Classic Client entscheiden, weil sie ihn einfach für sich selbst als angenehm empfinden. Und bei den ganzen Diskussionen wird völlig außer Acht gelassen, dass es bei NAV in erster Linie um die Anwendung geht und es eigentlich völlig egal ist, wie die Sachen dargestellt werden.

Was die Entwicklungsseite betrifft, da erinnere ich mich an Forumseinträge zu Zeiten der Jahrhundertwende, wo sich Microsoft-Entwickler schon beschwerten, dass sie sich bei ihrer Tätigkeit statt durch Handbücher und andere Dokumentation durch Whitepaper und sonstige "Fresszettel" wühlen mussten, um ihre Probleme lösen zu können. Und ich denke, dahin führt uns der Weg mittlerweile auch bei der NAV-Entwicklung. Bisher war die "Entwicklungsumgebung" zwar komplex aber gut beherrschbar. Nun erfolgt eine Öffnung, aber nur gegenüber anderen Microsoft-Produkten, und ich denke, das ganze einzig mit dem Ziel, die Kunden verstärkt an MS zu binden und nicht, eine in der Sache, sprich ERP, bessere Version zu bieten.

Es ist auch fast nicht zu stemmen, alle Mitarbeiter eines NAV-Partners innerhalb von 3 Jahren auf den auf Faktor 10 angewachsenen Wissensbedarf zu heben, was Dank entsprechender fehlender Dokumentation auch nicht autodidaktisch erreicht werden kann, und andere Ausbildungsmöglichkeiten gibt es ja auch kaum, zumindest habe ich keine entdeckt, außer den gelegentlichen Webcasts vielleicht. Dazu kommt, dass den vielen programmierenden Betriebswirtschaftlern so langsam der Boden entzogen wird, denn die hatten das Glück, dass ihnen Dinge wie .net und Ähnliches bisher am Allerwertesten vorbeigehen konnten. Überspitzt ausgedrückt entwickelt sich alles hin zu einem Produkt für Freaks und Nerds, die gewohnt sind, sich ihre Informationen aus Blogs und Foren zusammenzusuchen. Leider ist das auch nicht so richtig produktiv. Nicht umsonst wurde bei einem kürzlichen Vergleichstest NAV wegen fehlender Dolumentation abgewertet.

Bitte verstehe das hier nicht falsch, ich spreche hier weniger für mich, aber für viele meiner Kollegen, die sich nicht in Foren austauschen und die es eben nicht verstehen, dass sie ihre Vorgehensweise von logisch auf "try-and-error" umstellen müssen.

Gruß Rainer

was Dank entsprechender fehlender Dokumentation auch nicht autodidaktisch erreicht werden kann

Was genau an Doku fehlt dir denn? Es gibt sehr viele Schulungsunterlagen und White Paper zum Thema RTC, auch Upgrade und Reporting. Hast du die bereits in deiner Aussage berücksichtigt?

(1) ... und andere Ausbildungsmöglichkeiten gibt es ja auch kaum...
(2) ... vielen programmierenden Betriebswirtschaftlern so langsam der Boden entzogen wird.
(3) .... Produkt für Freaks und Nerds, die gewohnt sind, sich ihre Informationen aus Blogs und Foren zusammenzusuchen.

Gruß Rainer

Insgesamt stimme ich dir schon zu, aber in einigen Punkten muss ich etwas ergänzen:

(1) Impuls hat entsprechende Schulungsangebote:
http://www.impuls-academy.de/Descriptio ... ID=VS-1003

(2) Daher lasse z.B. ich als Consultant seit dem RTC die Finger von der Programmierung und lasse die echten Entwickler programmieren.

(3) Ähm, ersetze Freaks und Nerds mit jungen Diplom-Informatikern, welche an der BA, FH oder Uni Visual Studio, .NET, C# und SQL-Server hatten sowie idealerweise als Entwickler ausserhalb der NAV-Welt entsprechende Berufserfahrung sammeln konnten. Die sind es gewohnt in Blogs und Whitepapers zu stöbern. An einer Hochschule wird einem nix vorgekaut, da muss man sich ja auch durchbeissen und Wissen aus zig verschiedenen Quellen sammeln. Insgesamt steigen damit zwar vielleicht in Zukunft die Einstiegsgehälter für in .NET erfahrene NAV-Programmierer, aber diese Entwicklung lässt sich nunmal nicht umkehren.

...und ich denke, das ganze einzig mit dem Ziel, die Kunden verstärkt an MS zu binden ...

Naja, das denke ich nicht. Die Integration zu anderen MS-Produkten war ja schon vorher gegeben. Allerdings verbessert MS so die Art der Integration. Und ich denke, als Langzeitziel könnte eine Vereinheitlichung des ERP-Portfolios von MS anstehen, denn CRM, AX und GP schlagen in dieselbe Kerbe. Man hätte mit einem großen Produkt auf einmal seine Marktanteile gebündelt und könnte so den großen, ungeliebten und widerspenstigen Konkurrenten aus Walldorf besser bedrängen.

Es ist auch fast nicht zu stemmen, alle Mitarbeiter eines NAV-Partners innerhalb von 3 Jahren auf den auf Faktor 10 angewachsenen Wissensbedarf zu heben, was Dank entsprechender fehlender Dokumentation auch nicht autodidaktisch erreicht werden kann, und andere Ausbildungsmöglichkeiten gibt es ja auch kaum, zumindest habe ich keine entdeckt, außer den gelegentlichen Webcasts vielleicht. Dazu kommt, dass den vielen programmierenden Betriebswirtschaftlern so langsam der Boden entzogen wird, denn die hatten das Glück, dass ihnen Dinge wie .net und Ähnliches bisher am Allerwertesten vorbeigehen konnten.

Diese Probleme sehe ich allerdings auch. Besonders der Punkt, daß man im bisherigen NAV-Umfeld im eigentlichen Sinne kein Programmierer sein mußte, um Lösungen zu entwickeln, fand ich immer recht smart. Viele Lösungen ergaben sich auch schon aus einem guten (betriebswirtschaftlichen) Verständnis der Business Logic. Das wird in Zukunft auch nicht wegfallen, nur wenn Programmieraufwand zwingend erforderlich ist, dann werden einige nicht mehr ohne Programmierer können. Das ist doch eigentlich nicht schlecht. Es entstehen (evtl.) mehr Stellen, die Teamarbeit wird gefördert, man muß einfach mehr mit einander sprechen und die verschiedenen Sichtweisen einander erklären... nur teurer wird es auch für den Kunden.

Überspitzt ausgedrückt entwickelt sich alles hin zu einem Produkt für Freaks und Nerds, die gewohnt sind, sich ihre Informationen aus Blogs und Foren zusammenzusuchen.

Ich weiß nicht, warum man gleich ein "Freak" oder "Nerd" sein soll, nur weil man sich die Informationen selbst zusammensuchen muß?! Ich nenne das eigenverantwortliches und selbständiges Arbeiten. Sicherlich ist es noch eine andere Frage, wie die Informationen aufbereitet sind und ob sie dann auch von einem Nicht-Programmierer/-Techniker verstanden werden können, aber das steht ja auf einem anderen Blatt.

Bitte verstehe das hier nicht falsch, ich spreche hier weniger für mich, aber für viele meiner Kollegen, die sich nicht in Foren austauschen und die es eben nicht verstehen, dass sie ihre Vorgehensweise von logisch auf "try-and-error" umstellen müssen.

Das war früher in den Anfangszeiten von NAV nicht anders. Und genau wie früher wird es hier nach und nach besser werden. Man kann doch nicht erwarten, daß einem bei so einer massiven Umstellung alles bis ins Haarkleinste vorgekaut wird. Das kann weder MS leisten noch irgendeine andere Firma auf dieser Welt, denn viele Probleme ergeben sich ja gerade erst aus der Praxis. Das ist aber nichts anderes, wenn z.B. eine neue Maschine aufgestellt wird oder ein neues Gesetz verabschiedet wird.

@Natalie:
Gute Frage - welche Doku gibt es denn überhaupt? Und woher weiß ich, welche es gibt? Ich will ja nicht ausschließen, dass wir, aus welchen Gründen auch immer, irgendwie von diesen Informationen "abgehängt" sind.

@Freestyler:
zu 1: Vielen Dank für die Info!

zu 2: Wenn du die Möglichkeiten hast - gratuliere! Bei kleineren Partnern ist das sicher nicht so einfach möglich.

zu 3: Da fehlt dann doch häufig dafür der Praxisbezug. Es kann doch auch nicht das Ziel sein, die erfahrenen Leute rauszukegeln, nur weil sie vielleicht eine andere Didaktik bevorzugen. Außerdem ist der Markt zur Zeit dermaßen leergefegt, dass ALLE gebraucht werden. Außerdem muss die Ausbildung jetzt a) kurzfristig und b) auf breiter Front erfolgen, da sonst die, die in der "neuen Welt" schon angekommen sind, zu horrenden Preisen von den anderen Systemhäusern rausgekauft werden. Ich habe das vorhin bewusst überspitzt formuliert. Aber zu sagen, ich lasse die alten die vorhandenen Projekte fertigmachen und für die neuen Sachen stelle ich dann neue ein, das ist wenig nachhaltig und zeugt von einer gewissen Wegwerfmentalität. Soweit sollte es nicht kommen.

Gruß Rainer

@Natalie:
Gute Frage - welche Doku gibt es denn überhaupt? Und woher weiß ich, welche es gibt? Ich will ja nicht ausschließen, dass wir, aus welchen Gründen auch immer, irgendwie von diesen Informationen "abgehängt" sind.

Siehe Partnersource-Linkliste, Stichwort "Training":
https://mbs.microsoft.com/partnersource ... av2009.htm
https://mbs.microsoft.com/partnersource ... epaper.htm

Die Download-Berechtigung der Trainingsunterlagen erhält man allerdings nicht automatisch; wie die Bedingungen genau lauten, weiß ich allerdings nicht.
Im Fall der Fälle wendet euch bitte euren Partnerbetreuer von MS.

Vielen Dank! Hat geklappt!

Es kann doch auch nicht das Ziel sein, die erfahrenen Leute rauszukegeln, nur weil sie vielleicht eine andere Didaktik bevorzugen. Außerdem ist der Markt zur Zeit dermaßen leergefegt, dass ALLE gebraucht werden. Außerdem muss die Ausbildung jetzt a) kurzfristig und b) auf breiter Front erfolgen, da sonst die, die in der "neuen Welt" schon angekommen sind, zu horrenden Preisen von den anderen Systemhäusern rausgekauft werden. Ich habe das vorhin bewusst überspitzt formuliert. Aber zu sagen, ich lasse die alten die vorhandenen Projekte fertigmachen und für die neuen Sachen stelle ich dann neue ein, das ist wenig nachhaltig und zeugt von einer gewissen Wegwerfmentalität. Soweit sollte es nicht kommen.

Ich sehe es eher genau andersherum. Man wird in Zukunft nicht mehr auf die "alten Hasen" verzichten können. Denn was weiß denn schon ein reiner .NET-Entwickler von Business Logic? Deshalb, es wird das A und O in Zukunft sein miteinander zu kommunizieren. Und bei diesen ganzen Diskussionen wird der .NET-Entwickler langsam nach und nach mehr von der Welt der ERP-Systeme verstehen und der ERP-Consultant mehr und mehr von der .NET-Welt. Also, ich freue mich auf diese spannende Entwicklung.

(2) ... vielen programmierenden Betriebswirtschaftlern so langsam der Boden entzogen wird.

(2) Daher lasse z.B. ich als Consultant seit dem RTC die Finger von der Programmierung und lasse die echten Entwickler programmieren.
..

zu 2: Wenn du die Möglichkeiten hast - gratuliere! Bei kleineren Partnern ist das sicher nicht so einfach möglich.

@rainergaiss
wobei ich der Meinung bin, dass auch bei kleineren Partnern die Aufgaben strenger getrennt werden müssen. Ich weiß allerdings aus eigener Erfahrung, dass das nicht immer möglich ist.
Aber ich denke auch das gerade durch die "programmierenden Betriebswirtschaftler" viele technisch anspruchsvolle Lösungen in die Hose gehen und der Gesamtaufwand eher größer als geringer wird.

Daher lasse z.B. ich als Consultant seit dem RTC die Finger von der Programmierung und lasse die echten Entwickler programmieren.

Vorbildlich!

zu 2: Wenn du die Möglichkeiten hast - gratuliere! Bei kleineren Partnern ist das sicher nicht so einfach möglich.

Muss aber so sein. Man kann doch nicht jemanden im Quellcode eines Programms rumfuhrwerken lassen, nur weil es so einfach aussieht. Auch wenn die NAV-Entwicklungsumgebung einfach gestrickt und bedienbar ist: was manche da so verzapfen ist einfach nicht in Ordnung. Jeder schimpft über den Handwerker, wenn er gepfuscht hat, aber wenn mal wieder ein programmierunausgebildeter Consultant rumgepfuscht hat, sagt man einfach: fehlerfreie Software gibt es nicht.

zu 3: Da fehlt dann doch häufig dafür der Praxisbezug. Es kann doch auch nicht das Ziel sein, die erfahrenen Leute rauszukegeln, nur weil sie vielleicht eine andere Didaktik bevorzugen. Außerdem ist der Markt zur Zeit dermaßen leergefegt, dass ALLE gebraucht werden. Außerdem muss die Ausbildung jetzt a) kurzfristig und b) auf breiter Front erfolgen, da sonst die, die in der "neuen Welt" schon angekommen sind, zu horrenden Preisen von den anderen Systemhäusern rausgekauft werden. Ich habe das vorhin bewusst überspitzt formuliert. Aber zu sagen, ich lasse die alten die vorhandenen Projekte fertigmachen und für die neuen Sachen stelle ich dann neue ein, das ist wenig nachhaltig und zeugt von einer gewissen Wegwerfmentalität. Soweit sollte es nicht kommen.

Das Problem ist aus meiner Sicht nicht die Didaktik. Dass ältere Kollegen in diesem Geschäft in der Regel Quereinsteiger sind, liegt in der Natur der Sache. Ich als ausgebildeter Informatiker habe mir in der Ausbildung viel mehr Wissen angeeignet, als für das eigentliche Programmieren von NAV notwendig ist. Trotzdem sind offensichtlich viele der "älteren" der Meinung, dass sie ja viel mehr Erfahrung haben, obwohl dem oft einfach nicht so ist (meist wissen sie nur wie man es früher gemacht hat). Man kann doch seine Augen nicht vor Trends verschließen, nur weil man das vor 20 Jahren eben noch anders gemacht hat.

Ich freue mich jedenfalls auf noch mehr Möglichkeiten und Anspruch der Programmierung und vor allem, dass da hoffentlich nicht mehr jeder drin rumpfuscht. Zusätzlich wünsche ich mir, dass die Struktur der Datenbank nur noch von Leuten mit Verständnis (sprich Ausbildung für Datenbankdesign) vorgenommen werden können.

Macht es das teurer? Für mich kein Unterschied, ob der Kunde den Aufwand vorher für besser Software oder nachher für Fehlerbehebung bezahlt.

Hallo Rainer,

viele der Punkte sind bereits (mehrfach) aufgegriffen worden und es hat sich eine sehr gute, in meinen Augen wirklich tolle Diskussion etwickelt. Ich bin gespannt wie es weiter geht

Wozu noch nicht so viel gesagt wurde:

Leider ist sie nicht die Antwort auf meine Frage. Die geht schlicht und einfach dahin, ob es möglich sein wird, die kommenden Features, die den RDLC erst zu einem sinnvollen Werkzeug machen, so rückwärts zu implementieren, dass man dann wieder einen vernünftigen Upgrade-Pfad hat.

Als Anwender des Server/Client und der Entwicklungsumgebung (und Entwickler der Applikation innerhalb der Umgebung), wird es nicht ohne eine Neuimplementierung der Features in NAV 2009 SP1 funktionieren. Und das halte ich persönlich für mehr als fraglich. Deshalb mein Tipp dazu: Nein, wird es nicht geben!

Es gibt durchaus Kunden, auch neue ohne NAV-Background, die sich noch heute bewusst und vorbehaltlos für den Classic Client entscheiden, weil sie ihn einfach für sich selbst als angenehm empfinden. Und bei den ganzen Diskussionen wird völlig außer Acht gelassen, dass es bei NAV in erster Linie um die Anwendung geht und es eigentlich völlig egal ist, wie die Sachen dargestellt werden.

Nun, wir werden uns den Neuentwicklungen nur in kleinem Rahmen entziehen können. Der Weg hin zum RTC, verschiedenen anderen Endgeräten (Browser für Web Client, SharePoint), Unicode (definitiv mehr als überfällig), die Cloud, Diensten in der Wolke, RTC over WAN, Web Services, Datendienste, ... ist nicht aufzuhalten. Welche Möglichkeiten hier bestehen, auch nicht Microsoft-Produkte zu integrieren, kann denke ich jeder sich an wenigen Fingern abzählen.
Die Zeiten der alten Architektur sind definitiv gezählt, da ohne eine Reprogrammierung wie mit dem RTC irgendwann Schluss wäre mit der Weiterentwicklung. Sicherlich im kleinen Rahmen möglich (siehe Stylesheets, Senden an...), aber nicht so, wie man sich das heute vorstellt.

Bitte verstehe das hier nicht falsch, ich spreche hier weniger für mich, aber für viele meiner Kollegen, die sich nicht in Foren austauschen und die es eben nicht verstehen, dass sie ihre Vorgehensweise von logisch auf "try-and-error" umstellen müssen.

Nunja, Try and error ist vielleicht nicht ganz korrekt. Wir sind uns bewusst, dass nicht alles aktuell so läuft wie es sollte. Auch die Dokumentation könnte an einigen Stellen besser sein. Aber das ist ja der Grund, warum wir die Experten sind, es trotzdem zu wissen.
Ich denke aber, dass nicht wir als Microsoft hier in der Kommunikation etwas verändert haben, sondern wir uns nur dem allgemeinen Tenor anschließen. Die Art der Kommunikation, die Art zu Dokumentieren und miteinander "zu sprechen" hat sich in den letzten Jahren entwickelt, dass nicht immer alles rund um Dynamics NAV in der Partner Source zu finden ist, sondern auch bing und google hier die Anlaufstellen sind, wenn man nicht die verschiedenen Blogs und Foren direkt beobachtet.

Eines möchte ich in dem Zusammenhang noch los werden: Manchmal steht man (mich ebenfalls eingeschlossen!) sich vielleicht selbst im Weg, wenn es um bestimmte Fragen geht. "Wie funktioniert Kerberos mit Navision?" oder "Wie kann ich Daten aus Dynamics NAV im SharePoint Server anzeigen?". Sein wir mal ehrlich: Müssen diese Fragen wirklich so lauten oder eher "Wie funktioniert Kerberos bzw. wie funktioniert es in einer mehrschichtigen Umgebung?" und auch "Welche Datenquellen kann der SharePoint Server einbinden? -> Wie binde ich Daten in SharePoint unter Nutzung von Web Services ein?". Nichts davon hat direkt mit unserem geliebten ERP-Produkt zu tun...

Und, nur um das hervorzuheben: Wir hier bekommen auch nicht alle neuen Informationen/Features auf dem Tablett serviert. Wir müssen dafür auch arbeiten

Hallo Tim,

du widersprichst dir doch selbst. Die meisten Älteren sind für dich Quereinsteiger, dann wollen sie es plötzlich wie vor 20 Jahren machen - was denn nun?

Ich habe eine Ausbildung, die sowohl die IT als auch die Betriebswirtschaft abdeckt. Ersteres hat sich natürlich im Laufe der Zeit stark verändert, letzteres nicht so. Mit den Entwicklungen hielt ich bislang immer Schritt, da ich bis Anfang der 2000er überwiegend im Bereich Betriebssysteme Entwicklung und Support tätig war, Ich habe schon viele Dinge gemacht, lange bevor M$ auf den Zug aufgesprungen ist. Ich war im Telekommunikationsbereich mit tätig und habe mit weltweiten Netzen zu tun gehabt, da hat M$ gerade mal Windows 3.0 auf den Markt gebracht, ich war auch häufig in entsprechenden Gremien beratend tätig. Ich konnte mit ISDN und digitalen Telefonnetzen umgehen als Siemens hier in Deutschland gerade angefangen hat, sein "EWSD" vorzustellen. 1996 kam ich zu Navision, dem ich bis heute "treu geblieben" bin. Da ich sowohl gut programmiert habe (sagen andere) als auch einen guten kaufmännischen Background habe, war es für mich selbstverständlich, auch zum Kunden rauszufahren, um das abzuliefern was ich produziert habe, oder auch mal ein Projekt zu Ende zu führen, weil sich der Projektleiter im richtigen Moment verflüchtigt hatte. Auch mit den Kunden kann ich es, dank sozialer Kompetenz gut. Nebenher habe ich noch bis in die neueste Zeit zahlreiche Zertifizierungen im Bereich NAV, SQL und auch im Serverbereich erworben, bin also in jeder Hinsicht Topfit. Auch im Internet bin ich gut unterwegs, mit HTML, CSS und PHP habe ich keine Probleme. Eines ging mir allerdings immer am A*** total vorbei, das war .net und Visual Studio. Und genau deswegen habe ich jetzt das eine oder andere Verständnisproblem und die entsprechende Karte. Ich bin auch kein Hardcore-Entwickler, deswegen ist das alles für mich so ein bisschen Sumpfgelände.

Programmierung in diesem Bereich ist eine Notwendigkeit um Lösungen zu erzielen und kein Selbstzweck, so wie du es siehst. Und wenn etwas Neues, Spannendes kommt, da sollte man sehr wohl abwägen, ob es dem großen Ganzen dient oder ob es nur der Sicherung der eigenen Pfründe dient, so wie es M$ derzeit besonders gerne tut. Ich freue mich genau so auf neue Sachen, aber ich übernehme sie nicht unkritisch, sondern schaue wie und wobei sie mir nützen. Wenn du gerne so programmierst, dass du jedes Bit mit Vornamen kennst, dann ist das hier vieleicht nicht ganz zielführend.

Hoffe du weißt mich jetzt einzuordnen.

Hallo Carsten,

ich finde die Diskussion auch toll und möchte mich jetzt doch auch so langsam daraus zurückziehen.

Für den überwiegenden Teil gebe ich dir Recht. Bei manchen Dingen oder Trends frage ich mich aber auch, ob man es wirklich braucht. Für wieder andere Dinge z.B. im Bereich Cloud oder Webservices haben diverse Partner schon exzellente Lösungen entwickelt, die sie jetzt in die Tonne treten können, weil M$ es wieder ganz anders macht.

Ein wirklich alter Spruch heißt "Man muss nicht alles wissen, aber man muss zumindest wissen, wo es steht". Leider ist genau das derzeit ein Problem. Bitte verstehe mich nicht falsch: Ich brauche kein gedrucktes Handbuch und keine Doku-CD. Aber wenn ich heute eine Anforderung auf den Tisch bekomme, nennen wir als Beispiel eine Sharepoint-Anbindung oder was auch immer, dann will ich wissen, wo ich mir Material herunterladen kann oder ob es jemanden gibt, der mir das in wenigen Worten einmal erklären kann, so dass ich damit loslegen kann. Ich will eben nicht erst googeln oder auch bingen (sagt man so?), sondern es muss doch irgendwo etwas strukturiert abgelegt sein. Zumal es immer häufiger die Fundstellen der Suchmaschinen schon gar nicht mehr gibt. Gerade M$ ist da immer besonders schnell, Inhalte wieder zu verschieben oder zu löschen.

Mag sein, dass ich mir auch gelegentlich selbst im Wege stehe, aber es ist irgendwie ein verdammt blödes Gefühl zu sehen, dass die Lücke zwischen dem was man kann und dem was man können sollte trotz intensivster Bemühungen immer größer wird. Gerne würde ich einmal jemanden hier hören, der das bestreitet,

Gruß Rainer

du widersprichst dir doch selbst. Die meisten Älteren sind für dich Quereinsteiger, dann wollen sie es plötzlich wie vor 20 Jahren machen - was denn nun?

Also die von mir angesprochene Gruppe hat mal Taxifahren "gelernt" und hat dann vor über 20 Jahren mit IT und Programmierung begonnen. Navision "Blau" ist doch nun auch schon über 20 Jahre alt. Worin widerspreche ich mir da?

... Und genau deswegen habe ich jetzt das eine oder andere Verständnisproblem und die entsprechende Karte. Ich bin auch kein Hardcore-Entwickler, deswegen ist das alles für mich so ein bisschen Sumpfgelände.

Nicht falsch verstehen, ich wollte keine Kritik an dir persönlich üben, sondern an der Haltung: "C/AL war so schön einfach, jeder konnte drin rummachen, also sind andere Programmiersprachen doof, die kann nicht mehr jeder und vor allem ich nicht". Wenn man hier im Forum liest, kriegt man ja schon mit, wie oft für irgendwelche Lösungen gefrickelt werden musste, weil es NAV bzw. C/AL selbst eben einfach nicht hergibt. Dann doch lieber saubere Lösungen in C# selbst programmieren und reibungsfrei direkt in die Anwendung integrieren. So stelle ich mir jedenfalls NAV für die Zukunft vor.

Programmierung in diesem Bereich ist eine Notwendigkeit um Lösungen zu erzielen und kein Selbstzweck, so wie du es siehst.

Dass sehe ich anders. Bei einem ERP-System geht es ja nicht nur darum, dass die Mitarbeiter ihre Arbeit effektiv erledigen können, sondern vor allem, dass sie es effizient und komfortabel tun können. Das ist jedenfalls mein Verständnis von einem guten ERP-System. Wenn eine neue Anforderung in einem Unternehmen auftaucht, würde ich immer zuerst fragen: "kann ich das nicht auch mit meiner ERP-Software erledigen", statt zu sagen: "na notfalls machen wirs im ERP".

Und wenn etwas Neues, Spannendes kommt, da sollte man sehr wohl abwägen, ob es dem großen Ganzen dient oder ob es nur der Sicherung der eigenen Pfründe dient, so wie es M$ derzeit besonders gerne tut. Ich freue mich genau so auf neue Sachen, aber ich übernehme sie nicht unkritisch, sondern schaue wie und wobei sie mir nützen. Wenn du gerne so programmierst, dass du jedes Bit mit Vornamen kennst, dann ist das hier vieleicht nicht ganz zielführend.

Damit gebe ich dir vollkommen recht. Allerdings scheint sich unsere Bewertung des RTC dahingehend grundlegend zu unterscheiden. Ich sehe den RTC einfach als die logische Konsequenz. Man setzt sich wieder einen deutlichen Schritt von der Konkurrenz ab und kann Lösungen bieten, von denen andere nur träumen. Natürlich dadurch wird die Entwicklung komplexer, aber: um den Vergleich mit den Handwerkern zu bemühen: wenn ich arbeiten an meinem Haus zu erledigen habe, die ich nicht selbst erledigen kann, dann hole ich mir den Spezialisten für die Arbeit und nicht den Allround-Handwerker, der angeblich alles in sehr guter Qualität und zu niedrigsten Preisen kann.

Es gibt wirklich schon genug Partner, die das Image von NAV durch schlechte Qualität versauen. Insofern sollte MS hier wesentlich höhere Anforderungen an die Partner stellen.

Es gibt wirklich schon genug Partner, die das Image von NAV durch schlechte Qualität versauen. Insofern sollte MS hier wesentlich höhere Anforderungen an die Partner stellen.

Und das ist meines Erachtens der Hauptgrund, warum Navision in der Benutzerzufriedenheit im hinteren Feld liegt.

Hallo Tim,

nur zu meiner Bewertung des RTC: Ich sehe zwei Seiten. Einerseits war es die logische Konsequenz, klar, andererseits versteht ihn M$ nur als Gelegenheit, durch die Integration die eigenen Produkte stärker in den Markt zu drücken und die (nicht selten bessere) Konkurrenz auszusperren. Dem Kunden bringt er IMHO fast gar nichts (lassen wir die Optik mal außen vor, aber die ist Geschmackssache). Und die Möglichkeit "drum rum" zu programmieren erschwert die Wartbarkeit und erhöht die Bindung an den Programmierer. Wenn du mal plötzlich unter die Räder kommst kann dir niemand nachfolgen. Du hast dir vielleicht damit ein Denkmal gesetzt, was dir dann aber auch nichts mehr nützt. Leider hat für mich der RTC bei Upgrades in vielen Fällen dazu geführt, dass ich irgendwelche Funktionen komplett neu programmieren musste. Also für mich ist das kein Vorteil. Für Neueinsteiger mag das natürlich so nicht gelten.

Deine anderen Bemerkungen lasse ich so jetzt einfach mal stehen.

Gruß

Rainer

Und das ist meines Erachtens der Hauptgrund, warum Navision in der Benutzerzufriedenheit im hinteren Feld liegt.

Ich glaube, das ist wirklich etwas zu kurz gedacht, auch wenn es stimmt. Wie kommt es aber dann, dass andere besser waren, von denen wir wissen, dass deren Partner oft nicht einmal den schlechtesten M$-Partnern das Wasser reichen können? Ich tu mir hier sehr schwer, keine Namen zu nennen.

Bei dem letzten Anwendertest, den ich in einer durchaus seriösen Zeitung gelesen habe (also nicht Computer Bild), war es einzig und allein die Doku, die NAV so weit hat zurückfallen lassen. Vielleicht war es aber auch nur die insgesamt etwas schlechter gewordene Akzeptanz von M$.

Mach doch mal einen Vorschlag, wie man die Schlechten aussortieren kann. Was sind deine Kriterien?