Book Image

Extending Microsoft Dynamics 365 Finance and Supply Chain Management Cookbook - Second Edition

By : Simon Buxton
Book Image

Extending Microsoft Dynamics 365 Finance and Supply Chain Management Cookbook - Second Edition

By: Simon Buxton

Overview of this book

Dynamics 365 Finance and Supply Chain Management is Microsoft’s ERP solution, which can be implemented as a cloud or on-premise solution to facilitate better decision-making with the help of contemporary, scalable ERP system tools. This book is updated with the latest features of Dynamics 365 Finance and Supply Chain Management including Chain of Command (CoC), Acceptance Test Libraries (ATL), and Business Events. The book not only features more than 100 tutorials that allow you to create and extend business solutions, but also addresses specific problems and offers solutions with insights into how they work. This cookbook starts by helping you set up a Azure DevOps project and taking you through the different data types and structures used to create tables. You will then gain an understanding of user interfaces, write extensible code, manage data entities, and even model Dynamics 365 ERP for security. As you advance, you’ll learn how to work with various in-built Dynamics frameworks such as SysOperation, SysTest, and Business Events. Finally, you’ll get to grips with automated build management and workflows for better application state management. By the end of this book, you’ll have become proficient in packaging and deploying end-to-end scalable solutions with Microsoft Dynamics 365 Finance and Supply Chain Management.
Table of Contents (17 chapters)

Creating extended data types

Extended data types are commonly referred to as EDTs. They extend base types, such as Strings and Integers by adding properties that affect the appearance, behavior, data (size), and table reference/relationships. This means that we can have types like CustAccount that have a label, size, table relation information, and other properties that provide consistency and greater understanding within the data model.

Another example of an EDT is Name. Should we change the StringSize property of this field, all fields based on this EDT will be adjusted; and if we reduce the size, it will truncate the values to the new size.

All fields should be based on an EDT or an enum, but they are not just used to enforce consistency in the data model but are used as types when writing code.

The EDT in this example will be a primary key field for a table that we will use later in the chapter.

Getting ready

We just need to have an SCM project open in Visual Studio. To look at standard examples, ensure that Application Explorer is open by selecting View | Application Explorer.

How to do it...

We will create an EDT for a vehicle number. A vehicle table is of a similar pattern to customers and vendors, and we will extend the Num EDT for this type.

The Num EDT is used (at some level in the type hierarchy) for fields that will use a number sequence.

To create the EDT, follow these steps:

  1. Creating an EDT starts in the same way as all new Dynamics 365 items: by pressing Ctrl + Shift + A or right-clicking on a folder in the Solution Explorer and choosing Add | New Item.
  2. Select Data Types from the left-hand list, and then select EDT String.
  3. In the Name field, enter ConVMSVehicleId and click Add.
  4. Next, we need to complete the property sheet; the main properties are covered in the following table:
Property Value Description

Label

Vehicle ID

This is the label that will be presented to the user on the user interface when added as a field to a table.

Help Text

A unique reference for the vehicle record

This is the help text shown to the user when this field is selected or the mouse hovers over the controls based on this EDT.

Extends

Num

This should be completed for all EDTs, as we are usually following a pattern, such as ID, name, and grouping fields. This is explained in the There's more... section.

Size

This will be read-only, as we have based this EDT on another EDT. Although this is under the Appearance section, it controls the physical size of the associated fields in the database.

Reference Table

For types used as a primary key field on a table, this property should be populated. Along with the table references, it can be used to create a foreign key relation on child tables.

As always, remember to create labels for the Label and Help Text properties for each of your supported languages.
  1. If this EDT is to be used as a primary key field, we will need to populate the Table References node.
We will complete this later in the chapter, but you can see a good example by looking at the standard AssetId EDT. Navigate through the Application Explorer to AOT | Data Types | Extended Data Types, right-click on AssetId and select Open designer.
  1. Press Save (Ctrl + S) or Save all (Ctrl + Shift + S) in the toolbar to save the changes.

How it works...

There is a back and forth element to EDT creation when we are creating a primary key field. We can't create the field without the EDT, yet we can't complete the EDT when the field is on the table.

EDTs are types. Therefore, they must be globally unique among all other types, such as tables, views, data entities, enums, classes, and other EDTs. The EDT properties aren't just defaults, but they control behavior too. Should we add an unbound control to a form based on an EDT, the EDT can use the Table Reference property to provide a drop-down list, and the contents will be taken from a field group on the table.

There's more...

EDTs can also extend other EDTs; although, child EDTs can only affect appearance properties. This is useful when we want to enforce the physical storage attributes of a range of types, but have a different label depending on the context. If we change the size of a base EDT, all the EDTs that extend it will be affected and, consequently, all of the fields that are based on them.

We often extend specific EDTs when creating an EDT for certain types of fields.

The typical EDTs we use for this are shown in the following table:

EDT Base type Size Reason
SysGroup String 10 This is used for the primary key fields for group tables. Group tables are those used for backing tables for drop-down lists. They may provide further definition to a record, or just be used for reporting. Examples include the following:
  • Item group
  • Customer group
  • Item model group
Num String 20 This is used for primary keys on worksheet tables, such as the sales order table (SalesTable). These fields are usually numbered based on a number sequence, which must have a string size of 20 characters.
Examples include the following:
  • Sales order number
  • Purchase order number
AccountNum String 20 This is used for primary key fields for main tables, such as the customer table. These tables are also, usually, based on a number sequence.
Examples include the following:
  • Customer account
  • Vendor account
Name String 60 All name fields should be based on this EDT, such as vehicle name, customer name, and so on. This EDT can be used as is, unless we wish to specify a label and help text.
Description String 60 This is used as the description field on group tables. This EDT is usually used as is, and isn't usually extended.
AmountMST Real All monetary value EDTs that store the amount in local currency should be based on this EDT. MST stands for Monetary Standard.
AmountCur Real All monetary value EDTs that store the amount in the transaction currency should be based on this EDT.
Qty Real All fields that store a quantity should be based on this EDT.

There are many more. Rather than listing them all here, a good practice is to locate a pattern used in standard SCM and follow the same pattern.