Each entry or sub-entry ties directly to an Application Object Tree (AOT) class, has a name ending in “ConsistencyCheck” e.g for the AR module class, it is “SalesConsistencyCheck”.
The code searches all classes for any that derive from “SysConsistencyCheck”.
When there are sub-entries, each one is further derived from the class for that module.
The class “CustConsistencyCheck” has two classes that derive from it, which follow the naming for subclasses.
• “CustConsistencyCheck_LinkTable ” for checking Relation tables
• “CustConsistencyCheck_BOE” for checking Bills of exchange
Dynamics AX calls the method treeParentClassId() to determine which classes are subordinate to what..
(The default is a parent of the main class SysConsistencyCheck.)
A Module dropdown restricts the tree to just that module (where the “module” is one of the classes that says its parent is “SysConsistencyCheck”; entries in the first level of the tree below “Programs”).
When the “SysConsistencyCheckJob” class, which uses the RunBase framework, is run It sets up the form and then calls the “SysConsistencyCheck” classes selected.
The output is an InfoLog with all consistency errors and warning:
The “SysConsistencyCheck” class has some hook methods that can be overridden to allow the developer to add code at certain points in the process.
It also has methods that do the consistency check for a particular table (kernelCheckTable()), an individual record (kernelCheckRecord()) or a subset of records based on a query (kernelCheckRecords()).
To check a record in a table, the kernelCheckRecord() method first calls the table’s validateWrite() method on the record.
It goes through each non-system field in the record and calls the table’s validateField() method on it.
Don't be surprised to find that this exposes some problems with standard AX code.
I suggest generally follow Steven's advice, and when you want to try this do it in a test system backed up from live.
