December 2008

What is Idoc-overview

An IDoc is a container that can be used to exchange data between any two processes. The document represented in an IDoc is independent of the complex structure used in SAP to store application data. This feature enables SAP to rearrange its internal structure without affecting the existing interfaces.

An IDoc represents an IDoc type and IDoc data, depending on the context in which the word IDoc is used. An IDoc type defines the structure and format of the data being exchanged. For example, the IDoc type INVOIC01 defines the format of an invoice document. IDoc data can be seen as an instance of an IDoc type.

IDoc Types

IDocs types are based on EDI standards (ANSI X12 and EDIFACT). They are closer to the EDIFACT standards than to ANSI X12. The size and format of data elements in an IDoc type are derived from these standards wherever applicable. The IDoc format is compatible with most EDI standards.

An IDoc structure consists of several segments, and segments consist of several data fields. The IDoc structure defines the syntax of the data by specifying a list of permitted segments, the arrangement of the segments, and optional versus mandatory segments. Segments define a set of fields and their formats.

An IDoc is an instance of an IDoc type. Each IDoc is assigned a unique number for tracking and future reference. An IDoc serves as a focal object for tracking the state of the process that generated it. An IDoc consists of the following three types of records.

Parts of Idoc

One control record
One or many data records
One or many status records Control record. There is only one control record per IDoc. The control record contains all the control information about an IDoc, including the IDoc number, sender and receiver information, and other control information such as the message type it represents and IDoc type. The structure of the control record is the same for all IDocs and is defined by SAP. The field values, of course, can be different.
Data record. An IDoc can contain multiple data records, as defined by the IDoc structure. Segments translate into data records. Data records store application data such as purchase order header information, purchase order details lines, and other relevant information.
Status record. Multiple status records are usually attached to an IDoc. Status records are attached to an IDoc throughout the process as the IDoc achieves different milestones. A status code, date, and time are assigned at every milestone.

In the outbound process, after the IDoc is passed from SAP to the subsystem, the status records are generated by the subsystem and passed back to SAP. For the inbound process, SAP generates the status records because after an IDoc is generated, it stays in the system. Status records help you determine the status of the process and whether an IDoc is in error.

Multiple Messages per IDoc Type

A message represents a specific type of document that is transmitted between two partners. Orders, order responses, order acknowledgments, invoices, and shipment notices are examples of messages. An IDoc type in SAP can be used to represent several messages or business documents. Of course, the messages must be logically related.

For example, in the figure , an IDoc type represents all possible information about an employee. This IDoc type is being used to send two separate messages to two separate applications. One message is the Employee Salary Information; the other is the Employee Security Information. The difference between the two messages is the set of segments used.

SAP uses a single IDoc type for several logically related messages. For example, the Orders IDoc type (ORDERS02) is used for several messages, such as Order (ORDERS), Order Response (ORDRSP), and Order Change (ORDCHG).

See complete course about ALE IDOC'S HERE.

Related Posts about EDI:

EDI outbound process
EDI Process components AND part two Business Processing using EDI

What is inbound EDI Process

The inbound process simply reverses the steps of the outbound process. The inbound process receives an EDI document (such as a purchase order response, sales order, or payment information) from a business partner (such as a vendor, a customer, or a bank) and creates SAP documents from it. Figure at the bottom of the post shows the inbound process at a very high level.

The inbound process consists of five steps.

1.The EDI transmission is received : EDI documents are received from a business partner via the VAN. These documents are in one of the EDI standard formats. The documents are deposited in a common repository for the subsystem. This part of the process is not part of the SAP EDI architecture.

2 .The EDI document is converted into an IDoc:The EDI−specific headers and trailers are stripped off, and the document is converted into an IDoc format suitable for SAP applications. The process is carried out at the EDI subsystem level.

3. The IDoc is transferred to the SAP layer : The IDoc created in Step 2 is stored in a text file at the operating system layer. The subsystem starts an inbound program in the SAP layer. This program reads the IDoc file and creates an IDoc in the SAP repository for further processing.

4. The application document is created : The IDoc received from the subsystem is passed to a posting program. This program creates an application document such as a sales order, purchase order acknowledgment, invoice, or shipment notice.

5. The application document can be viewed: The application document created via EDI is the same as any document created manually in the system: The document can be viewed using standard application transactions. For example, if an incoming sales order was created via EDI, you could view the sales order document via transaction VA03.

Exception Handling via Work flow :

Exceptions can occur at any point during either the outbound or inbound process. They are caused by technical problems (such as network connectivity failures or file system problems), data−related problems (such as data that is formatted incorrectly or missing), or a combination of both.

Workflow provides a very sophisticated method for managing the exception−handling process. Based on the type of error, workflow can be configured to identify the persons responsible for handling the problem, notify them in a timely manner, and provide a mechanism for making the necessary correction. After the problem is fixed, the process can be restarted from the point of failure.(27.2)

EDI Outbound Process

Here i am going to present the overview of EDI process in SAP. The SAP EDI process comprises two distinct processes. The outbound process sends documents from the SAP system to a business partner (vendor, customer, bank). Figure below shows the outbound process at a very high level. The outbound process consists of six steps.

1.The application document is created: The first step in the outbound process involves creating an application document such as a purchase order or sales order and saving it in the database tables. This step is no different from the way in which these documents are normally created. It is the following steps that have relevance to EDI. The document is created and leaves some hooks for the EDI process to begin.

2.The IDoc is generated : The application document just created is now formatted to an IDoc format. At this point you can think of IDoc as yet another format in which the application document has been represented. For example, think of how a date can be stored in different formatsimagine a date as a document with three components: day, month, and year.

In one case, you represent it as MM/DD/YYYY, a standard American way of representing a date. To make it meaningful for a German partner, you have to represent it as DD.MM.YY. IDocs follow a similar concept of representing information in different ways. The data in the application document format is suitable for the application modules, screens, and internal programs.

3.The IDoc is transferred from SAP to the operating system layer : The IDoc created in Step 2 resides in the SAP database repository. This IDoc document must be passed down to the operating system layer for processing by the EDI subsystem. In Step 3, the IDoc is transferred to the operating system as a text file. The document is still in an IDoc format. The only difference is the medium of storage.

4.The IDoc is converted to EDI standards : The IDoc format is an SAP proprietary format. For EDI purposes, the document in IDoc format has to be converted into an EDI standard format. Third−party software called a translator carries out the transformation process and reports status back to the SAP system.

SAP refers to these translators as EDI subsystems, and has certified several subsystems for connectivity to SAP. SAP takes no responsibility for translation. Thus, from SAP's perspective, after the IDoc is delivered to the subsystem, SAP does not have control over the process, but it maintains the status reported by the EDI subsystem.

5.The EDI document is transmitted to the business partner : After the document is converted to an EDI standard format, it is transmitted to a trading partner based on the partner's EDI settings. This step is not part of the SAP EDI architecture, but is mentioned here to describe the complete process from a business perspective.

6.The EDI subsystem reports status to SAP : When an IDoc is under the control of the EDI subsystem, the subsystem can optionally report the state of processing at various milestones back to the SAP system. This mechanism is always recommended because it provides complete visibility of the process from within SAP, and the user does not have to be involved with the intricacies of the EDI subsystem.(26.2)

Related Posts :

EDI Process components AND part two
Business Processing using EDI Introduction to EDI
EDI converter for SAP EDI standards

EDI Architecture

SAP provides the application logic, application data, and format for the data contents for EDI. Third−party software vendors supply the other pieces. EDI−enabled applications in SAP are capable of generating IDoc (Intermediate Document) data from an SAP document or reading IDoc data and creating application documents.

The application must understand the syntax and semantics of the data in the IDoc format. In the case of outbound processes, a separate selection program reads application data and creates an IDoc, as shown in Figure below. Similarly, for inbound processes, a posting program reads IDoc data to create an application document.

In the standard SAP system, several EDI−enabled applications in various modules are capable of generating and processing IDoc data, but all EDI documents are not supported. It is very likely that SAP supports the business process but not the creation or processing of IDocs. However, with every release of SAP, the list of supported IDocs grows considerably.

Note An application that is not EDIenabled can be enabled by developing the selection and posting programs and IDoc structures. SAP provides a comprehensive set of tools for developing IDocs and programs.

Related Posts :

EDI Process components AND part two Business Processing using EDI Introduction to EDI EDI converter for SAP EDI standards
EDI Tools for SAP
EDI performance factors

EDI Process Components part two

This post is in continuation with EDI Process components part one .
Transaction : A transaction is the electronic equivalent of a business document. A transaction is usually divided into three areas: header area, detail area, and summary area. The header area consists of segments that apply to the entire document, and is usually mandatory.

For example, in a purchase order, vendor number and vendor address are part of the header segments. The detail area contains document details. The items being ordered and their quantities are considered detail segments. The summary area consists of data that summarizes the entire document, and the total amount and taxes are part of the summary segments.

Segment : A segment is equivalent to a record in a document. A data segment has the following attributes: a unique ID, a name, a flag indicating whether it is optional or mandatory, and a number of occurrences. A group of segments can be combined to form a loop, which can also be mandatory or optional, and can be nested as well.
Segments are contained in a segment directory .

A segment consists of a sequence of logically related data elements. Data elements are separated by a data element separator and can be mandatory or optional. Some data elements are conditional, or mandatory, in certain situations.

Data Elements : Data elements are the smallest unit of information in a transaction and are defined in the data element dictionary (X12.3). A data element is identified by a data element reference number, a data type, and a minimum and maximum length.

UN/EDIFACT (United Nations EDI for Administration, Commerce, and Transport) was formed in 1985, using the ANSIX12 and UNTDI (United Nations Trade Data Interchange) as the base standards. The purpose of the standard was to develop an international standard to meet the needs of a global economy.

Most companies are moving toward adopting EDIFACT because of its international recognition. EDIFACT is quite similar to ANSI X12, with some minor differences in terminology and layout.

EDIFACT calls business documents messages and represents them by a name such as ORDERS for a purchase order, whereas ANSI X12 calls them transactions and represents them by a number such as 850 for a purchase order.

EDIFACT uses different terminology for fields. Conditional fields of EDIFACT are the same as optional fields in ANSI X12.

EDIFACT uses the same segment in multiple places, whereas ANSI has a specific use for each segment.

EDIFACT has additional segments that apply to international trade.

Application Programs

Application programs are responsible for generating and processing data in business documents. These application programs are part of the application suite commonly referred to as ERP (Enterprise Resource Planning). ERP systems meet a broad range of a company's business needsSAP R/3 is an example. Most ERP vendors recognize the business needs for EDI and thus enable their software to support EDI processes. An ERP system must do the following:

Support standard EDI transactions in the business area of interest. For example, if the focus of a company is shipping and distribution, the software must support basic shipping transactions.

Make the data necessary for EDI messages readily available.
Document the EDI processes and functionality.
Be flexible enough to incorporate business requirements within the existing process.
Provide support for enhancing existing transactions.
Contain easily configurable and manageable systems.
Contain a sufficient number of control points to meet business needs.
Exhibit a disciplined approach for controlling the flow of documents within the organization, from error handling to the approval process.
Be integrated with EDI translation software vendors.
Provide system limits and performance measures if a company expects a large volume of EDI.
transactions.(22)

EDI Process Components

An EDI process is a transfer of one or a sequence of electronic messages.It involves senders, receivers, language, content, and a medium. In EDI, the senders and receivers are called trading partners, and the X12 or EDIFACT standards supply a common language for formatting the information content of common messages.

Software tools called translators enable trading partners to converse in a standard language, and application programs (such as SAP R/3), coupled with networking facilities such as the Internet or a commercial VAN (Value−Added Network), supply the messaging medium.

Trading Partners Parties involved in a business transaction are called trading partners. The trading partners can be any combination of organizations or business types. For example, customers and vendors are trading partners.

Business Documents A business document is a legal document that defines the transaction conducted between trading partners. The legal boundaries for these transactions are defined by trade agencies, trading partners, and the ISO (International Standards Organization). The trading partners are bound by the terms and conditions of these documents. Numerous business documents are in existence today. Examples of some typical business documents follow.

Requests for quotes
Purchase orders
Purchase order changes
Purchase order acknowledgments
Invoices

EDI Messages

The formation of common standards has many advantages.
Standardization allows representation that can be easily processed by a computer system.
Standardization allows companies to exchange information that is independent from the application software.
Third−party applications can provide EDI translation and thus relieve the application of having to keep up with evolving standards.(19.2)

Business Process using EDI

In the process of buying and selling goods, partners exchange business documents at various times. These documents record the process of creating and executing a contract for sales of goods or services.

While many of these documents help to meet legal requirements, they are also all significant factors in the efficiency of processing a particular sales transaction. Well−run businesses pay a lot of attention to optimizing these business processes, and EDI frequently plays a major role in efforts to improve speed and efficiency.

Many modern business process designs are feasible only because of the existence of EDI technology.

Documents Exchanged with Customers :

Between a customer and a supplier, it is the customer who typically drives the EDI requirements. The following are key business documents exchanged between a customer and supplier.

The customer requests price catalogs.
The customer requests quotes.
The customer places blanket purchase orders.
The customer authorizes delivery against its blanket orders.
The customer places an order.
The customer expects an order acknowledgment.
The customer expects a delivery schedule.
The customer wants to know the status of the order.
The customer might cancel an order.
The customer might change an order.
The customer expects an order.
The customer requires a shipment notification.
The customer receives goods.
The customer notifies the supplier that goods have been received.
The customer wants authorization to return goods.
The customer wants to return goods damaged in transit.
The customer is an international customer.
The customer receives an invoice.

Documents Exchanged with Carriers :

A carrier is a party who undertakes the transportation of goods. The following documents are exchanged during the transportation process.

The shipper requests a carrier pickup.
The carrier responds with a pickup date.
The carrier prints a bill of lading.
The carrier informs the receiving party of the shipment.
The receiver tells the carrier where to unload the goods.
The shipper requests tracking for a particular shipment.
The carrier informs the shipper of the status of the shipment.
The carrier bills the shipper through an invoice.
The carrier receives payment.(17.2)

EDI introduction

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.

Why do we need EDI ?

Business scenario :

A customer who wants to purchase an item creates a purchase order and then faxes or mails it to the vendor.
The vendor receives the purchase order and manually keys in a sales order.
The vendor's system generates a confirmation date that is sent back to the customer via fax or mail.
The vendor then ships the goods via a carrier. The carrier delivers the products to the customer.
When the goods are shipped, the vendor invoices the customer.
The customer makes the payment by check, and the vendor deposits the check in the bank.
Finally, funds are transferred from the customer's account to the vendor's account.

This simple scenario requires the exchange of various documents between several business partners at different times.

A business process is a series of actions or functions that bring about a business result, and as such there are some inherent problems with this scenario. They are

Is highly inefficient and laborious ·
Cannot be tracked easily ·
Gives no visibility into the process ·
Has a very long lead time ·
Includes redundant data entry at various points.

The electronic exchange of business documents in a standard format gave birth to what is now known as EDI.

Benefits of the EDI Process :

1.Reduced data entry errors: EDI does not involve data entry at multiple points. In the traditional process, a sender creates a purchase order on the system, prints the order, and then faxes or mails it to a trading partner. The receiver then rekeys the same information on his or her computer. The process is prone to data entry errors. This procedure is repeated when invoicing takes place. With EDI, data goes directly from one computer to another without involving a human being.

2· Reduced processing cycle time : The biggest advantage is the reduced processing time of the complete cycle. As soon as orders are entered into the system, they can be processed on the receiving side in seconds. There is a considerable savings in the processing time of document transfer.

3. Availability of data in electronic form : Data from EDI is in electronic form, which makes it easy to share across the organization.

4· Reduced paperwork : The entire EDI process can be handled without using a single piece of paper.

5· Reduced cost : Time is money. Any savings in time is directly linked to savings in money. The initial cost of an EDI setup is certainly higher compared to the paper process, but over a long period it is very cost−effective.

6·Reduced inventories and better planning : Companies do not have to keep a safety stock for the time taken with order processing. Changes to planning schedules can be communicated instantaneously. MRP (Material Requirements Planning) can take into account a shipment in transit as soon as an Advance ship notice (EDI 856) transaction is received.

7·Standard means of communication : Because EDI enforces standards on the contents of data,uniform naming standards and field sizes have emerged. Such consistency leads to clearer communication and less ambiguity.

8·Better business processes : Compared to traditional methods of exchanging business documents, EDI is certainly a better way of communicating with your trading partners. Companies are willing to share information and participate in inter−organizational issues. This environment enhances supply−chain management.

9·Competitive advantage: In many cases, companies that have implemented EDI have an advantage over their competitors, especially when dealing with government agencies or large corporations. (15.1)

Related Posts :

EDI converter for SAP and EDI standards
BADI IMPLEMENTATION PART TWO
IMPLEMENTATION OF SCREEN ENHANCEMENTS USING BADI

Syntax Check for LOAD part two

Previously we have discussed regarding syntax check for LOAD part one . This post is in continuation with that post.

Variant 7

LOAD REPORT prog PART 'SELC' INTO itab.

Effect

Loads the description of the selection variables ( SELECTOPTIONS and PARAMETERS ) into the internal table itab . itab must have the Dictionary structure RSELC .

Variant 8

LOAD REPORT prog PART 'STOR' INTO itab.

Effect

Loads the initial values of the global data into the internal table itab . The line width of itab determines where the line break occurs. Ideally, itab should contain exactly one field of the type X .

Variant 9

LOAD REPORT prog PART 'LITL' INTO itab.

Effect

Loads the literal table into the internal table itab . The line width of itab determines where the line break occurs. Ideally, itab should contain exactly one field of the type X .

Variant 10

LOAD REPORT prog PART 'SYMB' INTO itab.

Effect

Loads the symbol table into the internal table itab . itab must have the Dictionary structure RSYMB .

Variant 11

LOAD REPORT prog PART 'LREF' INTO itab.

Effect

Loads the line reference into the internal table itab . itab must have the Dictionary structure RLREF .

Variant 12

LOAD REPORT prog PART 'SSCR' INTO itab.

Effect

Loads the description of the selection screen into the internal table itab . itab must have the Dictionary structure RSSCR .

Variant 13

LOAD REPORT prog PART 'BASE' INTO itab.

Effect

Loads the segment table into the internal table itab . itab must have the Dictionary structure RBASE .

Variant 14

LOAD REPORT prog PART 'INIT' INTO itab.

Effect

Loads the initial values of the local data into the internal table itab . The line width of itab determines where the line break occurs. Ideally, itab should contain exactly one field of the type X .

Variant 15

LOAD REPORT prog PART 'DATP' INTO itab.

Effect

Loads the data descriptions of the parameters and local field symbols into the internal table itab . itab must have the dictionary structure RDATA .

Variant 16

LOAD REPORT prog PART 'TXID' INTO itab.

Effect

Loads the index of the text elements (assignment of text keys to data control blocks) into the internal table itab . itab must have the dictionary structure RTXID .

Variant 17

LOAD REPORT prog PART 'COMP' INTO itab.

Effect

Loads the description of the components of the (internal) structures used in the program into the internal table itab . itab must have the dictionary structure RDATA .

Runtime errors

· LOAD_REPORT_PART_NOT_FOUND : An invalid identification was specified under part .
· LOAD_REPORT_PROGRAM_NOT_FOUND : The specified program prog does not exist.
· LOAD_REPORT_TABLE_TOO_SHORT : The specified internal table is too narrow.(88).

Related Post

Syntax for Insert data into Table and Insert part two and Leave

FILTER DEPENDENT BADI IMPLEMENTATION PART TWO
SAP ABAP FILTER DEPENDENT BADI IMPLEMENTATION

Syntax Check for Load

Basic form

LOAD REPORT prog PART part INTO itab.

Effect

Loads the specified part of the generated version of the program prog into the internal table itab (for analysis purposes only).

The return code value is set as follows:

SY-SUBRC = 0 The load for the program prog exists and is current.

SY_SUBRC = 4 The load for the program prog does not exist.

SY-SUBRC = 8 The load for the program prog exists, but is not current. In some cases, this SY-SUBRC may mean that the program load has been destroyed. You can resolve this by generating the program. With PART 'LREF' , SY-SUBRC = 8 means that the line reference table is incorrect for the program. With PART 'CONT' , it means that the reference part of the internal table is empty.

itab has been filled only if SY-SUBRC = 0 .

Variant 1

LOAD REPORT prog PART 'HEAD' INTO itab.

Effect

Loads the program header into line 1 of the internal table itab . itab must have the Dictionary structure RHEAD .

Variant 2

LOAD REPORT prog PART 'TRIG' INTO itab.

Effect

Loads the event control blocks into the internal table itab . itab must have the Dictionary structure RTRIG .

Variant 3

LOAD REPORT prog PART 'CONT' INTO itab.

Effect

Loads the processing control blocks into the internal table itab . itab must have the Dictionary structure RCONT .

Variant 4

LOAD REPORT prog PART 'DATA' INTO itab.

Effect

Loads the static data descriptions into the internal table itab . itab must have the Dictionary structure RDATA .To find the data description for a data index i, proceed as follows:

0 <= i < 14 ="="> i+1 Index in data_itab
2^14 <= i < 15 ="="> i+1 - 2^14 Index in
datv_itab
2^15 <= i < 16 ="="> i+1 - 2^15 Parameter index
(2^14 = 16384, 2^15 = 32768)

Variant 5

LOAD REPORT prog PART 'DDNM' INTO itab.

Effect

The names of the dictionary structures used in the program are set in the internal table itab . itab must have the dictionary structure RDDNM .

Variant 6

LOAD REPORT prog PART 'DATV' INTO itab.

Effect

Loads the variable data descriptions into the internal table itab . itab must have the Dictionary structure RDATA .To find the data description for a data index i, proceed as follows:

0 <= i < 14 ="="> i+1 Index in data_itab
2^14 <= i < 15 ="="> i+1 - 2^14 Index in
datv_itab
2^15 <= i < 16 ="="> i+1 - 2^15 Parameter index
(2^14 = 16384, 2^15 = 32768)(87)

Related Post

Syntax for Insert data into Table and Insert part two and Leave
SAP ABAP BADI PART ONE

ABAP BADI PART TWO
ABAP BADI PART THREE

Subscribe to: Posts ( Atom )