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. ******************************************************************************************************************

[Former Member]

Well that's not good news for me. We are in this exact situation. We have a ZRQCAA* program, ZQC21, etc. We just upgraded from 4.0 to 6.0 and luckily only one minor ABAP fix had to be made to the COA Program. We currently have a requirement coming down the pipe to cert against one spec and manufacture against another. Hopefully it doesn't turn into a headache because of customization put in place by long gone consultants.

Btw, thanks for all your help to the SCN QM community. You are really a wealth of information, and these blogs are a great addition!

[former_member42743]

Thanks for the comment Jimmy.  There is nothing like having someone relate a real-life situation to validate a blog.  As you now know, using the multiple specs feature is not an option for you now unless you copy the current 6.0 COA program and apply the changes you require to that program.  Of course my first question would be to ask what was the primary reason to create the old custom COA program and can those items be somehow otherwise addressed with standard 6.0 functionality.

I'm glad the blog has helped.  Or at least highlighted the issues.

FF

[Jelena_Perfiljeva]

Liked and rated. I'm not an expert in QM, but as an ABAPer, you had me at "do not make a copy". :smile: Also minor changes may easily be done in the forms directly, no need to customize the output program too (although there are different schools of thought on that even in the ABAP community).

[former_member42743]

Yes.. exactly. Unfortunately I often find that a lot of developers do not know much about SAPscript.  Especially as SAP has pretty much moved to Smartforms in most areas.  But in the QM area, Smartforms are not fully supported yet. (through 6.0 EHP4 anyway).  Sometimes I know more SAPscript then they do and THAT's a scary thought!  :shock:

[kaushik_choudhury2]

Very nicely explained with the cons of introducing bespoke objects .

Z-objects should not been seen as a solution by functional consultants. Many years back, I was engaged in an upgrade project where during implementation customer had made ZQA03 and other Z- transactions with calling custom program (copied from standard program and made modifications)  Due to this upgrade has become quite complex and took more time to take care of these custom programs .

[former_member42743]

Thank you Kaushik.  Yes.. good functional consultants should really try to avoid customizations where ever possible.  It should be the last choice.  SAP has tried to introduce best practices throughout the system.  They aren't always a perfect fit for clients but many customizations can be avoided.

FF

[Jelena_Perfiljeva]

This is because SAPScript is an ancient technology (and an awful one!), so no one wants to learn it. ABAPers avoid it like a plague and I can't really blame them. If I would never have to deal with SAPScript again, it would make me so much happier.

The problem, however, is that it's still very much used in many modules, including FI. Even in SD SAP really did a so-so job providing Smartforms. From what I've seen, Smartforms were supposed to replace SAPScript, but half way through SAP lost interest because a shiny new toy (PDF forms) appeared. Not sure what happened with those - there are no standard PDF forms available in most cases either.

It seems as if Output is an unwanted child of SAP handled by the technical team with the attention span of a toddler and possibly lousy financing. Or maybe it's their strange way to support the consulting market, who knows...

[former_member42743]

So very true!  I never said I liked SAPscript nor do I blame developers for not really knowing it.  But as you pointed out, a consistent approach to these types of documents using a current technology would be welcomed!!! I agree.. in that output seems to be an unwanted child!  I think many feel these are just 'reports' and we should do all of this in BW.  But these forms are what the business runs on.  Pick lists, BOM's, Manifests, Shipping notifications, COA's, lab worksheets, sample control sheets, etc .. etc..  All wind up having to be custom built with some in SAPscript, some in Smartforms and some in PDF. Hardly an efficient model!

FF

[Jelena_Perfiljeva]

My thoughts exactly ("great minds think alike" :smile: )! These are the customer facing and legal documents, yet MS Word comes with a better collection of templates than ECC 6.0. Certainly I'd expect almost every customer wanting to customize their forms, but in most cases there is nothing to even build upon. On top of that, there is no consistency.

[Former Member]

Good document and all should embrace this guidelines. Could you please let know the user exits or BADIs that can be used in the program RQCAAP00. Also is there any exit that can be used in QC20.

I did a search but couldnt find anything.

Thanks

Prathib

[former_member42743]

These are all the user exits I know of related to COA's.  TO be honest, I've never had to use any of them.

QC100001	QM certificates: User exit for list of batches used
QC100002	QM certificates: User-defined initialization option
QC100003	QM certificates: Before and after cert. profile determinatn
QC100004	QM Certificates: User-Exit Before Call-Up of Form Printout
QC100006	QM Certificates: User-Exit After Selecting Delivery Data
QC100007	User-Exit for Changing Certififcate Profile Characteristics
QC100008	QM certificates: User exit for changing the customer number
QCE10001	Enhancement Modules: Electronic Certificate Dispatch
QCE10002	QM: Enhancement to IDoc Type QALITY02
QCE10003	QM: Quality Data Exchange of Electronic Cert. in Insp. Lot
QCPA0001	Certificates: Assign control data of certif. profile char.
QCPA0002	Certs: Criteria restriction insp.lot/ptl lot selection
QCPA0003	Certificates: Fill new fields to find certificate profiles
QCPA0004	QM Cert. Profile Menu: Cert. Profile Function Code +US4
QCPA0005	QM Certificate Profile Menu: Edit Function Code +US5
QCPA0006	QM Certificate Profile Menu: Environment Function Code +US6
QCPA0007	QM Certificates: Include Characteristics in Cert. Profile
QCPA0008	QM Certificate Profile: Header Data Subscreen
QCPR1001	QM GR certificates: Before sending the certificate request
QCWA0001	QM: Quality Certificates on the World Wide Web

I've usually just used the FM's that you can add in via the configuration of the COA's.

Craig

[Former Member]

Thanks Craig.

We have a requirement to create quality certificate as flat file in CSV format. I am afraid this cant be achieved through any of the exit and option is to copy and create Z program. Please advice if there is an option without creating custom program.

Thanks

Prathib

[Jelena_Perfiljeva]

Prathib, it might be beneficial if you open a separate discussion to get an answer to your questions. To my knowledge none of the output processing programs is capable of creating a csv file, but anyway it doesn't seem to make much sense to discuss this in the comments here.

[Louis-Nicolas]

Hi every one.

Does anybody have tried to develop the CoA in Smartforms technolgy (I means the layout only ... and keep the extraction program in standard).

I believe it should be possible no ? :???:

[former_member42743]

I don't think it's been done with out modifying the SAP provided program.  Someone may have, I'm just not aware of it though.

Craig

[ajercan]

Hi Louis,

Yes, it is possible, I had 3 customers already for whom we defined the layout and the logic for data retrieval in the smartform interface, leaving the standard print program untouched.

[Louis-Nicolas]

Good to know Andrei!

Thanks

[former_member780836]

Hi Andrei,

How standard program call smartforms, since it only call subroutine of the Sapscript, seem like imposible.

Thanks.

Danni.