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, the Repeat 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.