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.
- If you get specific instructions from SAP via the help portal.
- 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.
- 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.
- 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.
Examples?
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.
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?
Conclusion
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.
.
- SAP Managed Tags:
7 Comments
