Dynamics AX Blog - Beiträge vom Mai 2011

Wer schon einmal eine Tabelle aufbauen musste, wo die einzelnen Datensätze über Datumsfelder nur für einen bestimmten Zeitraum gültig sind - ähnlich den Handelsvereinbarungen -, weiß wieviel Entwicklungsaufwand daintersteckt, wenn sichergestellt werden muss, daß sich die Gültigkeitsbereiche der einzelnen Datensätze nicht überschneiden.

Dynamics AX 2012 stellt hierfür eine neue Tabelleneigenschaft validTimeStateFieldType zur Verfügung, mit deren Hilfe sich Dynamics AX selbst um vieles kümmert.

Beim Anlegen einer solchen Tabelle muss nur auf die folgenden Punkte geachtet werden:

1. Eigenschaft ValidTimeStateFieldType der Tabelle auf Date oder UtcDateTime setzen. Dadurch erstellt AX zwei neue Felder ValidFrom und ValidTo in der Tabelle.
   
   
    
2. Man muss einen eindeutigen Index erstellen, der die entscheidenden Felder der Tabelle sowie die Felder ValidFrom und ValidTo enthält.
   
   
    
3. Bei diesem Index müssen bestimmte Eigenschaften gesetzt werden.
   
   

Ab diesem Zeitpunkt kümmert sich Dynamics AX vollständig um das Aktualisieren von nicht mehr gültigen Datensätzen und die entscheidenden Prüfungen beim Anlegen von neuen Datensätzen.

Aber auch das Selektieren des jeweils gültigen Datensatzes für ein bestimmtes Datum wird wesentlich erleichert. Dafür stellt Dynamics AX das Keyword validTimeState zur Verfügung.

Im folgenden sind einige Gedankennotizen zum Thema Datum und Uhrzeit in Dynamics AX notiert.

In allen mir bekannten Versionen von Dynamics AX bzw. Axapta gibt es die nachstehenden Funktionen:

Ab Dynamics AX 2009 stehen u.a. zusätzliche folgende Funktionen zur Verfügung: 

In allen bisherigen Dynamics AX-Versionen wird das Systemdatum und die Systemzeit von der Zeit des Clients initialisiert. Diese Werte kann sich der Benutzer - entsprechende Rechte vorausgesetzt - jederzeit selbst ändern (die Uhrzeit allerdings erst seit Dynamics AX 2009). Sie gelten aber nur für die aktuelle Sitzung und nur für diesen Benutzer.
 
Übrigens: Erhält man unter AX 2009 beim Starten eines AX-Clients die nachstehende Fehlermeldung, sollte man die Zeitzone des aktuellen Benutzers in den Benutzeroptionen prüfen.

Die Zeitzone des lokalen Comuters stimmt nicht mit den Einstellungen für die bevorzugte Zeitzone überein.

Wie startet man einen Bericht, bei dem eine von RunBaseReport abgeleitete Klasse vorgeschalten ist, per X++ und gibt diesem Bericht bereits den Query und die Druckeinstellungen vor?

Wer sich diese Frage schon einmal stellen musste, für den liefert dieser Blogbeitrag vielleicht einen Lösungsansatz:

static void setPrintJobSettingsQuery4ReportClass_II(Args _args)
{
    custReport          custReport = new custReport();
    printJobSettings    printJobSettings = new printJobSettings();
    ;
    custReport.makeReportRun();

    // Modify Query
    sysQuery::findOrCreateRange(custReport.reportRun().query().dataSourceTable(tableNum(custTable)), fieldNum(custTable, custGroup)).value(queryValue('10'));
    custReport.reportRun().query().interactive(false);
    // Create printJobSettings
    printJobSettings.setTarget(PrintMedium::File);
    printJobSettings.format(PrintFormat::PDF);
    printJobSettings.fileName(@"C:\Temp\CustTableReport.pdf");

    // Apply printJobSettings
    custReport.reportRun().printJobSettings(printJobsettings.packPrintJobSettings());
    custReport.reportRun().report().interactive(false);  // Disable default printer-dialog
    custReport.reportRun().run();
}

Obiger Code instanziiert ein Objekt der Klasse custReport, deren wesentliche Methoden wie folgt aussehen:

class CustReport extends runBaseReport
{
}

public identifiername lastValueElementName()
{
    identifiername ret;

    //ret = super();

    ret = reportStr(Cust);

    return ret;
}

static ClassDescription description()
{
    return "Custreport";
}

static void main(Args args)
{
    CustReport  CustReport;
    ;
    CustReport = new CustReport();
    if (CustReport.prompt())
    {
        CustReport.run();
    }
}

Wenn man in Dynamics AX (4.0 bzw. 2009) einmal in die Verlegenheit kommen sollte, prüfen zu müssen, ob es Tabellen mit doppelten RecIDs gibt, kann folgendes SQL-Script dabei behilflich sein: