on 01-05-2012 5:57 AM
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
Extended DEBMAS IDoc and add adress fields and implement the code. take help from ABAPer. this is best approach
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
My suggestion would be to go for an extension of DEBMAS and include the address rather than handling it in PI.
Regards,
Manjusha
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
87 | |
10 | |
10 | |
10 | |
7 | |
6 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.