Skip to Content

A Primer on Correction Programs

I’ve been an SCN member since 2006 and watched the involvement from others increase over the passing years.  This is both good and bad at the same time.  It’s good to see more people get involved but I’m not sure the collective quality of SAP knowledge on the site increases at the same rate.  I suspose this isn’t unexpected given SCN’s growth rate.  However, with the increased size, scope, and viewership of SCN, I think there is a risk to SAP customers that rely on the information being presented here.

I’m blogging today because lately I’ve seen an increasingly growing number of recommendations from community members that the OP should solve their problem by either 1) running an SAP correction program or 2) debugging their way into a table update. Hacking table updates has been covered a few times already.  Just search on the appropriate key terms (I’d rather not list them) and you’ll see plenty of discussions on it.

The point of this blog is to talk about the other technique (correction programs) and their consequences.

What are correction programs?

Correction programs are used to fix table inconsistencies that can not otherwise be fixed through a normal dialog transaction.  The programs are developed by SAP and the intent is to solve specific errors.  This is a critial point because these programs can not be used in all circumstances.  It’s also important to note the audience of these programs.  They were developed to be used by SAP Developers… i.e., the folks in Germany, or now, in AGS worldwide.  These aren’t originally intended to be customer facing tools.

What’s the big deal?

Most, if not all of these programs, are direct table updates with little validation of the data in the existing table or the parameters entered at the time of execution.  There is little, if any, program documentation.  Most of them are crude utilities… and I’m not saying that to be critical.  Instead, I want to make the point that these are not sophisticated programs that can be used in a variety of scenarios and will safely stop an update from occurring if it doesn’t make sense to do so (from a functional perspective).

Because of this, there is an element of risk to executing them.  The original data can not usually be recovered.  If the programs are executed incorrectly it’s possible for inaccurate results to occurr.  SAP doesn’t advertise or document these programs because their stance is that they should only be executed by SAP resources (or under their guidance).  That means if you run a program and cause a bigger problem, SAP isn’t obligated to help you out of that situation.

When is it appropriate to run a correction program?

A correction program should only be executed after you’ve gone through the following 4 point checklist.

  1. If you get specific instructions from SAP via the help portal.
  2. A correction program should only be executed after thoroughly testing in a quality/test system.  This can be difficult because the unusual nature of these problems is such that it is difficult to replicate them.  However, if at all possible, I would do a test on the program as best I can and substantiate it with appropriate screenshots, table downloads, reports, etc.
  3. You should always try and solve the problem using normal transactions.  If there is a way to solve a GL issue using re-postings and such, then I’d always go that route then utilize a crude utility such as a correction program.
  4. Only as a last resort

When is it not appropriate to run a correction program?

Most importantly… and I can’t stress this enough…  these programs should not be executed without a thorough understanding of the problem at hand, the tables impacted, and the updates being performed by the program.  If you can’t read code or weren’t guided by SAP about the updates being performed, I wouldn’t run it.  If you can’t talk in complete detail about the error and have proof that the error is triggered by a table inconsistency, and have the knowledge or tools to fix a potentially bigger problem if the correction program causes one, I wouldn’t run it.


I’ll show a few examples but I’ll stay away from the more dangerous ones.

The first one has a clear warning message.  Most of the newer programs that I’ve seen have similar warnings even on the selection screen.

screenshot - 2014.08.11 - 14.56.53.png

Here’s an old one.  No program documentation, no selection criteria, and very little information in the title.  If you can’t read ABAP, how will you know what this program does.  What exactly does ‘debug’ mean in this context?

screenshot - 2014.08.13 - 17.10.31.png


The problem with topics such as this one is that a lot of people want to blast out the information to show off what they know.  My gripe is that we all need to realize that the responsibility (and blame) from running a correction program without proper consent or guidance from SAP is quite high.  Do so at your own risk.


You must be Logged on to comment or reply to a post.
  • I think it's important to always apply critical thinking to everything you hear and read. The complexity of SAP systems today and the unknown variables that are Z-code make absolute statements a dangerous thing.

    Hopefully we'll see and need fewer of these correction programs in the future with Simple Suite when every aggregate and index table is removed.

    • I'm not sure Simple FI and no more COSP entries will necessarily save us from new ones.  If there are less programs being created, and going off of memory I think the trend of new correction programs is going down, I think it's just a matter of the product having matured so much since the R/3 rel2 days. 

      Then again, with the greater occurrences of folks hacking tables on their own, the chances of having more table inconsistencies is much higher than it was years ago.  mmmm... so, I'm not sure if we'll see more or less correction program activity from SAP going forward!

      On a related topic, I've often thought they need to have greater table logging so that they could see if someone just hacked a table and are now reporting it as a routine error to SAP.

      • It's only Simple FI at the moment but once we get Simple SD/LE/etc the number of problems that can arise will decrease since the datamodel will be so simple. This will decrease errors caused by Z-code and it will decrease errors due to system inconsistency.

        Just thinking about rebates you have VBOX as index table for rebates, S060 for aggregates of accruals and quantities, S469 for extended rebate accruals and quantities. Then in FI you have line items that are aggregated in several tables. With the Simple SD I would imagine that VBOX+S060+S469 would be dropped, that removes the need for at least 3 correction programs I know of. For the transactional tables you should do corrections using transactions and not table hacks as Susan says.

        Hasn't HANA got a timetravel solution that uses some form of delta store which means that table logging is built into HANA? Or was that only an idea presented in one of the white papers on HANA?

  • Nathan, I really appreciate the cautions you have mentioned here.  As a long-time SAP developer, I've seen the use of some correction programs, and I've seen the use of some 'table hacks' and I've never been comfortable with either.  

    In particular, "You should always try and solve the problem using normal transactions. "

    Thank you for this community service blog!