The Project System (PS) module has a functionality called project-related incoming orders that allows you to report on incoming order values for an engineer-to-order process. The PS module can calculate order book and backlog values throughout the project life cycle. It allows you to avoid negative backlog and remaining backlog on closed projects. Three examples show how it handles transactions.
Key Concept
The order book (SAP uses the term "incoming orders") contains the value of all orders placed in a certain time period. Changes to those orders (change orders) should be reflected in the order book in the period they occur. Orders that generate more or less actual revenue than planned should be stated in the order book with their actual revenue. The order backlog (SAP uses the term "open order values") represents the value of unfilled orders and therefore the outstanding amount of revenue on all orders (e.g., future revenues from contracts signed to date). Backlog calculations should account for the order book value and subtract the revenue amount that has already been realized.
Project-related incoming orders, the Project System (PS) functionality used for backlog and order book, is neglected for budget or time-constraint reasons in some implementations. Instead, the sales order and revenue values are exported to Microsoft Excel, where the order book and backlog calculation takes place.
Exporting increases your manual workload in each period-end closing. In addition, the routines used in Excel are often too basic to cover all aspects that have to be addressed for a successful calculation. I will show you how the PS functionality can streamline your close, and will lead you through the calculation process with three examples.
Introduced with Release 4.5A, project-related incoming orders takes the sales order values from R/3 Sales and Distribution (SD) into account as well as the results analysis data in PS. The functionality is part of the period- end closing procedures, which has the disadvantage that the order book and backlog values are only updated at month- end.
The SD module holds the order book and backlog values, key performance indicators that are based on information about sales orders and their invoices. Companies that have only make-to-stock processes like repetitive, discrete, or process manufacturing use the Sales Information System (SIS) within SD to report their order book and backlog values.
However, if a company uses the engineer-to-order process, the SD module is no longer suitable for reporting on the incoming order values. This is because revenue amount data is only accessible via the PS module. PS contains results analysis, which can calculate revenues that exceed or fall short of the amounts billed to the customer. The revenues only deviate from the amounts billed while the project is still being worked on. At the end of the project life cycle, the calculations reflect the exact billed amounts. The backlog calculation has to take those revenue amounts stored in PS into consideration.
Incoming Orders Functionality
The incoming orders functionality consists of transactions CJA1 and CJA2. CJA2 processes a single project and CJA1 processes several projects at a time. The transactions calculate the revenue values needed for order book and backlog as well as the associated costs, which can be used to report expected future profits. I will concentrate on the revenue values.
The incoming orders function calculates two values — the order book value and the difference between order book and backlog value, which SAP calls "reduction by billing documents." It runs only on work breakdown structure (WBS) elements marked as billing elements, since sales orders can only be assigned to those.
Instead of only showing the order book value as one lump sum, the system breaks it down into multiple categories for new orders (category IONO), change orders (IOCO), and rejections (IORE). Most of my customers use these categories to monitor their ability to generate new projects from month to month.
Note
Don't be misled by the term "reduction by billing documents." At the end of the project life cycle, this value contains the amount billed to the customer. However, while the project work is ongoing, it contains the revenue value.
Tip!
If you run project-related incoming orders for a project and the new order value is incorrect (e.g., the sales order conditions were wrong), you can still make the change and report the updated plan revenues as new orders. Just reverse the incoming orders transaction before you run it again (select incoming ordersreverse from the menu in CJA2).
Figure 1 shows the result of the calculation of incoming orders values for one project. The order book value is shown in the first line as $150,000, category IONO (new order). The reduction by billing documents is shown in the fourth line under category OBRB with $75,000. The backlog is $75,000.
Figure 1
Detail list of transaction CJA2
Calculate Incoming Orders Values
The data used as a basis for the calculation of values in project-related incoming orders transactions falls into three categories:
Figure 3
Project status on Basic data tab in Project Builder (transaction CJ20N)
Tip!
Projects that are still in the created status do not calculate incoming orders values even though they have a sales order assigned. Only released projects are selected by transactions CJA1 and CJA2. Make sure to release all projects that should be part of the order book before period-end closing. You can use the created status to enter projects and their assigned sales orders without displaying them in the order book. Reasons for this might be that the customer places the order, but not all conditions for its revenue are worked out, or that the order entry belongs to the next accounting period.
This base data allows the system to switch your order book value from the sales order plan to actual revenue as necessary. Doing so avoids negative backlog on open projects as well as open backlog values on completed projects. The following three scenarios guide you through the calculation processing using hands-on examples.
Scenario 1: The planned revenues on the project are higher than the actual revenues and the final invoice has not been issued. R/3 uses the planned revenues as the order book value and subtracts the actual revenues calculated in results analysis to get to the backlog value.
In this example, you receive an order with total planned revenues of $110,000, billable in two steps of $50,000 and $60,000. You expect a plan cost of $100,000. Although you receive the order at the end of June, work didn't start until August. R/3 calculates an order book value of $110,000 in the June period-end close. Backlog also equals $110,000.
Tip!
Ensure the correct maintenance of system status FNBL so that the order book and backlog values are up to date.
Tip!
An administrative employee, either the project controller or the invoicing department, is often better suited to determine the accuracy of FNBL than the project manager.
In August, the expense on the project runs up to $30,000. Since it is a POC project, the system calculates a percentage of completion of 30 percent (POC = actual costs / planned costs). Therefore, the actual revenue is $33,000 (actual revenue = planned revenue * POC).
When running project-related incoming orders, R/3 reads the actual revenue from results analysis. The backlog is calculated using the order book value (planned revenue) of $110,000 and subtracting actual revenue of $33,000. The backlog therefore amounts to $77,000 in August. The order book value remains at $110,000.
Scenario 2: The planned revenues are higher than the actual revenue and the final invoice has already been issued. The system uses the actual revenue instead of the planned revenue as the order book value. The backlog is reduced to zero. At the end of December, you invoice the customer for $55,000 instead of the remaining $60,000 that appears in the billing plan. To handle this difference, you have two options:
- Change the billing plan to reflect the decrease in revenue of $5,000. The change automatically triggers a reduction in the order value and backlog.
- Leave the billing plan as is, but change the invoice amount while creating the invoice. To indicate final billing to the system, you set a reason for rejection indicator in SD. You also set system status FNBL (final invoice) on the billing element of the project. This option might raise concerns that the system will not be able to calculate the correct backlog amount.
A remaining positive backlog even when a project is fully invoiced as well as the possibility of a negative backlog are shortcomings of many ERP systems. This is not so in SAP. Even though a lower-than-planned amount is billed in the sales order, the system adjusts the order book to reflect the actual revenue and zero out the backlog as soon as the system status is set to FNBL.
Independent of which option you choose, the changes in order value are reflected in category IOCO (change orders).
Scenario 3: The actual revenues overrun the planned revenues. You usually would change the sales order values, which in turn would increase the planned revenues and the order book value. However, in some cases the sales order values are not updated and only the customer invoice amount is increased. R/3 can handle this situation. The incoming orders functionality always uses the higher of actual revenues and planned revenues and updates the order book value accordingly. The backlog is zero as soon as actuals surpass planned values.
Tip!
Here's a workaround for orders entered in the current month that should not be taken into account by the incoming orders transaction that runs for the previous month. Hold the sales order entries until the end of period-end closing. For new projects, you can avoid adding them by leaving them in the created status.
Tip!
You also have the option to use user exit ORBF0001, enhancements to project-related incoming orders, to influence which orders are taken into consideration by the incoming orders transactions. You can add an additional check mark to the SD order that reflects whether you want to take this SD order value into your order book or not. In the user exit, you reflect zero values for SD orders that do not have this check mark set.
Apply Calculated Order Book and Backlog Values
The calculation of order book and backlog values I've demonstrated is part of the period-end closing. Therefore, the calculated results have to be assigned to a certain period within the fiscal year.
The way in which incoming orders books are assigned differs from the revenue values in the regular project reports for plan data. In those reports, R/3 assigns the plan revenues to the period defined by the billing date in the SD order line. A billing plan could result in multiple periods.
The order book values are always assigned to the period for which the incoming orders functionality is carried out. The system assigns the values to the period entered on the selection screen of transaction CJA2. Then the order book shows its revenue for the period in which the order was accepted, not the period to which the revenue will actually be billed.
However, a drawback to the way that the incoming orders books are assigned is that R/3 will even take orders into consideration that have been entered in a period higher than the period entered on the selection screen. Since you have to run the incoming orders functionality after the results analysis, which you probably carry out when you are already some days into the new month, you always get order values into the order book that belong to a later period.
You can see why this is problematic in the following example. You receive two new orders from your customer: Order A is entered into the system on June 30. The order has been assigned a billing plan with two billing dates. On October 31, 2004, your customer owes $50,000 and on December 31, 2004, the customer owes $60,000.
Order B is entered into the system on July 5, 2004. The planned billing date for the full order value is August 31, 2005. The order's value is $240,000. You run the incoming orders transaction on July 7 for period 06/2004. The system applies the values in
Table 1.
Order A |
10/31/04 – $50,000
12/31/04 – $60,000 |
06/2004 – $110,000 |
Order B |
08/31/05 – $240,000 |
06/2004 – $240,000 |
|
Table 1 |
Billing plan for orders A and B |
Period-End Closing and Reporting
In your period-end closing procedures, incoming orders functionality has to run between the results analysis and settlement programs. Run the incoming orders functionality after the results analysis to pick up the revenue affecting net income value that is important for backlog calculation. Run it before settlement to allow the order book and backlog values to be transferred into CO-PA.
You can report in the PS and CO-PA module. You can use CO-PA as your reporting tool on order book values by market segments. To learn more details on settlement and reporting, go to the download "Reporting on Incoming Order Values" at the bottom of this article. Setting up the incoming orders functionality in customizing is fairly easy. The step-by-step instructions can shave off implementation time.
Marco Jordy
Marco Jordy is the vice president of SAP Finance Consulting at ORBIS America, Inc. ORBIS is an internationally active business consulting company with core competencies in consulting for customer-oriented management processes (CRM), internal management processes (ERP/PLM), and supplier-oriented management processes (SCM). Marco has more than 11 years of experience in SAP implementations in the US and Europe. He is a graduate of the University of Applied Sciences in Saarbruecken, Germany, with a major in finance and a specialization in informatics. Marco specializes in the integration between the finance and logistics modules as well as international rollout projects in multi-cultural environments.
You may contact the author at
marco.jordy@orbisusa.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the
editor.