Custom.pll in Oracle Application

Custom.pll in Oracle Application

Custom Library (custom.pll) allows to extend/customize Oracle Applications form(Oracle Form) without changing or modifying Oracle Applications code. Examples may include enforcing a new business rule, opening a form using zoom etc. Most of the things that we can do using custom.pll, we can achieve that using Forms Personalization. Since Custom.pll takes the full advantage of PL/SQL so it is having an edge over Forms Personalization for complex customizations.
CUSTOM.pll is used to add extensions to Oracle’s form Functionality. Some of the common scenarios where CUSTOM.pll can be used are:-
1. Enabling/Disabling the fields
2. Changing the List of Values in a LOV field at runtime
3. Defaulting values
4. Additional record level validations
5. Navigation to other screens
6. Enabling Special Menu
Where is this located?
Custom.pll is located in $AU_TOP/resource Directory.
How to add code to this?
Open this pll using the Form builder and make changes to the program units.
How to compile this PLL?
 Once you make changes you need to compile the pll. Use the F60gen to compile it
f60gen module=custom.pll userid=APPS/ output_file=$AU_TOP/resource/custom.plx module_type=library batch=no compile_all=special
While writing code inside custom.pll we should consider following things:
1. We should not run any SQL statement inside this, we can use record group.
2. We should not perform any DML operations, instead we should call database procedure and functions for the same.
For following Events call will go to CUSTOM Library:
 
WHEN–FORM–NAVIGATE
WHEN–NEW–FORM–INSTANCE
WHEN–NEW–BLOCK–INSTANCE
WHEN–NEW–RECORD–INSTANCE
WHEN–NEW–ITEM–INSTANCE
WHEN–VALIDATE–RECORD
SPECIALn (where n is a number between 1 and 45)
ZOOM
EXPORT
KEY–Fn (where n is a number between 1-8)
Custom Library contains Custom Package which is having two Functions and one procedure.
1] ZOOM_AVAILABLE:
This function allows you to specify if zooms exist for the current context. If zooms are available for this block, then return TRUE else return FALSE. This routine is called on a per-block basis within every Applications form from the WHEN-NEW-BLOCK-INSTANCE trigger. Therefore, any code that will enable Zoom must test the current form and block from which the call is being made. By default this routine must return FALSE.

view sourceprint?




01
Sample code1:




02
 




03
function zoom_available return Boolean is




04
 




05
    form_name  varchar2(30) := name_in('system.current_form');




06
    block_name varchar2(30) := name_in('system.cursor_block');




07
 




08
begin




09
 




10
    if (form_name = 'DEMXXEOR' and block_name = 'ORDERS') then




11
      return TRUE;




12
    else




13
      return FALSE;




14
    end if;




15
 




16
end zoom_available;




17
 




18
Sample code2:




19
 




20
function zoom_available return Boolean is




21
 




22
    form_name  varchar2(30) := name_in('system.current_form');




23
    block_name varchar2(30) := name_in('system.cursor_block');




24
 




25
begin




26
 




27
   if (form_name = 'APXINWKB' and block_name = 'INV_SUM_FOLDER')




28
     then




29
      return TRUE;




30
    elsif (form_name = 'APXINWKB' and block_name = 'LINE_SUM_FOLDER')




31
     then




32
      return TRUE;




33
    else




34
      return FALSE;




35
    end if;




36
 




37
end zoom_available;

2] STYLE:
This function returns a integer value. This function allows to override the execution style of Product specific events, but it doesn’t effect generic events like when-new-form-instance. Possible return values are:
1. custom.before
2. custom.after
3. custom.override
4. custom.standard
By default it returns custom.standard.

view sourceprint?




1
Sample code:




2
function custom.style(event_name varchar2) return integer is




3
begin




4
     if event_name = ’MY_CUSTOM_EVENT’ then




5
     return custom.override;




6
     else




7
     return custom.standard;




8
     end if;




9
end style;

3] EVENT: 
This procedure allows you to execute your code at specific events including:
  –    ZOOM
  –    WHEN-NEW-FORM-INSTANCE
  –    WHEN-NEW-BLOCK-INSTANCE
  –    WHEN-NEW-RECORD-INSTANCE
  –    WHEN-NEW-ITEM-INSTANCE
  –    WHEN-VALIDATE-RECORD
By default this routine must perform ‘null;’

view sourceprint?




01
Sample code:




02
procedure event(event_name varchar2) is




03
 




04
form_name varchar2(30) := name_in(’system.current_form’);




05
block_name varchar2(30) := name_in(’system.cursor_block’);




06
 




07
begin




08
 




09
     if (form_name = 'XXBI' and block_name = 'xxcc') Then




10
        if(event_name = 'WHEN-NEW-FORM-INSTNACE')




11
           --Write your code here




12
     elsif(event_name = 'WHEN-VALIDATE-RECORD')THEN




13
           --Write your code here




14
     else




15
          null




16
       end if;




17
     end if;




18
end;

How to make the changes get affected?

Once you make all the necessary changes, compile the pll and generate the PLX file. Since the CUSTOM library is loaded once for a given session, a user must log out of the application and sign-on again before any changes will become apparent.
Forms Personalization: an alternative of custom.pll
In older versions, prior to 11i, Custom.PLL was most prominently used for adding additional features in the seeded form but the latest version of Oracle EBS comes with the feature called as Forms Personalization which allows even an end user to alter the seeded forms functionality using an user interface called the Personalization form.
Advantages of Forms Personalization over Custom.PLL:

• Forms personalization can be used by an user with limited PL/SQL knowledge. 
• Changes take place immediately on reopening the form.
• Anything which can be done using Custom.PLL can be done using Forms Personalization also.
• Personalizations are stored in base tables related to Form Personalization.
• CUSTOM.pll is a single file/entity, hence only one developer can make changes to CUSTOM.pll at any given point in time. This is not a restriction in Forms personalization.
• Easy to disable/enable with click of a button.
• Can be moved easily through FNDLOAD from one instance to other.
• Can be restricted at site/responsibility/user level.
• Personalization stores who columns with which we have the ability to track who created/modified it where as in CUSTOM.PLL we don’t have that ability.

Filed under AOL, Architecture Tagged with CUSTOM Library, Custom.pll, Forms Personalization, Oracle Apps, Oracle Forms, ZOOM_AVAILABLE

MULTI ORG in Oracle Application

September 11, 2010 1 Comment

MULTI ORG in Oracle Application

The ability to define multiple organizations and the relationships among them within a single installation of Oracle Applications is called multi organization or Multi-org. Multi Org is the future used to store the data of multiple organizations in a single Database instance.
Basic Business Needs:

• Use a single installation of any Oracle Applications product to support any number of organizations, even if those organizations use different sets of books.
• Define different organization models.
• Support any number of legal entities within a single installation of Oracle Applications.
• Secure access to data so that users can access only the information that is relevant to them.
• Sell products from a legal entity that uses one set of books and ship them from another legal entity using a different set of books, and automatically record the appropriate intercompany sales by posting intercompany accounts payable and accounts receivable invoices.
• Purchase products through one legal entity and receive them in another legal entity.

Basically the different entities in multi-org are:

• Business Group (BG)
• Sets of Books (SOB)
• Legal entities (LE)
• Operating units (OU)
• Inventory organizations (IO)

Organization Structure Example:

Business Group (BG):
The business group represents the highest level in the organization structure, such as the consolidated enterprise, a major division, or an Operation Company. A BG is used to secure human resources information like generation of employee numbers, generation of applicants, position flex fields, Job flexfields, Grade Flex field, Fiscal year, etc.
Set of Books (SOB):
A SOB is a collection of Currency, Calendar and Chart of Accounts (COA). Oracle General Ledger is used to secure Journal transactions (such as journal entries and balances) of a company by set of books. For each organization of the Business Group we need to define a set of Book. A company which operates in separate cities or separate line of businesses may separate their accounting transactions across units through separate Set of Books. A Business Group can have one or more set of Books.
Legal entities (LE):
A legal entity represents a legal company for which you prepare fiscal or tax reports. You assign tax identifiers and other legal entity information to these types of organizations. Separate Legal Entities may share same set of Books.

Operation Unit (OU):
An operating unit is a division or a Business unit of the legal entity. At this level we are going to maintain the information of sub‐ledgers. We are going to maintain the ledgers at Legal Entity level. Receivable, Payables, Assets, etc. are comes under Operation Unit level. Each user sees information only for their operating unit. Responsibilities are linked to a specific operating unit by the MO: Operating Unit profile option.

Inventory organizations (IO):
An inventory organization represents an organization for which you track inventory transactions and balances, and manufactures or distributes products. Examples include manufacturing plants, warehouses, distribution centers, and sales offices. The following products and functions secure information by inventory organization: Inventory, Bills of Material, Engineering, Work in Process, Master Scheduling/MRP, Capacity, and purchasing receiving functions. To run any of these products or functions, you must choose an organization that is classified as an inventory organization.

Filed under Architecture Tagged with Business Group, Inventory organizations, Legal entities, MULTI ORG, Operating units, Oracle Apps, Sets of Books

Oracle Application Directory Structure

September 5, 2010 Leave a comment

Oracle Application Directory Structure

Oracle Application has a file system as shown in the below picture for the APPL_TOP Directory.

GL_TOP: (APPL_TOP/GL/11.5.0) is one of the Module Directory of Oracle Applications. It consists of a release directory (i.e. 11.5.0) under which Forms, Reports, BIN, LIB, SQL, etc.,
Forms/US: Forms directory to store all .FMX (Compiled) Form files of a specific module.
Reports/US: Reports directory to capture all the .RDF (Compiled) Report files of a specific module directory. US is a language specific directory.
BIN: Contains executable code of concurrent programs written in a programming language such as C, Pro*C, Fortran, SQL *LOADER or an operating system script.
LIB: Contains compiled object code (.OBJ files) of your concurrent programs.
SQL: Contains concurrent programs written in SQL*Plus and PL/SQL scripts.
HTML: Contains all .HTML, .HTM web files.
LOG: Contains all .LOG files of concurrent programs.
OUT: Contains output files from concurrent program.
Message: Holds your application message files for Message dictionary.