A client I once helped had a vendor that used to send the company a price list for a third- party product. The list had to be updated manually by the purchase department in SAP R/3 4.7. This manual process was cumbersome and prone to many errors. Not only did the company need an automatic process for updating the prices, but it also needed to ensure that the client’s own product and the third-party product were delivered together. My team and I helped the client by creating a custom development using intermediate document (IDoc) methodology in SAP R/3 4.7 for automatic price updates. Then, to ensure that the products were delivered together, we linked the delivery date of the client’s own product to the purchase requisition release date of the third-party product. This made the price update procedure seamless and reduced the number of errors that occurred due to manual intervention. It also reduced the manual effort, which was around 60 days of work a year. The automated process does not require any manual intervention. Someone has to manually intervene only if there are errors. This may be around seven to eight days of effort per year. The approximate savings for the client was US$15,000. I’ll explain exactly what we did and how we did it.

Third-Party Process Overview

Before I begin the procedure, let me explain how the third-party process works. The third-party process starts with the creation of a sales order for a product that a company does not manufacture but procures from a third party. When the sales order is created, the sales order of the third-party item results in the creation of a purchase requisition that is subsequently converted into a purchase order ( PO). The third party receives the PO and sends a PO confirmation. Once this material is shipped, the third-party vendor sends an advanced shipment notification to the customer or company, whichever is applicable. At the same time the third-party vendor also sends an invoice to the company for payment. There is no goods receipt-based invoice verification in this scenario as the goods are not brought into company inventory. Therefore, only the invoice is processed. The confirmation sent by the third-party vendor triggers an inbound delivery that is updated in the PO against the item confirmations. You can see the whole process in Figure 1.

Setting Up the Third-Party Process

Now let me explain the master data setup for a third-party scenario. Since the manufacturing company functions only in terms of buying and selling the product, the material type is HAWA (trading goods). This is the standard SAP material type used for trading goods. Step 1. Create a material. Start by using transaction MM01 to take you to the Create Material (Initial Screen). Go to the Material Type field and choose Trading Goods from the drop-down menu (Figure 2). You also can use standard account groups for customer (sold-to party – 0001) and third-party vendor (vendor – 0001). These are maintained in configuration and you can use them while maintaining customer master data and vendor master data. For customer master creation, use transaction XD01. Select Sold-to party in Account group for the customer from the drop-down menu (Figure 3). Step 2. Set up the material master. The material master item category group in Basic data has to be BANS (the SAP standard item category for third-party items), which you can select from the drop-down menu of the GenItemCatGroup field (Figure 4). Then go to the Purchasing tab of the material master and check the Autom. PO indicator in the Purchasing view to activate it (Figure 5). The Activate Autom. PO indicator creates POs from purchase requisitions using transaction ME59. Go to the Materials Requirements Planning (MRP) 2 tab. Then in the Procurement type field select F (external procurement) from the drop-down menu (Figure 6). The order can be sent to the vendor using EDI 850 message, which is the standard for PO. Step 3. Create vendor master data. Enter transaction XK01. Then, activate the Acknowledgement Reqd and Automatic purchase order check boxes in the vendor master purchasing data (Figure 7). The Acknowledge Reqd check box requires you to perform an order confirmation in the SAP system when the vendor receives the PO. You can also manually enter an order acknowledgement with a transaction. This can be automated via EDI 855, PO acknowledgement, resulting in an IDoc ORDRSP from the vendor to you. This helps the company to find out if the vendor has received the PO. The Automatic purchase order check box helps you to use transaction ME59 (which can be run as a background job) to convert the purchase requisition (PR) into a PO. Do this during vendor master creation using transaction XK01 or during vendor master change using transaction XK02 in the purchasing data screen. Do not activate the indicator GR-Based Inv. Verif. check box for this vendor. This is because in this scenario you do not carry out a goods receipt (GR) of the items in the company because they are directly sent by the third-party vendor to the customer. The company does not receive the inventory of such items on its books. The vendor sends the invoice to the company when the third-party goods are shipped to the customer. Step 4. Maintain the source list. This tells you that the third-party material for a particular plant has to be obtained from a particular vendor. Use transaction ME01 to go to the Maintain Source List: Overview Screen. In the Fix (fixed vendor) column, place a check in the check box (Figure 8). Step 5. Set up the standard purchase info record for the Vendor-Material-Plant combination. This maintains the price at which the third-party material is procured. Use transaction ME11 to get to the Create Info Record: Initial Screen (Figure 9). Provide the input and then press Enter. The system takes you to the Create Info Record: Purch. Organization Data 1 screen. The Ackn. Rqd (acknowledgement required) check box has to be active with the Confirmations key as 0001. Click the check box for Ackn. Rqd and a drop-down menu appears. Select 0001 (Confirmations) from the drop-down. (Figure 10). Do not activate the GR-based invoice verification indicator (GR-Bsd IV check box as shown in Figure 10). Step 6. Create a sales order. When you create a sales order for the third-party item, the sales order document type is OR. Populate the Order Type field with OR. Then the screen shows you the sales order header data (Figure 11). You can view the schedule line details by clicking the schedule lines for item icon. For the third party, the Item category for sales order item is TAS and the schedule lines category (in the Sc… column) is CS (Figure 12). These settings are standard settings for third-party items. Step 7. The system creates the PR while saving the sales order. This is because item category TAS is determined for the sales order item. Double-click the PR number in Figure 12. To see the purchase requisition details as shown in Figure 13. The purchase requisition in Figure 13 PR is just for display. When you perform this step, your purchase requisition converts into a PO using transaction ME59.

Customization of the Process

So far I have covered the standard SAP settings required for the creation of sales and purchase orders for third-party items. Now I’ll talk about the customization that we carried out per our client’s needs. Remember, our client needed to have its third-party products information sheet automatically update, and ensure that its products were delivered together. To satisfy both these needs, my team and I created two customizations which I call Arrive Together and Purchase Info Record Update.

Arrive Together Customization

Arrive Together customization ensures that both products arrive at the customer’s site at same time. In the case of sales processing with two line items, one of which is a company’s own product and the other a third-party product, you cannot achieve the Arrive Together concept. Standard SAP systems including SAP ERP Central Component (SAP ECC) 6.0 does not have any features to achieve this, but just follow these very simple instructions and you can have arrive together customization if you like. In this customization, you need an additional check for the third-party products to determine whether a purchase requisition (PR) has to be converted into a PO based on the delivery date of the deliverable product in the sales order. The PR release date is linked to this delivery date while you create the sales order. Once you’ve created the delivery for the company’s own order and flagged the sales order as ship complete, the system automatically converts the PR to a PO. A delivery creation job exists that runs for deliveries that are due. The sales order is marked as ship complete when the goods issue takes place against the delivery assuming that the drop-shipped components are always available at the vendor’s end for delivery.

Purchase Info Record Update Customization

The typical method to update the purchase info record to have them reflect changes in prices for third-party products is to update them manually once the vendor sends the price list. This consumes a lot of time and is not suitable when there are more advanced methods of doing it using EDI. You can address this limitation by developing some customization. I’ll show you how you can apply a custom development to make this process easier. The third-party vendor sends the catalogue of product prices in the form of an IDoc. This IDoc updates a custom table and maintains it in SAP ECC 6.0 using table maintenance. Then a custom program compares the prices in this table against those maintained in the purchase info records and updates the purchase info records for any changes. Use the following steps to create a new inbound IDoc: Step 1. Define and develop the function module. You write your own custom development by writing custom function modules or custom programs. Standard SAP systems use a combination of function modules and programs to execute transactions. Use transaction code SE37 to define and develop the new inbound IDoc. This is a custom object that contains the code to make updates to the table. Step 2. Maintain the characteristics of an inbound function module. Use transaction code BD51 to do so. This allows you to choose whether you want mass processing or individual processing for the IDoc. The SAP system has flexibility in case a company’s business requirement is to do it individually. Step 3. Define the IDoc type. Because you’re not using any SAP standard IDocs, you have to define a custom IDoc. Use transaction code WE30 to help build the structure of the IDoc. It also helps to define the data elements that have certain values in the actual processing. Certain values refer to the data values that IDoc data elements carry. For instance, the price has a value associated with it, such as 15. The currency has a value associated with it, such as USD, and so on. Step 4. Define a logical message. Use transaction code WE81 to identify which type of data is to be handled. For instance, it can be an order, delivery, or invoice. In this case it is a custom message type for price list. Step 5. Assign the message type to the IDoc type. Use transaction code WE82 to establish a link between the message and the IDoc basic type . Step 6. Assign an IDoc type and message type to the function module. This assigns the custom IDoc creation. Use transaction code WE57 to link the IDoc type and message type to the function module. The assignment is maintained by the technical person because it provides flexibility to have different messages types and IDoc types for different function modules. The technical person maintains the assignments of a message type to an IDoc type for custom IDocs. As for standard SAP IDocs, the assignments are maintained as a part of the product itself. Step 7. Define the process code for processing the inbound IDoc. The process code enables you to define a method for processing the IDoc. Use transaction code WE42 and assign the message type and the function module to this process code. Then select the processing options as Processing with ALE service and Processing by function module. Table 1 shows the fields the custom IDoc can have.

Field name Field description VENDOR Vendor from whom the price details are sent AMATNR Material number of the client MMATNR Manufacturer material number VMDESC Vendor material description UPRICE Material price PCURR Purchase currency AVAIL Availability (Y/N) AVLQNTY Available quantity AQUNIT Quantity unit UPCCODE Universal Product Code (UPC)
Table 1	IDoc fields

A custom function module updates a custom table, such as ZT_PRICE_UPDATE, with the data from the IDoc. Then a custom code compares the prices in the structure with the info records and updates the purchase info records wherever applicable. The details of the custom table (ZT_PRICE_UPDATE) are in Table 2. It is a Delivery Class A table (that shows master and transaction data) showing the price and product master from third-party suppliers.

Field Data element Data type Length Decimal places Description MANDT MANDT CLNT 3 0 Client VENDOR LIFNR CHAR 10 0 Account number of vendor or creditor AMATNR MATNR CHAR 18 0 Material number VMATNR ZVMATNR CHAR 35 0 Vendor’s material number MMATNR ZMFMATNR CHAR 35 0 Manufacturer’s material number SMATNR ZSMATNR CHAR 35 0 Substitute material number VMDESC ZVMDESC CHAR 40 0 Vendor’s description of material — segment UPRICE ZSPRICE CURR 11 2 Unit price for third-party processing materials as on EDI 832 file PCURR WAERS CUKY 5 0 Currency key AVAIL ZAVAIL CHAR 1 0 Availability flag third-party material — segment Z1TPRIC AVLQNTY ZAVLQNTY1 QUAN 15 3 Available quantity — EDI 832 file from third-party suppliers AQUNIT MEINS UNIT 3 0 Base unit of measure MSTATUS ZMSTATUS CHAR 1 0 Material status for third party MTYPE ZMTPTYPE CHAR 3 0 Material type for third party UPCCODE EAN11 CHAR 18 0 International article number (EAN/UPC) LASTUPDT DATUM DATS 8 0 Date LASTUPTM UZEIT TIMS 6 0 Time LASTUPID UNAME CHAR 12 0 User name RECSTAT ZRECSTAT CHAR 6 0 Record status — insert or modify for EDI 832

Table 2

Price table for third-party products

In an SAP system one or more data elements can be common to many tables. To maintain a consistency, the custom tables should be in sync with the main tables where the master data is stored. Therefore, you have to carry out the validation for the following fields since I am referring to existing master data in the system for vendor and material: VENDOR-LIFNR with LFA1-LIFNR and LFM1-LIFNR AMATNR-MATNR with MARA- MATNR and MARC-MATNR AQUNIT-MEINS with MARA-MEINS To validate them, the custom table uses data elements that are also a part of standard SAP tables. The validation has to be carried out to maintain data consistency. For instance, when you create a vendor, the master data is stored in table LFA1. Since you are going to update the purchase info record for a vendor whose master data is stored in table LFA1, the vendor code has to be common in the custom table and the LFA1 table. A custom program such as ZT_PRICE_COMPARE compares the prices in Table 2 with those maintained in the purchase info records. The logic of the program is as follows: For the material number and vendor number provided in the selection criteria, the program should query custom price table and find a suitable entry. For this entry, it should carry out the following: Compare ZT_PRICE_UPDATE -UPRICE with EINE-NETPR (first the program queries EINA with material (EINA-MATNR) and vendor (EINA-LIFNR) combination to get the info record number (EINA- INFNR). This result then queries the standard back-end EINE table to get EINE-NETPR. Compare ZT_PRICE_UPDATE - PCURR with EINE-WAERS (search logic same as in 1 above) Compare ZT_PRICE_UPDATE - AQUNIT with EINE- BPRME (search logic same as in 1 above) If all the values are identical then no update is required and therefore you do not need to call transaction ME11 or ME12. If only the first value differs, then use transaction ME12 to update the price. If there is mismatch in the second value, you see the error message “Currency incorrect, please change currency”. If there is mismatch in the third value, you see the error message “Base unit incorrect, please change base unit.” If you find more than one info record, then you have to make changes for all the records. There could be multiple purchase info records for one vendor in an SAP system. A purchase info record is vendor-, material-, purchasing organization-, and plant-specific. Table 2 stores the price for a material-vendor combination. If multiple plants and purchasing organizations have the same vendor-material combination, then you need to change multiple records. If no entry is found in the standard SAP table EINA for the material number and vendor number combination and both the material number and vendor exist, then the program uses transaction ME11 to create a new purchase info record for the combination. Figure 14 shows a sample screen of the custom program for price update. The material number has multiple values. Other inputs include the plant, purchasing organization, vendor number and purchase info record category (e.g., standard, sub-contracting, pipeline, and consignment). Here I am using the standard info record category.

Output Determination and Standard SAP Specifications — EDI Messages

My third-party procurement can use standard electronic data interchange (EDI) message types to make the entire process seamless by integrating with the customer and the vendor systems. You can use these standard EDI types: EDI 850: Purchase order EDI 855: Purchase order confirmation EDI 856: Advance shipment notification EDI 810: Invoice You can use the following details, which SAP IDoc methodology uses for standard EDI messages: For purchases (EDI 850) Basic type – ORDERS01 Condition table – 27 Access sequence – 0001 Message determination schema – RMBEF1 Message type – ORDERS (outbound) Processing code – ME10 For order acknowledgement (EDI 855) Message type – ORDRSP Confirmation control key – 0001 Confirmation acknowledgement category – AB and LA (LA creates an inbound delivery when the 856 comes in) Shipping notification (856) Basic type – DESADV01 Message type – DESADV Processing code – DESA Vendor invoice (810) Basic type – INVOIC01 Message type – INVOIC Processing code – INVL To use these messages, you have to set up additional master data. For an 850 purchase order (i.e., a standard EDI message type used for purchase orders), you need to carry out the following three steps: Step 1. Create an output condition record. This is a logical step of SAP EDI setup. Use transaction code MN05 to do this. The input screen is shown in Figure 15. Provide the following input: Output Type: Enter NEU — the SAP standard output for the purchase order Key Combination: Select the Purchasing Output Determination: Purch. Org./Vendor for EDI radio button Once you’ve provided these inputs , the system takes you to the next screen where you need to maintain the Vendor , Function (Funct), and Medium (Me…) data. Put the vendor code in the Vendor column . In my example , I put, VN ( Vendor ) in the Funct column , and put a 6 (EDI) in the Medium column . This defines how the purchase order output type is set up for EDI mode of transmission (Figure 16). Step 2. Define the partner for EDI in the partner profile. Use transaction code WE20 to set up EDI partner settings. (For a purchase order, the sending partner is the manufacturing company and the receiving partner is the third-party vendor.) Fill in the fields under the Post processing: permitted agent tab. Fill in the Ty. (agent type), Agent (name), and Lang. fields (Figure 17). Step 3. Maintain the outbound parameters and message types in transaction WE20. This links the vendor and the EDI message types for which the vendor has to be set up. This is for 850 PO. EDI message types are nothing but the IDoc message types. When these are linked to the vendor EDI setup, you are set up to have IDocs with these message types created as soon as you create a PO for the vendor (Figure 18). Partner Role: VN Message Type: ORDERS In the Outbound Options tab, define the: Receiver port: A000000002 Basic type: ORDERS01 In the Message Control tab (Figure 19), define the: Application: Ef Message type: NEU Process code: ME10 Maintain a similar setup for the other message types. Some parameters differ. EDI message types are nothing but the IDoc message types. DESADV for advance shipment notification, INVOC is for vendor invoices and ORDRSP is for purchase order confirmation. These have been explained below. Partner Role – VN, Message type – DESADV Outbound options – Process code – DESA, Trigger immediately, Cancel Processing after syntax error active Partner Role – VN, Message type – INVOC Outbound options – Process code – INVL, Trigger immediately, Cancel Processing after syntax error active Partner Role – VN, Message type – ORDRSP Outbound options – Process code – ORDR, Trigger immediately, Cancel Processing after syntax error active