When is customization dangerous even if the BADI's/exits are all there ????

Question

In this blog post here:
/people/david.halitsky/blog/2007/03/08/the-astrobiology-of-enterprise-soa-how-planet-abap-can-seed-life-on-planet-bpx
I gave a schematic outline of the badi's and exits required to customize SAP QM in a particular way.
Up until recently, it was thought that we only had to use these badi's and exits
to update QALS records in order to link an inspection lot to an inspection plan that is not the one that standard SAP logic picks.
But it turns out that we not only have to update QALS in this way, but also delete SAP-added records from AFFL, AFVC, AFVU, and AFVV and re-add our own corresponding to the operations in the non-standard plan we're selecting for the inspection lot.
OK - so we know exactly how to do these deletes and re-adds, because the way  SAP does the original inserts into AFFL/AFVC/AFVU/AVFF (during a MIGO goods receipt post) is perfectly clear - the sequence of FMs and forms is:
FM's:
qeev_tables_generate
qpap_plan_read
qpap_post_qapo
co_bt_order_post_qm
co_vb_order_post
FORMs performed from co_vb_order_post:
affl post
afvg_post (takes care of afvc, afvv, afvu)
But even though we know what we're doing, and even though we can do everythign we need to do with an SAP-delivered BAdI or exit, maybe what we're doing is still too dangerous because we're relying on SAP keeping a number of different files interrelated in exactly the way they are now:
QALS
MAPL
PLKO
PLFL
PLAS
PLPO
AFVC
AFVV
AFVU
AFFL
What do you think ?
Thanks in advance for whatever time you can afford to spend considering this matter ...
djh

Answer 1

Hi Stephen -
I appreciate the responses from you and Chris very much, because my current customer is right now grappling with the question of whether what we "need" to do is actually too much dangerous over-customization.  So this is not a discussion in the usual "theoretical vacuum".
I want to explain why I think the "direct update" rule here MAY not apply in this particular case. 
But before I do, I want to make very clear that I was the one who brought this situation to management attention when it turned out that NINE core SAP tables were involved, not just ONE.  So whereas I felt more or less comfortable with one update to one table to repoint an inspection lot to a different inspection plan than the one which SAP selects, I didn't feel at all comfortable with direct updates to eight other core tables, particular when these involve what amount to "key field updates" - effectively, "deletes/re-adds".
That being said, the details of this particular case involve the fact that when we go for the eight core SAP tables, we are not doing anything other than doing exactly what SAP does, but with different "ALLOWABLE" choices.  There are SAP delivered transactions which allow a customer to choose the inspection plan that will be associated with a given inspection lot.  These transactions record the customer's choice in two different ways: 1) first - in the relationships among the rows of PLKO, PLAS, PLFL, PLPO; 2) second - in the relationships among the rows of AFFL, AFVC, AFVV, and AFVU.  So what we're doing in the exits/BAdI's is:
1) undoing the choice of inspection plan that SAP has made and recorded in these tables;
2) recording our "custom" choice of inspection plan in these tables.
For this reason, it is difficult to BLINDLY apply the "don't do direct updates" and "don't do something SAP doesn't anticipate you doing" rules.  Because on the one hand, it is true that SAP does not specifcally say in the BAdI documentation or exit parameters: "use this exit to change choice of inspection plan" or "use this BAdI to change choice of inspection plan".  But on the other hand, we are not using the exits/BAdI's to do anything different than SAP already does when MIGO GR posting triggers inspection lot creation and inspection plan assignment.
With respect to the "watch-out for problems during upgrade" rule of thumb, it is also difficult to apply this rule blindly because it turns out that in our case, all the columns in the relevant tables are KEY columns.  And for that reason, it is hard to imagine SAP changing its fundamental "E-R diagram" for QM during the course of any future upgrade.  And if this possibility is, in fact, remote (i.e. if SAP cannot really change the "E-R" key columns of QM tables without rewriting QM from scratch), then the "upgrade problem" issue really doesn't arise.
Anyway, I want to close this post by saying that the functional analysts who proposed the customization in the first-place do NOT think that direct updates of nine core SAP tables is overly dangerous, and this is why management has to make a difficult decision between what the functional consultants are saying and what the in-house development lead is saying.
As a consulting developer, my job (fortunately!) is to collect the relevant facts and present a clear picture to the development lead, so that he or she can in turn present a clear picture to management.
It will be interesting to see the eventual outcome of this situation, and I will of course report this outcome back to this thread.
And again, thanks very much for taking the time to respond.
djh