cancel
Showing results for 
Search instead for 
Did you mean: 

Legacy data transfer and Make company code settings - Asset Accounting specific - different FYV

maekman
Explorer
0 Kudos
225

Hi,

we have a client moving from ECC to S/4HANA Public cloud and we are trying to get fixed asset values to reconcile. The target system uses fiscal year variant K4 (Cal year + 4 special periods) and in ECC their fiscal year has been 01.08-31.07. Their aim is to extend their current fiscal year so that it will last from 31.08.2024-31.12.2025.

Asset transfer date is 31.04-2025 so for go-live in the middle of the year we aim to take in legacy asset values for the situation per 31.12 and then add the 2025 transactions. When doing like this, we face a reconciliation difference between ECC and S4 in between book and tax. The amount appears to be the 5 periods of depreciations in year 2024. 

What settings should be change to overcome this reconciliation difference? I was already thinking of app Make company code settings - Asset Accounting specific and there in Depreciation area settings change the last day of last closed fiscal year to 31.07.2024 but the system does not allow me to do that. 

Please let me know what other options we have?

-ME-

I was thinking that this setting could be 

 

Accepted Solutions (0)

Answers (2)

Answers (2)

maekman
Explorer
0 Kudos

Hi,

thank you NorbertB for a very good and clear reply.  

Our customer has now tested this and reports as follows.

To cumulative values they put the situation of 31.7 in ECC and to posted values (area32)1.8.2024-28.2.2025 book depreciation. 

The result is that S4 posts book depreciations for 01.08.2024-28.02.2025 (go-live in TEST 1.3.2025) to period 1 and in period 2 S4 is correcting the depreciation from previous period. 

Is this how you meant to use the dates and cumulative/posted values? 

Thanks for your comments again,

-ME-

NorbertB
Product and Topic Expert
Product and Topic Expert
0 Kudos
Hi, yes the tabs and dates you mention here is aligned with the previous explanation.
NorbertB
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi,

 

you can use FYV SZ and configure it as you wish. With the current FYV K4, the desired outcome is hardly possible.

However, the FYV assignment is a very early step, with no option to change it later. The selected fiscal year variant will apply to your entire system.
If your system is still on early phase (no journal entry, no org. structure) you can change the assigned variant from K4 to SZ.

Check out this HelpPortal topic: https://help.sap.com/docs/SAP_S4HANA_CLOUD/0fa84c9d9c634132b7c4abb9ffdd8f06/497a54d1c7714de69a4b1fa3...

maekman
Explorer
0 Kudos
Hi, thank you Norbert! We are already in testing phase so we cannot change the K4. Anyway, even if this could be the solution for the first go-live I don´t think that the change needs to be done this drastic. What if our client acquires another company code with again another fiscal period different from our client´s, how should we prepare for that asset transfer from legacy?
NorbertB
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi,
I guess the 5 period depreciation amount difference is coming from the fact that you take over the values from your ECC system with date 12/31/2024. While the last day of FY in your ECC is 07/31/2024. So, to match the year end dates between the ECC and Cloud, it would be 07/31/2024 (own FYV) = 12/31/2024 (K4 FYV).
If you take 12/31/2024 from your ECC it will already include the 5 periods from FY 2025 and uploading those values to Cloud will end up messing up the values.

How I would do it, get the amounts from your ECC system with date 07/31/2024, those are the Cumulative values. And all the postings afterwards are current year values, they should go under Posted values. Starting from 01/08/2024 until the actual legacy transfer date: 30/04/2025.

The initial idea to overwrite the last day of closed FY is not possible. Those dates are coming from the FYV settings. Any FYV that's not the same as your ECC settings will behave differently.