Split Purchase order lines

Sometime we need to split purchase order line into multiple lines with Quantity = 1, here is a piece of code through which you can split purchase order line into multiple lines. You can easily alter the below code based on your Quantity factor.

static void SplitPurchLine(Args _args)

{

    PurchQty    qty;

    PurchTable  purchTable;

    PurchLine   purchLine;

    

    purchTable = PurchTable::find("PO-0001");

    

    while select forUpdate purchLine

        where  purchLine.PurchId == purchTable.PurchId && purchLine.PurchQty > 1

    {

        qty = purchLine.PurchQty;

        while (qty > 1)

        {

            PLPurchLineSplit::update(purchLine, 1);

            qty -= 1;

        }

    }

}

Non-admin debugging

1.) Add the admin to the roles that you want to test. Note that it is ok to leave the admin user in the system administration role.

2.) Open a dev workspace and close the application work spaces.
3.) Set applicable breakpoints.
4.) Create a job with the following line of code and execute: SecurityUtil::sysAdminMode(false);

5.) So at this point the current session is in "non-admin mode".
6.) Use Ctrl+W to open the application work space. You should notice that few menus / menu items are available
7.) Run the test and any break points set will be hit.

When SecurityUtil::sysAdminMode(…) is invoked, it is only applicable to the current session. So you must use CTRL+W to open the app workspace; launching a new client will not work.

Accessing the correct QueryBuildDataSource for a Form DataSource

Traditionally within Forms it has been rather cumbersome to get to the QueryBuildDataSource for a specific FormDataSource within Forms. You had to write code such as this:

public void FormDataSource::init()
{
    QueryBuildDataSource qbds;

    super();

    qbds = this.query().dataSourceTable(tableNum(CustTable));
}

That’s all fine and dandy if you have a simple Form, but on some Forms you might have multiple instances of CustTable, especially with the advent of ReferenceDataSources. In these cases you might fall back to using the name of the FormDataSource to ensure you get the correct QueryBuildDataSource:

public void FormDataSource::init()
{
    QueryBuildDataSource qbds;

    super();

    qbds = this.query().dataSourceName(this.name());

}

This is also problematic in the cases that a different query is applied to the Form, such as in the CopyCallerQuery from a List Page to a Details Page. This makes it all very confusing and difficult, and to tell you the truth, we have a very long method in the kernel that finds the correct QueryBuildDataSource for the respective FormDataSource. The good news is those methods are now exposed to X++

With Dynamics AX 2012 you can now use the methods FormDataSource::queryBuildDataSource() and FormDataSource::queryRunQueryBuildDataSource(). The first method will return you the QueryBuildDataSource in the FormDataSource.query(), while the second will return you the QueryBuildDataSource in the FormDataSource.queryRun().query(). There'll be another blog entry discussing when using each is appropriate, but the short of it is use the first whenever you want to modify the QueryBuildDataSource and have the modification stay throughout the life of the Form (such as adding developer ranges that you never want the user to be able to change). The second should be used when you want to make modifications that will just live for the current executeQuery() call and will be cleared whenever the user clicks on the "Clear Filters" button.

 

Dynamics AX Cheat Sheet

I have compiled general events required to perform upon certain actions. I named it as Dynamics AX Cheat Sheet. I will update it time to time based on new ideas and will try to enhance the UI of this cheat sheet. Your valuable comments and suggestions are most Welcome.



Dynamics AX Cheat Sheet

Happy Daxing!!!!