Get value from lookup & assign the value into fields.

Finance and Operations/AX Developer Forum
1

Hi all,

I’m new to AX, i have read tutorials about lookup none of them discussed how to get value from the selected record from the lookup and put it in other fields. So my situation is :

I have a grid with 3 column, column lookup, color and size. *illustrated

Lookup field : ItemID, Item’s color, Item’s size.

Now, if i select a record from this lookup how can i get item’s color and item’s size (from lookup) and put the values into color and size grid fields? I need a detailed step for this, or if you can give me reference tutorial about this, or ax default class sample code with same scenario thanks.

2

Hi Nisha, welcome do Dynamics User Group forum. Please never forget to attach a tag with your AX version, there are significant differences between versions and therefore it’s crucial to know which version we’re talking about.

First of all, thing twice whether you really should copy the fields. Maybe you should use a reference to the original record instead of duplicating all the data. It depends on your business requirement, which you unfortunately didn’t mention.

I’m not going to open any discussion about implementation details until I know your AX version.

3

Hi Martin,

Done [Y]

Okay, about my business requirement, i’m not really have a requirement for this, it’s just a testing (my testing, i made scenario in my head) let’s just say that i’m new in AX so i need to explore here and there, so far i have learn how to make an auto lookup from table, and also lookup by override lookup() of a field’s method. Now i have this idea how to get the value & add it into other field, but i have no resource for this i’m totally blank- no clue about this.

4

You have to choose one of two scenarios.

Either you add a reference to the selected record and merely display those three fields. AX 2012 has a great support for this kind of things; you don’t have to write any code for that.

Or you want to duplicate all three fields in the target table. It’s what you usually shouldn’t do, but it may be needed if you want to capture the current state of the source table, which may change later. Nevertheless you can also solve this problem with date-effective data without creating extra fields in your table.

5

I don’t need to capture the current state, so let’s go with first scenario with reference… Would you be so kind to explain this scenario?

6

One of possible ways is storing surrogate keys in your table and display the three fields through a replacement field group.

If you need more details, please give me more information about the referenced table.

7

Hi Martin,

Sorry for late reply, i’m trying here and there to break this problem but still have no right solution. So, discussing your reply :

“storing surrogate keys in your table” : is what you mean for me to create relationship to other table, so their surrogate keys available in my table?

" display the three fields" : is what you mean for me to create display method in my table level for each my fields?

“through a replacement field group.” : i don’t understand about this.

8

Did you follow the link and read read my article ? Using the example in from my article, the product table uses a surrogate key (RecId) and that’s what InventTable refers to in its Product field.

How to use the replacement group is explained in the article, so I’m not going to repeat it here. If needed, tell me which part of the article you don’t understand.

You’ll also find details in documentation, such as Table Keys: Surrogate, Alternate, Replacement, Primary, and Foreign and Surrogate Keys.

9

Martin,

I have read your link (just now), i’ve tried it and drag it into design node, then it became a reference group. Now, what should i do next to get the value from the lookup i have select and put it into “each” fields? With display method in table level?

10

If you’re trying to add more physical fields into your table, you still don’t understand how to design your requirement.

You said you wanted to use a reference. Therefore the correct design is to refer to a unique key of the other table (such as RecId). Adding any more fields would violate your requirement and rules for designing detabase schema.

You don’t want to show the key (RecId), of course, therefore you’ll join tables together and display any field you like. Replacement groups will do this work for you. If you want to see three fields, simply use a replacement group with three fields.