COA Programs - Why are they being changed?

[former_member42743]

This blog came about because of a question in a forum.  I get very frustrated when I see this question asked.  It keeps coming up regularly.  I can summarize my response in one sentence and anyone familiar with this topic will probably know the question:

Answer:   DO NOT make a copy of the COA program RQCAAP00 and customize it and then assign it to your COA output types.

Question:  Transactions QC21 and QC22 don't work or don't create COA's like the ones from my COA outputs in my deliveries.  How come?

I have seen client after client do this.  I don’t know why.  They all seem to think they have a unique requirement that can’t be met any other way.  Or, the more likely reason is that they have someone doing their consulting that is less then knowledgable about the COA programs, the available functionality and the ramifications of changing this program.

For most chemical companies, providing Certificates of Analysis (COA’s) is a primary requirement of any SAP installation that implements the QM module.  Some choose to use external systems such as their LIMS or maybe a custom solution.  But many choose to use SAP, which can do this and which can integrate very nicely with the SD module.  This is a key reason to do this function in SAP since most external solutions require some type of manual step or communication.

Typically we configure the system such that a COA output type is created automatically in deliveries for certain materials and/or customers.  The output is then either automatically processed at some point or is manually requested by someone by a transaction like VL71 or QC20.  The program ultimately sitting behind this functionality is usually RQCAAP00.

In configuration, SAP has a section where the program for the output can be defined.  Under QM config the config path is Quality Certificates-->Process Output-->Assign Print Program to Output Type/Medium.  When this is executed, you have to provide an output type such as LQCA.  You can then assign a print processing program to each output medium such as print output, fax output, EDI, etc…  A key thing to keep in mind is that this same config process is used in other modules to assign print programs to their modules output types.  The technique is used across several different modules.

So, people are used to editing and modifying their print programs as they see fit.  They can change the BOL or Pick List this way and do all kinds of fancy things with regards to collecting data and how the data is presented.  And guess what?  It works for COA’s too!!!!  Wow!  But just because you CAN do something doesn’t mean you SHOULD.  Why does SAP let us do this for COA’s?

Well, it could be you have a special type of EDI format that is required by a specific industry.  You can copy the standard program, make your changes to the output format and configure it as an output medium for one or more output types.  This is a valid reason.   But the key here is that the program should only be changed to accommodate the medium type, i.e. EDI.  Not to change the underlying functionality of the program.  Once you make that Z program for that medium, you, as the client are responsible for maintaining it, updating it with each SAP revision and adding in any new logic that you want to incorporate.

Now, as far as the standard COA program, RQCAAP00, you could copy that to a Z program, modify it to meet some requirement and assign that to your print and fax mediums for your outputs. No problem.  The COA’s come out and everyone is happy.  For awhile.

But one day you try to use the QC21 or QC22 transactions to manually create a COA for some reason. (Trust me, it will happen).  Each of these transactions use their own programs, RQCAAP01 and RQCAAP02 respectively. The program for transaction QC20 is RQCAAP03 which utilizes the output type configuration and as a result will call any custom program you have configured. It is no different than running VL71 really.

SAP has set up RQCAAP01 and RQCAAP02 to basically always call the original COA program RQCAAP00 and the submodules.  Since you can't modify RQCAAP01 and RQCAAP02 to use your custom program, you cannot use QC21 or QC22 as they won't have the same functionality/logic as your Z COA program you assigned to your output types.  Your COA's won't come out correctly, if at all.

SAP never really intended for you to change the underlying COA program. The ability to assign COA output programs to output types was primarily allowed to create programs for special output mediums like EDI and any future output types maybe not envisioned.

Mods to your COA should be done via standard SAP functionality such as the function modules that can be written and configured, user exits, and SAPscript.

Here’s another issue you will run into if you have not already.

Once you modify the program, whatever version you use as your base program to start from, is the version of SAP you are stuck with. So if you modified a 4.6c version of RQCAAP00 program, as SAP rolls out new versions, such as in 6.0 or 6.0 EHP, your custom program cannot take advantage of any new functionality that SAP provides. SAP can and does make changes to RQCAAP00 and it’s sub modules to accommodate new functionality or make bug fixes.  It is conceivable that at some point, if SAP makes a major change to the COA functionality, you might find your custom Z COA program no longer functions some day after an upgrade or hot patch.

An excellent example of this is the use of multiple specifications in QM. A company who for instance modified their COA program in version 4.0 are stuck with the 4.0 version. When upgraded to 6.0, their program might still run fine.  But they cannot use the new multiple specifications functionality as they cannot output COA's for it because their custom COA program, built on 4.0, has no logic in it for multiple specs. So they must rewrite their custom program, or use it as is.  This means that no business in their company can consider using multiple specifications as a possible business option.

Some places make "Z" versions of QC21 and QC22. They have to copy the RQCAAP01 and RQCAAP02 programs and put in the same logic they put in the custom copy of RQCAAP00. Then they create ZQC21 and ZQC22 transactions. Of course you now have to maintain three programs with any changes and updates.

No QM consultant should ever recommend a change to the basic COA program normally. It often appears to be the easiest solution but this is usually because not enough is known about the various config options available, user exits and SAPscript. I have only seen one client in over 15 years that absolutely had to change the COA program. And for them a special output type was set up for just that business and only their output types were set up with the custom program.  And that wasn't technically a chemcial firm but a mill products company.

If there is interest in this topic, I was thinking of writing a blog about common COA issues and how these can be addressed without modifying the standard COA program.  Usually through a combination of some business process review, education, careful examination of requirements and use of standard SAP functionality, the need to make modifications to the underlying COA program can be avoided allowing for easier upgrades and the ability to incorporate future functionality.

******************************************************************************************************************This document is not intended for distribution, publication or for use on internet sites other than by SAP.  Written permission for use must be obtained from the original author or SAP.  If you are seeing this document on a site other than via SAP.COM please report the pirated use of this material to SAP or the author. ******************************************************************************************************************