Dynamics AX Blog - Dynamics AX 2009 - Seite 16

Im Standard-Code werden in Verbindung mit dem Befehl setPrefix des öfteren die Makros PreFixField und PreFixFieldValue verwendet. Was die Verwendung dieser Makros für eine Auswirkung auf die Darstellung des Infologs hat, möchte ich im folgenden anhand einfacher Beispiele demonstrieren.

Beispiel für PreFixField

Um im Lookup von Datumsfelder zusätzlich die Kalenderwoche angezeigt zu bekommen, ist eine Anpassung der Form SysDataLookup notwendig.

Es muss lediglich die Eigenschaft ShowRowlabels des Table-Controls DaysTable auf YES geändert werden.

Warum diese Eigenschaft nicht standardmässig auf YES gesetzt ist, wundert mich zwar, da ja die dahinterliegende Logik komplett vorhanden ist, aber das darf jemand anderer mit Microsoft diskutieren :-)

Nachtrag vom 19.11.2009
Zuständig für die Berechnung der Kalenderwoche ist die Methode drawMonth() des Formulares. In dieser wird standardmässig die Funktion weekOfYear() verwendet. Diese Funktion sollte - zumindest für nicht amerikanische Unternehmen - durch wkOfYr() ersetzt werden. Erstere berechnet nämlich die Kalenderwoche nach amerikanischem Vorbild.

Unter AX 2009 SP1 ist mir vor kurzem beim Versuch eine Bestellung zu buchen, folgende Fehlermeldung über den Weg gelaufen

Ein Datensatz in Bestellkopfdaten - Tabelle aktualisieren
(PurchParmSubTable) kann nicht erstellt werden. Bestellung: 000375, Silver and Black Services.
Die SQL-Datenbank hat einen Fehler gemeldet.

bzw.

Cannot create a record in Purchase order header - Updating table (PurchParmSubTable). Purchase order: 000375, Silver and Black Services.
The SQL databse has issued an error.

Eine Suche nach dieser Fehlermeldung im Internet ergab, daß wenn für die Tabelle PurchParmTable (Achtung, kein Tippfehler, eine andere Tabelle als in der Fehlermeldung) das Datenbankprotokoll aktiviert wäre, es zu dieser Fehlermeldung kommen kann.

Vor kurzem bin ich in der Klasse TaxVATNumValidate von Dynamics AX 2009 über eine Methode gestolpert, die einen String dahingehend überprüft, ob er einen rein numerischen Wert enthält.

boolean isNumeric(str _input)
{
    ;
    return (strlen(_input) == strlen(strkeep(_input,'1234567890')));
}

Dies geht natürlich mit der Funkton isInteger wesentlich einfacher, aber die gefundene Methode bietet einen netten Gedankensansatz, wie man Strings auf deren darin enthaltener Zeichen prüfen kann. In den Sinn kamen mir hierbei z.B. eine sehr einfache Validierung von E-Mail-Adressen, Telefonnummern u.ä.

Nachstehend ein Stück Code, wie man in der init-Methode einer FormDataSource einen QueryBuildRange für ein mehrdimensionales Feld aufbaut (z.b. vom EDT Dimension).

Das ganze ist mehr eine Notiz für mich selbst, weil ich mir das einfach nicht merke :-)

In den Debitoren-Parametern gibt es ein Kennzeichen namens "Aufträge als ungültig markieren". Ist dieses Kennzeichen gesetzt, werden gelöschte Aufträge in den Tabellen SalesTableDelete und SalesTableLine gespeichert. Derartige Aufträge können unter Debitoren / Abfragen / Historie / Ungültige Aufträge eingesehen werden.
 
Leider gibt es standardmässig scheinbar keine Möglichkeit, solche Aufträge wiederherzustellen.

Um eine temporäre Tabelle in einem Report zu verwenden, kann diese in der fetch-Methode mit Daten befüllt werden.

public boolean fetch()
{
    boolean ret = true;
    QueryRun localQuery = new QueryRun(this);
    ;
 
    localQuery.setRecord(TmpCustVendTrans::custTransBalanceCurrency("200030", true, "EUR"));  // Befüllt die Tabelle mit den Salden eines Debitors
 
    while (localQuery.next())
    {
        TmpCustVendTrans = localQuery.get(TableNum(TmpCustVendTrans));
        element.send(TmpCustVendTrans);
    }
 
    return ret;
}

Die Variable TmpCustVendTrans ist dabei in der classDeclaration des Reports deklariert.