When using forms in Dynamics AX we usually get access to them by clicking a button that uses a menu item, this along with the args that is sent we get a form that displays the requested information. But if you want to do this using code, how is this done?
You usually see this used in classes such as SalesFormLetter or PurchFormLetter that uses an existing form instead of a creating a temporary one. The user enters the information and the class uses the new information to perform the tasks at hand.
Continue reading Open filtered forms with X++
This is a basic job that describes how you can jump from one order line to another in the intercompany order structure.
In this example I have created an intercompany order that also has a linked purchase order in the production company to a vendor. This is one way you can use to jump up between the linked order lines.
Continue reading Jump between InterCompany order lines
When programming Dynamics AX it is very easy to add days to a date. You can take todays date and just add an integer of five to get the date five days from now. But because this is easy to do it doesn’t mean that this always is the right way to go about this date business.
If you look closer at how the dates are calculated on the sales order lines or the purchase order lines in Dynamics AX you see that a class called WorkCalendarSched is used. This is because deliveries are dependant on when the company using Dynamics AX actually can send the order. Not all companies work on weekends.
This is when WorkCalendarSched comes in handy, with this class and the class method “shedDate” you can make sure that the delivery is set to a day when the company actually is going to be able deliver.
Continue reading WorkCalendarSched
This is an easy way to use labels and infologs in a bit more dynamic manner. It also makes it easier to do type conversion of for example dates to strings when printing to infologs.
static void FO_StrFmt(Args _args)
CustTable cust = CustTable::find("4000");
SalesTable sales = SalesTable::find("00697_036");
info(strFmt("Hello %1!", cust.Name));
info(strFmt("Hello %1, you live in %2!",
Hello Light and Design!
Hello Light and Design, you live in Los Angeles!
Notice that the date is presented in the format that is set up on the clients computer. In this case the Swedish format. The same format that you see in the Sales Table form.
I was building an extended search form for one of our customers. When called from one form everything worked fine, but when called from a second form my grid only contained one record… Exact same parameters, same menu item etc. When looking around I found that when the error occured, I was calling from a form which had same table (InventTable) as one of it’s main Data Sources. This is one of the non-documented features in AX, if same table exists in the Data Sources in both forms, AX tryes to link them together. To break this connection I had to call ClearDynaLinks() on the second form. Like below, in my search form’s init method.
I noticed a bug in the routine for printing out misc. charges on the SalesInvoice_SE document. The problem is that the label that are printed is always “Amount currency”, and the routine doesn’t calculate the amount correctly when the category is set to Pcs or Percent. I Haven’t tested if the SalesInvoice document has the same problem, but the markupSpec method seams to have the same errors so I think it shares the same problems.
Continue reading Misc. charges bug
Using the PriceDisc class in Dynamics AX is not always the easiest thing in the world. If you start out with a sales line or a purchase line you got methods that helps you get prices from the trade agreement, but if all the info you have is the ItemId and VendAccount it gets a bit tricky.
My thinking was that I should be able to use the PriceDisc class just as the InventOnhand class. You put in basic info, and the more data you enter into the class the more precise the result gets. But the hurdle I had trouble getting over was that the class PriceDisc requires a record from table InventDim, something that you only get if you start out with a sales line or a purchase line.
Continue reading The magic of InventDim “AllBlank”
We start out in the PurchTable form where we, by clicking a button, calls a class with the help of a menu item. The menu item has been given the datasource PurchTable.
The called class updates the record that was selected in the PurchTable, but when this is done the user cannot see the changes without pressing F5 or restarting the form completely. The method FO_doRefresh() does a refresh on the PurchTable Form.
Continue reading Refresh caller form
In Dynamics AX it is possible to select multiple records in any form, well at least you can if more than one record is visible. This example describes a simple way to handle the selected records before doing something with or to them. In this example we have a clicked-method on a button. If, and only if, the new field “newField” on our table “TestTable” is set on all the selected records, then the super() is run.
Continue reading Multiple records selected in a form
I have only tested this i Dynamics AX SP2, but I would guess that this is also a problem in SP1.
When registering a Sales Order of the type “Returned item”, there are some validations and other functionality that apply. To start with you get an auto generated RMA number. There is also not possible to enter a positive quantity on the order lines, because that would defeat the purpose of the Sales type “Returned item”. The customer is supposed to get money back, not pay the items price again when returning it.
Continue reading Returned item bug