In this chapter, we will cover the tasks required to write the data dictionary elements commonly used within Operations development.

Data structures in Operations are not just tables and views, but also include the ability to define a data dictionary. This is now called the Data Model in Operations. The data model hasn't changed much in structure since AX 2012, but is much more refined with many more features to aid development and minimize the footprint when extending standard tables and types.

This chapter does not cover creating extensions of standard types, but it does cover how to create types that allow your structures to be extensible. Extensibility is covered in Extending standard tables without customization footprint section of Chapter 7, Leveraging Extensibility .

Most development in Operations is based on patterns, even if we are not aware of it. For example, the Vendor and Customer...

Enumerated types are called Base Enums in Operations, which are similar to enumerated types in C#. They are commonly referred to as Enums. It is an integer referenced as a symbol, which can be used in code to control logic. It can also be used as a field on a table that provides a fixed drop-down list to the user. When used as a field, it has the ability to provide user-friendly labels for each symbol.

All Enums have to be defined in the data model before we use them and can't be defined within a class or method.

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 Customer account 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.

In this section, we will create a group table. A group table is used as a foreign key on main tables, such as the customer group on the customer table and the vendor group on the vendor table; the customer and vendor tables are examples of main tables. Group tables have at least two fields, an ID and a Description field, but can contain more as required.

In this case, to aid flow, we will create the group table first.

We just need a Operations project open in Visual Studio.

We will create a Vehicle group table. We don't have much choice on the name in this as...

A parameter table only contains one record per company. The table contains a list of fields, which can be defaults or company-specific options used in code to determine what should happen. The parameter table is usually created first, and the various fields that act as parameters are added as we create the solution.

This follows directly from the Creating setup tables recipe.

To create the parameter table follow these steps:

1. Create a new table called ConWHSVehiclePararameters; again, the prefix and suffix is based on practice. Usually, the name will only be <Prefix>+<Module>+Parameters.
2. Set the table's parameters as follows:

In this section, we will create a main table, similar to the customer table. The steps are similar to the vehicle group, and we will abbreviate some of the steps we have already done. The pattern described in this recipe can be applied to any main table using your own data types.

The table in this example will be to store vehicle details. The table design will be as follows:

In order to follow these steps, the elements created earlier in this chapter must be created...

Order and line tables are used whenever we need a worksheet to enter data that is later acted upon. Once they have been processed, they should no longer be required. Reports should act upon the transactions that the order created, such as inventory transactions, sales ledger transactions, invoices, and more.

Although we will be using the tables created earlier, the pattern can be followed with your own solution.

We will first create the worksheet header table, which will be a vehicle service order table:

1. Create a new table named ConWHSVehicleServiceTable...

This recipe continues from the previous order header table recipe. The example in this recipe is that we will have service order lines that reflect the work required on the vehicle. The concepts in this recipe can be applied to any order line table; to follow exactly, the previous recipes should be completed first.

To create the order line table, follow these steps:

1. Create a new table named ConWHSVehicleServiceLine.
2. Drag the following EDTs onto the table:
   • ConWHSVehicleServiceId
   • LineNum
   • ItemId (you may receive an error if you haven't referenced Application Suite)
   • ItemName
   • ConWHSVehicleServiceStatus

3. Remove the ConWHSVehicle prefixes.
4. The ServiceId and LineNum fields are usually controlled from code, so make them...