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.

5. 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.

6. 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.