D365 Datasource range lock / visibility

Microsoft Dynamics 365 for Operations & Financials

When adding ranges to datasources in code, you sometimes don't want the user to alter the range in any way. Sometimes it is also necessary to hide the applied range.

To lock or hide the range, use the status method of the QueryBuildRange class. The following code creates a hidden range of the field MyField to empty string.

QueryBuildRange qbrExampleRange;
qbrExampleRange = MyDatasource_ds.query().dataSourceTable(tableNum(MyTable))
	.addRange(fieldNum(MyTable, MyField));
qbrExampleRange.value(SysQuery::valueEmptyString());
qbrExampleRange.status(RangeStatus::Hidden);

The user will not be able to see or change the range of the field MyField.

Similarly the following code sets the field Department to "HQ". This time setting the range status to Locked.

QueryBuildRange qbrDepartmentRange;
qbrDepartmentRange = MyDatasource_ds.query().dataSourceTable(tableNum(MyTable))
	.addRange(fieldNum(MyTable, Department));
qbrDepartmentRange.value(SysQuery::value('HQ'));
qbrDepartmentRange.status(RangeStatus::Locked);

The user will be able to see that there is a "HQ" filter on the Department field, but not able to remove it or change the value.

D365 Capture switch between gridview and details view

Microsoft Dynamics 365 for Operations & Financials

In a form with the Details Master pattern, the user switches between viewing the list view (grid with all records) and a details view (only one record). This navigation happens within the same form, so there is no form initialization upon entering a record detail or going back to the list.

If you want to something to happen when the user switches between views, you need to capture the switch itself.

Let's say you want to enable a button in list view, but disable it in detail view.
Override the task() method like this:

public int task(int _p1)
    {
        int ret;
  
        #Task

        if(_p1 == #taskSwitchToDetailsView)
        {
            MyButton.enabled(false);
        }
        else if(_p1 == #taskSwitchToGridView)
        {
            MyButton.enabled(true);
        }

        ret = super(_p1);
        return ret;
    }

You might also want to enable or disable the button when the form opens.
Since controls are rendered after the init() is called, you need to put the code in the run() method.
You need to check if the form is in list or detail view mode:

public void run()
    {
        super();

        if(element.viewOptionHelper().getViewOption() == FormViewOption::Details)
        {
            MyButton.enabled(false);
        }

    }

D365 Do not disable form controls - disable the datasource fields!

When developing forms in Microsoft Dynamics 365 for Operations you sometimes want to disallow the user to edit some of the forms fields. The typical approach is to turn on Auto Declaration on the form controls and diasable them using:

FormControl.allowEdit(false);

The problem with this approach is that the same field might be exposed more than once in your design, for instance both in the grid view and in the details view. Also, users adding fields via Personalization might pose challenges. In order to make sure the user is not allowed to edit the data, use this approach:

Datasource_ds.object(fieldNum(tablename, fieldname)).allowEdit(false);

Similarly you can enable/disable the fields if this is your business requirement. This will make it more evident for the user that the field is not editable:

Datasource_ds.object(fieldNum(tablename, fieldname)).enabled(false);

Domain role with multiplicity 0..1 or 1 can hold at most 1 link

I got the following error when I duplicate a SSRS report in Visual Studio:

Domain role with multiplicity 0..1 or 1 can hold at most 1 link: DataSetParameter of Microsoft.Dynamics.Framework.Design.Model.Reports.DataSetParameterRefersToParameter.

To resolve it do the following on the report datasets:

1. Change the datasource type to Query.
2. Delete the whole query text in the "Query" field.
3. Save, rebuild and change the values on the datasource back to the ones intended

Thanks to AlexDAX for this tip!

I also noticed the above actions can help resolve other problems, like inconsistency in the report parameters (can occur if you change the contract parameters).

Cancel salesline in x++ code (including CW)

Cancelling an open salesline through code is a simple task.
When you're operating with catch weight items you need to include the CW remainder field.

The following code will cancel all open lines on a sales order that has been invoiced.
Don't forget tts.

    while select forupdate salesLine
    join salesTable
        where   salesTable.SalesId == "[Your SO]"
        &&      salesTable.SalesStatus == SalesStatus::Backorder
        &&      salesTable.DocumentStatus == DocumentStatus::Invoice
        &&      salesLine.SalesStatus == SalesStatus::Backorder
    {
        salesLine.RemainInventPhysical = 0;
        salesLine.RemainSalesPhysical = 0;
        salesLine.PdsCWRemainInventPhysical = 0;
        salesLine.Update();
    }

Parameter _reportName cannot be null or empty.

Recently came over a problem with running SSRS reports from AX 2012 (R2). This infolog error message was presented immediately when trying to run a report:

Parameter _reportName cannot be null or empty.
The [CLASSNAME].[METHODNAME]() reflection API could not create and return the SrsReportNameAttribute object.

In this specific case it looks like an earlier full compile did not finish.

If you encounter this problem I would suggest that you first compile the class mentioned in the error message and see if this solves the problem. Then you should schedule for a new full compile of the application.

AX World End Date

In some cases you will need to use the highest date available in a datetime field in Dynamics AX 2012.
Microsoft has decided that this date is:

December 31, 2154

Specifically when handling Date Effective Data in AX 2012, you might encounter date fields with the value "Never" when viewing it in the table browser. The field actually contains the date Dec 31, 2154.

When writing, updating or querying date effective records in x++, you can use the date 31\12\2154.
But a more accurate and less cryptic apporach would be to use the maxDate system function:

myDateEffectiveRecord.ValidTo = maxDate();