COPYRIGHT NOTICE and DISCLAIMER:

(c) Copyright 1998, 1999, 2000, 2001, 2002, 2004, 2005  by the Massachusetts Institute of Technology, Cambridge, Massachusetts, USA.

M.I.T. hereby grants to any organization producing ABAP code the right to use this document or parts thereof for noncommercial internal use subject to M.I.T.'s disclaimer of liability contained herein and provided that all copies shall bear an M.I.T. copyright notice in the form provided above.

This documentation is provided "as is" without warranty of any kind, expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose, and further without warranty that use of this documentation will not infringe the patents, copyrights or other intellectual property of third parties. In no event shall M.I.T., its trustees, directors, officers, employees or students be liable for incidental or consequential damages of any kind, including, but not limited to damage or injury to property and lost profits, regardless of whether M.I.T. knew or had reason to know of the possibility of such an occurrence. No permission to use the name of Massachusetts Institute of Technology or M.I.T. or any adaptation thereof is granted to any user of the ABAP code or documentation, except for use in the notice of copyright provided above. Massachusetts Institute of Technology, M.I.T. and MIT are registered trademarks of the Massachusetts Institute of Technology and may not be used in any manner without the prior written permission of the Massachusetts Institute of Technology.

If you have questions about topics in this guide, would like to suggest changes, or provide new topics to be included, please submit the topics and details about the updates to sap-dev-standards@mit.edu.

Revision	Date	Description of Changes
8	13-Feb-2006	Added two sections under Coding Standards; "Interface: Processing Inbound & Outbound Files" and "Uploading and Downloading files between the SAPgui & the R/3 System." Updated Appendix B (2 character codes for application areas), adding BD and EP.  Updated Appendix C (Development Classes), adding development classes ZBD0 and ZEP0. Some UI clean up.
7	31-Aug-2005	Removed the red arrows in the Table of Contents that indicated previously modified or added sections.  Added a requirement for setting the P_HNCAT and P_BOUNCED_MAIL parameters to the Z_SENDMAIL function module.  Added instructions for restricting access to HR data.  Updated Appendix B (2 character codes for application areas), adding BU, EH, and FF.  Updated Appendix C (Development Classes), adding development classes ZBUD0, ZEH0, ZFF0, ZPE0, ZPM0, and ZPY0.  Added a new section on the naming conventions for "Check Modules for External Commands". Added Appendix D (Approval process for Direct Updates & Mods). Replaced obsolete mailing lists with active ones. Replaced ZJOBRUN with ZJOBRUN2 table details.
6	1-Oct-2002	Updated the table of contents. Modified the ZJOBRUN section. Updated Appendix B (2 character codes for application areas).  Updated Appendix C (Development Classes). Made many spelling corrections. Fixed one of the links in the table of contents so that it would link to the correct section.
5	1-Feb-2002	Modified the Introduction/Purpose section.  Added a link to "Revision History" and reversed the order of revisions so that the latest revision is at the top.  Updated the table of contents.  Modified the section concerning making programs obsolete.  Added a section on "Guidelines For Deleting Old/Unused ABAP Code".  Modified the section on "Dates : Output in reports".  Added a section on "Termination Codes in Cost Objects".  Added a section on the "Communication Between Foreground and Background Processes".   Added a section on the "Choices of Currency Fields".  Added a section called "Intercepting & Logging Emails via Z_SENDMAIL".  Added a section on "Restricting the Capabilities of Select Options in ABAP Programs".  Added a section on the "Enterprise Structure Attribute Table".  Added a section "Naming Conventions in ABAP Objects".  Added a section called "General Toolkit for Multiple Enterprise Structures".  Added a new major section in the table of contents called "User Interface Standards", and moved the sections "GUI: SAP Style Guide", "GUI : Screen Painter Resolution" into it.  Added a link to the "MIT Web Site Look and Feel Standards" and moved this section under the "User Interface Standards".  Added a section regarding the use of Radio Button Groups.  Added a section on "Naming Conventions in ABAP Objects".  Updated Appendix B (2 character codes for application areas).  Updated Appendix C (Development Classes).  Made many spelling corrections.  Updated 4.5 references to relevant 4.6 references.  Added tables and more bulleted sections for better readability.  Modified coding examples to incorporate some of the correct documentation standards
4	6-Mar-2000	Added disclaimer. Added section on function modules. Added section on making programs obsolete. Added section concerning request & task naming. Added section for the creation of custom tables. Updated source code documentation section. Added information about messages and program variable naming. Updated performance checklist. Updated section concerning legacy conversion function modules. Added some application area two-letter abbreviations. Added naming standards for function module IO. Added requirements for handling 40-character program names. Added list of development classes. Added section for processing the results of a BDC call transaction. Note that new or modified sections are highlighted in the table of contents with a "".
3	17-Sep-1998	Performance Section update, New Tips & Tricks, Application abbreviations added (PM, RQ, BP), New document layout and navigation features.
2	22-May-1998	Document layout changes and spelling corrections.
1	15-May-1998	Initial (post-review) distributed version.

This document was created to outline several naming standards, programming standards, and best practices in ABAP programming and provide guidelines for ABAP development for MIT. These are MIT's "ABAP/4 Development Standards" and contain MIT-specific programming conventions and techniques. The topics include:

• general coding standards
• performance standards
• user interface standards
• naming conventions
• tips & tricks
• sample programs

The document is intended for use by ABAP developers as a guide for MIT-specific developments and enhancements to R/3. The user of this document should be familiar with basic concepts of R/3 and should have taken a training class equivalent to SAP20 R/3 Overview.

To request clarification of these issues or to suggest other topics to be covered, please send mail to: sap-dev-standards@mit.edu.

The purpose of this document is as follows:

• to describe a consistent set of practices so that all code which follows these practices will use uniform conventions and techniques. Therefore, once a programmer has become familiar with these conventions, he will have a much easier time understanding all the other MIT programs which also follow the same set of practices.
• to recommend, explain and illustrate techniques that have been developed as efficient ways of handling certain situations which come up in ABAP programming.

The standards have been developed in conjunction with a number of supporting function modules, custom tables, and (sometimes) complete programs. It was worth investing the development effort in those supporting tools, because many people will use them. Similarly, since the tools already exist, are known to work, and are being maintained, it would be foolish not to use them whenever the circumstances for which they were created arise.

SAP development at MIT has been done by a combination of consultants, contractors and employees who have had varying levels of experience with other SAP projects and with other MIT projects. A number of the people who worked on our implementation are no longer at MIT. We need to make the code developed for MIT's SAP project as easy to understand and easy to maintain as possible. In order to do that, the ABAP developers at MIT have written this set of development standards.

Anyone doing SAP development at MIT should subscribe to the MIT-ABAP mail list. This includes employees, contractors, consultants, project leaders, and project managers. The list is intended for all development issues including configuration, workflow, report writer, report painter, basis, system administration, documentation, support, training, management, and master data maintenance.

To subscribe to the list, send e-mail to LISTSERV@MITVMA.MIT.EDUwith the body of the message containing the single line "SUBSCRIBE MIT-ABAP [Your real name]". (without the quotes or brackets and filling in your name.)

Steps to make a program obsolete:

1. Verify that the program is not referenced by any other programs, transactions or dialog modules that are not obsolete in either the production or development environments. If it is, notify the person who requested the program to be made obsolete and stop here.


2. Reconcile the development version with the production version, and revert development to the same version as production if it is different. (Use the Version Management function to do this). Make sure that the retrieved version can be generated without errors. If there are errors - return back to the original active version.


3. If you have to go back to the previous version, make sure that any active development of an object in unreleased requests/transports is saved by releasing the request/transport.


4. If the program is not a function module, go to transaction SE38, and put in the program name which is to be made obsolete.  Click on Attributes, and then click on "Change". Change the title of the program to start with the word "Obsolete". Change the Authorization Group to "ZINACTV0" (the last character is the digit ZERO), and the Application to "* Cross-Application". Attempt to change the Development Class to "ZZZ0" (the last  character is the digit ZERO). If you have problems changing the development class, go back to the ABAP editor initial screen. Click on "Goto" at the top of the screen, and then click on "Object Directory entry" on the dropdown. Make the change and save.


5. Send all the information about the program (including by whom & when it was determined that this program is obsolete) to sap-obsolete-progs@mit.edu. Please be sure to send your e-mail before releasing the program from SF2.


6. Transport the changes made to SF5 and Production.

Since SAP doesn't let us change the authorization group for one function module, we (MIT) are

   4a. Under ATTRIBUTES tab, change the short text (i.e. one line description) of the function

       module to start with the word "Obsolete".

   4b. Use the editor function to make all the source code lines of the function module into

       comments.  (On the PC version of the ABAP editor, you can use Control-A to select

       all the code and Control-< to make all the selected code into comments. On the Mac,

       click on the first line of code, then click on the Select icon, then click on the last line

       of code, then click on the Select icon to select all the code. Then select the menu item

Utilities -> Block/buffer -> Insert comment*

      to make all the selected code into comments.)

      * NOTE: you cannot comment out the key lines Function/Endfunction.

   4c. Insert a comment at the top of the function module source code stating that the function
        module is now obsolete.

   4d. Put the following ABAP statement in the source code in order to force a short dump should
        someone try to execute the function module:

MESSAGE ID 'ZZ' TYPE 'X' NUMBER '132' WITH 'Function module'
    '<name of function module>'.

   4e. Use the ABAP Workbench command to mark the function module as obsolete. (Go to SE37,
       type in the function module name and click on the "change" button. Go to the "Attributes"
       tab. Select the menu item:

Function module -> Release -> Object obsolete

 Here is an example showing steps 4b, 4c & 4d:

FUNCTION Z_INSERT_TR_ACCOUNT .
*********** This function module is OBSOLETE ***********

MESSAGE ID 'ZZ' TYPE 'X' NUMBER '132' WITH
'Function module' 'Z_INSERT_TR_ACCOUNT'.

**"---------------------------------------------------------------------
*
**"*"Update function module:
**"
**"*"Local interface:
**"  IMPORTING
**"     VALUE(TRAV_ACC) LIKE  ZTRV1 STRUCTURE  ZTRV1
**"  EXCEPTIONS
**"      INSERT_ERROR
**"---------------------------------------------------------------------
*
*
*   MOVE-CORRESPONDING TRAV_ACC TO ZTRV1.
*   INSERT ZTRV1.
*   IF SY-SUBRC <> 0.
*     RAISE INSERT_ERROR.
*   ENDIF.
ENDFUNCTION.

Guidelines For Deleting Old/Unused ABAP Code

When maintaining a program, new code is written to replace older code. It is usually a good idea to comment out the code rather than delete it entirely. This serves 2 purposes: it makes the old code readily available in case there is a problem with the new code, and it serves as documentation of how the old code used to work. After a while, so much commented-out code can accumulate that it makes it difficult to read the program - that is, the accumulated commented-out code can become confusing rather than helpful. (Code that was once active generally should be carried as commented-out code in at least one transport before it is actually deleted, but this is not an absolute requirement.)

If, in the judgement of the programmer, the commented-out code is confusing rather than helpful, the old code may be deleted if ALL of the following four conditions are met:

1. The code to be deleted has been captured in SAP version management as part of a released transport.


2. You add text to the revision history stating which line numbers in a previous (specified) released transport you deleted and why you deleted them. It is very desirable that you also cite the last transport in which these items were active. For example, you might write "Deleted commented-out code on lines 1570 through 1620 of transport SF2K912345 in order to make the program easier to read. This code was last active as lines 1232 through 1282 in transport SF2911678.".


3. The revision history of the program is reasonably complete with good explanations of what was added or deleted as part of each transport, as well as the functional consequences of that change (not just a generic comment like "fixed bug" or "added new features"). A revision history like this should be maintained contemporaneously with changes to the code. If you acquire maintenance responsibility for a program that is already in production and has commented-out code which is not described in the revision history, you don't have to retroactively document the effect of the commented-out code. You do have to add to the revision history a statement following the example in item 2 (above) and a statement of whatever you know (or can easily determine) about the intended effect of the commented-out code that you are deleting.


4. (If applicable) When an algorithm or general approach is changed, comments should be added near the code for the new algorithm or approach describing:
   1. how the new approach differs from the old one
   2. the most recent released transport with the old approach
   3. the range of line numbers containing the code that implemented the old approach in the version included in the referenced transport

Authorization Groups permit users access to execute report-type programs from transaction SA38 (or SE38).  All MIT-written reports must have an explicit authorization group. There are 3 cases:

• Programs that can be executed by all MIT users must be configured using the authorization group 'ZOPN2ALL' for Application '*'.  This configuration is done by the developer of the report program in the 'Attributes' screen of SE38 .
• Programs that should only be executed by a restricted set of users should have an authorization group that is defined to include only that set of users. (In many cases, it may be desirable for a large set of developers and testers to have that authorization in SF2, a smaller set to have that authorization in SF5, and an even more restricted set to have that authorization in production.)
• Some programs have other authorization controls (for example, the program may provide particular functionality to certain users as determined by the ABAP "AUTHORITY-CHECK" command or an authorization checking function module), but other functionality is available to everyone. In that case the program should use the 'ZOPN2ALL ' authorization group in addition to its explicit use of the ABAP "AUTHORITY-CHECK " command or an authority checking function module.

When choosing an existing authorization group to assign to a program, especially a program that does not have additional authority checks in the program itself, be sure that the people who will be using the new program already have access to the authorization group chosen. If they don't, it is very possible that the authorization group chosen is not appropriate for the program, as giving them access to the new program would give them access to the other programs the authorization group controls.

In summary, all MIT-written reports must have an explicit authorization group - either as the only authorization mechanism or in conjunction with some other authorization mechanism. The 'ZOPN2ALL' authorization group should be used where the intent is to allow everyone in the community to at least start the program (although another authorization mechanism may be used to further restrict who can perform particular functions or access particular data).

For any custom programming using authorization checks, developers must determine whether a standard SAP authorization object should be used, or if a custom object should be developed. Since the authorization object implementation typically comprises more business-related than technical issues, developers should consult with the business analysts responsible for the application in making this decision.

Because of the sensitivity of HR data, all custom-written programs that access HR data must restrict who can access the HR data. Four methods to accomplish authorization checks for HR data are listed below:

1. Use function module HR_READ_INFOTYPE instead of direct SELECT statements when reading a specific infotype.


2. Use logical database PNP to leverage SAP authorizations (caveat: performance can be slow)


3. SELECT statements should only be used when the SAP documented data interfaces which incorporate the SAP authorization checks (Logical Databases, function modules, and BAPI's) cannot provide the functionality required. If it is necessary to use SELECT's, then you must perform your own AUTHORITY-CHECK on the data selected.


4. Place a strict authorization group at the program (transaction) level. If a wide variety of data for a large group of individuals is needed in a single program, then this program must have a very strict authorization on who can run it (definitely not on any menu path).
   

The preferred formats for representing a date in a printed report are either MM/DD/YYYY or DD-Mon-YYYY(where "MM" is the two-digit number of the month, "DD" is the two-digit number of the day within the month, "YYYY" is the four-digit year, and "Mon" is the three-letter abbreviation of the name of the month).

In any case, use of a 4-digit year is a requirement. (The preferred format for dates in input, i.e. "Feed", files is YYYYMMDD.)

The R/3 system is already year 2000 compliant. To preserve that compliance, whenever a date is written or read, the year field should contain four digits. The only exception to this standard is reading from or writing to external files, where the year 2000 restriction in the external system may be different. However, even in this case, if it is at all possible, it is desirable to allocate four digits for the year in the file layout.

All external file layouts used for files transmitted to and from the R/3 system should be discussed with and approved by the Infrastructure (formerly Bridges) Team before the layout is finalized. This is to insure consistency in field conventions and file processing standards. The requirements for the following data elements are:

• Dates: As indicated in the section "Writing dates in reports," dates should use a 4-digit year with certain exceptions.
• Cost Objects: Cost objects should be left-aligned in a 12-character field with trailing blanks. (Optionally, a 7-character field followed by 5 characters of blank filler is acceptable.
• Cost Elements: Cost elements should be left-aligned in a 10-character field with trailing blanks. (Optionally, a 6-character field followed by 4 characters of blank filler is acceptable.
  

The dropbox is the standard method for data providers to automatically deliver files created outside of SAP as feeds into MIT's SAP R/3 environments. Data providers must be registered with the dropbox. These providers FTP data files to the dropbox. Based on a combination of file naming conventions and registered dropbox userids, the files are automatically delivered to the appropriate MIT SAP R/3 environment.

Detailed documentation on how to use this mechanism is located at http://web.mit.edu/ist/org/admincomputing/dev/dropbox.html

What SAP application programmers do to process inbound files

• Call Z_UT_GET_INPUT_FILE_NAME with the filename field from the selection-screen, the (4-char) provider & the (3-char) feed codes and (optionally) the name of an acceptable event.
• Call Z_UT_START_OF_INBOUND with the file name (from Z_UT_GET_INPUT_FILE_NAME).
• Read & process the input file.
• Call Z_UT_END_OF_INBOUND when finished.

More information on processing inbound files (pdf).

What SAP application programmers do to process outbound files

• Call Z_UT_START_OF_OUTBOUND with the (4-char) provider and the (3-char) feed code to obtain the pathname of your output file.
• Do your processing, write the output file and accummulate control totals.
• Call Z_UT_END_OF_OUTBOUND with the key (in the ZJOBRUN2 table) for the output file and the contents of the control record.

More information on processing outbound files (pdf).

When an inbound interface program is initiated by triggering an SAP event, the filename is sent as an event parameter which should then be read by the interface program. An example of using this triggering and parameter passing method is outlined in program ZDMR0036 (in development system SF2).

Many programs read input files or produce extracts from the R/3 and require detailed tracking data file names and error statuses (beyond the capability of the standard R/3 job scheduler). Even if the program doesn't need to keep track of file numbers or status, there are other reasons that a program might need to preserve some status information from one run of the program to the next. It also might be necessary to record some status information for easy access by a human being. To provide a common repository for job status, the ZJOBRUN2 table was created. All programs that need to track job status should read / write records to / from this table. New programs must not use text files outside of the R/3 system or other custom tables for this purpose. Programs that currently use methods other than the ZJOBRUN2 table to track status should be modified to use ZJOBRUN2 instead.

NOTE: ZJOBRUN2 is an new and improved version of the original ZJOBRUN table. The original table is still in use by older programs but should no longer be used for developing new programs.

Here is the layout of the ZJOBRUN2 table:

Supervisor and addressee names are stored in SAP master data tables. Because it is possible for more than one person to have the same name, MIT ID is used to uniquely identify a person at MIT. The MIT ID of each cost object's supervisor and addressee is stored in table ZCOOBJECT. The master list of MIT ID's is kept in table ZMITID. Several MIT-developed function modules exist to allow programs to access these tables. They are outlined below.

• Z_CO_M
• ITID_TO_NAME - Convert MIT ID to name in format L /F M and as separate components;
• Z_CO_COST_OBJECTS_FROM_MITID - Return a list of cost object numbers from MIT id numbers passed in a range table;
• Z_CO_COST_OBJECT_NAMES - Return the names of the supervisor and addressee of a given cost object;
• Z_CO_GET_MITID_POPUP - Display Popup of MITID information from a given select-options.

In addition, collective search help ZMID is available for possible value help. It consists of two elementary search helps:

• ZMIDA - Lists all MIT ID's in the system for given selection criteria;
• ZMIDB - Lists only those MIT ID's which are either supervisors or addressees of cost objects.

Master Data: Determining Cost Object Type, Company, and Validity

Function Module Z_CO_GET_COST_OBJECT_TYPE can be used to determine the type
of a cost object, verify that the cost object is valid, and determine the company code of which
it is a part. The function module Z_FI_VALIDATE_GL_ACCOUNT is the G/L account counterpart
to Z_CO_GET_COST_OBJECT_TYPE. Z_FI_VALIDATE_GL_ACCOUNT is called with a G/L
account number and a company code. Z_FI_VALIDATE_GL_ACCOUNT will indicate whether
the specified G/L account is valid in the specified company code and whether any flag is set which
obviously prevents posting to that G/L account. (Again, it is possible that even if no flag is set there
might be some other reason that a charge or credit can't be posted to the specified G/L account.)

This section describes TermCodes in Cost Object master data and the ZSTATUS field of ZCOOBJECT table entries describing those Cost objects. (Note: when there is no TermCode on a Cost Object that is the same as saying that the value of the Termcode is "space").

* = Was used to indicate a restricted state in the MIT classic system but it no longer has any special significance.

Invalid Cost Objects (Cost Objects with TermCode = ZSTATUS = 8 or 9) should be treated by almost all MIT custom programs as though the Cost Objects don't exist. The only programs that should take cognizance of these invalid Cost Objects are transactions ZCO2 and ZCO3 (for modifying and displaying Cost Object master data), program ZCO005F (the Trial Balance report), and some extracts sending data to the data warehouse.

Terminated Cost Objects (with TermCode = 3, ZSTATUS = T) are valid and may be reported on, but they may not have any charges or credits posted to them. It is permissible to "Park" a document with charges or credits to a terminated (TermCode = 3, ZSTATUS = T) Cost Object.

An alphabetic character in the ZSTATUS field of the ZCOOBJECT table indicates that the Cost Object described by that row is a valid Cost Object. A numeric digit in the ZSTATUS field of the ZCOOBJECT table indicates that the Cost Object described by that row is an invalid Cost Object. MIT's Master Data maintainers guarantee that if the same Cost Object number appears in ZCOOBJECT more than once, only one of those appearances will have an alphabetic character in the ZCOOBJECT-ZSTATUS field - that is, at any instant, there will only be one valid cost object with a given Cost Object number.

Most MIT function modules that return data about a Cost Object by looking it up in the ZCOOBJECT table will ignore any rows that have a numeric digit in the ZSTATUS field of the ZCOOBJECT table. If the only row for a particular Cost Object number has a numeric digit in the ZSTATUS field of the ZCOOBJECT table, the function module will raise an exception indicating that there is no valid Cost Object with that number.

Function module Z_CO_GET_COST_OBJECT_TYPE was originally written to return the type (cost center, internal order, or WBS) of a valid Cost Object. During the M.E.S. project it was enhanced to (optionally) return the company code of the Cost Object. It has been enhanced again to also (optionally) return the status of the Cost Object. The status is the contents of the ZSTATUS field of the ZCOOBJECT table. Currently the returned status will be either 'X' (for a valid non-terminated Cost Object) or 'T' (for a valid terminated Cost Object).

Attempts to post charges or credits to terminated (TermCode = 3, ZSTATUS = T) cost objects will be prevented by MIT's validation rules. However, some programs might find it useful to know before attempting to post that the posting will be prevented by MIT's validation rules. Such programs can check whether the status returned by Z_CO_GET_COST_OBJECT_TYPE is 'X' or 'T'. (Of course, even if the statusis 'X', there are many other reasons why it might not be possible to post charges or credits to the Cost Object.)

Under no circumstances should any program directly update SAP-delivered tables using the INSERT, UPDATE, or DELETE commands. SAP-delivered tables begin with all letters other than Y and Z, and they should only be updated using an SAP transaction. To automate updates to SAP tables via a program, you may use the CALL TRANSACTION command (or optionally create a BDC using SAP supplied functions, or use BAPIs).

More information is in Appendix D.

R/3 has message libraries (or classes) containing numbered messages which may contain placeholders. The ABAP MESSAGE command allows the programmer to specify a message library, a message number and up to four values to be substituted for the placeholders in the message.

Sometimes an ABAP programmer needs to substitute values for the placeholders himself - for example to present the messages produced as the result of a CALL TRANSACTION.
It is strongly recommended that the ABAP programmer use the ABAP

"MESSAGE ID mid TYPE mtype NUMBER nr WITH f1 ... f4 INTO expanded"

command.

When a function module detects an error, it (typically) raises an exception to report the error back to the caller. If you use the ABAP "RAISE" command, the caller gets the number associated with the exception. It is strongly recommended that MIT-written function modules not use the ABAP "RAISE" command - but use the ABAP

"MESSAGE ID mid TYPE mtype NUMBER nr WITH f1 ... f4 RAISING exception"

command.

This form of the ABAP "MESSAGE" command is only possible within a function module or a method. It triggers the exception "exception". If the program calling the function module or method handles the exception itself, control returns immediately to that program. In this case, the export parameters of the function module are ignored. However, the calling program can refer to the system field values:

• SY-MSGID (message ID)
• SY-MSGTY (message type)
• SY-MSGNO (message number)
• SY-MSGV1 (message value 1)
• SY-MSGV2 (message value 2)
• SY-MSGV3 (message value 3)
• SY-MSGV4 (message value 4)

This section discusses the "recommended" method of communicating information from a foreground process to a background process.

In some cases it is desirable to have an interactive program which acquires some data (perhaps by reading a file on the desktop machine, perhaps some by other means such as user entry or a selection controlled by user entry) and passes that data to a background job for further processing. There are several ways that the information could be passed. One method is to have the interactive program write a Unix file which the background job will read.  That is NOT recommended (any more). The following three methods are recommended. The first two methods assume that the interactive (foreground) job creates and SUBMITs the background job and can pass parameters to the background job by including the parameter values in the SUBMIT command.

• If there is very little data, have the foreground job use the SUBMIT command to pass the actual data through selection screen    parameters or select-options when creating the background job.
• If there is more data, have the foreground job export it to the INDX table in the database and us the SUBMIT command to pass the ID key through a selection screen parameter when creating the background job.
• In some special cases, it might be better to create a new custom table and have the foreground job load the data into the custom table, from which the background job will retrieve it.

TABLES INDX.                                   "Not required in 4.6C
DATA key like INDX-SRTFD.
EXPORT t_itab TO DATABASE INDX(ar) ID key.
    where "t_itab" is the name of your internal table,
          "ar" is a two-character constant of your choosing,
          "key" is a variable containing a unique key (up to 22
          characters long) that you created (you might want to consider
          using elements such as the user name, the date, the time, the
          work process number, the application server name, etc. to
          produce a unique key)
SUBMIT BACKGRND ... WITH A_KEY1 = key ... .

In the background job:
TABLES INDX.                                   "Not required in 4.6C
PARAMETERS: a_key1 like INDX-SRTFD NO-DISPLAY.
IMPORT t_itab FROM DATABASE INDX(ar) ID a_key1.
    where "t_itab" is the name of your internal table,
          "ar" is the same two-character constant,
          "a_key1" is the parameter into which the unique key was passed
After you no longer need the data, the program should
DELETE FROM DATABASE INDX(ar) ID a_key1.

SAP Tables contain multiple monetary amounts for two reasons:

1.  The amounts are expressed in (potentially) different currencies.
2.  The amounts represent different costs, expenses, or balances.

This section deals only with item 1 - that is, it is intended to provide guidance in the selection of field(s) which use the current currency.  It does not deal with item 2 - the programmer or business analyst must determine which costs, expenses, or balances the program should be using.

Make sure that the correct monetary fields are used.

• For FI Tables, use the monetary amount in the company code currency firld, sometimes described as the "local currency" field.
• For CO Table, use the monetary amount in the controlling area currency field.

If you need guidance in selecting fields from a table not yet listed here, or you have information about "monetary" fields not listed here, please contact either your FI-CO technical resource or Technical Services.

TABLE	TABLE DESCRIPTION	MONETARY FIELD TO USE *	FIELD DESCRIPTION
BSEG	Accounting Department Segment	DMBTR	Amount in local currency
COEP	CO Object: Line Items(by period)	WKGBTR	Total value on CO area currency
COSP	CO Object: Cost Totals for External Postings	WKG99	Total value on CO area currency
COSS	CO Object: Cost Totals for Internal Postings	WKG99	Total value on CO area currency
GLT0	G/L Account Master Transaction Figures	HSL99	Total Transactions in the period in local currency
RSPCO	Project Info Database: Cost,Revenues,Finances	WLP99	Period value in Ledger currency

*  The '9' 's in this column stand for a given period (1 through 16).

The majority of E-Mail sent from the MIT R/3 systems is sent via custom function module Z_SENDMAIL. After it was put into production, some additional input parameters were added to Z_SENDMAIL. Since Z_SENDMAIL was already being called by production programs, the new input parameters had to be added as optional parameters. However, any new or recently modified programs that call function Z_SENDMAIL are required to supply

• An explicit two-character "E-Mail Handling Category" in the P_HNCAT parameter
• An appropriate address in the P_BOUNCED_EMAIL parameter

Regarding P_HNCAT, if you do not find a mail handling category to fit your needs at E-mail Handling Categories , request a new mail handling category by sending mail to tech-services@mit.edu and then use the assigned value for the P_HNCAT parameter.

The address supplied in the P_BOUNCED_EMAIL parameter should be the address of a list of people who can take action to fix whatever problem caused the mail to bounce. Usually, this should be a mail list that is monitored by process owners who can investigate an undeliverable message or correct an invalid address. In general, the address supplied in the P_BOUNCED_EMAIL parameter should be one of the following (in order of preference):

1. A mailing list of people from the business process side who can recognize and have the ability to resolve the issue of a bounced E-Mail message. For example, CAO maintains master data including cost object approvers. If a message to someone in the role of cost object approver bounced, the bounce should be directed to a list of appropriate people in CAO, so that the master data can be updated.
2. A mailing list of people from an Admin Computing support or project team who can resolve the bounced mail.
3. "sap-bounces@mit.edu". Currently, this mail will go to Carolyn Fuller, David Rosenberg, Wai-Ming Li, and Kevin Lyons for resolution.

Each call to the custom function module Z_SENDMAIL must pass a two-character "E-Mail Handling Category" in the P_HNCAT parameter (see previous section). The ZEHCAT table is used in conjunction with this e-mail handling category to instruct Z_SENDMAIL to intercept and/or log the e-mail message.

The purpose of documents listed below is to:
 

•     Provide information needed to instruct Z_SENDMAIL to intercept and/or log e-mail.

•     Detail the process by which e-mail is intercepted and/or logged.

          View document : Intercepting and Logging E-mail via Z_SENDMAIL

          View document :  E-mail Handling Categories

The following document discusses how to restrict the capabilities of select-options in an ABAP
program. In particular, it addresses the special situation of restricting a select-option in a
program that makes use of the standard MES include file ZES_AFTER_INIT_FOR_S_BUKRS
(this include file already contains code to restrict the company code select-option, S_BUKRS).

View Document :  Restricting_Select_Options

In the original SAP implementation at MIT, we had written all our custom programs assuming that there was only one company code, one controlling area, one currency, one fiscal year variant, etc. When a decision was made to alter our configuration to have multiple company codes, controlling areas, and fiscal year variants, we had to review all our custom code and modify more than half of it to accommodate multiple enterprise structures. We wanted to protect ourselves from ever having to go through that experience again. We created an "MES Toolkit" consisting of three function modules, about nine include files, and cookbook documentation describing how to use them. One of benefits of the "MES Toolkit" is that it provides structures that contain all the relevant MES variables so that (after it has been initialized properly) they can be used like SY-* variables Ð there is a consistent set of names that will be populated with the correct values and be referred to in a consistent way in all programs (that use the "MES Toolkit"). We defined 7 different MES compliance levels (depending on what the program had to do) and we added a command to the ABAP editor for recording a programÕs MES compliance level. We also have a required field when submitting a transport request (via ZUTTREQ) to state the MES compliance of the program being transported. We wanted to be sure that all new programs and every program that was modified in a way dealing with multiple enterprise attributes followed these procedures - to save us the effort of ever going to go through the conversion again.

All new programs, all programs that undergo significant modification or enhancement, and every program that was modified in a way dealing with multiple enterprise attributes must be written to function correctly in an environment where we may have many different enterprise structures in the same SAP client - preferably by using the "MES Toolkit".

The following table lists those enterprise structure attributes that have thus far been identified as those whose value should be determined dynamically.  That is, they should not be assumed to have a constant value throughout the SAP system, but instead, should be derived either through user input or via table lookups based upon the value of a known related attribute.

Area	Attribute	Par ID	Valid Values	Campus Value	Typical Use
Cross Application	Fiscal Year Variant	GJVAR	T009-PERIV	V6  (see table T009 in Production)	MARC-PERIV
Cross Application	Chart of Accounts	KPL	T004-KTOPL	HEUS	SKA1-KTOPL
Cross Application	Country	LND	T005-LAND1	US	CSKS-LAND1
Cross Application	Currency  (used as transaction currency)	FWS	TCURC-WAERS	USD	BKPF-WAERS
Cross Application	Currency  (used as company code currency)	FWS	TCURC-WAERS	USD	GLT0-HSL01
Cross Application	Currency  (used as CO area currency)	FWS	TCURC-WAERS	USD	COSS-WKG001
Cross Application	Currency  (used as group currency)	FWS	TCURC-WAERS	USD	GLT0-KSL01
Finance	Consolidation Company	GCC	T880-RCOMP	MIT	GLT2-RCOMP
Finance	Company Code	BUK	T001-BUKRS	CUR	CSKS-BUKRS
Finance	Funds Mgmt Area	FIK	FM01-FIKRS	MIT	FMFCTR-FIKRS
Finance	Credit Control Area	KKB	T014-KKBER	MIT1	BSEG-KKBER
Finance	Business Area	GSB	TGSB-GSBER	<initial>(Not currently used)	BSEG-GSBER
Finance	Functional Area	FBE	TFKB-FKBER	<initial>(Not currently used)	BSEG-FKBER
Controlling	Controlling Area	CAC	TKA01-KOKRS	MIT	CSKS-KOKRS
Sales and Distribution	Sales Organization	VKO	TVKO-VKORG	Several  (see table TVKO in Production)	VBAK-VKORG
Sales and Distribution	Distribution Channel	VTW	TVTW-VTWEG	10	VBAK-VTWEG
Sales and Distribution	Division	SPA	TSPA-SPART	10	VBAK-SPART
Materials Management	Plant	WRK	T001W-WERKS	Several  (see table T001W in Production)	EBAN-WERKS
Materials Management	Purchasing Organization	EKO	T024E-EKORG	GPO, SUB	EKKO-EKORG
Human Resources	Personnel Area	PBA	T500P-PERSA	Several  (see table T500P in Production)	PA0001-WERKS
Human Resources	Personnel Sub-Area	PBS	T001P-BTRTL	Several  (see table T001P in Production)	PA0001-BTRTL

The values of most enterprise structure attributes may be derived from the value of some "base" attribute such as company code or controlling area.  Therefore, many programs will not require that their selection screens contain any enterprise structure attributes other than company code and controlling area.

The program should be written so that it uses variables containing the values of enterprise structure attributes obtained from the selection screen and system tables, even in the event that the program may not permit user entry of the "base" attributes and hence only one set of values will be used for the enterprise structure attributes.

The M.E.S. (Multiple Enterprise Structure) include files described in the next sectiuon automatically gather some of these enterprise structure variables for you.  The M.E.S. function modules can also be used to gather values in a standard way.

In an effort to assist developers in making MIT custom programs MES (multiple enterprise structure) compliant, numerous standard INCLUDE programs and function modules have been developed.  The following section describes the use of these standard routines when developing a list-processing program.

Directions in this section will support one or more (user-specified or defaulted) companies in a (user-specified or defaulted) controlling area. It involves the use of a parameter to indicate the chosen controlling area and includes variations to allow either a parameter or a select-option for indicating the chosen company code(s).

I. What you must include near the beginning of the program:

    A. In the case where the program selects company codes via a select-option, you must add
        the following statement within the section where you are declaring database tables
        (unless GLPCA is already in a TABLES statement):

      TABLES GLPCA.

    B. Early in the section where you are declaring global data, include:

      INCLUDE ZES_GLOBAL_DATA_ALWAYS.

    C. Controlling area: Include a parameter named A_KOKRS in the definition of the selection screen
         and create the selection text "Controlling Area" for it:

            1. If the user can NOT choose a controlling area (i.e., this program only works for
                companies in controlling area "MIT"), include in the definition of  the selection
                screen (but users will NOT see it):

     PARAMETERS: A_KOKRS LIKE GLPCA-KOKRS NO-DISPLAY DEFAULT 'MIT'.

            2. If the program will work for any company code(s) in any controlling area but the user is
                supposed to make the selection by company code, include in the definition of the selection
                screen (but users will NOT see it):

      PARAMETERS: A_KOKRS LIKE GLPCA-KOKRS NO-DISPLAY.

            3. If the user CAN choose a controlling area, but the user must explicitly select it (rather
                than allowing the program to deduce it from the company code(s)), include in the
                definition of the selection screen:

     PARAMETERS: A_KOKRS LIKE GLPCA-KOKRS OBLIGATORY MEMORY ID CAC

            4. If the user CAN choose a controlling area and the user MAY also leave it blank (to
               allow the program to deduce it from the company code(s)), include in the definition
               of the selection screen:

      PARAMETERS: A_KOKRS LIKE GLPCA-KOKRS MEMORY ID CAC.

    D. Company code: Include either a parameter named A_BUKRS or a Select-Option named
      S_BUKRS in the definition of the selection screen. If the user is allowed to select more
         than one company code, clearly, the select-option must be used.  If only one company
         code may be selected, either approach is allowed.  Whether a parameter or select-option
         is used, you must create a selection text "Company Code" for it.

            1. If the user can NOT choose a company code (i.e., this is a program which only works for
                company code "CUR"), include in the definition of the selection screen (but users will NOT
                see it) either:

             SELECT-OPTIONS:   S_BUKRS FOR GLPCA-RBUKRS
                          NO INTERVALS NO-EXTENSION
                          NO-DISPLAY DEFAULT 'CUR'.
        or:

        PARAMETERS:       A_BUKRS LIKE GLPCA-RBUKRS
                          NO INTERVALS NO-EXTENSION
                          NO-DISPLAY DEFAULT 'CUR'.

            2. If the user CAN choose exactly one company code, include in the definition of the
                selection screen either:

        SELECT-OPTIONS:   S_BUKRS FOR GLPCA-RBUKRS
                          NO INTERVALS NO-EXTENSION
                          OBLIGATORY MEMORY ID BUK.

        or:

        PARAMETERS:       A_BUKRS LIKE GLPCA-RBUKRS
                          NO INTERVALS NO-EXTENSION
                          OBLIGATORY MEMORY ID BUK.

            3. If the user CAN choose one or more company codes, include in the definition of the
                selection screen:

        SELECT-OPTIONS:   S_BUKRS FOR GLPCA-RBUKRS
                          NO INTERVALS MEMORY ID BUK.

    E. Early in the INITIALIZATION event, include the following line:

              INCLUDE ZES_AFTER_INIT_ALWAYS.

               Additionally, if you are using the select-option, S_BUKRS, include the line:

               INCLUDE ZES_AFTER_INIT_FOR_S_BUKRS.

    F. In the part of the program where you have AT SELECTION-SCREEN events, you must include
        two ABAP statements. Please note that each of these statements declares the beginning of
        an event (for example,. "AT SELECTION-SCREEN ON A_KOKRS"). The second of them
        should be immediately followed by another event.

        The first of the two statements is:

              INCLUDE ZES_AT_SEL_SCREEN_ON_A_KOKRS.

        If the parameter, A_BUKRS, is used to select company code, the second statement must be:

          INCLUDE ZES_AT_SEL_SCREEN_ON_A_BUKRS.

        Otherwise (i.e. S_BUKRS was used) the second statement must read:

              INCLUDE ZES_AT_SEL_SCREEN_ON_S_BUKRS .

    G. Early in the START-OF-SELECTION event, one line must be included.  If the parameter,
         A_BUKRS, is used to select company code, this statement must read

              INCLUDE ZES_AFTER_S_O_SEL_FOR_A_BUKRS.

        Otherwise, (i.e. S_BUKRS was used) the statement must read:

          INCLUDE ZES_AFTER_S_O_SEL_FOR_S_BUKRS.
 

II. What is available for your use:

        A.  After the ZES_AFTER_S_O_SEL_FOR_A_BUKRS or
       ZES_AFTER_S_O_SEL_FOR_S_BUKRS  include, the following
      COMMON_ESA- variables and R_ES_ range tables are automatically defined and
             set to appropriate values. If more than one company code was supplied (or implied),
             the COMMON_ESA- variables are set to the appropriate value only if it is common
             to all the company codes - otherwise the COMMON_ESA- variable is left blank.
             (Hence, if only one company code was supplied (or implied) you get some
             additional values.)

            1. Variables set when more than one company code is supplied (or implied):

           Controlling Area           COMMON_ESA-KOKRS (like TKA01-KOKRS)
       Fiscal Year Variant        COMMON_ESA-PERIV (like T009-PERIV)
       Chart of Accounts          COMMON_ESA-KTOPL (like T004-KTOPL)
       Currency                   COMMON_ESA-WAERS (like TCURC-WAERS)
       Consolidation Company      COMMON_ESA-RCOMP (like T001-RCOMP)
       Funds Management Area      COMMON_ESA-FIKRS (like FM01-FIKRS)
       Default Credit Ctrl Area   COMMON_ESA-KKBER (like T014-KKBER)

            2. Additional variables which MAY be set when more than one company code is supplied and
                WILL be set when only one company code is supplied (or implied):

        Country                    COMMON_ESA-LAND1 (like T005-LAND1)

            3. Additional variables set when only one company code is supplied (or implied):

           Company Code              SINGLE_ESA-BUKRS (like T001-BUKRS)
       Company Name (25 chars)   SINGLE_ESA-BUTXT (like T001-BUTXT)
       Company Name (40 chars)   SINGLE_ESA-BUKRS_NAME1
       (like ADRC-NAME1)

            4. Range tables: If more than one company code was supplied (or implied), the  R_ES Range
                    tables are filled with the union of the values from all the company codes.

        Company Code             R_ES_BUKRS       (like RANGE_BUKRS_CO)
       Sales Organizations      R_ES_VKORG       (like SHP_VKORG_RANGE)
       Distribution Channels    R_ES_VTWEG       (like SHP_VTWEG_RANGE)
       Divisions                R_ES_SPART       (like SHP_SPART_RANGE)
       Plants                   R_ES_WERKS       (like RANGE_WERKS)
       Purchasing Organizations R_ES_EKORG       (like EKORG_RANG)
       Personnel Areas          R_ES_PERSA       (like RANGE_C4)
       Personnel Sub-areas      R_ES_BTRTL       (like RANGE_C4)

        B. New function modules - Three new function modules are being provided. Two of them are
             automatically called in the above include files and the results are left in the above variables
             and range tables for your use.

                1. A function module named Z_ES_GET_ENTERPRISE_ATTRIBUTES which
                    returns other enterprise attributes that can be deduced from the ones that you
                    supply in the call.
                2. A function module named Z_ES_GET_ESA_RANGES which returns range tables filled
                    with the values associated with the company/ies that you supply in the call.
                3. A function module named Z_ES_GET_COMP_CODE_ATTRIBUTES that calls the
                    above two function modules. This function module provides a slightly simpler
                    interface when you are dealing with exactly one company at a time.

        C. Company code associated with a cost object: The table ZCOOBJECT has been expanded to
             include the company code associated with each cost object. Two existing MIT-written
             function modules have been modified to return the company code associated with a cost
             object, if the caller requests it. They are:

              1. Z_GET_COST_OBJECT
          2. Z_CO_GET_COST_OBJECT_TYPE

        D. Accessing some of the enterprise attributes:

                1. If you want to know how many companies were selected, you can use the following:

              DATA NUMBER_OF_COMPANIES TYPE I.
          DESCRIBE TABLE R_ES_BUKRS LINES NUMBER_OF_COMPANIES.

                2. If you want to get the enterprise attributes for particular companies, one company at
                    a time, get the company codes from  R_ES_BUKRS-LOW   and call
                    Z_ES_GET_ENTERPRISE_ATTRIBUTES for each one. The structure
                    SINGLE_ESA is a convenient place to hold the results.
                    Your code might look something like this:

         LOOP AT R_ES_BUKRS.

                        "Execute the body of this loop once for each company
                        *  If you need some enterprise attribute values associated with this company
                        *  that are not "common" enterprise attribute values across multiple companies

            CALL FUNCTION 'Z_ES_GET_ENTERPRISE_ATTRIBUTES'
            EXPORTING
              I_BUKRS  = R_ES_BUKRS-LOW
            IMPORTING
              E_PERIV  = SINGLE_ESA-PERIV
              E_KTOPL  = SINGLE_ESA-KTOPL
              E_WAERS  = SINGLE_ESA-WAERS
              E_LAND1  = SINGLE_ESA-LAND1
              E_RCOMP  = SINGLE_ESA-RCOMP
              E_BUKRS  = SINGLE_ESA-BUKRS
              E_FIKRS  = SINGLE_ESA-FIKRS
              E_KKBER  = SINGLE_ESA-KKBER
              E_KOKRS  = SINGLE_ESA-KOKRS
              E_BUTXT  = SINGLE_ESA-BUTXT
              E_BUKRS_NAME1 = SINGLE_ESA-BUKRS_NAME1
            EXCEPTIONS
              CANNOT_FIND_ALL_REQUESTED_DATA = 1
              OTHERS     = 2.

            IF SY-SUBRC <> 0.
              MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
              WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
            ENDIF.

                        As a result of the include files, the R_ES_ range tables are set with the "union" of the
                        values for all the selected companies. If that is appropriate for your program, don"t
                        call Z_ES_GET_ESA_RANGES. If you need range tables associated with one
                        company at a time, you can call the function module Z_ES_GET_ESA_RANGES.
                        If you need range tables associated with one company at a time but you don"t need
                        the "union" range tables, you can overwrite them, as we do in the following code.
                        If you need both the "union" range tables and company-specific range tables, you
                        can store the results in new tables that you defined to be LIKE the R_ES_ tables.

             CALL FUNCTION 'Z_ES_GET_ESA_RANGES'
              EXPORTING
                I_BUKRS  = R_ES_BUKRS-LOW
              TABLES
                R_PERIV  = R_ES_PERIV
                R_KTOPL  = R_ES_KTOPL
                R_WAERS  = R_ES_WAERS
                R_LAND1  = R_ES_LAND1
                R_RCOMP  = R_ES_RCOMP
                R_FIKRS  = R_ES_FIKRS
                R_KKBER  = R_ES_KKBER
                R_GSBER  = R_ES_GSBER
                R_KOKRS  = R_ES_KOKRS
                R_VKORG  = R_ES_VKORG
                R_VTWEG  = R_ES_VTWEG
                R_SPART  = R_ES_SPART
                R_WERKS  = R_ES_WERKS
                R_EKORG  = R_ES_EKORG
                R_PERSA  = R_ES_PERSA
                R_BTRTL  = R_ES_BTRTL
              EXCEPTIONS
                INPUT_PARAMETERS_MISSING = 1
                TOO_MANY_INPUT_PARAMETERS = 2
                OTHERS     = 3.

              IF SY-SUBRC <> 0.
                MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
                WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
              ENDIF.

                            Do the program logic needed for this company here.   The enterprise attributes
                            are in the SINGLE_ESA structure.  If you called Z_ES_GET_ESA_RANGES, you
                            have range table for this company. If you didn"t call Z_ES_GET_ESA_RANGES,
                            you have the range tables for the union of all selected companies.

         ENDLOOP.

III. Other Aspects to Consider:
      The full scope of what else needs to be done will depend on what the program
      is trying to do, which tables it uses and how it uses them.
      For example, if the program uses custom tables, the programmer will have to decide whether
      any enterprise attributes need to be added to those tables (and if so, which attributes).

      A. Use values from the SINGLE_ESA  or  COMMON_ESA structures rather than literals or
          constant for the values of enterprise structure attributes. (This is necessary to make
          a program work for a user-specified company. If you are just making a program work
          for one program-specified company code, it is very desirable, but not strictly necessary,
          to use values from the SINGLE_ESA or COMMON_ESA structures rather than literals or
          constants for the values of enterprise structure attributes.) Note that programs should
          NOT refer to A_KOKRS, A_BUKRS, or S_BUKRS (other than setting up the selection
          screen as described in the first section of this document).  Programs should instead
          refer to SINGLE_ESA-KOKRS, SINGLE_ESA-BUKRS, or R_ES_BUKRS.

     B. In the WHERE clause of SELECT statements, use the appropriate SINGLE_ESA-variable,
          COMMON_ESA-variable or R_ES_ range table to restrict the data to the company/ies with
          which the program is supposed to work. Even if a program is only being made to work with
          one program-selected company code, the WHERE clause must still restrict the data being
          retrieved. In this case, it is very desirable, but not strictly necessary, to use the
          SINGLE_ESA-variable, the COMMON_ESA-variable or the R_ES_ range tables
          for this purpose.

      C. Some programs operate on an externally supplied list of cost objects, documents, or other
          master or transactional data objects. For example, such an external list might be supplied
          via an input file, a spreadsheet upload, or a selection screen. The program should  verify
          that all these externally supplied data objects are associated with the company/ies with
          which the program is supposed to be working.

          In the case of cost objects, that means call either the Z_GET_COST_OBJECT or
            Z_CO_GET_COST_OBJECT_TYPE function module for each externally supplied cost object
          and verify that "BUKRS EQ SINGLE_ESA-BUKRS" (or, more generally,
          "BUKRS IN R_ES_BUKRS"). How the test should be done for other types of data objects,
          depends on the data object. The test should be done using the SINGLE_ESA- variables,
          COMMON_ESA- variables and R_ES_ range tables, so as to make the program easy to
          maintain and extend to other companies or groups of companies.

      D. Most output should show which company it is for. For an internal report, you might just show
           in the header of the report the company code(s) whose data is included. Any business
          document (for example, a Purchase Order or Invoice) which will go to another party should
          show the name of the company from which it was generated. (The variables
          SINGLE_ESA-BUTXT and SINGLE_ESA-BUKRS_NAME1 are 25 and 40 character (respectively)
          fields for the company name.)

      E. Make sure that the correct monetary fields are used. For FI tables, use the monetary amount
          in the company code currency field, sometimes described as the "local currency" field.
          Generally, it is NOT the monetary amount in the field described as "document currency" or
          "transaction currency".   For CO tables, use the monetary amount in the controlling area
          currency field.  For more information, see the section of this document called
      "Choice of Currency Fields".

      F. Determining the relationship between calendar months and fiscal periods: This is not strictly
            necessary for programs that only handle  companies in the "MIT" controlling area, but it is
            a good programming practice. (In addition to the specific function modules cited
            here, other function  modules in the function groups ADAT and FACS may be helpful,
           depending on the situation.)

                1. To convert a calendar date to a fiscal year and period, use function module
                         DATE_TO_PERIOD_CONVERT
                    (or function module FI_PERIOD_DETERMINE).
                2. To convert fiscal year and period to the calendar date of the first day of the period,
                    use function module FIRST_DAY_IN_PERIOD_GET.
                3. To convert fiscal year and period to the calendar date of the last day of the period,
                    use function module LAST_DAY_IN_PERIOD_GET.

In R/3 4.6C, ABAP programs should use the WS_UPLOAD and WS_DOWNLOAD
function modules (rather than the GUI_UPLOAD and GUI_DOWNLOAD function
modules or static methods).

In R/3 6.20 and later, the WS_UPLOAD and WS_DOWNLOAD function modules
are still available, but the GUI_UPLOAD and GUI_DOWNLOAD static
methods of the CL_GUI_FRONTEND_SERVICES class are preferred. New code
that will not be used until after our SAP upgrade should use the
GUI_UPLOAD and GUI_DOWNLOAD static methods of the

CL_GUI_FRONTEND_SERVICES class (rather than the WS_UPLOAD and
WS_DOWNLOAD function modules).

For applications that require dialog programming, the SAP Style Guide should be used as a basis for development. Using this guide for screen design and ergonomics will insure consistency in MIT developed transactions. The SAP Style Guide is available in the help documentation using the following path:  Help -> R/3 Library -> BC-Basis Components -> ABAP Workbench (BC-DWB) -> BC-> SAP Style Guide. Another useful resource is the SAP supplied demo transaction which gives examples (with documentaion) of the standards used in both dialog programming and list generation. The demo transaction BIBS is used for screen painter guidelines. The demo transaction LIBS is used for list output guidelines.

The MIT user community, in general, uses monitors capable of at least 800x600 resolution. Hence, any screen painter development should ensure that all fields are viewable within that screen size. This corresponds to the SAP default screen size of 21 lines by 83 columns. Note that SAP does not include the title, menu bar, status line, and OKCode box in this area.

View Document: MIT-ITS Web Site Standards

Radio Button Groups:

In each radio button group exactly one button in the radio button group must be defaulted to 'X'.

Example:

parameter: p_rb1 radiobutton group grp1 default 'X',
                p_rb2 radiobutton group grp1.

If we did not have the above requirement, and no radio button was defaulted to 'X', then we would get different behavior when the program was run interactively versus being run in the background(when run in the background, no radio button would be set.  When run interactively, the first radio button would be set.)

Accounting document type configuration is maintained as part of the SAP configuration process. As such, you must always confirm any new document types with the configuration team prior to coding a report to access the data.

Also, existing extract programs may need to be modified for the new document type, hence it is necessary to pro-actively notify The Financial Architecture Group < sap-doc-types@mit.edu > of the creation of a new document type. After the new document type is approved, the Financial Architecture Group will communicate the changes to all other necessary parties so that other programs can be modified.

ABAP/4 code is fairly self-documenting. However, it is wise to provide future programmers with documentation. Explain the purpose, design, structure and any testing hints at the top of the program. Maintain a history of modification notes, dated, with the most recent change first. Comment work fields, and fields in work records especially those used for interfacing. Comment all subroutines with their purpose. Comments should explain what the code is doing, not how the code is doing it.

MIT has developed several templates for providing documentation via the ABAP "Program Documentation" function. From the ABAP Editor transaction SE38, you can access the documentation by selecting object component "Documentation" then click "Display", or from within the editor screen by doing Goto -> Program doc. The MIT templates are in the following ABAP programs:

Program	Usage
ZPROGDOC	ABAP/4 Program documentation
ZSYSTDOC	System documentation
ZFUNCDOC	Function Module documentation
ZINCLDOC	Include documentation
ZRPRPDOC	Report Painter report documentation

Note that a "general purpose" include file, or any include file which is not documented in the documentation for an associated main program, should be documented using the "program" template (ZPROGDOC) rather than the degenerate "include file" template (ZINCLDOC). There must be documentation for the code within an include file either in the include file documentation itself (using the long form contained in ZPROGDOC), or in the main program's documentation object (ZPROGDOC). In the case of the latter, the short form contained in ZINCLDOC must be filled out with information which points to the main program.

It is mandatory to complete a documentation template prior to transporting your program to the production system.

In addition to documentation via the templates, brief comments within the code can be very helpful for ongoing program maintenance.  For example, you should document the major steps in the program source, such as:

  do 16 times.  "why are we doing this 16 times instead of 12???
   ...
  enddo.

 For the example of CASE statements, each case value should be documented:

   case <variable>.

    when 'Y'.  "explain what 'Y' actually means
      ...
    when 'H'.  "explain what 'H' actually means
      ...
  endcase.

When modifying a program, to document within the source code, you can use the following convention:
 

*-----------------------------------------------------------------* * This program is Multiple Enterprise Structure compliant * at level 4. * It runs for any selected company code(s) in the MIT "CO" area. * * Purpose: * * *-----------------------------------------------------------------* * Author: * Date: * *-----------------------------------------------------------------* * Revision History: * *   Date     Author      Transport/Description * --------- ---------    ---------------------- * 13-Nov-01  John Doe    SF2K123456 *          1. This is the documentation of one of the revisions  *             made within transport SF2K123456. *          2. This is the doumentation of a different revision *             revision made within transport SF2K123456. *          3. This is the documentation for yet another revision *             made within the same transport. * 06-Jun-00  Jane Doe     SF2K012345 *          1. This is the documentation for a revision within *             transport SF2K012345 *-----------------------------------------------------------------*      DATA: BEGIN OF rec,                          "SF2K900001         ind,                                 "interface type ind.         f1 LIKE MA-IDNRA,                    "material number         f2 LIKE MA-KTX01,                    "material short text         f3(16),            "filler           "SF2K9000000         ...      END OF rec.

This convention is available from the ABAP editor, via the pattern function. Select "DOCU_BLOCK" from the "other pattern" option to paste it into your program.

Always indicate which lines were changed or added by appending the transport (change request) number to the line. (This is the convention used by SAP developers).
 

INSERT D030L-TYPE D030L-DDNAME D030T-DDTEXT D030L-CBNAME        D030L-SEGMENTID D030L-DOCTYPE INTO HEADER. SELECT * FROM D030L WHERE                       "SF2K900001          DDNAME BETWEEN TABLEFR AND TABLETO.    CHECK D030L-DDMODIFY NE USR.    SELECT * FROM Validation Rules D030T WHERE      DDLANGUAGE EQ SY-LANGU AND     DDNAME EQ D030L-DDNAME.   ENDSELECT.    EXTRACT HEADER.  ENDSELECT.

The import and export parameters of function modules should have names beginning with 'I_' and 'E_' respectively. They should be documented with brief descriptions of the fields and their typical contents. Also, any special requirements or usage should be noted. At the minimum, the documentation 'Short Text' should be completed for each parameter. This is found by selecting the 'interface' radio button on the main function module transaction, SE37. From there, click on the 'Documentation' tab.

Because of the nature of the impact of changes in validation rules to the entire SAP system operation, validation rules should only be changed by (or with the permission of) the Validation Rules Team. If you need a new or modified validation rule, do not act unilaterally, instead coordinate with the Validation Rules Team. Any developer who is considering altering a validation rule must send a message to MIT-ABAP@MITVMA.MIT.EDU as early in the development process as possible.  At a minimum this notification must be sent one week before any development is transported to the test and integration system (SF5).

As with changes to validation rules, any configuration changes that alter the "required", "optional", or "not permitted" status of fields, or that remove a field, must be submitted in a mail message to MIT-ABAP@MITVMA.MIT.EDU as early as possible with a minimum of one week notification before transport to the test and integration system.

ABAP/4 Tuning Checklist
The general performance standards above outline ways to increase efficiency from many different perspectives, the following checklist was developed by SAP to quickly review the most common performance problems.   Please note that some of the information may overlap with the general performance section.
Is the program using SELECT * statements?
	Convert them to SELECT column1 column2 or use projection views.
Are CHECK statements for table fields embedded in a SELECT ... ENDSELECT loop?
	Incorporate the CHECK statements into the WHERE clause of the SELECT statement.
Do SELECTS on non-key fields use an appropriate DB index or is the table buffered?
	Create an index for the table in the data dictionary or buffer tables if they are read only or read mostly. Please consult R3-Admin for creation of indexes on or the buffering of SAP supplied tables.
Is the program using nested SELECTs to retrieve data?
	Convert nested SELECTs to database views, DB joins (v4.0), or SELECT xxx FOR ALL ENTRIES IN ITAB. Click here for a discussion on "for all entries".
Are there SELECTs without WHERE condition against tables that grow constantly (BSEG, MKPF, VBAK)?
	Program design is wrong - back to the drawing board.
Are SELECT accesses to master data tables buffered (no duplicate accesses with the same key)?
	Buffer accesses to master data tables by storing the data in an internal table and filling the table with the READ TABLE ... BINARY SEARCH method
Is the program using SELECT ... APPEND ITAB ... ENDSELECT techniques to fill internal tables?
	Change the processing to read the data immediately into an internal table (SELECT VBELN AUART ... INTO TABLE T_VBAK ...)
Is the program using SELECT ORDER BY statements?
	Data should be read into an internal table first and then sorted unless there is an appropriate index on the ORDER BY fields
Is the programming doing calculations or summarizations that can be done on the database via SUM, AVG, MIN, or MAX functions of the SELECT statement?
	Use the calculation capabilities of the database via SELECT SUM, ...
Are internal tables processed using the READ TABLE itab WITH KEY ... BINARY SEARCH technique?
	Change table accesses to use BINARY SEARCH method
Is the program inserting, updating, or deleting data in dialog mode (not via an update function module)?
	Make sure that the program issues COMMIT WORK statements when one or more logical units of work (LUWs) have been processed.

In general, any custom developed programs or objects should be named with the "Z" for the first character. SAP has designated objects beginning with the letters "Y" and "Z" as customer named objects and ensures that this name space will not be overwritten during an upgrade. At MIT, we have started using the convention that objects whose names begin with "Y" are intended for "one time use" and objects whose names begin with "Z" are intended "regular" use.   An example of a program that should start with 'Y' would be a program that was written for the Y2K conversions.   Also, programs that are not intended to be migrated to Production should begin with "Y".

Also, SAP regularly updates the recommended customer name ranges for all development objects. For objects not included in this guide, please consult this SAP-created document. It is located on the SAP OSS system in note #16466.

In R/3 release 3.0F, ABAP report names were limited to 8 characters. In R/3 release 4.6C, ABAP report names can now be up to 40 characters long.

Examples:

• ZARI007     (Cashier Feed Validation Request)
• ZCOR001, or ZCO_MISSING_FUND    (Report CO objects missing funds and/or fund centers)

Examples:

•   ZFCCMTOP      (Credit card TOP Include)
•   ZFCCMF01       (Credit Card FORM include)

Since classification objects and class types are more like programming data constructs than they are like configuration data, MIT naming conventions should be followed when creating new classification objects or class types.   To differentiate between SAP supplied classes and MIT developed classes the prefix 'MIT_' should be used followed by either the SAP data element or a descriptive abbreviation.  For example, when creating a characteristic for a 'Profit Center' where the data element is 'PRCTR' the name would be 'MIT_PRCTR'.  In addition, SAP recommends using only letters from A-Z, digits 0-9, and the underscore character in the name.

Development classes should only be created when a specific new project requires all components to be linked for organizational purposes. Before creating a new development class, please consult with the Technical Services Team <tech-services@mit.edu >. See Appendix C for a list of development classes.

Most SAP system interfaces using flat ASCII files for input or output should use the following directory paths for temporary and permanent interface files.

• To R/3 from an EXTERNAL SYSTEM:       /usr/bridges/[environment name]/sapin/

• To an EXTERNAL SYSTEM from R/3:       /usr/bridges/[environment name]/sapout/

• Files written by one ABAP program and read by another:   /usr/bridges/[environment name]/saptmp/

• Files already used by R/3:            /usr/bridges/[environment name]/archive/

Sample code follows:

data: begin of myfile,          part1(13) value '/usr/bridges/',          part2(15), "dev2 or tst1 or prod          part3(9) value '/saptmp/',          part4(30) value 'flname',        end of myfile.  initialization.   call function 'Z_DETERMINE_FUNC_AREA'      importing        func = myfile-part2      exceptions        unknown_sysid = 1        unknown_mandt = 2.    if sy-subrc eq 0.      condense myfile no-gaps.    endif.

Function Groups are named using the following convention:

For example, ZBR0 is the function group for application "BR" for "Bridges" and number "0" sequentially. Before creating a new function group, please consult with Technical Services.

Function module names should be as descriptive as possible given that there are 30 characters available for naming. They should be formatted as follows:

In the special case of function modules which are used as check modules for external commands, their names follow different rules. Such function modules should be created in the function group "SAPLZEXT_CMD_CHECK_MODULES" and given names of the form "Z_CK_EXTCMD_<external-command>" (where <external-command> represents the actual name of the External Command whose invocation is checked by this function module before the External Command is executed).

Module pools should be named as follows:

Module pool includes should be named as follows:

Introduction

ABAP Objects' namespace validity is very complex. In order to avoid problems during
development it is not only helpful but also necessary to outline name conventions
for that matter.

Classes and their dependent subclasses share the same namespace which affects

        Constants (CONSTANTS) ,
   Variables (DATA, CLASS-DATA) ,
   Methods (METHODS, CLASS-METHODS) and
   Events (EVENTS, CLASS-EVENTS).

SAP has not yet decided whether to allow upper/lower case for internal names (to separate individual words - as in JAVA). Therefore in order to do that we still have to use the underscore character.

Naming Conventions

General rules:

• Always use meaningful English terms for naming objects.
• Use glossary terms whenever possible.     For example: ZCL_COMPANY_CODE,  instead of  BUKRS, as this will be SAP"s standard in the futue (see  BAPIs)
• Where names are grouped together use the '_' as a separator.   For example: ZCL_COMPANY_CODE, ZCL_GENERAL_LEDGER_ACCOUNT

• Names should describe what the subject is not how it is to be implemented.   For Example: PRINT_RECTANGLE and not RECTANGLE_TO_SPOOL.

Objects marked with * are protected by the global TADIR, but they occupy the same namespace as data elements, tables, structures and types.

Class Conventions

Method Name	<method name>   The method name should begin with a verb.    GET_STATUS, CREATE_ORDER,    DETERMINE_PRICE
Event	<event name>   Event names should be named like this:    <Noun>_<Participle of Verb >.    BUTTON_PUSHED,    COMPANY_CODE_CHANGED,    BUSINESS_PARTNER_PRINTED
Local Class Type Definition	<type name>_ty   INTERNAL_TYPE_TY,    TREE_LIST_TY
Data Definition (Variable)	<variable name>   You should avoid using verbs at the beginning when naming    variables within a class (CLASS-DATA, DATA).    (This is to prevent confusion with method names.)    LINE_COUNT, MARK_PRINTED,    MARK_CHANGED, STATUS
Data Definition (Constants)	C_<constant name>   C_MAX_LINE,    C_DEFAULT_STATUS,    C_DEFAULT_WIDTH,    C_MAX_ROWS

Fixed Method Names

Attribute Accesses	SET_<attribute name>,   GET_<attribute name>   You should prefix all types of attribute access with GET_    or SET Accordingly,    GET_STATUS,    SET_USE_COUNT
Methods that Deal with an Event	ON_<event name>   For methods that deal with an event, you should begin the    name with ON followed by the name of the relevant event.    ON_BUTTON_PUSHED,    ON_BUSINESS_PARTNER_PRINTED
Methods that carry out Type Conversions	AS_<new Type>   AS_STRING,    AS_ISOCODE
Methods that deliver a Boolean Value   These methods cannot return    any EXCEPTIONS.    Recommendation: The    Boolean value should be    represented by SPACE/"X" for    False/True.	IS_<adjective>   IS_OPEN, IS_EMPTY,    IS_ACTIVE
Check Methods   These methods differ from the    IS_<adjective>" methods by    their ability to return    exceptions.    CHECK_AUTHORIZATION,    CHECK_PROCESS_DATE	CHECK_<objective>   CHECK_AUTHORIZATION,    CHECK_PROCESS_DATE

Method Conventions

The parameters are observed from the point of view of the methods, which implemented them:

IMPORTING-Parameter	IM_<parameter name>
EXPORTING-Parameter	EX_<parameter name>
CHANGING-Parameter	CH_<parameter name>
RESULT	RE_<result>
EXCEPTIONS	See "Exceptions"

Exceptions
The developer"s job is made easier when standards for the naming of exceptions are available. The following is a table of meaningful exceptions, which can also be used generically.
(Example: ...NOT_FOUND could become DATE_NOT_FOUND)

EXCEPTION	MEANING
ACTION NOT SUPPORTED	The requested action or the requested OK-Code is not supported
CANCELLED	This EXCEPTION can be set if the user is required to select what happens next in a method (for example: Selection List) and he/she selects "Cancel".
EXISTING	A new object already exists in the database.
FAILED	The methods could not carry out your task because of the present state of the environment. This exception is especially intended for cases where the environment is temporarily in a situation that does not allow the method tasks to be carried out.
..._FAILED	A sub function of the method could not be carried out because of the present state of the environment. (OPEN_FAILED, CLOSE_FAILED, SELECTION_FAILED, AUTHORIZATION_FAILED)
FOREIGN_LOCK	Other users lock data.
INCONSISTENT	Object data in the database is inconsistent.
..._INCONSISTENT	The sub-object data of an object in the database is inconsistent.
INVALID	The object data entered is not correct. (e.g. Company Code is not available) (in contrast to NOT_QUALIFIED)
..._INVALID	The given sub-object data of an object is not correct. (In contrast to NOT_QUALIFIED)
INTERNAL_ERROR	The last resort. If all else fails and the error can no longer be contained, apply this EXCEPTION.
NOT_AUTHORIZED	The user does not have authorization for this action.
NOT_CUSTOMIZED	The object requested is not correctly customized.
..._NOT_CUSTOMIZED	The sub-object of the object requested is not correctly customized.
NOT_FOUND	The requested object has not been found.
..._NOT_FOUND	The sub-object of the object requested has not been found.
NOT_QUALIFIED	The combination of input parameters is not sufficient to allow the method"s functions to be carried out. (In contrast to INVALID)
..._NOT_QUALIFIED	A specific parameter of the method is not qualified
NUMBER_ERROR	Error in the provision of numbers.
SYSTEM_ERROR	This exception can be set where the Basis System registers an unexpected error code.

Please note:
SAP Basis Technology is presently implementing class-based exception handling like we have in JAVA. The error classes – from the development point of view a welcome simplification of error handling, which is clearly preferred – should then replace EXCEPTION-handling as we use it now. This will however not be available for 4.6c. A standardized usage of the EXCEPTIONS named above will simplify the move to this error class and allow a part-automated move.

ABAP: Passing unknown table structures into functions

This new class-based exception handling is scheduled to be implemented and delivered with Basis Rel. 6.10 as part of R/3 Core release 4.7 (R/3 Enterprise). Availability not before Q2 2002.

Typically function modules must specify the exact structure of each parameter they are passed, hence runtime structures cannot be handled easily in normal function module creation. However, by using the ABAP programming construct ASSIGN COMPONENT idx OF STRUCTURE record to <FS>, a function can determine the structure of a record. For an example of how to develop a function to do this refer to function Z_LIST_SELECT_OPTIONS which reads the structure of a RANGES table in a SELECT-OPTION parameter.

Support for one and two-dimensional arrays within ABAP is provided through the use of internal tables.  However, in the case of a 3-dimensional array, ABAP has no native programming constructs.  While a method could be devised to index a 3-dimensional array via internal tables, the following code fragment demonstrates an alternative approach using field symbols as pointers into data structures:

* This code fragment illustrates the use of a field symbol * and an ASSIGN statement to get the effect of having * multi-dimensional subscripted arrays. There are several * costs of this method. One is performance and the other * is that EVERY cell in the multi-dimensional array * must be declared in a DATA (or CONSTANT, etc.) statement * at the beginning of the program. * Using this method, you would have to have DATA statements * like the following four for EACH CELL of the  * multi-dimensional array.   DATA: VARA_001_005_006(11) VALUE 'Some value!'. DATA: VARA_002_005_006(11) VALUE 'Other value'. DATA: VARA_003_005_006(11) VALUE 'Next value!'. DATA: VARA_004_005_006(11) VALUE 'The target!'.   DATA: BEGIN OF POINTER,         STEM(5) TYPE C VALUE 'vara_',         PART1(3) TYPE N,         SEP1(1) TYPE C VALUE '_',         PART2(3) TYPE N,         SEP2(1) TYPE C VALUE '_',         PART3(3) TYPE N,       END OF POINTER.   DATA POINTER_DEFAULT(11) VALUE 'The default'.   FIELD-SYMBOLS: <INDIRECT>.   * This is the example of using the multi-dimensional array in * the body of a program. You would have to have use something * like the following PERFORM for each change to the * subscripts in a reference to the multi-subscripted variable. PERFORM ASSIGN_POINTER_3 USING 'vara_' 4 5 6. WRITE: / 'Indirectly referencing through pointer,           we get:', <INDIRECT>.   PERFORM ASSIGN_POINTER_3 USING 'vara_' 10 11 12. WRITE: / 'Indirectly referencing through pointer,           we get:', <INDIRECT>   PERFORM ASSIGN_POINTER_3 USING 'vara_' 1 5 6. WRITE: / 'Indirectly referencing through pointer,           we get:', <INDIRECT>. FORM ASSIGN_POINTER_3 USING STEM SUB1 SUB2 SUB3 .   POINTER-STEM = STEM.   POINTER-PART1 = SUB1.   POINTER-PART2 = SUB2.   POINTER-PART3 = SUB3.     ASSIGN (POINTER) TO <INDIRECT>.   IF SY-SUBRC <> 0.     ASSIGN POINTER_DEFAULT TO <INDIRECT>.   ENDIF. ENDFORM. " ASSIGN_POINTER_3

Type coercion is typically defined as the means to force a variable of one type to be another type.  In ABAP programming, type coercion is most useful for the ASCII conversion of character data.  The following code fragment is an example of coercion which outputs ASCII character data:

data: begin of hex,         byte type x,       end of hex. data: char type c. data: temp like sy-index. do 224 times.  temp = sy-index + 31.    hex-byte = temp.    char = hex.    write: / 'Decimal =', temp.  write:   'Hex     =', hex-byte.  write:   'View    =', char. enddo.

When writing BDCs that read dates to be entered into SAP transactions (either by generating batch input sessions or by using call transaction) problems occur when determining what date format to use when entering the data into its corresponding field. Assume that the ABAP program that must call the transaction (or generates the batch input session) can read the 'date' field properly from the input file, but it does not know which format the data entry screen of the transaction requires as this may change based on the user"s setup defaults.

The current best approach to solving this problem is:

1. Declare a date variable in the interface program to be LIKE SY-DATUM.
2. Then, store the date (read from the input file) in the date variable in the correct internal form (YYYYMMDD).
3. Write that date variable to a character string variable.
4. Use the character string variable as the value of the date field in the transaction screen

When writing BDCs that read numbers to be entered into SAP transactions (either by generating batch input sessions or by using call transaction) problems occur when determining what number format to use when entering the data into its corresponding field. Assume that the ABAP program that must call the transaction (or generates the batch input session) can read the 'number' field properly from the input file, but it does not know which format the data entry screen of the transaction requires as this may change based on the user"s setup defaults.

The current best approach to solving this problem is explained by the following example code:

* Assume we have a numeric value in the variable "Amount" and we * want to format it into the variable "String" for entry into a * transaction field. data amount like bseg-wrbtr. data string(20). data temp(2). write amount to string currency 'USD'.   * String+19(1) is a possible minus sign * String+17(2) is the number of cents * String+16(1) is the decimal point * String+13(3) is the three digits to the left of decimal * String+12(1) is a possible thousands separator temp = string+12(1). " String is 20 chars. 20 - 8 = 12 * If there are any thousands separators, change them to spaces. if temp(1) cn '0123456789'.   translate string using temp. endif. * Remove any spaces condense string no-gaps.

Prior to our 4.5B upgrade, we had programs and interfaces which converted MIT legacy cost objects and accounts to the corresponding SAP account or object. Two custom MIT function modules were developed for use in this conversion process. We are no longer converting from the legacy system to SAP. The function modules have been modified so that they will raise an exception if asked to convert from the legacy architecture. As code is modified, calls to these function modules should be removed. The names of these function modules are Z_GET_COST_OBJECT and Z_GET_GL_ACCOUNT.

Often it is necessary to execute an external program as part of an ABAP program, however, you should be very careful in doing so because any external command is executed as the UNIX user <SID>adm. For example, if a program is written to call the command "rm" on the development system it is executed at the system level as the user "sf2adm".

For an example of how to call UNIX system commands, look at program ZUNIXCMD on system SF2. Remember, you can call external programs either synchronously so that your ABAP program will wait until they complete before continuing, or you can call them asynchronously so that your ABAP program will continue execution immediately.

Earlier programs written at MIT used the "CALL SYSTEM" command. In the future, this command should not be included in any new programs and should be removed from existing programs when they are revised.

The following two-character abbreviations are used to identify certain projects or modules when naming programming objects. . (Note that SAP has associated many two-character codes with specific application areas, even though they do not appear in this list.)

Please do not use any code not listed here, and do not use a code for any application area other than the one associated with the code in this list.

If you have an application area which is not listed here, please discuss the situation with Technical Services Team Leader. He will talk with you and either determine that your project should be classified as belonging to an application already listed here, or (after checking SAP-assigned codes) he will assign a new code for the new application area.

2-Character Abbr.	Application Name	Devel. Class- MIT	Devel. Class- Lincoln
AA	Asset Accounting	ZKG0	.
AC	Accounting General	.	.
AP	Advanced Planner and Optimizer	ZAP0	.
AR	Accounts Receivable	ZAR0	.
AU	Authorization Checks	ZSB0/    ZR30	.
BC	Basis Components	.	.
BD	Broad Institute	ZBD0
BP	Buy-Pay Process (incl. Purchasing)	ZSC0/    ZUT0/    ZSB0	.
BR	Bridges / Infrastructure	ZBR0	.
BU	Budget (SAPBud)	ZBUD0	.
BW	Business Information Warehouse	.	.
CA** CS	Cashier's Office	ZCS0	.
CA	Cross-Application Components	.	.
CD	Change Documents	.	.
CK	Ckeck Modules (see the section on "Check Modules for External Commands")	ZUT0	.
CO	Controlling	ZKG0	.
CS ** CU	Customer Service	.	.
EC	Enterprise Controlling (or Electronic Commerce)	.	.
EH	Environment, Health & Safety	ZEH0	.
EP	Internet Portal	ZEP0
ER	Extended Relationship Management	.	.
ES	Enterprise Structure	ZES0	.
FC	(MIT) Credit Card	ZCC0	.
FF	Funds Center	ZFF0	.
FI	Financial Accounting	ZGL0	.
GL	General Ledger	ZBR0	.
HR	Human Resources	ZHR0	.
IM	Investment Management	.	.
IS	Industry-Specific Components	.	.
KM	SAP Knowledge Management	.	.
L*	Labor Distribution System	ZLD0	.
LE	Logistics Execution	.	.
LO	Logistics - General	.	.
MM	Materials Management	.	.
MP	mySAP.com Marketplace	.	.
MS	Mobile Sales	.	.
PA	Personnel Management	.	.
PE	Training and Event Management	ZPE0	.
PM	Plant Maintenance	ZPM0	ZLCP1_PM0
PP	Production Planning and Control  (or Physical Plant)	ZPP0	.
PS	Project System	ZSB0	.
PT	Personnel Time Management	.	.
PY	Payroll Accounting	ZPY0	.
QM	Quality Management	.	.
R3	MIT Basis	ZR30	.
RE	Real Estate Management	ZRE0	.
RQ	Requisitions	.	.
SD	Sales and Distribution	ZSB0	.
SE	Strategic Enterprise Management	.	.
SV	Service	.	.
TR ** TY	Treasury	.	.
TR	Travel	ZTR0	.
TS	Time Sheet (CATS Related)	.	.
UT	Utilities and Tools	ZUT0	.
WF	Workflow	ZWF0	.
WH	(MIT) Data Warehouse	ZWH0	.
WP	mySAP.com Workplace	.	.
XX	Miscellaneous	.	.
	IMG Documentation	.	ZLCP1_IMG

**   should NOT be used for new programs created after October 1, 2001.

SAP Repository objects are classified according to development classes. It is recommended that functionally related objects (such as programs, dictionary components, message classes, etc...) be grouped together by development class. For example, code development for Accounts Payable would be in development class ZAP0. This structuring of the SAP object repository facilitates the control and recording of development efforts.

Please consult with Technical Services Team < tech-services@mit.edu > regarding the creation of new development classes or the uses of existing classes.

DEVEL. CLASS	DESCRIPTION
Z001	Customer Development Class
ZAP0	Accounts Payable
ZAR0	Accounts Receivable
ZBC404	ABAP Object Class
ZBD0	Broad Institute
ZBF0	Business Framework Architecture: Customer Development
ZBFA	Business Framework Architecture
ZBP0	Buy/Pay
ZBR0	Bridges and Feeds
ZBR1	ABAP Bridges and Feeds
ZBUD0	Budget project (SAPBud)
ZCC0	Credit Card Processing
ZCS0	Cashier Office
ZCT0	Computer Aided Test Tools
ZED0	EDI
ZEH0	Environment, Health & Safety
ZEP0	Internet Portal
ZES0	Multiple Enterprise Structure
ZEI0	EIS
ZFF0	Fund Center: custom development
ZFX0	Field Exits: Customer Development
ZGL0	General Ledger
ZGN0	General/Miscellaneous
ZHR0	H/R Application: Customer Development
ZIF0	ITS Financial
ZKA0	Availability checking in CO
ZKG0	Controlling
ZLD0	Labor Distribution System
ZPE0	Training and Events Management
ZPM0	Plant Maintenance
ZPP0	Physical Plant
ZPY0	Payroll Accounting (Employee and Pension)
ZR30	R/3 Administration
ZR31	R/3 Administration: SAP Tools/Development
ZRE0	Real Estate Management: Customer Development
ZRF0	Remote Function
ZRV0	Technology Review Development
ZSB0	Sponsored Billing
ZSC0	SAPScript/Word Processing
ZSL0	Sloan School Support
ZSP0	SPO Legacy Link Program Product
ZTR0	Travel
ZUS0	SPO Bridge Development Program Product
ZUT0	Tools & Utilities
ZUT1	Tools & Utilities for EDI
ZWB0	SAP Workbench Training: Instructor
ZWB1	SAP Workbench Training: Workshop
ZWF0	SAP Business Workflow
ZWH0	Data Warehouse
ZZZ0	Obsolete Programs

Notes:

• The development class Z001 is an SAP example and it should not be used to classify MIT objects.
• The Development classes ZBR1, ZGN0, and ZSPO are obsolete and should not be used to classify any new development object.
• The Development classes ZWB0 and ZWB1 are meant to be specific to objects related to MIT's ABAP workshops. Such objects should not be transported into our test, production, or training environments.

Very rarely, a business scenario arises for which the most viable solution is to write code that directly updates SAP table data ("Direct Update") or to make a modification to SAP source code ("Mod"). Our rule is to avoid doing either. Below is process for a developer to follow if he/she facing a situtation where a Direct Update or Mod is needed:

1. Prepare the business justification as to why a Direct Update to an SAP table or Mod to SAP code is needed.
2. Identify the risks of doing the Direct Update or Mod.
3. Identify alternatives.
4. Analyze the impact & cost of not doing the Direct Update or Mod.
5. Make the presentation to the Technical Services Team Leader.
6. Depending upon the scope of the Direct Update or Mod, further approval might be required by AD-Leadership Team, Director or VP of IS&T.