BAHAG Online-Shop Integration mit OSTRPT: Teil 1: Bestellprozess

BAHAG online store integration with OSTRPT: Part 1: Order process In addition to the classic order process that has been in use for a long time already, BAHAG AG is asking suppliers to process the orders from the BAHAG online store in a predefined scenario. For all suppliers who are not competent in EDI, BAHAG offers a corresponding online portal. To minimize the manual workload, the entire order process for the orders generated in the online store can also be automatically mapped by classic EDIFACT messages; this process chain, however, requires a few specifics that make considering the process sequence from a holistic point of view necessary. The end customer orders generated in the BAHAG online store are initially processed by internal BAHAG mechanisms before being transferred to the supplier in a particular variant of the EDIFACT ORDERS message. For visualization, the entire sequence can generally be subdivided into three blocks that are to be considered separately and also impose some requirements in each case with respect to the processing mechanism:

• Orders
• Cancelation management
• Returns management

The text below deals with the requirements of the first requirement complex for processing online data generated by the end customer; the additional application areas are considered separately in other blog entries. When analyzing the information provided by BAHAG AG, the process can be subdivided into five subsections for automated processing of online ORDERS.

1. End customer order via online store to BAHAG
2. Order from BAHAG to the supplier via EDIFACT message ORDERS
3. Order confirmation from supplier to BAHAG through EDIFACT message OSTRPT (ORDERS STATUS REPORT)
4. For CEP / parcel service providers: Shipping confirmation from supplier to BAHAG through EDIFACT message OSTRPT (ORDERS STATUS REPORT)
5. For shipping delivery: Notification of the delivery date from supplier to end customer through a telephone call
6. For shipping delivery: Delivery confirmation from supplier to BAHAG through EDIFACT message OSTRPT (ORDERS STATUS REPORT)

This brief view of the entire process shows, on the one hand, that the process may require manual interaction. On the other hand, it is evident that the OSTRPT message (ORDERS STATUS REPORT) carries different meanings according to the position in the entire process, which are characterized by a special status indicated by a qualifier. The three most important and mandatory statuses are:

• 5: Order has been received
• 24: Goods were handed over to the transport service provider
• 21: In case of shipping delivery—delivery has been successfully delivered, customer has confirmed receipt of goods in writing

There are also a number of optional statuses, which primarily map the various variants of the delivery details. From the supplier’s perspective, it is important to know that the inbound orders are usually ORDERS messages, which may concern only some order items, i.e., that an individual order is triggered for each end customer and therefore overall a large number of ORDERS messages is to be expected. Processing of these inbound ORDERS is not a problem in a high-performance EDI system; it should, however, be noted that a corresponding OSTRPT message must also be generated for all inbound ORDERS and sent to BAHAG. To keep the manual workload as low as possible, Softzoll therefore offers a specific module that automatically acknowledges inbound messages from the BAHAG online store with an OSTRPT message. The message content required to do this for the OSTRPT response message does not have to be delivered via the ERP interface, but is automatically populated by the EDI system with the content of the inbound ORDERS by BAHAG and given “status 5” (see above) as successfully entered and shipped. This feature reflects the fact that most ERP systems have no suitable interface for the OSTRPT process as standard and in this way avoid the costs of a dedicated ERP project geared to do this. This feature is enough to cover subsection 5 (see above). To successfully realize subsection 4 (shipping confirmation), however, an extended feature is required. The most important elements for complying with the BAHAG specifications are semantic in nature; for this reason, the “parcel service” and “dispatch number” must be delivered to the EDI system. Because in most cases, this is dynamic data content, delivery of the data via ERP interface is often compulsory. This delivery from the ERP system to the EDI system can therefore be achieved relatively easily under certain circumstances in which the interface is extended by the relevant content for outbound delivery notices (DESADV). On the basis of a qualifier to be agreed on bilaterally, the Softzoll EDI system recognizes whether it is data intended for generating OSTRPT messages. In this way, it is possible to separate this data stream from the traditional delivery notices and to use it only to produce the OSTRPT messages. If the various OSTRPT statuses are provided via this interface too, the EDI system automatically generates an OSTRPT document in BAHAG for any change in status. An additional challenge can arise from the fact that the online store order number / ID generated by BAHAG cannot be imported into the ERP system, carried forward, and delivered to the EDI system via an interface in order to generate the OSTRPT messages.This online store order number/ID is, however, usually compulsory in all relevant document interchanges. A particular add-on module from Softzoll extracts the online store order number / ID from the inbound BAHAG online store ORDERS and holds it in a separated database table (standard storage period: 7 days). When the relevant OSTRPT messages are generated, this information is then automatically added. The prerequisite for this feature is merely the possibility of referencing the ERP interface’s outbound data to item level if required. Keywords

• Softzoll, EDI, EDIFACT, BAHAG, online store, integration, suppliers, order, order process, order confirmation, delivery notice