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. 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.

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:

• Planned revenue: Planned revenues can result from manual planning or from an automatic transfer from sales orders that have been created in SD and assigned to a project. The amount is determined based on the net value of the sales order line item. All changes made in the sales order (e.g., changing the value of a condition type) are reflected in PS automatically, so the incoming orders functionality makes that change. If an SD order is assigned in addition to manual plan revenues, then the system aggregates both numbers.
• Revenue affecting net income: This is the share of the revenue that a certain project contributes to the income statement. Its calculation depends on the type of results analysis method you use — for example, completed contract or percentage of completion (POC). Some methods, (e.g., POC, which calculates revenue based on how much of the project has been accomplished) calculate revenue that is higher or lower than the amount billed to the customer. The difference is defined by SAP as revenue in excess or revenue surplus.Figure 2 shows the results analysis for a POC project (transaction KKA2). In this example, the project (WBS element B-120002-B) has planned revenues of $200,000, which is shown in the Planning data tab value R(p). The project's planned costs are $160,000 (value C(p) under the Planning data tab). Billings to the customer amount to $40,000 under the Actual data tab, value R(a). Actual costs are $100,000 (value C(a) under the Actual data tab).
  Figure 2
  SAP results analysis (transaction KKA2) showing actual revenue
  The system compares actual and planned cost to compute a 62.5 percent percentage of completion. Based on the percentage of completion, the system calculates the revenues affecting net income (actual revenue) as 62.5 percent of the planned revenue. Therefore, actual revenue amounts to $125,000. To find this figure, follow menu path Logs > Explanation facility. In the log of the explanation facility, the revenue affecting net income for this example is listed as $125,000.
• Information on Final Invoice Being Issued: The calculation of order book and backlog also depends on whether the final invoice has already been issued. To determine this, the system looks for the fully invoiced system status (FNBL) set in the WBS element. Remember that the system runs the incoming orders functionality only for WBS elements marked as billing elements. Therefore, pay special attention to the system status on those WBS elements, which is located in the project master data. Use transaction CJ20N (Project Builder) to display the project. The system status is usually shown on the Basic data tab (Figure 3).

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.   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.

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 Planned revenue Incoming orders value 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.