版权声明：署名，允许他人基于本文进行创作，且必须基于与原先许可协议相同的许可协议分发本文 （Creative Commons）
Taking initial upload & delta upload for example, once the inbound processing on ERP side has finished,
So if one message is required to be sent from ERP to CRM and visible in tcode SMW01, at least corresponding changes must be done based on above three points. We have a customer incident handy, which complains about the ERP message returned to CRM while doing equipment uploading. The use case is like this: · Business partners and equipment have been downloaded. · In CRM, user change the sold-to party to another BP downloaded from ERP and save. · Equipment update is transferred to ERP with the old sold-to party deleted and new sold-to party inserted. · While doing new sold-to party inserting, the account group is checked with error, so ERP equipment sold-to party update failed and a message of type I is raised: IX I 046 The customer account group is not allowed for the partner function
Now, at CRM side, the equipment upload is done successfully with no error message in BDoc. Customer regard it as an issue of product, because the sold-to party at ERP side is not updated successfully. We are not very clear on how & what validation message transfers between ERP and CRM. Could you give us a hint, please? Thank you for your time!
Below is a screen shot of where the message raised at ERP side:
To: Wang, Jerry Subject: RE: question regarding CRM Middleware
一些新发现： 是否有message retrun给CRM取决于FM CRM_EQUIPMENT_UPLOAD_OS中的lt_bapiret2是否有entry 而在account group 检查出错的地方（FM PM_PARTNER_MAINTAIN line 264），并没有raise exception, 这样在caller FM CRM_IHPA_CHANGE_OS里（line 122）就不会去组装bapireturn。
FM PM_PARTNER_MAINTAIN line 264
if h_nrart = 'KU' and g_obtyp <> 'QM1'. include claim_053. select single * from tpakd where ( parvw = parvw ) and ( ktokd = h_ktokd ). if sy-subrc <> 0. * message i046. perform ipar_message_store using yix yi '046' yc yc yc yc. exit. endif. include claim_054. endif.
FM CRM_IHPA_CHANGE_OS line 122
CALL FUNCTION 'PM_PARTNER_MAINTAIN' EXPORTING OBJNR = CS_ITOB-OBJNR PARNR = IT_BAPI_IHPA-PARTNER PARVW = IT_BAPI_IHPA-PARTN_ROLE TABIX = LV_TABIX CHECK_DEBITOR = ' ' EXCEPTIONS INVALID_PARNR = 0 CPD_CUSTOMER = 1 INVALID_PARVW = 2 PARVW_UNIQUE = 3 OTHERS = 4. IF SY-SUBRC <> 0. CLEAR LS_BAPIRET2. CALL FUNCTION 'BALW_BAPIRETURN_GET2' EXPORTING TYPE = SY-MSGTY CL = SY-MSGID NUMBER = SY-MSGNO PAR1 = SY-MSGV1 PAR2 = SY-MSGV2 PAR3 = SY-MSGV3 PAR4 = SY-MSGV4 IMPORTING RETURN = ES_BAPIRET2. EV_ABORT = 'X'. EXIT. ENDIF.
I agree it is definitely a BP customizing problem. But this exception is not sent to CRM middleware. That’s why customer is complaining. After debugging further, I found for new sold-to party inserting in ERP, FM CRM_IHPA_CHANGE_OS calls FM PM_PARTNER_MAINTAIN with parameter CHECK_DEBITOR = ’ ', which overwrites the default ‘X’. Therefore no exception is raised while sold-to party checking fails. As a result no bapireturn2 entry is created. While FM CRS_SEND_TO_SERVER tries to convert bapiretun2 entry into t_messages, nothing is there. We reckon CHECK_DEBITOR is set on purpose, so I forwarded incident to responsible for double check.
Another good analysis. One remark: Yes table ERROR_SEGMENTS is shown in SMW01. To be able to see an ERP message in SWM01 you do only have to fill internal table T_MESSAGES before the call of FM CRS_SEND_TO_SERVER (step 1 you listed below). Step 2 is completely handled by CRM Middleware. During this step the ERP message is also already mapped into the ERROR_SEGMENTS. When modules like the one you mentioned in step 3 are executed, additional messages could be added (and theoretically the ERP message could be deleted - even thought that doesn’t make sense but the ERROR_MESSAGES are a changing parameter).