Let's say we have an AIF inbound port for importing Sales order requisition from a partner, and we need to add a new field to import Contact person.
In standard we can easily import Contact person by its ID. However, it is not probable that your partner uses the same internal IDs for contacts as you do.
On the other hand, there is no standard mapping feature for contact persons via external codes, like those we have for items, customers, vendors and some other artifacts.
So, our goal is to find a way to map an internal contact person ID to a given name. Something similar to what we do by selecting a contact from the drop-down list in Sales order, which is actually an Edit-method.
Basically we will touch two classes only.
First, we add a new parm method to SalesSalesOrder_SalesTable class, which exposes data through SalesSalesOrderService. In other words, this new parameter will be available in the fields of Data policy (document scheme). Also the exist method must be added to the same class.
Then we implement the logic in AxSalesTable class, which finds contact id based on the name provided in the aforementioned parameter.
We place the new method before standard setting Contact person id because the latter will use Contact person id, if it is already found.
Compile and compile incremental CIL.
Next step is to refresh service via Register menu.
We have paved the new way: AIF will search for Contact person based on an imported Person name.
In standard we can easily import Contact person by its ID. However, it is not probable that your partner uses the same internal IDs for contacts as you do.
On the other hand, there is no standard mapping feature for contact persons via external codes, like those we have for items, customers, vendors and some other artifacts.
So, our goal is to find a way to map an internal contact person ID to a given name. Something similar to what we do by selecting a contact from the drop-down list in Sales order, which is actually an Edit-method.
Basically we will touch two classes only.
First, we add a new parm method to SalesSalesOrder_SalesTable class, which exposes data through SalesSalesOrderService. In other words, this new parameter will be available in the fields of Data policy (document scheme). Also the exist method must be added to the same class.
Then we implement the logic in AxSalesTable class, which finds contact id based on the name provided in the aforementioned parameter.
We place the new method before standard setting Contact person id because the latter will use Contact person id, if it is already found.
Compile and compile incremental CIL.
Next step is to refresh service via Register menu.
We have paved the new way: AIF will search for Contact person based on an imported Person name.
2 comments:
You could also run the AXD wizard again and not do any coding... That is like 5-8 clicks I believe. But it is good to know what is under the hood. Nice post. Thanks.
In fact this is kind a "virtual" field that does not actually exist in the table. So I doubt if the wizard could generate it automatically.
Post a Comment