Standard behavior to GR_BASEDIV flag

[laurent_burtaire]

Hello,

i asked to have clarifications concerning points in this below wiki:

Topics of PO Vendor Flags - Standard behavior to GR_BASEDIV flag

Does anyone have an idea?

Thank you for your help.

Regards.

Laurent.

[ImreMatyas · Accepted solution]

Bonjour Laurent,

Je réponds en anglais pour la visibilité...

Let me answer the b, question first. You're right regarding the /SAPSRM/CL_PDO_DYN_MDF_IT_PO. If that would be the only check, that could lead to problems. The reason why it is coded like this, is that the check for GR-BASED_IV itself is done elsewhere.
(The code you mentioned only sets the metadata on item-level based on follow-on docs.)

The check itself is being done in the include LBBP_PDIGPF0B, FORM PO_ITM_CHECK :

IF i_com-itm_type NE c_hier. =====>>> If no hierarchy items;
IF p_itmigp-subtype = c_subtype_i_dp OR =====>>> If direct PO or extended;
p_itmigp-subtype(1) = c_subtype_i_extd.
IF lv_quan_cf_e IS NOT INITIAL =====>>> If there are GR's OR
OR lv_quan_iv_e IS NOT INITIAL. =====>>> If there are IR's :
* For ECS if follow-on document exists, retain the old flag value for gr_basediv
cs_new_itmpset-gr_basediv = ls_retain_flags-gr_basediv. =====>>> Flag should not be touched.
ENDIF.
ENDIF.
ENDIF.

That should work for the case you mentioned , too. Problem can happen if there are replication issues of "lv_quan_cf_e" or "lv_quan_iv_e" > see Troubleshooting of 1934728 .

Now let me come to the first question a, .

In the same check code include LBBP_PDIGPF0B, FORM PO_ITM_CHECK :

the system only checks whether there was a change/update and whether the vendor is given or no:

IF ( i_com-ev_vendor_changed = gc_no OR
i_com-update_from_ev_vend_chgd = gc_yes )
AND i_com-vendor IS NOT INITIAL . " ir_ind is not checked if vendor is not yet set

So in my understanding the back-end update of the same Vendor itself wont trigger new flag-determination here on PO. But this is a complexe question and it would worth to try in runtime debugging. Maybe I'll come back to you later if I find more info about this. In case you have a reproducible scenario, you could also raise this in an OSS incident under component SRM-EBP-POR.

Merci pour votre question, en tout cas j'espere que vous trouvez notre Wiki utile.

Bien á vous,

Imre

[laurent_burtaire]

Hello Imre,

thank you for your anwser and your precise information.

For point b), as PDO check is done on Confirmation and Invoice, I would have thought normal to have same process at UI level (metadata) to not allow something PDO will finally not allow.

For point a), that what i thought also.

Merci beaucoup pour cet excellent Wiki.

Cordialement.

Laurent.