Programming conventions to be followed in iRM environment:

Dictionary Objects: 1. All the application tables will have a prefix-/IRM/ and then the corresponding development class name followed by a minimum of 3 characters. 2. All the customizing tables will have a prefix -/IRM/T and then the corresponding development class name followed by a minimum of 3 characters. 3. The only exception to the above being, all the customizing tables in /IRM/GLOBAL development class will start with /IRM/TG and followed by a max of 3 characters. 4. All the customizing transactions should start with /IRM/0 (development class) followed by sequential number. 5. Structures: /IRM/S_ 6. Table Types: /IRM/T_ 7. Screen Fields: /IRM/<dev.class><application>SCRFIELDS. 8. Text tables: End with T that is /IRM/T<original definition table>T 9. Views: Maintenance Views : /IRM/V_<Customizing Table Name> Database Views : /IRM/VD_[<Table Name>/<Dev. Class><Purpose>] Help Views : /IRM/VH_[<Table Name>/<Dev. Class><Purpose>] Projection Views : /IRM/VP_[<Table Name>/<Dev. Class><Purpose>] DATA Declarations: 1. Global Data gv_ for variables, gt_ for internal tables, gs_ for independent structures, gwa_ for internal table work areas, ref_ for data/object references,

-1-

ts_ for tab strip controls, tc_ for table controls. 2. Local Data lv_ for variables, lt_ for internal tables, ls_ for independent structures, lwa_ for internal table work areas. lref_ for Local Data/object refernces

NOTE: Field symbols will follow the same conventions as above for global and local declarations. CONSTANTS: All constants will start with C_ Object references: start with ref_ Local Classes: Will start with lcl_ RANGES: Will start with R_ SELECT-OPTIONS: Will start with SO_ PARAMETERS: Will start with P_ Function Group: /IRM/<Dev. Class>_followed by at least one character, /IRM/G for function groups in Global development class. Function Modules: /IRM/<Dev. Class>_<Verb>, /IRM/G_..<verb> for global. Programs: /IRM/SAPM<Dev. Class>_<Verb>, /IRM/SAPMG_..<verb> for global.

Reports: Will start with /IRM/<Dev. Class>. Subroutines: end with <verb> all the time. Classes: /IRM/CL_ Interfaces: /IRM/IF_ Messages: Use the MESSAGE INTO command to raise message into application log. Define a global variable of 72 characters to store the formatted

-2-

message text. GUI Titles: For overview maintain/Display <application>: Overview For object in focus <create/change/display> <object type/category text> <object number> For selection screen Selections for <applic. Object> Menu: <object>, Edit, Go to, Extras, and Environment. <object>: create, change, display, separator, delete, separator and exit All docking containers should have SHOW/HIDE functionality. NOTE: You should not have selection screens for creating an iRM object in normal circumstances. NOTE: Always fill MANDT in all interface parameters while calling SAP standard functions. Function Codes: ENTR, DETL, DICH, COPY, CHDI, SAVE, CANC, BACK, UPDT, DELE, CONT, EXIT, CREA, CHNG, DISP. Tab-strip fcodes will start with TAB_. All fcodes in central engines will start with <Function group name>_ Environment Variables: We will always use GS_VARIABLES. Transactions: Create - /IRM/<Dev. Class>01 Change - /IRM/<Dev. Class>02 Display - /IRM/<Dev. Class>03 Authorization Objects: Will start with I_<Dev. Class>. Search-helps: Elementary search-helps: Will start with /IRM/SH_ Collective Search-helps: Will start with /IRM/CSH_ And then followed by selection method name (table/view/exit) Function modules/Class methods Interface:

-3-

IMPORTING: i_ for variables, it_ for internal tables, Is_ for structures/work areas, Iref_ for data/object references. EXPORTING: e_ for variables, et_ for internal tables, es_ for structures/work areas, eref_ for data/object references. CHANGING : c_ for variables, ct_ for internal tables, cs_ for structures/work areas, cref_ for data/object references. TABLES : t_ for table parameters. Classes: Member Data mv_ for variables, mt_ for internal tables, ms_ for independent structures, mwa_ for internal table work areas, mref_ for data/object references.

Functional Conventions: 1. Technical details are to be hidden from the end users as much as possible instead descriptions will be displayed. 2. All the domains with value ranges will be list boxes. 3. In all IRM applications wherever DELETE function is selected, a confirmation pop up is to be displayed. 4. Hide/Show Locator functionality to be provided for all docking containers that are on left side of the screen in all IRM application. 5. All the table controls will have With Configurable option selected. 6. In all grid display, a double click will display the details window. 7. All the QUANTITY fields are to be displayed along with corresponding UOM fields and all the AMOUNT fields are to be displayed along with corresponding CURRENCY fields. 8. All the application should have REFRESH functionality. Some More added: 1. For an IRM business application, the following should have the same name, a. BOR object b. Message class c. Lock object -4-

d. Number range object e. Application Log object f. Notes object 2. No test data to be created in CLIENT 025(application and Customizing 3. Test data (application and customizing) must be creates in CLIENT 040. 4. customizing (including cross client customizing) that is to be delivered must be done in CLIENT100. 5. BACK must come back one level if there are no errors . It must not be an E function, must process PAI and is to be handled to be FCODE_PROCESSING. 6. CANCEL must come back one level and must give a confirmation Popup only at document level and not at any sub levels(for example, item level) .It must not process PAI(unless directed so by user in confirmation popup)and is to be handled in EXIT_PROCESSING. 7. EXIT must come back to the initial screen of the transaction if any or must come out of the transaction and must give a confirmation popup at all levels. It must not process PAI (unless directed so by user in confirmation popup) and is to be handled in EXIT_PROCESSING. Coding Conventions: 1. All IRM application should support with/without dialog processing 2. All the necessary routines are to be reusable and should be compatible with/without dialog processing modes. For example consistency check routines. 3. For each application, 3 function groups are to be created. a. For Access b. For Maintenance (with/without dialog processing) c. For Update 4. All SAVE function module interfaces should have a field called I_COMMIT(default space) for COMMIT WORK inside the function modules if it is set to X. Wherever the save function modules are called with I_COMMIT equal to space, the commit work will be provided by the caller. 5. Wherever we use LOOP AT internal table we should use LOOP AT . ASSIGNING. -5-

6. Whenever a message is to be given, MESSAGE statement will be used if in dialog mode otherwise MESSAGE . RAISING statement will be used and the messages will be collected in application log. 7. Wherever the dates are to be calculated, factory calendar has to be considered. 8. For all QUANTITY fields, different UOMS are to be supported i.e. unit conversions are to be done if required. 9. For all AMOUNT fields, different CURRENCIES are to be supported i.e. currency conversions are to be done if required.

-6-