There are numerous changes that SAP has made in New Asset Accounting for S/4HANA. Today, I’ll focus on the changes with the depreciation posting run from ECC to S/4HANA because it is so core to the fixed asset solution.
What has changed?
For starters, it’s an entirely new program. We can still use the previous AFAB transaction code but it is now mapped to a new program; FAA_DEPRECIATION_POST. The old programs RAPOST2000 and RAPOST2010 are no longer delivered or available. Here is what the new program looks like:
Now for some details. I’ll go through the top 10 changes between ECC and S/4HANA.
10. Both the AFAB and AFABN transaction codes map to FAA_DEPRECIATION_POST, but only AFAB is really needed. AFAB used to be mapped to an (even) older depreciation program but now the tcodes are defined the same. When in doubt, save a keystroke and just use AFAB.
9. There is a new button at the top [Info for Posting Parameters]. This will display the basics of the most recent execution run per company and accounting principle. Previously, the only way to figure out what period was last posted was to look at table T093D or TABA. This feature brings that same posting status information to the user side. This was available previously in ECC but required the activation of a business function. Now it’s available for everyone.
8. As with the previous program, you’ll see options regarding parallel processing options on the selection screen but how they’re used has changed. In ECC, the posting program would only run in parallel if a server group was specified. Most customers never did this. If you leave the Server Group blank in S/4HANA, it has the opposite effect. In this case it will always run in parallel on all available servers using the number of processes specified (10 is the default). In order to control how that parallelization works you would have to configure a server group accordingly.
7. We still have a test run option but SAP has removed the [Error Analysis] option. You can read more about it here: Making error analysis easier when running depreciation. The reason being that the details of which asset caused the error is now more accessible with the new program. This feature wasn’t needed anymore.
6. SAP has also removed two other seldom used options. No longer can we separately list the documents related to manual depreciation in the output log. Another option to not output the specific simulated documents when running a test mode in the background is no longer available.
5. The selection screen has changed in a few noticeable ways. First, the four options under “Reason for Posting Run” are no longer available. For some reason, customers ocassionally struggled with determine what type of execution run they should choose. The new program will correctly determine what type of run you are making so the options are no longer there.
4. You can now execute the depreciation run for multiple company codes. Previously in ECC, it was only possible to execute depreciation for a range of company codes by directly executing program RAPOST2010. RAPOST2010 wasn’t mapped to any tcode so few customers were aware of it. Now in S/4HANA, the main (and only) program allows you to execute it for multiple company codes.
3. We now have the control as to what accounting principles we want to run it for. If left blank, it will run for all available accounting principles that post to the GL. If you wanted to control the timing of how each accounting principle was posted to, you now have the capability to do so.
2. A major change that SAP has made has to do with errors that hold up the depreciation run. In the past, the FI document created by the depreciation run would only post to the GL if there were no errors in the group of assets that it was posting for. If even a single asset had an error (ex. blocked cost center) than all of the other assets that were summarized in that particular FI document would also not get posted. This led to cases where some of the FI documents from the depreciation run would be able to post but others wouldn’t. You had to then execute the program in Restart mode after you fixed the underlying error. This is no longer the case in S/4HANA. The good assets are allowed to post and only the assets that errored out will be held back. You can even complete the rest of your month end close and move on to the next period in this situation. However, at year end, you’ll need 100% accuracy in order to close out the fiscal year so you have to deal with the errors eventually… but the point is that a single error on one asset won’t hold up the posting of depreciation for other assets.
1. The biggest change that SAP made with this program is related to ACDOCA. We now have a far greater level of posting detail which allows us to report (at the GL level) how each asset posted per accounting principle and fiscal period. Previously, SAP used some extensive logic to summarize the asset data when it was creating the FI documents. First, the old program would update it’s own table to track the posted depreciation per asset and period; ANLP. Then it would move on to the GL postings. First, it would summarize the depreciation values for every account determination (cost object -X- GL account) and would construct it’s own internal asset document. Then it would roll up these asset documents into multiple line items in an FI document. Once the FI document reached 100 line items, SAP would post it and start working on another FI document (Note: this 100 line item determination could be modified). This is why you sometimes have thousands of assets that are depreciating but you only get 4-5 FI documents per run.
The downside to this approach was that we could not (at a GL level) confirm what amount actually posted per asset and period. ANLP had that information but not BSEG. Now, ACDOCA will show us the amounts posted per asset, per period, and per accounting principle (depreciation area).
In the below screenshot is a document posted by FAA_DEPRECIATION_POST. While the asset field isn’t shown, the description column shows the asset number that is credited in each line item. This is the big change; we can now see the posted depreciation at an asset level from within the GL.
The underlying source is ACDOCA. For this same FI document, the table is recording the data per…
- Ledger (accounting principle)
- Depreciation area (that posts to the GL)
- Asset
- Fiscal year/period
- Depreciation period
There are also several other technical items that make it easy to report on the specific traits of this transaction.
What hasn’t changed?
- Regrettably, we still have the 1,000 asset record limitation when the program is run in the foreground.
- In order to do an update run, we are still required to execute it in the background. A foreground run will only be allowed if it’s a test run.
- While we have control over which companies and accounting principles will post in update mode, we can only restrict the program at an asset level during a test run.
- Just as in RAPOST2000, locked cost objects are checked and errors will be issued accordingly. In releases prior to ECC with program RABUCH00, this was not the case and a separate program RAANALYZE01 had to be run to catch these situations in advance.
- Similarly, this program is making a direct FI posting. RABUCH00 generated a BDC but SAP has moved on from that.
- A lot of the checks being made haven’t changed either. The new program still looks for incorrect account assignment (locked cost objects, end-dated cost centers), account assignment types, missing GL accounts, missing settings for the depreciation posting cycle, and incorrect posting period information that was entered at run time.
- The number range must still be internally defined.
- The posting program log (program RAPOST2001) has also not changed.
What are the benefits?
What will you actually get out of this change?
First, the process to post depreciation should be simpler to execute. Regarding the previously mentioned four execution type options (planned, repeat, etc.) that the user had to select before scheduling the job… Each execution type was documented and had a logical reason for being included in the program. But for some reason, there were still some folks struggling with determining which option to choose. With the new program able to correctly determine the execution type automatically, it should make the program easier to use.
Next, the change in the error treatment is potentially a bigger issue. For those customers that happen to have a particularly hectic month end and are dealing with some error that they don’t have time to deal with, they’ll still be able to post a large majority of the depreciation run for that period. Maybe that will be appreciated at some customers but most of the customers I’ve dealt with are too regimented about their month end process to let even a few percent of depreciation expense slide over to the next month. That’s true if they’re the ones running the program, but in the current corporate environment that is highly reliant on offshore resources doing the job scheduling and job management, maybe they won’t pay as much attention to this. That could lead to a surprise at year end when they are required to post with 100% accuracy.
The new program is supposed to be much faster in it’s execution. The biggest change is that the program no longer has to read ANLC and calculate the planned amount to be posted per asset. This was an expensive read of a large table. Now in S/4HANA, the program just reads FAAT_PLAN_VALUES for the appropriate period to be posted… and it’s doing so in parallel across all available servers… and then starts writing the FI documents. I personally haven’t experienced any noticeable benefit but for a large enough dataset… I’m thinking of FAAT_PLAN_VALUES having 100’s of millions of records… then I could imagine HANA quickly slicing through that portion of the process. The time required to prepare and post the FI documents is another body of work though. Because the program is posting more detail in the FI documents, the documents themselves are bigger and contain far more line items so there is more to post.
The biggest benefit though will be the increased GL detail. Now that the integration between FI-AA and the GL is much tighter in S/4HANA as compared to ECC, it’s good to see that we have greater asset details in the actual FI documents. I like that I can query ACDOCA on such a large number of distinguishing characteristics (SLALITTYPE is my favorite) and it’s helpful that the depreciation line items now store the asset level information.
