Dynamics AX Blog - Dynamics AX 4.0 - Seite 7

Ich habe schon seit einiger Zeit das Buch Inside Microsoft Dynamics AX 4.0 auf meinem Schreibtisch liegen und verwende es immer wieder um kurz etwas nachzuschlagen. Und so manche Funktion bzw. Funktionsweise habe ich nur in diesem Buch erklärt bekommen, deshalb kann ich - obwohl ich leider noch nicht dazugekommen bin es komplett zu lesen - dieses Buch nur empfehlen.

Und das Beste daran: bei mfp's two cents habe ich folgenden Link gefunden:

http://download.microsoft.com/down...2579eBook.pdf

Über diesen kann man sich das komplette Buch als PDF herunterladen. Kostenlos!

Wem allerdings - so wie mir - die gebundene Variante lieber ist, kann sich das Buch natürlich gerne bei Amazon kaufen ;-)

Nachdem wir AX-Entwickler in der Version 4.0 leider der Möglichkeit des Sperrens und Entsperrens von Objekten beraubt wurden, habe ich in letzter Zeit vermehrt Zeit investieren müssen, um die in dieser Version integrierte Versionskontrolle (Microsoft Visual SourceSafe) an Stelle dessen zu verwenden.

Leider mit der - mittlerweile auch von Microsoft selbst bestätigten - Erkenntnis, daß bei aktivierter Versionskontrolle pro Applikation und AOS nur ein Entwickler unterstützt wird :-(

D.h. besteht die Notwendigkeit, daß mehrere Entwickler gleichzeitig an einer Applikation entwickeln, die Versionskontrolle in eigenem Interesse deaktiviert werden muß. Ansonsten kann es zu Verlust von Programmzeilen kommen!

Wozu ein einzelner Entwickler allerdings ein "schweres" Versionskontroll-System verwenden soll, ist mir persönlich allerdings schleierhaft.

Übrigens: Laut Microsoft soll in Dynamics AX 2009 dieser Mißstand behoben sein. Ich bin gespannt...

Über nachstehenden Code kann ganz einfach jederzeit eine Verkaufsrechnung nachträglich ausgedruckt werden. Durch leichte Modifikationen des Codes gilt dies auch für sämtliche anderen verkaufs- und einkaufsseitigen Dokumente.

Hier ein kurzes Beispiel unter AX 2009

static void PrintSalesInvoice(Args _args)
{
   custInvoiceJour     custInvoiceJour;
   SalesFormLetter     salesFormLetter = SalesFormLetter::construct(DocumentStatus::Invoice, false);
   PrintJobSettings    printJobSettings = new PrintJobSettings();
   Args                args = new Args();
   boolean             prompt = true;
   boolean             printIt = true;
   ;

   if (prompt)
   {
       // Auswahl des Benutzers über Dialog
       printIt = printJobSettings.printerSettings('SysPrintForm');
   }
   else
   {
       // Printjobsettings per Code steuern
       printJobSettings.setTarget(PrintMedium::File);
       printJobSettings.format(PrintFormat::PDF);
       printJobSettings.fileName(@'c:\temp\myfile.pdf');
   }

   if (!printIt)
   {
       return; // Benutzerabbruch
   }

   salesFormLetter.updatePrinterSettingsFormLetter(printJobSettings.packPrintJobSettings());

   select firstOnly custInvoiceJour
       where custInvoiceJour.salesid == '100001';

   args.record(custInvoiceJour);
   args.caller(salesFormLetter);

   new MenuFunction(menuitemoutputstr(SalesInvoice), MenuItemType::Output).run(args);
}

Nachstehend ein Code-Beispiel unter AX 4.0

static void PrintSalesInvoice(Args _args)
{
   custInvoiceJour     custInvoiceJour;
   SalesFormLetter     salesFormLetter = SalesFormLetter::construct(DocumentStatus::Invoice, false);
   PrintJobSettings    printJobSettings = new PrintJobSettings();
   Args                args = new Args();
   boolean             prompt = true;
   boolean             printIt = true;
   salesPrintSetup     salesPrintSetup;
   ;

   if (prompt)
   {
       // Auswahl des Benutzers über Dialog
       printJobSettings = new PrintJobSettings(salesPrintSetup.PrintJobSettings);
       printIt = printJobSettings.printerSettings('SysPrintForm');
       salesPrintSetup.PrintJobSettings = printJobSettings.packPrintJobSettings();
   }
   else
   {
       // Printjobsettings per Code steuern
       printJobSettings.setTarget(PrintMedium::File);
       printJobSettings.format(PrintFormat::PDF);
       printJobSettings.fileName(@'c:\temp\myfile.pdf');
   }

   if (!printIt)
   {
       return; // Benutzerabbruch
   }

   salesFormLetter.updatePrinterSettingsFormLetter(printJobSettings.packPrintJobSettings());

   select firstOnly custInvoiceJour
       where custInvoiceJour.salesid == '100001';

   args.record(custInvoiceJour);
   args.caller(salesFormLetter);

   new MenuFunction(menuitemoutputstr(SalesInvoice), MenuItemType::Output).run(args);
}

Ob CRM in der jeweiligen AX-Umgebung aktiv ist, erfährt man ganz einfach über folgende Abfrage:

smmLicense::CRM() // returns boolean

Heute musste ich eine AX-Standard-Klasse adaptieren und nach meiner Adaption wurde ich mit merkwürdigen Fehlermeldungen dieser Klasse konfrontiert, die aber allesamt mit meiner Änderung nicht direkt etwas zu tun hatten (Bsp: "Elemententyp kann nicht zugewiesen werden").

Kompilieren, aus- und einsteigen, neustarten des AOS, all das half nichts gegen diese Fehlermeldungen. Erst als ich alle Klassen mitkompiliert habe, die von meiner "Problemklasse" abgeleitet waren, waren die Fehlermeldungen verschwunden. Objektorientierte Programmierung kann auch so seine Fallen haben ;-)

Sämtliche Eltern und Kinder eines Objekts findet Ihr in AX übrigens im Kontext-Menü unter AddIns / Entwicklungshierachie. In dieser Maske kann man u.a. vor- und rückwärts kompilieren.

Zusätzlich dazu sieht man in der Übersicht, welche Methoden in welcher dieser Klassen verwendet werden, in welchen Schichten (Layer) das Objekt existiert und bei aktualisierten Querverweisen auch die Anzahl derselben.

Sowohl unter AX3 als auch AX4 gibt es die Klasse AxInventTable, mit der sich ganz einfach per Code Artikel anlegen lassen. Leider ist die Klasse in der 3er-Version noch nicht ganz so programmiererfreundlich, deshalb also anbei zwei Code-Beispiele wie diese Klasse in den beiden AX-Version genutzt werden kann.

Artikel per Code anlegen unter AX4...

static void CreateItemAX4(Args _args)
{
    axInventTable   axInventTable;
    ;
    
    axInventTable = new axInventTable();

    // Pflichtfeldverprüfung aktivieren
    axInventTable.validateInput(true);  

    // Werte setzen
    axInventTable.parmItemId        ('DL-100-D4');
    axInventTable.parmItemName      ('Deckenlampe - Silber');
    axInventTable.parmItemGroupId   ('Lampen');
    axInventTable.parmModelGroupId  ('DEF');
    axInventTable.parmDimGroupId    ('Std-Dim');

    // Datensatz speichern
    axInventTable.save();
} 

...und AX3

static void CreateItemAX3(Args _args)
{
    axInventTable   axInventTable;
    sysDictTable    sysDictTable = new sysDictTable(tableNum(InventTable));
    int             field;
    boolean         validateField = false;
    ;

    axInventTable = new axInventTable();

    // Werte setzen
    axInventTable.itemId        ('DL-100-D3');
    axInventTable.ItemName      ('Deckenlampe - Silber');
    axInventTable.ItemGroupId   ('Lampen');
    axInventTable.ModelGroupId  ('DEF');
    axInventTable.DimGroupId    ('Std-Dim');

    // Prüfung der einzelnen Felder
    for(field = 1; field <= sysDictTable.fieldCnt(); field++)
    {
        validateField = axInventTable.inventTable().validateField(field);
    }

    // Datensatz speichern
    if(axInventTable.inventTable().validateWrite() && validateField)
    {
        axInventTable.save();
    }
}

Wenn man Objekte aus einer AX4-Umgebung in eine AX3-Umgebung importieren will, muss man selbstverständlich darauf achten, daß der zu importierende Code auch von AX3 verstanden wird. Aber selbst wenn dies sichergestellt ist, muß man im XPO selbst einige Anpassungen vornehmen, um die Objekte überhaupt einspielen zu können. Einige derartiger "Stolpersteine" findet Ihr im folgenden:

Im Export-File der Version 4 müssen folgende Textpassagen rausgelöscht werden:

<Table:Field name="recVersion">0</Table:Field>

und

<Table:Field name="SysLabelApplModule">0</Table:Field>

Letzterer Text ist im XPO nur dann vorhanden, wenn man Labels mit exportiert hat.

Des weiteren muß, soferne man Menus transferieren will, der Text

MNUVERSION 4

durch

MNUVERSION 3

ersetzt werden.

Danach mus das gesamte XPO im ANSI-Format gespeichert werden, mit Hilfe von z.b. Notepad und dessen "Speichern unter..."-Dialog sollte dies aber kein Problem sein.

Ausserdem ist mir noch aufgefallen, daß AX3 scheinbar die Eigenschaft Columns in einem Design einer Form nicht importieren kann. Diese Eigenschaft wird nach einem Import standardmässig auf 2 gesetzt. Um sich durch dieses Verhalten keine Probleme einzuhandeln, sollte man schon beim Gestalten eines Formulares darauf achten, diese Eigenschaft immer auf 2 zu setzten.

Nachtrag vom 19. März 2008

Müssen MenuItems transferiert werden, so muß außerdem

ObjectType

durch

Class

ersetzt werden.