IDocs: A Guide for New Developers – Part 3

Recommend This Post!Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

Tony CecchiniAnthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company  headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation,  implementation, upgrade, and training assistance to   companies. Anthony has over 17 years of  experience in SAP R/3 business process analysis and SAP systems integration. His  areas of expertise  include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro  development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com.

The SAP IDoc Technology

In this month we will continue our look at SAP IDocs and the IDoc Technology by exploring IDoc extensions and enhancements.

Why do We Need an Extended IDoc?

Standard SAP sends out or receives in data through IDocs using standard delivered Segments, Message Types and fields. But sometimes, these fields are not sufficient for a specific end-to-end business scenario as far as data transfer is concerned. So in such scenarios, we can add new segments with completely new structures to the standard IDoc as an extension. We create a brand new structure and insert it into existing delivered IDoc structure creating a whole new IDoc satisfying the requirement. This new IDoc is called an Extended IDoc.

As an example, lets take a scenario in billing, where we already have a predefined IDoc type ‘INVOIC02’. But the requirement is to transfer an additional structure containing the fields VBRK-KTGRD (Account assignment group for this customer) and VBRK-MANSP (Dunning block). In order to fulfill this requirement, we need to create a new segment structure, add two additional fields to it, then add it as an extension to the existing IDoc Type ‘INVOIC02.  Sound good? OK lets take each step in turn …..

Create a new IDoc Segment using transaction WE31

Our first task is to create a segment with the two new fields VBRK-KTGRD (Account assignment group for this customer) and VBRK-MANSP (Dunning block). In this transaction we create a segment type. This segment type has two fields KTGRD and MANSP as specified from VBRK table. This segment will be used in the final extended IDoc.

Lest take a look at the standard IDoc INVOIC02 using transaction WE30. We want to add our new segment under the first header segment E1EDK01 as a CHILD segment.

IDocs Display WE30

OK, now lets use WE31 to create a new Segment ZE1EDK01.

IDoc Extension

 

Next we enter a description, add our two new fields and hit save.

Idoc Extension

When you hit SAVE, you will get a popup as below. Just put in your User-id. The next popup will be for the transport system, for now, lets just make this a LOCAL OBJECT.

IDocs

 

At this point we can RELEASE the segment by following the menu path below. If for some reason you need to change the segment after it has been released, go back and cancel the release and make your changes.

IDoc Extension

 

 Create a new IDoc Type (Extension) using transaction WE30

Now we can use transaction WE30 to create the new Extension Type ZINVOIC02. Fill in the Obj. Name and hit CREATE.

Please be sure to mark the new IDoc type as an extension!

IDoc Extension

When you hit the CREATE button, a new popup screen will appear. Fill in the description and enter the IDoc Type we want to extend and hit the GREEN Check.

For us this will be INVOIC02.

IDoc Extension

You will get a screen showing our extension ZINVOIC02 and a set of segments belonging to the standard IDoc INVOIC02. Since the extension has VBRK-KTGRD and VBRK-MANSP and they belong to “HEADER” tab in SAP Billing transaction VF02 the extension is done for the relevant segment type E1EDK01 related to “Header General Data”. Click on the E1EDK01 Segment to place focus on that segment and click the create button.

IDoc Extension

When you hit the CREATE button, yet another new set screens will appear. The first Pop-Up is information only and you can ENTER past this. You will see our new segment will be a CHILD segment to the PARENT segment E1EDK01.

IDOCS

 

The next screen is for identifying our new segment we created way back using transaction WE31, and, maintaining the attributes for the new segment. The attributes include whether it is a mandatory Segment. The Maximum and minimum numbers specify the number of times the segment can be repeated in sequence. The Hierarchy level suggests the parent/child relationship. Segments which have a parent segment (like ours) have a hierarchy level which is one higher than that of their parent.

We will use our new custom Segment ZE1EDK01, set it to mandatory, and use a minimum and maximum of 1. Enter these values and click the GREEN check button.

IDoc Extension

Almost there! Now after you hit the GREEN check, you will have the distinct privilege of seeing the result of your hard work. The actual Extension Type with our new segment shown. All we need to do now is hit the SAVE button. Again, for our purposes we will make this a LOCAL object so no transports are necessary.

IDoc Extension

The last and final step is set the RELEASE flag on this extension. Once you have done this the IDoc Extension is ready to use!

IDoc Extension

 

Summary

So in summary, we needed a IDoc Type that was different than the delivered IDoc Type of INVOIC02. We needed to add new fields. We achieved this by creating a custom segment, adding our fields to it, then inserting into the delivered IDoc Type as a NEW IDoc Extension.

To read the part 1 of the Blog click HERE

To read the part 2 of the Blog click HERE

In the next part of this blog series we will take a look at how we can use this new IDoc Extension. Create a custom Message Type, assign this to our New IDoc Extension and configure the Partner Profile.

ITP logo

If you enjoyed this blog, IDocs: A Guide for New Developers – Part 3, please fill out the form below to sign up for our newsletter. We deliver SAP Technical tips & tricks, SAP news, and the current month’s BLOG right to your inbox!

Recommend This Post!Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

Related Posts

Comments (7)

[…] In this month we will continue our look at SAP IDocs and the IDoc Technology by exploring how we can use the new custom IDoc extension we created in the last blog. If you need a refresher on how to extend an IDoc CLICK HERE […]

[…] In this month we will continue our look at SAP IDocs and the IDoc Technology by exploring how we can use the new custom IDoc extension we created in the last blog. If you need a refresher on how to extend an IDoc CLICK HERE […]

Hi, we have request to post Delfor with delivery block at the item level. But in DELFOR02 idoc, it did not have this delivery block field. Can someone advise how we can achieve this? Should we create a extension idoc?

Can you elaborate a bit? It may help folks answer your question… Is this inbound? What release of SAP? ECC 6.0? Are you trying to block at the header(VBAK) or (VBEP) Schedule line level? LIFSP or LIFSK. Neither may be in the basic IDoc, but it may help to know when determining if we have an old CMOD exit or BAdi, or even an Enhancement SPOT. And yes you may have to create an extension.

Hi Anthony, Thank you for your reply. We are current using ECC 6. We would like to block certain schedule line item VBEP-LIFSP when customer send in their Delfor or Deljit information to us. We are currently using DELFOR02 Idoc, we are not able to find this delivery block field in this Idoc. Is there any other delfor idoc we can use? What are the best way to handle this? Thanks

Hi Anthony, do you have any suggestion for me on how we can work on?

I checked and were are DELFOR02, so I believe the answer is no.

So, you need to understand IDocs so I am assuming I am speaking to a developer….

A couple ways to look at this… At a very high level… YOU WILL NEED TO DIG IN…

You have to probably extend the IDoc basic type and add a field for the block. This also assumes the data coming in has the block so in your middleware mapping you can populate the new IDOC field. If it’s not a one-to-one mapping, then you create a translation table in the middleware. This will require constant maintenance as new reasons for blocking are added. OR, create the translation table in ECC, still needs constant maintenance.

Another way is not to extend the IDoc because the block isn’t coming in already. BUT there are fields populated that you could check to KNOW that this should be blocked.

Regardless of the above two situations, you will have to find the FM be used that is currently processing the message type. You could jump into SE16 -> enter table name EDIFCT -> enter Idoc type DELFOR02 -> here you can see list of FM.

Once you have the FM, you will need to find the appropriate CMOD, BAdi, Enhancement point or SECTION to drop some code in. Inside you could check either the discrete field holding the block from your extension, or the set of conditions and update VBEP-LIFSP.

Good Luck!

Comments are closed.

Pin It on Pinterest

Share This

If you enjoyed this post, why not share it with your friends!