Do's

What Start-Up
1 Coding standards docs to be prepared and finalized immediately after the startup of the project 2 Follow Customisation Standards from Oracle Application Developer Guide for any customisation 3 Coding standard doc need to signed off from client before actual coding starts Do cost/benefit analysis of all the options for customization before going ahead with anyone. 6 The design docs needs to be freezed and signed off by client before starting the development.Any further modifications should be taken through Change control. Any Change during the development should be properly reflected in the design Docs. 9 Test environment should be setup with all relevant data before actual startup of the project. 10 If the developer is not sure from which form/table/application he should pick the information asked in design doc he should contact the client/func user to show him the navigation path/screenshot from where he can see the info 11 All the deliverables should be under proper version control

Why
So that all the deliverables follow the same conding standards These standards are prescribed by Oracle to ensure that your customisations are compatible with Oracle Applications and does not alter any standard functionality and also works successfully Need to bring client into confidence about the quality procedures practised As any gap may have a no of solutions, so have a look at different options from development/maintenance/User usability effort perspective. This is to ensure that we deliver the code as per design docs.

This is required from maintenace perspective to have consistency across development deliverables. Many a times we deliver incorrect code as the code could not be tested properly due to lack of test data As a technical expert/developer he should not ask the client from which table he would get the info and at the same time it is not expected a technical consultant to know the functionality of the module. So he can follow this approach to get to know the screen and in turn query that screen to get the base table/view. As in any project this is needed Many a times Customizations are asked for, since the users are not aware of complete Functionality within Oracle Applications across modules. Each Customisation request needs to be validated against standard functionality. We need to see whether same objective can be achieved through profiles, configurations or setups

Generic
12 Explore Standard Functionality before deciding on any customization

All Customization requirements should be priotized based on whether they are nice to have or must have. 13 Check the Entire cycle from start to finishin case of any major process customization. 14 Check all the different scenarios that may be impacted by the customization. E.g. for changing anything related to the invoicing process you should consider all the types of invoice. 15 Keep future requirements in consideration 16 Plan cross team coordination where customisation is dependent on other teams' work

To understand any Impacts in other modules/ areas To ensure that no particular situation is missed out

17 Consider Multi Org criteria while Developing customisations 18 Do not consider invasive customization 19 Consider performance/maintenance issues before start of the development

To reduce impact on future business requirements No of times a customisation involves cross team involvement like one team is working on building interface using integration tool like WebMethods and fetching required data where other team works on customisation part to enhance Oracle Applications Functionality using data fetched by WebMethods like tool. In this scenario it becomes imperative to have close coordination among teams so that any change in one team's design is communicated to other team well in advance and other team can factor in its impact and modify their design in time. Also for installation and migration activities this is very very important Can be used by different operating units Any invasive customization should be avoided. It is better to have business process change in that case. In many cases the customizations are not effective as due consideration to performance has not been given during design.

20 Use Custom Applications to register forms, functions, Oracle Application Patches change standard AOL objects a no of executables, concurrent programs, report sets, responsibilites, times. In order to preserve your customisations it is imperative to use menus Custom Applications so that any patch does not affect your AOL setups for Customisations 21 Errors should be handled in such a way that it can be rectified To reduce back end updates from the front end Put userfriendly message in the error log. E.g. instead of User should be able to appreciate the issue from the error log. putting inventory item id or organization id in the error log , put the part no, organization name which can be easily understood. Even if the solution requires more effort, still always go for Updating of the standard apps table may corrupt the data as there using the standard API for updating standard apps table. E.g. may be different front end validations that will not be taken care of. rather than updating hold information in the order table directly, Standard API will take care of the same. it is better to populate the information from order table to order interface table and then agian updating the order table by running the the order import api in an update mode after changing the hold information there.. Requirement for insertion of data in apps tables in absence of The custom data should be stored separately in a custom table. The APIs should be handled carefully by using a custom data in apps tables should be updated only after ensuring that the intermediary table to store the custom data and by doing the original data in apps tables can be retrieved back easily. Any possible required validation there. validation should be done at the custom table. Create a Custom Oracle Id to register new custom objects Oracle Apps Customization standard for easy code maintenance/preventing any accidental change of Standard apps 31 objects. Create index in cases where many queries will be able to use It improves performance the same and the table is not frequently updated/inserted. Choss the right type of index based on the data diversity.

Interfaces
Inerting data directly into base tables is not supported by oracle and also, APIs are already designed to do all validations. Custom programs might not do it completely due to process mapping / design 22 oversight Always use a staging table when pulling in data from external If data is inserted directly into the APPS open interface table, the source to an APPS open interface APPS Open interface will validate the data in the open inteface table while trying to import it, but it won't give you any "customized" error msgs. It might become a major activity to figure out these errors. It is better to have staging table and do all possible validations there by a custom code before the code inserts the data into APPS open inetrface table. Also, any other validation as per the specific project 23 requirement can be taken care of at that stage. All codes should have proper exception handling and reporting All custom codes should have proper exception handling. At the same time, every exception should be captured and written into a log, preferably along with some key data being processed at that time. 24 Proper message segregation should be done between the log out put and the error log while putting comments in the concurrent program. All custom concurrent programs should write important While figuring out the cause of an exception or an unexpected output, activities and key data into logs it is a great help if there is a trail of activity created by the code. 25 Use AUTHID current_user clause in the custom package This eliminates the requirement of creation of synonyms and giving declaration. grants to standard apps objects to the custom schema as per the requirement of the custom package. Always use Oracle APIs when creating/updating any record in APPS base tables.

Forms
New Form Customisation - Modular Approach While creating a new custom form, it is advisable to create a new Libaray to store all common custom programs, triggers etc so that same code can be called a no of times in different form triggers and also code remains easily maintainable. Even it this code is in form level triggers it will not work as expected.

26

Standard Forms Customisation

It is not advisable to customise any standard oracle applications form. Instead one should try to achieve the same by either excluding certain functions available to responsibility or by changing the custom.pll 1) It allows extension of Oracle Applications without modification of Oracle Applications code 2) It that allows you to take full advantage of all of the capabilities of the Developer 2000 suite of products and integrate your code directly with Oracle Applications 3) In basic terms, the CUSTOM library lets you change properties, functionality and operation of a form as if you were actually changing the source code of the form. Executable should be compatible with server-end version As advised by Oracle To avoid upgrade overwrite Oracle Apps Customization standard for easy code maintenance Code must be maintainable Code must be maintainable Code must be Readable Use reusable and shared objects In many cases, the requirement of folder form is established towards the end of development cycle, based on the no of columns requirement. This requires almost a redevelopment of the form. Coding for better performance

27 Always try to use custom.pll/ Apps personalization for forms code customization

28 29 Always do a server-side compilation of forms/plls In Custom PLL Use FNDSQF library for function security, flex 30 fields and message procedures Do not use standard OA prefix like "INV_" in custom database 32 objects Create a Custom Directory Structure to register custom source 33 codes Write Code in discrete packaged procedures, known as 34 Handlers Follow naming conventions for objects, package and 35 procedures Use proper indentation in your code 36 Put comments in your code wherever possible 37 Template form is the starting point for building a form Always evaluate the requirement of a folder form or a canvas based form at the begining of the development.

38 39 40 41 42 43 44

Create base table blocks on views Use data base stored procedure when extensive SQL is required Code all non-SQL logic on the client side wherever possible. Code should be platform independent Keep number of procedures in a package < 25 Specify field names along with their block name Use object id: U_id := find_item ('block.item'); Use FND_MESSAGE to display any message Use raise form_trigger_failure to stop processing on the client

As advised by Oracle Coding standard Coding standard Coding standard Coding standard Coding standard Coding standard Coding standard Coding standard

Use app_exception.raise_exception to stop processing on the 45 Server Replace EXIT_FORM to do_key('EXIT_FORM') after copying 46 'Y' to :GLOBAL.APPCORE_EXIT_FLAG Use APP_ITEM_PROPERTY.SET_PROPERTY, APP_ITEM_PROPERTY.GET_PROPERTY, APP_ITEM_PROPERTY.SET_VISUAL_ATTRIBUTE to get 47 Oracle Applications behavior. Use FND_FUNCTION.EXECUTION instead of OPEN_FORM 48 for security purpose 49 Use do_key('COMMIT') in place of COMMIT 50 Use do_key('CLEAR_FORM') in place of CLEAR_FORM Use do_key('edit_field') in place of EDIT_FIELD/EDIT_TEXTITEM, so that calendar is raised if the 51 current item is a date. Use AK flow pages to create custom self service web pages 52 If some additional functionality is needed on a seeded form, doing it thru the use of CUSTOM.pll is preferred, rather than 53 copying the form & then modifying & registering the copy.

Coding standard Coding standard Coding standard Coding standard

Easy to maintain during upgrade, less technical skill is required, look & feel is same as Oracle Apps Lower maintenance & higher consistency. In addition, the form thus "modified" thru the use of CUSTOM.pll calls is very much supported by Oracle.

Use of Folders in Form Customisation 54 Query Only Forms

55 If additional columns (on top of what APPS already provides) are needed to store certain business data, use DFFs 56 Plan the usage of any Descriptive Flexfields 57 Keep a single register of all the DFF attributes used. If there is a need to use database triggers (one inventory txn record kicking off notifications, for example), use Oracle alerts. 58 Be cautious about using too many alerts 59

Sometimes it is not possible to fit all fields in a form in single screen or form canvas, it is advisable to use folder option. This option gives easy navigation to user. Oracle Applications allows to define a function with parameter QUERY_ONLY = Yes. This Function allows read only access of form to user. Developer do not need to change form in any way to achieve this functionality DFFs have been provided to "customize" your tables to certain extent. Not all tables in the APPS db have this feature, but most of the critical ones do. There are limitations but most business requirements can be met. It is supported by Oracle. No. of DFFs on any Oracle Applications Table are limited. Hence Developer needs to use them very conservatively. To avoid usage of same DFF attribute for different purpose in different enhancements. Alrets has been provided by Oracle to write triggers on tables.

Every alert slows down the system. Do not use alert on transaction tables which will cause the alert trigger to fire frequently.

Workflows
Workflow Customisation Approach For any workflow customisation, developer should copy standard process with some other relevant name and customise it. One should never change standard process as it removes any fallback on standard functionality in case customisation does not work. Also original file needs to be kept as separate object in version control tool

60

Reports
Use this example istead of truncating a date column in where clause of sql query. Example WHERE creation_date between to_date('10-JAN61 1950') and (to_date('10-JAN-1950') + .99999) Use fnd_profile or fnd_global utility to get various values required in concurrent program instead of hard coding. Prefer using a non displayable parameter for any hardcoded value used by the program and set the the value as default to the parameter. You can also use lookups to define various values 62 Obtaining the Concurrent Request Id from within Reports Define a user parameter called P_CONC_REQUEST_ID. The parameter is be called as P_CONC_REQUEST_ID. In the After Paramete form trigger in the report, have the following code srw.user_exit('FND SRWINIT'); This user exit will populate p_conc_request_id with concurrent request id. In the After Report trigger, have the following code: 63 srw.user_exit('FND SRWEXIT'); While registering a new concurrent program / report, use 64 existing, seeded, value sets where possible. Use Request Sets to execute series of related sequential 65 requests Use Shared Parameters for parameter values that should 66 repeat in requests in a report set 67 Ensure Page protection for records 68 Ensure proper anchoring of frames & fields 69 Define correct print styles while registering reports Use attachment files (e.g. tif file) for Faxmail type reports' 70 header & trailer pages Increases the performance of the query if any index exists for the column creation_date

You can chage the parameter default value in future without changing the program code

Using fnd_global.conc_request_id will return null value

Lower maintenance & higher consistency. Linking logic between the sequences can be established User inputs will be less To prevent data inconsistency in reports This will prevent unintended data overlaps This will prevent unintended data loss in O/P & wrapup of data Reusablity of the same attachment file for multiple similar reports from same business/module, less coding in the rdf file

While making enhancements to an existing report with nonEnglish characters (German, Japanese etc), make sure that 71 you have the font installed in your PC For all summary columns ensure that reset level is correct by 72 thorough testing 73 For ftping reports to database server, use binary mode

Otherwise all non-english data will become corrupt upon savoing the report. To avoid incorrect totals/subtotals Otherwise the rdf gets corruprted

Delivering the Components

74 The structure and components in design docs,installation docs need to be finalizedso that all the deliverables follow be asame standard. We can attach a This is necessary and signoff from the client. May the sample design/installation doc Detailed Documentation for Installation & Migration of Each Customisation is unique in terms of functionality it affects, Customisations components it involves and migration requirements. In order to reduce dependancy on availability of instances or migration tools and to reduce risk of losing any setups, configurations we need to document each installation and migration step. We also need to maintain a traceability matrix for each customisation in terms of which components it involves, which APPL_TOP they need to be and so on 75 The functional doc should have the test cases component filled To ensure that the code is tested with expected data. up while the developer has to ensure that he fill up the test 76 results before delivery of the code 77 Should have IQA/EQA before actual delivery of the code. To delivery code first time right.

Reusability

78 For conversion projects, the team should prepare a mapping doc.If some remove the re-work onhave done, E.g. same10.7 be 11i upgradationthe projects This will other projects already the same. the from can to shared across have alread

Mandatory / Optional Mandatory Mandatory

Mandatory Mandatory

Mandatory

Mandatory Mandatory Optional

Mandatory Mandatory

Mandory Mandatory

Mandatory Mandatory

Optional Mandatory Mandatory

Mandatory

Mandatory Mandatory

Mandatory

Optional

Mandatory

Mandatory

Mandatory

Optional

Optional

Mandatory

Mandatory

Mandatory

Mandatory Mandatory Mandatory Optional Optional Optional Optional Optional

Optional

Mandatory Optional Optional Optional Optional Optional Optional Optional Optional

Optional Optional Optional Optional

Optional Optional

Mandatory

Mandatory

Optional

Optional Optional Optional

Optional

Mandatory

Optional

Optional

Mandatory

Optional Optional Optional Optional Optional Optional Optional

Optional

Optional Mandatory Mandatory Mandatory

Mandatory

Mandatory Mandatory

Don'ts
What
1 Prevent commiting to client without requirement analysis & exhaustive feasibility study Do cost/benefit analysis of all the options for customization before going ahead with anyone. 2 Design docs once freezed should not be changed to incorporate last minute changes. 3 Do not try to direclty insert/update records in Oracle Applications Tables

Why
To ensure on-time & first time right delivery As any gap may have a no of solutions, so have a look at different options from development/maintenance effort perspective. So that code is delivered on time

5 6

7 8 9

10

11 12

13

14

Many times oracle provides Interface tables to import data from external sources into Oracle Applications. The benefit of using Interfac e Tables are that before this data gets imported into Oracle Applications Table, it goes through validation by standard Import Programs and hence ensure data integrity. Do not change seeded Oracle Application Packages unless Changing any seeded Oracle Apps Package can alter standard advised by Oracle Support functionality. It is also a high maintainence customisation since when any patch is applied, DBA team needs to revert Oracle Apps Package to its Original State before Customisation and after patch is applied, Developer again needs to make required changes Do not ever Drop any standard database object The entire system may become corrupt For customizations using standard import APIs, do not commit Cannot modify standard APIs to include such features - try to work out directly including features that are not supported by that an optimum solution standard import process Prevent using custom API's to load data into OA production To keep standard functionality unchanged tables, use Oracle's standard Open interface routines Do not add or remove fields in any standard form as a part of Changing standard forms NOT recommended by Oracle customization -- try using CUSTOM.pll & DFFs instead In forms/reports customization we should not write any code Oracle Apps works across multiple platforms which are Microsoft based. E.g OLE/ACTIVEX/MOUSEMOVE,WINDOW-CLOSED etc As a part of Customization, custom objects should not be Not recommended by Oracle. created in Apps or other standard Application schemas. Shouls create custom objects in custom schemas and create public synonyms for these objects Avoid coding of database triggers on Standard tables of Apps Not recommended by Apps. See if you can use the CUSTOM.pll as far as possible instead Do not change seeded workflow where Oracle does not Workflow is an integral part of Oracle Applications Functionality and recommend customisation. This is evident in customisation affects multiple modules. In many cases, functionality is so integrated access level on each workflow objects with other modules that any customisation will severly affect standard Oracle Applications Functionality and hence Oracle does not recommend any customisation on them Deletion of objects in customised workflows Whenever any customised workflow is being modified and some objects are getting deleted, user must first connect to database before doing so. Otherwise there is discrepancy between workflow definition and workflow database tables and this does not allow new definition to be saved successfully While writing custom functions for workflows, dont do any W/f engine writes selective pieces of control data & flags into W/f commit in your code. tables while executing a W/f function. Your commit in the same session MIGHT commit some data into w/f tables which W/f engine had no intention to commit !!! This can cause severe status problems in that W/f - in fact it might simply get into an invalid status & error out.

15 Do not use SQL in the CUSTOM library, (call server side Easy to maintain and OA standard packages instead, or use a record group to issue the SQL for you) 16 Do not change the specification of the CUSTOM package As advised by Oracle 17 Do not attach the APPCORE library to the CUSTOM library because CUSTOM is attached to APPCORE For example, function APP_ITEM_PROPERTY is not available within the CUSTOM library. You should use Oracle Forms SET_ITEM_PROPERTY instead

18 Do not use CALL_FORM or OPEN_FORM within the CUSTOM library, use FND_FUNCTION package instead 19 Do not create triggers on ALR_ALERT 20 Do not insert rows into FND_DUALs Do not create index on the interface table unless really 21 required. Do not create triggers on standard transaction tables Do not go for many customizations in the same process cycle unless really required. Avoid creation of alert on transaction tables unless really needed. Prefer database triggers to the creation of alerts in cases, where the operation can be more selective by use of triggers. e.g. there is no option to specify 'WHEN' Criteria in an alert which is possible through a database trigger.

Limitation

To avoid recursive loops To keep standard functionality unchanged It will have heavy performance impact. It will have heavy performance impact. Due to heavy customization the performance may be heavily impacted. Many a times the requirement for alert or database trigger can be eliminated by having scheduled jobs, which are much prefereable option to the the triggers.

Mandatory / Optional Mandatory Mandatory

Optional

Optional

Mandatory Optional

Optional Mandatory Mandatory

Mandatory

Optional Mandatory

Mandatory

Mandatory

Mandatory

Mandatory Mandatory

Mandatory

Mandatory Mandatory