Cost/revenue elements are user-definable categories that are used to break down cost and revenue for planning and follow-up purposes in projects, making IFS/Project Management suitable for flexible cost and revenue management. Cost/revenue elements are defined per company as a part of setting up the company. All projects within the same company will use the same set of cost/revenue elements.
The various objects that can be connected to project activities can report different types of cost, hours and revenue to the project. Cost and hours can be reported as:
Similarly, different types of revenue values can be reported:
The type of cost or revenue reported to the activity depends on the type of object connected and its status. For more information about the types of cost and revenue a particular connected object will report to a project activity, see About Cost, Hours and Revenue Reported to Activity.
Any object which reports any type of cost, hours and revenue to projects will report these values on a cost/revenue element. There are several methods by which the system determines which element the cost or revenue should update. This is described in the following sections.
The majority of the object types use posting control setup in the project company. This setup determines which cost/revenue elements should be used to report values to project activities.
Once the cost/revenue elements have been defined, there are additional setup steps so that the desired elements can be derived through posting control for the different business processes. These steps are generally performed by an administrator when setting up the company and will apply for all the projects in the company.
This setup will ensure that a code part value for the Base for Project Cost/Revenue Element code part is considered for every project related business transaction. Then the cost/revenue element will be derived from the mapping of code part values.
The above setup is also used to determine the relevant cost/revenue element which should be used to report the preliminary or planning cost and revenue values (for example Planned Cost, Committed Cost or Planned Revenue). A posting control simulation is performed to find the most likely values for all the code parts. In the same way as for the actual transaction, a code part value for the base for project cost/revenue elements is retrieved. The cost or revenue value will be updated to the cost/revenue element as derived from the mapping of code part values.
One important fact about the simulation is that the code part selected as the base for project cost/revenue elements is not singled out. It is necessary that the simulation considers all the code parts because one code part value can be derived based on code string completion.
The scenario is project miscellaneous demand supplied through purchasing a non-inventory purchase part. The following applies:
Posting control setup for posting type M93:
| Posting Type | Code Part Name | Control Type | Default Value No Details | Default Value No CT Value |
| M93 - Purchase Non Inventory Material Invoice | Account | AC1 - Fixed Value | 5490 | |
| M93 - Purchase Non Inventory Material Invoice | C and R | AC1 - Fixed Value | MISC |
When a miscellaneous demand is entered for a project activity to purchase a non-inventory part, planned cost is reported from the demand line to the project activity. The planned cost is updated to the cost element derived according to the posting control setup described above. In this example the planned cost will be reported to the activity on the cost element EQUIPMENT.
When the supply objects (purchase requisition line and then the purchase order line) are created, the planned committed and the committed costs are reported based on the same simulation. Finally when the supplier invoice is matched, the posting rows are created based on the posting type M93 to report used cost.
On some types of project connected objects, you can manually define a cost element on the object. The object will then report its cost and hours to this cost element on the connected activity. Objects on which you can manually define a cost element are generally planning objects, such as project activity tasks or document packages.
The relevant cost element to use for reporting costs from allocated resources is determined through posting control. If no posting controls has been set up, a cost element is defined on the basic data for Resource Groups. This cost element can be used as a default value.