You’re offline. This is a read only version of the page.
Hi,
I am currently modifying AX 2012 R3. There is little documentation about Standard lookup form filtering for fields connected through Natural Foreign Key relation - the most informative I have found is here: https://msdn.microsoft.com/en-us/library/aa597861.aspx#Anchor_2. To cite the site under the link:
When you use the lookup to specify a record in another table, you must supply values for all the fields in the natural key. In addition, the field values must identify a valid record in the related table. To help you select a valid record, the value that you chose for the field that represents the first relation field restricts the values that you will see in the field that represents the second relation field. The same type of filter is applied to each subsequent member field of the natural key.
Let's consider standard AX address capabilities in this matter. If we open LogisticsAddresssCity [sic] table, then if we select a country, then the lookup form for states will filter all states by the selected country (which can be seen explicitly stated by opening the lookup form's query window by pressing Ctrl+F3 while on the lookup form - where we'll see a range setup for the country we chose). The same goes for the county field - when we enter a country and a state, only counties from this country and state will be shown. The chunk of bold text from the citation doesn't explain the peculiarity which is present in this algorithm, however. To show the idiosyncrasy let's consider adding a "Commune" administrative division, which slips between "County" and "City" address entities in AX address capabilities.
From what the bold text reads it should be enough for the filtering to work, ie. if we open the LogisticsAddresssCity table and properly fill the country, state and county fields, the communes should be filtered by that. However, if we're unlucky during the automatic procedure of Natural Foreign Key relation lines generation (for which the code is unfortunately inaccessible), any number of them could be not taken into account as filters. The idiosyncrasy is that the applied filters on auto-generated lookup forms come only from those fields for which the relation lines are above the relation line coming from the new table (no matter their order). So, in this example, if have ended up with the relation properly defined as:
then after filling country, state and county fields the filters under Ctrl+F3 on the lookup form will be:
| Table | Field | Criteria |
| Communes | Country/Region | <country we chose> |
| Communes | State | <state we chose> |
| Communes | County | <county we chose> |
However, if we're unlucky and the automatic procedure of Natural Foreign Key relation lines generation ends up with:
[Note that two bold bottom lines are switched from the proper order]
then we get:
| Table | Field | Criteria |
| Communes | Country/Region | <country we chose> |
| Communes | State | <state we chose> |
| Communes | County |
[Note the empty county filter]
and we are returned all communes from all counties withing the chosen country and state.
And so, if we're the most unlucky and end up with:
[note the field coming from the new table is first]
we get:
| Table | Field | Criteria |
| Communes | Country/Region | |
| Communes | State | |
| Communes | County |
[note all the criteria are empty]
and are returned all the communes in the database on the lookup form.
So to sum up: the relation line concerning the field coming from the new table has to go last in the AOT. To change the order of the lines (they can't be ordered by drag-and-dropping) use Alt+Up and Alt+Down, which move the current line up and down, respectively.
*This post is locked for comments
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,232
Super User 2024 Season 2
#2
Martin Dráb
230,064
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (