OBJECTIVE OF THE DOCUMENT

The modules involved in logistics in SAP are tightly integrated between each other and works
seamlessly in an organization. The module which aligns centrally to all the logistics modules in the
planning, execution and management of capacities, resources and costs is Project System popularly
called as PS. In the light of this, it is very much important for consultants to know various elements of
the project and how these elements are related to each other. Knowing the project structure and its
elements along with the database tables will help the consultants to devise customized reports for
various scenarios suiting to individual projects.
This document contains
Database tables for each of the project elements
Connecting link between various database tables
This document does not contain
Detailed information about the elements of project though it is precisely mentioned for the
purpose of understanding
Costing related data as my knowledge level is very less in this area
Detailed information about the module as such and the processes involved
Transaction codes for all the project elements. However it is included wherever possible.
This document explains the logic only around the functionalities enabled in PS system, but not in any
other modules like PP or PM. Even in those modules some of these tables may be used, but the logic
mentioned here explains the usage, logic and joins between these tables only in the perspective of PS.

ELEMENTS OF PROJECT AND THEIR TABLES

A project is initiated with the intention of creating a unique purpose; it can be a product a service or
combination of both.
In order to manage the project, the project is subdivided into various small deliverables called WBS
elements or Work Breakdown Structures. Each such deliverables can be used to plan costs and
revenues, resources and capacities.
In some cases, the projects are

PROJECT
Project is at the highest level and WBS elements are networks are subordinates of the project. The
costs are revenues at the network or WBS level will finally accrue as the cost and revenue of the
project.
The database table which contains the relevant information about the project is PROJ. In this table the
field PROJ-PSPNR represents the project number. There is also another field PROJ-OBJNR is an
important field as this field serves as the foreign key for making any queries at the project level. This is
the key field for finding the status of the project. The method to find out the status of the project is dealt
in the later part of the document.

WBS ELEMENTS
A project can have many WBS elements assigned to it. The details pertaining to the WBS elements
are available at the database table PRPS. The table has the field PRPS-PSPNR has the WBS element
number. The project related to the WBS element can be obtained from the field PRPS-PSPHI. Hence
using this field all the WBS elements assigned a project can be easily found in any custom report. The
table PRPS also has got another field called PRPS-OBJNR which is the linking field to any other
tables containing various information related to the WBS element. This field is the key field for finding
the status of the WBS element. The method to find the status of WBS element using this field is dealt
in the later part of this document.

A project can also contain various networks. Networks contain lot of activities which are linked to each
other by means of different relationship types. The duration which each activity takes and lead time or
lag time between two activities are also available in the network. Some of these activities are also
earmarked as Milestones in the project and based on the Milestone completion; revenue generation
can be initiates in Sales and Distribution by means of an invoice creation for the relevant Milestone
using Milestone billing functionality. In a network enabled business scenario, all the details of the
project like Schedule, cost, capacity and reservations will flow from network to the higher level
structures like WBS element and project. Various features of the network and their underlying
database tables are discussed below here.

NETWORK HEADER
The database table AUFK contains the network header related information. Some of the important
fields available in this table are listed one by one as follows.
The field AUFK-AUFNR represents the network number created in the system.
The field AUFK-OBJNR is a field which will be used as a foreign key in case this table needs to be
linked with some other table.
The field AUFK-PSPEL represents the WBS element which is linked to the network at the header
level. However if the business scenario involves activities within the network, this field may not be of
much use as each activity can have different WBS elements of the same project. This field assumes
importance if the networks are used without activities.
In case of assembly processing, where a network is created from a sales order using standard project
elements the fields AUFK-KDAUF and AUFK-KDPOS represents the sales order number and line
item respectively which triggered the network. These fields are seen in the network header in the fields
Sales Order Number and Sales Order Item in the Assignments tab.
There is also another table CAUFV which is similar to AUFK but CAUFV has some other additional
information related to costing etc. The table CAUFV is very important because this table is the central
table using which all the other network related tables are accessed. Some of the important fields in this
table are discussed below.
The field CAUFV-AUFNR represents the network number which is same as AUFK-AUFNR.
The field CAUFV-AUFPL represents the connecting link between all the related tables. The field which
is read as Routing number of Operations in the Order is the main field to be used for any join using
this table.

NETWORK ACTIVITIES
The details pertaining to network activities can be obtained from the table AFVC. When a network
number is known it should be passed as CAUFV-AUFNR and the resultant CAUFVAUFPL and CAUFV-BEDID should be obtained.
Now the value of CAUFV-AUFPL should be passed as AFVC-AUFPL and AFVC-BEDID respectively.
The resultant list gives the list of all the activities of the network.
Various fields and their importance are provided in detail below.
The field AFVC-VORNR refers to the activity number of the activity in the network. This number can
serve as the foreign key in many of the tables associated with the network activities. However there
are also other fields which can serve as foreign keys in different tables.
The field AFVC-APLZL refers to the counter number of the activity. This is an important field when the
network relationships are to be found out.

There are various fields related to control key of the activity, activity description, plant, work center,
calculation type etc which can be seen using this logic and hence those fields are not discussed in
detail here.
The data pertaining to planned cost for primary cost activities can also be found in this table in the
fields AFVC- PRKST for the planned cost and AFVC- SAKTO for the cost element against which the
cost is planned.
There is also another table AFVCP where AFVCP-AUFPL = CAUFV-AUFPL using which the WBS
element assigned to each of the activities can be found out.

NETWORK RELATIONSHIP
The details pertaining to the relationship of the network activities can be seen from the table AFAB. In
this table following are the fields which are very important.
The field AFAB-AUFPL_VOR represents the CAUFV-AUFPL of the network where the preceding
activity is located.
The field AFAB-APLZL_VOR represents the preceding activity counter number of the network. This
value is same as the value of the field AFVC-APLZL
The field AFAB-AUFPL_NCH represents the network number of the succeeding activity.
The field AFAB-APLZL_NCH represents the counter number of the network which is same as the
value of the field AFVC-APLZL.
If the relationship of all the activities are within a single network without involvement of any other sub
network like a task list or maintenance order etc, then the field values will be same for both AFABAUFPL_VOR and AFAB-AUFPL_NCH. In such a scenario the value of the fields AFABAUFPL_VORand AFAB-AUFPL_NCH will be same. In a case where the activities of one network are
related to activities of some other network, then these fields will have different value. Hence if the
relationship of activities in a network needs to be found, then it is necessary to give the condition
that CAUFV-AUFPL should be in either AFAB-AUFPL_VOR or (not and) in the field AFABAUFPL_NCH.

NETWORK MILESTONES
Some of the network activities can be maintained as milestones and the list of milestones can be
obtained from the database table MLST. In order to get the information of all the milestones of the
network the table CAUFV and MLST can be used.
The field CAUFV-AUFPL can be given as an input in MLST-AUFPL and the resultant list provides the
list of milestones of the network.
The field MLST_ZAEHL is the Milestone number. This field can be used to get information about
milestones from different database tables. For all those purposes, this field can be used as the foreign
key.
The field MLST- MLSTN provides the Milestone usage.
If the MS is confirmed then the confirmation number can be obtained from the field MLST- RUECK.
The table also has information related to Trend analysis, Progress analysis, Milestone functions etc
which can be analyzed in detail. As the key fields are already mentioned, it should be easy to get all
the other necessary details used this table.

NETWORK MILESTONE CONFIRMATION DETAILS

The status of the confirmed milestones of a network can be found from the table AFRU. Some of the
important fields in this table are discussed below.
The field AFRU-AUFPL represents the link with all the other tables of the network where this field
equals to the field CAUFV-AUFPL or AFVC-AUFPL or MLST-AUFPL. Using this table AFRU can be
accessed.
The field AFRU-VORNR represents the activity number whose milestone is confirmed
The field AFRU-APLZL represents the counter number of the activity in the network. This is nothing
but the AFVC-APLZL number.
The field AFRU- RUECK represents the confirmation number. This field is available both in AFRU and
also in MLST. However MLST gives the information that the milestone is confirmed but AFRU also
says whether the confirmation is a final confirmation or not in the field AFRU- AUERU.
Once this information is known, any other confirmation related information can be extracted either from
the table MLST or from AFRU based on requirement.

NETWORK MATERIAL COMPONENTS

The details pertaining to material components and their assigned transactions can be seen in the
tables RESB, AFWD and AFWI.
Some key fields of the table RESB are first explained.
The field RESB- AUFNR represents the network number which triggered the reservation. As this table
is the central table for reservation happening from various other transactions like sales order, planned
order etc, different fields will be updated during different transactions. If the reservation is triggered
through the network, then this field will be filled. For items which do not create reservations from
material components, this table is not valid.
The field RESB- RSNUM represents the reservation number and this can be used to find out all the
reservation related data.
There are other important fields like requirement quantity and requirement date which can be easily
found once this key field is known.
Similarly the tables AFWD and AFWI deals with the material movements associated with the
confirmation of milestones. Because of my limited knowledge on these tables, I am just mentioning
these tables and leave the rest for exploration.

STATUS OF THE PROJECT ELEMENTS

There are two tables related to the status of any transaction provided the transaction is enabled for
statuses using a status profile. They are JCDS and JEST. There are also two other tables TJ02 and
TJ30 and these tables are also discussed here.
Any transaction with the status profiles enabled will get updated in tables which will definitely have a
field called OBJNR. For example the tables relevant for project, WBS element and network
namely PROJ, PRPS and AUFK have this field OBJNR. This field forms the basis for finding out the
correct status.
In other modules transactions include sales order, production order, planned order, maintenance order,
task list etc will also have the object number. In sales order object number will be available for both
sales order header and item. Accordingly the statuses can be seen both at sales order header and at
item level. Similarly each transaction has its own structure and their respective object number.

The table JCDS shows the change history of the status. The relevant object number OBJNR should be
given as the input here and the output should be received.
Here the field JCDS- STAT represents the status. Any status with the prefix E is the user status and
the one with the prefix I is the system status.
In order to get the correct system, the value from this field should be passed on into the field TJ02ISTAT to get the system status.
For user status the field TJ30- ESTAT should be filled with the value of the field JCDS-STAT to know
the actual user status. However my knowledge in this table is very limited and there seems to be some
more logic involved to find out the correct status. That part is left for exploration. I will update this logic
later if I can find this.
The table JEST shows the current status of the object. The same logic should be used as explained
earlier.
The fool proof logic for status identification still needs to be explored.
There is also a function module STATUS_TEXT_EDIT which can be used to fetch the system status or
the user status for any project object, as long as we know the Object number OBJNR of the project
element. We can have this value for any project element in the respective table, as already explained.
If this value is provided as the input parameter, it is possible to get the user status and system status
as output parameters.

PROJECT VERSIONS
The database table pertaining to the version of the project elements follows the syntax VS<DATABASE
TABLE OF THE OBJECT>_CN. Using this logic the project versions of all the objects can be found out
without any problem.

CONCLUSION
This document still can be evolved by providing information on the logic for getting the information
pertaining to actual costs, actual revenues etc. As of now, I am in the process of trying to standardize
the logic for getting these elements and the same will be updated whenever it is ready. For now, let us
all make use of this document and enjoy the world of PS ing in SAP.
PROJ Project definition
PRPS WBS elements
PRTE Scheduling data
PRHI WBS hierarchy
AUFK Orders/networks headers
AFKO Production Orders/networks
AFVC Network activities
AFVU Network activities
AFVV Network activities
RESB Network Components
MLST Milestones

Transaction data and totals:

RPSCO Project info database (cost, revenues)
RPSQT Project info database (quantities)
COSP Cost totals for external postings
COSS Cost totals for internal postings
COSB Total variances/result analysis
COEP Line items, actuals
COOI Line items, commitments
COEJ Line items, planned orders
BPGE Budget, overall cost
BPJA Budget, annual values
QBEW Project stock valuation
MSPR Project stock (incl. non-valuated)
AUFK Order master data
AFVU DB structure of the user fields of the operation
AFKO Order header data PP orders
EBAN Purchase Requisition
EBKN Purchase Requisition Account Assignment
JEST Individual Object Status
LFM1 Vendor master record purchasing organization data
EKKO Purchasing Document Header
EKPO Purchasing Document Item
CSKU Cost Element Texts
CSKT Cost Center Texts
ANLA Asset Master Record Segment
JCDS Change Documents for System/User Statuses (Table JEST)
COSP CO Object: Cost Totals for External Postings
COSS CO Object: Cost Totals for Internal Postings
COEP CO Object: Line Items (by Period)
BKPF Accounting Document Header
BSEG Accounting Document Segment

CSKS Cost Center Master Data

COBK CO Object: Document Header
CEPC Profit Center Master Data Table
PRPS WBS (Work Breakdown Structure) Element Master Data
PROJ Project definition
PRHI Work Breakdown Structure, Edges (Hierarchy Pointer)
TJ02 System status
BPJA Totals Record for Annual Total