Professional Documents
Culture Documents
S/4 HANA
(/blog/2017/8/28/introducing- H AV E A S I M I L A R
new-asset-accounting) SAP QUESTION?
First Name
Last Name
Email Address
Introduction
SIGN UP
I will start by giving you a bit of background on New Asset Accounting and
S/4HANA, and then I will run through some of the key changes that were
introduced which distinguish it from Classic Asset Accounting. Next, I will go into
some more detail on some of the larger areas, for example how the depreciation
areas work with the ledgers to record the different accounting principles. You may
already have heard of the Universal Journal, which is one of the biggest
innovations in Finance in S/HANA. I will explain what that is and how New Asset
Accounting integrates with it and how the new asset transactions work. I will also
run through the depreciation and finally I will briefly touch on the migration of
assets.
assets.
Background
The first version of New Asset Accounting was actually introduced in 2013 on SAP
ECC6 Enhancement Pack 7. So, if you’re not on S/4HANA but you’ve already
implemented the New General ledger, you can still get New Asset Accounting,
although you need to activate some business functions first and you won’t have
the full functionality until you are on S/4HANA.
Initially the SAP Business Suite simply ran faster on the new in-memory HANA
database, with its super fast processing speeds. With S/4HANA, SAP has rewritten
and partly redesigned some areas to take advantage of the increased power and to
run with greater efficiency.
New Asset Accounting is one of the areas that was further optimized to run on
S/4HANA with additional functionality and a new data structure along with full
integration to Finance via the Universal Journal and the ACDOCA table.
Only the New Asset Accounting and the New General Ledger versions are available
on S/4HANA. The New General Ledger is now officially called the SAP S/4HANA
General Ledger, by the way. You don’t have to implement all the functionality of
either, but you won’t be able to use the old classic versions any more on S/4
HANA.
The actual components of the asset module haven’t changed much, so you still
assign your company code to a local chart of depreciation where you have most of
the local rules for calculating the depreciation, such as straight line or reducing
balance methods, and whether to start depreciating at the beginning, middle or
end of a period and so on. The account assignment, screen layout and default
useful lives are still linked to asset classes, which group together assets of a
similar nature, and you still have the concept of depreciation areas to record
different values for different accounting principles.
However, there have been many improvements in different areas and a much tighter
integration to finance, which you can see straight away if you are migrating fixed
assets from a legacy system. You no longer post the asset master data and values
together and then later post a summary journal to finance. Now, similar to the
accounts payable and accounts receivable sub-ledgers, you create the master data
first and separately post the value to the asset and simultaneously to the general
ledger.
A common phrase you may hear a lot in relation to S/4HANA is the Single Source
of Truth. In S/4HANA, Finance and Controlling have been merged; and Asset
Accounting and even Profitability Analysis all create entries directly to the
ACDOCA table in Finance. In other words, you now have everything in one place.
Additi l ti i i l l h t b t d i di ll i t d
Additional accounting principles no longer have to be posted periodically; instead
all accounting principles post real-time and at the same time. Because the accounts
are reconciliation accounts in all ledgers, you can’t post only to the general ledger
and not to the asset. Altogether, this means that you how have everything in sync
with everything else, which has got to be one of the biggest advantages, especially
for us accountants.
In addition, asset postings are transferred to finance at asset level and more asset
information is now available in finance, so you can run financial reports by asset
number for example in the general ledger line item display transaction. You also
don’t have to wait until the period end to see values in the parallel ledgers, and
even the planned depreciation is always up to date.
The table in Figure 1 shows some examples of transactions that have changed with
S/4HANA. Although many of you will be using Fiori to access the S/4HANA
transactions, particularly if you are using the public Cloud version of S/4HANA,
quite a lot of the S/4HANA transactions are very similar whether you are using the
SAP GUI or the Fiori equivalent. I thought it would be easier to show the
transaction codes so you could compare the ECC transactions and see what has
changed. Also, I’m sure some of you will still want to explore the SAP GUI
transaction codes on the on-premise version, even if you have Fiori, or intend to
implement Fiori later.
As the asset and general ledger values are now in the same table (ACDOCA), the
consistency and reconciliation transactions are now obsolete and do not even exist
in S/4HANA. All ledgers post real-time, so the periodic posting transaction is also
now obsolete. One of the migration prerequisites by the way, is to complete all
periodic postings before the migration, as you won’t be able to post them
afterwards without that transaction.
Prior to S/4HANA, in a legacy migration, after you had uploaded the asset master
data and the related values to asset accounting, you could then use Transaction
OASV in order to post those values to the general ledger. Now, as both the asset
and the general ledger are posted to simultaneously, this transaction is no longer
required.
The legacy Transaction AS91 can no longer be used to post the values to an asset,
but you can still create the master data with it and post the values to both the
asset and finance with Transaction ABLDT.
The post depreciation transaction AFAB, like the calculate planned depreciation
e post dep ec at o t a sact o , e t e ca cu ate p a ed dep ec at o
Transaction AFAR has the same transaction code but there is a different program
underneath and a slightly different selection screen. I will explain these differences
in the depreciation section shortly.
Finally, a number of transactions now contain an L at the end to signify that you
can post to different ledger groups, for example ABAA is now ABAAL. In fact, if you
try to select the old code on S/4HANA by mistake, you will see that you have been
redirected to the new code anyway. Previously, you had to set up specific
transaction types if you wanted to post to one ledger and not another.
Originally the only way to record different accounting principles in Finance, for
example local GAAP and IFRS or Group Accounts, was to use different number
ranges in the chart of accounts. When the New General Ledger was introduced in
SAP, your main ledger then became your leading ledger and you could set up
parallel ledgers with identical GL accounts instead of using different number
ranges. Most postings would update all the ledgers together, but if the accounting
treatment for something was different in one of the parallel ledgers, for example an
accrual, you could post an adjustment just to that ledger, by selecting its ledger
group in the transaction.
Depreciation area one posted to the leading ledger real-time and you could map
the other depreciation areas to the parallel ledgers and post them at the end of
the period; but for technical reasons you also had to create delta depreciation
areas.
You still have the option to use the accounts approach or the ledger approach for
your different accounting principles. The accounts approach may be a better choice
if you have only a few differences between the two accounting principles. However,
in S/4HANA, you still have to assign a ledger group to each accounting principle in
the configuration, even though each ledger group will contain only the leading
ledger as you won’t have any other ledgers with the accounts approach.
You also no longer need delta depreciation areas, but, if you want to have
additional currencies in one ledger you have to set up additional depreciation areas
for those currencies in the asset module.
When you assign the accounting principle to each depreciation area, it then pulls in
the target ledger group that is assigned in the financial configuration, to that
accounting principle. Usually there is one ledger in the group with the same name
as the ledger group.
All depreciation areas are now equal, which means that you can choose any
depreciation area to be the main accounting principle and linked to the leading
ledger. More than one area can be set to post real-time to both the asset and to
the general ledger, and you can choose which depreciation area updates quantities.
Because of the power of S/4HANA, you no longer need to split data into a number
of tables with additional totals tables and special programs for managing and
storing the indexing, summarizing and aggregations etc. The actual data from the
various asset value tables can now be stored in the single finance table ACDOCA,
with the header data in BKPF, and the statistical, planned and year dependent data
stored in the other tables in Figure 3, for example FAAT_PLAN_VALUES.
Don’t worry though, if you have a lot of bespoke programs which use the old
tables. Although the old tables no longer exist, the programs will still work, as long
as you are just reading the tables and not writing directly to them. This is because
of something called compatibility views. These are views, which are recreated from
the new tables such as ACDOCA, but linked to the old table names such as ANEP,
ANEK and so on, so you can still read the data, but you would not be able to
update anything in that view.
Figure 3 New table Structure in New Asset Accounting
The Technical Clearing Account is a new account that has been introduced for
accounts that cannot be posted to in a single ledger only. If you’ve set up parallel
ledgers in the New General Ledger, you will know that there are certain accounts
that the system will not let you post to in one ledger and not another. If you
receive an invoice from a supplier for 100 dollars, you cannot record it against that
supplier as anything other than 100 dollars in all ledgers and the amount you pay
against it will be the same in all ledgers along with any related taxes. By the same
logic, the GR/IR accounts (where you post the goods receipts and invoices
received) and the customer accounts have to be posted to all ledgers at the same
time as well.
You can see in the Figure 4, that the Technical Clearing Account allows you to do
this by posting the first document to all ledgers, crediting the supplier and
debiting the technical clearing account. This is called the operating part of the
posting. Then you can post the other side in two separate documents one to each
ledger. This is called the valuating part of the transaction. The valuating part
credits the technical clearing account and debits the assets separately for each
ledger, or posts to costs instead. An additional posting is required if for one ledger,
you need to post for example to freight, or legal fees or whatever the policies of
the other accounting principle requires.
Figure 4 The Technical Clearing Account
The Technical Clearing account is a reconciliation account and works in the same
way for both account and ledger approaches, and you can also have more than one
technical clearing account. It is defined in the configuration by Chart of Accounts
and account determination, so you could have a different account by asset class
assuming your account determination is mapped closely with your asset class.
This is different to the normal clearing account for asset acquisition which still
exists and behaves in the same way for transactions such as the acquisition
ABZON where there is no automatic offsetting account.
Figure 5 shows that you can still create different settlement rules, for example
settling to an asset in the leading ledger 0L, but settling to a cost center for the
parallel ledger in this case ledger 2L.
You can no longer set a transaction type to be ledger specific. Instead you can
select the ledger by choosing the depreciation area or the accounting principle in
the new transaction codes, for example Asset Retirement by Scrapping, Transaction
ABAVL.
Figure 6 Transaction Types are no longer ledger specific
Because Finance and Controlling are merged in S/4HANA, there are no more cost
elements. instead, the chart of accounts master data contains a new field for the
P&L cost element categories. However, this does not include cost element category
90 which was used for statistical postings to the Balance Sheet so that you could
link internal orders and WBS elements to balance Sheet accounts. Instead we have
a new check box in the chart of accounts to allow you to apply account
assignments statistically in the fixed asset accounts and the material accounts see
Figure 7.
Now we come to the depreciation programs. There are a few changes in this area,
for example speed, different selection screen options, and under the hood (or
bonnet in the UK) there is a new Depreciation Calculation Engine, which you may
have heard of and be wondering what it does.
The first thing you will notice when you enter the depreciation transaction AFAB, is
that the selection screen is simplified, as you can see in Figure 8. Previously, if I
had to rerun the depreciation in a particular period I always had to think for a
had to rerun the depreciation in a particular period, I always had to think for a
minute which button to choose, now the system figures it out automatically.
The second point is that you can still run the depreciation for all accounting
principles at the same time, or you can choose to run it for the different accounting
principles separately.
I find the new icon at the top of the screen, called “info for posting parameters”,
particularly useful in test environments, so that I can quickly find when
depreciation was last posted.
The main difference in S/4HANA for transaction AFAR, the calculation of the
planned depreciation, and Transaction AFBP, the depreciation posting log, is again
the option to run by accounting principle. In the depreciation log, when you run the
transaction, you will see a button marked “Notes on Use” at the top, which explains
in detail the additional functionality.
Now, as you can see in Figure 9, the transactions are grouped by period and the
depreciation is calculated based on periods. So, in this example, instead of
calculating depreciation on the original amount of 1,000 for the whole year and
deducting and adding retirements and additional acquisitions, you take the balance
of each period and calculate it separately.
Figure 9 The New Depreciation Calculation Engine
The second option, system conversion is less disruption and you keep your
transaction history, but it is only available for on-premise S/4HANA versions.
The New General Ledger is the only ledger available in S/4HANA, but if you don’t
have it already, and want to use the full functionality, for example the parallel
ledgers and document splitting, a separate project to migrate to New General
Ledger prior to S/4HANA may be advisable.
Document splitting at the moment cannot be implemented once you convert your
data to S/4HANA, although the functionality should be available in the next on-
premise version 1709. Adding parallel ledgers on S/4HANA which wasn’t initially
available, is now available from the 1610 version. Of course, timing is important,
because whereas you can migrate to S/4HANA at any period end, you need a fiscal
year end to do a full New General Ledger migration.
During the migration, there are a number of checks and adjustments to be done, for
example for the cost elements during the merge of finance and controlling, and
ensuring everything has the correct fiscal year variant. It is particularly important
to get the asset module correctly aligned with finance, especially if you have
additional accounting principles in both
additional accounting principles in both.
The exact changes that you will need to carry out will depend on your existing and
planned configuration. If you already have parallel ledgers you will need to match
the depreciation areas to the parallel ledgers and currencies using the accounting
principles. If you plan to use the accounts approach for different accounting
principles you need to set up ledger groups and tick the new flag in the ledger
configuration for parallel accounting using GL accounts.
You also need to create your technical clearing account, and change the asset
accounts to reconciliation accounts for the non-leading ledgers (the leading ledger
should already have reconciliation accounts). If you have any transaction types that
are applicable to only one ledger, you will need to mark them as obsolete as you
will no longer be able to use them. There are also some additional flags to verify
for net book value retirements and revenue distribution.
Only one fiscal year can be open during migration and the last year cannot be
reopened after migration, but you can still run reports for prior years.
Obviously, the usual rules of reconciling everything before you start and running
reports before and after to compare and check the figures apply. In particular you
should reconcile asset accounting with the general ledger using transactions such
as ABST and ABST2. There are many standard asset reports such as asset balances,
asset history, planned depreciation and so on that you can run both before and
after the migration.
If you are used to using the LSMW (which stands for the Legacy System Migration
Workbench), the bad news is that it has not been fully converted to the new table
structures and methods of posting, so SAP do not recommend to use it in the same
way as before. (see their Simplification List of new functionalities released for the
1610 on-premise version). The new transaction ABLDT to post the legacy
values, uses an input enabled ALV grid control, so it can’t be used with batch input
and therefore can’t be used by the LSMW. Instead SAP suggest three options to
transfer your data depending on the quantity of data that you have.
If you have a small amount of data, you can still use transaction AS91 to create the
asset master data, but the take-over values button is grayed out so you can no
longer enter values and need to use the new transaction ABLDT for the values. The
reason for this is that the posting of the value now creates a Universal Journal
document which posts between the asset and finance, and therefore the asset has
to exist before the posting can be made. Hence you have to save the asset first
and then go into a different transaction to post the value. ABLDT however, posts
directly to the migration account so you don’t need to make any additional
postings.
For medium amounts of data SAP recommend to use transaction AS100 and for
larger amounts to use the BAPI_FIXEDASSET_OVRTAKE_CREATE (see OSS note
2208321). Note that the BAPI only supports new assets, not the transfer of
amounts to an existing asset or the correction of values previously transported.
(/blog/?author=57f28a5729687faa60ffa2e7)
OFLANAGAN
Oona Flanagan is an expert Fixer, a qualified accountant and an S/4 HANA consultant
who has spent over 17 years as an SAP FICO Consultant for a number of multinational
projects, mainly in Europe. She has covered all aspects of the implementations, support
and training for many well-known companies such as SAP themselves, Unilever, Coca
Cola, Burberry, Danone, Britvic, BNP Paribas, Deloitte, Uniphar, Bombardier, Moet
Hennessy. Author of several SAP Press E-Bites on the GR/IR and the payment program
and more recently: "Introducing New Asset Accounting in SAP S/4HANA
(https://www.sap-press.com/introducing-new-asset-accounting-in-sap-s4hana-fi-
aa_4415/)".
10 Likes Share
F I X E R P R O C E SS ( / H OW - TO - F I X / )
MEMBER PROCESS (/MEMBER-PROCESS/)
M O D U L E S L I ST ( / M O D U L E S - L I ST / )
(http://www.asug.com)