It’s necessary that users need to be noticed when some important fields in order been changed in the system. Sap provides transaction OMFS where you can maintain a combination of table names and table fields along with control flags to control whether Purchase order printout should be triggered or not. You can check my previous blog if you interest in this topic.
Now one requirement is to retrigger the output of the sales order only when some specific fields have been changed for the contact person at the header level (partner function is AP). Unfortunately, I didn’t find accordingly transaction for a Sales order to deal with the output retrigger after some changes. SAP does provide solutions at notes 395569 CHECKLISTSD: Change outputs.
This topic has been discussed many times, but still not easy to get all answers in one single place. This article tries to wrap up related points that could be used about retrigger SO output related to contact partners.
1. Allow multiple issuing of output
No one wants to keep receiving order confirmation for a specific order. By default, the system prevents the same output been issued to the same partner more than once. So the indicator of Multiply issuing should be ticked at the configuration of the output type.
2. Output control with filter conditions by customized routine
Of course, we don’t need to retrigger output after every change happens at sales orders. So have to filter the output retrigger only with specific conditions. This is controlled by two fields (APROG& AROUT ) at the T685B table.
For sales orders, create a routine called ZZ_ITEM_CHECK at include program MV45AFZZ. Set the return code when a specific field has been changed by comparing the old value fetched from YVBAP with the new value fetched from XVBAP.
FORM ZZ_ITEM_CHECK.
SY-SUBRC = 4. "default no output for all changes!
LOOP AT XVBAP.
IF ( UPDKZ = 'I' ) OR ( UPDKZ = 'D' ) "check if any changes at item level
<add customized conditions here for specific fields!>
SY-SUBRC = 0. "set to 0 means need output for this change!
EXIT.
ENDIF.
ENDLOOP.
ENDFORM.
Then maintain the program name and routine name at the output setting accordingly.
3. Get field changes for partner
For item level fields which can be achieved by the above routine and output setting. But for contact person changes, one field VBPA-ADRDA may need to pay attention to. I’m not sure it covers all cases, please correct me if I’m wrong.
Scenario 1: Initial Order creation without modification of default contact person
This field VBPA-ADRDA will be ‘D’ when an order created using default master data. For contact person data which comes from table KNVK, for the customer which from table KNA1. (Be cautious that user exit may impact this process). Please notice that ADRNP is blank here as no selection of contact person. (Btw, changes at VAP2 will update the contact person against ADRC-ADRNR but not related to order level at all.)
Scenario 2: Change contact person after order been created
This field VBPA-ADRDA still equal to ‘D’ when the user chooses a different contact person other than the default in the below screen.
At the VBPA table, field ADRNP been updated to a newly selected partner. The table source here is ADRP.
Scenario 3: Manual change contact person details after order been created
This field VBPA-ADRDA will turn into ‘E’ when the user modifies the contact person details at the below screen.
At the VBPA table, we can find the ADRNR been replaced with a new address number 9000080912 which is been created along with the saving event of this order instead of update the previous address number 0201342374.
In the changelogs table CDPOS, there are several new insertions against this new address number at ADR* table. The object class is ADRESSE, and the object ID is ‘SD01’ plus this new address number.
- For validation purposes, you can try USEREXIT_SAVE_DOCUMENT_PREPARE in MV45AFZZ. Internal table XVBADR holds both old and new values for NAME1-NAME4
Source: sap.com
No comments:
Post a Comment