cancel
Showing results for 
Search instead for 
Did you mean: 

Best way for getting DEBMAS+ADRMAS

Former Member
0 Kudos

Dear all

As we know DEBMAS idoc does not contain address data. Address fields are contained in ADRMAS.

I want to know the best way to achive this requirement. How to club these 2 idocs?

Regards

Monika

Accepted Solutions (1)

Accepted Solutions (1)

rajasekhar_reddy14
Active Contributor

Extended DEBMAS IDoc and add adress fields and implement the code. take help from ABAPer. this is best approach

Former Member
0 Kudos

Dear Raja

thanks for your response. Can we not trigger both idocs and create a single message? Also for that one address field i can do a RFC Look up too?

Are these feasible?

Regards

Monika

Former Member
0 Kudos

Hello,

To create single message you have to extend the IDOC that will be the best one.

if you do the RFC look up then also u have to extend the IDOC to added the address field.

Regards,

Phani

Former Member
0 Kudos

Dear Phani

We can use RFC look up in message mapping, so this would not require idoc extension. From single message i meant in use both the idocs in the signature tab, and do some configuration on R/3 end?

Regards

Monika

PriyankaAnagani
Active Contributor
0 Kudos

Hi,

If you want to trigger multiple IDOcs and collect them in PI, you'll require a BPM for collecting. You can design IDOc to target interface with RFC lookup if you've any standard RFC. If not IDOc extension will be the good approach instead of creating ZRFC for getting address details.

Regards,

Priyanka

Answers (5)

Answers (5)

Former Member
0 Kudos

Hi,

We have enhanceed the message type in our project.

http://www.saptechnical.com/Tutorials/ALE/IDOCExtension/IDOCExtension.htm

We have followed this blog.

Regards,

Krishna Chauhan

former_member184681
Active Contributor
0 Kudos

Dear Monika,

Then it looks like FM BAPI_ADDRESSORG_GETDETAIL should work fine for you, just call it from graphical message mapping as you described. Use OBJ_TYPE = "LFA1" and OBJ_ID = CREMAS\E1LFA1M\LIFNR and you will find street 2 and street 3 in BAPIAD1VL table structure, as fields STR_SUPPL1 and STR_SUPPL2.

The question is: do you expect a high number messages daily in this interface? If not, then RFC Lookup should be ok.

Regards,

Grzegorz

Former Member
0 Kudos

Dear Grzegorz

We need to update and create new vendors.

I found a bapi. BAPI_BUPA_CREATE_FROM_DATA

Will this help?

Regards

Monika

Former Member
0 Kudos

No i guess this is only for creating Bupa.

Former Member
0 Kudos

Hi,

If i understand your requirement correctly...all you need is store the vendor master data along with the address...

I think below options can be looked at..

1. Use idoc type CREMDM...so that it will contain all the info needed in one idoc only..n then do the remaining things in PI for the target system..

2. Another option can be to use the two idocs and using update_insert statement at the PI for insert/updating the data at the Database using Vendor Number as key..

Hope the above helps..

Rajesh

Former Member
0 Kudos

Dear Rajesh

the issue with CREMDM would be it will not be triggered automatically on vendor save/update.

We would have to use bpm for having 2 idocs on the sender side. How can we do it without bpm?I have used serialization on the receiver side for idocs, how does it work on the sender side, how would the message structure be formed in this case.

Regards

Monika

former_member184681
Active Contributor
0 Kudos

Hi,

You have multiple options to do what you require. Here are some of them, in the sequence of preference (from my point of view):

1. Only use one of the messages (DEBMAS or ADRMAS), choosing the one that matches your needs better. Add the IDoc extension to the chosen IDoc type and use ABAP code to populate a custom segment with additional fields. Based on my experience, I would prefer this particular approach.

2. Only use the change pointers mechanism of DEBMAS/ADRMAS/both, then write a custom ABAP report that will process those change pointers and execute a proxy to pass the data to XI. All in all it might so happen that writing that functionality on your own requires less work than adjusting existing ones, while you gain total control over the process. I would prefer that approach if the message structure is not so complex and there are not so many places to collect data from. Moreover, you can send multiple customers with once connection this way (just build the proxy structure properly).

3. Send both DEBMAS and ADRMAS independently from ECC, while in XI create a Business Process that will wait for both of them and bundle them to a single outgoing message. However, many XI users are reluctant to use BPM.

4. You can trigger only use an RFC lookup I do not recommend using RFC lookups as they have negative influence on the performance. If you decide to do it anyway, check BAPIs for instance: BAPI_CUSTOMER_GETDETAIL2, BAPI_ADDRESSORG_GETDETAIL (with OBJ_TYPE KNA1 and OBJ_ID = customer's number with leading zeros) or similar.

Regards,

Grzegorz

Former Member
0 Kudos

Dear Grzegorz

Thanks for your response. By RFC look up i mean

I will use standard idoc CREMAS for most of my fields. However i need street 2 and street 3, here in the graphical message mapping i will do a RFC look up and get the required street and map it further,

My scenario would still be IDoc->JDBC.

Please comment,

Regards

Monika

Former Member
0 Kudos

Hi,

Another way will be, identify the fields with required length in the header segment of Idoc DEBMAS which are not used for your scenario. In the process code of the Idoc, through user exit, fetch the data and populate those segment fields and then map the same with the output.

Reg,

NJ

Former Member
0 Kudos

Hi,

My suggestion would be to go for an extension of DEBMAS and include the address rather than handling it in PI.

Regards,

Manjusha