Customer changes!

[Former Member]

I have one more question. I am creating a debmas idoc whenever there is a change/insert to a customer. But how do I trap a classification change in the change document/change pointers table?

Thanks,

[Former Member]

Classification is sent via CLFMAS message and can be activated for change pointer processing like DEBMAS.

[Former Member]

Do the customization for change pointers. For this you need to activate the change pointers globally in BD61.

Declare activate message types for change pointers with view V_TBDA2.or transaction BD50 or .

SALE -> Activate change pointers for message types

use the program RBDMIDOC to process the changed data.

During the processing, it calls the actual IDoc creating module MASTERIDOC_CREATE_DEBMAS .

To summarize the change pointer concept

·Change pointers record relevant updates of transaction data

·Change pointers are written separate from the change documents, while at the same time

·Change pointers are evaluated by a collector run

Below are th FM those works for this concept

CHANGE_DOCUMENT_CLOSE

CHANGE_POINTERS_READ

CHANGE_DOCUMENT_CLOSE

[ferry_lianto]

Hi Somen,

You need to activate change pointers (BD61) and change pointers for messages type CLFMAS (BD50) in order to trap any classification changes in table BDCP and BDCPS.

Regards,

Ferry Lianto

[Former Member]

Right. But I need to send classification info (CLFMAS) when ever customer master is changed (DEBMAS) and vice versa. Is there any way where I can create a change pointer for classification changes for customers like any BTE's?

[Former Member]

You could add classification change objects to the customer master message type via BD52. Likewise, you could add all customer master change objects to the classification message. I would recommend using custom copies of the DEBMAS and CLFMAS messages for this, however.

Better yet, create one custom message ZDEBMAS_CLFMAS and assign all customerr and classification change objects in BD52. Create a copy of FM MASTERIDOC_CREATE_SMD_DEBMAS and configure your new message to use this function. It will get executed when you run RBDMIDOC for the new message.

In the custom function, you can code the creation of both customer and classification messages.

Another option would be to make a custom message with customer and classification change objects assigned and extend DEBMAS05 IDoc to include the relevant fields from classification. Use the standard FM mentioned above, and populate the custom segments in the user-exit.

[Former Member]

I had awarded points to answers, but I would like to keep this question open. Looking for different solutions.

Thanks for the replies.

[Former Member]

I think wou will find your options somewhat limited. The primary issues are:

1. Capture changes to customer and classification data.

2. Send both customer and classification data to external system when change occurs to either.

Standard change pointers would be used to capture changes. This can be done with standard or custom message types. I would suggest custom.

As for sending the data. Output would be triggered with standard change pointer processing via RBDMIDOC. It's up to you to decide whether you want one IDoc for each type of data, or collected as extension of one of them, or collected on entirely new IDoc.

[Former Member]

Thanks for the replies again.

Whenever a field on customer master (other than classification) is changed, I am processing those changes using RBDMIDOC program and generating DEBMAS06 IDOC.

And coming to classification data, the middleware (Webmethids/XI) will make an RFC call passing the customer number ans will get the classification. The middleware will pick the data from IDOC and RFC function, put in some format and send that to legacy system.

Now I think of one solution. Whenever classification is changed, there will be a change pointer or change document created of object type CLASSIF. Read those entries and get the object value from TABKEY or OBJECTID field (read DEBI objects also) and then pass it to BD12 transaction program instead of using RBDMIDOC.

Does this approach sound reasonable?

Thanks,

[Former Member]

The solution sounds like it would work, but you introduce a little unneccessary overhead requiring XI to make the RFC call back to R/3. Since your solution will require capturing change pointers for both customer and classification changes anyway, consider adding the classification change objects to your customer message type, then extend your customer IDoc to include those fields from classification you wish to send. This would require a custom version of MASTERIDOC_CREATE_SMD_DEBMAS so you can generate the customer IDoc from classification objects. The standard FM would obviously only recognize customer changes. The custom function can be assigned to your custom message type using BD60.

Using the custom function would also handle setting the PROCESS field in BDCPS for your captured change entries.

[Former Member]

Actually I must had made myself little bit clear in the beginning itself that all the interfaces in our project follow RFC approach. They said NO to the solution of IDOC extension or a complete new IDOC. So that was the reason why I was looking for other alternatives.

But thanks for your responses. They are really helpful.

I awarded points to you.

Thanks,

[Former Member]

Best of luck.