Everything what is not shipped as Oracle standard may be called customization. And very often we differentiate between setup and customization, although setup can also be required when working with customizations.

This highlights one of the first challenges, because someone needs to track setup brought over with customizations and this needs to be synchronized with the (standard) setup done manually. This is not only a tracking issue, but also a documentation issue. I will cover this in one of the following blogs in more detail.

But back to the topic itself. Mainly our code pieces (java, pl/sql, sql, shell scripts), custom objects (tables, views, packages etc.) and application objects (concurrent programs, lookups, forms, reports, OAF pages etc.) are treated as customizations. In general we define two types: customization by extension and customization by modification. For sure we like to minimize standard code modifications, but sometimes it is just not possible to provide a certain functionality without doing it.

Keep in mind that the EBS provides a number of alternatives for modifications, just to mention some:

• Files in file system    add your custom top before the standard top to the path
• BI Publisher Report    add a custom layout and disable the standard layout, automatically yours will be taken.
• Form /OAF Change    use personalization or substitution

Using such techniques you are on the safe site regarding standard patches, but for sure a retest is always required!

Many customizations are growing over the time, initially it was just one file, but in between we have 5, 10 or 15 files in our customization pack. The more files you have, the more important is the installation order.

Last but not least also personalization's are treated as customizations, although you may not use any deployment pack to transfer such personalisation's (but you can). For OAF personalization's you can use iSetup, I have also enabled iSetup to allow Forms personalizations to transport.

Interfaces and conversion objects are quite often also categorized as customizations and I promote this decision. Your development standards are related to all these kinds of custom code whether we are exchanging data with users (via form or report) or with other systems (via inbound or outbound interface).

To cover all these types of customizations two acronyms have been defined: RICE and CEMLI.

RICE = Reports, Interfaces, Conversions, and Extensions
CEMLI = Customization, Extension, Modification, Localization, Integration

The word CEMLI has been introduced by Oracle On Demand and is used within Oracle projects quite often, but also RICE is well known as acronym.

It doesn't matter which acronym you are using, the main task here is to classify and categorize your customizations to allow everyone to understand when you talk about RICE- 211, CEMLI XXFI_BAST or XXOM_RPT_030.

Side note: Such references are not automatically objects prefixes, but they are often used as such. I plan also to address this point in one other blog.

Thank you!

Volker