Down payment 4 customer projects in S/4HANA
2024-1-15 05:43:59 Author: blogs.sap.com(查看原文) 阅读量:16 收藏

Co-Authored by Gabi Hoffmann and Stefan Walz

Welcome to this blog, in which we will show you the new integration of customer down payments in S/4HANA General Ledger and Event Based Revenue Recognition. Base for this functionality is the Universal Journal. The screenshots are taken out of a CE 2308 and OP 2023 system, the scenario is valid for public cloud and on premise.

We will start in this blog with a functional overview. Then we will show an end-to end process in the system based on the professional service tailored customer project scenario. We give some insights for customer projects in OP, which work like EPPM projects – alias projects – in public cloud. We will cover the two options in EBRR to react on the received down payment or not. We will close with deeper insights in the process control.

1.    Functional scope

The customer down payment request (DPR) is mapped in financials as an Account Receivables entry in the BSEG table, which stores Accounting Document Segment data, see figure 7. Until this solution there was no general ledger journal entry created and DPR and down payment received was not visible in project reporting/Controlling.

In a customer project scenario, we have the requirement to show the DPR and the down payment received in the project reports – as balance sheet values. There exists also an IFRS requirement for certain cases to offset down payments received with existing accrued revenues – to shorten the balance sheet values. To reflect these requirements, we have added additional journal entries:

  • The down payment request is now reflected in General Ledger – see figure 1 and 8.
  • The received customer down payment clears the DPR journal entry items and creates additional journal entry items with own liability G/L accounts – see figure 13.
  • To allow simple tracing in reporting, these JE items are posted with own SLA type: 8011 for DP request, 8010 for down payment received.

This new down payment posting logic works in public cloud only for customer project scenario. There are prerequisites in the sales order master:

  1. a wbs billing element must be assigned to the sales order item.
  2. the DP request must be maintained in the sales order billing plan.

The posting logic for down payment request and down payment received does not work for financial DP requests (App Manage Customer Down Payment Requests or transaction F-37).

To enable project reporting and additional EBRR functionality the liability journal entry items created by the DP request and the received down payment are account assigned to the wbs billing element and – same as for other actual postings – market segment fields are derived – see figure 1.

Figure1%3A%20reflection%20of%20the%20DP%20request%20in%20Universal%20Journal

Figure1: reflection of the DP request in Universal Journal

We use here the new capabilities in the Universal Journal to account assign even balance sheet accounts to co objects and attribute market segments, derived by the sales order item.

In S/4HANA the accounting applications General ledger, Controlling, event-based revenue recognition and margin analysis are now integrated in the Universal Journal, in which all actual data is stored. There is no separate data store for controlling, margin analysis or revenue recognition. All KPIs like realized revenues, cost of goods sold, margin per quantity unit or multilevel contribution margin are calculated based on journal entry items, stored in the Universal Journal single source of truth.

More about the account assignment of balance sheet and market segment attribution you can get in this blog: https://blogs.sap.com/2023/08/06/co-account-assignment-and-attribution-with-s-4hana/

In the current solution, release CE2402, there are no taxes applied for the down payment request, which covers the legal requirement for multiple countries like Germany. An overview about the functionality and a comparison with the pre-payment method on account, which is only available for professional service projects and T&E Billing, you get in figure 2.

Figure%202%3A%20Overview%20down%20payment%20functionality%20and%20Comparison%20with%20on%20account

Figure 2: Overview down payment functionality and Comparison with on account

Further information about the customer project processes you get here:
Financial Accounting for professional service tailored customer projects
Financial Accounting for EPPM customer projects in S/4HANA

2    system walkthrough – Down Payment in professional service projects

We will now show an end-to end process for a professional service project with a time and expense billing method: from the DPR to the customer invoice and the final revenue recognition posting.

First let’s look in the customer project billing plan with the app create or plan customer projects.

Figure%203%3A%20Down%20payment%20request%20maintained%20in%20the%20billing%20plan

Figure 3: Down payment request maintained in the billing plan

A down payment request of 1000 EUR is planned.

To create the DPR invoice, we start the app Manage project billing. We select our wbs billing element and enter button “prepayment” to get the pop-up “new prepayent for SW007.0.1”

Figure%204%3A%20app%20Manage%20project%20billing%20%u2013%20creating%20a%20DP%20request

Figure 4: app Manage project billing – creating a DP request

With submit we create a billing document request. We start app Create billing document and filter for the BDR:

Figure%205%3A%20app%20create%20billing%20document%20%u2013%20based%20on%20the%20billing%20document%20request

Figure 5: app create billing document – based on the billing document request

We select the row with the BDR and enter the button “create Billing documents”, The created billing document can be analyzed with the app Manage billing documents.

Figure%206%3A%20app%20Manage%20Billing%20documents%20with%20the%20DP%20request

Figure 6: app Manage Billing documents with the DP request

With the button “Post billing document” we create the financial documents.

Figure%207%3A%20update%20financial%20BSEG%20view%20for%20down%20payment%20request

Figure 7: update financial BSEG view for down payment request

The DP Request updates the open AR item in table BSEG. This always happens, when customer DP is requested. And it is the only update in FIN, if no special posting logic is activated in configuration.

In our example an additional General Ledger journal entry is created:

Figure%208%3A%20General%20Ledger%20document%20of%20the%20down%20payment%20request

Figure 8: General Ledger document of the down payment request

The G/L Ledger document contains two journal entry items with balance sheet accounts. The contract liability line item is account assigned to the billing wbs element (Account assignment type = PR) to allow controlling reporting – with new SLA type 8011.

  • with the account assignment to customer project the profitability segment is derived – like for the other actual postings on the project – see linked blogs above
  • This 8011, DPR; journal entry item is not relevant for revenue recognition!

To check project reporting, we start the app Project actuals.

Figure%209%3A%20down%20payment%20request%20is%20reflected%20in%20project%20reporting.

Figure 9: down payment request is reflected in project reporting.

The DP request, first line item, is visible in project reporting, like the also posted journal entry of time confirmation with the matching EBRR journal entry.

The Contract Liability DP request G/L account is, like the WIP/Accrued revenue account, a general balance sheet account – not open item managed.

Let’s have a look on the G/L account master for this liability account:

Figure%2010%3A%20G/L%20account%20master%20of%20the%20down%20payment%20request%20Liability

Figure 10: G/L account master of the down payment request Liability

The Contract Liability DP request G/L account, like the WIP/Accrued revenue account, is a general balance sheet account – not open item managed. (Remark for on premise: no cost element type 90 is used)

Now we post incoming payment (transaction F-28)

Figure%2011%3A%20creating%20incoming%20payment%20for%20down%20payment%20request

Figure 11: creating incoming payment for down payment request

With the button “select more” you can specify the filter criteria.

Figure%2012%3A%20filter%20options%20for%20the%20open%20item

Figure 12: filter options for the open item

We assign the created down payment request and post.

Figure%2013%3A%20journal%20entry%20for%20the%20down%20payment%20received

Figure 13: journal entry for the down payment received

The created Journal entry consists of 3 parts

  • The first 4 journal entry items (red part) reflect the received payment
  • The yellow part reflects the reversal of the down payment request (with clearing the balance sheet account with SLA type 8011)
  • The last 3 journal entries (blue part) is the reflection of the down payment received on a new „Liability from down payment“ G/L account (posted with SLA type 8010)

We account assign the wbs billing element in two journal entry items with SLA type 8010 and 8011. We analyze the project reporting with the app product and service margins.

Figure%2014%3A%20Product%20and%20service%20margin%20after%20down%20payment%20received.

Figure 14: Product and service margin after down payment received.

The received down payment, G/L account 21191100, is shown within project reporting in the column Deferred Revenue.

The down payment request, G/L account 21191200, is netted to zero.

Now let’s check the WIP details app, which provides additional analysis option for customer projects, which use Time and expense billing.

Figure%2015%3A%20WIP%20details%20after%20down%20payment%20received.

Figure 15: WIP details after down payment received.

In WIP details app there are own columns for Down payment requested, Down payment received and DP WIP netting – selection is done by SLA type.

The down payment requested is netted to zero. Down payment received are now 1000€ and the WIP, based on the time confirmation to the project, is shown with 1200€.

Now we start EBRR with the app “Event based revenue recognition – Projects”.

Figure%2016%3A%20EBRR%20simulating%20result%20%u2013%20netting%20of%20accrued%20revenue%20and%20down%20payment%20received.

Figure 16: EBRR simulating result – netting of accrued revenue and down payment received.

The Simulation result shows that the down payment liability of 1000€ is taken in account by rev rec. The accrued revenue decreases from 1200€ to 200€.

With posting we get the following journal entries:

Figure%2017%3A%20EBRR%20Journal%20entry%20for%20netting

Figure 17: EBRR Journal entry for netting

EBRR offsets the two balance sheet accounts accrued revenue and liabilities from down payments received.

The  described netting is one option for EBRR to react on the down payment received. Another option is that there is no netting between accrued revenue and contract liability for received down payments. Chapter 4 describes how this is controlled.

We check the result in the app WIP details

Figure%2018%3A%20WIP%20details%20after%20netting

Figure 18: WIP details after netting

The WIP details app shows now:

  • A reduced WIP of 200€. Remark: the billable revenue in next column is untouched of course and still 1200€
  • The down payment request is balanced to zero.
  • The column DP WIP netting shows the amount reduced by WIP.

As a next step we bill the complete billable amount of 1200€ and use the received down payment amount of 1000€ (these are net amounts without taxes).

The billing leads to the following journal entries:

Figure%2019%3A%20journal%20entry%20of%20the%20final%20billing

Figure 19: journal entry of the final billing

The JE for billing shows the billed amount of 1200€. The complete down payment amount is used and thus the contract liability from DP received G/L account is balanced to zero (Journal entry with SLA type 8010)

The second Journal entry is the matching EBRR document, which defers the billed revenue.

As next step we run EBRR for clearing the balances of the balance sheet accounts.

The EBRR posting leads to following journal entry.

Figure%2020%3A%20Journal%20entry%20of%20EBRR%20run%20%u2013%20final%20netting%20of%20accrued%20and%20deferred%20revenues%20and%20liability

Figure 20: Journal entry of EBRR run – final netting of accrued and deferred revenues and liability

The journal entry consists of two parts:

  • Line 1 and 3 nets the balances of the accrued and deferred revenue
  • Line 2 and 4 reverses the previous down payment received netting.

Let’s look on the final view in the WIP details app:

Figure%2021%3A%20WIP%20details%20final%20view.

Figure 21: WIP details final view.

All values are now balanced to zero.

The same you get of course in the product and service margins app.

Figure%2022%3A%20product%20and%20service%20margin%20-%20final%20view

Figure 22: product and service margin – final view

An Overview of the posted journal entries by T-account you can get in figure 23.

Figure%2023%3A%20Posted%20journal%20entries%20in%20T-account%20view

Figure 23: Posted journal entries in T-account view

3.    Down payment example for EPPM projects and customer projects in on prem

We start with the sales order maintenance in on premise (transaction VA02).

Figure%2024%3A%20sales%20order%20item%20assigned%20to%20customer%20project.

Figure 24: sales order item assigned to customer project.

We account assign a billing wbs element, here SW-Mario1, to the sales order item.

Figure%2025%3A%20billing%20plan%20with%20DPR%20item

Figure 25: billing plan with DPR item

The first item in figure 25 reflects the down payment request – with an own billing type FAZ.

We invoice the due down payment request with transaction VF01 with relation to the sales order.

Figure%2026%3A%20DPR%20invoice

Figure 26: DPR invoice

The journal entry document of the down payment invoice you get here:

Figure%2026%3A%20DPR%20invoice

Figure 27: journal entry ofDPR invoice

The created journal entry looks similar as our example for the public cloud example – figure 8.

How you activate these postings in on premise we show in the next chapter.

4 control for G/L document creation and EBRR

the configuration consists of two parts:

  • the netting of accrued revenue and received down payment in EBRR
  • the journal entries creation, which is a prerequisite for the EBRR netting, without the activation you get only the BSEG entry for DP request and no liability JE item for the down payment received, so not the journal entry items with SLA type 8011 and 8010.

Activation of journal entries creation

In public cloud the journal entry creation is always active, if you use a ledger with IFRS accounting principle. In this case the new posting logic is active for all parallel ledger – including those with different accounting principles. There is no config available.

In on premise you need to activate the new posting logic in configuration. There are multiple steps required, which we list in the following.

There is an IMG view FINSV_AP_CNTRL_C available with which you can activate the DP posting logic per ledger.

Figure%2027%3A%20IMG%20node%20for%20activation%20of%20G/L%20postings

Figure 27: IMG node for activation of G/L postings

The details you get in the next screen.

Figure%2028%3A%20activation%20of%20G/L%20journal%20entries%20per%20ledger

Figure 28: activation of G/L journal entries per ledger

Here for German GAAP, DEAP, and IFRS the new posting logic is active.

Additionally, you need to assign G/L accounts in the account determination SSCUI. In on premise with transaction FBKP you get the following screen:

Figure%2029%3A%20G/L%20account%20determination%20-%20groups

Figure 29: G/L account determination – groups

Within the down payment posting group you need to activate G/L account determination for the transactions DPL and DPR.

Figure%2030%3A%20G/L%20account%20determination%20%u2013%20account%20determination%20activation%20for%20down%20payment%20process

Figure 30: G/L account determination – account determination activation for down payment process

Behind the two account determination transactions you can assign the balance sheet G/L accounts:

Figure%2031%3A%20G/L%20account%20determination%20for%20liability%20of%20received%20payment

Figure 31: G/L account determination for liability of received payment

Figure%2031%3A%20G/L%20account%20determination%20for%20down%20payment%20request

Figure 31: G/L account determination for down payment request

Activation of DP netting in event-based revenue recognition

In public cloud the netting of accrued revenue and the liabilities created by down payment request for customer projects is always active. There is no SSCUI available.

In on premise, you need to activate it per expert config. Transaction SM30 table FINS_TRR_CNTRL.

Figure%2032%3A%20required%20expert%20config%20in%20on%20premise.

Figure 32: required expert config in on premise.

With the parameter ROD you activate that EBRR includes additional postings on account assigned balance sheet accounts.

With the parameter CDU you can deactivate netting in general. But you can activate per assignment rule with usage 106.

  • With CDU:Blank – like you see it in figure 32 – the netting is for all methods active. There is no the netting.
  • With CDU=X the netting is in general inactive. Y

Closing remarks

We hope you enjoyed these insights into down payment handling in customer projects in S/4HANA. It is another scenario, in which we are now benefiting from the innovations in financial accounting.

Feedback welcome


文章来源: https://blogs.sap.com/2024/01/14/down-payment-4-customer-projects-in-s-4hana/
如有侵权请联系:admin#unsafe.sh