Depreciation Posting Runs explained in detail 

 
RAPOST2000 (t‐code AFAB) vs. RAPOST2010  
If you have to run depreciation by company code wise, the t‐code AFAB (Program name RAPOST2000) can be 
executed. The program RAPOST2010 allows selection of several company codes. The Report selection variables can 
be maintained in the TVARV table for both these programs and can be scheduled using the scheduler Manager. 
 
Planned Posting Run 
The Planned Posting Run is the standard periodic run to post planned depreciation. This should be used when the 
last depreciation run was successful, and it’s time to carry out the depreciation run as part of the new period‐closing 
process. The system checks that the posting period is the one following the last successfully posted period; this 
information is then recorded in Table T093D, in the AFBLPE (period) and AFBLCJ (year) fields. In addition, the status 
of a depreciation run is also updated in the table TABA. The field names in TABA are “Document posted indicator‐
XBUKZ and Period in which last depreciation was posted‐AFBLPE. Please note TABA entry is created first during the 
posting process. The table T093D is updated as one of the last steps. However, please note the table T093D 
wouldn’t be updated for test runs. In addition, the table ANLP stores the depreciation posting values from each 
depreciation run. The field NAFAZ has value to be posted from this depreciation run. 
  
Restart 
The Restart run would only be used if the depreciation Posting Run terminated during processing due to either a 
system outage or error may have caused it to end abnormally. If posting run terminated for technical reasons, and 
changes made already made to the database, the depreciation run report must be begin in restart mode. 
  
For example, when an asset has an either closed WBS or invalid cost center, system makes posting to Fixed Assets 
sub‐ledger (by updating the tables ANLC/ANLP), but the job failed to post to G/L. In other words, the program failed 
the postings to G/L, thus an inconsistency created at this point of time between FI‐AA and FI‐GL, at least 
until restart of the depreciation is run again. If the WBS or Cost Center is fixed in the asset master, the restart will 
reset tables and execute the planned posting run, beginning at the point it was interrupted. This will clear any 
database of possible inconsistences. Using the restart mode ensures that all system activities that were interrupted 
by the termination are repeated. The table TABA entry must exist at this point, but the restart run does not create a 
new TABA entry. If the field TABA‐XBUKZ has a value of “1”, which means restart mode is required. After solving 
error(s), the field will be changed to “X” which means it’s posted successfully. If TABA‐XBUKZ has a value of “N”, it’s 
yet to be posted. 
  
Note: This affects only those assets that were not successfully executed in the previous run. 
  
Repeat 
The Repeat run is used to repeat the posting run within the period last posted. Repeat would be used if changes 
have been made after the period depreciation run has been posted. 
  
For example, let’s say depreciation terms (e.g. an asset useful life) are changed in the asset master data or new 
transactions posted (for e.g. asset transfers). Therefore, there is a need to depreciate in the current period for the 
changes made. The system recalculates the depreciation for the period, subtracts the depreciation already posted, 
and then posts only the difference. This can be restricted to specific assets which can be listed under parameters for 
Test Run or for all assets in the company code. In addition, theRepeat posting run may be used if additional assets 
were settled after the planned posting run was complete. An example would be allocation was run which caused 
additional assets to be created. A Repeat run could then be processed for only those specific asset numbers or a 
single asset. 
  
Note: During a repeat posting run, the system only posts the differences that resulted between the first posting run and 
the repeat posting run in other words no double posting or overwriting existing posting. 
  
Unplanned Posting Run 
The Unplanned Posting run allows posting outside of the normal processing cycle (for example monthly).This option 
is not same as unplanned depreciation. Several periods can be posted in a single run with this option. By setting this 
indicator, the system does not check for the connection to the previous period and allows skipping over 
periods. This can be a useful option for test purposes for estimation or validating some depreciation calculation, but 
generally this option is not recommended.