Dynamics AX Blog - Seite 52

Dynamics AX: Rechnungen per Code drucken

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

Hier ein kurzes Beispiel unter AX 2009

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

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

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

   salesFormLetter.updatePrinterSettingsFormLetter(printJobSettings.packPrintJobSettings());

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

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

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

Nachstehend ein Code-Beispiel unter AX 4.0

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

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

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

   salesFormLetter.updatePrinterSettingsFormLetter(printJobSettings.packPrintJobSettings());

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

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

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

 
 

Dynamics AX: CRM aktiv oder nicht?

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

smmLicense::CRM() // returns boolean

 
 

CSV-Datei und Zeilenumbrüche

Wenn man aus AX Daten in eine CSV-Datei exportieren muss, gibt es immer wieder Probleme mit Zeilenumbrüchen in mehrzeiligen AX-Feldern.

Um diese zu umgehen, müssen lediglich folgende Punkte beachtet werden:

  • Der Text muss in doppelte Anführungszeichen (") eingeschlossen werden
  • Der RecordDelimiter des TextIO-Objekts muss ein Linefeed sein [=num2char(10)]
  • Doppelte Anführungszeichen im Text müssen "verdoppelt" werden

 

static void Export_CSV(Args _args)
{
    TextIO      textFile;
    CustTable   CustTable;

    str csv(str _str)
    {
        _str = strReplace(_str, """, """");
       
        return """ + _str + """;
    }
    ;

    textFile = new TextIO("c:\temp\csv_test.csv","W",0);
    textFile.outFieldDelimiter(";");
    textFile.outRecordDelimiter(num2char(10));  // Wichtig wegen Zeilenumbrüchen!!!


    while select CustTable
    {
        textFile.write(
            csv(CustTable.Name) +
            ";" +
            csv(CustTable.Address) +
            ";"
            );
    }
   
    textFile = null;
}

 
 

Vor- und rückwärts kompilieren in AX

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

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

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

Entwicklungshierachie

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


 
 

AxInventTable: Artikel per Code anlegen

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

Artikel per Code anlegen unter AX4...

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

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

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

    // Datensatz speichern
    axInventTable.save();
} 

...und AX3

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

    axInventTable = new axInventTable();

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

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

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

 
 

Stolpersteine beim Exportieren von AX4 --> AX3

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

 

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

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

und

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

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

 

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

MNUVERSION 4

durch

MNUVERSION 3

ersetzt werden.

 

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

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

Nachtrag vom 19. März 2008

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

ObjectType

durch

Class

ersetzt werden.


 
 

Bug in SysInfoAction_MenuFunction in AX 4.0

Kleiner Nachtrag zu meinem Beitrag Fehlermeldungen in AX aussagekräftiger gestalten: In AX 4.0 gibt es über die SysInfoAction_MenuFunction-Klasse die Möglichkeit, ein Menuitem aufzurufen (Beispiel dazu siehe im Beitrag).
Man kann rein theoretisch über die Klasse z.b. ein Formular aufrufen, ohne einen Datensatz zu übergeben, welcher im zu öffnenden Formular ausgewählt werden soll. Wenn man das Formular aber ohne einen solchen Buffer aufruft, wechselt AX scheinbar in den Standard-Mandanten. Zwar gibt es eine Methode namens parmDataAreaId() mit der man den Mandanten setzen können sollte, der über diese Methode gesetzte Mandant wird allerdings nicht berücksichtigt.

Ein einfacher Work-Around für das Problem ist, der Klasse über parmCallerBuffer() einen leeren Datensatz (Buffer) zu übergeben. Oder die Klasse korrigieren, fast noch einfacher ;-)


 
 
Seiten « 1 ... 49 50 51 52 53 » 

 

 
 
 
Beiträge des aktuellen Monats
April 2024
MoDiMiDoFrSaSo
1234567
891011121314
15161718192021
22232425262728
2930 
 
© 2006-2024 Heinz Schweda | Impressum | Kontakt | English version | Mobile Version
Diese Webseite verwendet Cookies, um Benutzern einen besseren Service anzubieten. Wenn Sie weiterhin auf der Seite bleiben, stimmen Sie der Verwendung von Cookies zu.  Mehr dazu