Tag Archives: IDOC

Deletion / Archiving of IDOCs

7 Replies

There is no special deletion program for IDocs.
Use the archiving programs. IDoc is a separate archiving class. The following programs are available:

1. Archive RSEXARCA and RSEXARCB (as of Release 3.0C)
2. Delete RSEXARCD
3. Read archiveRSEXARCR
4. Restore RSEXARCL

RSEXARCB is similar to RSEXARCA except for the selection screen. The selection options for RSEXARCB are designed for periodic scheduling.

The Idoc archiving is checked against the status. The statuses which can be archived and those that cannot be archived are stored in the “Status maintenance” table. You can change the standard settings. Menu path: Area menu “WEDI”, control, status maintenance.

Advertisement

Program To Generate IDoc

3 Replies

Report  ZZ_Program_To_Create_Idoc

report  zz_program_to_create_idoc                     .
tables: ekko,ekpo.

selection-screen skip 3.
selection-screen begin of block b1 with frame title titl.
selection-screen skip.
select-options s_ebeln for ekko-ebeln.
selection-screen skip.
selection-screen end of block b1.

data: header_segment_name like edidd-segnam value 'Z1EKKO',
      item_segment_name like edidd-segnam value 'Z1EKPO',
      idoc_name like edidc-idoctp value 'Z19838IDOC1'.

data: header_segment_data like z1ekko,
      item_segment_data like z1ekpo.

data: control_record like edidc.

data: messagetyp like edmsg-msgtyp value 'ZZ9838MESG1'.

data: i_communication like edidc occurs 0 with header line,
      i_data like edidd occurs 0 with header line.

data: begin of i_ekko occurs 0,
      ebeln like ekko-ebeln,
      aedat like ekko-aedat,
      bukrs like ekko-bukrs,
      bsart like ekko-bsart,
      lifnr like ekko-lifnr,
      end of i_ekko.

data: begin of i_ekpo occurs 0,
      ebelp like ekpo-ebelp,
      matnr like ekpo-matnr,
      menge like ekpo-menge,
      meins like ekpo-meins,
      netpr like ekpo-netpr,
      end of i_ekpo.

start-of-selection.

select  ebeln aedat bukrs bsart lifnr from ekko
          into table i_ekko where ebeln in s_ebeln.

select ebelp
       matnr
       menge
       meins
       netpr
       from ekpo
       into table i_ekpo
       where ebeln in s_ebeln.

control_record-mestyp = messagetyp.
control_record-rcvprt = 'LS'.
control_record-idoctp = idoc_name.
control_record-rcvprn = '0MART800'.

loop at i_ekko.
header_segment_data-ebeln = i_ekko-ebeln.
header_segment_data-aedat = i_ekko-aedat.
header_segment_data-bukrs = i_ekko-bukrs.
header_segment_data-bsart = i_ekko-bsart.
header_segment_data-lifnr = i_ekko-lifnr.
i_data-segnam = header_segment_name.
i_data-sdata = header_segment_data.
append i_data.

select ebelp
       matnr
       menge
       meins
       netpr
       from ekpo
       into table i_ekpo
       where ebeln = i_ekko-ebeln.

loop at i_ekpo.
item_segment_data-ebelp = i_ekpo-ebelp.
item_segment_data-matnr = i_ekpo-matnr.
item_segment_data-menge = i_ekpo-menge.
item_segment_data-meins = i_ekpo-meins.
item_segment_data-netpr = i_ekpo-netpr.
i_data-segnam = item_segment_name.
i_data-sdata = item_segment_data.
append i_data.
endloop.
clear i_ekpo.
refresh i_ekpo.
endloop.

call function 'MASTER_IDOC_DISTRIBUTE'
  exporting
    master_idoc_control                  = control_record
*   OBJ_TYPE                             = ''
*   CHNUM                                = ''
  tables
    communication_idoc_control           = i_communication
    master_idoc_data                     = i_data
 exceptions
   error_in_idoc_control                = 1
   error_writing_idoc_status            = 2
   error_in_idoc_data                   = 3
   sending_logical_system_unknown       = 4
   others                               = 5
          .
if sy-subrc <> 0.
 message id sy-msgid type sy-msgty number sy-msgno
         with sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
else.

  loop at i_communication.
    write: 'IDOC GENERATED', i_communication-docnum.
  endloop.
  commit work.

endif.

initialization.
titl = 'ENTER THE PURCHASE ORDER NUMBER'

IDOC / BAPIs

2 Replies

There are many differences between IDOCs and BAPIs.

BAPIs in 3.1 are synchronous; in 4.+ they can be asynchronous (and I
believe they then drive certain ALE/IDOCs).

BAPIs are called from the outside-in.  That is, an external program
invokes a BAPI that gets data from SAP to display or updates data in
SAP.  The BAPI concept does not include an event concept — you cannot
tell SAP that when certain events happen to a “business object”, to fire
a message or a file to an external system.

BAPIs are invokable from Java or C/C++ or Visual Basic (and I think some
people are using Delphi).

In 3.1x there are very few BAPIs to use.  In 4.+ SAP has added a large
number.

BAPIs are not totally immune to upgrades but if they are to be retired
you supposedly will have them supported for two releases.  Whether those
are point or letter releases, I don’t know.   I believe that IDOCs may
be more changable from release to release.

BAPIs are reasonably well documented and there is a common place to look
to see what is available.   IDOCs — I have heard — are poorly
documented in terms of finding them, and IDOCs were done differently by
different groups in SAP.

BTW, you can also use Java, C/C++, Visual Basic, … to invoke RFCs in
SAP and get or update data.  That’s how the BAPIs work since they
utimately are sets of RFC calls (written to a design spec for BAPIs).

What is the different between ALE, IDOC and BAPI?

3 Replies

ALE (click here for documentation)

ALE is SAP proprietary technology that enables data communications between two or more SAP R/3 systems and/or R/3 and external systems. When a new enterprise resource planning (ERP) solution such as R/3 is implemented, companies have to interface the ERP system with legacy systems or other ERP systems.

ALE provides intelligent mechanisms where by clients can achieve integration as well as distribution of applications and data.

ALE technology facilitates rapid application prototyping and application interface development, thus reducing implementation time.

The ALE components are inherently integrated with SAP applications and are robust, leading to a highly reliable system.

ALE comes with application distribution/integration scenarios as well as a set of tools, programs, data definitions, and methodologies that you can easily configure to get an interface up and running.

BAPI

BAPIs provide a stable, standardized method for third-party applications and components to integrate into the Business Framework. These interfaces are being specified as part of SAP’s initiative with customers, partners and leading standards organizations. Also, SAP has implemented the emerging Object Application Group (OAG) specifications with BAPIs.

BAPI AND CALL TRANSACTION

BAPI
One of the big plusses for BAPIs is that the interface and function are not supposed to change. This is a big plus when you do upgrades or hot packs because the transaction can change (format, required inputs etc) which means you then need to update the call transaction.

Some of the BAPIs are better documented and easier to use than others.

You usually need to perform the BAPI that actually does the COMMIT after you call your BAPI.

The Program coding for calling a BAPI is usually cleaner than setting up the screen flow etc for the Call Transaction.

You don’t need to worry about special data circumstances interrupting the normal data flow of the screens and causing errors because of that.

BAPIs probably have better performance since they don’t do the screen flow processing.

In general if the BAPI exists for the transaction you want to perform and you can figure out how to use it the BAPI is probably the best way to go.

This is just from my experience working with both BAPI and Call Transaction. I have had some very good successes with BAPIs, but very occasionally found that I could not get the BAPI to perform the update I needed.

The interface concept of the classic R/3 is based on two different strategies: Remote Function Calls (RFC) and data exchange through IDoc message documents. RFC makes direct and synchronous calls of a program in the remote system. If the caller is an external program it will call an RFC-enabled function in R/3 and if the calling program is the R/3 system it will call an
RFC-function in another R/3-system or it will call a non-R/3 program through a gateway-proxy (usually rfcexec.exe). BAPIs are a subset of the RFC-enabled function modules, especially designed as Application Programming Interface (API) to the SAP business object, or in other words: are function modules officially released by SAP to be called from external programs.

IDocs are text encoded documents with a rigid structure that are used to exchange data between R/3 and a foreign system. Instead of calling a program in the destination system directly, the data is first packed into an IDoc and then sent to the receiving system, where it is analyzed and properly processed. Therefore an IDoc data exchange is always an
asynchronous process. The significant difference between simple RFC-calls and IDoc data exchange is the fact, that every action performed on IDocs are protocolled by R/3 and IDocs can be reprocessed if an error occurred in one of the message steps.

While IDocs have to be understood as a data exchange protocol, EDI and ALE are typical use cases for IDocs. R/3 uses IDocs for both EDI and ALE to deliver data to the receiving system. ALE is basically the scheduling mechanism that defines when and between which partners and what kind of data will be exchanged on a regular or event triggered basis. Such a set-up is called an ALE-scenario.

The philosophical difference between EDI and ALE can be pinned as follows: If we send data to an external partner, we generally speak of EDI, while ALE is a mechanism to reliable replicate data between trusting systems to store a redundant copy of the IDoc data. The difference is made clear, when we think of a purchase order that is sent as an IDoc. If we send the purchase order to a supplier then the supplier will store the purchase order as a sales order. However, if we send the purchase order via ALE to another R/3 system, then the receiving system will store the purchase order also as a purchase order.

Difference Between EDI and IDOC

3 Replies

EDI is nothing but Electronic data interchange. SAP will support EDI through Intermediate documents (IDOCS).EDI (Electronic Document interchange) – EDI is the electronic exchange of business documents between the computer systems of business partners, using a standard format over a communication network.

EDI is also called paperless exchange.

Advantages: 
Reduced Data entry errors
Reduced processing time
Availabilty of data in electonic form
Reduced paperwork
Reduced Cost
Reduced inventories and better planning
Standard means of communications
Better business process

EDI has two process
1. Outbound process
2. Inbound process

OP:
1.Application document is created.
2.IDOC is generated
3.IDoc is transferred from SAP to Operating system layer
4.Idoc is converted into EDI standards
5.Edi document is transmitted to the business partner
6.The Edi Subsystem report status to SAP

IP:
1.EDI transmission received
2.EDI document is converted into an IDOC
3.IDOC is transferred to the SAP layer
4.The application document is created
5.The application document can be viewed.
IDOC:
IDOC is a container that can be used to exchange data between any two process.
Each iDoc is assigned a unique number for tracking and future reference.
iDoc Consist of several segments,and segments contain several fields.
iDoc contains the following three type of records…
1.One Control Record.
2.One or many Data Record
3.One or many Status record.

PORT:
Port is used in the outbound process to determine the name of the EDI subsystem program,the directory path where the idoc file will be created at the operating system level,the idoc file names and the rfc desinations.

RFC Destination:
Used to define the characteristics of communication links to a remote system on which a functions needs to be executed.

Partner Profile:
Partner profile specified the various componets used in an outbound process ( Partner number,IDoc type,message type,Port,Process code),the mode in which it communicates with the subsystem(batch or immediate) and the person to be notified in case of errors.

Message Control
Used in pricing,account determination,material determination,and output determination.The message control component enables you to encapsulate business rules with out having to write abap programs.

Process:
Setup RFC destinations SM59
Port Destinations WE21
Partner Profile WE20
Message control NACE
Purchase Order ME21
Check IDOCs WE02,WE05

Explain to me about Idoc?

IDoc (for intermediate document) is a standard data structure for electronic data interchange (EDI) between application programs written for the popular SAP business system or between an SAP application and an external program. IDocs serve as the vehicle for data transfer in SAP’s Application Link Enabling (ALE) system.

IDocs are used for asynchronous transactions:  Each IDoc generated exists as a self-contained text file that can then be transmitted to the requesting workstation without connecting to the central database.

Another SAP mechanism, the Business Application Programming Interface (BAPI) is used for synchronous transactions.
A large enterprise’s networked computing environment is likely to connect many geographically distributed computers to the main database. These computers are likely to use different hardware and/or operating system platforms. An IDoc encapsulates data so that it can be exchanged between different systems without conversion from one format to another.

IDoc types define different categories of data, such as purchase orders or invoices, which may then be broken down into more specific categories called message types. Greater specificity means that an IDoc type is capable of storing only the data required for a particular transaction, which increases efficiency and decreases resource demands.

An IDoc can be generated at any point in a transaction process. For example, during a shipping transaction process, an IDoc may be generated that includes the data fields required to print a shipping manifest. After a user performs an SAP transaction, one or more IDocs are generated in the sending database and passed to the ALE communication layer. The communication
layer performs a Remote Function Call (RFC), using the port definition and RFC destination specified by the customer model.

The IDoc is transmitted to the receiver, which may be an R/3, R/2, or some external system.

IDOC

7 Replies

What is IDOC

• IDOC = Intermediate Document

• IDOC is simply a data container used to exchange information between any two processes that can understand the syntax and semantics of the data.

• When we execute an outbound ALE or EDI Process, an IDOC is created

• In an inbound ALE or EDI process, an IDOC serves as input to create an application document.

• In the SAP System, IDOCs are stored in database.

• Every IDOC has an unique number(within a client).

• IDOCs are independent of the sending and receiving systems.(SAP-to-SAP as well as Non-SAP)

• IDOCs are based on EDI standards, ANSI ASC X12 and EDIFACT. In case of any conflict in data size, it adopts one with greater length

• IDOCs are independent of the direction of data exchange e.g. ORDERS01: Purchasing module : Inbound and Outbound

• IDOCs can be viewed in a text editor. Data is stored in character format instead of binary format.

IDOC Components

Basic IDOC Type (we30)

• Basic IDOC Type defines the structure and format of the business document that is to be exchanged.

• IDOC Type has a

– specific name

– list of permitted segments

– hierarchy of segments

– mandatory/optional segments

– minimum/maximum range of each segment.

Segments

• Segment defines the format and structure of a data record. Segments are reusable components.

• For each segment SAP creates

– Segment Type (version independent)

– Segment Definition (version dependent)

– Segment Documentation

• The last 3 characters is the version of the segment

• Definitions keep changing as per the version but the segment type remains the same

IDOC Run-Time Components

• An IDOC is an instance of an IDOC Type

• At run time the following events occur

– A unique IDOC no. is allocated by SAP

– One control record is attached to the IDOC

– Segments translate into data records

– Status records are attached

– Syntax rules are checked.

• Each IDOC has 3 parts

– Control Record

– Data Record

– Status Record

• We02 or We05

Control Record

• All control record data is stored in EDIDC table. The key to this table is the IDOC Number

• It contains information like IDOC number, sender, recipient information, channel it is using, which port it is using etc.

Data Record

• Data record contains application data like employee header info, weekly details, client details etc

• All data record data is stored in EDI_DD40 table and EDI_DD

Status Record

• Status record are attached to an IDOC at every milestone or when it encounter errors.

• All status record data is stored in EDID8 table.

Where and How IDOC is created

Where and How an IDOC is created?

• Lets take an example to understand this:

• Whenever a Purchase Order (PO) is created we want to send the IDOC to a vendor.

• The PO is sent in the form of an IDOC to the vendor (partner). That partner has to be EDI enabled in that system.. SAP should realize that it could send doc to this vendor electronically. (Creating a vendor is not sufficient). Partner Profile should be EDI enabled i.e. A partner profile should exist in the sap system.

• Quotation, RFQ, PO, SO, Invoice, delivery challan etc are some of the commonly exchanged documents through IDOCs

• We create only one profile for both inbound and outbound IDOCs.

• Partner profile should contain message type……to be able to exchange the IDOC.

• We define partner type, partner function and message type (it distinguish if an IDOC is being sent to same person in same function for different reason e.g. SO)

Process Code

Creating Outbound Process Code (WE41)

• What is Process Code?

Process of filling the IDOC with application data is done by Function Module. But, function module is not assigned to a Partner. It is encapsulated by a Process Code and this Process Code is assigned to a Partner in Partner Profile.

• Assigning Function Module to Process Code

– Go to Transaction WE41.

– Switch to “Change” Mode and click “New Entries”.

– Enter Process Code Name and assign the Function Module created.

Partner Profile

Creating Partner Profile (WE20)

• What is Partner Profile?

We must maintain the business partners with whom we communicate via IDocs, in Partner Profiles.

• Steps to create Partner Profile

– Goto Transaction WE20.

– Click on Create Button.

– Enter the Number of Vendor Created in Partner No. and ‘LI’ in Partner Type fields.

– Save the Data.

– For Outbound Partner Profile we have to create Outbound Parameters

– Specify Partner Function, Message type created, Port (create a port in WE21),Basic Type and Output Mode.

– Goto “Message Control” Tab and link the Message Type and Process Code created.

– Save.

Change Application Data to be transmitted

• Change Purchase Order Created using transaction ME22n for the Vendor to which partner profile has been created.

• Go to “Messages” , add the new “Message Type” to the list and Save the Purchase Order.

• An IDOC will be created for the purchase order and will be dispatched to PORT mentioned.

Check the status of IDOC (WE02)

• The IDOC status can be checked using transaction WE02

• If the status is ’03’, it implies that IDOC is passed to Port.

Summary: IDOC Workflow

The sequence:

1. Checks whether Partner profile exists or not

2. Whether that PP has a outbound parameter

3. Whether NEU message type is there or not (message control)

4. Checks the process code (gives the name of Function module)

5. Checks immediate transfer or batch transfer

6. Based on that it checks the receiver port

7. Then it will trigger the RFC destination

8. Then it triggers the event on subsystem/customer system

9. Transfer the IDOC to a port and transfer the Idoc in terms of file and it triggers the customer system

10. Customer knows from where it should pick up the file ….it picks up the file.

Extending an Existing IDOC Type

• Used in cases where some additional information is required in addition to that supplied by the Standard IDOC Type.

• In Transaction WE30 we create the IDOC as an Extension and specify the basic type for which it is an extension.

• We add the segments needed as children to existing ones.

• None of the Reference Segments can be deleted or changed.

Extension Child Segs

Basic Type (ORDERS01)

F1

F2

F3

F4

F5

Cannot be modified

IDOC Views

• An IDOC type can be used for more than one message type, which results in IDOCs containing more fields than required for a particular message type.

• IDOC views are used to improve performance in generating IDOCs to ensure only the relevant segments are filled with data.

• IDOC Views are important only for Outbound Processing.

IDOC Type

F1

F2

F3

F4

F5

Processing Logic

• The processing logic associated with the IDOC is the function module that is written to handle the inbound/outbound IDOC.

• Its written just like any function module but has to follow a standard interface (i.e. Import, Export, Changing & Tables) parameters and it is should be RFC enabled.

• In this function module we are effectively building up a table of type EDID4 (IDOC Data table) and change the control record.