Applicability

This is applicable for Microsoft Dynamics 365 Supply Chain Management, a.k.a. Finance and Operations.

The solution presented here uses the extension capabilities in 365, but can easily be converted to work in AX2012 using the overlayering capability of that system.

Problem

There is a need to prompt the user for additional information during the Unplanned Move Process, and change the posting to reflect this.

For this example we want to prompt the user whether or not they want to update the to location entered, as a default location for the item in question.

Solution

This can be achieved by extending the Class MobDocUnplannedCount.

The way an unplanned flow, such as the Unplanned Move, works is that the user has a page with a filter/header, where the basic information, needed to prompt the user, is entered. In this case it is the itemId of the item you want to move.

Once the user has entered this information, the device sends a request to the backend D365FO, and in this case, the MobDocUnplannedMove class is found and activated.

The method that needs to be extended is name unplannedMoveRegistrationCollectors().

To add a new field to the prompting flow we can add the following;

Adding to the user Prompt
[ExtensionOf(classStr(MobDocUnplannedMove))]
final class MobDocUnplannedMoveExample_Extension
{
    public Map unplannedMoveRegistrationCollectors()
    {
		//Get collectors through Chain-Of-Command
        Map registrationCollectors = next unplannedMoveRegistrationCollectors();

        registrationCollectors.insert('updateDefault',MobRegistrationCollectorRadioButton::RadioButtonStepMap(100,'updateDefault',"Update Default Location","Update Default Location","Update Default Location",'No','Yes;No'));

        return registrationCollectors;
    }

}

In line 9, a new Registration Collector is added. Registration Collectors is the term used in Mobile WMS, for when a field in a flow is shown to the user.

There are 16 different types of Registration Collectors, that can be used in the flows:

You can read more about the different steps here.

When the above code has been compiled, the next time you use the Unplanned Move flow, a new step has been added in the end of the flow.



What is missing now, is this being handled in the posting process.


To do this, an extension must also be made to the postUnplannedMove() method on the MobDocUnplannedMove class:

Posting extension
	public void postUnplannedMove()
	{
		boolean updateDefault = unplannedMoveRequest.getFieldValue('updateDefault') == 'Yes'; //Get the value of the extra step
		next postUnplannedMove();
		//Do stuff here to update relevant data. The journal can be found in the variable inventJournalTable
	}


That should be sufficient changes to do the required customization.

The unplannedMoveRequest is of the type MobRequestItemAndDimensionElement, and adding a parmMethod called updateDefault on this class through an extension, will make the value available on this parm method. No need to do more, the system will adapt to the new parmMethod.

See also