This website is not affiliated with, sponsored by, or approved by SAP AG.
Help!! We have a requirement that I can not meet (yet). The business wants the first receipt (see their definition below) against a Purchase Order to undergo a special inspection characteristic.
By using dynamic modification at characteristic level, I have QM selecting the characteristic into the inspection lot on first receipt for each unique combination of material + vendor. However the business defines the requirement to also include material revision level. Purchase Orders specify material revision level but stock is only maintained at the material number.
Each first-time receipt for a new combination of material + revision level + vendor should cause the special characteristic to be required in that corresponding lot. All lots following are to be skipped on that special characteristic.
The large number of material numbers and the changes in revision level make frequent changing of quality level very unlikely. I have QM handling all but material revision level. Can anyone help with a configuration setting or an ABAP user exit where revision level can be considered--or even ideas with master data or combinations of things in Inspection Plan --or other!
Thank you for your ideas.
I faced the same problem, material revision is using, but quality level cannot be defined with revision level. when new revision material comes from vendor, quality level should be reset to initial stage of dynamic modification rule, otherwise, will have risk on quality.
do somebody have experience on this? especially user exit.
Craig, can you help?
I think the best way to handle this is via a user exit. I don't believe there is any standard functionality to address this.
I don't believe however you'll find this to be too difficult.
QAAT0001 (Inspection type determination different from variant 01) I believe is the exit you want to look at.
Create a new inspecition type, like "01FIRST". Assign a new plan usage to this inspection type. Like Z1.
Create two inspection plans. (I'd probably use the same Group number but different group counters for this. Of course that would depend on your clients procedure for creating inspection plans). The normal plan would have a plan usage of 5. The plan with the extra characteristic would have a plan usage of Z1.
Assign the material to both plans.
Activate both inspection types, 01 and 01FIRST. Do not set a preferred status.
In the user exit, insert logic to determine if an 01FIRST inspection type was ever UD'd for the material revision level. Use QALS-QPART, (looking for 01FRIST), QALS-MATNR and QALS-REVLV to search for insp lots. If not found, assign inspection type 01FIRST to be used. If found then assign inspection type 01. If found you might need a second check or logic to determine if the 01FIRST lot was passed or rejected. (QAVE-QBEWERTUNG). It depends on exactly what your clients rules are.
Once that is done, the correct plan should automatically be assigned.
I'm sorry. I thought you were trying to use the dynamic modification as a way to address the issue of first article inspection when using material revisions.
I wouldn't recommend it to be used for that, hence why I laid out the solution I proposed.
For influencing the quality levels and DMR you can look at the following user exits:
QDSE0001 Enhancement to affect Q position
QDSE0002 Changing the current insp. stage for sample determination
QDSE0003 Influencing init. insp. stage on autom. qual. level creation
Maybe for your issue, the 0002 would be the first one I would look at.
You might also want to seriously consider the long term impact of using the DMR at characteristic level for resolving your problem. What happens if two years from now the client really wants to do true DMR for tightening and reducing sample quantities for testing? Since you are using it for this first article inspection at a characteristic level, you will basically make the DMR functionality for sampling qty's no longer available as a future option for them.
Thanks for your input. yes, QDSE0002 is best one to reset quality level, but i cannot understand the potential issue regarding to the usage of QDSE0002. since we are using DMR at char. level already, can you elaborate more?
Sure. If you use DMR and the user exit we discussed, you are locking yourself into using DMR at the characteristic level across the board. I.e. For basically all your components.
So let's say you have 5 characteristics you always inspect and let's say you have one extra MIC that you do just for first article inspection, (as you indicate is currently done). For one, if at anytime you change from having one characteristic, to say two, or maybe three, you have to have the user exit reset the quality level to the initial stage for each of these. So when you are developing the user exit, make sure you have a way to determine which MIC's are for FA inspection and which are not. Do not hard code the Mic into the code. Either use a specific number range for them or put something consistent in the description. Another option is to use a specific operation for your FA inspection MIC's. I.e. by agreed upon procedure, operation 800 will only contain FA inspection MIC's and your user exit code is only programmed to look at operation 800 characteristics.
Now, let's say you have first article inspection set up and the client wants to reduce/tighten the sampling amounts, (say based on some AQL procedure) or they want true DMR where they fully inspect the first 3 shipments, then skip 5, then inspect 1. Your DMR is at the characteristic level now and each characteristic is tracked separately. This usally does not meet a clients needs. You don't want one characteristic required on one delivery whle another is skipped. Usually you want all the characteristics to be required or optional.
In your solution, on the first delivery, all the characteristics will be required. On the second delivery, your FA inspection characteristic is skipped. The other 5 are required. The third delivery is the same. But the client says that after three good deliveries, I want to skip all inspection testing, I.e. a true skip lot. And they only want to inspect every fifth shipment. This can work fine for awhile. Until one characteristic fails, let's say characteristic # 4 fails. And lets say it fails right after a full inspection.
Now the DMR sets characteristics 1,2,3 & 5 as skipped and 4 required. These are now out of sync with each other. As characteristic 4 now has to pass 3 inspections before becoming a skip again. But characteristics 1,2,3. & 5 will be on a different pattern now. And if say characteristic 2 fails, you would now have characteristic 1,3,5 in sync, but 2 & 4 would each be on their own pattern of inspections. You could wind up having lots created where at least one characteristic is required to be done and you would never see a true skip lot.
In addition, if you are moderating sample sizes and reducing and tightening them, and not just skipping, you could see sample sizes all over the place for any given inspection lot.
I hope all the above is clear. Let me know if you have any questions and I'll try to clarify some more.
Thanks for your detail explanation.
I agree with you, If DMR is defined at char. level, then it is not easy to get all chars. sync. but this is not only related to first article, but for all.
I have checked QDSE0002, only one output field E_STUFE_AKT, but this field is not related to each char., do it mean that the DMR can only be updated at lot level with this user exit? i'm wondering about this.
*" VALUE(I_DYNHEAD) LIKE QALS-DYNHEAD
*" VALUE(I_DYNTIME) LIKE QALS-STAT44
*" VALUE(I_QALS) LIKE QALS STRUCTURE QALS
*" VALUE(I_QDSE) LIKE QDSE STRUCTURE QDSE DEFAULT SPACE
*" VALUE(I_STUFE_AKT) LIKE QDPS-PRSTUFE
*" VALUE(E_STUFE_AKT) LIKE QDPS-PRSTUFE
INCLUDE ZXQDQU04 .
You are correct. My point was however that if you implemented DMR to address the FA inspection process, then the client is committed to DMR at the characteristic level. Which as you already know it can be difficult to keep the characteristics in sync. I just wanted to point that out because you don't have any idea how many times I come to a customer later on, (upgrade project, consolidation project, additional functionality project, etc..), and because of the way a solution was desinged, it prevents the customer from using something else. As long as you understand that and the client is aware of it, there is no problem. If you already use DMR at the characterisitic level it may not be an issue for you. Again, my point is just that you are using charac. DMR for something for which SAP really didn't design it for and as a result, there could be future issues using functionality for which it was designed for.
As far as you question about the exit, I guess it depends on how SAP calls the exit and the only way you'll know is by testing it and see if it's called for each characteristic in a loop or if it is only called once for the lot. I don't know that exact answer for that.
But if the exit is called, you can write you own include and do whatever you need to. You just have to be responsible for everything and of course you always have to worry about database locks, having your data overwritten or not saved when the exit returns, etc. etc.. typical stuff.
you are right, i could insert my own updating logic inside the user exit. and i found the user exit could change the current inspection stage temporarily for all char. with the loop. but i faced below problem:
(1) change quality level to initial stage
(2) change current inspection stage
when i put quality level updating logic in the user exit, and execute "COMMIT WORK" for function module. then system popup message "Operation QM12 not available for this lot", message number is QV224. if i write off statement "COMMIT WORK", then no problem with inspection lot creation. any idea?
Operation QM12 not available for this lot
Message no. QV224
The desired operation does not fit the inspection lot (object type).
The operation is not permitted and can therefore not be carried out.
INTO CORRESPONDING FIELDS OF i_qdqlv
WHERE werks = I_QALS-werk AND
matnr = I_QALS-matnr AND
plnty = I_QALS-plnty AND
plnnr = I_QALS-plnnr AND
plnal = I_QALS-plnal AND
lifnr = I_QALS-lifnr AND
dynregel = I_QDSE-dynregel AND "DMR
VORNR = I_QDSE-VORNR AND "operation number
MERKNR = I_QDSE-MERKNR. "char.number
i_qdqlv-prstufenae = '0010'.
i_qdqlv-anzpraen = 0.
i_qdqlv-anznioaen = 0.
i_qdqlv-aendlosm = sy-uname.
i_qdqlv-aedatlosa = sy-datum.
i_qdqlv-aezeilosm = sy-uzeit.
i_qdqlv-kzbuchen = 'U'.
CALL FUNCTION 'QDBU_Q_LEVEL_POST' IN UPDATE TASK
t_qdqlv_tab = i_qdqlv
post_err = 1
OTHERS = 2.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
COMMIT WORK AND WAIT.
Ok.. you are getting way beyond me. Was never an ABAP'er. So I can't really make comment on the code.
But I have read enough code and written in other languages that I have an idea what you are doing.
But the thing that jumps out at me and bothers me is the message that specifies QV12. Is it possible that you have a status profile in the Q-info record for supplier-relationship and the resetting of the QL or something else is conflicting with the current status profile being used? Since you are writing code that is technically outside the structures defined by the exit, you have to make sure your manage all things including any status rules.
I would suggest removing any status profiles entirely from a test inspection lot and running your code as is and see if you get the same message, no message or a different message. It might at least get you on the right track.
When you're calling a function IN UPDATE TASK, it'll be executed at the next COMMIT - the EXCEPTIONS addition is ignored, so the return code won't be changed. Assuming it was 0 before your function call - that is, assuming your SELECT was successful, it will keep this value.
Your COMMIT WORK AND WAIT is therefore executed, and your function is called immediately, as well as any other update function calls already registered.
If you comment out this COMMIT WORK, it will wait for the standard commit to call these functions.
I'd advise against using COMMIT WORK in exits in general,as the state of your object at this point might not be consistent.
68 74 74 70 3a 2f 2f 74 69 6e 79 75 72 6c 2e 63 6f 6d 2f 62 64 6f 37 6d 77 67
I may have only a very remote idea of what you're trying to accomplish, but I saw "ABAPer" in your post, so I had to butt in.
68 74 74 70 3a 2f 2f 74 69 6e 79 75 72 6c 2e 63 6f 6d 2f 62 64 6f 37 6d 77 67
Thanks for your reply. my new finding is:
Only activate QDSE0002
(1) If I didnâ€™t use COMMIT WORK, quality level cannot be changed, only change current inspection stage
(2) If I use COMMIT WORK, will cause data inconsistency because â€œCOMMIT WORKâ€ normally should not be used in User exit/BADI, then system popup message as my previous email.
Only activate user exit(EXIT_SAPLQAAT_002) to put quality level update logic, the updating works fine. But inspection lot will be created with CRTD status due to missing sample determination.
Activate user exit(EXIT_SAPLQAAT_002) together with QDSE0002, put quality level update logic into EXIT_SAPLQAAT_002 and put inspection stage change logic into QDSE0002, the quality level updating will be ignored as well.
Who is online
Users browsing this forum: No registered users and 5 guests