Hi,
Refer this link for IDOC Test environment.
Extending an IDoc Type
Purpose
In the case of a customer extension, you add additional segments to an IDoc type supplied by SAP (basic type), so that you can transfer more (or simply other) business information. This extension is upward compatible, that is, it will be supported by future releases.
Prerequisites
This checklist requires that the basic type to be extended is already included in the processing: This means, in particular, that the processing (inbound and outbound) is defined using process codes in the partner profiles and that the corresponding programs (for example, function modules) which lie behind the process codes are extended in the same way as the basic type.
You require development authorizations (authorization object S_IDOCDEFT, for example, in the role SAP_BC_SRV_EDI_DEVELOPER) for the extensions. Development takes place in the customer system.
Process flow
The following subsections contain the individual steps. The list can be used as a checklist when creating the extension. More information about the required steps and any alternatives can be found in the process flow diagram.
With the help of an example, you can define an actual IDoc type and process the type in a number of different ways. The example is used in each individual step. As a prerequisite, master data for the test customer TESTCUST (partner type KU) and the test vendor TESTVEND (partner type LI) must be present in the system. In addition, the example also assumes that the file port TESTPORT has been created.
Refer http://help.sap.com/saphelp_nw04/helpdata/en/dc/6b82a343d711d1893e0000e8323c4f/frameset.htm
Some IDoc types are supplied by SAP in the standard system: These are the basic types Other IDoc types are customer extensions: In these cases, a basic type is combined with an extension which is created by the customer, according to certain rules. Unlike customer extensions, these extended basic types are upward compatible.
Different terms were used in 3.X Releases: The current basic type was previously called a "basic IDoc type" and an extension was called an "extension type". The term "IDoc type" was used to denote both the extended basic type and the umbrella term.
Extensions are "appended" to basic types via reference segments. Since basic types cannot lose segments in subsequent SAP releases, compatibility is ensured.
Segments form the basic building blocks of an IDoc type and are used to store the actual data.
A segment type is the name of a segment and is independent of the SAP release.
The segment definition is the release-specific name of a segment. By combining the segment type and the release, the required segment definition can be determined: This way, you can assign segment definitions from previous releases to an IDoc type in the current release. This may be necessary if, for example, the partner is using an older release which supports your current IDoc type but not your current segment definitions. You then have to "reset" these in the Partner profiles .
The segment definition is also the external name of the segment that the partner system "sees".
Do not transfer the meaning of these terms to IDoc types: Therefore, an IDoc type ("an IDoc is an IDoc type filled with data") is always data-independent, while a segment type is always release-independent. A segment can be part of both an IDoc (data-dependent) and an IDoc type (data-independent).
Design Guidelines and Formatting Rules for Creating New Segments
Design guidelines
Do not re-invent the wheel
Before you create a new segment, check whether your requirements can be met by an existing segment. Use the EDI standards, for example, ANSI X12 (North America) or EDIFACT (worldwide). You should use ISO codes for coded field values so that they are based on a standard which is generally applicable. ISO codes exist, for example, for countries (ISO 3166), currencies (ISO 4217) and units of measure (ISO 31).
Group your data in a meaningful manner
Business data is contained in segment fields. Data which belongs together from a logical point of view should be combined to form a segment. Segments which belong together from a logical point of view should be combined to form a segment group. For example, the materials in a purchase order could be contained in one segment. Together with other segments (information about the partner, taxes and terms of payment), this segment can then form part of the "Items" segment group.
Create universal segments
You can use segments which you have already created in other IDoc types. Check whether a segment can be used for different messages. An example of a universal segment is one which contains general address data.
Create clearly arranged segments and segment groups
Position the required fields as close as possible to the start of the segment. Two segments which always occur together should be combined in one segment.
Consider whether the use of qualifiers can be avoided. Qualifiers indicate how a segment is used and are difficult to document and interpret. Qualifiers are not usually defined on a cross-application basis, with the result that these segments are not universal.
Don’t waste space
The maximum length of all the fields in a segment is 1000 characters. The larger the segment, the better the ratio of useful data to administration data. A certain amount of space should be reserved in segments to allow for additional fields in the future.
Document your segments
Use the documentation options provided by the segment editor. You can store an additional data element for each field to provide information about how the field is used in the application. You can also document a segment to explain the attributes and structure of the entire segment. When documenting segments, remember that the segment fields are used in both inbound and outbound processing.
Remember that conversion to EDI standards may be necessary
Regards
Aashish Sinha
PS : reward points if helpful
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.