Have you ever seen the message, Update was terminated, and wondered what it meant? Here’s a more worrisome question: Do your FI users know what to do when they see this message? Perhaps they click through, thinking it’s just another irritating log-on pop-up message. Since it looks so technical, they might assume that it does not apply to them. Users often find out otherwise at month-end when their books do not reconcile or they cannot find documents in open item lists. Many users believe that all their data is safely stored when they click on the save button and see a message such as Document 3100153969 was posted in company code 0001. In reality, this may not be the case. To maximize online response time performance, R/3 sends the data to a background process to update later—as long as five minutes with a slow system. This is referred to as an asynchronous update process. There are two types of update processes, V1 and V2. In either case, if an error occurs, details are stored in the update error log, viewed using SM13. V1 updates are the key updates related to a transaction (such as post FI document, print invoice, update monthly balance tables). If any one of the V1 updates fails, all of the V1 updates are rolled back and no V2 updates take place. This ensures that only complete documents are posted and no “half-posted” documents occur. V2 updates are less important update activities (updates to LIS or SIS). If a V2 process update fails, the V1 updates and the successful V2 updates are both kept. In this case, the main document is posted and secondary data is not fully updated. This is designed to stop failures in secondary systems that cause the primary documents not to post. Sometimes things go wrong, and the journal you think was posted is only half-posted or not posted at all. For instance, it is possible for a G/L, A/R, A/P, or AA document to post to the main document tables, but not to summary tables or to submodules such as the Special Purpose Ledger (FI-SL), Cost Center Accounting (CO-CCA), or Profitability Analysis (CO-PA). Although such mistakes can occur as infrequently as once or twice a year, the error rate increases in systems with network, database space, or sudden termination problems. R/3 provides several end-user tools to detect and correct these errors. This article explains what lies behind those error messages (Figure 1) and what actions you should take when they occur. First I will show you which ABAP reports detect the errors. Then I will demonstrate how to correct the incomplete tables. In most cases, this will allow you to recover the information and ensure your ledgers balance so that users can trace all transactions. From an SAP perspective, a document is posted if the BKPF and BSEG entries are consistent. In this case, you can recreate all other entries with correction programs. If data is missing in BKPF or BSEG, it may be impossible to recover the missing data. These tools are intended to be used by functional experts. However, you may wish to check with your Basis and DBA teams as well before making these corrections. For more detail, see "What to Do When You See the Message, ‘Update Was Terminated,’" at the bottom of this article.

Step 1: Use ABAP Reports to Identify Differences

The first step is to pinpoint the document problem as an update-terminated error. The following symptoms point to an inconsistent document:

• You cannot view documents using transaction code FB03
• Monthly balances in transaction codes FS10/FD10/FK10 do not match the line-item detail when you drill down
• ABAP reports show inconsistent numbers (RFSSLD00 balances do not match RFHABU00 balances, FI-SL reports do not match G/L reports)
• Drill-down of line items not available

If you notice any of these signs, you can use the appropriate ABAP report to detect documents that have not been completely updated. Make sure no postings occur while these reports run. Ideally, they should run for closed periods. You can select one of the following three reports:

• SAPF190 – Financial Accounting Comparative Analysis. SAPF190 checks that the G/L, A/P, and A/R monthly balance tables and secondary index tables match the line-item detail for posted documents. This report calls the older SAPF070 and performs its own checks. Do not use SAPF070 directly as you will miss the more comprehensive checks of SAPF190. You should run SAPF190 at month-end to ensure that no mispostings have occurred. It takes a long time, so run it in background mode. The report is comprehensively documented. OSS note 86067 gives more information.
• SM13 – Display Update Records. You can find update terminations with transaction code SM13, which records all updates (Figure 2). Choose All to list all users and change the Selection date to the beginning of the fiscal period.

Double-click one of the lines shown in Figure 3 to list all of the update modules. In this example, you drill down on FB05 in the TCode column. The Update Modules screen (Figure 4) displays all the individual update modules called when you click on the save icon. The specific module that caused the error is highlighted in red. Double-click the Err line to display error message details, which may help detect the cause of the update termination.

RFVBER00 – FI Document: List of Update Terminations

RFVBER00 (Figure 5) is a more practical and detailed report for FI users than SM13. It provides an analysis of all the FI documents within the SM13 list in Figure 3. It takes into account FI postings generated by other modules as well as direct FI postings using FB01. This report enables you to keep a log of "missing" document numbers if your auditors are concerned about continuous number sequences. To see the list (Figure 6), run report RFVBER00 and change the selection dates to cover the fiscal period you are investigating.

Step 2: Correct the Problem Via Transactions

After you identify an inconsistency, you select a report to correct the problem. The report you choose depends on the table that is missing data. Understanding the many FI tables affected by the terminated update helps you choose the best method of correction. It also helps explain why a document missing from one table, such as a monthly balance total, can still be viewed with transaction code FB03. (See the sidebar, "Commonly Used Tables"). You should first try a single-record update with transaction code SM13 – Display Update Records. From the SM13 display screen (Figure 7), select the item to be updated and choose Update, Repeat update, and Single. This does not always work, as the status of the R/3 system might have changed since the update termination occurred. For instance, locks placed on tables may no longer be valid. If this single-record update does not work, you have to use a mass correction program. The following mass correction transactions are available for submodules within R/3. This list contains only the most common correction programs. G/L, A/R, A/P:

• SAPF071 – Adjust Balances after Comparing Documents/Transaction Figures. When the run of the SAPF190 report indicates that the monthly balances are incorrect but the index amounts are OK, use SAPF071 to correct monthly balance tables GLT0, KNC1, and LFC1.Use this program only after thoroughly checking the prerequisites, which are listed in the report documentation.
• RFSEPA01 – Switch On-Line Item Display by Changing Master Record. Use this report when entries are missing in the line-item detail tables, but the monthly balances are OK—for example, when the line item display flag for a G/L account has been changed after the account was created. See OSS note 86067 for more details.
• RFINDEX/ZFINDEX – FI Consistency Check. The report RFINDEX is not suitable for regular reconciliations due to its complexity. Start report RFINDEX only after consultation with SAP for problem analysis. This is an SAP program even though the program’s name might begin with a "Z" in your system. It corrects secondary index tables BSIS, BSAS, BSID, BSAD, BSIK, and BSAK. You also can use it to correct monthly balance tables. See OSS note 195515.

Make sure the document is correctly posted in G/L, A/R, and A/P before attempting to correct the submodules.

• FI-SL and EC-PCA: Use transaction code GCU1, ABAP program RGUREC10, to re-post a G/L document to FI-SL or EC-PCA. See OSS note 115840.
• CO-CCA: Use transaction code OKBA, ABAP program RGUREC10, to re-post a G/L document to CO-CCA. See OSS note 45122.
• CO-PA: Use transaction code KE4S, ABAP program RKERV002, to re-post a G/L document to CO-PA. See OSS note 126937.

Cautions on Corrections

Posting corrections is not always the solution in every situation. Here are three examples when it is not advisable:

• Posting a correction to a prior period can affect publicly reported figures or create a reconciliation error between G/L and another module. If you use FI-SL as your book of record for external reporting, you may want to update directly in G/L, but manually post an adjustment in FI-SL in the current period to avoid changing figures reported to external parties. If G/L is your book of record, then consider carefully how to update. A manual entry in the current period may be a better solution than updating directly in a closed period.
• Some errors correct themselves and need no manual intervention. For instance, an automated clearing posting may fail because of a deadlock in the database. As the batch report runs every night, the clearing takes place on the next batch run, and a recovery of the transaction using SM13 is not required. Users may repost documents themselves when they discover they did not process properly, as when an update termination in manual invoicing results in no invoice being printed. The user has no paper invoice and repeats the invoicing. You have to investigate each update termination to see if reposting is required.
• When a company has been through a euro conversion or other local currency modification, a minor difference between the monthly balance amount and the total of the line items is normal. You should not correct this (see OSS Note 151509. SAP does not recommend or support correcting the error in a closed fiscal year). If the error occurs in a closed fiscal year, correcting the error may cause problems with roll-forward to future periods. This emphasizes the need to run checks of your balances using SAPF190 on a timely basis.

Although the type of error described in this article is uncommon, you should monitor for possible errors by running report SAPF190 every month after close. To detect errors before close, review the SM13 logs on a regular basis for transactions that update FI/CO. Make all corrections with care. Incorrect use of the correction programs can result in major errors in the R/3 system that are more serious than the ones you are trying to correct. If you are running correction programs, read their prerequisites and make sure posting periods are closed during detection and correction. If in doubt, call SAP OSS for support.