FNDLOAD – The Generic Loader

Start Here

Get in touch with a
TriCore Solutions specialist

Blog | Apr 1, 2016

FNDLOAD – The Generic Loader

FNDLOAD is an Oracle utility that allows for the transfer of a wide range of Oracle Foundation (FND) data from one instance to the other.



The migration of Oracle application setup data from one instance to another is very time consuming and sometimes error prone too. In order to migrate setup data from one instance to the other, oracle generic loader FNDLOAD is used. It can download data from an application entity into an editable text file, which can be uploaded to another database. Conversion between database format and text file format is specified by a configuration file.

What is FNDLOAD?

As stated above FNDLOAD is an Oracle utility that allows for the transfer of a wide range of Oracle Foundation (FND) data from one instance to the other. The loader reads a configuration file (LCT) to determine what data to access. It works by downloading the data in the source instance into a text file (LDT file) that can then be uploaded into target instances. FNDLOAD ensures consistent migration of the objects within Oracle Applications.

Image reference:

The acronym ‘LDT’ stands for Loader data files and ‘LCT’ for Loader configuration files. 

The LCT files are located in the directory $FND_TOP/patch/115/import. The configuration files are delivered and maintained by Oracle. It has entity definitions, parent-child relationships and user input parameters. Downloading a parent automatically downloads all children. Oracle neither support the custom configuration files nor recommend to edit the seed configuration files provided. 

FNDLOAD is used frequently in migrating customization, configuration data, FND Messages , Lookups , Concurrent Programs , Profile Options , Request Groups, Menus, EBS User, EBS Responsibility, Value Sets, Form Functions, Alerts, Descriptive Flex fields (DFF) and other objects across the instances. We have different configuration files available for different types of objects- see table below.

Object Type

Config file Name (lct)

FND Messages




Concurrent Programs


Profile Options


Request Groups




EBS User


EBS Responsibility


Value Sets


Form Functions




Descriptive Flexfields (DFF)


Request Set


Data Definition and Template


Printer Styles


Request Group


Syntax - To use FNDLOAD, the following syntax is required-

FNDLOAD apps/appspwd 0 Y mode configfile datafile entity [parameter1.....]

apps/appspwd is the apps user and password for the apps schema for the instance.

The values 0 and Y are flags for FND Executable like FNDCPASS and FNDLOAD.

  • 0 is request id (request ID 0 is assigned to request ID's which are not submitted via Submit Concurrent Request Form.
  • 'Y' indicates the method of invocation. i.e. it is directly invoked from the command-line not from the Submit Request Form.
  • The mode is either DOWNLOAD or UPLOAD.
  • The configfile is the LCT file that FNDLOAD needs to download and upload the metadata.
  • The data file is the output file, in which the downloaded data is written by the FNDLOAD.
  • The entity is the entity you want to download.

    Some examples of running FNDLAOD complete command- 

    1. For Concurrent program migration from one instance to another-


    FNDLOAD apps/apps_password 0 Y DOWNLOAD $FND_TOP/patch/115/import/afcpprog.lct XXX_CUSTOM.ldt PROGRAM APPLICATION_SHORT_NAME="application_short_name" CONCURRENT_PROGRAM_NAME="Prog_Short_Name" 


    FNDLOAD apps/apps_password 0 Y UPLOAD $FND_TOP/patch/115/import/afcpprog.lct XXX_CUSTOM.ldt UPLOAD_MODE=REPLACE CUSTOM_MODE=FORCE 

    2. For Responsibility migration from one instance to another-


    FNDLOAD apps/apps_password 0 Y DOWNLOAD $FND_TOP/patch/115/import/afscursp.lct XXX_CUSTOM_RESP.ldt FND_RESPONSIBILITY RESP_KEY="Resp_Key" 


    FNDLOAD apps/apps_password 0 Y UPLOAD $FND_TOP/patch/115/import/afscursp.lct XXX_CUSTOM_RESP.ldt UPLOAD_MODE=REPLACE CUSTOM_MODE=FORCE 

    3. For Menu migration from one instance to another-


    FNDLOAD apps/apps_password 0 Y DOWNLOAD $FND_TOP/patch/115/import/afsload.lct XXX_CUSTOM_MENU.ldt MENU MENU_NAME="Menu_Name" APPLICATION_SHORT_NAME="App_short_name" 


    FNDLOAD apps/apps_password 0 Y UPLOAD $FND_TOP/patch/115/import/afsload.lct XXX_CUSTOM_MENU.ldt UPLOAD_MODE=REPLACE CUSTOM_MODE=FORCE 

    NB: Using UPLOAD_MODE=REPLACE and CUSTOM_MODE=FORCE is usually used when replacing rather than creating. It can be omitted if it is the first time that the objects are being loaded. There onwards, to replace the objects you would have to use UPLOAD_MODE=REPLACE CUSTOM_MODE=FORCE. For every FNDLOAD command ran, there is a log file generated with details of the outcome. 

    Conclusion: As it can be seen from the information shared in this blog, FNDLOAD utility offers great flexibility for migrating oracle applications data across the instances. I would like to conclude this blog by highlighting some of the major advantages and disadvantages. 

    Advantages -

    • Fully supported and recommended by Oracle.
    • AOL data migration process is now simplified.
    • No technical skill is required to run the loader.
    • It’s a tedious task to maintain environments at different level of setups configurations. This can be easily done with loader. We can transfer the setup data incrementally as required, this will help us debugging the issues and a better control over instance.


    • FNDLOAD allows for the download of individual entity instances or groups of entity instances. For example, all responsibilities could be downloaded within a specified application. However, this creates a serious risk of uploading bad data from development into production. For this reason, we download only specified individual entity instances that are assumed to have been fully tested in development.
    • No validations against migrating database sensitive data.

For more questions on the topic click below:

Ask Harish