Wie im Blog des Dynamics AX Sustained Engineering Teams zu lesen ist, wird der neue SharePoint Server, Microsoft SharePoint 2010, nun auch von Dynamics AX 2009 SP1 unterstützt.

Es wird allerdings empfohlen, dass Hotfix Rollup 5 zu installieren.

Genauere Details können dem Blog des Dynamics AX Sustained Engineering Teams oder im “Solutions Monkey” Blog entnommen werden:

Artikel im Blog des Dynamics AX Sustained Engineering Teams

Artikel im “Solutions Monkey” Blog

Ein großer Vorteil des Application Integration Frameworks (AIF) gegenüber “selbst geschriebene” Schnittstellen ist es, dass man sich über Dinge wie Datentyp-Mapping keine Gedanken machen muss.
Das Application Integration Framework verfügt über die entsprechende Logik, um alle Dynamic AX Datentypen automatisch in den jeweils gültigen XSD-Datentyp zu “mappen” (oder umgekehrt).

Zeiten, in denen sich der Entwickler zum Beispiel Gedanken machen musste, wie viele Nachkommastellen eine Zahl haben darf, oder welches Zeichen als Dezimaltrennzeichen verwendet werden muss, sind somit vorbei.
Da alle Daten die aus Dynamics AX exportiert oder nach Dynamics AX importiert werden, in einem XSD-Schema konformen XML-Dokument “transportiert” werden, und das AIF entsprechendes Mapping bereits stellt, geschieht das Datentyp-Mapping automatisch.

Allerdings kann auf Seiten der Anwendung, welche über das Application Integration Framework (AIF) angebunden werden soll, ein wenig “Verwirrung” entstehen.
Durch die von Programmiersprache zu Programmiersprache durchaus unterschiedlichen Datentypen kann es vorkommen, dass Dynamics AX Datentypen nicht in dem erwarteten Datentyp der anderen Programmiersprache erscheinen.
Dies ist allerding kein “wirkliches” Problem des Application Integration Frameworks (AIF), sondern eher eine Frage, welche Datentypen eine Programmiersprache bereit stellt und wie diese in XSD-Datentypen “gemappt” werden.

Ein gutes Beispiel hierfür sind die Dynamics AX Datentypen “Date”, “Time” und “DateTime” (inklusive aller von diesen Basisdatentypen abgeleiteten EDT’s).

Ohne genauere Betrachtung liegt die Annahme nahe, dass ein DateTime Datentyp von Dynamics AX in einen DateTime Datentyp von z.B. C# “gemappt” wird.
Dies ist allerdings nicht richtig. Da nicht direkt zwischen Dynamics AX Datentyp und C# Datentyp gemappt wird, sondern immer von/zu einem XSD-Datentyp gemappt wird, wird in C# eine neue Klasse hierfür erzeugt.

Ein wenig schwieriger wird es bei den beiden Dynamics AX Datentypen “Date” und “Time”. Für diese Datentypen wird z.B. in C# kein direkt vergleichbarer Datentyp bereit gestellt.
Diese Datentypen werden jeweils als C# DateTime Datentypen gemappt.

Das Mapping der Datentypen geschieht wie folgt:

Da die beiden Dynamics AX Datentypen “Date” und “Time” in den C# Datentyp “DateTime” gemappt werden, kann an dieser Stelle leider ein kleines Problem entstehen.
In C# ist nun leider nicht mehr zu erkennen, um was für einen Dynamics AX Datentyp es sich z.B. bei einem Feld handelt, und ob nun ein Datum oder eine Zeit in diesem enthalten ist.

Oftmals entsteht diese Problem dadurch nicht, dass der jeweilige Business-Kontext die Datentypverwendung entsprechend einschränkt und es somit teilweise egal ist ob nun in ein Dynamics AX Date oder Time gemappt wird.
Ist es aber erforderlich zu wissen, um ob ein Feld nun den Dynamics AX Datentyp Date oder Time hat, kann der generierte Code der Proxyklasse Aufschluss geben (oder das XSD-Schema).

Durch die Angabe eines Serialisierungs-Attributes wird bestimmt, welcher “Teil” des DateTime Datentyps verwendet wird.
Für ein Feld, welches in einen Dynamics AX Date Datentyp gemappt wird, wird nur der “Datumsteil” in das XML-Dokument serialisiert.
Entsprechendes geschieht für einen Dynamics AX Time Datentyp.

Mapping eines C# Datetime Datentyps in einen Dynamics AX Date Datentyp (generierter Code der Proxyklasse):

             1: [System.Xml.Serialization.XmlElementAttribute(DataType="date",
IsNullable=true, Order=54)]

             2: 
            public System.Nullable<System.DateTime>
MyDateField {

             3:  get {

             4: 
            return
            this.myDateFieldField;

             5:  }

             6:  set {

             7: 
            this.myDateFieldField
= value;

             8: 
            this.RaisePropertyChanged("MyDateField");

             9:  }

             10: }

Mapping eines C# Datetime Datentyps in einen Dynamics AX Time Datentyp (generierter Code der Proxyklasse):

             1: [System.Xml.Serialization.XmlElementAttribute(DataType="time",
IsNullable=true, Order=56)]

             2: 
            public System.Nullable<System.DateTime>
MyTimeField {

             3:  get {

             4: 
            return
            this.myTimeFieldField;

             5:  }

             6:  set {

             7: 
            this.myTimeFieldField
= value;

             8: 
            this.RaisePropertyChanged("MyTimeField");

             9:  }

             10: }

Wie durch den generierten Code der Proxyklasse ersichtlich wird, wird nur der jeweils benötigte “Teil” eines C# Datetime Datentyps serialisiert/deserialisiert und somit verwendet.

Für einen Dynamics AX DateTime Datentyp wird bei Erstellung des Proxys eine neue Klasse generiert. Somit kann der Dynamics AX Datentyp hierbei immer eindeutig identifiziert werden.

             1: [System.CodeDom.Compiler.GeneratedCodeAttribute("System.Xml", "2.0.50727.4016")]

             2: [System.SerializableAttribute()]

             3: [System.Diagnostics.DebuggerStepThroughAttribute()]

             4: [System.ComponentModel.DesignerCategoryAttribute("code")]

             5: [System.Xml.Serialization.XmlTypeAttribute(Namespace="http://schemas.microsoft.com/dynamics/2008/01/documents/Customer")]

             6: 
            public
            partial
            class AxdType_DateTime
: object, System.ComponentModel.INotifyPropertyChanged {

             7: 
          

             8: 
            private System.DateTime
localDateTimeField;

             9: 
          

             10: 
            private
            bool localDateTimeFieldSpecified;

             11: 
          

             12: 
            private AxdEnum_Timezone
timezoneField;

             13: 
          

             14: 
            private
            bool timezoneFieldSpecified;

             15: 
          

             16: 
            private System.DateTime
valueField;

             17: 
          

             18:  [System.Xml.Serialization.XmlAttributeAttribute()]

             19: 
            public System.DateTime
localDateTime ... 

             20: 
          

             21:  [System.Xml.Serialization.XmlIgnoreAttribute()]

             22: 
            public
            bool localDateTimeSpecified... 

             23: 
          

             24:  [System.Xml.Serialization.XmlAttributeAttribute()]

             25: 
            public AxdEnum_Timezone
timezone...

             26: 
          

             27:  [System.Xml.Serialization.XmlIgnoreAttribute()]

             28: 
            public
            bool timezoneSpecified...

             29: 
          

             30:  [System.Xml.Serialization.XmlTextAttribute()]

             31: 
            public System.DateTime
Value {

             32: 
          

             33: 
            public
            event System.ComponentModel.PropertyChangedEventHandler
PropertyChanged;

             34: 
          

             35: 
            protected
            void RaisePropertyChanged(string propertyName)...

             36: }

Dieses Verhalten ist nicht nur mit C# zu beobachten. Auch JAVA oder andere Programmiersprachen verhalten sich ähnlich und muss entsprechend berücksichtigt werden.

Macros werden innerhalb von Dynamics AX z.B. für die Best-Practice konforme Verwendung von festen Zeichenfolgen innerhalb des X++ Quellcodes verwendet.
An vielen Stellen im System finden sich Quellcodezeilen wie diese:

#define.MySimpleMacro('The string value')

Dies ist die am meist verwendete Art der Macrodefinition innerhalb von Dynamics AX.
So weit, so gut.

Es gibt allerdings Konstellationen von “Werten”, welche bei dieser Art der Macrodefinition zu einer Fehlermeldung beim speichern führen.
Es bei dieser Art der Macrodefinition z.B. nicht möglich, eine schließende Klammer als Macrowert zu definieren.
Dies ist auch so im MSDN dokumentiert: http://msdn.microsoft.com/en-us/library/cc197110.aspx

Gerade bei der Verwendung von Regular Expressions (Regex) kann dies zu regelmäßiger Verwirrung führen, da man gerne die weiteren Macrodefinitions-Möglichkeiten vergisst und oder diese nicht so präsent sind.

Die Syntax

#define.Macroname(Wert)

sollte eigentlich nur verwendet werden um (einfache) Konstanten innerhalb des Quellcodes zu definieren.
Für alle anderen Fälle und wenn ein Macro mit mehr als einer Zeile benötigt wird, sollte folgende Syntax zu Definition eines Macros verwendet werden:

#localmacro.AnExample

// Some statements
or text #endmacro

Die Verwendung von #localmacro anstelle eines "(einfachen) #define erlaubt es nun auch mit schließenden Klammern als Macrowert zu arbeiten oder sogar ganze SQL oder X++ Codeblöcke zu verwenden.
Eine genauere Beschreibung von Dynamics AX Macros (deren Möglichkeiten und Einsatzgebiete) ist im MSDN dokumentiert:

Macros in X++

Im Microsoft Downloadcenter ist ein Whitepaper verfügbar, welches bei der Konfiguration einer Microsoft Dynamics AX Datenbank unterstützen soll.

Das Dokument kann als eine Art “Checkliste” angesehen werden, nach welcher einzelne Konfigurationspunkte abgearbeitet werden können.

Das Whitepaper kann über folgenden Link bezogen werden:
http://www.microsoft.com/downloads/details.aspx?FamilyID=ab4cd401-b366-4c1c-9a73-88c945ae8191&displaylang=en

Beim Entwickeln und/oder Testen von AIF-Service, welche als Webservice bereit gestellt werden, entstehen oftmals (mindestens) 2 Fragestellungen.

1. Wie kann die Nachricht betrachtet werden, welche zwischen den System über den Webservice ausgetauscht wird?
2. Wie lässt sich der Webservice-Aufruf debuggen?

Leider werden diese Fragen bei einer Suche im Internet oft mit “Geht nicht” beantwortet.
Dies ist so allerdings nicht richtig.

Es ist z.B. möglich, für alle Webserviceaufrufe eine Tracing-File zu erzeugen, welches u.A. auch die Nachricht protokolliert, die von oder zu Dynamics AX geschickt wurde.
Um das Tracing zu aktivieren müssen nur entsprechende Einstellungen in der web.config des Webservices vorgenommen werden.

Wie dies im Detail funktioniert beschreibt dieses kleine How-To des Microsoft Dynamics Developer Centers im MSDN.
http://msdn.microsoft.com/en-us/library/cc967372.aspx

Es ist ebenfalls möglich, die Webserviceaufrufe zu debuggen.

Allerdings müssten hierfür einige Schritte beachtet werden, damit das Debuggen von Webserviceaufrufen auch für X++ Code funktioniert.
Eine detaillierte Anleitung hierzu ist am Ende des Whitepapers “Tips for Creating Services in Microsoft Dynamics AX 2009” zu finden.
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=90388b14-fb8c-4633-a255-28ff7146c5b2

Oftmals besteht die Anforderung, über einen Zeitgesteuerten Job (Batchjob), das Generieren von statistischen Berichten, welche in einer Datei gespeichert werden soll, zu automatisieren.

Microsoft Dynamics AX stellt hierfür die Möglichkeit bereit, jeden Bericht mithilfe der Stapelverarbeitung zu einem definierten Zeitpunkt zu generieren und in einer Datei, z.B. in einem Netzwerklaufwerk, bereit zu stellen.
Soweit stellt dies kein Problem dar, da über den Standard von Dynamics AX diese Anforderung ohne weiteres erfüllt werden kann.

Leider wird hierbei oft vergessen, dass  der entsprechende Batchserver (AOS) so konfiguriert werden muss, dass dieser das “Drucken auf dem Server” zulassen muss.
Dies ist eine Einstellungsoption des Serverkonfigurations-Utilities.

Weiterhin sollte bei der Angabe der Datei bzw. des Speicherortes der Datei immer ein UNC-Pfad verwendet werden, da die eigentlich Ausführung des Berichtes und somit auch die Erstellung der Datei über das Benutzerkonto des AOS-Dienstes geschieht.

Dies bedingt auch, dass entsprechende Berechtigungen für das Dienstkonto des Batchservers (AOS) für das freigegebene Verzeichnis vergeben werden müssen, damit die Datei und somit der Bericht erfolgreich erstellt werden kann.

Eine weiterführende Beschreibung hierzu ist auch im EMEA Dynamics AX Support Blog zu finden.

Notizen, Dokumente oder Dateien werden in Dynamics AX mithilfe des “Dokumentenmanagement-Systems” verwaltet.

Zu jedem beliebigen Datensatz einer beliebigen Tabelle (z.B. CustTable -> Debitoren) können beliebig viele Notizen oder Dokumente hinterlegt werden.
Per Benutzeroberfläche kann die entsprechende Funktionalität über die Menüleiste der Masken aufgerufen werden.

Das folgende Beispiel zeigt wie dies auch per Programmcode erfolgen kann:

            static
            void AKU_CreateDocuRefNote(Args
_args)

{

    CustTable       custTable;

    DocuRef         docuRef;

    DocuType        docuType;

    ;

    custTable = CustTable::find("1101");

    docuType  = DocuType::find("Note");

            if(custTable && docuType)

    {

        docuRef.initValue();

        docuRef.RefTableId   = custTable.TableId;

        docuRef.RefRecId     = custTable.RecId;

        docuRef.RefCompanyId = custTable.dataAreaId;

        docuRef.TypeId       = docuType.TypeId;

        docuRef.Restriction  = DocuRestriction::External;

        docuRef.Name         = "Name der Notiz";

        docuRef.Notes        = "Text (Inhalt) der
Notiz";

        docuRef.insert();

    }

}

Für Debitoren (Kunden) kann in Microsoft Dynamics AX ein Kreditlimit vergeben/eingestellt werden.

In der Auftragsmaske wird bei Anlage eines Auftrag (in Abhängigkeit der Kreditlimit-Einstellungen) das verbleibende Kreditlimit berechnet und der Auftragswert gegen dieses geprüft.
Bei Überschreitung des Kreditlimits wird eine entsprechende Warnung oder ein entsprechender Fehler ausgegeben.

Die Funktion zur Überprüfung des Kreditlimits kann auch manuell, durch  eine entsprechende Funktion auf der Auftragsmaske, aufgerufen werden.

Soll das verbleibende Kreditlimit mit X++ Code berechnet werden, muss leider eine “Kleinigkeit” beachtet werden, die so auf den ersten Blick nicht immer ersichtlich ist bzw. für Verwirrung sorgen kann.

Die Berechnung des verfügbaren Kreditrahmens oder des verbleibenden Kreditlimits ist durch die alleinige Angabe eines Debitors nicht möglich.
Es muss immer ein entsprechender Auftrag “vorhanden” sein um diese auszuführen zu können.

Berechtigterweise stellt sich die Frage, wie das verbleibende Kreditlimit eines Debitors berechnet werden kann, wenn keine “Beziehung” zu einem Auftrag besteht bzw. wenn kein Auftrag angegeben werden kann.
Hierfür muss ein kleiner “Trick” angewendet werden, der nichts anderes macht, als einen neuen “SalesTable” Datensatz zu initialisieren, diesen aber nicht zu speichern.
Ist der “SalesTable” Datensatz initialisiert kann mithilfe der beiden Klassen “SalesTotals” und “CustCreditLimit” der verfügbare Kreditrahmen berechnet werden.

Beispiel:

    CustTable               custTable = CustTable::find("1101");

    CustCreditLimit         custCreditLimit;

    SalesTotals             salesTotals;

    SalesTable              salesTable;

    AmountMST               balanceEstimate;

    AmountMst               creditRemain;

    ;

    salesTable.CustAccount  = custTable.AccountNum;

    salesTable.initFromCustTable();

    salesTotals = SalesTotals::construct(salesTable);

    salesTotals.calc();

    custCreditLimit = CustCreditLimit::construct(salesTable);

    balanceEstimate = custCreditLimit.balanceEstimate();

            if(custCreditLimit.useEstimated())

    {

        creditRemain -= balanceEstimate;

    }

    creditRemain += conpeek(salesTotals.displayFieldsCurrency(CustTable.Currency), TradeTotals::posFreeValue());

    info(strfmt("Verbleibendes Kreditlimit: %1", creditRemain));

Wie bereits an mehreren Stellen angekündigt, hat Microsoft das HotFix Rollup 3 für Microsoft Dynamics AX 2009 (RTM und SP1) veröffentlicht.

Alle Microsoft Dynamics AX Kunden und Partner können das Hotfix Rollup über das Customer Source bzw. Partner Source beziehen.

HotFix Rollup 3 für Dynamics AX 2009 RTM (KB974407)

HotFix Rollup 3 für Dynamics AX 2009 SP1 (KB974409)

In mehreren Artikeln wurde bereits beschrieben, wie LookupForms erstellt werden müssen, um alle Funktionen bereit zu stellen, die auch durch einen Standard-Lookup bereit gestellt werden.

Ein guter Artikel ist zum Beispiel auf Axaptapedia zu finden:
http://axaptapedia.com/Lookup_Form

Leider wurde in diesem Artikel auf eine Kleinigkeit nicht hingewiesen, die allerdings für sehr viel Verwirrung sorgen kann.

Um beim Öffnen des Lookups den bereits eingetragenen Wert zu selektieren (in dem Control der aufrufenden Maske), müssen wie in dem Artikel beschrieben, die Methoden „executeQuery“ und „init“ der DataSource der Lookup-Maske überschrieben werden.

Beispiel:

          public
          void executeQuery()
{ FormStringControl callerControl = SysTableLookup::getCallerStringControl(element.args());
; super(); xyz_ds.findValue(fieldnum(xyz,id),callerControl.text()); } publicvoid init()
{ Query q = new Query(); QueryBuildDataSource qbds; ; super();
qbds = q.addDataSource(tablenum(xyz)); qbds.orderMode(OrderMode::OrderBy); qbds.addSortField(fieldNum(xyz,some_other_field)); this.query(q);
} 

Es wird auch beschrieben, dass in der Methode “init” der Datasource eigene Ranges oder Sortings definiert werden können.
Dies ist soweit auch richtig, allerdings mit einer Ausnahme.

Wird auf dem Feld, welches bei dem Aufruf von „Datasource.findValue“ in der Methode „init“ angegeben wurde (sollte auch immer das Feld sein, dessen Wert durch den Lookup ausgewählt wird), eine Range definiert, so funktioniert die Selektion des zuvor gewählten Wertes nicht mehr und es wird immer der erste Wert im Lookup selektiert bzw. ausgewählt.

Beispiel:

          public
          void executeQuery()
{ FormStringControl callerControl = SysTableLookup::getCallerStringControl(element.args());
; super(); xyz_ds.findValue(fieldnum(xyz,id),callerControl.text()); } publicvoid init()
{ Query q = new Query(); QueryBuildDataSource qbds; QueryBuildRange
range; ; super(); qbds = q.addDataSource(tablenum(xyz)); qbds.orderMode(OrderMode::OrderBy);
qbds.addSortField(fieldNum(xyz,some_other_field)); range = qbds.addRange(fieldnum(xyz,id));
range.value(SysQuery::valueNot(<someValue>)); this.query(q);
} 

Dieses Verhalten lässt sich allerdings umgehen, wenn anstelle des Aufrufs von “DataSource.findValue” in der „ExecuteQuery“ Methode der DataSource der Aufruf von „DataSoucre.findRecord“ verwendet wird.
Hierfür muss aber der entsprechende Datensatz des zuvor oder bereits ausgewählten Wertes ermittelt werden um diesen beim Aufruf von „DataSource.findRecord“ als Parameter zu übergeben.

Beispiel:

          public
          void executeQuery()
{ FormStringControl callerControl; Xyz xyzRecord; ; callerControl = SysTableLookup::getCallerStringControl(element.args());
xyzRecord = Xyz::find(callerControl.text()); super(); xyz_ds.findRecord(xyzRecord);
} publicvoid init() { Query q
= new Query(); QueryBuildDataSource qbds; QueryBuildRange
range; ; super(); qbds = q.addDataSource(tablenum(xyz)); qbds.orderMode(OrderMode::OrderBy);
qbds.addSortField(fieldNum(xyz,some_other_field)); range = qbds.addRange(fieldnum(xyz,id));
range.value(SysQuery::valueNot(<someValue>)); this.query(q);
}

Es muss also darauf geachtet werden, ob eine Einschränkung (Range) auf dem „ID-Feld“ benötigt wird oder nicht.

Wird keine Einschränkung benötigt, kann, wie in dem Artikel auf Axaptapedia beschrieben, mit „DataSource.findValue“ gearbeitet werden um den entsprechenden Datensatz zu selektieren.
Wird aber eine solche Einschränkung benötigt, muss mit „DataSoucre.findRecord“ gearbeitet werden.

Ab sofort führt mein Arbeitgeber, die Firma AX Solutions GmbH, einmal in der Woche (mittwochs 15:30 - 16:30 Uhr) eine kostenlose „Experten-Sprechstunde“ durch.

Diese „Sprechstunde“ richtet sich an Microsoft Dynamics AX Bestandskunden sowie Interessenten die Antworten auf bisher unbeantwortete Fragen oder einen Rat zu einer speziellen Problemstellung suchen.

Unter anderem werde auch ich diese Sprechstunden abhalten und versuchen nach besten Wissen und Gewissen Rat zu geben. Sicherlich wird sich nicht jede Problemstellung Ad-hoc lösen lassen. Ich bin aber sicher, dass der gemeinsame Dialog zumindest Lösungsoptionen aufzeigen wird.

Guter Rat ist Sprichwörtlich teuer. Diesmal aber nicht, denn die Dynamics AX Sprechstunde ist kostenlos.
Auf die sonst übliche Praxisgebühr in Höhe von 10,- EUR pro Quartal wird verzichtet.

Da die Sprechstunden in einem 1:1 Gespräch durchgeführt werden, und möglichst vielen Ratsuchenden die Möglichkeit gegeben werden soll diese zu nutzen, ist jede Sprechstunde auf 60 Minuten begrenzt.

Ratsuchende bzw. Interessierte möchte ich bitte, sich unter folgendem Link: (http://www.ax-solutions.de/kontaktformular.html) mit dem Stichwort „Dynamics AX – Sprechstunde“ anzumelden.

Weitere Informationen können über die  Webseite der AX Solutions GmbH bezogen werden.

Wie schon die erste Auflage des Buches „Inside Dynamics AX“ ist dieses Buch eine sehr gute Ergänzung zu den von Microsoft angebotenen Schulungsunterlagen (Development 1-4).

Angefangen bei der Architektur, der Entwicklungsumgebung und –Tools, bis hin zu Code Upgrades beschreibt dieses Buch alle Themen die für einen AX Entwickler von Bedeutung sind.

Nicht nur alle neuen Features von Dynamics AX 2009, z.B. Dynamics AX Reporting Services oder Workflows, sondern auch ältere Features wie z.B. das Application Integration Framework (AIF), werden wesentlich detaillierter beschrieben als an anderen Stellen.

Leider gibt es auch Bereiche, die nicht so detailliert besprochen werden bzw. wo einige Fragen nicht gänzlich beantwortet werden.
Ein Beispiel hierfür ist die .NET Integration. Zwar wird der Business Connector ausreichend beschrieben, aber das Thema CLR-Interoperability wird leider nur sehr knapp behandelt.

Einige Kapitel wurden im Vergleich zu der ersten Auflage des Buches gänzlich überarbeitet.
Beispielhaft sei das Kapitel über Form Customizations genannt, welches komplett neu geschrieben wurde.

Leider hat dies auch zur Folge, dass einige sehr gut Beschriebene Themen, wie Beispielweise das dynamische Anpassungen von Masken mit X++,
jetzt nicht mehr behandelt werden.

Was dieses Buch aber nicht beschreibt oder behandelt, sind die Klassen, Tabellen, API‘s, etc. des Microsoft Dynamics AX Standards.
Dies würde allerdings auch den Rahmen des Buches mehr als sprengen.

In der Gesamtbetrachtung ist die neue Auflage von Inside Microsoft Dynamics AX eins der besten technischen Bücher über Microsoft Dynamics AX.
Kein Buch geht soweit in die Tiefe wie dieses. Egal ob Anfänger oder erfahrener Entwickler, für jeden ist etwas dabei.

Auch wer schon die erste Auflage von Inside Microsoft Dynamics AX gelesen hat, wird viele neue Themen finden.

Wird die Eigenschaft(Property) “AllowEditOnCreate” eines Tabellenfeldes auf den Wert “No” gesetzt, ist es nicht möglich,
Werte für dieses Tabellenfeld über das AIF (Application Integration Framework) zu schreiben (Insert-Operation).

Alle Tabellenfelder, welche diese Eigenschaft auf “No” gesetzt haben, werden durch das AIF automatisch auf deren Default-Wert gesetzt und jegliche Wert der AIF Nachricht werden ignoriert.
Dies hat zur Folge, dass wenn das Tabellenfeld kein Enum ist, das Tabellenfeld immer leer ist.

Da dieser Automatismus schon vor Ausführung der AX<Table> Klasse greift, der Wert also schon beim Ausführen der entsprechenden Parm-Methode “leer” ist,
kann dieses Verhalten ohne Änderung der AIF-Basis Klassen nicht geändert werden.

Die neue oder zweite Auflage von "Inside Mircosoft Dynamics AX" ist vor wenigen Tage erschienen.

Inside Mircosoft Dynamics AX 2009

Wie auch schon die erste Auflage des Buches, welche auf der Version 4.0 von Microsoft Dynamics AX basierte, ist diese Buch in erster Linie für Entwickler gedacht.
Die aktuelle Auflage umfasst gut 100 Seiten mehr als die erste Auflage und ist leider auch im Preis etwas teurer.

Weitere Informationen über den Inhalt können z.B. auf den Seiten von Amazon entnommen werden.

Es ist zu hoffen, dass sich diese Auflage auf gleichem Level wie die erste Auflage bewegt und somit zu einem "Must-Have" oder "Must-Read" für AX Entwickler wird.

In dem Artikel "Anzeige von Lagerdimensionen auf Masken" wurde bereits gezeigt, was zu tun ist, um die Anzeige von Lagerdimensionen auf Masken dynamisch anpassen zu können bzw. das Standardverhalten für die Anzeige von Lagerdimensionen zu implementieren.

Manchmal soll eine ähnliche Funktionalität auch für Berichte bereit gestellt werden, um zum Beispiel vor der Berichtserstellung auswählen zu können, welche Lagerdimensionen auf dem Bericht(Report) angedruckt werden.
Auch hierfür sind im Dynamics AX Standard die entsprechenden Funktionalitäten (oder besser Klassen) bereits vorhanden, sodass diese nur verwendet werden müssen.

Als Ausgangsbasis für den Bericht dient ebenfalls die Tabelle „AKU_DemoTable“.

Der Bericht soll nun, die in dieser Tabelle gespeicherten Datensätze andrucken/ausgeben.

Wie bei Masken, muss auch für einen Bericht, die Query entsprechend um die Tabelle InventDim ergänzt werden.
Hierbei ist zu beachten, dass die Eigenschaften (Properties) „FetchMode“ auf „1:1“ und „Relations“ auf „Yes“ gesetzt werden.

Als nächstes muss nun, ebenfalls analog zu dem Vorgehen bei Masken, die Feldgruppe „InventoryDimensions“ in den Designzweig des Reports aufgenommen werden.
Beispielhaft wird diese in einem Body-Element erstellt.

Nun müssen noch einige Anpassungen an den Methoden des Berichts durchgeführt werden, damit das gewünschte Ergebnis erreicht werden kann.
Bezogen auf die Möglichkeit, die zu druckenden Lagerdimensionen bestimmen zu können, müssen die Methoden „classDeclaration“, „run“, „dialog“ und „getFromDialog“ wie folgt überschrieben werden.
Auch das Überschreiben der Methoden „pack“ und „unpack“ ist hilfreich (für die Lagerdimensionsanzeige nicht zwingend erforderlich), da über diese die Speicherung der „Nutzungsdaten“ realisiert wird.

public class ReportRun extends ObjectRun
{
   InventDimParm inventDimParm;
   DialogRunbase dialog;
   DialogGroup dialogInventoryDimensions;

   #define.CurrentVersion(1)
   #localmacro.CurrentList
      inventDimParm
   #endmacro
}

Wird nun der Bericht geöffnet, zum Beispiel über ein MenuItem, kann in einem Dialog ausgewählt werden, welche Lagerdimensionen auf dem Report angedruckt werden sollen.

Der ausgegebene Bericht(Report) sieht, unter Berücksichtigung der im Dialog gewählten Einstellungen, wie folgt aus.

Das vorgestellt Bespiel steht hier als Download bereit um die einzelnen Schritte genau ansehen/nachvollziehen zu können.

Oft ist in Newsgroups und Foren die Frage zu lesen, wie .NET (CLR) Arrays in X++ verwendet, bzw. wie diese deklariert werden können.
Im Großen und Ganzen unterscheidet sich die Syntax für die Verwendung eines .NET Array kaum von der eines reinen X++ Array.
.NET Arrays können in X++ sogar auf zwei verschiedene Arten deklariert werden.

Variante 1:

Die Deklaration eines .NET Arrays erfolgt analog zu der Deklaration eines "reinen" X++ Arrays:

System.Object[] arrayOfObjects;
System.Int32[] arrayOfIntegers;

Die Syntax für die Instanzierung des .NET Array weicht allerdings leicht von der "normalen" X++ Syntax ab:

arrayOfObjects =new System.Object[10]();
arrayOfIntegers =new System.Int32[3]();

Wichtig ist hierbei, dass immer "()" verwendet wird.

Um die Werte eines .NET Arrays zu setzen wird die Methode "SetValue()" verwendet:

arrayOfObjects.SetValue(myObject, 0);
arrayOfIntegers.SetValue(300, 1);

Um Werte aus einem Array abzufragen kann die Methode "GetValue" verwendet werden:

arrayOfObjects.GetValue(0);
arrayOfIntegers.GetValue(1);

Eine weitere sehr nützliche Methode ist die Methode "get_Length()". Diese liefert die Anzahl der Array-Elemente zurück.

Variante 2:

Alternativ zur ersten Variante besteht noch die Möglichkeit, ein .NET Array über die Klasse System.Array zu erzeugen.
Leider stößt man bei diesem Weg immer mal wieder auf kleinere Probleme, weswegen die erste Variante für die Verwendung von .NET Array bevorzugt werden sollte.

Eine etwas ausführlichere Beschreibung der Verwendung von .NET Array in X++ bzw. deren besonderheiten und Abweichungen zur "normalen" X++ Syntax kann im Microsoft Dynamics AX Developer Center gefunden werden.

How to: Use X++ Syntax for CLR Arrays

Wie in einem Artikel auf der Microsoft Dynamics AX Webseite zu lesen ist wird der "alte" COM Business Connector nicht mehr in zukünftigen Versionen von Dynamics AX enthalten sein.
The COM Business Connector will be discontinued in future releases of Microsoft Dynamics AX

Bereits in der Version 2009 von Microsoft Dynamics AX wird der COM Business Connector vom "normalen" Setup nicht mehr angeboten.
Dieser muss manuell, wie im Microsoft Dynamics AX Developer Center beschrieben, nachinstalliert werden.
How to: Install COM Business Connector using Command-line Options

Somit ist es an der Zeit, bestehende Lösungen welche den COM Business Connector verwenden, auf den neueren .NET Business Connector zu portieren, um diese Lösungen auch in zukünftigen Versionen verwenden zu können.

Alle benötigten Informationen über die Verwendung des .NET Business Connectors können in der Library des Microsoft Dynamics AX Developer Centers gefunden werden
.NET Business Connector Overview

Wer schon mit dem AIF in der Version 4.0 von Microsoft Dynamics AX gearbeitet hat wird sich daran erinnern, dass ein Debuggen des Quellcodes, welcher durch das AIF ausgeführt wird, nur möglich ist, wenn hierfür eine kleine Codeanpassung in den Klassen "AifInboundProcessingService" und "AifOutboundProcessingService" vorgenommen wird.
Das genaue Vorgehen für die Version 4.0 von Dynamics AX ist in diesem Artikel beschrieben.

Für Dynamics AX 2009 kann diese Quellcodeänderung allerdings nicht so ohne weiteres angewendet werden, da für Dynamics AX 2009 einige Features ergänzt wurden (z.B. paralelle Verarbeitung von AIF Nachrichten) und somit der Quellcode der beiden Klassen einige Abweichungen zu dem der Version 4.0 hat.

Debuggen von ausgehenden Nachrichten

Um das Debuggen von ausgehenden Nachrichten zu ermöglichen, muss die Methode "runAsWrapper" der Klasse "AifOutboundProcessingService" angepasst werden.
Der Aufruf von "runAS" (Zeile 22) muss durch "AifOutboundProcessingService::processAsUser(messageIdContainer)" ersetzt werden.

...
try
{
   // runAs currentUser and process all messages in the container.
   new RunAsPermission(runAsUserId).assert();

   // AKU, Enable Debuging for outbound messages - START -->
   // Do not use in production system!!!
   // BP deviation documented
   //runas(runAsUserId,
   // classnum(AifOutboundProcessingService),
   // staticmethodstr(AifOutboundProcessingService, processAsUser),
   // messageIdContainer,
   // runAsCompany);
   AifOutboundProcessingService::processAsUser(messageIdContainer);
   // AKU, Enable Debuging for ourbound message - END -->

   // Revert the permission
   CodeAccessPermission::revertAssert();
}
...

Debuggen von eingehenden Nachrichten

Um das Debuggen von eingehenden Nachrichten zu ermöglichen, muss die Methode "runAsWrapper" der Klasse "AifInboundProcessingService" angepasst werden.
Der Aufruf von "runAS" (Teile 24) muss durch "AifInboundProcessingService::processAsUser(messageIdContainer)" ersetzt werden.

...
try
{
   // Convert to Axapta UserId
   axaptaUserId = AifEndpointUser::getAxaptaUser(runAsUserId).Id;

   new RunAsPermission(axaptaUserId).assert();

   // AKU, Enable Debuging - START -->
   // Do not use in production system!!!
   // BP deviation documented
   //runas(axaptaUserId,
   // classnum(AifInboundProcessingService),
   // staticmethodstr(AifInboundProcessingService, processAsUser),
   // messageIdContainer);
   AifInboundProcessingService::processAsUser(messageIdContainer);
   // AKU, Enable Debuging - END -->

   CodeAccessPermission::revertAssert();
}
...

Für beide Quellcodeänderung sollte noch erwähnt werden, dass diese in einem Produktivsystem nicht durchgeführt werden sollten, da dies Auswirkungen auf die Verarbeitung der Stapelprozesse des AIF's haben könnte.

Das Application Integration Framework von Dynamics AX basiert auf Dokumenten (Axd<Document> Klassen).
Eigene Dokumente lassen sich reicht einfach per Hand oder mit Hilfe des Dokumenten-Wizards erstellen.
In der Version 2009 von Dynamics AX erstellt dieser Wizard auch gleichzeitig den benötigenten Service (WCF-Webservice) und andere benötigte Elemente wie (Serviceklassen und Macros).
Welche Schritte hierfür benötigt werden ist zum Beispiel im Microsoft Dynamics AX Developer Center beschrieben.

Ein kleines Problem entsteht, wenn das neue Dokument, genauer gesagt die Elemente oder Objekte des Dokuments, in einem Layer (zum Beispiel CUS-Layer) entwickelt wird und später, aus welchen Gründen auch immer, alle Objekte des Dokuments (Query, Ax<Table> Class, Axd<Document> Class) in einen anderen Layer (zum Beispiel VAR-Layer) verschoben werden.

Nach der "Verschiebung" des neuen Dokuments in einen anderen Entwicklungslayer werden durch die AIF-Konfigurationsmasken (siehe Maske Dienstleistungen) allerdings keine Operationen (Insert, Update, Delete, FindKey, etc.) mehr angezeigt.
Auch an anderen Stellen, wie zum Beispiel der Endpunktkonfiguration, sind die entsprechenden Operationen nicht mehr auswählbar oder vorhanden.

Der Grund hierfür liegt in der ClassId der Serviceklasse des neuen Dokuments. Dieser, wie auch jedem anderen Objekt, wird beim Import in einen anderen Layer eine neue ID zugewiesen, wenn nicht explizit angegeben wurde, dass der Export und Import mit ID's erfolgen soll. So kann es sein, dass die Klasse mit der ID 40001 nach dem Import in einen anderen Layer die ID 300001 zugeordnet ist.

Da wärend der Konfiguration des AIF's der AOT nach Dokumenten/Services durchsucht wird und für jedes Dokument bzw. jeden Service ein Datensatz in der Tabelle "AifService" sowie ein bis mehrere Datensätze in der Tabelle "AifAction" erzeugt wird, welche alle eine Referenz auf die ClassId der Serviceklasse enthalten, kommt es jetzt zu dem genannten Problem.
Der Id 40001 ist nun keine Klasse oder noch schlimmer eine andere Klasse zugewiesen. Auch eine "Aktualisierung" dieser Datensätze über die Aktualisierungsfunktion, welche auf der Maske Dienstleistungen bereit gestellt wird, führt nicht zum gewünschten Erfolg.

Genau in dieser Funktion scheint sich ein kleiner Fehler eingeschlichen zu haben. Dort wird zwar eine Aktulisierung der ClassId für die Datensätze der Tabelle "AifService", aber nicht für die Datensätze der Tabelle "AifAction", durchgeführt.

Um diese Verhalten zu reproduzieren, muss folgendes gemacht werden:

1. Erstellen eines neuen AIF Dokuments bzw. AIF Services.
2. Über die Maske Dienstleistungen, zu finden unter "Grundeinstellungen -> Einstellungen -> Application Integration Framework -> Dienstleistungen", Funktion "Aktualisieren" das neue Dokument / den neuen Service "aktivieren".
3. Über den Button "Servicearbeitsgänge" können nun alle Operationen welche durch das Dokument / den Service bereit gestellt werden eingesehen werden.
4. Verschieben aller Elemente des Dokuments / des Services in einen anderen Layer.
5. Schritt 2 erneut druchführen.
6. Über den Button "Servicearbeitsgänge" werden keine Operation mehr angezeigt.

Um dieses Problem zu lösen, gibt 2 Möglichkeiten.

Entweder manuelles Löschen alle zu diesem Dokument/Service gehörigen Datensätze der Tabelle "AifAction" oder aber man ergänzt die Methode "registerOperations" der Klasse "AifServiceGenerationManager" um ein wenig X++ Code (bei Zeile 43) welcher nicht nur den Namen der Operation aktualisiert sondern auch die ClassId.
Da dieser Code sehr einfach ist verzichte ich an dieser Stelle auf ein Beispiel.

Leider tritt dieses Problem auch mit Dynamics AX 2009 Service Pack 1 auf.

In Microsoft Dynamics AX werden alle Informationsmeldungen, Warnungen und Fehlermeldungen in einem Fenster, dem so genannten Infolog, ausgegeben.

Wie Informationen, Warnungen oder Fehlermeldungen erzeugt werden können, ist an vielen Stellen bereits beschrieben.
Ein wie ich finde sehr guter Artikel über dieses Thema ist dieser: The user friendly Infolog.

An dieser Stelle soll aber kurz beschrieben werden, wie die Meldungen des Infologs ausgewertet werden können, um zum Beispiel zu ermitteln, ob das Infolog eine Fehlermeldung oder auch eine Warnung enthält.

Zuerst stellt sich die Frage, warum benötigt man überhaupt diese Art von Information da in Dynamics AX die Möglichkeit besteht, verschiedenste Operationen innerhalb einer Transaktion zu Kapsel und diese bei Auftreten eines Fehlers oder Erzeugung einer Fehlermeldung (Stichwort "throw error") automatisch rückgängig zu machen.

Diese Frage soll anhand eines Beispiels beantwortet werden.

Angenommen wir möchten eine Anpassung in Dynamics AX schreiben, welche es ermöglicht, Änderungen an Stücklisten und Arbeitsplänen von Produktionsaufträgen zu automatisieren und alle getätigten Änderungen in einer Transaktion zu kapseln. Anschließend soll noch der Status der Produktions aktualisiert werden. Ebenfalls innerhalb der Transaktion.
Zum Beispiel soll der Produktionsauftrag gestartet werden.

Hierfür ist es notwendig verschiedene Standardfunktionen von Dynamics AX zu verwenden, die bereits eine Fehlerbehandlung implementiert haben und somit keine Fehler mehr "melden", welche den Abbruch einer Transaktion zu Folge haben könnten.
Somit wird zwar gewährleistet, dass alle "Unterfunktionen" in sich richtig auf Fehler richtig reagieren, aber dennoch könnte eine Dateninkonsistenz entstehen, da nicht alle Operationen rückgängig gemacht werden. Es könnte Beispielhaft sein, dass die Anlage von neuen Stücklistenpositionen und/oder Arbeitsgangpositionen funktioniert, die spätere Statusaktualisierung des Produktionsauftrags aber nicht. Die erstellten Stücklistenpositionen und/oder Arbeitsgangpositionen würden im System gespeichert (bleiben).

Abhilfe für dieses Problem kann duch die Auswertung des Infologs und manuellen Aufrufs von "ttsabort" geschaffen werden.

Mit dem "SysInfologEnumerator" können alle Meldungen, welche in das Infolog geschrieben wurden, durchlaufen werden.
Über die Methode "currentException" kann anschließend ausgewertet werden, um was für eine Meldung (Information, Warnung, Fehler) es sich handelt.

Hier ein kurzes Beispiel, wie dies aussehen könnte:

boolean hasError()
{
   SysInfologEnumerator enum;
   SysInfoAction action;
   boolean hasError =false;
   ;
   //Analyse the infolog to see if there are any warnings/errors
   enum= SysInfologEnumerator::newData(infolog.infologData());
   while (enum.moveNext())
   {
      switch (enum.currentException())
      {
         case Exception::Error:
         case Exception::Warning:
            hasError =true;
            break;
      }

      infolog.add(enum.currentException(), enum.currentMessage(), enum.currentHelpUrl());
   }
   return hasError;
}

Es muss allerdings beachtet werden, dass alle Meldungen des Infologs, durch den Aufruf von "SysInfologEnumerator::newData(...)", gelöscht werden.
Sollen diesese Meldungen nach der "Auswertung" dennoch dem Benutzer angezeigt werden, müssen diese wieder manuell in das Infolog geschrieben werden (über "infolog.add(..)").

Im Standard von Microsoft Dynamics AX 2009 werden verschiedenste Business Intelligence Funktionen mitgeliefert.
Die hierfür benötigen Cubes und Dimensionen erstellt Dynamics AX 2009 unter Verwendung der Analysis-Extension direkt in den Analysis Services des SQL Servers.
Dies ist schon einmal sehr schön, da die meiste Arbeit durch die Installationsroutinen abgenommen wird.

Muss oder möchte man allerdings die mitgelieferten Cubes oder Dimensionen an die eigenen Gegebenheiten anpassen, muss zuerst ein BI-Projekt für Visual Studio erzeugt werden, da die Bearbeitung in Visual Studio erfolgt (über die Funktion „BI-Projekt generieren“).

Es können einige „allgemeine“ Einstellungen für die Erstellung eines BI-Projektes über die Funktion „Generierungsoptionen für BI-Projekt“ getätigt werden.
Beispielhaft sei hier die Einstellung der Zeitdimensionen genannt.

Allerdings kann es sein, dass man anstatt der erwartet Maske eine Fehlermeldung ausgegeben bekommt.
Dies kann besonders bei Verwendung, der für Dynamics AX 2009 bereit gestellten, Demo Daten der Fall sein.

Leider ist diese Fehlermeldung nicht sehr Aussagekräftig.

Hier hilft ein Blick in das Ereignisprotokoll des Dynamics AX Object Servers.

Dies lässt zumindest schon einmal den „groben“ Grund erkennen, was für ein Fehler verursacht wurde bzw. wo der Fehler liegen könnte.

Nach einem Blick in die Tabellendefinition und den Tabellebrowser der angegebenen Tabelle „BIUDMROLES“ wird man feststellen, dass es die angegeben Spalte wirklich nicht gibt. Es gibt aber einen Datensatz mit entsprechender UserGroupId (UserGroupId = PRComplete). Verwendet man nun die Funktion „Gehe zu Haupttabelle“, wird man feststellen, dass es diese Benutzergruppe nicht im System gibt.

Somit ist die Lösung recht einfach.
Nachdem der Fehlerhafte Datensatz gelöscht wurde, kann die Maske „Generierungsoptionen für BI-Projekt“ ohne Probleme geöffnet werden.

Wie bestimmt man ein Alias für ein Tabellenfeld in Microsoft Dynamics AX um über mehr als ein Feld die Auswahl des Datensatzes zu bestimmen?

In den Auftragspositionen kann man anstelle einer Artikelnummer auch den Suchbegriff aus dem Artikelstamm eingeben um den gewünschte Artikel auszuwählen.

Beispiel:

Artikelnummer: 12345
Suchbegriff: MeinArtikel

Da, sofern man keine sprechenden Artikelnummern verwendet, ein Suchbegriff oft einprägsamer ist als eine Artikelnummer hat man Systemweit die Möglichkeit anstelle der Artikelnummer „12345“ den Suchbegriff „MeinArtikel“ einzugeben.

Diese Funktion kann man ganz einfach auch selbst erstellen. Hierzu wird auf Tabellenfeldebene in den Eigenschaften des Feldes Suchbegriff, die Eigenschaft AliasFor auf Artikelnummer (ItemId) gesetzt.

Sobald man nun „MeinArtikel“ im Feld Artikelnummer eingibt, wird automatisch die Artikelnummer eingefügt.
Dieses Verhalten ist nun Systemweit anwendbar. Überall wo ein Artikel über die Artikelnummer ausgewählt werden kann (Bspw. Aufträge, Bestellungen) kann nun in der manuellen Eingabe der Suchbegriff verwendet werden. Nach der Eingabe des Suchbegriffs wird dieser durch die Artikelnummer ersetzt (sofern vorhanden).

Microsoft Dynamics AX 2009 bietet die Möglichkeit, den Verlauf eines Dokuments, welches über das AIF exportiert oder importiert wurde zu betrachten.
Dies war auch schon mit Microsoft Dynamics AX 4.0 möglich.

Über die Maske "Dokumentverlauf" können alle Dokumente/Nachrichten eingesehen werden, welche über das AIF verarbeitet wurden.
Über den Button "Korrelation" ist es sogar möglich, die von der Verarbeitung (schreiben, ändern, lesen, etc.) betroffenen Datensätze anzuzeigen.

So ist es zumindest in der Theorie.
In der Praxis sieht es leider etwas anders aus. Nach einem Klick auf den Button "Korrelation" öffnet sich leider nicht wie erwartet die Maske "Dokumentkorrelierung".
Stattdessen wird der Debugger (wenn installiert) geöffnet und die Fehlermeldung ausgegeben, dass ein Objekt nicht über die Methode "extendedTypeId" verfügt.

So wie es scheint, hat sich in den Quellcode ein kleiner Fehler eingeschlichen, welcher dazu führt, dass die Maske "Dokumentkorrelierung" niemals geöffnet werden kann.
Nach einem Vergleich der Funktionalitäten zwischen Dynamics AX 4.0 und Dynamics AX 2009 kann dieses Verhalten (der Fehler) aber wie folgt beschrieben behoben werden.

1. AOT öffnen und zu der Tabelle "AifCorrelation" navigieren.
2. Den Quelltext der Methode "displayEntityKey" anzeigen lassen bzw. diese für die Bearbeitung öffnen.
3. Folgende Quelltextzeile suchen:
   dictField = new DictField(entityKey.parmTableId(), enumerator.currentKey());
4. Dieses Zeile abändern in:
   dictField = new SySDictField(entityKey.parmTableId(), enumerator.currentKey());

Nach dieser kleinen Quelltextänderung sollte alles wie erwartet funktionierten und die Maske "Dokumentkorrelierung" mit den entsprechenden Datensätzen angezeigt werden.

Im wieder taucht in den Newsgroups und einschlägigen Foren die Frage auf, ob es möglich ist, Dynamics AX 2009 unter Windows Server 2008 und/oder in Verbindung mit SQL Server 2008 zu betreiben.

Die Antwort auf diese Frage lautet eigentlich „Ja“, zugleich aber auch „Nein“.

Offiziell sind die beiden Produkte zwar noch nicht für die Verwendung mit Dynamics AX 2009 freigegeben, aber prinzipiell funktioniert Dynamics AX 2009 auch mit dieser Systemkonfiguration (Kernfunktionalität).
Allerdings muss auch erwähnt werden, dass der eine oder andere Punkt bei der Installation bzw. beim Betrieb von Dynamics AX 2009 mit Windows Server 2008 und/oder dem SQL Server 2008 für Verwirrung sorgen kann.

So wird, nach erfolgreicher Installation der Basiskomponenten von Dynamics AX 2009 und anschließendem AOS Start, eine Fehlermeldung im Ereignisprotokoll von Windows Server 2008 erzeugt, welche aussagt, dass Dynamics AX 2009 (genauer der AOS) das gewählte Betriebssystem nicht unterstützt.

Ungeachtet dieser Fehlermeldung, läuft der AOS Dienst von Dynamics AX 2009 unter Windows Server 2008 ohne weitere Probleme. Unschön ist nur, dass diese Meldung bei jedem Start des AOS erzeugt wird.

Für die Verwendung des Enterprise Portals bzw. des Rolecenters muss beachtet werden, dass wie im Installation Guide von Dynamics AX 2009 beschrieben, die Sharepoint Services 3.0 mit SP1 verwendet werden müssen, da frühere Versionen nicht richtig unter Windows Server 2008 laufen.

Ein weiterer Punkt der unbedingt beachtet werden sollte, sind die Reporting-Erweiterungen von Dynamics AX 2009.
Eine Installation der Reporting-Erweiterungen ist derzeit leider nur möglich, wenn die Reporting Services des SQL Server 2005 in der Service Pack Version 2 verwendet werden.
Sollen die Reporting Services des SQL Server 2008 verwendet werden, scheitert es schon an der Installation der Reporting-Erweiterungen von Dynamics AX 2009.
Diese lassen sich in einer solchen Systemumgebung erst gar nicht installieren. Das Setup wird durch eine entsprechende Fehlermeldung abgebrochen.

Dies hat zur Folge, dass die Reporting Services des SQL Server 2008 nicht mit Dynamics AX 2009 verwendet werden können.

Gleiches gilt für die Analysis Extensions von Dynamics AX 2009 in Kombination mit den Analysis Services des SQL Server 2008.
Diese lassen sich zwar ohne Problem installieren, aber eine Verarbeitung der Cubes ist nicht möglich, da diese auf Grund von Verarbeitungsfehlern abgebrochen wird.

Schlussendlich bedeutet dies, dass die Verwendung von Windows Server 2008 als Betriebssystem für Dynamics AX 2009 keine Probleme bereiten sollte.

Für die reinen Datenbankdienste von SQL Server 2008 trifft dies ebenfalls zu. In meinen Test konnte ich keinerlei Probleme beim Betrieb mit Dynamics AX 2009 erkennen.
Anderes gilt für die Reporting und Analysis Services von SQL Server2008. Deren Verwendung ist leider noch nicht möglich und es müssen weiterhin die Reporting und Analysis Services des SQL Server 2005 verwendet werden um alle möglichen Funktionalitäten von Dynamics AX 2009 zur Verfügung stellen zu können.

Im Microsoft Partner Portal stehen die Präsentationsfolien der Vorträge, die beim Dynamics AX Technical Airlift 2008 sowie dem Dynamics ERP-Launch, gehalten wurden zum download bereit.

Die Präsentationsfolien können über folgenden Link gedownloaded werden.
Microsoft Dynamics ERP-Launch und Technical Airlift - Vortragsfolien

Am 9. September 2008 fand der Dynamics Technical Airlift 2008 in Fürstenfeldbruck bei München statt. Wie auch schon im letzten Jahr, richtete sich die Veranstaltung an die eher technisch ausgerichteten Personen (Consultants/Entwickler) aus der Dynamics-Gemeinde.

Ich selbst durfte in diesem Jahr als ATE (Ask the Expert) an dieser Veranstaltung teilnehmen.
Der eine oder andere wird mich in dem orangen Poloshirt gesehen haben.

Insgesamt kann ich nur sagen, es war eine sehr gut organisierte Veranstaltung, auch wenn einige Vorträge, für den einen oder anderen, nicht die gewünschte technische Tiefe hatten.
Auch der gemeinsame Informationsaustausch und die vielen Gespräche mit Personen der Dynamics-Gemeinde haben die Veranstaltung positiv abgerundet.

Da Meinungen ja bekanntlich weit auseinander gehen, möchte ich jeden einzelnen bitten, seine Eindrücke und Meinungen zu dem Dynamics Technical Airlift 2008 zu schildern.
Wer dies nicht "öffentlich", durch die Kommentarfunktion (hier), machen möchte, kann mir auch gerne eine Email schreiben (Email me).

Ich möchte auch die jenigen bitten, die nicht an dieser Veranstalltung teilgenommen haben, mir ein kurzes "Feedback" zukommen zu lassen.
Besonders die Erwartungen an eine solche Veranstaltung und/oder die Community im Allgemeinen würden mich interessieren.

Bitte beachtet, dass alle Kommentare erst durch mich "überprüft" werden müssen, bevor sie angezeigt werden.

Alle frei erhältlichen Dokumente über Microsoft Dynamixs AX 2009 stehen jetzt über Windows Live SkyDrive für jedermann frei zur Verfügung.

Vielen Dank an Arijit Basu, der sich die Arbeit gemacht hat, diese dort zum downlaod zur Verfügung zu stelllen. 

Mehr Informationen hierzu gibt es im Blog von Arijit Basu.

Hier der "direkt" Link zu den Dokumenten: AX 2009 Documents

Wie bereits in diesem Artikel "Auswahl von mehreren Datensätzen in einem Grid-Control (MultiSelect)" beschrieben, kann für ein Grid-Control die Eigenschaft MultiSelect gesetzt werden, womit es ermöglicht wird, dass mehrere Datensätze für eine weitere Verarbeitung ausgewählt werden können.

Dies Funktioniert solange, bis <DataSource>_ds.research() aufgerufen wird. Dieser Aufruf hat zur Folge, dass die Daten der DataSource neu geladen werden und somit auch die Selektierung verworfen wird.

Ein Beispiel wie es nicht funktioniert:

void clicked()
{ 
   CustTable custTable; 
   ; 
   for (custTable = CustTable_ds.getFirst(true) ? CustTable_ds.getFirst(true) : CustTable_ds.cursor(); 
        custTable; 
        custTable = CustTable_ds.getNext()) 
   { 
      //do something with custTable 
      info(custTable.accountNum);
       custTable_ds.research();     
   }
}

Es gilt also genau zu beachten zu welchem Zeitpunkt bzw. an welcher Stelle im Quelltext die Methode <DataSource>_ds.research() aufgerufen wird.

Weiterhin kann es zu Problemen beim MultiSelect kommen, wenn in den Methoden der DataSource ein Aufruf von <DataSource>_ds.research() erfolgt.
Normalerweise werden die DataSource-Methoden für jeden selektierten Datensatz ausgeführt. Wenn aber innerhalb einer der Methoden, wie z.B. Delete(), wird diese Methode nur für den ersten ausgewählten Datensatz ausgeführt und dann ein Research ausgeführt, was wie schon beschrieben zu einem Verwerfen der Selektierung führt.

Microsoft Dynamics AX verwendet für eindeutige Kennungswerte (Id’s) die eingebauten Nummernkreise, für welche ein Feld vom Typ „String“ benötigt wird. Dies macht auch Sinn, da Nummernkreise in Dynamics AX oft ein oder mehrere alphanumerische Zeichen enthalten. Natürlich können auch rein nummerische Nummernkreise mit diesem „Framework“ erstellt werden.

Allerdings sind die Nummernkreise im Dynamics AX Standard nicht ganz optimal bei der Verwendung von einem rein nummerischen Nummernkreisen. Dies fängt z.B. schon beim Datentyp an, der für das ID-Feld der Tabelle verwendet werden muss. Bedingt dadurch, dass ein Feld vom Typ „String“ verwendet werden muss, belegt dieses Feld unnötig viel Speicher in der Datenbank. Weiterhin gestalten sich Sortierungen, Rechenoperationen, etc. erheblich schwieriger.

Diese Probleme können umgangen werden, wenn für das ID-Feld der Datentyp „Integer“ oder „Int64“ verwendet wird. Leider kann nun nicht mehr das Nummernkreis-Framework des Dynamics AX Standards verwendet werden, da dies den Datentyp „String“ für ein ID-Feld vorschreibt.

Es muss also ein eigenes, kleines Nummernkreis-Framework oder ein eigener Nummernkreis geschrieben werden, der die Verwendung des Datentyps „Integer“ für ID-Felder ermöglicht. Dies hört sich zuerst schwierig an, da Dinge wie fortlaufende Nummernvergabe oder die Wiederverwendung von freien Nummern (Löchern im Nummernkreis) berücksichtigt werden sollten.

Es ist aber ganz und gar nicht schwierig, eine eigene Nummernkreisfunktionalität zu erstellen. Das einzige was hierfür benötigt wird ist eine entsprechen aufgebaute Select-Abfrage.

Die nächste Nummer eines Nummernkreises ist immer die zuletzt vergebenen Nummer (höchste) + 1.

   Aku_TestTable t1;
   ;
   select maxof(ID) from t1;
   return t1.ID + 1;

Etwas schwieriger wird es, wenn auch die frei gewordenen Nummern des Nummernkreises wieder vergeben/verwendet werden sollen. Dann muss immer die kleinste Id aus der Tabelle gesucht werden, für die es keinen Datensatz in der Tabelle gibt. Gibt es kein "Nummernloch", muss die nächst höchste Nummer vergeben werden.

   Aku_TestTable t1;
   Aku_TestTable t2;
   ;
   select minof(ID) from t1 notexists join t2 where t2.ID == (t1.ID + 1);
   return t1.ID + 1;

Um diese ein wenig zu verdeutlichen, kann eine beispielhafte Implementierung eines eigenen Nummernkreises in diesem Demoprojekt "SharedProject_AKU_OwnIntNumberSeq" angesehen und runter geladen werden.

Die Benamung von Tabellenfeldern erfolgt über Labels, die in der Feldeigenschaft "Label" festgelegt werden.
Diese Benamung wird immer angezeigt, wenn das Feld in der Applikation angezeigt wird. Es gibt in den Eigenschaften der Tabellenfelder noch die Eigenschaft "GroupPrompt", die die Benamung in Masken festlegt, wenn das Feld innerhalb einer Gruppe angezeigt wird.

Die hinterlegte Benamung in der Eigenschaft GroupPrompt wird immer dann verwendet, wenn das Feld in einer Gruppe dargestellt wird. Das können Tabellenfeldgruppen oder Gruppen, die in Forms erzeugt wurden, sein.

Manchmal ist es möglich, dass beim Starten des Microsoft Dynamics AX 4.0 Clients eine oder meherer Fehlermeldungen in einem Infolog-Fenster ausgegeben werden.

Diese Fehlermeldung könnten z.B. "Corrupted ini file" sein.

Die große Frage ist nun, woher kommt diese Fehlermeldung bzw. wodurch wird diese erzeugt.
Leider ist die Fehlermeldung, welche im Ereignisprotokoll gefunden werden kann, meist auch nicht besonders hilfreich.

Sollten solche, eher unerklärlichen Fehlermeldungen beim Starten des Dynamics AX Client ausgegeben werden, lohnt sich oft ein Blick in die Systemkonfiguration, welche über Verwaltung, Einstellungen, System, Konfiguration aufgerufen werden kann.

Der Grund für diese Fehlermeldung könnte die aktivierte Telefonieintegration des CRM Moduls sein.
Wird diese deaktiviert, sollte die Fehlermeldung nicht mehr erzeugt werden.

In der Screencast Sektion von Channel 9 hat Mey Meenakshisundaram 6 Screencasts über die Entwicklung mit dem Enterprise Portal veröffentlicht.

Microsoft Dynamics AX 2009 – Creating simple List Page in Enterprise Portal
This how-to video demonstrates how to create a simple List Page in Enterprise Portal using AxGridView control.

Microsoft Dynamics AX 2009 – Creating simple Task Page in Enterprise Portal
This how-to video demonstrates how to create a simple Task Page in Enterprise Portal using AxForm control.

Microsoft Dynamics AX 2009 – Creating simple Tunnel(Wizard) Page in Enterprise Portal
This how-to video demonstrates how to create a simple Tunnel(Wizard) Page in Enterprise Portal using ASP.net Wizard control and EP AxForm control.

Microsoft Dynamics AX 2009 – Calling X++ classes in Enterprise Portal User Controls in C#
This how-to video demonstrates how to create a simple X++ Class in AOT and create a C# proxy for this class and call it in Enterprise Portal user control written in C#.

Microsoft Dynamics AX 2009 – Using Record Context in Enterprise Portal
Microsoft Dynamics AX developers will learn how to use record context in Enterprise Portal. Record context is used to pass currently selected record information on a page or Web part to another page or connected Web part. This how-to-video demonstrates three ways of passing record context...

Microsoft Dynamics AX 2009 – Advanced Grid in Enterprise Portal List Page
This how-to video demonstrates how to add ranges in dataset to restrict the data displayed and the different options supported (open,hidden,locked). This also demonstrates how to use display and edit methods defined in the table in the Grid.

Wenn bei der Entwicklung mit Microsoft Dynamics AX 4.0 die Quellcodeverwaltung mittels Visual SourceSafe 2005 eingeschaltet wurde, besteht die Möglichkeit einzelne Versionen eines Objekts miteinander zu vergleichen.

Hierbei kann es aber bei einer "ungünstigen" Konfiguration des lokal Repository-Verzeichnisses sein, dass bei einem Vergleich von zwei Objektversionen die Fehlermeldung "Fehler: Fortsetzen nicht möglich" ausgegeben wird.

Diese Fehlermeldung wird immer erzeugt, wenn sich das lokale Repository-Verzeichnis und das Verzeichnis, in dem die temporären Internetdateien (Temporary Internet Files) gespeichert werden, nicht auf der gleichen Partition (Datenträger) befinden.

Beispiel:

Ordner der Temporary Internet Files = C:\Dokumente und Einstellungen\UserXY\Lokale Einstellungen\Temporary Internet Files
Ordner des lokalen Repositories = D:\VSSRepository\Test

-> Die Fehlermeldung wird ausgegeben.

Ordner der Temporary Internet Files = C:\Dokumente und Einstellungen\UserXY\Lokale Einstellungen\Temporary Internet Files
Ordner des lokalen Repositories = C:\VSSRepository\Test

-> Die Fehlermeldung wird nicht ausgegeben und der Versionvergleich funktioniert problemlos.

Dieses Problem wird durch ein Update für Visual SourceSafe 2005 behoben. Es empfiehlt sich, bei Verwendung der Quellcodeverwaltung mit Visual SourceSafe 2005 als VC-System, dieses Update einzuspielen.

FormControl.heightMode(1);

FormControl.heightMode(FormHeight::ColumnHeight);

FormHeight::Auto
FormHeight::ColumnHeight

FormControl.witdthMode(FormWidth::ColumnHeight);

FormWidth::Auto
FormWidth::ColumnHeight

FormControl.TopMode(0);

FormControl.TopMode(FormTop::Auto);

Mögliche Optionen:

FormTop::Auto
FormTop::ButtomEdge
FormTop::Center
FormTop::TopEdge

FormControl.frameOptionButton(0);

FormControl.frameOptionButton(FormFrameOptionButton::None);

FormFrameOptionButton::None
FormFrameOptionButton::Hide
FormFrameOptionButton::Check
FormFrameOptionButton::Radio

QueryBuildRange.Status(0);

QueryBuildRange.Status(RangeStatus::Hidden);

RangeStatus::Hidden
RangeStatus::Locked
RangeStatus::Open

So nach und nach erscheinen immer mehr Informationen über die Version 2009 von Dynamics AX im Internet.
Hier eine Liste der bereits verfügbaren Quellen:

Install Microsoft Dynamics AX 2009 (Informationen zur Installtion von Dynamics AX 2009)

Using Microsoft Dynamics AX 2009 (Allgemeine Informationen zu Dynamics AX 2009)

Microsoft Dynamics AX 2009 SDK

What's new for Microsoft Dynamics AX 2009 (Änderungen/Neuerungen als download)

The Microsoft Dynamics AX Enterprise Portal Blog (Informationen über das EP, direkt vom MS EP Team)

Für jede Tabelle können Systemfelder wie Erstellt von, Geändert von, Erstellungsdatum, Erstellungszeit oder Änderungsdatum von Dynamics AX aktiviert werden.
Diese Felder werden durch Dynamics AX automatisch gefüllt. Wird zum Beispiel ein neuer Datensatz erzeugt, füllt Dynamics AX die Systemfelder mit den entsprechenden Daten.

Es gibt aber Situationen wo man selber Einfuß auf die Werte dieser Felder nehmen muss. Ein Beispiel hierfür könnte eine Datenübernahme sein, bei der die Informationen über den Ersteller oder das Erstellungsdatum des Datensatzes nicht verloren gehen dürfen.

Wie dies gehen kann zeigt dieses kleine Beispiel:

YourTable table;
;
ttsbegin;

//can only be called on server tier. -> method must be executed on server tier.
new SkipAOSValidationPermission().assert();
table.skipAosValidation(true);

table.YourField ="Value";

table.overwriteSystemfields(true);

//set your own values for the system fields.
table.(fieldnum(Table1, ModifiedDate)) = today() - 2;
table.(fieldnum(Table1, CreatedDate)) = today() - 5;
table.(fieldnum(Table1, CreatedBy)) ="TEST";

table.insert();
ttscommit;

table.skipAosValidation(false);

Allerdings können die Systemfelder nur beim Erstellen eines neuen Datensatzes "von Hand" festgelegt werden.

Wie das Ändern von Werten der Systemfelder bei bereits bestehenden Datensätzen geht demonstriert die Klasse "BatchRun", Methode "runJob" und "finishJob".
Kurz gesagt wird genau genommen der Datensatz nicht geändert, sondern es werden nur die Daten des bestehenden Datensatzes in den neuen Datensatz kopiert (mit newBuffer = oldBuffer.data()) und dann wie bereits beschrieben die Systemfelder mit eigenen Werten befüllt. Dann wird der bestehnde Datensatz gelöscht und der neue Datensatz in die Datenbank geschrieben.

So nach und nach sind immer mehr Informationen über die nächste Version von Microsoft Dynamics AX im Internet erhältlich, die einen ersten Einblick in das verschaffen, was alles an Neuerungen mit Dynamics AX 2009 kommt.

Arijit Basu hat in seinem Blog einen Artikel über einige der Änderungen gepostet.
Der Artikel beschreibt unter Anderem die Änderungen am Benutzerinterface, das neue Role Center, die neuen Workflow-Features sowie die Erweiterungen am Enterprise Portal.

Weiterhin ist auf Channel9 ist ein Video zu finden, welches das Enterprise Portal von Dynamics AX 2009 und dessen System-Architektur erläutert.
Es wird gezeigt, wie eigene Controls (mit ASP.NET) für das Enterprise Portal erstellt werden können und wie diese in das Enterprise Portal sowie das Role-Center eingebunden werden können.

Häufig werden Optionen (Ja/Nein-Fragen) in Microsoft Dynamics AX durch ein CheckBox Control und einem entsprechendem Feld einer Tabelle abgebildet.

Ein gutes Beispiel hierfür ist die Maske „Lagerparameter“, Reiter „Lagerungsdimensionen“. Hier kann eingestellt werden, welche Lagerungsdimension wo im System angezeigt werden soll. Zur Speicherung der gewählten Einstellungen wird die Tabelle „InventDimSetupGrid“ verwendet. Diese Tabelle enthält für jede Option jeweils ein Feld (abgeleitet vom Enum „NoYes“).
Diese Art der Speicherung von Optionswerten ist sicherlich sehr leicht zu verstehen und auch sehr einfach zu erstellen. Da aber für jede Option ein Feld in der Tabelle angelegt werden muss, kann dies relativ zeitaufwendig sein.

Es besteht aber die Möglichkeit, Optionswerte in nur einem Feld zu speichern. Diese Art der Speicherung kann unter Umständen sogar als die elegantere angesehen werden, da z.B. für einen Datensatz weniger Speicher in der Datenbank benötigt wird.

Um dies zu realisieren, wird als erstes ein Feld vom Typ „int“ in der Tabelle benötigt. Dieses Feld dient als Datenspeicher für alle benötigten Optionswerte (Ja oder Nein). Jedes Bit dieses „int“ Feldes stellt genau einen Optionswert und somit eine Option dar. Um nun die gewählten Werte der Optionen speichern zu können, müssen diese mit Bit-Operationen (right / left shift, binary and, etc.) in das „int“ Feld geschrieben werden.

Das Feld "bitMask" wird in dieser Darstellung als Datenspeicher der Optionswerte verwendet.

Auf einer Maske werden alle Optionen als einzelne CheckBoxen bereit gestellt.

Da diese Art der Speicherung in Dynamics AX nicht besonders oft verwendet wird und Quellcode oft mehr sagt als (nur) ein langer Artikel, habe ich ein kleines „Tutorial“ erstellt, um die benötigten Schritte zu beschreiben.

Eine Erklärung aller Bit-Operatoren ist im Microsoft Dynamics AX Developer Center zu finden.

Im Microsoft Dynamics AX Developer Center wurde für Dynamics AX Entwickler eine neue Webcast Serie gestartet.

Auszug:

"On this page you will find videos designed for all Microsoft Dynamics AX developers, from the novice to the professional. New videos are added regularly, so check back often."

Derzeit ist nur ein Webcast über "Dynamics Links between parent and child Forms" erhältlich.
Gilt zu hoffen, dass in der nächsten Zeit noch weitere nützliche Webcast folgen.

Wie kann man zur Laufzeit den FormControlType einer beliebigen FormControl ermitteln?

Eine Methode auf der FormControl scheint nicht zu existieren, wie kann also der Typ einer FormControl mittels X++ ermittelt werden?
Mit Hilfe der Klasse SysFormRun ist dies möglich.

Hierzu ein kleines Stück Quellcode als Beispiel.

FormControlType formControlType;
;
formControlType = SysFormRun::controlType(classidget(MeineFormBuildControl));

Eine Listbox ist einfach erstellt. Entweder man benutzt eine datengebundene Listbox, indem einfach die Datasource und DataField/ DataMethod im FormControl festgelegt wird oder man befüllt die Listbox manuell.

Das manuell befüllen der Listbox aus einem Tabellenfeld sieht dann beispielsweise so aus:

void initListBox()
{
counter elementCnt;
str elementStr;
;
meineListBox.clear();
for (elementCnt = 1; elementCnt <= conlen(Tabelle.ContainerFeld); elementCnt++)
{
meineListBox.add(onpeek(Tabelle.ContainerFeld, elementCnt));
}
}

Über die angegebene Methode werden alle Elemente des aktuellen Containers der Tabelle in die Listbox übertragen.

Hierbei bin ich auf ein seltsames Verhalten der Listbox gestossen.
Im aktuellen Fall ist die Darstellung der Listbox einwandfrei. Beim Datensatz wechsel habe ich die Listbox mit den neuen Werten befüllen können. Alles war gut.

Bis auf die Tatsache, dass ich bei der Auswahl in der Listbox nicht das ausgewählt Element angezeigt bekam. Es wurde immer das erste angezeigte Element der ListBox gewählt.

Nachdem die Datasource aus der FormGroupControl entfernt wurde, funktionierte alles wieder wie erwartet und gewünscht.

Um die FormDataSource einer Form anzusprechen benutzt man das Suffix _ds. So erhält man in der Maske CustTable mit

CustTable_ds

den Zugriff auf die FormDatasource der CustTable.

Es gibt aber noch andere Suffixe, die nicht so häufig verwendet werden und mir bis dato auch unbekannt waren.
So erhält man mit dem Suffix _q oder _qr Zugriff auf die Query oder QueryRun der aktuellen FormDataSource.

Das heisst, das mit

CustTable_q

die Query der FormDataSource CustTable und mit

CustTable_qr

die QueryRun der FormDataSource CustTable direkt angesprochen wird.

Hiermit kann man sich also verschiedene Deklarationen oder Zuweisungen sparen und hat direkten Zugriff auf diese Objekte.

• FormDataSource = Zugriff auf den Datensatzpuffer
• FormDataSouceName_DS = Zugriff auf FormDataSource
• FormDataSourceName_Q = Zugriff auf Query der FormDataSource
• FormDataSourceName_QR = Zugriff auf QueryRun der FormDataSource

Das Erstellen von Produktionsaufträgen sollte an sich kein Problem darstellen. Leider ist dem nicht ganz so.

Anders als in anderen Modulen (z.B. Aufträge) von Dynamics AX, existiert hierfür keine Klassenstruktur, welche die entsprechenden Funktionen bereit stellt.
Der Dynamics AX Standard erstellt Produktionsaufträge immer über die Maske „ProdTableCreate“. Es gibt aber Situationen, wo für die Erstellung eines Produktionsauftrages keine Maske verwendet werden kann. Ein Beispiel hierfür könnte eine Schnittstelle sein, welche über eine Textdatei die zu produzierenden Waren einließt und entsprechende Produktionsaufträge im System generiert.

Die Frage ist nun, wie erstellt man Produktionsaufträge per Quellcode, damit diese auch „richtig“ im System erzeugt werden (inkl. Stückliste, Arbeitsplan und Lagerbuchung).

• Zuerst muss der Produktionsauftrag mit den Daten des zu produzierenden Artikels initialisiert werden.
• Weiterhin müssen Produktionsmenge und Lieferdatum festgelegt werden.
• Ebenfalls sind die zu verwendende Stückliste und der Arbeitsplan zu definieren.
• Und als letzter Schritt muss der Produktionsauftrag noch erzeugt werden.

Hierbei gilt es aber zu beachten, dass die Erstellung (Speichern in der Datenbank) nicht mit der Methode „insert“ der Tabelle „ProdTable“ geschieht, sondern dass hierfür die Klasse „ProdTableType“ und deren Methode „insert“ verwendet wird. Nur so wird die entsprechende Lagerbewegung / Lagerbuchung im System erzeugt und wenn notwendig Referenzen zu einem Verkaufsauftrag oder einer anderen Produktion hinterlegt.

Um dies zu veranschaulichen ein kurzes Beispiel, in welchem ein neuer Produktionsauftrag erstellt wird.

static void CreateProductionOrder(Args _args)
{
    //Die zu produzierende Menge
    ProdQtySched productionQty = 1;
    //Der zu produzierende Artikel
    ItemId productionItem ="Artikelnummer";

    ProdTable prodTable;
    InventTable inventTable;
    ;
    inventTable = InventTable::find(productionItem);

    //Initialisierung des Produktionsauftrags
    prodTable.initValue();
    prodTable.ItemId = inventTable.ItemId;
    prodTable.initFromInventTable(inventTable);

    //Lieferdatum festlegen
    prodTable.DlvDate = today();

    prodTable.QtySched = productionQty;
    prodTable.RemainInventPhysical = prodTable.QtySched;

    //Die zu verwendende Stückliste und Arbeitsplan bestimmen
    prodTable.initRouteVersion();
    prodTable.initBOMVersion();

    //Produktionsauftrag erstellen
    prodTable.type().insert();
}

Selbstverständlich sind auch weitere Angaben bei der Erstellung des Produktionsauftrags möglich.
Z.B. kann ein Produktionsauftrag auch aus einer Verkaufsauftragsposition erzeugt werden (bei Verwendung der Methode "initFromSalesLine").

Mit Hilfe von SysDictClass kann man wertvolle Erkenntnisse über Klassen gewinnen und abfragen.
Ich habe einige Dinge, die ich am häufigsten gebrauche, anhand einfacher Beispiele zusammengetragen.

Dieses kleine Stück Quellcode ermittelt alle abgeleiteten Klassen der Klasse FormControl.

SysDictClass formCtrlClss;
ListEnumerator listEnumerator;
;

formCtrlClss =new SysDictClass(classnum(FormControl));

listEnumerator = formCtrlClss.extendedBy().getEnumerator();

while (listEnumerator.moveNext())
{
formCtrlClss =new SysDictClass(listEnumerator.current());
print formCtrlClss.name();
}
pause;

Diese Funktionalität wird auch im Standard von Microsoft Dynamics AX verwendet, um alle möglichen Funktionen der Stabelverarbeitung abzufragen/ zu ermitteln.

Man kann natürlich auch ermitteln, von welcher Klasse(n) die aktuelle Klasse abgeleitet ist.

SysDictClass dictClass =new SysDictClass(classnum(SalesFormLetter_Invoice));
;
while (dictClass.extend())
{
dictClass =new SysDictClass(dictClass.extend());
print dictClass.name();
}
pause;

Um zu ermitteln, ob eine Klasse von einer bestimmten Klasse abgeleitet wurde, muss folgendes geschrieben werden.

SysDictClass dictClass =new SysDictClass(classnum(SalesFormLetter_Invoice));
;
// Überprüfen ob die Klasse von der Klasse Object abgeleitet ist
print dictClass.isExtending(classnum(Object));
// Überprüfen ob die Klasse von der Klasse FormControl abgeleitet ist
print dictClass.isExtending(classnum(FormControl));
pause;

Es kann auch auf die Methoden der Klasse zugegriffen werden.

SysDictClass dictClass =new SysDictClass(classnum(SalesFormLetter_Invoice));
;
//Statische Methode der Klasse SalesFormLetter_Invoice aufrufen, wenn vorhanden
if (dictClass.hasStaticMethod("Description"))
print dictClass.callStatic("Description");

//Methode der Klasse SalesFormLetter_Invoice aufrufen, wenn vorhanden
if (dictClass.hasObjectMethod("canGoBatchJournal"))
print dictClass.callObject("canGoBatchJournal", dictClass.makeObject());

pause;

Das ist nur ein Teil der Funktionen, die ich persönlich am Wichtigsten empfinde und hin und wieder benötige.

In Foren, Newsgroups oder auch in persönlichen Gesprächen ergibt sich oft die Frage, wo man anfangen soll/kann um den Umgang mit Microsoft Dynamics AX zu lernen.

Gerade für Einsteiger oder Anfänger ist es machmal schwer, die Informationen zu finden, die gerade benötigt werden. Dank der Dynamics AX Community, welche zum Glück immer größer und besser wird, stellt das Internet mit seinen vielen Dynamics AX Blogs, Foren, Newsgroups und nicht zuletzt dem Microsoft Dynamics AX Developer Center eine sehr gut Informationsquelle dar.

Trotzdem hört man oft die Frage, ob es denn keine Bücher über Microsoft Dynamics AX gibt. Um etwas mehr Klarheit zu schaffen, welche Bücher über Microsoft Dynamics AX erhältlich sind, hier eine Liste aller Bücher die mir bekannt sind:

• Inside Microsoft Dynamics AX 4.0
• Quality Assurance for Dynamics AX-Based ERP Solutions
• Dynamics AX. A Guide to Microsoft Axapta
• Grundkurs Microsoft Dynamics AX 4.0
• Successfully Implementing Microsoft Dynamics
• Using Microsoft Dynamics AX
• Microsoft Dynamics Ax Interview Questions
• Microsoft Dynamics Ax 5.0 Programming Unleashed

Ich habe die Erfahrung gemacht, dass FormControls, die zur Laufzeit direkt auf dem Design der Form erzeugt wurden, sich meisst am rechten Rand befinden.

Sollen diese FormControls nun aber nicht am Rechten, sondern am Linken Rand erscheinen, kann man dieses natürlich schon beim Erzeugen dieser Controls mittels

FormGroupControl.leftMode(FormLeft::LeftEdge) 

festlegen.

Die Probleme treten dann auf, wenn mehrere FormControls erzeugt werden und diese am Linken Rand erscheinen sollen.

Werden nun alle FormControls mit FormControl.leftMode(FormLeft::leftEdge) an den Linken Rand verschoben, erhält man dann unter Umständen erstaunliche Ergebnisse – nur nicht die Gewünschten.

FormControl.moveControl(int _controlId [, int _insertAfterId = 0])

Wird nur 

ÜbergeordneteFormControl.moveControl(ControlIDderzuveschiebenenControl)

Soll das FormControl hinter einem bestimmten FormControl innerhalb desselben übergeordneten FormControls platziert werden, wird

Übergeordnete.moveControl(ControlIDderzuveschiebenenControl, ControlIDhinterDerdieControlangefügtwerdensoll)

benutzt.

Mit .moveControl() können auch FormControls in das übergeordnete Control eingefügt werden, die vorher nicht in dem übergeordneten Control enthalten waren. 

Anbei eine einfache Form, die schon ein FromGroupControl mit zwei Controls enthält,  bei der zur Laufzeit zwei neue Controls hinzugefügt werden und die mittels Button nach links verschoben werden.

In Kürze soll ein neues Buch über Microsoft Dynamics AX erscheinen. Im Schwerpunkt soll es sich mit dem Thema Qualitätssicherung beschäftigen. Titel des Buchs ist "Quality Assurance for Dynamics AX-Based ERP Solutions".

Ein Auszug der einzelnen Themenpunkte:

Das Buchen von Bestellungen in Microsoft Dynamics AX geschieht über die Klasse „PurchFormLetter“ bzw. einer ihrer konkretisierten (abgeleiteten) Klassen. Jeder Buchungstyp (z.B. Bestätigung oder Rechnung) ist durch eine eigene Klasse abgebildet, welche von der Basisklasse „PurchFormLetter“ abgeleitet ist (siehe Abbildung).

Abbildung 1 - Klassenhierarchie der Klasse „PurchFormLetter“

Vergleicht man die Klassenhierarchie der „PurchFormLetter“ Klassen mit der Klassenhierarchie der „SalesFormLetter“ Klassen, so ist zu erkennen, dass auch das Buchen von Bestellungen vom Prinzip her genau so funktioniert wie das Buchen von Aufträgen (Vergleiche hierzu: Microsoft Dynamics AX API – Teil 3 „Buchen von Aufträgen“).

Deswegen sind auch für das Buchen von Bestellungen im Wesentlichen nur zwei Schritte notwendig.

1. Über die Methode „construct“ der Klasse „PurchFormLetter“ ein dem Buchungstyp einsprechendes Objekt erzeugen.
2. Über den Aufruf der Methode „update“ die Bestellung buchen.

Hierzu ein Beispiel (Buchen des Lieferscheins für eine Bestellung):

static void PurchPostPackingSlip(Args _args)
{
   PurchFormLetter purchFormLetter;
   PurchTable purchTable;
   PurchId purchId;
   Num packingSlipId;
   ;
   //Angabe der Bestellung, für welche der Lieferschein gebucht werden soll.
   purchId ="00244_049";
   purchTable = PurchTable::find(purchId);

   //Bestimmen des Buchungstyps durch Angabe des DocumentStatus (Lieferschein).
   purchFormLetter = PurchFormLetter::construct(DocumentStatus::PackingSlip);

   //Festlegen der externen Lieferscheinnummer.
   packingSlipId ="EXT-100155L";

   //Buchen des Lieferscheins.
   purchFormLetter.update(purchTable,
                          packingSlipId,
                          SystemDateGet(),
                          PurchUpdate::All,
                          AccountOrder::Auto,
                          NoYes::No,
                          NoYes::No,
                          NoYes::No,
                          NoYes::No);
}

Einziger Unterschied zu den Auftragsbuchen ist, dass bei der Buchung einer Bestellung die „externe“ Nummer des Belegs (Lieferscheinnummer, Rechnungsnummer, etc.) angegeben werden muss.

Analog zu den Auftragsbuchen, sind auch beim Buchen von Bestellungen umfangreichere oder etwas speziellere Buchungsszenarien möglich (Vergleiche hierzu: Microsoft Dynamics AX API – Teil 3 „Buchen von Aufträgen“).

Alexei Eremenko hat auf seinem Blog einige Artikel über die kommende Version von Microsoft Dynamics AX und dessen neue Features veröffentlicht. Da diese leider in Russich geschrieben sind, hier eine kurze Zusammenfassung:

• Aus Microsoft Dynamics AX 5.0 wird Microsoft Dynamics AX 2009.
• Geänderte Benutzeroberfläche (Office 2007 Style, inkl. Ribbon's).
• Neue "Funktion" Rollcenter, die dem Benutzer schnellen Zugriff auf die, für seine Arbeit, relevanten Daten geben soll.  
• Unterstützung des UNION Befehl's für SQL Abfragen, bei Verwendung der Query-Klassen.
• Neuer Exception-Typ "DublicateKeyException" zur Ausnahmebehandlung wenn ein Datensatz schon besteht.
• Die SQL DML bulk Anweisungen erlauben die Verwendung von Inner- und Outer-Joins.
• Zugriff auf das Ergebnis der "update_recordset" Anweisung, um zu bestimmen wie viele Datensätze durch die Operation geändert wurden.
• CrossCompany-Unterstützung für Datenbankabfragen (Daten aus unterschiedlichen Mandaten können in einer SQL Anweisung behandelt werden).

Wer die orginalen Artikel einmal selber lesen möchte, findet die einzelnen Blog-Posts hier:
(Die Links verweisen auf die Übersetzung der Artikel ins Englische)

• What's new in Microsoft Dynamics AX 2009?
• DAX 2009, which in conjunction with the new database?
• DAX 2009, working with several companies

Für ein Grid-Control kann über die Einstellung "MultiSelect" gesteuert werden, od dieses Control die Auswahl von mehr als einem Datensatz erlaubt.

Gültige Einstellungen sind:
Yes - Es können mehrere Datensätze ausgewählt werden.
No - Es kann immer nur ein Datensatz ausgewählt werden.

Auswahl eines Datensatzes

Auswahl mehrerer Datensätze

Zugriff auf die aktuelle Selektion (einer oder mehrere) erhält man wie folgt beschrieben:

Ist nur ein Datensatz markiert, bzw. soll mit einfacher Auswahl gearbeitet werden (MultiSelect = No), kann der ausgewählte Datensatz über den aktuellen DataSource-Cursor der Grid-Control DataSource ermittelt werden.
Der DataSource-Cursor steht immer auf dem zu letzt ausgewählten Datensatz eines Grid-Control's.

Beispiel:

void clicked()
{
   //CustTable ist die DataSource des Grid-Controls 
   ;
   //Datenoperationen für den Datensatz ausführen.
   //Do something....
   info(CustTable.AccountNum);   

   //Angezeigte Datensätze im Grid Control aktualisieren
   element.lockWindowUpdate(true);
   CustTable_ds.research();
   element.lockWindowUpdate(false);
}

Soll eine Mehrfachauswahl möglich sein, reicht der Zugriff auf den aktuellen DataSource-Cursor nicht mehr aus. Um alle ausgewählten Datensätze der DataSource zu erhalten, muss diese mit einer Schleife unter Verwendung der Methoden "getFirst" und "getNext" durchlaufen werden. Hilfreich hierbei ist die Methode "anyMarked", mit welcher ermittelt werden kann ob mehrere Datensätze ausgewählt sind oder nicht.

Auch hierfür ein Beispiel:

void clicked()
{
   CustTable selectedCustTable;
   Common currentRecord;
   ;
   if (CustTable_ds.anyMarked()) //Es sind meherer Datensätze selektiert.
   {
      //Ersten selektierten Datensatz ermitteln.
      selectedCustTable = CustTable_ds.getFirst(1);

      while(selectedCustTable)
      {
         //Datenoperationen für den Datensatz ausführn.
         //Do something....
         info(selectedCustTable.AccountNum);

         //Nächsten selektieren Datensatz ermitteln.
         selectedCustTable = CustTable_ds.getNext();
      }
   }
   else//Nur ein Datensatz ist selektiert.
   {
      //Selektierten Datensatz ermitteln.
      currentRecord = CustTable_ds.cursor().data();
      selectedCustTable = CustTable_ds.cursor();

      //Datenoperationen für den Datensatz ausführen.
      //Do something....
      info(selectedCustTable.AccountNum);
   }

   //Angezeigte Datensätze im Grid Control aktualisieren   
   element.lockWindowUpdate(true);
   CustTable_ds.research();
   CustTable_ds.findRecord(currentRecord);
   CustTable_ds.refresh();
   element.lockWindowUpdate(false);
}

Von Zeit zu Zeit ist es hilfreich sich den Abfragebefehl, der durch eine Query erzeugt wird, zur Laufzeit anzusehen.

Leider unterstützt der Debugger von Microsoft Dynamics AX das Debuggen von Querys nicht. Ein Datenbanktrace durchzuführen ist auch nicht immer sinnvoll, da man durch das Traceprotokoll keine direkte "Verbindung" von Abfragebefehl und Query einsehen kann.

Einen Workaround hierfür gibt es aber.

Die Methode "toString" einer Query DataSource gibt den Abfragbefehl, der durch die Query an die Datenbank geschickt wird, zurück. Dieser kann dann, durch die statischen Methoden des "Debug" Objekts, im Debuggers ausgegeben bzw. angezeigt werden.

Ein Beispiel:

debug::printDebug(query.dataSourceTable(tablenum(CustTable)).toString())

Weiterhin ist unter http://www.axaptapedia.com/DEV_QueryBrowser ein Tool für die Analyse von Querys erhältlich. Dieses Tool funktioniert ähnlich wie der Tablebrowser von Dynamics AX. Mit dem Tool können nicht nur der Abfragebefehl, der durch eine Query erstellt wird, sondern auch die von der Query ermittelten Daten betrachtet und ausgewertet werden.

Eine ausreichende Beschreibung zur Verwendung des Tool's ist ebenfalls auf Axaptapedia (siehe Link weiter oben) zu finden.

Einen ersten Ausblick auf die "neuen" Quellcodeverwaltungsfeatures in Microsoft Dynamics AX 5.0 zeigt der Screencast "Version control in MorphX" auf Channel9.

http://channel9.msdn.com/Showpost.aspx?postid=367024

Ich zitiere:
"This screencast is a preview of the version control system integration options in the next release of MorphX - the IDE of Dynamics AX.
It shows a side-by-side comparison of the integration options with Team Foundation Server, Visual Source Safe, and MorphX VCS. 
The latter is a simple, yet powerful alternative without any additional infrastructure requirements. The last half of the screencast gives a demonstration of MorphX VCS."

Durch die neuen Features die MorphX VCS mit sich bringt, sowie die Möglichkeit Visual Studio Team System, oder genauer der Team Foundation Server, (nicht nur) als Quellcodeverwaltung zu verwenden, sollte nun für jeden ein "passendes" Quellcodeverwaltungsystem bereit stehen.

Vielen Dank an dieser Stelle an Michael Fruergaard Pontoppidan (http://blogs.msdn.com/mfp/default.aspx) für diesen und die bisherigen Screencasts über Microsoft Dynamics AX. 

Die Version 4.0 von Microsoft Dynamics AX enthält eine neue Funktion ("Nach Raster filtern" oder "Filter by Grid") mit der die Datenfilterung direkt in einem Grid ermöglicht wird.

Die Funktion "Nach Raster Filtern" kann entweder über die Tastenkombination "STRG + G", über die Symbolleiste oder den Menüpunkt "Bearbeiten - Filtern - Nach Raster filtern" aktiviert werden.

Das "Nach Raster filtern" ist per Standard deaktiviert und muss somit immer manuell durch den Benutzer aktiviert werden. Leider wird in den benutzerspezifischen Einstellungen für eine Maske nicht gespeichert ob das "Nach Raster filtern" aktiviert oder deaktiviert ist. Somit muss die Funktion, wenn diese verwendet werden soll, für jede Maske und nach jedem Schließen einer Maske erneut aktiviert werden.

Soll nun für eine Maske die Funktion "Nach Raster filtern" dauerhaft aktiviert sein, ist eine kleine Anpassung im Quelltext der Maske notwendig.

Als erstes muss die Eigenschaft "AutoDeclaration" für das Grid Control, bei welchem die Funktion "Nach Raster filtern" aktiviert werden soll, auf "Yes" gesetzt werden. Weiterhin muss die Methode "run" der Maske, nach dem Aufruf von "super", um diese Quellcodezeilen ergänzt werden:

Grid.enter();
this.task(2855);

"Grid" ist hierbei der Name des Grid Controls, für welches die Funktion "Nach Raster filtern" aktiviert werden soll.

Soll gleichzeitig noch ein Filter für die Datensätze aktiviert werden, erfolgt dies über die Ranges der Datasource-Querys. Hierbei kann wie gewohnt eine Range für die entsprechende Query definiert werden. Wird die Range für ein Feld gesetzt, welches in dem Grid Control angezeigt wird, wird der Wert der Range entsprechend in der "Filterzeile" angezeigt.

Man kann viel darüber lesen, dass es ab der Version 4.0 von Microsoft Dynamics AX möglich ist auch mit .NET Objekten innerhalb von Dynamics AX zu arbeiten. Leider fehlt es oft an konkreten Beispielen, die einen ersten Überblick geben, wie man was machen muss.

Jeder der sich mit dem Thema schon einmal auseinander setzen musste, wird mit hoher Wahrscheinlichkeit auf eines dieser „Probleme“ gestoßen sein:

• Wie kann ein Datum zwischen Dynamics AX und .NET ausgetauscht werden?
• Wie kann die aktuelle Zeit an ein .NET Objekt übermittelt werden?
• Wie rufe ich eigentlich Werte eines .NET Enums ab?

Diese Liste könnte man noch beliebig erweitern.

Damit man einen kleinen Anhaltspunkt hat, wie die „Arbeit“ mit .NET Objekten gehen kann, soll dies anhand des Beispiels „Anlegen eines Termins in Outlook“ vorgestellt werden.

Zuerst muss eine Referenz zur der .NET Assembly erstellt werden, welche im Weitern verwendet werden soll. Hierzu muss im AOT der Zweig „References“ gewählt werden und über das Kontextmenü „Verweis hinzufügen“ ausgewählt werden.

In der neuen Maske wird die Assembly ausgewählt zu der eine Referenz erstellt werden soll. Hierzu navigiert man zu der entsprechenden Assembly und wählt diese über „Auswählen“ aus. Mit dem Drücken von „OK“ werden zu den ausgewählten Assemblys die Referenzen erstellt.

Bei diesem Beispiel wurde eine Referenz zur Assembly „Microsoft.Office.Interop.Outlook“ erstellt.

Ab jetzt können alle .NET Objekte, die in dieser Assembly enthalten sind, in Dynamics AX verwendet werden.

Wie dies im Einzelnen geschieht kann dem folgenden Beispiel entnommen werden, wo demonstriert wird, wie man aus Dynamics AX heraus ein Outlook Termin erstellt werden kann.

static void CreateOutlookAppointment(Args _args)
{
   //.NET (CLR) Datentypen
   InteropPermission permission;
   Microsoft.Office.Interop.Outlook._Application outlookApplication;
   Microsoft.Office.Interop.Outlook._AppointmentItem outlookAppointment;
   Microsoft.Office.Interop.Outlook.OlItemType outlookItemType;
   System.DateTime appointmentStartTime;
   System.DateTime appointmentEndTime;

   //Dynamics AX Datentypen
   Date1980 startDate, endDate;
   TimeExpected startTime, endTime;
   ;
   permission =new InteropPermission(InteropKind::ClrInterop);
   if (permission == null)
   {
      return;
   }
   //”Unsichere” Aufrufe starten
   permission.assert();

   //Das Outlook Application Objekt instanzieren
   //(Beispiel für Erstellung eines .NET Klassenobjekts)
   outlookApplication =new Microsoft.Office.Interop.Outlook.ApplicationClass();

   //Gewünschten Outlook-Elementtyp auswählen
   //(Beispiel für Zuweisung eines .NET Enum Wertes)
   outlookItemType = ClrInterop::parseClrEnum('Microsoft.Office.Interop.Outlook.OlItemType', 'olAppointmentItem');

   //Gewünschten Outlook-Elemnttyp erstellen (Termin)
   outlookAppointment = outlookApplication.CreateItem(outlookItemType);

   //Den Betreff zuweisen
   //(Beispiel für Zuweisung eines "einfachen" Wertes)
   outlookAppointment.set_Subject("Ein Test aus Dynamics AX");

   startDate = str2Date("25.10.2007", 123);
   startTime = str2Time("10:30:00");
   //"Beginnt um" zuweisen
   //(Beispiel für Konvertierung Dynamics AX Datum/Zeit -> .NET DateTime)
   appointmentStartTime = System.Convert::ToDateTime(strfmt("%1 %2", startDate, time2str(startTime, 0, 0)));
   outlookAppointment.set_Start(appointmentStartTime);

   endDate = str2Date("26.10.2007", 123);
   endTime = str2Time("11:00:00");
   //"Endet um" zuweisen
   appointmentEndTime = System.Convert::ToDateTime(strfmt("%1 %2", endDate, time2str(endTime, 0, 0)));
   outlookAppointment.set_End(appointmentEndTime);

   //Den Termin speichern (ab jetzt ist der Termin in Outlook zu sehen)
   outlookAppointment.Save();

   //”Unsichere” Aufrufe beenden
   CodeAccessPermission::revertAssert();
}

Das Buchen von Aufträgen in Microsoft Dynamics AX geschieht über die Klasse „SalesFormLetter“ bzw. einer ihrer konkretisierten (abgeleiteten) Klassen. Jeder Buchungstyp (z.B. Bestätigung, Lieferschein, Rechnung) ist durch eine eigene Klasse abgebildet, welche von der Basisklasse „SalesFormLetter“ abgeleitet ist (siehe Abbildung).

Um einen Auftrag per Programmcode zu buchen, muss ein Objekt der Klasse „SalesFormLetter“ erstellt werden.

salesFormLetter = SalesFormLetter::construct(DocumentStatus::Confirmation);

Dies geschieht, wie Allgemein in Microsoft Dynamics AX üblich, über die “construct” Methode der Klasse. Als Parameter muss dieser Methode die gewünschte Art der Buchung (z.B. Bestätigung, Lieferschein, Rechnung) angegeben werden. Die „construct“ Methode erzeugt ein,der Buchungsart entsprechendes, Objekt und gibt dieses zurück (In diesem Fall wird ein „SalesFormLetter_Confirm“ Objekt erzeugt).
Die eigentliche Buchung wird über die Methode „update“ aufgerufen. Da dieser Methode alle für die Buchung notwendigen Daten als Parameter übergeben werden können, ist eine einzelne Zuweisung von z.B. dem Auftrag, welcher gebucht werden soll, nicht notwendig.

Hierzu ein Beispiel:

// --- Buchen ohne Ausdruck ---
static void PostingConfimation(Args _args)
{
   SalesFormLetter salesFormLetter;
   SalesTable salesTable;
   SalesId salesId;
   PrintJobSettings printJobSettings;
   ;
   //Angabe des Auftrags, welcher gebucht werden soll.
   salesId ="00423_036";
   salesTable = SalesTable::find(salesId);

   // Bestimmen des Buchungstyps durch Angabe des DocumentStatus
   salesFormLetter = SalesFormLetter::construct(DocumentStatus::Confirmation);

   //Buchen des Auftrags (aber nicht Drucken).
   salesFormLetter.update(salesTable,
                          SystemDateGet(),
                          SalesUpdate::All,
                          AccountOrder::None,
                          NoYes::No,
                          NoYes::No);
}

Bei diesem Beispiel ist gut zu sehen, dass für die Buchung eines Auftrags im Wesentlichen nur zwei Schritte notwendig sind.

1. Über die Methode „construct“ ein dem Buchungstyp einsprechendes Objekt erzeugen.

2. Über den Aufruf der Methode „update“ den Auftrag buchen.

Natürlich können auch noch umfangreichere oder etwas speziellere Buchungsszenarien mit der Klasse „salesFormLetter“ abgebildet werden. So ist es z.B. möglich, gleich bei der Buchung entsprechende Dokumente auszudrucken (einmal, mehrfach und in verschiedene Formate), die Maske für die Buchung zu öffnen (damit der Benutzer Einfluss auf die Buchung nehmen kann) oder die Buchung nicht direkt auszuführen, sondern diese für die Stapelverarbeitung bereit zu stellen.

Damit es nicht zu komplex wird, kurz noch ein Beispiel zum Buchung und gleichzeitigen ausdrucken entsprechender Dokumente.

// --- Buchen mit Ausdruck ---
static void PostingConfimation(Args _args)
{
   SalesFormLetter salesFormLetter;
   SalesTable salesTable;
   SalesId salesId;
   PrintJobSettings printJobSettings;
   ;
   //Angabe des Auftrags, welcher gebucht werden soll.
   salesId ="00423_036";
   salesTable = SalesTable::find(salesId);
   salesFormLetter = SalesFormLetter::construct(DocumentStatus::Confirmation);

   //Buchen des Auftrags und drucken (Druckmedium aus Std. Einstellung).
   salesFormLetter.update(salesTable,
                          SystemDateGet(),
                          SalesUpdate::All,
                          AccountOrder::None,
                          NoYes::No,
                          NoYes::Yes);

   //2ter Ausdruck.
   printJobSettings =new PrintJobSettings(salesFormLetter.printerSettingsFormletter(
                                                           PrintSetupOriginalCopy::Original));
   //Wohin möchten wir drucken (hier Datei).
   printJobSettings.setTarget(PrintMedium::File);

   //In welches Format soll gedruckt werden (hier PDF).
   printJobSettings.format(PrintFormat::PDF);
   printJobSettings.fileName(@"C:\Test_Order.pdf");

   //Übergabe der Druckoptionen an das SalesFormLetter Objekt.
   salesFormLetter.updatePrinterSettingsFormLetter(printJobSettings.packPrintJobSettings());

   salesFormLetter.printJournal();
}

{
CCADOConnection adoConnection;
CCADOCommand adoCommand;
Inventtable inventtable;
;
adoConnection =new CCADOConnection();
//ODBC-Connection
adoConnection.connectionString(strfmt("Dsn=%1",dsnName));
//Connection öffnen
adoConnection.open();

adoCommand = new CCADOCommand();
adoCommand.activeConnection(adoConnection);
//Alle Datensätze der Artikeltabelle
while select inventtable
{
// Neue Anweisung für das Einfügen des Datensatzes
adoCommand.commandText(strfmt("Insert into ExterneArtikelTabelle (Artikelkennung,Artikelname) values ('%1','%2')", inventtable.ItemId, inventtable.itemName));
// Anweisung ausführen
adoCommand.execute();
}
}

staticvoid ArtikelinExterneDatenquelleeinfuegen(Args _args)
{
CCADOConnection adoConnection;
CCADORecordSet adoRecordSet;
CCADOCommand adoCommand;
str sql;
Inventtable inventtable;
SysDictTable dictTable =new SysDicttable(inventTable.TableId);
SysDictField dictFieldID =new SysDictField(dicttable.id(), fieldnum(InventTable, ItemID));
SysDictField dictFieldName =new SysDictField(dicttable.id(), fieldnum(InventTable, ItemName));
;
//Neu Verbindung
adoConnection =new CCADOConnection();
adoConnection.connectionString(strfmt("Dsn=%1",dsnName));
adoConnection.open();

//Neu Command
adoCommand =new CCADOCommand();
adoCommand.activeConnection(adoConnection);

//Tabelle löschen wenn sie existiert
/*
sql = strfmt("DROP Table IF EXISTS %1", dictTable.label());

adoCommand.commandText(sql);
adoCommand.execute();
*/

//Tabelle erzeugen
sql = strfmt("Create Table %1 (%2 %3(%4), %5 %6(%7))",
strrem(dictTable.label(), " "),//Leerzeichen löschen
strrem(dictFieldID.label(), " "),
dictFieldID.baseType(),//Datentyp festlegen
dictFieldID.stringLen(),//Größe festlegen
strrem(dictFieldName.label(), " "),
dictFieldName.baseType(),
dictFieldName.stringLen());

adoCommand.commandText(sql);
adoCommand.execute();

//Datensätze in die neue Tabelle schreiben
while select inventtable
{
sql = strfmt("Insert into %1 (%2,%3) values ('%4','%5')",
strrem(dictTable.label(), " "),
strrem(dictFieldID.label(), " "),
strrem(dictFieldName.label(), " "),
inventtable.ItemId,
inventtable.itemName);

adoCommand.commandText(sql);
adoCommand.execute();
}
}

Erhält man bei seiner täglich Arbeit die Fehlermeldung „Ein Befehl der Datendefinitionssprache kann nicht für () ausgeführt werden. Die SQL Datenbank hat einen Fehler gemeldet.“ oder auf englisch „cannot excecute a data definition language command on (). The SQL database has issued an error.” stellt sich einem meist eine große Hürde in den Weg, weil aus dieser Fehlermeldung nicht eindeutig zu erkennen ist, wo ein Fehler entstanden ist bzw. wieso der Fehler auftritt.

Durch Zufall bin ich drauf gestoßen, wie man genau diese Fehlermeldung produzieren kann und somit Rückschlüsse auf die Ursache des Fehlers schließen kann.

Das Folgende Vorgehen...

1. Erstellen eines EDT’s vom Typ „string“ mit dem Namen „MY_BaseId“.
2. Verwenden des EDT’s in einer Tabelle (Name:  MY_BaseTable).
3. Erzeugen von mehreren Datensätzen in der Tabelle.
4. Löschen des EDT’s „MY_BaseId“.
5. Erstellen eines EDT’s vom Typ „real“ mit dem Namen „MY_BaseId“ (gleicher Name wie der gelöschte EDT vom Typ „string“ hatte).
6. Kompilieren oder synchronisieren der Tabelle „MY_BaseTable“.

...ergibt die genannte Fehlermeldung.

Daraus ist zu schließen, dass der Fehler immer Auftritt, wenn der Typ eines vorhandenen EDT’s den bereits eine oder mehrere Tabellen verwenden, geändert wird.
Ich konnte die Fehlermeldung bzw. den Fehler aber nur reproduzieren, wenn die jeweilige Tabelle ein oder mehrere Datensätze enthielt. War in der Tabelle kein Datensatz vorhanden kam es nicht zu der Fehlermeldung.

Um besagten Fehler oder besagte Fehlermeldung zu beheben müssen entweder alle Datensätze in der Tabelle oder die Tabelle selbst gelöscht werden.

Eine Bestellung umfasst in Microsoft Dynamics AX immer einen Datensatz der Tabelle „PurchTable“ und wenn die Bestellung einen Artikel enthält, auch einen Datensatz in der Tabelle „PurchLine“. Zusätzlich werden in Abhängigkeit von den Daten der Bestellung (Einmallieferant: Ja/Nein, Intercompany: Ja/Nein, etc.) zusätzliche Datensätze in anderen Tabellen erzeugt bzw. geändert. Beispielhaft sei hier die Tabelle „VendTable“ genannt. In dieser wird ein neuer Lieferant erstellt, wenn beim Erstellen der Bestellung angegeben wurde, dass es sich um einen Einmallieferanten handelt. Ein weiteres Beispiel wäre die Tabelle „MarkupTrans“ in der in Abhängigkeit von den Einstellungen für sonstige Zuschläge ebenfalls weitere Datensätze erzeugt werden.

Die Logik, die das Erstellen der einzelnen Datensätze der verschiedenen Tabellen steuert wird in Microsoft Dynamics AX durch die Klassen „PurchTableType“ (Abbildung 1) und „PurchLineType“ (Abbildung 2), sowie deren abgeleiteten Klassen abgebildet. Diese Klassen steuern das Verhalten bei Anlage, Änderung und Löschung einer Bestellung. Dies beinhaltet auch, welche Werte ein Feld bei welchem Bestellungstyp annehmen darf, was geschieht wenn ein Feld geändert wird, was wird wie gebucht und so weiter.

Diese Klassen werden von überschriebenen Methoden der Tabellen „PurchTable“ und „PurchLine“ aufgerufen. So ruft zum Beispiel die Methode „Insert“ der Tabelle „PurchTable“, die Methode „Insert“ der Klasse „PurchTableType“ auf. Abhängig vom Bestellungstyp wird über die Methode „construct“ bei der Initialisierung eines „PurchTableType“ Objekts gesteuert, welches konkrete Objekt erzeugt wird („PurchTableType_Purch“, „PurchTableType_ReturnItem“, etc.). Dies erfolgt in der Methode „type“ der Tabelle „PurchTable“ oder „PurchLine“. Unter anderem sind weiterhin die Methoden „Update“, „Delete“, „InitValue“, „ValidateField“ und „Delete“ auf die gleiche Weise überschrieben.
Ein Blick in die Methoden der Tabelle „PurchTable“ sollte dies verdeutlichen.

Somit ist die Logik, die für die Steuerung von Bestellungen in Microsoft Dynamics AX verantwortlich ist, vom Prinzip her vergleichbar mit der Logik welche die Aufträge „steuert“ (vergleiche hierzu: Microsoft Dynamics AX API – Teil 1 „Erstellen von Aufträgen“).

Deswegen ist das Erstellen einer Bestellung genau so einfach wie das Erstellen eines Auftrags. Um eine neue Bestellung zu erstellen muss im Wesentlichen nur:

1. Eine neue Nummer des entsprechenden Nummernkreises gezogen werden.
2. Die Methode „InitValue“ der Tabelle „PurchTable“ aufgerufen werden.
3. Die Methode „InitFromVendTable“ der Tabelle „PurchTable“ mit Angabe des Lieferanten Datensatzes aufgerufen werden.
4. Die Methode „Insert“ der Tabelle  „PurchTable“ aufgerufen werden.

Soll für diese gerade erzeugte Bestellung nun noch eine Artikelposition erzeugt werden, muss im Wesentlichen nur die Methode „CreateLine“ der Tabelle „PurchLine“, mit vorheriger Definition von Bestellungsnummer („PurchLine.PurchId“) und Artikelnummer („PurchLine.ItemId“), aufgerufen werden.

Hierzu ein Beispiel:

void createPurchTableAndLine()
{
   VendAccount vendAccount ="<yourVendAccount>";
   ItemId itemId ="<yourItemId>";

   PurchTable purchTable;
   PurchLine purchLine;
   NumberSeq numberSeq;
   InventTable inventTable;
   ;
   //Bestellungskopf (PurchTable)
   //Neue Bestellungsnummer aus Nummernkreis erzeugen
   NumberSeq = NumberSeq::newGetNumFromCode(
   PurchParameters::numRefPurchId().numberSequence);
   purchTable.PurchId = NumberSeq.num();

   //Bestellungskopf initialisieren
   purchTable.initValue();

   //Initialisierung der lieferantenspezifischen Bestellungsdaten
   purchTable.initFromVendTable(VendTable::find(vendAccount));

   //Bestellungskopf erstellen
   purchTable.insert();

   //Bestellungsposition (PurchLine)
   purchLine.clear();

   //Zuweisen von Bestellungsnummer und Artikelnummer
   purchLine.purchId = purchTable.PurchId;
   purchLine.ItemId = itemId;

   //Bestellungsposition erstellen (ruft PurchLine.insert auf)
   purchLine.createLine(NoYes::Yes, NoYes::Yes, NoYes::Yes,
                        NoYes::Yes, NoYes::Yes, NoYes::Yes);
}

Ein Auftrag umfasst in Microsoft Dynamics AX immer einen Datensatz in der Tabelle „SalesTable“ (Auftragskopf) und wenn der Auftrag einen Artikel enthält (Auftragsposition), auch einen Datensatz in der Tabelle „SalesLine“. Zusätzlich werden in Abhängigkeit von den Daten des Auftrags (Einmalkunde: Ja/Nein, Intercompany: Ja/Nein, etc.) zusätzliche Datensätze in anderen Tabellen erzeugt bzw. geändert. Beispielhaft sei hier die Tabelle „CustTable“ genannt. In dieser wird ein neuer Kunde erstellt, wenn beim Erstellen des Auftrags angegeben wurde, dass es sich um einen Einmalkunden handelt. Ein weiteres Beispiel wäre die Tabelle „MarkupTrans“ in der in Abhängigkeit von den Einstellungen für Sonstige Zuschläge ebenfalls weitere Datensätze erzeugt werden.

Die Logik, die das Erstellen der einzelnen Datensätze der verschiedenen Tabellen steuert (die so genannte Geschäftslogik) wird in Microsoft Dynamics AX durch die Klassen „SalesTableType“ (Abbildung 1) und „SalesLineType“ (Abbildung 2), sowie deren abgeleiteten Klassen abgebildet. Diese Klassen steuern das Verhalten bei Anlage, Änderung und Löschung eines Auftrags. Dies beinhaltet auch, welche Werte ein Feld bei welchem Auftragstyp annehmen darf, was geschieht wenn ein Feld geändert wird, was wird wie gebucht und so weiter.

Diese Klassen werden von überschriebenen Methoden der Tabellen „SalesTable“ und „SalesLine“ aufgerufen. So ruft zum Beispiel die Methode „Insert“ der Tabelle „SalesTable“, die Methode „Insert“ der Klasse „SalesTableType“ auf. Abhängig vom Auftragstyp wird über die Methode „construct“ bei der Initialisierung eines „SalesTableType“ Objekts gesteuert, welches konkrete Objekt erzeugt wird („SalesTableType_Sales“, „SalesTableType_ItemReq“, etc.).
Unter anderem sind weiterhin die Methoden „Update“, „Delete“, „InitValue“, „ValidateField“ und „Delete“ auf die gleiche Weise überschrieben. Ein Blick in die Methoden der Tabelle „SalesTable“ oder „SalesLine“ sollte dies verdeutlichen.

Somit gestaltet sich das Erstellen eines neuen Auftrags sehr einfach, da die gesamte Geschäftslogik die hinter einem Auftrag steht, automatisch aufgerufen wird.

Um einen neuen Auftrag zu erstellen muss im Wesentlichen nur

1. Eine neue Nummer des entsprechenden Nummernkreises gezogen werden.
2. Die Methode „InitValue“ der Tabelle „SalesTable“ aufgerufen werden.
3. Die Kundennummer zugewiesen werden.
4. Die Methode „InitFromCustAccount“ der Tabelle „SalesTable“ aufgerufen werden.
5. Die Methode „Insert“ der Tabelle  „SalesTable“ aufgerufen werden.

Soll für diesem gerade erzeugten Auftrag nun noch eine Artikelposition erzeugt werden, muss im Wesentlichen nur die Methode „CreateLine“ der Tabelle „SalesLine“, mit vorheriger Definition von Auftragsnummer („SalesLine.SalesId“) und Artikelnummer („SalesLine.ItemId“), aufgerufen werden.

Hierzu ein Beispiel:

void createSalesTableAndLine()
{
   AccountNum custAccount = <yourCustAccount>;
   ItemId itemId = <yourItemId>;

   SalesTable salesTable;
   SalesLine salesLine;
   NumberSeq NumberSeq;
   ;
   //Auftragskopf (SalesTable)
   //Neue Auftragsnummer aus Nummernkreis erzeugen
   NumberSeq = NumberSeq::newGetNumFromCode(
   SalesParameters::numRefSalesId().numberSequence);
   salesTable.SalesId = NumberSeq.num();

   //Auftragskopf initialisieren
   salesTable.initValue();
   salesTable.CustAccount = custAccount;

   //Initialisierung der kundenspezifischen Auftragsdaten
   salesTable.initFromCustTable();

   //Auftragskopf erstellen
   salesTable.insert();

   //Auftragsposition (SalesLine)
   salesLine.clear();

   //Zuweisen von Auftragsnummer und Artikelnummer
   salesLine.SalesId = salesTable.SalesId;
   salesLine.ItemId = itemId;

   //Auftragsposition erstellen (ruft SalesLine.insert auf)
   salesLine.createLine(NoYes::Yes, NoYes::Yes, NoYes::Yes, NoYes::Yes,
                        NoYes::Yes, NoYes::Yes);
}

Immer wieder wurde ich darauf angesprochen, ob es nicht möglich sei, die SQL Server Reporting Services Berichte auch ohne Umweg über einen Browser direkt aus dem Dynamics AX 4.0 Menü aufzurufen.

Leider ist dies im Standard nicht möglich.
So habe ich mich entschlossen ein kleines Tool hierfür zu schreiben.

Mit der SSRS Berichtsviewer Erweitung können nun die SQL Server Reporting Services Berichte direkt aus dem Dynamics AX 4.0 Menü geöffnet werden. Dadurch kann eine einfachere und vor allem durchgängigere Benutzung von Berichten innerhalb von Dynamics AX 4.0 gewährleistet werden, da es für den Benutzer keine Unterschiede mehr zwischen dem Aufruf von Dynamics AX 4.0 Berichten und SQL Server Reporting Services Berichten gibt.

Innerhalb von Dynamics AX 4.0 werden die SQL Server Reporting Services Berichte in einem neuen Berichtsviewer gerendert und dargestellt.

Die SSRS Berichtsviewer Erweiterung für Dynamics AX 4.0 - Version 0.1 kann hier herunter geladen werden:
SSRSReportingExtension_V0.1.zip (403,96 KB)

Der Downlaod enthält eine Anleitung zur Verwendung.
Sollten dennoch einige Fragen durch die Anleitung nicht beantwortet werden können, bitte ich diese über die Kommentarfunktion zu stellen. Gleiches gilt auch für Bugs oder Featurewünsche für kommende Versionen.

Manchmal ist es hilfreich beim Debuggen eines Codeblocks zusätzliche Informationen im Debugger auszugeben. 
Dies kann zum Beispiel der aktuelle Wert eines Tabellenfelds sein.

Ebenfalls ist es machmal hilfreich, zusätliche Überprüfungen von Werten einzelner Variablen oder Tabellenfeldern durchzuführen, wenn der jeweilige Codeblock im Debugger ausgeführt wird.

Hierzu ein Beispiel: 

CustTable custTable;
;
while select custTable
{
   //Den Kundennamen im Debuggerfenster ausgeben.
   debug::printDebug(custTable.Name);

   //Information in einem beliebigen Debugger-Info-Tab ausgeben.
   debug::printTab(DebugPrintTab::Method, "Aufruf einer Methode");

   //Eine Überprüfung eines Wertes durchführen (nur im Debug-Mode).
   debug::assert(CustTable.Name != nullValue(CustTable.Name));

   info(custTable.Name);
}

Alle "Debug::" Anweisungen werden nur beachtet/ausgeführt, wenn der Code im Debugger ausgeführt wird (gesetzter Breakpoint). Wird der Code "normal" ausgeführt, wird in dem Beispiel nur die "info()" Anweisung ausgeführt.

Microsoft Dynamics AX bietet eine performante Möglichkeit viele Datensätze einzufügen. Hierzu wird die Klasse RecordInsertList verwendet.

RecordInsertList recordList;
CustTable custtable;
;

recordList= new RecordInsertList(tableNum(custtable));

while
{
//TODO: Datensätze erzeugen ohne insert aufzurufen

recordList.add(custtable); //Datensatz der Liste übergeben
}

recordList.insertDatabase();// Datensätze einfügen

Hierbei werden die Datensätze nicht mehr sofort in die Datenbank geschrieben werden, sondern im RecordListInsert Buffer lokal zwischengespeichert. Die dort enthaltenen Datensätze werden spätestens beim Aufruf der Methode insertDatabase() -das Einfügen der Datensätze wird hier vom Kernel gesteuert, der einen geeigeneten Zeitpunkt zum Einfügen auswählt- in die Datenbank geschrieben.

Bei meinem Versuch auf einem VirtualPC habe ich eine Geschwindigkeitsvorteil von ca. 25% erzielt.

Im AXforum.info (eines der größten Dynamics Foren) kann man noch einen Testjob finden, der deutlich macht, was an Zeit eingespart werden kann, wenn mit RecordInsertList gearbeitet wird.

Update

Bei der Instanzierung gibt es noch optionale Parameter wie

• Insert Methode der Tabelle überspringen [Default=false]
  
• Datenbanklog überspringen [Default=false]
• Alerts überspringen [Default=false]
• AOS Validierung überspringen [Default=false]

Ist bei der aktuellen Tabelle einer dieser Punkte (Insert Methode, Datenbanklog...) vorhanden, müssen diese dann mittels der Parameter übersprungen werden, sonst wird aus dem Bulk-Insert wieder ein Single-Record-Insert!

Möchte man alle Datensätze einer Tabelle löschen, kann hierfür der Befehl "Delete_From" verwendet werden.

Dies funktioniert soweit und es ist auch nichts gegen diese "Art" des Löschen einzuwenden.
Wenn allerdings in der Tabelle mehrere millionen Datensätze gespeichert sind, dauert dies schon recht lange (mehrere Stunden).

Um das Löschen aller Datensätze einer Tabelle zu beschleunigen, kann der SQL Server Befehl (Transact SQL) "TRUNCATE TABLE" verwendet werden.

Dieser Befehl erfernt alle Zeilen aus einer Tabelle, ohne die einzelnen Löschungen zu protokollieren. Der "TRUNCATE TABLE" Befehl ist wesentlich schneller und verwendet weniger Systemressourcen als der "Delete" Befehl.

Microsoft Dynamics AX unterstütz diesen Befehl leider nicht direkt.
Somit muss der Aufruf von "TRUNCATE TABLE" über eine ADO-Connection oder in einem der SQL Server Verwaltungs-Tools erfolgen.

Update:
Der "Truncate Table" Befehl ist doch in Dynamics AX implementiert. Und zwar wird er durch die Methode "tableTruncate" der Klasse "SqlDataDictionary" implementiert.

Beispiel zur Verwendung:

SqlDataDictionary sqlDict;
;
sqlDict =new SqlDataDictionary();
sqlDict.tableTruncate(tablenum(SysDataBaseLog));

Weitere Informationen zum "TRUNCATE TABLE" Befehl können über das MSDN bezogen werden.
http://msdn2.microsoft.com/de-de/library/ms177570.aspx

ich komme gerade von der Prüfung und bin erleichtert. Das war wohl einer der schwierigsten Prüfungen die ich bisher gemacht habe. Trotzallem habe ich die Prüfung

bestanden und bin froh das ich die nicht nochmal machen muss. Darauf sollte man eigendlich feiern, ich dagegen arbeite lieber noch ein bischen :).

CCADOConnection adoConnection =new CCADOConnection();
adoConnection.open("DNS=altDatenKunden");

str SQLstring ="SELECT * From Artikeltabelle";
CCADORecordSet adoRecordSet =new CCADORecordSet();

adoRecordSet.open(SQLstring, adoConnection);

Über adoRecordSet enthält man nun Zugriff auf alle Datensätze aus der Tabelle "Artikeltabelle". Mittels einer Schleifen kann man nun auf jeden einzelen Datensatz zugreifen.

while (!adoRecordSet.EOF())
{
adoRecordSet.moveNext();
}

Um nun Zugriff auf die Daten zu erhalten brauchen wir noch CCADOFields, bzw. CCADOField

CCADOFields adoFields;
CCADOField adoField;

adoFields = adoRecordSet.fields();
adoField = adoFields.itemName("Artikelnummer");

print adoField.value();

Durch diese Anweisungen wird nun das Feld "Artikelnummer" des aktuellen Datensatzes ausgegeben.

Direkte Zuweisungen zum Datenfeld:

• Über den Feldnamen  

  adoField = adoFields.itemName("Artikelnummer");

                     
• Über die Feldnummer 

  adoField = adoFields.itemIDx(1);

Über die Methode

erhält man die gesamte Anzahl der Felder, der aktuellen Tabelle und erhält so Zugriff auf jedes einzelne Tabellenfeld auch ohne deren Benennung und/ oder Anzahl zu kennen..

for( i =1 ; i<= adoFields.count() ; i++)
{
adoField = adoFields.itemIdx(i);
print adoField.value();
}

Die Methode value() der Klasse CCADOField gibt den Wert des Feldes immer als den richtigen Axapta Basis Wertetyp (str, int, real usw.) zurück. Somit muss man sich über eine Typenwandlung in der Regel keine Gedanken machen.

Zum Abschluss noch ein komplettes Bespiel.

CCADOConnection Connection;
str SQL;
CCADORecordSet adoRecordSet;
;
// Neue ADO Connection
Connection =new CCADOConnection();

// Verdingung zur Datenbank öffnen
Connection.open("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\\altDatenKunde.mdb");

// Neuer RecordSet
adoRecordSet =new CCADORecordSet();

// SQL Anweisung
sql = strfmt("SELECT * FROM %1","Artikeltabelle");

// Datensatzsammlung mit Verbindung zur Datenbank und anhand der SQL Anweisung
adoRecordSet.open(sql, connection);

// Alle Datensätze
while (!adoRecordSet.EOF())
{
// Ausgabe des Erstfeldes
print adoRecordSet.fields().itemIdx(1).value();
// Ausgabe des Feldes "Artikelbestand"
print adoRecordSEt.fields().itemName("Artikelbestand").value();

// Nächster Datensatz
adoRecordSet.moveNext();
}

adoRecordSet.close(); //Recordset schließen
Connection.close(); //Connection schlißen

pause;

Wird eine DTAUS Kreditorenzahlung erzeugt, werden im Bericht "Zahlungsavis" (Report "VendOutCoveringLetter_DEDTAUS" scheinbar immer die möglichen Skonti und damit auch der Zahlungsbetrag abzüglich möglicher Skonti gedruckt und nicht die tatsächlich gewährten Skonti. Das Problem scheint nur in diesem Bericht für die DTAUS zu bestehen.

Durch einfache Anpassungen in den Reportmethoden, die ich anhand des Berichts "Zahlungsavis" für die DTAZV (Report "VendOutCoveringLetter_DEDTAZV") genommen habe, werden diese Fehler behoben.

Folgende Methoden sind im Report VendOutCoveringLetter_DEDTAUS anzupassen:

paymentAmount ()

//BP Deviation Documented
display TempReal paymentAmount()
{

// Original
// return element.invoiceAmount() + element.cashDiscAmountIfPossible();

// Korrektur
return specTrans.Balance01 * -1;
}

chashDiscAmountIfPossible ()

display VendCashDiscAmount cashDiscAmountIfPossible()
{
// Original
// return VendTransOpen::find(specTrans.RefRecId).PossibleCashDisc;
// Korrektur
return specTrans.vendCashDiscAmountIfPossible(ledgerJournalTrans.TransDate,
VendPaymModeTable::discGraceDays(ledgerJournalTrans.PaymMode)) * -1;
}

Nun werden die gewährten Skonti und nicht die möglichen Skonti auf dem Bericht gedruckt.