The previous blog (link below) gave an overview of revaluations mostly from a business perspective. In this blog I’ll cover the SAP side.
The Correct Way to Handle Fixed Asset Revaluations in SAP with AR29N (Part 1)
The Correct Way to Handle Fixed Asset Revaluations in SAP with AR29N (Part 2)
The Correct Way to Handle Fixed Asset Revaluations in SAP with AR29N (Part 3)
History of the SAP Solution
For the record, SAP has always had a way to handle asset revaluations as far back as in R/3. There have always been high-inflationary driven countries that executed revaluations on a monthly basis. They usually need to consistently revalue their balance sheet based on an index. Another common requirement was to revalue the assets based on a transactional update. SAP has always had a way to handle both of these situations.
However, like most solutions, there were some limitations so SAP re-coded a new solution sometime back around 2003 or 2004. It was previously accessed at transaction AR29 and the new program at AR29N. As of S/4HANA, both transactions execute the same program because the old one has been permanently removed.
Benefits of Using AR29N For Revaluations
There are several reasons to use AR29N for revaluations
First, it’s easier than any other approach I can think of. If you have to manipulate the values of a single asset than you can usually use some combination of transaction types (standard or custom) to get what you want. There are several backdoors that I’m aware of to get the values correct no matter what the circumstances are. However, this is just on one asset. If you have to revalue an entire balance sheet over multiple company codes, that approach is just not scalable.
Some junior consultant would normally say at this time “well, I can write an LSMW to mass change all of them!”. That may be true but one thing I’ve learned over the years (decades actually) is that there can be a great amount of variety in the asset data. Some will require some combination of transaction type postings to be valuated correctly, other will require a different solution. Having to identify all of that and then go through a full QA process just isn’t feasible. The more you post, the more variations you uncover which leads to more solution complexity. Also, as you go down this road, you’re starting to pollute the data which makes it harder to validate. That’s a lot to juggle and ends up wasting time.
With AR29N you don’t have to worry about that. All you have to tell SAP is what the new asset value should be and AR29N will automatically make the appropriate posting for you. Zero out accumulated depreciation? Done. Leave A/D the same and just adjust the asset’s APC basis instead? Done. Change one asset’s APC basis up and another one down? Done… and at no time do I have to tell it which direction to go. I just provide the final target value.
Secondly, the solution supports a very wide variety of approaches to executing the revaluation. You can revalue a single asset’s values, post a depreciation adjustment, or use an index-based revaluation. Most importantly, the tool provides it’s own Excel-based file upload mechanism. Again, someone might say they can do this themselves in LSMW but you can’t execute an LSMW in test mode… AR29N supports a test run even during a file upload.
Next, this whole process is supported by SAP. They wrote a specific program to handle this specific requirement for revaluations and recommend that it be used for this requirement. I’d be highly skeptical of anyone pushing a solution other than AR29N for an asset revaluation in SAP. Honestly, anytime you are doing a particular process in SAP and choose a solution that is different than the one SAP specifically provides a solution for and supports… well, you better have a good justification for why you turned it down and went the custom route.
Want the Final Solution to Look Good?
Lastly, the main reason to use AR29N is that it makes the data and the assets themselves look the best. It posts the adjustment to both the asset’s APC and A/D reserve balances correctly as well as the upward/downward revision that is often necessary for appraisal-based revaluations. If you want certainty in the final solution to make sure that the balance sheet is correct and easily reported on, then using AR29N is the way to go.
As with most things in SAP, there are some items you’ll want to be aware of and address before working with AR29N.
Obviously, there is specific configuration related to the revaluation effort that has to be addressed. I don’t consider it particularly difficult or lengthy to work with.
But the major item that has to be addressed has to do with the posted depreciation in the FI-AA subledger. Early on in the coding of AR29N, the program does a check against the revaluation date and the last period that depreciation was posted for. If they’re not the same period, the program will error out. Additionally, in other parts of the program it is evaluating the posted depreciation.
This means one of two things. Either you have to change the coding or reverse the depreciation run.
Changing the coding is easily done via a BADI that SAP has delivered. Reversing depreciation is also easy IF you have the correct program to execute it. We’ve handled multiple revaluations and decided on reversing the depreciation run at all of them. We’ve done this over 100 company codes and 15 months of depreciation runs… yes, 15 months… which means we had to go back into prior closed fiscal years to get it done. This is not a trivial process and not one that I would recommend doing on your own unless you have a high degree of knowledge of all of the affected tables in the GL and FI-AA.
You can read more about this at the links below.
How Does it Work?
I’ll have to push the bulk of the screenshots with a specific example in the next blog, but here is how AR29N works.
The initial screen is below. The selection criteria at the top can be used to make some macro-level selections but I do most of the work in one of the tabs at the bottom.
As I said, the tool has it’s own upload utility which is on the 4th tab. The last one is for index based revaluations which isn’t typically implemented for most revaluation requirements.
I’ll go into more detail in the next blog.