What's New für Entwickler (mit VS Code)

Er ändert das Diagramm.[/size]

...Bisher noch nicht...

-----

1. Wenn Fälle aus der täglichen Praxis nicht abgebildet werden können, dann hat das Konzept einen Fehler, egal wie neu, modern oder innovativ.
2. Nur weil Dinge neu oder modern sind, sind sie nicht besser. Vor nicht allzu langer Zeit musste alles in XML verarbeitet werden, mit allen Problemen, die daraus resultieren (RDLC mit großen Datenmengen), heute muss es unbedingt JSON sein.
3. ERP ist aus meiner Sicht kein Spielplatz für Programmierer. Es erfordert intensives NACHdenken bevor man an etwas herum bastelt, und Innovationen sollten ausgereift aber zumindest zu Ende gedacht sein, bevor man sie auf den Markt bringt.

Das sieht Microsoft leider anders (und wie man so liest auch eine ganze Reihe von Programmieren bei Partnern). Ich bin ja nicht international unterwegs, mag ja sein dass das in Nordamerika anders ist, aber in Deutschland ist nach meiner Erfahrung ERP ein ganz anderes Geschäft als z. B. Office-Software. Ich kenne keinen Kunden der halbjährlich oder jährlich seine ERP-Software updaten will.

Das ist das Konzept von BC, dass der Anwender sich Apps aus dem Appstore lädt und in seine Anwendung installiert, und alles funktioniert, oder auch nicht.

...und dieses Konzept kann nur bei ganz einfachen und banalen Add-ons funktionieren die so in sich gekapselt sind dass keiner sie gebrauchen kann...

Andrius Pilkonis: AL Interfaces and Other Dynamics 365 Business Central Wave 1 Features

Docs:
Interfaces in AL
AL interfaces

[INFO] "Document Type" use Enum Data Type now (16.0), be careful

Performance Articles For Developers

How to REALLY rename all AL-files of your Business Central app..

[INFO] "Document Type" use Enum Data Type now (16.0), be careful

...und was will mir der Autor damit sagen? Man könnte das Feld Document Type von Option zu Enum ändern. Und nun?

[INFO] "Document Type" use Enum Data Type now (16.0), be careful

...und was will mir der Autor damit sagen? Man könnte das Feld Document Type von Option zu Enum ändern. Und nun?

Naja, das heißt, dass du ab jetzt die Belegarten um eigene Werte erweitern kannst, und dass du deine eigenen Extension-Felder namens "Document Type" entsprechend auch dieses Enum-Variablen umstellen solltest.
Übrigens wurde in BC 16.0 der Sales Document Type "Order" versehentlich in "Bestellung" übersetzt. Wurde aber schon für die nächste Version korrigiert.

Man könnte das Feld Document Type von Option zu Enum ändern. Und nun?

Wieso "könnte"? Der Feldtyp in dieser Tabelle wurde geändert, nach über 30 Jahren. Wer diese Felder anspricht z.B. mit TRANSFERFIELDS, muss das beachten und seinen Code anpassen.

Ei gut dann, das geht ja aus dem "Beitrag" in der Dynamics Community der ja nur aus ein paar Screenshots besteht so gar nicht hervor. Mit dieser Erklärung zusammen würde dieser "Beitrag" sinn machen. So hab ich keinen Sinn erkennen können.

Um mir nicht nachsagen zu lassen, ich würde ich unangenehme Themen meiden, greife ich deine Statements hier nochmal auf:

Wenn Fälle aus der täglichen Praxis nicht abgebildet werden können, dann hat das Konzept einen Fehler, egal wie neu, modern oder innovativ.

Hans Heinrich, wir sind doch alle erwachsen. Wir wissen, dass Konzepte nicht immer allem standhalten. Wir gehen hier einen Weg der anpruchsvoll ist und sicherlich auch noch einiges an Gehirnschmalz erfordert. Natürlich wird es zu Problem(ch)en und ggf. Inkompatibilitäten kommen. Dafür sind wir ja aber da.

Das "Konzept" kann definitiv nicht 100% der Anforderungen abdecken. Aber es ist ein guter, wenn nicht DER Weg, den wir zukünftig einschlagen können und werden. Sind dir die modernen und nicht zwangsweise besseren Dinge zuwider, dann steht dir ja der Weg der Anpassung der Base Application weiterhin offen. Sicherlich nur bis zu einem gewissen Zeitpunkt. Aber der liegt sicherlich noch einige Jahre in der Zukunft.

ERP ist aus meiner Sicht kein Spielplatz für Programmierer. Es erfordert intensives NACHdenken bevor man an etwas herum bastelt, und Innovationen sollten ausgereift aber zumindest zu Ende gedacht sein, bevor man sie auf den Markt bringt.

Auch wenn ich nicht mit allen Änderungen von Microsoft konform gehe, so halte ich den Weg doch für den richtigen. Und Microsoft ist sich seiner Rolle im ERP-Markt sehrwohl bewusst. Auch wenn nicht immer alles im ersten Schritt auf 100% steht, so reflektieren die Zahlen doch, dass der Weg mehr als richtig ist!

Am Ende müssen wir die Probleme unserer Kunden zu vertretbaren Kosten lösen und unterhalten können, sonst kauft keiner mehr unsere Lösungen, und wir sind unsere Jobs los, egal wie genial wir zu sein glauben.

Ich habe noch keine Schlagzeile gesehen, in der steht "Microsoft hat das ERP verkackt". Sicherlich sind wir Partner als Puffer auch ein Grund dafür, aber wir wären alle schon Pleite, wenn Microsoft alles falsch machen würde.

Macht A plötzlich etwas, von dem B nichts weiß und A sorgt nicht dafür, dass B es weiß, dann weiß es B halt nicht.

Entschuldige bitte, aber solche Algemeinplätze sind keine Antwort.

Die Möglichkeit über einen anderen Partner AddOns zu beziehen, war schon immer da. Und sind diese inkompatibel, dann muss man halt für Abhilfe sorgen. Natürlich macht AppSource dieses Vorgehen ggf. anspruchsvoller. Aber ich bin da entspannt und warte ab. Und wenn wir uns in dem Punkt uneins sind, OK, dann ist das halt so. Ich schätze dich und deine Meinung wirklich sehr, aber ich sehe diese Thematik nicht als tödlichen Dolchstoß an.

Alle Eventualitäten sind nicht vorhersehbar. Und wahrscheinlich müssen wir und mal über unseren kleinen Tellerrand auch mit Anderen unterhalten und ggf. Probleme mit deren Lösungen diskutieren. Aber ehrlich: Es heißt doch immer, die NAV-Welt ist klein. Und in einer kleinen Welt findet man immer zueinander. Wenns jemand "verkackt", dann reiche ich Papier, kein Messer.

Dependency Analysis Tool (ALDependencyAnalysis)

[INFO] "Document Type" use Enum Data Type now (16.0), be careful

Diese Änderung (Wechsel Option zu Enum) ist im Standard anscheinend noch nicht ganz durchdesignt worden. Der Kollege hier musste sich hier bei ehemaligen Optionsfeldern der Sales Line mit einem Workaround behelfen.
https://forum.mibuso.com/discussion/752 ... ntral-16-0

Dynamics 365 Business Central: using Camera in AL

Stefano Demiliani: Azure DevOps and cross-repo branch policies

Breaking up the Base App | Request new Interfaces

A.J. Kauffmann: Deep insert with Business Central API’s

Roberto Stefanetti
Publishing apps to a Business Central Online by Powershell
Business Central, fast debugging with AL Object Designer

Multiple variable declarations of the same type in the same line
https://docs.microsoft.com/de-de/dynami ... clarations
https://twitter.com/MSDYN365BC/status/1 ... 5530253312

Lars Westman: Access Business Central API’s in Azure

Neue Extension für VSC, um die Doku zu erleichtern.
AL XML Documentation

https://twitter.com/365businessdev/stat ... 4299731973

Hallo,

irgendetwas funktioniert dein Link nicht, hier ein Korrigierter

Gruß Fiddi

irgendetwas funktioniert dein Link nicht, hier ein
Korrigierter

Der ist korrekt, deiner ist auch identisch. Ab und zu kommt derzeit "Error 503", das liegt aber am Marketplace.

Gibt es schon Pläne wann ich diese Dokumentation der Funktionen auch im Tooltip sehe, wenn ich eine Funktion aufrufen will?
Vorher macht das Dokumentieren ja irgendwie nur bedingt Sinn.

Der Befehl WITH war ja schon immer zweischneidig, nun fliegt er für SaaS-Entwicklung raus.
https://github.com/microsoft/AL/issues/ ... -617004754
Mehr Info dazu morgen:
https://twitter.com/MSDYN365BC/status/1 ... 8323548160

Auch wenn ich den Hintergrund verstehe, macht das den Code nicht unbedingt lesbarer.
Wegen der Extensions hilft hier leider auch keine Compiler- Warnung.

Gruß Fiddi

macht das den Code nicht unbedingt lesbarer.

Wenn man sich sehr kurze Record-Variablen ausdenkt, gehts - hoffentlich.

Ich sehe es schon kommen: ILE, CLE, VLE, SH, SL, SSH, SSL, ...
Bitte übertreibt es bei den Abkürzungen nicht!

Wenn man sich sehr kurze Record-Variablen ausdenkt, gehts - hoffentlich.

Wenn du das WITH-Problem wirklich lösen willst, musst du immer einen Objekt-Modifizierer verwenden. Also auch in einer Page für jedes Feld Rec.Feldname schreiben. Für jeden Funktionsaufruf aus der Page CurrPage.Funktion.
Aber das Problem, das eine Funktion und ein Feldnamen mit gleichem Namen existieren, erschlägst du damit auch nicht, wenn das in einer oder meheren Extension(s) verteilt passiert.

Gruß Fiddi