Purpose
This page has the purpose of help to clarify some doubts related to the behavior of the Flag GR_BASEDIV in SRM and ECC system.
Overview
The flag GR_BASEDIV has different behavior when comparing SRM to ECC. The Master Data has important influence in this case. Here it is found a brief explanation how this flag should behaves in a PO transferred to ECC side.
Behavior
If SRM PO has no GR, the GR based IV indicator change with the vendor master. On the other hand, ECC PO even though there is no GR, the GR based IV stay the same no matter what in the vendor master record.
In ECC, the GR based IV ultimately control on the PO by PO basis. Whereas, in the SRM the GR based IV indicator control by the vendor if there is no GR on that PO yet. If there is GR, then the indicator stays the same.
It could be handling by BBP_DOC_CHANGE_BADI, however there is some restriction as we can see by note 1260486 - BBP_DOC_CHANGE_BADI: vendor and follow-on document flags
BBP_DOC_CHANGE_BADI can be used for follow-on document update only under following pre-requisites:
o No follow-on documents exist for the PO.
o No vendor is assigned to the PO (partner function: 0000019). Cause: RZ20 errors during PO transfer should be avoided caused by PO resp. vendor master follow-on document flags probably not being in synch with MM vendor master (XK03) or other Backend settings (e.g. OME9).
If the above pre-requisites are fulfilled follow-on document flag changes must be realized using Badi BBP_ECS_PO_OUT_BADI instead with effect to MM PO only.
In the ECC the flag is propose from vendor master, but the user can change it. In the SRM is not the same behavior once GR and IV flags are set to vendor. It is not possible to change according to the note: 1010791 - Flag Confirmation based Invoice Verification set erroneous. This note explains that when there is no flag set in the Master data, it is possible set what user wants in the PO:
In the material PO, the follow-on document related flags come from the supplier master record, at the purchase organization level. The related supplier master data is saved in the table BBPM_BUT_FRG0061. If in vendor master all these flags are not set, then from UI when buyer can set flags. If GR_IV and IR_IV flags are set, then GR_BASEDIV is automatically set. This is the standard system behavior. The buyer cannot change GR_BASEDIV from UI in this case.
Cutting it short, we have:
A) It is not possible manage the flags even using Badi, according to note: 1260486 - BBP_DOC_CHANGE_BADI: vendor and follow-on document flags;
B) The Flags come from Master Data (tcode BBPMAININT as example on SRM side);
C) According to note: 1010791 - Flag Confirmation based Invoice Verification set erroneous , if you unflag the GR_BASEDIV, but keep the others flags GR_IV and IR_IV, so the flag GR_BASEDIV will be flag again after check button.
Related Content
Related SAP Notes/KBAs
KBA: 1718228 - Collection notes to known issues related to GR_BASEDIV flag
SAP Note: 1260486 - BBP_DOC_CHANGE_BADI: vendor and follow-on document flags
SAP Note: 1010791 - Flag Confirmation based Invoice Verification set erroneous
3 Comments
Laurent Burtaire
Hello Rafael Rhoden, hello Tamas Koban,
i woul like to have clarifications regarding some points of this wiki.
a) sentence "If SRM PO has no GR, the GR based IV indicator change with the vendor master. On the other hand, ECC PO even though there is no GR, the GR based IV stay the same no matter what in the vendor master record."
At PO creation, document control flags come from SRM Vendor Master (table BBPM_BUT_FRG0061 populated during ECC vendor replication to SRM). So, 'Confirmation-Based Invoice Verification' field at UI level is populated with value of GR_BASEDIV field from BBPM_BUT_FRG0061.
If user changes this value (set to unset, or unset to set, based on initial value), it will be replicated to ECC PO during transfer, which means ECC vendor master data will not be used for ECC PO creation as leading PO is the SRM one.
What will happen in SRM PO, if:
1) in ECC vendor master data, WEBRE field (GR based IV) is changed from set to unset, or unset to set, based on initial value, then Vendor is retransferred to SRM,
2) then, user changes PO item (after Vendor replication), for example, PO item description (but none of the document control fields)
Does the 'Confirmation-Based Invoice Verification' UI field will be updated in the SRM PO based on new SRM Vendor Master data?
b) sentence "In the material PO, the follow-on document related flags come from the supplier master record, at the purchase organization level. The related supplier master data is saved in the table BBPM_BUT_FRG0061. If in vendor master all these flags are not set, then from UI when buyer can set flags. If GR_IV and IR_IV flags are set, then GR_BASEDIV is automatically set. This is the standard system behavior. The buyer cannot change GR_BASEDIV from UI in this case."
If I understand correctly, buyer cannot change GR_BASEDIV in the SRM Vendor Master.
But this point does not forbid user to set/unset 'Confirmation-Based Invoice Verification' in the SRM PO.
Nevertheless, on ECC side, if a Good Receipts exist, you cannot order the SRM PO due to ECC error message MEPO 025 (for non-SRM PO, ECC item field WEBRE is in display mode).
If this control is normal in ECC, why this check is not done in SRM in method DOCUMENT_FLOW from class /SAPSRM/CL_PDO_DYN_MDF_IT_PO?
I did not find any OSS note dealing with this issue (we are in Extended Classic scenario with SRM 7.14).
Thank you for your answers.
Regards.
Laurent.
Imre Matyas
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.