EDI SAP Inbox and Monitoring Errors

Previously we have discussed regarding EDI Inbound process testing. Now we are going to deal with Errors monitoring via EDI SAP inbox.

Workflow is useful for detecting errors that are infrequent, unpredictable in timing, and meant for a specific group of people.

For example, assume that you are in charge of handling errors with purchase orders going out to your vendors via EDI. Several purchasing clerks can create purchase orders in the system. You could try to stay up−to−date with the problems by displaying a list of purchase orders created in the system every hour, looking for purchase orders that go via EDI and then checking the status of each output to make sure that the EDI part is correct.

You could devote your entire day to monitoring the system manually and not find a problem, or you could be busy doing something else and end up being accountable for an unresolved error.

The transaction codes are

Transaction (prior to version 4.6): SO01
Transaction (from version 4.6): SBWP
Path: From SAP Easy Access menu, click on Business Workplace icon

The SAP Inbox is an interface to view and process work items and SAP office documents . It is similar to the inbox of any e−mail system and contains separate folders for the office documents and work items. The office documents are e−mail documents, and the work items are workflow items.

The number next to each folder indicates the number of items in the folder. Workflow items are accessible in any of four folders within the overall Workflow folder. Each folder displays the work items in a different order according to task, content, content type, or sort key.

The work item highlighted in the worklist is displayed in the preview window below the worklist. You can customize this preview window through the use of a user exit.

Understanding Work Items

A work item represents an instance of a task that needs to be executed. For example, a workflow task (Orders_Error) handles application errors in the orders IDoc. When a sales order IDoc has application errors in posting, a work item representing this task is instantiated. A work item has brief text describing its purpose .

A work item is executed from the Inbox to carry out the task, and can have more than one status governing the operations allowed on it.

As part of the ALE/EDI interface, items that can appear in the SAP Inbox. Because work items are intelligently routed to the person responsible for them, the work item's type determines who is notified. You can expect to see work items for the following items.

1. Errors in the outbound ALE/EDI interface.
2. Errors in the inbound ALE/EDI interface.
3. Syntax errors in an IDoc for the outbound process.
4. Syntax errors in an IDoc for the inbound process.
5. Application errors in posting an IDoc on the inbound process.
6. Errors reported by the EDI subsystem.
7. Technical errors in the EDI interface with reading and deleting IDoc files for the inbound process.
8. A predefined threshold state exceeded by the number of IDocs. For example, someone is notified
9. when at least 10 sales order IDocs are not posted because of application errors.
10. Inbound EDI processes routed via workflow. For example, someone needs to review an order change IDoc before it is posted.

Successful posting of an application document. For example, you want to view invoices whenever
they are successfully posted in the system via EDI.

The previous post of the blog deals with EDI Testing outbound process
and you can go through entire EDI Course here.

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.

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

Related Posts :

EDI Process components
Business Processing using EDI
Introduction to EDI
EDI with message control scenario with purchase order and part two

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.

1. Requests for quotes
2. Purchase orders
3. Purchase order changes
4. Purchase order acknowledgments
5. Invoices

EDI Messages

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

Related Posts :

Business Processing using EDI
Introduction to EDI
EDI converter for SAP and EDI standards

SAP ABAP BAPI 1
SAP ABAP BAPI 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.

1. The customer requests price catalogs.
2. The customer requests quotes.
3. The customer places blanket purchase orders.
4. The customer authorizes delivery against its blanket orders.
5. The customer places an order.
6. The customer expects an order acknowledgment.
7. The customer expects a delivery schedule.
8. The customer wants to know the status of the order.
9. The customer might cancel an order.
10. The customer might change an order.
11. The customer expects an order.
12. The customer requires a shipment notification.
13. The customer receives goods.
14. The customer notifies the supplier that goods have been received.
15. The customer wants authorization to return goods.
16. The customer wants to return goods damaged in transit.
17. The customer is an international customer.
18. 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.

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

Related Posts :

Introduction to EDI
EDI converter for SAP and EDI standards


IMPORTANCE OF BADI IN SAP ABAP

COMPARISON OF ENHANCEMENTS IN ABAP

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 :

1. A customer who wants to purchase an item creates a purchase order and then faxes or mails it to the vendor.
2. The vendor receives the purchase order and manually keys in a sales order.
3. The vendor's system generates a confirmation date that is sent back to the customer via fax or mail.
4. The vendor then ships the goods via a carrier. The carrier delivers the products to the customer.
5. When the goods are shipped, the vendor invoices the customer.
6. The customer makes the payment by check, and the vendor deposits the check in the bank.
7. 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

1. Is highly inefficient and laborious ·
2. Cannot be tracked easily ·
3. Gives no visibility into the process ·
4. Has a very long lead time ·
5. 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

EDI Converter for SAP

R/3 does not provide any tool to convert IDocs into international EDI format like ANSI X.12, EDIFACT or XML. This conversion needs to be done by an external add-on product which is Provided by a variety of companies who specialize in general EDI and e-commerce solutions.

R/3 does not provide conversion to EDI standard formats like X.12, EDIFACT or XML.Converters exist on UNIX and PC platforms.

Many converters are simple PC programs.

R/3 certification only guarantees that the converter complies to RFC technology and works fine with standard IDoc scenarios.

Real life situations require a flexible and easily adaptable converter program.

SAP R/3 has foregone implementing routines to convert IDocs into international EDI standard formats and forwards those requests to the numerous third party companies who specialize in commercial EDI and e-commerce solutions..

Nearly every standard organization defined an own EDI standard for their members. So there is X.12 by ANSI for the US, EDIFACT/UN adopted by the United Nations Organization UNO or XML as proposed by the internet research gurus of W3C.

But there is still more about it. All major industry companies define an additional file format standard for their EDI partners. Even if they adhere officially to one of the big standards, they yet issue interpretation guidelines with their own modifications according to their needs.

If a company does not play in the premier league of industry or banking companies, it will have to comply with the demands of the large corporations.

As this leads to the insight that there are as many different EDI formats as companies, it is evident that an EDI converter needs to have at least one major feature, which is flexibility in the sense of openness towards modification of the conversion rules.

There are hundreds of converter solutions on the market not counting the individual in-house programming solutions done by many companies.

EDI is a market on its own. Numerous companies specialize in providing EDI solutions and services. The majority of those companies also provide converters. Many of the converters are certified by SAP to be used with R/3. However, this does not tell anything about the usability or suitability to task of the products.

RELATED POST

IDOC COMPLETE


SAP definition,full form,over veiw and introduction
What is SAP Full form and its definition part one

EDI and International Standards for SAP

Electronic Data Interchange (EDI) as a tool for paperless inter-company communication and basic instrument for e-commerce is heavily regulated by several international standards.Unfortunately, it is true for many areas in the industry that an international standard does not mean that everybody uses the same conventions.

Too many organizations play their own game and define standards more or less compatible with those set by competing organizations.The main contenders are the national standards organizations and private companies versus the big international organizations ISO and ANSI.The private companies being backed up by their country organizations usually fight for maintaining conventions, which have been often established for many years with satisfaction.

The American National Standards Organisation ANSI and the international partner International Standards Organization ISO will usually fight for a solid open standard to cover the requirements of everybody.This generally leads to a more or less foul trade-off between pragmatism and completeness. Tragically the big organizations put themselves in question. Their  publications are not free of charge. The standards are publications which cost a lot of money. So they mostly remain unread.

Nowadays computing standards have mostly been published and established by private organizations who made their knowledge accessible free of charge to everybody. Examples are manifold like PostScript by Adobe, HTML and JavaScript by Netscape, Java by SUN, SCSI by APPLE, ZIP by PK Systems or MP3 by – who cares, XML by W3C and EDIFACT by the United Nations Organization UNESCO.

The well-known standards EDIFACT, X.12 and XML have similar characteristics and are designed like a document description language. Other standards and R/3 IDocs are based on segmented files.

ANSI X.12 is the US standard for EDI and e-commerce. Why is it still the standard? There are chances that X.12 will be soon replaced by the more flexible XML, especially with the upcoming boost of e-commerce. ANSI X.12 is a document description language.

An ANSI X.12 message is made up of segments with fields. The segments have a segment identifier and the fields are separated by a special separator character, e.g. an asterisk.

BEG*00*NE*123456789**991125**AC~

EDIFACT was originally a European standard. It became popular when chosen by the UNO for their EDI transactions. EDIFACT is a document description language. EDIFACT is very similar to ANSI X.12 and differs merely in syntactical details and the meaning of tags.

XML and the internet page description language HTML are both subsets derived from the super standard SGML...The patent and trademark holder of XML describes the advantages of XML very precisely as follows.

1. XML is a method for putting structured data in a text file.

2. XML looks a bit like HTML but isn't HTML.

3. XML is text, but isn't meant to be read.

4. XML is verbose, but that is not a problem.

5. XML is license-free and platform-independent.

And XML is fully integrated in the world wide web. It can be said briefly: XML sends the form just as the customer entered the data.

XML

This is an excerpt of an XML EDI message. The difference from all other EDI standards is that the message information is tagged in a way that it can be displayed in human readable form by a browser.XML differs from the other standards. It is a document markup language like its sister and subset HTML.XML defines additional tags to HTML, which are specially designed to mark up formatted data information.The advantage is that the XML message has the same information as an EDIFACT or X.12 message. In addition, it can be displayed in an XML capable web browser .

RELATED POST

EDI CONTINUIED

What is SAP and Why do we are in need of It

What is SAP Full form and its definition part one