Page tree
Skip to end of metadata
Go to start of metadata

Basics on postings and the main database tables in asset accounting

Author: D021502



Tables For Postings

Postings in Asset Accounting create or modifies entries in the following tables:

  • ANEK (Document Header Asset Posting)
  • ANEP (Asset Line Items)
  • ANEA (Proportional Values: mostly for retirements and retiring transfers)
  • ANLC (asset values summarized on area and year level)
  • ANLB (only for the very first posting on the asset; table is updated)
  • ANLA (aquisition date, deactivation date, origin)

Fields of Posting Tables

The most important fields are explained in the following slides:
The following fields belong to the tables ANEP, ANEA, ANEK:

  • BUKRS: company code
  • ANLN1: asset main number
  • ANLN2: asset sub number
  • GJAHR: fiscal year
  • LNRAN: number of the asset line item

Table ANEK

The following important fields belong to table ANEK:

  • CPUDT, CPUTM: System date of posting
  • TCODE: Transaction code, which was used for posting
  • ANLU1, ANLU2: Asset number of acquired/retired asset for transfer or intercompany transfers
  • BELNR: document number (FI or reference number)
  • AWTYP, AWORG, AWSYS: fields which are the unique link to the corresponding FI document.

Table ANEP

Table ANEP consists of the following important fields:

  • AFABE: depreciation area
  • BELNR: document number (or reference number)
  • BWASL: transaction type
  • ANBTR: APC amount of the posting
  • NAFAB, SAFAB, ZINSB: ordinary, special depreciation, interest on transaction (not valid anymore for the new depreciation engine!)
  • XANTW: indicator, that proportional values exists (XANTW = X, if there are entries in table ANEA)
  • LNSAN: line item number of the reversal document
  • AUGLN: number of the clearing line items (is set by the AuC settlement)

Table ANEA

Table ANEA is filled if proportional values/value adjustments have to be considered, e.g. for retirements and transfers.
In table ANEP field XANTW is set to X
The following important fields are part of table ANEA:

  • AFABE: depreciation area
  • NAFAV, SAFAV, AAFAV: proportional value adjustments of previous fiscal years
  • NAFAL, SAFAL, AAFAL: proportional value adjustments of current fiscal year

Table ANLC

In table ANLC the sum of all asset values are listed per asset, depreciation area and fiscal year :

  • BUKRS: company code
  • ANLN1, ANLN2 : asset number
  • GJAHR: fiscal year
  • AFABE: depreciation area
  • KANSW: accumulated APC values
  • KNAFA, KSAFA, KAAFA: accumulated ordinary, special, unplanned depreciation

Further fields of table ANLC per company code, asset, depreciation area, fiscal year:

  • NAFAP, SAFAP, AAFAP: Planned ordinary, special, unplanned depreciation of the current fiscal year
  • NAFAG, SAFAG, AAFAG: Posted ordinary, special, unplanned depreciation of the current fiscal year
  • ANSWL: sum of all the changes of the APC value
  • NAFAV, SAFAV, AAFAV: Proportional depreciation of previous years
  • NAFAL, SAFAL, AAFAL: Proportional depreciation of the current fiscal year

Example

Example: Posting of an acquisition of 1200 Euro for asset 4711 in company code 1000 on 1.1.2008.
A FI document is created that looks like:



BSCHL means posting key.Posting key 70 ist for debit postings to an asset reconciliation account.Posting key 50 is for credit postings to for example clearing accounts.

The acquisition affects table ANEK in the following way:
An asset line item with the line item number 00001 is created, if it is the first posting to the asset. In all other cases a line item with the number of the last line item + 1 is taken, regardless if the already existing line items are created in previous fiscal years. This means that the line item number is independent of the fiscal year.
The transaction code of the posting is stored in field TCODE (e.g. ABZON or FB01)
The time and the date when the document was created is stored in the fields CPUDT and CPUTM.

The acquisition affects table ANEK in the following way:
For postings triggered by FI field BELNR contains the FI document number, for postings with ABZON the internal asset document number is stored, for example 0000000012.
The fields AWORG, AWSYS and AWTYP combined with the document number BELNR are the link to the FI document.There is the following relation:BKPF-AWKEY = ANEK-BELNR + ANEK-AWORGBKPF-AWSYS = ANEK-AWSYS BKPF-AWTYP = ANEK-AWTYPAWORG is for example BUKRS + GJAHR (FI applications)

Example: Table ANEK

Effects on table ANEK:



Example: Table ANEP

The acquisition affects table ANEP in the following way:
An asset line item with the line item number 00001 is created if it is the first posting to the asset.
Per depreciation area one entry is created. In our example there is only one depreciation area for the asset.
The document number is stored in field ANEK-BELNR.
The transaction type of the posting (in our example 100 for an acquisition) is stored in field BWASL.
The posting amount of 1200 Euro is stored in field ANBTR.
The depreciation value (for example 10 % of the APC amount for 10 years useful life) is stored in NAFAB. This field might be changed if the depreciation parameters are changed.

Example table ANEP

Effects on table ANEP:



Old Depreciation Engine -120,00 / New Depreciation Engine 0,00

Example table ANLC

The posting affects table ANLC in the following way:
The acquisition of 1200,00 Euro provokes a change of the APC value (ANSWL) of 1200,00 Euro.
With for example 10% of depreciation per year considering a useful life of 10 years the planned depreciation for a year (NAFAP) results in 120,00 Euro.

Effects on table ANLC:



Example 2 (Reversal)

Example: Reversal of the acquisition of asset 4711 in company code 1000 on 1.1.2008.The following FI document is created:



BSCHL is the posting key.
Posting key 75 is for credit postings to the asset reconciliation account (KTANSW).
Posting key 40 is for debit postings to for example a clearing account.

The reversal of the acquistion affects table ANEK in the following way:
An asset line item with number 00002 is created, because the last asset line item of this asset was 00001.
The transaction code of the posting is stored in field TCODE like for the acquisition, in our example AB08 or FB08.
The time and the date, when the document was created is stored in the fields CPUDT and CPUTM.
Field BELNR is filled like for the acquistion posting, for example 0000000013.
The fields AWORG, AWSYS and AWTYP are filled corresponding to the original acquisition posting.

Effects on table ANEK:



The reversal of the acquisition affects table ANEP in the following way:
An asset line item with number 00002 is created.
Per depreciation area one entry is created. In our example there is onle one depreciation area for the asset.The document number BELNR corresponds to field ANEK-BELNR.
The transaction type of the posting (in our example 100 is stored for the acquisition) is stored in field BWASL.
The amount of the original posting is posted with reversed sign. In our example -1200 Euro is stored in field ANBTR.
The amount of the depreciation (10% of the amount for 10 years useful life in the example) is posted with reversed sign in field NAFAB.

Effects of the reversal in table ANEP:
In order to mark a line item as reversed, the number of the line item of the original posting is filled in field LNSAN of the reversal posting and vice versus.
Reversed line items are no more considered by the depreciation recalculation, e.g. the depreciation of the transaction NAFAB of a line item is no more changed for line items with non initial values in field LNSAN.Apart from this, the APC amounts of reversed line items are no more considered in rebuilding the value ANSWL.

Effects on table ANEP:



Example 2

The posting effects table ANLC in the following way:
The reversal of the acquisition changes the APC value with the value -1200,00 Euro.
The planned depreciation (NAFAP) for the whole fiscal year results in 0 Euro with the reversal.

Example 2 (Reversal)

Effects on table ANLC:



Example 3

  1. Acquisition posting on 1.7.2007 (previous year) to asset 4712 in company code 1000 with the amount of 2400 Euro. The depreciation is calculated with the APC value as base value and the method is depreciation according to the useful life.
  2. Posting of a complete retirement on 1.4.2000.
  3. Reversal of the complete retirement.
  4. Posting of a partial retirement with the amount of 600 Euro.

Example 3: Acquisition

Acquisition to asset 4712 in company code 1000 on 1.7.2007. A FI document is created which looks like:



Depreciation on the transaction:

With period rule 01 pro rata depreciation is calculated as of 1.7. (i.e. for half of the year).
With 10 years useful life the depreciation is 240 Euro per year. For a half year the depreciation is 120 Euro.

1. Acquisition to asset 4712 in company code



Example 3: Fiscal Year Change

Fiscal year change (RAJAWE00 or automatically when a posting is done for previous years)
Effects on table ANLC: A new entry for the new fiscal year 2008 is created.
The cumulated values are calculated as:
previous fiscal year = PY
KANSW = KANSW(PY) + ANSWL(PY)
KNAFA = KNAFA (PY) + NAFAP(PY) + NAFAL(PY) + NAFAV(PY)



Example 3: Complete Retirement

Complete Retirement
For a retirement, value adjustments have to be considered.

  • Proportional values or value adjustments for a retirement:
  • A retirement means, that an asset is retired with its net book value.But the system stores only the APC value on the database.
    The netbook value of asset 4712 on 1.4. is calculated as the APC value minus the depreciation that was considered up to 1.4. This depreciation is called value adjustments.
    The system makes differences between the value adjustments of previous fiscal years and of those of the current fiscal year:

    NAFAV : Value adjustments of the previous fiscal years.
    NAFAL : Value adjustments of the current fiscal year.
    Both fields are also called „Proportional Values".

Example 3: Complete Retirement

Value Adjustments for a complete retirement of asset 4712
Value adjustments of previous fiscal years NAFAV:The whole depreciation of previous fiscal years is - 120 Euro.
Value adjustment of the current fiscal year NAFAL: On 1.4. the retirement is posted. Thus 1/4 of the depreciation planned for the whole year is depreciated considering period rule pro rata. E.g. NAFAL is 1/4 * (- 240) Euro = - 60 Euro.The sum of the value adjustments is thus - 180 Euro.



For the complete retirement without revenue the FI documentlooks like:



Thus we get 3 lines:

  1. Credit posting to the APC account (KTANSW) with the APC value.
  2. Debit posting to the value adjustment account KTNAFB with the value of the value adjustments.
  3. Debit posting to the account Loss of Scrapping.

A new entry is created in table ANEP for fiscal year 2008
with the line item number (LNRAN) = 00002 (last LNRAN + 1)
transaction type BWASL for retirement 200
retiring APC amount -2400 Euro
ordinary depreciation on the transaction NAFABSince the system always plans the depreciation for a whole fiscal year, regardless if an asset is retired in the current fiscal year, the depreciation has to be corrected. Retirement on 1.4., e.g. 3/4 of the deprecation of the whole fiscal year has to be corrected: 3/4 * (- 240) = - 180.
The indicator for proportional values XANTW = X, because there exist entries in table ANEA. This is always valid for retirements and for the retiring part of a transfer.



Please note: The amount of NAFAB does normally not correspond to the amount of the value adjustments. This is only accidentally!

Effects on table ANLC



Effects on table ANEA



Example 3: Reversal of the Retirement

The reversal of the complete retirement results in the following FI document:



The reversal document consists naturally of the same values than the orignal documents but uses reversed signs.
Therefore, the reversed debit/credit posting keys are used.

A new entry for the reversal posting in table ANEP is created for the fiscal year 2008. The number of the line item is 00003 (last LNRAN + 1).
The amounts are the same as for the original document, but the signs are reversed. Since the document is reversed, the field LNSAN is filled with the line item number of LNRAN of the original document, thus with 00002.
All other fields, especially field XANTW = X is taken from the original document. Only fields for the posting periods or for a date need not to correspond to the orignal document.

Effects on table ANEP



Effects on table ANLC



The APC value of the current fiscal year (ANSWL and the proportional values (NAFAV, NAFAL) get to 0. NAFAP gets back the orignal value.



A second entry for a new LNRAN is created. The proportional value are the same like for the original documents but with reversed signs.

Example 3: Partial Retirement

4. Partial retirement with the amount of 1200 Euro on 1.4.2008.Since only half of the total sum is retired, the value adjustments are also half of the complete retirement.
NAFAV = 60
NAFAL = 30
For a partial retirement of n % the value adjustments are calculated as NAFAV (part. retiremt) = NAFAV(compl. retiremt) * n % and NAFAL accordingly.The same is valid for the depreciation on the transaction NAFAB.
Also, the retiring APC amount is calculated internally as the percentage of the whole amount.

The partial retirement results in the following FI document:







The fields ANSWL, NAFAV, NAFAL are filled again.



A new entry for LNRAN 00004 is created with half of the proportional values of the complete retirement.

Retirement with Revenue

Retirement with RevenueAsset 4713 with
a cumulated APC value of 2400 Euro,
cumulated ordinary depreciation of 120 Euro and
10% depreciation, e.g. the planned depreciation for the whole fiscal year will be 240 Euro.

Retirement Gain/Retirement Loss
Dependent on the revenue amount entered , the FI document contains an additional line in the document for the Retirement Gain/Retirement Loss.

Retirement Gain:
The revenue is higher than the net book value of the asset when retired. Example: Asset 4713,
net book value = APC - value adjustments = 2400 - 180 = 2220.
The revenue of 3220 Euro results in a Retirement Gain of 1000 Euro. The retirment gain is posted to the account KTMEHR.

Retirement Loss:
The revenue is lower than the net book value.
Example: Asset 4713, revenue of 1220 Euro.
The revenue of 1220 Euro results in a Retirement Loss of 1000 Euro. Retirement Loss is posted to the account KTMIND.

Retirement Gain/Retirement Loss
No retirment gain/loss:
The revenue corresponds exactly to the net book value of the asset when retired.
Example: Asset 4713, revenue is 2220 Euro.
There is neither retirement gain nor loss.
The FI document consists of only three lines for this situation.

Complete retirement with revenue of 3220 Euro results in the following FI document:



Complete retirment with the revenue of 1220 Euro results in th following FI document:



Complete retirement with the revenue of 2220 Euro results in the following FI document:



New Acquisition and Acquisition of Previous Fiscal Years

New Acquisition and Acquisition of Previous Fiscal Years when retiring
The transaction type indicates, if new acquisition of previous fiscal year acquisitions are retired.
When posting a complete retirement new acquisition as well as acquisition of previous fiscal years is retired, because after a complete retirement APC and net book value has to be zero.Therefore, two entries in table ANEP and ANEA will be created for an asset with acquisition of previous fiscal years and with new acquisition. Two table entries belong then to one transaction.

  • No part of this presentation may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.
  • Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
  • Microsoft®, WINDOWS®, NT®, EXCEL®, Word® and SQL Server® are registered trademarks of Microsoft Corporation.
  • IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®, AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation.
  • ORACLE® is a registered trademark of ORACLE Corporation, California, USA.
  • INFORMIX®-OnLine for SAP is a registered trademark of Informix Software Incorporated.
  • UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of The Open Group.
  • HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Laboratory for Computer Science NE43-358, Massachusetts Institute of Technology, 545 Technology Square, Cambridge, MA 02139.
  • JAVA® is a registered trademark of Sun Microsystems, Inc. , 901 San Antonio Road, Palo Alto, CA 94303 USA.
  • JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.
  • SAP, SAP Logo, mySAP.com, mySAP.com Marketplace, mySAP.com Workplace, mySAP.com Business Scenarios, mySAP.com Application Hosting, WebFlow, R/2, R/3, RIVA, ABAP, SAP Business Workflow, SAP EarlyWatch, SAP ArchiveLink, BAPI, SAPPHIRE, Management Cockpit, SEM, are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.
  • No labels