In this chapter, we will cover the more advanced techniques of Dynamics AX development. The topics we will cover are as follows:
Date-effective tables, or ValidTimeState
tables, allow us to see a record at a point in time, such as an employee's details in the past, or even planned future changes. This feature is part of the table definition in AX, which makes this technology much easier to use. There is, therefore, very little coding required in order to implement it.
This is pretty exciting, but we shouldn't get too carried away by it. Each edit will result in a new, time stamped record. Main tables, such as customer and vendor tables, should not be made date-effective, as it will create a lot of unnecessary records and complicate the foreign key relations to them. For example, if we did make the customer table date-effective, we would need to determine the version of the customer record that should be found when navigating back from a customer transaction.
In some cases, AX makes deliberate use of this technology. The LogisticsPostalAddress
record is date-effective, yet the foreign key relation on SalesTable
is based on RecId
. This means that it relates to a specific version, which is suitable since the sales order should go to the address at the point when the order was taken.
For our example, we'll use the vehicle service records, which will consist of two parts. The first part is to configure the table as being date-effective and the second is to update the interface so that the user can see the record at a specific point in time.
To configure the table as a date-effective table, follow these steps:
ConFMSVehServiceTable
table.Date
will make the records valid on a day-by-day basis.ValidFrom
and ValidTo
. They are of the UtcDateTime type.Cannot edit a record in Vehicle service table (ConFMSVehServiceTable). Table does not contain a valid time state key. A unique index needs to be marked as a valid time state key.
ValidFrom
and ValidTo
fields onto the ServiceIdx
index.Yes
and set ValidTimeStateMode to NoGap
.ConFMSVehServiceTable
form and change the value of Current odometer. If you scan through the records or open the table's list page, it appears as if a version was not created. But, if you open the table browser to see what is actually stored, you will see that a new record was created, like this:find
and exist
methods to handle the fact that ServiceId
is no longer unique. By default, we want the current valid record, with the ability to select a record at a particular time. Modify the find
method as follows:public static ConFMSVehServiceTable find( ConFMSServiceId _id, utcdatetime _validFrom = DateTimeUtil::utcNow(), utcdatetime _validTo = _validFrom, boolean _forUpdate = false) { ConFMSVehServiceTable service; service.selectForUpdate(_forUpdate); if(_id != "") { select validTimeState(_validFrom, _validTo) service where service.ServiceId == _id; } return service; }
exist
method.The next part is to update ConFMSVehServiceTable
so that we can view the data at a point in time, which is done by the following steps:
classDeclaration
code window and add the following code inside the braces:DateEffectivenessPaneController dePaneController
VersionGroup
and set the following properties:
AutoDeclaration |
|
VerticalSpacing |
|
HideIfEmpty |
|
init
method so that it reads like this:public void init() { super(); formHandler = ConFMSVehServiceTableForm::construct(); switch(element.args().dataset()) { case tableNum(ConFMSVehicleTable): formHandler.parmVehicleTable( element.args().record()); break; } dePaneController = DateEffectivenessPaneController::constructWithGroup( element, versionGroup, // the form group ConFMSVehServiceTable_ds, false, // use plural labels true, // allow show all records true); // use datetime }
ModifiedDateTime
and modifiedBy
fields useful in this scenario.3.144.96.105