Über einen Blog-Eintrag bin ich aber auf einen wertvollen Tip gestossen: Wenn man die [SHIFT]-Taste hält, während man über die rechte Maustaste das Kontext-Menü einer Applikation aufruft, steht die Option Als anderer Benutzer ausführen wieder zur Verfügung.
Szenario: Es soll ein Bericht erstellt werden, bei welchem der Umsatz pro Verkaufsgruppe ausgewertet werden kann.
| Ich gehe davon aus, daß der geneigte Leser schon einmal einen Query erstellt hat, deshalb werde ich darauf nur sehr oberflächlich eingehen. Basis-Tabellen meines Queries sind die Tabellen
Die Tabelle CustInvoiceTrans wird per InnerJoin mit der CustInvoiceJour über die im Screenshot gezeigten Felder verknüpft, die Tabelle CommissionSalesGroup wird per OuterJoin über das Feld SalesGroup verknüpft. |
|
Seit AX 2012 muss die Eigenschaft Dynamic der Fields-Gruppe aller beteiligten Tabellen entsprechend gesetzt werden, im einfachsten Fall wird diese auf Yes gesetzt, um im Visual Studio später alle Felder der Tabellen verwenden zu können.
| Über File > New > Project das Template Microsoft Dynamics AX auswählen, Report Model auswählen und einen Namen und Speicherort angeben. | 
|
|
Innerhalb dieses Reports ist nun ein neues DataSet zu erstellen. Diesem geben wir den Namen CustInvoiceDataSet und tragen als Query den zuvor in Dynamics AX erstellten ein. Letzteres erfolgt über einen Dialog wo auch jene Felder oder Methoden gewählt werden können, die im Bericht ausgegeben werden sollen. In unserem Fall sind dies: Aus der Tabelle CustInvoiceTrans die Felder
und die Methode
Aus der Tabelle CommissionSalesGroup benötige ich das Feld
Gleichzeitig habe ich das DataSet über die Properties auf CustInvoiceDataSet umbenannt. |
Die Eigenschaften des DataSet stellen sich nach Abschluß des Dialoges wie folgt dar:
Nun kann das DataSet per Drag & Drop in den Knoten Designs gezogen werden. Dadurch wird ein neues Design namens AutoDesign1 erstellt.
Nun gilt es einige Eigenschaften dieses Designs anzupassen. Dazu zählen das Seitenformat, Bezeichnungen (Title) des Berichtes aber auch das Layout (LayoutTemplate), im Beispiel habe ich als Seitenformat die Einstellungen für DIN-A4 eingetragen.
Der automatisch generierten Tabelle CustInvoiceDataSetTable weisen wir ebenfalls über die Eigenschaft StyleTemplate ein Layout zu. Im Beispiel habe ich das Layout so gewählt, daß die einzelnen Zeilen später abwechselnd grau oder weiß unterlegt werden.
|
Nun gilt es, die geforderte Gruppierung nach der Verkaufsgruppe (Feld SalesGroup) abzubilden. Hierzu muss im Knoten Groupings der CustInvoiceDataSetTable benannten Tabelle ein neuer Knoten erstellt werden. Diesen nennen wir SalesGroupGrouping und vergeben im einen sprechenden Label, z.B. Verkaufsgruppe. In diesem Knoten können wir nun einen Unterknoten erstellen, in dessen Expression wir das Feld SalesGroup eintragen. Dieser Knoten bekommt nun noch den Namen SalesGroup. Danach erstellen wir jeweils einen neuen Knoten im Header und Footer-Bereich. Auch diese bekommen einen möglichst selbstsprechenden Namen (SalesGroupHeader bzw. SalesGroupFooter). Im SalesGroupHeader erzeugen wir zwei Unterknoten. Beim Ersten tragen wir in der Eigenschaft Expression das Feld SalesGroup ein, beim Zweiten das Feld Name. |
Im SalesGroupFooter erzeugen wie nun in Summe sieben Unterknoten. Nur beim siebenten tragen wir über die Eigenschaft Expression einen Wert ein, die anderen taufen wir Dummy1 bis Dummy6.
Damit diese Summe je Verkaufsgruppe korrekt formatiert wird, passen wir die Eigenschaften entsprechend an:
Hintergrund der Dummy-Felder ist, daß Visual-Studio die Spalten im Footer automatisch unter den Spalten im Data-Bereich versucht auszurichten. Würden wir diese Dummy-Felder nicht erstellen, würde die Summe unterhalb der ersten Spalte angedruckt.
In früheren Versionen von Dynamics AX hätten wir einfach die Eigenschaft ModelFieldName für solcherart Positionierung herangezogen, eine solche Eigenschaft scheint es aber in Visual Studio nicht zu geben.
Damit die Daten in einer bestimmten Reihenfolge sortiert angedruckt werden, erstellen wir im Sorting-Knoten entsprechende Unterknoten und tragen über deren Eigenschaft SortBy das jeweilige Feld ein. Wir sortieren nach Verkaufsgruppe, Rechnungsnummer und Rechnungsdatum.
Abschließend prüfen bzw. ändern wir die Reihenfolge der anzudruckenden Felder im Data-Bereich und passen über die jeweiligen Eigenschaften Spaltenbreiten und ggf. die Bezeichnungen an. So wähle ich zum Beispiel für die Spalte LineAmountMST als Bezeichnung Betrag statt dem vom Visual Studio vorgeschlagenen Label.
Damit Gutschriften bzw. Rechnungen mit negativen Werten rot dargestellt werden, ändern wir die Eigenschaft Style > Font > Color über eine entsprechende Expression:
Diese Änderung bewirkt, daß im Bericht negative Beträge später wie folgt dargestellt werden:
| Abschließend erstellen wir in Dynamics AX ein neues MenuItem, verknüpfen dieses mit einem Menü um den Bericht aus Dynamics AX heraus starten zu können. AX erzeugt - wie schon in früheren Versionen - automatisch einen Dialog, wo man die anzuzeigenden Daten filtern kann. |
|
You are not recognized user of Dynamics AX. Please contact your system administrator
Die Ursache dafür ist, daß in der Tabelle UserInfo - das ist jene Tabelle wo die AD-Benutzer verwaltet werden - natürlich noch die Benutzer der Ursprungsdomäne hinterlegt sind. Im einfachsten Fall ändert man in dieser Tabelle den Eintrag für den Administrator, indem man die Felder NetworkDomain, NetworkAlias und SID entsprechend ändert. NetworkDomain und NetworkAlias sind selbsterklärend, woher bekommt man aber die SID?
Eine einfache Internet-Recherche nach "GET SID" liefert einige Möglichkeiten, weniger bekannt ist aber, daß auch Dynamics AX 2009 selbst eine Methode zur Verfügung stellt, um die SID für einen Benutzer auszulesen.
Jetzt braucht man also nur noch ein anderes, bereits lauffähiges AX, wo man sich anmelden und den Job absetzen kann ;-)
Einfacher geht’s mit folgendem Codebeispiel, welches in der init-Methode der DataSource eingebunden wurde und - im konkreten Fall in der Tabelle SalesLine - nur bei einem einzigen Feld die Bearbeitung erlaubt.
Im Gegensatz zu einem früher veröffentlichten Beitrag mit dem gleichen Thema werden bei diesem Codebeispiel auch Array-Felder korrekt berücksichtigt.
Getestet in Dynamics AX 2009
]]>Im Beispiel wird ermittelt, wieviele Benutzer- bzw. Unternehmensvorlagen es für die Tabelle InventTable gibt und ob der aktuelle Benutzer sich den Vorlagendialog anzeigen lässt, wenn er/sie einen neuen Artikel anlegt.
Dafür wird ein Dialog verwendet, wo man lediglich den Namen und den Typ des zu suchenden Elementes angeben muss. Außerdem kann man noch einstellen, ob auch die privaten Projektknoten durchsucht werden sollen.
Wer eine etwas komfortablere Möglichkeit vorzieht, der kann sich bei Firma Loncar Technologies Inc. ein entsprechendes XPO herunterladen und ins AX einspielen. AUf Basis dieses XPOs ist auch obiger Job entstanden.
]]>
Erste Anlaufstelle war das Programm PC2Box in der Version 2.0. Leider stellt dieses Programm offenbar nur die Möglichkeit zur Verfügung, die Aufnahmen auf dem PC zu sichern. In die umgekehrte Richtung scheint dies nicht vorgesehen zu sein. Jetzt nur noch die neue Festplatte am Receiver anschliessen und schon kann man sich seine Aufnahmen ansehen. Super!
Ein paar kleine Bugs beim Zurückschreiben der Aufnahmen auf die Festplatte sind mir dann aber doch aufgefallen:
Zum einen bekommen die Aufnahmen einen neuen Namen, dieser scheinbar aus dem ursprünglichen und dem jeweiligen Sicherungslaufwerk zusammengesetzt sind. Da man über PC2Box die Aufnahmen auch umbenennen kann ist dies aber kein wirkliches Problem. Ausserdem können aber u.U. die Sicherungen der Aufnahmen nicht immer zurückgespielt werden. Ich hatte z.b. mit einer Aufnahme die Sonderzeichen im Namen enthalten hat Schwierigkeiten. Erst als ich die Aufnahme im Verzeichnis des PCs entsprechend umbenannt habe, konnte ich die Aufnahme zurückspielen.
Ein weiterer Schönheitsfehler war auch die Anzeige der Länge der Aufnahmen. Lt. Anzeige in PC2Box aber auch im Menü der DVB-C-Receivers wurde eine wesentlich kürzere Laufzeit angezeigt. Beim Abspielen dieser Aufnahmen wurde aber dennoch die gesamt Laufzeit problemlos abgespielt.
]]>Diese Bedingung dient dazu, berechnete Werte einer GROUP BY-Clause in der WHERE-Clause berücksichtigen zu können. Dieses Feature habe ich in der Vergangenheit vor allem dazu gerne verwendet, wenn es darum ging über eine SQL-Abfrage doppelte (bzw. vielfache) Datensätze in einer Tabelle zu finden. In den bisherigen Versionen von Dynamics AX war dieses Unterfangen über X++ nur etwas umständlich abzubilden.
Microsoft hat dies scheinbar eingesehen, und stellt nun bei der Verwendung von Queries die Methode addHavingFilter zur Verfügung.
Im folgenden Beispiel möchte ich mir z.B. alle Kundengruppen ausgeben lassen, die bei mehr als nur einem Kunden hinterlegt sind.
// Add having filter to query
query.addHavingFilter(QueryBuildDataSource, "recId", AggregateFunction::Count).value(">1");
// Run query
QueryRun = new QueryRun(query);
while(QueryRun.next())
{
custTable = QueryRun.get(tableNum(custTable));
info(strFmt("Custgroup %1: %2 records", custTable.CustGroup, custTable.RecId));
}
}
Das Ergebnis der oben stehenden Abfrage ohne addHavingFilter würde wie folgt aussehen:
Mit addHavingFilter ändert sich das Ergebnis/Infolog:
Natürlich kann man dieses neue Feature auch bei einem im AOT definierten Query einsetzen. Dazu gibt es einen neuen, entsprechend benannten Knoten:
Mit folgendem Beispiel möchte ich die Anwendung dieser neuen Methode demonstrieren.
Aufgabenstellung: Es sollen alle Aufträge des Kunden 1102 ausgegeben werden, bei denen zumindest eine Auftragsposition existiert, bei der die bestellte Menge größer 1 ist.
Die Datenbank enthält im Beispiel folgende Auftragsköpfe und die zugehörigen Positionen. Der Auftrag 00000011_050 besitzt keine Positionen (und ist somit ein Auftrag, der nicht ausgegeben werden soll).
| SalesId | SalesName | CustAccount |
| 00000002_050 | Adventure Works | 1102 |
| 00000010_050 | Adventure Works | 1102 |
| 00000011_050 | Adventure Works | 1102 |
| SalesId | ItemId | QtyOrdered |
| 00000002_050 | 1290 | 10 |
| 00000010_050 | 1291 | 20 |
Ohne die Methode addQueryFilter würde der nachstehende Job alle Aufträge ausgeben, bei denen dies zutrifft. Es würden aber auch alle Auftragsköpfe ohne Auftragspositionen ausgegeben.
Resultierendes SQL-Statement
SELECT * FROM SalesTable(SalesTable_1)
WHERE ((CustAccount = N'1102'))
OUTER JOIN * FROM SalesLine(SalesLine_1)
ON SalesTable.SalesId = SalesLine.SalesId AND ((QtyOrdered>=1.E0))
Ergebnis
Info Meldung (18:39:50) Sales order 00000002_050: 10,00
Info Meldung (18:39:50) Sales order 00000010_050: 20,00
Info Meldung (18:39:50) Sales order 00000011_050: 0,00
Bei Verwendung von addQueryFilter werden nur noch jene Aufträge ausgegeben, die eine Position mit der gewünschten Menge enthalten. Aufträge ohne Positionen werden allerdings nicht verarbeitet.
Resultierendes SQL-Statement
SELECT * FROM SalesTable(SalesTable_1)
WHERE ((CustAccount = N'1102'))
OUTER JOIN * FROM SalesLine(SalesLine_1)
ON SalesTable.SalesId = SalesLine.SalesId
WHERE ((SalesLine(SalesLine_1).QtyOrdered>=1.E0))
Ergebnis
Info Meldung (18:41:05) Sales order 00000002_050: 10,00
Info Meldung (18:41:05) Sales order 00000010_050: 20,00
Der Auftrag 00000011_050 wird nicht mehr aufgeführt.
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:
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.
]]>
In allen mir bekannten Versionen von Dynamics AX bzw. Axapta gibt es die nachstehenden Funktionen:
| Funktionsaufruf | Beschreibung |
| today() | Datum des Clients |
| systemDateGet() | Sitzungsdatum von AX |
| timeNow() | Zeit des Clients |
Ab Dynamics AX 2009 stehen u.a. zusätzliche folgende Funktionen zur Verfügung:
| Funktionsaufruf | Beschreibung |
| DateTimeUtil::getSystemDateTime() | Sitzungsdatum/-zeit von AX in koordinierter Weltzeit |
| DateTimeUtil::applyTimeZoneOffset ( DateTimeUtil::getSystemDateTime(), DateTimeUtil::getUserPreferredTimeZone() ) |
Sitzungsdatum/-zeit von AX für die aktuelle Zeitzone des Benutzers |
| DateTimeUtil::date(_utcDateTime) | Wandelt einen UTC-Datetime-Wert in ein Datum um |
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.
]]>
Wer sich diese Frage schon einmal stellen musste, für den liefert dieser Blogbeitrag vielleicht einen Lösungsansatz:
Obiger Code instanziiert ein Objekt der Klasse custReport, deren wesentliche Methoden wie folgt aussehen:
]]>
Das Ergebnis des obigen Codes ist ein sehr einfacher Report:
Nun also hier ein entsprechendes Beispiel:
]]>
Nun habe ich mir basierend auf diesem Eintrag und vor allem aufgrund von Erfahrungswerten eine eigene Klasse namens tutorial_ClassWithQueryRun geschrieben, die einige oft benötigte Anforderungen vereinigt.
Diese Klasse vereint folgende Fähigkeiten:
Die erste Anforderung an meine Klasse war, daß sie stapelfähig sein musste. Dazu muss sie in erster Linie von runBaseBatch abgeleitet sein, und einige Methoden wie pack, unPack, canGoBatch müssen entsprechend überschrieben werden.
Die nächste Anforderung war, daß der Benutzer über einen Dialog Parameter festlegen kann. Dafür verantwortlich sind u.a. dialog, getFromDialog, putToDialog und natürlich die main-Methode.
Weiters sollte über diesen Dialog der Benutzer die Möglichkeit erhalten, einen definierten Query durch Filter und drgl. zu erweitern. Dazu mussten folgende Methoden angepasst/erstellt werden: initQuery, showQueryValues und showQuerySelectButton.
Die Methoden filenameLookupFilter, filenameLookupInitialPath und filenameLookupTitle wurden dazu verwendet, dem Benutzer im Dialog die Eingabe des Dateinamens zu erleichtern.
Starten wir also mit der classDeclaration. Hier erfolgt die Ableitung von runBaseBatch, weiters werden sämtliche Objektvariablen deklariert, die innerhalb der Methoden benötigt werden. Außerdem wird hier über das Makro currentList festgelegt, welche dieser Variablen in den Nutzungsdaten gespeichert werden.
In der pack-Methode werden nun über einen Container jene Variablen in die Nutzungsdaten geschrieben, die z.B. für die korrekte Abarbeitung innerhalb der Stapelverarbeitung von Nöten sind.
Die Methode unPack ist das Gegenstück zur pack-Methode, ist sie doch für das Auslesen der Werte aus den Nutzungsdaten zuständig. Wichtig hierbei ist natürlich, daß die Werte innerhalb des Containers in der gleichen Reihenfolge ausgelesen werden, wie sie geschrieben wurden. Weiters ist hier dafür zu sorgen, daß unterschiedliche Nutzungsdaten der Klasse über die entsprechende Versionsinfo korrekt berücksichtigt werden. Wird zum Beispiel die Klasse insofern angepasst, daß entweder die Reihenfolge der Variablen im Macro currentList geändert wird, oder - und das ist der wohl üblichere Fall - daß neue Variablen in die Nutzungsdaten aufgenommen werden, ist das Makro currentVersion anzupassen.
In nachstehender Methode wurde beispielsweise berücksichtigt, daß in der ersten ausgelieferten Version der Klasse die Variable dialogDate noch nicht in den Nutzungsdaten gespeichert wurde. Erst mit Version 2 (=aktuelle Version) wurde auch diese Variable über die pack-Methode in die Nutzungsdaten geschrieben.
Über die Methode allowSaveLast kann gesteuert werden, ob Werte aus den Nutzungsdaten oder die Standardwerte aus der Methode initParmDefault verwendet werden sollen.
In der Methode canGoBatch legt man fest, ob eine Klasse im Stapel ausgeführt werden können soll.
Die Methode runImpersonated steuert (unter AX 2009), ob die Klasse, sofern sie im Stapel ausgeführt wird, am AOS ausgeführt wird, oder über die manuell vom Benutzer zu startende Stapelverarbeitung.
Die main-Methode wird aufgerufen, wenn die Klasse über eine Schaltfläche in einem Formular, einen Eintrag im Menu (beides setzt sein entsprechendes MenuItem voraus) oder aber direkt aus dem AOT aufgerufen wird. Über den Aufruf von prompt wird der Dialog der Klasse geöffnet.
Die dialog-Methode dient dazu, dem Benutzer die Möglichkeit zu geben, bestimmte Parameter und dergleichen festzulegen. Dazu werden dem Dialog die gewünschten Dialog-Felder hinzugefügt.
GetFromDialog wird aufgerufen, wenn der Benutzer den Dialog mit OK bestätigt. Die Methode dient dazu, die eingetragenen Werte/Parameter auszulesen und wie im Beispiel über entsprechende parm-Methoden der Instanz zu übergeben.
this.parmFilename(df_FileNameSave.value());
this.parmDialogDate(df_DialogDate.value());
return ret;
}
Die Methode putToDialog dient dazu, um die Dialogfelder des Dialogs mit Werten zu befüllen. Diese Methode wird unter anderem beim Betätigen der Schaltflächen Löschen und Standard aufgerufen.
Die Methode dialogClear kann dazu verwendet werden, um Dialogfelder bzw. deren Inhalten zurückzusetzen. Diese Methode zu überschreiben macht natürlich nur dann Sinn, wenn die Methode showClearButton entsprechend true retourniert und somit die Schaltfläche Löschen im Dialog angezeigt wird.
Die folgenden drei Methoden werden dazu verwendet, den Benutzer bei der Eingabe des Speicherortes für die durch die Klasse zu erstellende Datei zu unterstützen. So werden der auszuwählende Dateityp genauso gesteuert, wie der Initial-Ablagepfad und der Titel des "Speichern untern"-Windows-Dialoges.
Die Schaltfläche Löschen im Dialog kann über die Methode showClearButton gesteuert werden. Wird die Schaltfläche eingeblendet, sollte die Methode dialogClear entsprechend überschrieben worden sein.
Soll im Dialog die Schaltfläche Standard angezeigt werden, so muss die Methode showDefaultButton entsprechend übersteuert werden. Diese Schaltfläche setzt die Felder des Dialoges auf die Standard-Werte zurück. In diesem Fall sollte aber auch die Methode initParmDefault entsprechenden Code enthalten.
Ob man dem Benutzer die Möglichkeit gibt, den Query mit Filterkriterien, Sortierung usw. zu erweitern kann man über die Methode showQuerySelectButton steuern. Diese legt fest, ob die Schaltfläche Auswählen im Dialog angezeigt wird.
In dieser Methode wird festgelegt, ob die Auswählen-Schaltfläche im Dialog angezeigt wird. Soll diese angezeigt werden, so muss übrigens auch die Methode queryRun überschrieben sein
Bestätigt der Benutzer den Dialog mit OK, so wird die validate-Methode aufgerufen. Hier können Dialogfelder bzw. deren Inhalt geprüft werden. Bevorzugterweise sollte man jedoch die Variablen der Instanz prüfen und nicht die Felder selbst. Auf diese Art und Weise kann man - so wie ich dies beinahe immer mache - die validate-Methode nochmals manuell in der run-Methode aufrufen, um vor der Abarbeitung der Klasse zu prüfen, ob alle notwendigen Parameter übergeben würden. Unabhängig davon, ob die Klasse über den Dialog (also über ein MenuItem) oder aus X++-Code heraus aufgerufen wurde.
Die construct-Methode muss überschrieben werden, um eine Instanz der Klasse bilden zu können.
Die Methode initParmDefault wird u.a. ausgeführt, wenn die Klasse erstmalig über ein MenuItem aufgerufen wird und es somit noch keine Nutzungsdaten gibt. Außerdem wird sie aufgerufen, wenn der Benutzer die Schaltfläche Standard betätigt.
Im Beispiel werden hier all jene Variablen, die der Benutzer auch im Dialog ggf. ändern kann, durch Standard-Werte befüllt. Wichtig ist der Aufruf der initQuery, die den zu verwendenden Query erstmalig initialisiert.
Die initQuery wird u.a. beim erstmaligen Aufruf der Klasse über ein Menuitem von der initParmDefault aufgerufen und generiert ein Query- sowie ein QueryRun-Objekt. Hier werden im Beispiel diverse QueryBuildRanges (Filter) aufgebaut. Auch die Sortierung des Queries kann hier festgelegt werden.
Die parm-Methoden werden u.a. dazu verwendet, um innerhalb einer Instanz der Klasse die Variablen abzufragen bzw. zu setzen.
In der Methode queryRun wird das in der initQuery aufgebaute queryRun-Objekt zurückgegeben.
Das eigentliche Herzstück der Klasse ist natürlich die run-Methode. Hier ist die eigentliche Logik zu implementieren. Im konkreten Fall wird nach der Prüfung der Parameter eine Datei erstellt. Danach wird der Query durchlaufen und bestimmte Werte werden in die Datei geschrieben. Der Benutzer wird währenddessen über eine Fortschrittsanzeige informiert, wie weit der Vorgang fortgeschritten ist.
Da es das Ziel der Klasse ist, eine Datei auf Basis eines Queries zu erstellen, muss diese Datei zu einem bestimmten Zeitpunkt erstellt werden. Dafür sind die Methoden createFileServer bzw. createFileClient zuständig.
Die Methode closeFile wird lediglich dazu verwendet, die Instanz des textIO zu entfernen.
Welcher Titel im Dialog angezeigt werden, kann mit Hilfe der Methode caption gesteuert werden.
Die Methode description sollte dazu verwendet werden, um dem Benutzer im Formular Stapelverarbeitungsliste eine Beschreibung des Stapelverarbeitungsauftrages zur Verfügung zu stellen.
Die Methode howToUseClass wird zu keinem Zeitpunkt automatisch aufgerufen, sie dient dem Entwickler lediglich als Information, wie die Klasse über X++ aufzurufen ist.
Die oben beschriebene Klasse wurde in Dynamics AX 2009 entwickelt, sie läuft aber auch in Dynamics AX 4.0.
Die Klasse steht hier als XPO-File zum Download zur Verfügung, Verwendung natürlich auf eigene Gefahr!
]]>
Lösen kann man so etwas mit Hilfe der Methode setTimeOut, die z.B. auch von der clientseitigen Stapelverarbeitung unter Grundeinstellungen > Periodisch > Stapel > Bearbeitung verwendet wird.
Dazu muss z.B. im Formular eine Methode angelegt werden, die sich selbst über die setTimeOut-Methode nach einer definierten Zeitspanne (in tausendstel-Sekunden anzugeben) aufruft:
Diese Methode muss nun einmalig aufgerufen werden, z.B. in der run-Methode des Formulares:
Mehr zu dieser Methode gibts hier:
http://msdn.microsoft.com/en-us/library/aa857865.aspx
Und zwar gehts um ein einfaches SELECT-Statement, z.B. wie das folgende:
Obiges Statement soll mir einfach eine Zahl der Auftragszeilen liefern, die an einem bestimmten Tag erstellt wurden.
In Dynamics AX 2009 wurde ja das Feld createdDate durch createdDateTime und einen vollständigen neuen Datentyp, der nun auch die Zeit mitspeichert, ersetzt.
Will ich nun in AX 2009 das selbe Statement absetzten, so könnte dies wie folgt aussehen:
Ist das wirklich so, oder übersehe ich hier etwas?
]]>Im Beispiel wird der Standardbericht Cust verwendet, wobei nur Debitoren der Debitorengruppe 10 in eine PDF-Datei ausgegeben werden sollen.
Update 12.12.2010
Inspiriert von einem Kommentar von Andi habe ich obigen Job etwas abgewandelt und verwende nun die classFactory um den ReportRun zu instanzieren:
args = new args();
args.name(reportstr(Cust));
ReportRun = classFactory.reportRunClass(args);
// Modify Query
sysQuery::findOrCreateRange(ReportRun.query().dataSourceTable(tableNum(custTable)), fieldNum(custTable, custGroup)).value(queryValue('10'));
ReportRun.query().interactive(false);
// Create printJobSettings
printJobSettings.setTarget(PrintMedium::File);
printJobSettings.format(PrintFormat::PDF);
printJobSettings.fileName(@"C:\Temp\CustTableReport.pdf");
// Apply printJobSettings
ReportRun.printJobSettings(printJobsettings.packPrintJobSettings());
ReportRun.report().interactive(false); // Disable default printer-dialog
ReportRun.run();
}
Diese Methode scheint allerdings nicht in den überschreibbaren Methoden auf, also muss man einfach eine solche wie folgt anlegen:
Wird der Report über eine Klasse aufgerufen, dann muss in dieser die gleichnamige Methode entsprechend überschrieben werden.
Getestet in Dynamics AX 2009
]]>]]>