Copying a Record using data() method in D365 for Operations

Introduction

Data is an essential pillar of an Enterprise. Therefore, Microsoft Dynamics 365 for Finance and Operations provides various data manipulation tasks. Among which, copying an existing record for re usability is an important task. Dynamics 365 application provides numerous places where the copy functionality exists: Project management and accounting > Projects > All projects > Copy project or Cost management > Inventory accounting > Costing versions. The idea is clear: the existing data is reused while creating new entries.

Solution

Microsoft provides an out-of-the-box solution for our problem - The Common table provides us with a data() method that lets us copy all fields from a record buffer into another. This approach provides us with an independent copy that is capable of operating on its own.

Demonstration

In this demonstration we are going to duplicate a record on HcmEthnicOrigin form (Human resources > Setup > Ethnic origins). Lets take a look at the record that we want to duplicate:

We are going to use a Runnable class to duplicate the record shown above:

public static void main (Args _args) 
{ 
    HcmEthnicOrigin asianEthnicOrigin = HcmEthnicOrigin::findByEthnicOrigin('Asian'); 

    ttsBegin; 
    HcmEthnicOrigin arabEthnicOrigin = asianEthnicOrigin.data(); 

    arabEthnicOrigin.EthnicOriginId = 'Arab'; 
    arabEthnicOrigin.Description = 'A person having origins in Saudi Arab, Kuwait, Oman and UAE'; 

    if (!arabEthnicOrigin.validateWrite()) 
    { 
        throw Exception::Error; 
    } 

    arabEthnicOrigin.insert(); 
    ttsCommit; 
} 

The result after running the class is (Arab record is inserted):

Conclusion

In this little demonstration we can see the power that lies within the data() method. It is capable of creating a standalone copy of a record that can be modified as per our requirement. This allows for a better development and user experience since the user is engaged in modifying fields as per his requirement.

Multi Table Lookup using Views in Microsoft Dynamics 365 for Operations

Introduction

With the release of Microsoft Dynamics 365 for Finance and Operations, many features have been deprecated, and upgraded with solutions that provide abstract and far better control to the developers than its previous counterpart. Unfortunately, with the deprecation of SysMultiTableLookup class, there was no substitute provided by Microsoft. Therefore, to handle this scenario, we are left with implementing the underlying scenario using either display methods or Views. The problem with display methods is that we can not filter columns that were defined by display methods, leaving Views as our optimal choice for implementing multi table lookups in Microsoft Dynamics 365 for Finance and Operations.

Solution

In this solution, we are going to display Worker's PersonnelNumber, Worker's Name, and the current Department that he works in. As dicussed above, we are going to start by creating a view. Therefore, we are going to use the HcmWorker, HcmPositionWorkerAssignment, HcmPositionDetail, DirPartyTable, and OMOperatingUnit tables.

The view after being configured should look like this, Note that relations and fields are visualized in the image below:

The results in the table browser after synchronizing the view looks like:

Note: Multiple records per worker are being displayed by the view, and we need to display worker's current record. To handle this, we would either handle this by using Ranges on View or the Lookup method. In this example we are going to be using the later solution.

Next up, we are going to create and design a form:

Finally, we'd override the lookup method on the LookupControl FormStringControl:

[Form] 
public class WorkerDepartmentLookup extends FormRun 
{ 
    [Control("String")] 
    public void lookup() 
    { 
        Query query = new Query(); 
        QueryBuildDataSource qbds = query.addDataSource(tableNum(WorkerDepartmentView)); 

        qbds.addRange(fieldNum(WorkerDepartmentView, ValidFrom)).value(strFmt("<%1", today())); 
        qbds.addRange(fieldNum(WorkerDepartmentView, ValidTo)).value(strFmt(">%1", today())); 

        SysTableLookup sysTableLookup = SysTableLookup::newParameters(tableNum(WorkerDepartmentView), this); 

        sysTableLookup.parmQuery(query); 
        sysTableLookup.addLookupfield(fieldNum(WorkerDepartmentView, PersonnelNumber)); 
        sysTableLookup.addLookupfield(fieldNum(WorkerDepartmentView, WorkerName)); 
        sysTableLookup.addLookupfield(fieldNum(WorkerDepartmentView, DepartmentName)); 
        sysTableLookup.performFormLookup(); 
    } 
}

Lastly, the results of the above query during control lookup are as:

Conclusion

In this blog, we looked at how to implement Multi Table Lookup using Views in Microsoft Dynamics 365 for Finance and Operations. If you are bummed about the work put into implementing the solution, than you should be aware about the advantages provided by views. First of all, Views are virtual tables i.e. they don't store data therefore taking up literally no space. Secondly, Views provide faster lookup than run time queries generated by the Query object. Lastly, Views allows us to filter each individual column that display method deny.

Color Picker Control in Microsoft Dynamics 365 for Operations

Introduction

Microsoft Dynamics 365 for Finance and Operations provides many out-of-the-box controls, but even after covering a vast amount, some controls need to be implemented by our self. Among those controls is a Color picker control, which allows a user to select a color from a selection of approximate 16 million colors.

Solution

In this solution, we would be implementing a basic color picker control with the goal of looking up 16 million colors, and allowing a user to select a single one.

To start, we'd create a form with the following form control:

Note that we are using a FormIntControl to specify a color picker control. An alternative to this approach is to use FormStringControl instead.

Now we will override the lookup method on Color picker control, this would allow us to view the colors in a circular wheel when the drop down button on FormIntegerControl is clicked.

public class ColorPicker extends FormRun
{
    [Control("Integer")]
    public void lookup()
    {
        int color = this.value();
        color = ColorSelection::selectColor(this, color);
        this.value(color);
        this.backgroundColor(color);
    }
}

Finally, we would run the form to view the results as:

Conclusion

In this blog, we looked at creating a color picker control. Even though we didn't perform operations on it to control the amount of colors it can produce, or display a subset of colors to the user, but we got an overview of its working. This can be helpful in scenarios in which colors are important such as tint of a car or paint of the house at a particular portion.

The new Messaging API in Dynamics 365 for Operations

Introduction

With the release of Microsoft Dynamics 365 for Finance and Operations, many features have been revamped, including the Messaging API. Even though support for legacy API (info(), warning()/checkFailed(), and error()) still exists, they are now a part of the framework's new messaging system. The new messaging system exposes a Message class that allows you to Add or Remove messages from the user interface. This is a powerful feature since it can be used to reflect the current state of the system. Therefore, this API is useful for enhancing the user's experience who is using the application.

The Add method's signature is as:

public static int64 Add(MessageSeverity severity, SysInfoLogStr txt);

The Remove method's signature is as:

public static int64 Remove(int64 messageId);

Where, MessageSeverity is an enumeration that identifies the type of message being logged. The possible values are Informational, Warning, and Error.

Lets see how we can actually use the new Message class.

Demonstration

The example below demonstrates how the new Add and Remove methods work, and how that code reflects the form's current state.

public class MessageAPI 
{ 
    public static void main(Args _args) 
    { 
        // Adding messages to infolog stack 
        Message::Add(MessageSeverity::Informational, "Information Message"); 
        Message::Add(MessageSeverity::Warning, "Warning Message"); 
        Message::Add(MessageSeverity::Error, "Error Message"); 

        // Adding message to infolog stack, but pertaining its message Id 
        int64 noMsg = Message::Add(MessageSeverity::Informational, "This message won't be displayed"); 

        // Removing message with messageId identifier 
        Message::Remove(noMsg); 
    } 
}

The result of running MessageAPI class is as:

The demonstration above shows how messages can be logged onto the infolog window. The program when executed, pushes 4 messages to the user interface message stack via Add method. After that we call the Remove method to remove one particular message from the stack, leaving us with 3 messages (Information Message, Warning Message, and Error Message). Finally, when the program execution is completed, it displays 3 messages that are shown in the screenshot above.

Conclusion

As you can see from this simple demonstration. The new Message API controls how and when to display certain messages. The Add method pushes a message to the infolog stack while returning its unique Id, and the Remove method removes a particular message with a specific MessageId. The provides us with dynamic control over how and when to display certain message on the user interface.