When most businesses implement the Project System (PS) module, the fields available in the project master data are not sufficient to cover their business needs. One common workaround is to use an existing field in the master data for a purpose other than what was intended.

However, this option has disadvantages. The field description does not fit the purpose of the field, search helps (formerly known as matchcodes) might be unavailable, and the user entry is not validated. An unused field with the right length and data type is often not even available.

Standard SAP PS delivers better alternatives. I will describe the various options you have to add fields to the project master and the steps to implement them.

All options I will discuss do not require a modification in the system because they are based on customizing settings and user exits. This allows for easy future upgrades. In addition, all options are independent of the transaction your company uses to maintain the PS master data. The new project builder transaction CJ20N, which incorporates all functions to create, maintain, and display project definition and work breakdown structure (WBS) elements (introduced in Release 4.6A), is supported. Previously used transactions for project definitions (transaction codes CJ06, CJ07, and CJ08) and WBS elements (transaction codes CJ01, CJ02, and CJ03) are also supported.

You have three options to add new fields to the master data:

• Partner functionality
  
  
• User-defined fields
  
  
• Customer-specific fields

These fields help you to store your data in the system but are not useful unless you are able to access them in reporting. The sidebar, "Integration of Added Fields into Reporting," on page 20 describes how to make the fields available for reporting.

Partner Functionality

The partner functionality is the most well known of the three options. It is used not only in PS but also in the sales orders of R/3 Sales and Distribution (SD) and purchase orders of R/3 Materials Management (MM). Partners represent organizations or individuals that are part of your business processes. Examples are sold-to party, ship-to party, credit representative, or manufacturer.

Partners can be linked to the project definition and the WBS elements. You may assign as many partners as you want.

Each partner is assigned in the Funct field under the Partner tab – in this example, the partner functionality is ZC Controller and the partner number is 120. (Figure 1.) This partner function indicates to the system which type of master data you want to refer to. The partner function can be linked to a master data table that could include customer, vendor, employee, or user record information. The partner function also indicates what group of partner it is. For instance, both sold-to and ship-to are linked to the customer master, but are used in different ways and therefore distinguished by the partner functionality.

Figure 1

Assign ZC Controller to project definition

Since the partner function links to a master data table — in my example the employee master record — search helps are automatically available. Search helps are important to your user community's acceptance of the system, since they ease the process of selecting the correct field value. They also limit the number of errors since the user is restricted to the available field values. SAP comes equipped with the most common partner functions, but new ones can be created as needed, as shown in Figure 1.

The implementation is simple. All you have to do is to define the new partner function in customizing. Refer to the sidebar, "How to Implement New Partner Functionality," which contains an explanation of how to define and assign a new partner functionality. The master data tables to which you can refer are the biggest restriction to the usability of the partner functionality. If you are looking for a field that refers to data other than the customer, vendor, employee, or user (plus some less important tables), then the partner functionality is no help because partner functions are intended to link to business partners, not objects.

An example of a new partner function I usually define is the project controller, the employee of the controlling department who supports the project. Do not confuse the project controller with the project manager (who is responsible for the whole project).

User-Defined Fields

User-defined fields are predelivered by SAP for customer-specific purposes. They are already a part of the master data table of the WBS elements— table PRPS. They range from USR00 to USR11.

The fields have different data types. Figure 2 shows the data dictionary declaration of these fields. Unfortunately, those fields are only available within WBS elements. They are not available in the project definition. The project definition is stored in table PROJ. SAP did not incorporate any user-defined fields in PROJ.

Figure 2

Data dictionary definition of user-defined fields in the WBS element

The description of the fields on the input screens can be defined in the customizing. Use customizing transaction OPS1 and select the field key you assigned to your projects in the project profile. On the next screen, enter the field description you would like to see on the screen. (Figure 3.)

Figure 3

Define user fields

Since the data declaration of the fields was defined by R/3, the length of those fields cannot be changed in the data dictionary or on the screen without modification. No search helps are available for the user to get an overview of the allowed field entries.

Nevertheless, you have two possibilities to check the user entries. You can either use a validation rule (maintained in transaction OPSI) or a user exit that R/3 offers for this purpose. The enhancement is called CNEX0001.

All these fields can be displayed without further customizing and enhancement in SAP cost element reports (using Report Painter/Report Writer). To use these fields in the hierarchy reports (using drill-down reporting), the fields have to be added to the reporting structure on which the reports are based.

Customer-Specific Fields

Unlike user-defined fields, customer-specific fields are not predelivered by SAP. The necessary fields are individually defined and assigned to the PS database in an append structure.

An append structure is an extension of a standard R/3 table. It allows you to add fields to a standard table without modification. Append structures are empty in the R/3 standard delivery. The data declaration of the fields within the append structure is done by the R/3 customer.

In addition, R/3 provides the necessary user exits to add an additional subscreen to the project builder and to transfer the user entries into the database.

It is possible to add new subscreens and fields in WBS elements as well as in the project definition. Also, since the programmer exclusively defines the fields in the database, it is possible to add a search help to these fields.

Reporting on those fields has the same restrictions as user-defined fields. Table 1 shows the similarities and differences among user-defined and customer-specific fields and partner functions.

You should decide on a case-by-case basis which option to use. If you have to add a simple text field, a quantity, date, or check box, then you should use a user-defined field because these values do not need a search help. A drawback is the length of the text field – 20 characters long. If this is too short, you have to use customer-specific fields instead.

If you need a field referencing your customer, vendor, user, or employee master data, create a new partner function. If you need an additional field that should offer search helps but does not fall under the partner category, add a customer-specific field. Although customer-specific fields require more time to implement, they offer the best functionality. Next, I will show you how to incorporate customer-specific fields into the project master data.

Incorporating Customer-Specific Fields into Master Data

SAP delivers the following customer enhancements to define the customer-specific fields:

• Enhancement CNEX0006: customer-specific fields in the project definition
  
  
• Enhancement CNEX0007: customer-specific fields in WBS elements
  
  
• Enhancement CNEX0003: customer-specific fields for standard project definition
  
  
• Enhancement CNEX0004: customer-specific fields for standard WBS element

Figure 4 on the next page shows an overview of the components assigned to enhancement CNEX0006.

Figure 4

SAP enhancement CNEX0006

I will explain how to add customer-specific fields using an example of a software development company. The company develops customer-specific programs based on different standards. Let's say this company has two standard programs, CRM1000 and CRM2000. Therefore, the company is interested in recording which standard program was used as a basis for the customer program.

Since no standard SAP field is available, you must add a customer-specific field in the project definition. The design of customer-specific fields in the WBS elements and in the standard projects works in the same fashion.

1. Extend the project tables in the data dictionary. The information that the user enters in the project maintenance transaction has to be stored in the database. Therefore, fields have to be defined that keep this information. You must add those fields to the data dictionary definition of the PS master data tables (SE11). R/3 has append structures in its tables to do this without modification. Fields that are added to the project definition have to be added to database table PROJ in append structure CI_PROJ. (Figure 5.) Also, fields to be added to the WBS elements need to be added to table PRPS in append CI_PRPS. Don't forget to define and assign check tables where needed.
   
   
2. Add customer-specific screen area to the project builder transaction. Define the subscreen for the PS master data transaction. Create an enhancement project with transaction CMOD. Assign SAP enhancement CNEX0006, as shown in Figure 6. Select screen exit SAPLCJSS0205_CUSTSCR1_SAPLXCN10600. Under Screen type, choose Subscreen. Under Other attributes, enter 600 in the Next screen field.
   
   Now define and position the fields as needed on the subscreen using the layout function. In my example, the only field added onto the subscreen is the field Product. The easiest way to define its data type and length is to refer to a data structure defined the same as database table PROJ.
   
   Define the data structure PROJ as a global variable in customer include ZXCN1TOP using the tables statement (Figure 7). ZXCN1TOP is included in LXCN1TOP, which in turn is part of SAPLXCN1, the main program of the function group XCN1 – PS Customer-Exits.
   
   
3. Define function exits to transfer the customer-specific field values into the database fields and then back again. When the user saves a project in the project builder transaction using codes CJ20N or CJ01-CJ08, the values that were entered in the customer-specific fields defined in step 2 must be transferred into the database fields defined in step 1. Conversely, when the user calls up the project builder transaction for this project the next time, the screen fields have to be filled again with the latest values of the database tables.
   
   SAP offers function exits to transport the data between the screen fields and the database:
   
   • EXIT_SAPLCJWB_002 is for transferring data from the database into the program    fields
   
   • EXIT_SAPLCJWB_003 is for transferring data back from the project builder    transaction into the database

Figure 5

Definition of customer-specific fields in append structure CI_PROJ

Figure 6

Screen definition project builder in enhancement CNEX0006

Figure 7

Define the data structure PROJ

Tip! When you add fields to the WBS elements, make sure that the WBS element screen appears in the project master data. That's necessary since in contrast to many other master data areas like customer master and material master, PS offers a flexible way to customize the screen layout in the project builder. The screen fields are assigned to detail screens. Multiple detail screens may appear on one tab (e.g., Figure 1 shows tabs for Control data, Administration, etc.). You define in customizing which tabs the project builder will show and which detail screens will appear on each tab.

Don't forget to assign the screen that contains your customer-specific fields to a tab! If this link is missing, the screen is not shown at all.

To ensure that the screen is shown, go to customizing function Include User-defined detail screen in the IMG menu path Project structure>Operative structures>Work Breakdown Structures>User interface settings.

Make sure that screen 1215 is assigned to a screen number. In standard delivery, screen 1215 is already assigned to screen 19. Note the screen number and switch to customizing setting Define layout of WBS element detail screens, which is directly located in the customizing tree. Make sure that the screen number is assigned to one of the tabs. (Figure 8.)

Figure 8

Assigning customer-specific subscreen to tab strip

Let's start with the programming of EXIT_SAPLCJWB_002. Add the simple line of code move-corresponding sap_proj_imp to proj. to include ZXCN1U11. (Figure 9.)

Figure 9

Code for include ZXCN1U11

This ABAP statement in the function exit is executed when the user calls up the project definition within the project builder. Before the execution, the system reads the project definition from the database (table PROJ) into its memory. From there, it passes into the function exit through the import parameter SAP_PROJ_IMP. The ABAP statement above moves the fields of the table into the data structure PROJ, which is used for the screen fields. (See step 2.)

Next, you transfer the data back from the project builder transaction into the database. Function exit EXIT_SAPLCJWB_003 has to be used. This exit is called after the user hits SAVE. It transfers the content of the screen fields into the database. Therefore include statement move-corresponding proj to sap_proj_imp into include ZXCN1U12.

This concludes the definition of customer-specific fields. Simply activate the function exits and subscreens as well as your customer enhancement project. The next time you call the project builder, the customer-specific field PRODUCT will show up in tab Cust. Enhancement. (Figure 10.)

Figure 10

Customer-specific field Product on Cust. Enhancement tab in Project Builder screen (transaction CJ20N). Screen shows assigned search help.

Integration of Added Fields into Reporting"
After adding new fields into the master data, you must incorporate them into reporting.

SAP offers various types of reporting tools in PS. These include:

• • Structure overview
  
  
• Hierarchy reports (using drill-down reporting)
  
  
• Cost element reports (using Report Painter/Report Writer)
  
  
• Line item reports

Depending on the strategy you choose to incorporate the new fields and the report type, the fields may be automatically available in reporting or you may have to define a user exit to make them available.

If you used user-defined fields, you don't have to do anything. Since these fields are predelivered by R/3, they are already incorporated into all the reporting tools. If you used customer-specific fields, these fields are available for cost element reports immediately. (Figure 1.) However, customer-specific fields are not automatically available in structure, hierarchy, and line item reporting.

Structure Reports

To make the customer-specific fields available to the structure reports, you have to run program RCNCT001. This program adjusts the necessary report structures. After the program runs, the fields are available in the reports.

Line Item Reporting

Customer-specific fields are added to line item reporting in three steps.

1. First, the fields have to be added to structure KAEP_COAC. To do that, use include CI_RKPOS. If you want to show the field value and also the text assigned to it, you have to do that by defining two separate fields in structure KAEP_COAC — one for the field value, one for the text.
   
   
2. The fields must be read from the database and transferred to include KAEP_COAC. This happens when the line item report runs. SAP delivers enhancement COOMEP01 for this purpose. Within this enhancement, you will find multiple user exits, one for each type of line item report (i.e., actual data and plan data). For example, user exit EXIT_SAPLKAEP_001 is used for line item report on actuals.
   
   In the user exit, you will find structure CS_RECORD. This structure contains all fields included in structure KAEP_COAC. (See step 1.) The field you added to this structure is empty. You have to fill it with the corresponding value of the respective project table (in my example, the field product in the project definition PROJ). Read the project definition table PROJ and transfer the field value into structure CS_RECORD.
   
   
3. The last step is to add the field with its technical information to view V_TKALV. Use transaction SM34 to maintain this view. All fields defined in this view appear in the list of available fields in the line item report. Enter the field structure name KAEP_COAC in Field catalog information, the name of the added field in Field name, and K in Field group assignment. (Figure 2.) In the Text fld column, enter the name of the related text field. Consult SAP note 325546 for additional information on how to fill the table. As a result of these steps, the customer-specific fields show in the field list of the line item reports in transaction CJI3. (Figure 3.)

Hierarchy Reports Using Drill-Down Reporting

The steps are basically the same as for the line item reporting. Extend structure RPSCO_X in append CI_RPSCO_X. Use enhancement KAP10001 and user exit EXIT_SAPLPS01_002 to fill in the fields you want to add to the structure. In the last step, maintain the field catalog in table TKAF. Refer to SAP note 454509 for further details.

Partner Function

To make the newly defined partner functions available in reporting, follow the same steps shown for customer-specific fields.