Miscellaneous Technology

There are several instances where you will be required to extend the standard FNDLOAD processing. This allows you to implement new data centric logic. Let us take a simple example. You might have descriptive flexfields on lets say FND_LOOKUP_VALUES table, and the descriptive flexfield Attribute1 might be attached to a table validated value set. Therefore the table will contain entries as

Due to the table validated value set, the value 1021 equates to service request type = "Missing Equipment". Likewise,  value 1023 could equate to request type = "Warranty Expired"

In case you use the standard lct file to download the lookup codes, then there the Attribute1 value will be loaded into destination environment with their original id's. However, in the destination system a value of 1023 might equate to service request type="Missing Paperwork". To overcome this problem, you can extend the lct file $FND_TOP/patch/115/import/afffload.lct

The steps are

1. Make a copy of $FND_TOP/patch/115/import/afffload.lct to XX_LOOKUP_SR_TYPE.lct
2. Modify XX_LOOKUP_SR_TYPE.lct
This is done at three places
    a. Register the custom fields that can be referenced in the download/upload section of lct file
    b. Modify the DOWNLOAD section, so that values like  "Missing Equipment" and "Warranty Expired" are extracted within the ldt file itself
    c. Modify the upload section to convert the text values back to the id's. The UPLOAD is of course executed in the destination environment.

These steps are detailed as per the three figures below

Anil Passi

Add comment