Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
cancel
Showing results for 
Search instead for 
Did you mean: 
stefan_walz
Product and Topic Expert
Product and Topic Expert
2,646

Co-Authored by Gabi Hoffmann and Stefan Walz 

Welcome to this blog, in which we will show the financials integration for the new Advanced Execution scenario. This scenario is suitable for maintenance and repair services, which require advanced planning and execution capabilities. For this we integrate the commercial aspects of the Service order with the planning and execution capabilities of Maintenance Management.

The described functionality is only available in SAP S/4HANA on premise and S/4HANA Cloud Private Edition. It is foreseen to replace the CS order scenario, which will be deprecated.

We will start in this blog by describing the underlying financial architecture.

Then we will show an end-to end process in the system. We will explain two scenarios: fixed price billing with a cost-based POC and T&E/ Resource-related billing. We will close with insights into the configuration.

Solution Approach/ Architecture of Advanced Execution Service

The advanced execution order scenario is based on service management with the item-based accounting finance integration. (for activation check figure 39)

This implies:

  • Service order item related processes post on the new CO object, SV CO-Object, for service order items.
  • As revenue recognition tool Event-Based Revenue Recognition (EBRR) is provided, no Result Analysis.
  • Plan data are stored with own service plan categories in ACDOCP.
  • Universal Parallel Accounting (UPA) is not a prerequisite, but it is supported. Parallel valuation must be mapped with UPA, as multi valuation (the solution based on the usage of currency fields in ACDOCA) by default is not supported by EBRR.
  • In the current release margin analysis is supported, but not cost-based CO-PA - as settlement of EBRR data is not yet supported.
  • Service orders are automatically included in margin analysis reporting by the attribution of the related journal entries – costs, revenues, EBRR data, WIP. There is no settlement required.
  • A reporting integration with a WBS element is available by adding it in the service order item.

 Further information about the new financial accounting 4 service order is available here: Financial Accounting for service management 

Here an overview about the involved objects and processes in the advanced Execution Service scenario:

Figure1: Advanced Execution Service – process overviewFigure1: Advanced Execution Service – process overview

 

 

 

 

 

 

 

 

 

How the integration between PM order and service order works you can see in the next slide.

 

Figure2: Integration PM order with service order itemFigure2: Integration PM order with service order item

In this scenario, service order and PM order have clear roles:

The service order is the commercial item and will be billed and gets revenues posted. Revenue recognition method is defined on service order item level by assigning an EBRR key. The revenue recognition journal entries are posted on the service order item. There is an option to assign a service contract item and a WBS element to the service order item. These objects will be attributed for all postings on the service order and the PM order. There is no confirmation on the service order item.

The PM order creates the confirmations, which lead to cost postings on the PM order. The revenue recognition method is defined in the service order item, which will be used for every posting on the PM order. Thus, there must not be a Result analysis key in the PM order assigned. The costs would be activated twice.

To enable matching costs and revenues on the profit center, on the PM order should be the same profit center assigned as in the service order item. Thus, the profit center is derived from the service order item for the assigned PM orders.

For every posting on the PM order the system checks the assignment to an Advanced execution service order item. If available, the assigned EBRR key is used for revenue recognition. The EBRR key can be checked in the FIN mirror table/ FCO_SRVDOC – see figure 8. Based on the assigned method, revenue recognition is triggered, and the matching EBRR journal entry is posted on the service order item.

Regarding the WBS assignment:
If you assign a WBS element to the service order item all postings on the service order item and the assigned PM orders get attributed with this WBS element and you can report all these costs, revenues and WIP on the project as statistical postings – see report in figure 37.

To achieve this there is no need to assign the PM order to the WBS element. If you additionally assign the PM order to a project, which is different, you will get these costs double in project reporting.

With the service order item WBS attributing, the costs and revenues are only impacting the WBS reporting. They cannot be included in revenue recognition on the WBS or in the project hierarchy reporting!

If you assign the PM order to a WBS element, the costs can be included in the revenue recognition of the project, and they are visible in the project hierarchy reporting.

With which information the costs on the PM order and the matching EBRR journal entry are posted you get in the next figure.

Figure3: Advanced Execution item reflection in Universal JournalFigure3: Advanced Execution item reflection in Universal Journal

One confirmation on the PM order leads to two journal entries:

  • The cost posting on the PM order attributed with the service order item and the market segment derived from the service order item.
  • The revenue recognition posting account assigned to the service order and attributed with the service order item market segment.

With this market segment attributing, market segment reporting is already available by reporting on the P&L journal entries posted in this scenario. There is no settlement needed – see figure 38.

Please consider that in the Advanced Execution service scenario there now can be multiple cost objects applied in one journal entry: in line one we have the real account assignment on PM order, attributing on service order, WBS element and service contract. This allows an aggregated reporting on these objects.

More about CO account assignment and attributing you can get here:  blog about CO account assignment and attribution with S/4HANA 

Now let’s have a look at some system examples.

System walkthrough

We will now show an end-to-end Advanced Execution Service process in a OP2023 FP2 system.

First a scenario with time and expense billing. Here we show a special usage of the accounting indicator,

Secondly a fixed price billing, for which we adapt manually the plan data and manually change the technical completed status.

Advanced execution order master

We create a service order with the app “Manage Service Orders”.

Figure 4: service order headerFigure 4: service order header

We insert a service order item, enter the product “ZPUMP_MAINTENANCE”, the profit center (YB112) is derived -option for flexible derivation please check in FIN 4 Service blog above.
We enable the Advanced execution Service scenario with the new item category “Execution order item” – see figure 44.

Figure5: service order assignment to service contract itemFigure5: service order assignment to service contract item

The service order item gets assigned to a service contract item. With this, in finance we derive the market segment field product sold from the service contract item – see figure 13.

 Figure 6: service order item billing parameterFigure 6: service order item billing parameter

With the billing relevance the type of billing is defined: fixed price Billing or resource related Billing/ itemized Billing. For itemized billing you need to assign a DIP Profile, in which you:

  • Assign a bill material to the confirmation activity type.
  • Or assign a bill material to the G/L account used in the confirmation.
  • Define if the billing value is defined by confirmation quantity and product price – like we do it for activity confirmation. Or if you bill based on the costs – used for e.g. billing travel expenses.

 Figure 7: service order item assigned PM order.Figure 7: service order item assigned PM order.

With release of the service order item a PM order is created – you see here order 4046367.

 The financial attributes of the created service order item can be checked in table FCO_SRVDOC by SE16:

Figure 8: financial attributes of service order itemFigure 8: financial attributes of service order item

In this view you can get the financial attributes for this service order item:

  • the derived revenue recognition key CCOTM – for derivation logic check figure 45.
  • the assigned service contract item - see second column object number , number starting with SC - will be derived in the assigned journal entries as attribute.
  • the market segment fields derived by the service order item. The product sold will be derived by the product of the service contract item – see figure 13,17 and 18.

We analyze the created PM order with transaction IW32.

Figure 9: PM order masterFigure 9: PM order master

In the PM order header, you see the reference to the service order item – 8000075165, 10.

Figure 10: PM order master – financial attributesFigure 10: PM order master – financial attributes

The Profit center YB111 is derived from the service order item and is not changeable.

As functional area we maintain YB18, a cost of sales functional area.

Figure 11: PM order master – controlling dataFigure 11: PM order master – controlling data

In this tab the costing sheet can be applied and the parameters for the PM order cost estimation are assigned.

As mentioned, there must not be a result analysis key assigned.

 For confirmation we start transaction IW41 or app “Enter PM order confirmation

Figure 12: PM order confirmationFigure 12: PM order confirmation

We confirm the first two operations and analyze the created journal entries with the app “Display Line Item Margin Analysis”.

Figure 13: journal entries of PM order confirmationFigure 13: journal entries of PM order confirmation

For each of the two confirmations we get two journal entries:

  • The first journal entry item is the cost posting on the PM order – with service order and service contract item and its market segment attributed.
  • The second journal entry is the matching revenue recognition document, posted on the service order item.

The realized revenue of 600 USD for the first confirmation is calculated by EBRR by simulating the resource related billing. In resource related billing the activity type “11” is mapped to a product. For the product in SD pricing there is a price of 120 USD defined. Multiplied by the 5 hours, we get the 600 USD.

 

Resource related Billing

Now let’s start billing for the service order item by transaction DP92 or the app ”Create Resource-Related Billing Request – Service Order”.

Figure 14: app “Create Resource-Related Billing Request – Service Order”Figure 14: app “Create Resource-Related Billing Request – Service Order”

We enter our service order item.

With selecting button Billing document request, system reads all Controlling Journal Entries, which are posted on the service order item assigned PM order and creates billable items– see next figure.

 Figure 15: app “Create Resource-Related Billing Request – Service Order” – billable itemsFigure 15: app “Create Resource-Related Billing Request – Service Order” – billable items

Underneath the billing header we see 2 billable items: the two confirmations of 5 and 3 hours. The activity type 11 is mapped to the bill product SM0001. The billable amount is equal to what we already simulated for the realized revenue for the matching EBRR journal entries.

 Out of DP92 a debit memo request (DMR) is created. With the app “Create Billing Document”/ transaction VF01 we create the billing document:

Figure 16: T&E billing documentFigure 16: T&E billing document

We release the billing document to accounting and analyze the created journal entries in app “Display Line Items – Margin Analysis”.

Figure 17: journal entries created by the T&E billing documentFigure 17: journal entries created by the T&E billing document

Two journal entries have been posted with reference to the billing document:

  • The billing document with the billed revenue line item is account assigned to the service order item.
  • The matching EBRR journal entry, which defers the revenue on the service order item - as it was already realized with the confirmation.

All journal entry items posted on the service order item are attributed with the market segment and the assigned service contract.

 To get the financials analysis for the service order we start the app “Product and Service Margins”.

 Figure 18: Advanced Execution Service impact in margin analysisFigure 18: Advanced Execution Service impact in margin analysis

You see not only the figures for the service order, but you also see how the advanced execution scenario impacts the margin analysis reporting. You get also a margin for e.g. the market segment fields product sold and customer – and for the profit center.

Usage of Accounting Indicator

Now we want to show you, how the Accounting Indicator can impact revenue recognition in case of a resource related billing contract.

We create another service order, 8000075349, with assigned PM order 4046450.

Then we create for the bill product SM0001 and the Accounting Indicator Z1 a price condition with a discount of 100% - transaction VK11.

Figure 19: Accounting indicator dependent price conditionFigure 19: Accounting indicator dependent price condition

We create a PM order confirmation with transaction IW41.

Figure 20: confirmation with warranty Accounting IndicatorFigure 20: confirmation with warranty Accounting Indicator

In the PM order confirmation, for one confirmation item we apply the Accounting Indicator Z1.

We analyze the created journal entries of the confirmation with the app “Display Line Items – Margin Analysis”.

Figure 21: journal entries of a confirmation with warranty Accounting indicatorFigure 21: journal entries of a confirmation with warranty Accounting indicator

The result is: for the confirmation item with the applied accounting indicator (column Billable Control ) Z1, first journal entry, there is no EBRR journal entry created – other than in the two following confirmations.

Reason: the expected revenue for this confirmation with a discount of 100% is zero and there will be no subsequent billing journal entries created for this confirmation.

 

Fixed price billing

Now we show a fixed price scenario. In this scenario we will assign a WBS element to the service order item.

We create a new service order with an Advanced Execution Service item:

Figure 22: service order item assigned to a WBS billing elementFigure 22: service order item assigned to a WBS billing element

We assign to the service order item the WBS element SW-Mario1710. The planned billing amount is 1200 USD, this will be the value we take in revenue recognition as planned revenue.

Figure 23: service order item - billing viewFigure 23: service order item - billing view

We maintain In the billing view as billing relevance, billing on completion – fixed price scenario.

Figure 24: service order item – Maintenance order viewFigure 24: service order item – Maintenance order view

Maintenance order 4046460 is assigned.

 We analyze the PM order with transaction IW32.

Figure 25: Maintenance order – assigned to service orderFigure 25: Maintenance order – assigned to service order

 

Manual plan adjustment

With release of the PM order the plan costs are calculated based on the maintained operations and resources. The planned costs are attributed – like the actuals we have seen before – with the service order attributes.

We analyze the calculated plan costs with the app “Service Plan/Actuals”.

Figure 26: Advanced Execution plan costs and revenuesFigure 26: Advanced Execution plan costs and revenues

There are plan revenues derived from the service order item of 1200 USD.

And plan costs of 705,50 USD – based on the PM order calculation.

 

We want to adjust the plan data. We first enter the additional plan data in an excel sheet.

Figure 27: Additional plan costs for service orderFigure 27: Additional plan costs for service order

We enter additional plan costs of 294,49 USD with an own plan category SW-SERVICE. More about the new functionality of manual plan data for service order you can see in figure 40 to 42.

We start the app “Import Financial Plan Data” and select the excel sheet as source.

Figure 28: app Import Financial Plan DataFigure 28: app Import Financial Plan Data

We can analyze the updated plan data again in the app “Service – Plan/Actuals”.

 

Figure 29: Advanced Execution plan costs and revenues after adding manual plan data.Figure 29: Advanced Execution plan costs and revenues after adding manual plan data.

The manually entered plan data with category SW-SERVICE are added to the plan data determined by the cost estimations.

Also, for the manually entered plan data all attributes – like the market segment - of the service order item are derived.

Now we create a PM order confirmation. The created journal entries we analyze here:

Figure 30: journal entries of a PM order confirmation for the fixed price service order itemFigure 30: journal entries of a PM order confirmation for the fixed price service order item

As in the example before for every confirmation a matching EBRR document is created. The realized revenue is now calculated by a cost based POC.

When we look on the first line with cost of 375 USD,

the POC is: 375 USD divided by the planned costs of 1000 USD = 37,5%,

multiplied with the planned revenue of 1200 USD = 450 USD.

 As a next step we bill the service order item. In the service order we set the status to complete and start app “Release for Billing”. With this a DMR is created. We start the app “Create Billing Document” and create the invoice for the DMR. The created journal entry of the invoice we analyze here:

Figure 31: journal entries of the fixed price billing documentFigure 31: journal entries of the fixed price billing document

The billing document for fixed price looks like the T&E billing journal entry: the revenues need to be deferred as the revenue is already realized with the PM confirmation.

 We need to net deferred and accrued revenues and start the app “Event-Based Revenue Recognition – Service Documents” and push button revalue.

Figure 32: app “Event-Based Revenue Recognition – Service Documents” – simulationFigure 32: app “Event-Based Revenue Recognition – Service Documents” – simulation

On balance sheet accounts there is accrued revenues of 810 USD and deferred revenues of 1200 USD; which needs to be netted.

EBRR nets accrued and deferred revenue. Accrued revenue is balanced to zero.

Figure 33: app “Event-Based Revenue Recognition – Service Documents” – after nettingFigure 33: app “Event-Based Revenue Recognition – Service Documents” – after netting

The recognized margin based on the adjusted plan data is 525 USD.

The system still expects costs, thus there are still deferred items – here the deferred Revenue and the adjusted revenues of 390 USD

 

Manual change of technical completed.

Now the controller decides that there are no more costs and revenues expected and all posted costs and revenues should be realized –and sets the status to TECO manually.

Figure 34: service order item – setting TECO manually.Figure 34: service order item – setting TECO manually.

You have 3 options in the TECO determination.

  • You can determine by system – item confirmed and billed.
  • You can set it manual.
  • And you can reverse it, when you still want to accrue.

There is a second step needed to update the status to the service order item. This is done by the report CRMS4_SET_FIN_TECO:

Figure 35: starting program to update manually defined TECOFigure 35: starting program to update manually defined TECO

We run again EBRR to verify the impact of the assigned TECO Status.

Here you get the simulation result:

Figure 36: EBRR results with status TECOFigure 36: EBRR results with status TECO

All deferrals and accruals are balance to zero: the posted actual costs and revenues are realized.

 

Aggregated reporting

For the last service order, the fixed price order, we assigned a WBS element, SW-Mario170. The journal entries posted on the service order item and the PM order are attributed with the WBS element – see figure 30 and 31.

We can analyze these postings in the project reporting. For this we start the “Project – Actuals” app:

Figure 37: advanced execution Service Journal entries in project reportingFigure 37: advanced execution Service Journal entries in project reporting

The postings on the Advanced execution Service are visible in the project reporting – costs, revenues and WIP.

The postings are marked as statistical- visible with the dimension “WBS element is statistical”.

Statistical costs are not available for subsequent processes. So, they would not be included in revenue recognition and settlement on the project.

Remark: if you assign a WBS element in the PM order master, the PM order costs would not be visible here.

 

Now let’s check how the 3 Advanced Execution Service scenarios are reflected in market segment reporting. We select them in the “Product and Service Margins” app.

Figure 38: advanced execution Service Journal entries in Product and Service margin appFigure 38: advanced execution Service Journal entries in Product and Service margin app

All 3 service orders contribute to the market segment of customer 1700001 and to profit center YB111. We have two “product sold”. The second product sold was derived in the first scenario from the assigned service contract item.

All 3 scenarios updated market segment reporting – without settlement.

 

Control of planning and event-based revenue recognition

 To get the scenario enabled, the following configuration steps are necessary for finance.

 Item based accounting activation

 To use the Service Management with the financial integration described above, it is necessary to activate the item-based accounting. Item-based accounting enables you to record costs and revenues in real time as they are incurred in the service orders and service contracts. The system assigns an account assignment object (also known as a CO object) to each service item that is part of a service order or service contract.

Figure 39: config for activating item based accountingFigure 39: config for activating item based accounting

The activation takes place via the customizing path:

Service à Transactions à Settings for Service Transactions à Integration à Enable Item-based Accounting for Service.

The switch is on client level. In addition, there is important information available in the release information note: restriction note 

Plan category including virtual plan category.

For service all plan data are stored in ACDOCP -only.

The planned revenues on service order item are stored with plan category ‘PSERV01’ as the service document baseline information and ‘PSERV02’ as the service document ongoing information. The baseline information is stored once with the release of advance execution item.  

The planned costs are based on the information in the plant maintenance order. Here the plan category ‘PMORDER01’ is available for the baseline and the plan category ‘PMORDER02’ of the ongoing planning. The baseline is stored once with release of plant maintenance order.

These plan categories are delivered as standard and cannot be changed.

The planned costs for the PM order are always written. The planned revenues are written depending on the billing relevance of the item. No planned revenue is written for T&E billing. They are written for advanced execution items with fixed price billing: with billing relevance ‘billing at completion’ or ‘Billing via Billing Plan After Release’. For ‘billing at completion’ the net value of the item is taken into consideration for the billing relevance ‘‘Billing via Billing Plan After Release’ the value of the billing requested lines.

The customizing for service order planning can be found in standard controlling view: Controlling > General Controlling > Planning.

Figure 40: IMG path for CO object planningFigure 40: IMG path for CO object planning

 If you want to add manual planning to a service order item, you must create a manual plan category (maintain category for planning).

 

Figure 41: manual plan category for service documentsFigure 41: manual plan category for service documents

With OP 2023 FP2 there is now a new application type ‘Service Document’ available. We select this and the usage ‘1’, manual update.

With the assignment of application type “Service Document” additional checks and derivation logic are provided by the plan update.

  •              The three service document fields must be provided for every planning line item.
  •              The account assignment type “Service Document“ is determined for all planning line items and
    additional attributes are taken from the financial view of service documents (FCO_SRVDOC) like Profit center or margin analysis fields are derived and stored for the planning line items.

 

If we now want to aggregate the plan revenues of the service order, PSERV02, the plan costs on the PM order, PMORDER02, and the manual added plan data, SW-SERVICE, we need to build a plan category, which aggregates these 3 plan categories. This is a virtual plan category – here EBRR_MSO. For the assignment there is an own IMG step:

Figure 42: assignment of plan categories to virtual plan categoryFigure 42: assignment of plan categories to virtual plan category

This virtual plan category can then be used in reporting for aggregating different plan categories on different objects and it can be assigned in the customizing of the EBRR.

Figure 43: assignment of virtual plan category in EBRRFigure 43: assignment of virtual plan category in EBRR

 

In addition to the assignment of the plan category, there are other settings that need to be made in the Event-Based Revenue Recognition.

Event-Based Revenue Recognition configuration

 The activation of EBRR for an advanced execution item depends on the company code and billing relevance. It is possible to include both the product and the 'product sold' details for the item. When the status of the advance execution item is set to 'released,' the system accesses the derivation table to derive a revenue recognition key.

The billing relevance is defined at item level and is determined at item category level.

Figure 44: config of service order item category Execution order itemFigure 44: config of service order item category Execution order item

So far in this blog the Itemized billing ‘G’ and billing upon completion ’D’ were discussed.  In addition, EBRR supports ‘B’ Billing via Billing Plan After Release.

Itemized billing is linked to resource related billing and the required EBRR method for this is ‘4’. This method makes it possible to post the revenues in parallel to the costs. The revenue values result from an invoice simulation.

In our example, method 3 is stored for billing relevance ‘D’ (billing after completion). The method is relevant for a cost based POC. The planned revenues result from the net value of the item and planned costs from the PM order.

Figure 45: derivation of EBRR key in Advanced Execution Service scenarioFigure 45: derivation of EBRR key in Advanced Execution Service scenario

A general overview of what is currently supported in EBRR can be found in the note:  note about EBRR functionality in OP 2023 

Further supported scenarios

1 : n PM order scenario

For the scenarios we have shown above, a single Plant Maintenance Order was created from the Advanced execution item. The relationship between advanced execution item and PM order is 1:1. There is also the option that more than one PM order refers to a single advanced execution item. The 1: n relationship is supported with the same billing relevance and EBRR methods as described above.

The customer can perform one of the following 3 functions on the billable maintenance order with an additional option to carry over the service linkage:

  • Simple copy
  • Create follow-on
  • Create sub-order

With each of these 3 functions, if the service option is selected, then the system would create a new maintenance order with following characteristics by default:

  • The new maintenance order will be a billable maintenance order.
  • The service order and execution order item reference will be carried over from the source billable order into the new billable order.
  • The new billable maintenance order will have a doc flow to the existing execution order item.
  • The existing execution order item will get a new Service document flow to the new billable maintenance order.

 All assigned PM order will be taken in account in the service order reporting, in Resource related billing for the service order and in EBRR running on the service order.

Service Contract as Root Item in Financial Hierarchy 

To support a newly established business linkage, we are now introducing with OP 2023 FPS2 a service process that ensures seamless integration and effective management of service delivery.

The business use case being illustrated is:

A company signs a service contract with a customer to provide designated services over a specific timeframe. Periodic billing will be applied to the customer. Since the delivery of services may fluctuate throughout the contract term, the revenue will be recognized using a cost-based Percentage of Completion approach, reflecting the actual progress in fulfilling the contract.

Within this scenario, the service contract is crucial for revenue determination, and consequently, it is relevant for deriving the revenue recognition key. In the initial version of the process, the advanced execution items are not included in billing, while the associated PM orders account for the costs. The planned revenues and costs for the contract and PM order, respectively, are recorded. Both sets of planned figures can be expanded with manual planning if needed.

All costs of the hierarchy are aggregated to get complete plan and actual costs for the cost based POC method. EBR is running on the service contract item, the hierarchy header. here the EBRR key is assigned.

Closing remarks

We hope you found these insights into Advanced Execution in S/4HANA On-Premise / SAP S/4HANA Cloud Private Edition valuable. This scenario showcases yet another way how we're leveraging innovations in S/4HANA financial accounting.

Feedback welcome

 

 

3 Comments