Problem with the incomming bDocs

[Former Member]

Hi Experts,

We have limited the number of bDocs from CRM to ECC for contact person creation. This was done by adding Z Function Module to table CRMC_BUT_CALL_FU, for CRMOU (CRM 4.0).

Now this caused a problem with the incomming bDocs (ECC -> CRM).

Is there a way to consider the sending side in our Z module?

I have also seen a Badi to control MW flow (CRM_DATAEXCHG_BADI).

Best regards,

Christina

Edited by: Christina Hammer on Apr 22, 2010 5:06 PM

[Former Member · Accepted solution]

Hi Christina,

Can you explain in detail what is the problem you face when the bdoc's come into CRM from ECC?

On a different token, CRMC_BUT_CALL_FU has an event field - BPOUT / BPIN for differentiating inbound and outbound transactions.

[Former Member · Accepted solution]

Hi Naresh,

To explain a bit more in detail.

The incoming bDoc corresponds to a newly created BP in R/3. When a new BP is created in R/3, we have a red bDoc with error message "Validation error occurred: Module CRM_BUPA_MAIN_VAL, BDoc type BUPA_MAIN", also with error message "BP with Guid XXXX does not exist (R11124)". Also we have a green BDoc without any error and finally the BP is replicated correctly to CRM.

But obviously the red bDoc is not desired.

The BPOUT and the BPIN exist for CRM 5.0 and higer, I believe.

But we are working with CRM4.0.

Best regards,

Christina

Edited by: Christina Hammer on Apr 22, 2010 9:12 PM

[Former Member · Accepted solution]

In that case, please check if you can configure a function module in table SMOFSUBINT (service = 'RCV').

[Former Member · Accepted solution]

Hi Naresh,

I believe it will be possible to create a new entry in table SMOFSUBINT with trx. SM30.

But I do not understand.."What should the FM contain?" How can it influence the valudation error?

Best regards,

Christina

[Former Member · Accepted solution]

Good morning Naresh,

What about the idea of adding a filter "sender side " to our Z function module for outgoing bDocs? Would this be possible in CRM 4.0?

Best regards,

Christina

[Former Member · Accepted solution]

Christina,

The Bdoc in itself has an inbound / outbound flag. Can't you use that in your FM.

Can you also briefly explain what kind of validation error you are encountering on an inbound Bdoc ? I do not want to give a half-baked solution without understanding the root cause of the issue.

Naresh

[Former Member · Accepted solution]

Hi.

What's the goal of view SMOFSUBINT ?

Regards.

Susana Messias

[Former Member · Accepted solution]

The goal is if you want to remove BAPI segments based on certain logic before getting into CRM you can use this table.

[Former Member · Accepted solution]

Naresh:

On one hand, I do not know how to insert the sending side in our Z FM.

On the other hand, I do not understand the validation error of this bDoc. It is the first of 3 bDocs that ends with this error. This only happens for newly created BPs in R/3. Modification of existeing BPs does not cause erroneous bDoc.

As I stated before the messages are:

"Validation error occurred: Module CRM_BUPA_MAIN_VAL, BDoc type BUPA_MAIN" (EN),

"BP with Guid XXXX does not exist (R11124)" (Working language),

"BUPA_MW_EXCHANGE010" (Working language).

When I reprocess the bDoc, it still ends with the same error messages.

Best regards,

Christina

[Former Member · Accepted solution]

Hi Naresh:

I need to supress the incomming bDoc when the HEADER-OBJECT_TASK = U and the error message is ID=R11, Number=124.

These bDocs come with error. But later the BP is replicated by a correct bDoc anyway.

I am a little bit confused.

I think the problem could be solved with a Z FM in table CRMC_BUT_CALL_FU for CRMIN, BUPA. It should delete the C_BP_STRUCT-Partner in case the HEADER-OBJECT_TASK = U and the error message is ID=R11, Number=124. You mentioned this solution at the beginning of the thread.

What is the advantage of using view SMOFSUBINT?

Thanks and best regards,

Christina

[Former Member · Accepted solution]

I threw this option of using SMOFSUBINT if you want to interrogate ECC fields (BAPI structure) before even a BDoc gets generated.