What SAP may have forgotten to integrate
One major implicit agreement in the EDI business is that +”No News is Good News.”+. A customer ordering via EDI assumes that its purchase orders will be fulfilled completely as long as the customer is not informed otherwise by the supplier. A supplier assumes that its EDI invoices have been accepted and will be paid unless they are rejected by the customer. Given the fact that we do not use a full-blown EDI Adapter like Seeburger at Lindt (CH) but just an “Add-On” (for more details contact http://www.resource.ch (http://www.resource.ch) about their *rEDI Adapter*) which does the conversion XML to Flat and vice versa we do not (yet) have and End-to-End Monitoring of our EDI processes. How do we cope with this situation in case of EDI incidents? *The Challenge* If EDI invoices are rejected by the customer we are informed by their EDI support team. Many customers tells us not only that a transmission failed but also which invoice (i.e. the invoice no.) was affected. However, some customer just let us know that +”Transmission (LNDSMUMU004392) failed”+ (see below). The cryptic number LNDSMUMU004392 is the +sequential +*transmission number* (or ICN = *interchange control number*) as defined in the customer’s EDIFACT EDI guidelines (LNDS = Supplier prefix; MUMU = Customer prefix; 004392 = sequential number). In case of TRADACOMS messages (UK-specific standard) the FIL segment is used for the numbering (field FLGN = File Generation Number). The EDI error described in the e-mail is that we sent a wrong invoicee party (NAD+IV) due to a wrong assignment of partner roles in the customer master data. Now how do we find out the affected invoice by just knowing its transmission number, sent date and value? Using standard means (e.g. *WE02*) may become tedious if many invoices were sent to this customer at the same day (which actually is the case for this particular customer). Another option would be to check table *VBRK *for the specific net value. Or searching through the XML messages on SAP-XI (*SXMB_MONI*) in the possible period of time. However, none of these ways is really efficient and all of them are too time-consuming. And what about multiple incidents happen within a short period of time?
*eXtended IDoc Monitoring at Lindt* As an answer to tackle this acute support problem I developed an “eXtended IDoc Monitor” for Lindt UK (our EDI “pacemaker” among the Lindt group). The three main features of this extended monitor are: 1. Display the *business object* (e.g. invoice, delivery, etc.) on the IDoc list 2. Display the SAP-XI message ID (*GUID*) on the IDoc list 3. Display the *ICN *(or transmission number) of outbound IDocs on the IDoc list
In the standard IDoc monitor (WE02) you need 3-4 mouse-clicks in order to navigate from the IDoc on the list to the business document. Since the link between IDoc and business document can be retrieved by +standard +means I just removed this unnecessary navigation and brought the business document to the surface (i.e. on the IDoc list).
On SAP-XI we can see the link between IDocs and XI-message ID (*GUID*) using transaction *IDX5*. Provided a suitable RFC connection is available we can jump from SAP-XI into the business system and display the IDoc. Thus, we have again +standard+ means to retrieve this link (IDoc – GUID). | | In summary: All I have done is *to grab the Lego bricks that SAP has built already and merged what obviously belongs together.* The result is shown below: As soon as the selection is started the message displayed in the status bar shows the additional selection of business object data. The business document related columns are coloured in dark green. As soon as we restrict the Idoc list to a particular message type (e.g. *INVOIC*) additional data specific for this business document type can be displayed (e.g. net value and payer in case of invoices). By simply sorting the IDoc list by column ICN (= Interchange Control number) we have found out that the rejected transmission LNDSMUMU004392 belonged to invoice 90081069. By right-clicking on the affected IDoc we can quickly call the appropriate function (e.g. “Maintain Store (code) mapping”) in order to solve this incident. Needless to say that a double-click on either the business document number or the GUID forwards the user to the corresponding display +business transaction+ (e.g VF03 for invoices) or the list “XML Messages in Adapter (IDX5) on SAP-XI, respectively. *Business Activity Monitoring* You may have noticed that the selection-screen of the eXtended IDoc Monitor (ZWE02) has an additional tabstrip *”Bus.Object”* as compared to the standard.Wouldn’t it be nice to follow the business activities of a document based on the sent and received IDocs? The selection for a specific outbound delivery gives the following result: * The warehouse sent the picking confirmation (WHSCON) back. * The inbound WHSCON triggererd an outbound SHPORD as ASN (= Advance Shipping Notice) to the customer (by means of a VOFM condition). * Finally the warehouse sent a proof of delivery (STPPOD) which allows billing of the delivery. Or in other words: We can see the all business activities of the outbound delivery in the eXtended IDoc Monitoring.