Skip to end of metadata
Go to start of metadata

 Open Catalog Inteface Conversion Modules - Fixing the data that comes back

The SAP Open Catalog Interface (OCI) Makes integration between SAP PM systems and suppliers of Maintenance, Repair, and Operations material much more accurate while reducing the complexities of finding 'the right part.'  The information protocol that is established between the SAP system and the vendor is fairly well defined and has proven to work.  Unfortunately, the context that the supplier sees the information in does not always align with the way that the information needs to be structured in our SAP systems.  This can be easily seen in looking at what additional data entry is required when a Maintenance Technician returns a shopping cart as components to a work order.  For each item returned in the shopping cart an additional dialog box of information needs to be manually entered by the Technician.  This includes information like  Material Group, General Ledger, and other information that realy should not be required knowledge for a mechanic.  While the amount of entry can be significantly reduced by keeping the SAP Material Master current with every part that may possibly be needed, this is more of a dream than a reality.

For many items, particularly for non-stocked (N) items, additional entries will be required when bringing a shopping cart back into the system.  OCI Conversion Modules can do a lot to reduce the need for these manual entries and improve the accuracy of the information entered by the Maintenance Technicians.  Some examples of how this accuracy can be improved relate to properly identifying the part manufacturer, more clearly identifying the proposed vendor for the material, and (possibly) determining the correct GL for the part.

Conversion Modules for OCI are somewhat like a user exit.  They are small programs that are executed as a part of the shopping cart processing.  They can be configured to execute with specific catalogs (i.e., trading partner specific) and multiple conversion modules can be called for each shopping cart.  Once the shopping cart has been returned to SAP and the data from the HTML page has been stored in an SAP internal table a conversion module can be called to adjust, enhance, or otherwise alter the data received from the supplier.

The local interface for an OCI Conversion Module looks like this:

*"----------------------------------------------------------------------
*"*"Local Interface:
*" IMPORTING
*" VALUE(CAUFVD_EXP) TYPE CAUFVD OPTIONAL
*" VALUE(AFVGD_EXP) TYPE AFVGD OPTIONAL
*" VALUE(PLKOD_EXP) TYPE PLKOD OPTIONAL
*" VALUE(PLPOD_EXP) TYPE PLPOD OPTIONAL
*" TABLES
*" IMPORT STRUCTURE IOCI_FIELDTAB OPTIONAL
*" CHANGING
*" VALUE(FCOM_XL_TAB) TYPE RIHFCOM_XL OPTIONAL
*"----------------------------------------------------------------------

The FCOM_XL_TAB contains the data related to the component as selected from the shopping cart. There is a lot of interesting information in this structure (it is worth a discussion by itself), but we will just use a couple of these in the current discussion. These items will be the Manufacturer/Manufacturer Part Number, the Material Group, and the G/L Account Number.  From looking at the interface header above it should be clear that there is a lot of information available at the time that the conversion program runs, including work order information and equipment information. 

Manufacturer Correction

In the process of implementing an OCI interface with a vendor, it will eventually become obvious that there are differences in terminology and berivity.  One place this will stand out is in manufacturer names.  One would think that we would all be good with the simple ones like SKF and Timken, but that shows one of the flaws of thinking.  I have seen SKF saved as SKF, SKFBRG, BEARINGSKF, and SKFGROUP.  This is further complicated by suppliers sometimes using the Manufacturer code to add some intelligence to the parts list.  For example, the Caterpillar punchout seems to return the Manufacturer Code as 'AAA' if a remanufactured part is being ordered instead of a new one. 

Since the beginnings of Information Technology, we have addressed these kinds of inconsistencies by using simple look-up tables.  The correct home (in my opinion) for a manufacturer lookup table is in the OCI conversion Module.   This example assumes that a manufacturer cross-reference table has been creates in the SAP system.  This 'Z' table does not contain many records in the production environment that I support (less than 1000 records) so the example will read the entire 'Z' table into an internal table.  This is done to improve supportability rather than performance, although there is only the smallest performance impact from this approach.  The attached screen shots show the function header settings for an OCI Conversion Module. 






 

 
 

The Conversion Processing

On entry into the conversion routine, the cross-reference table is read in its entirety into the internal table used by the function.  Some shops may have standards that require a qualified read of this table, so everyone's approach may be a little different when it comes to populating this data.

IF lt_XREF_MFR[] IS INITIAL.
 SELECT * FROM zmfr_xref
  INTO TABLE lt_XREF_MFR
  ORDER BY mfrnr.
 ENDIF.

With a lookup table in place, We can now get to the real work that this enables.  The process can now do a read of the MARA table for material that contains the manufacturer/Manufacturer Part Number combination that was returned from the supplier's web site.  This can enable the automatic determination of several of the required items on the material input screen such as the G/L account, pricing over-rides, alternative sources, Item Category, and other functionality that allows the OCI process to comply with corporate purchasing policies and practices.  information is updated in the fcom_xl_tab structure, and when the function is returned the changes are now in the SAP system.

A particular case mentioned earlier was Caterpillar's changing the manufacturer name when a selected component is a rebuild.  To address this the following logic was added to the conversion module that we have added to all of our Caterpillar punchouts:

*"---------------------------------------------------------------------
* Ticket 79344 Caterpillar uses manufacturer code AAA for Cat rebuilt
* parts. This was causing problems for the buyers. Reconvert to CAT.
*"---------------------------------------------------------------------
IF fcom_xl_tab-CATALOGID = 'CIWALKER' OR
   fcom_xl_tab-CATALOGID = 'CLEVEBROS' OR
   fcom_xl_tab-CATALOGID = 'CARTER' OR
   fcom_xl_tab-CATALOGID = 'WYOMINGCAT'.
      TRANSLATE fcom_xl_tab-mfrnr TO UPPER CASE. "#EC TRANSLANG
      IF fcom_xl_tab-MFRNR = 'AAA'.
          fcom_xl_tab-MFRNR = 'CAT'.
      ENDIF.
ENDIF.
 

Material Group Handling

Material Groups are another area where we have a hard time synchronizing with our suppliers. The OCI interface does allow a supplier to provide material group information back with a part on the shopping cart.  Unfortunately, most companied have decided they they need to create their own material group codes and do not comply with any of the internationally recognized standards.  If the supplier can provide a listing of material group codes the same cross reference approach as used above with the Manufacturer Names can be applied to the shopping cart item. 

Adding Conversion Modules

Conversion Modules are set up in the IMG in the same workspace as the other OCI configuration:


Conversion Modules are ties to external catalogs, which requires an entry on a catalog by catalog basis.  Each conversion module can be used with mor than one (or even all) of the catalogs called by the SAP system.  Even further, more than one conversion module can be called when a shopping cart is processed.  Be careful when assigning multiple modules to a catalog to ensure that they are processed in the order that you want them to be processed.  A sequence number is provided in SAP for this purpose.
 
If you find that your users are having to do rework after using OCI catalogs, or that there are issues with determining the correct purchasing processes when users are calling open catalogs, you should consider looking into using Conversion Modules to improve the dependability and accuracy of data returned from external vendor catalogs.