Streamline Inventory Item Creation/Maintenance in Complex Value Added Reseller Business Environments

By Radhe Lanka World Wide Technology, Inc. Introduction

Businesses housing a gamut of Supply Chain Processes often encounter complex Inventory Item setup requirements which can quickly become bottlenecks when the system lacks a robust and scalable Item Definition process. This paper explains how a new design implemented at WWT can streamline such inventory item creation and maintenance processes and make improvements to the overall business flow. The paper has been presented under the sub headings below. About the Company World Wide Technology, Inc. Previous State Inventory Item Maintenance System Objectives Enhanced Process Design and Functional Set ups Technical Aspects Scalability and Ease of Use Conclusions

About World Wide Technology, Inc

World Wide Technology, Inc. (WWT) is a leading Systems Integrator providing technology products, services, and supply chain solutions to customers around the globe. Founded in 1990, WWT has grown from a small startup to a world-class organization approaching $3 billion in revenue. WWTs proven processes span the technology implement ation lifecycle as we provide customers with advanced technology solutions, such as Unified Communications, Security, Datacenter and Wireless Mobility from over 3,000 manufacturers around the world. By engaging WWT to manage their planning, procurement and deployment processes, our customers benefit from our certified technology professionals, nationwide logistics facilities and a suite of eCommerce applications designed to greatly simplify the supply chain. WWTs ISO 9001:2008 and TL 9000 registration reinforces World Wide Tec hnologys commitment to exceed our customers requirements and expectations. Global Presence: Headquartered in St. Louis, Missouri, WWT employs more than 1, 100 professionals and owns more than 1.3 million square feet of state-of-the-art warehousing, distribution and int egration space strategically located throughout the US. Sales Offices around the Globe 13 Distribution Cent ers across the Americas Headquartered in St. Louis, Missouri Engineers in most major U.S. Cities

Previous State Inventory Item Maintenance

At WWT we have several supply chain partners in the system that require new programs and projects setups, as the business scope keeps extending. The Inventory requirements from this varied set of customer business programs range from Items needing simple Inventory setups to complex business rules around Categories, Catalogs, Substitute Parts, Serial/Asset Controls, Planning Part Controls and many others. Primarily WWT s Customer Order Fulfillment process handles most of the Inventory It em
COLLABORATE 10 OAUG Forum Copyright 2010 by Radhe Lanka Page 1 of 8

setups as orders keep rolling into the Production system as shown in Fig 1.0 below. Batch Item Uploads and manual Item entry via Oracle Forms are also part of the process.

Until early 2009, using a more traditional approach, customer Inventory Item setups were done in the Oracle E RP via Oracle Standard It em Import mec hanism using Interface Tables and Scheduled Conc urrent Programs. Rapidly increasing set of new Customer Business programs and revisions to existing programs began choking the It em Import process and soon this traditional approac h was becoming an overall Order Fulfillment process bottleneck. Further, the manual uploads that were used depended totally on the users ability to identify the rec ords and the Inventory Item supply chain attributes required by a particular business program correctly and creat e a file and drop it to the Item Import process (Batch Item Upload as shown in Fig 1.0 above). As you can imagine this process has a good amount of scope for error (during manual dat a file creation) and pot entially setup incorrect Item attributes. This White paper presents a new IT initiative implemented at WWT that was aimed at significantly reducing the complex processes that encompass entire Item Creation and Maintenance and make the process very scalable and ultimately help improve the overall Order Fulfillment and Inventory processes. The new design also incorporates Custom Setup Forms (setting up Process Metadata) that reduces errors in the process significantly. The paper elaborates the new design under the sections below.

System Objectives
The Inventory Item process that was being us ed depended on certain set of hard coded rules written in the inbound order process and some table level database triggers, developed and maint ained per customer program requirements. For instance to set the serial/asset control the dependency was on the Item template attached to the Inventory Organization in which the item was getting created or the code had a logic that catered to certain business programs. Extending the functionality required code changes and time invested in regression testing. Handling new item setup requirements based on the
COLLABORATE 10 OAUG Forum Copyright 2010 by Radhe Lanka Page 2 of 8

Customer business rules began affecting the overall productivity of the Inventory and Order Fulfillment Processes. And this further became more concerning wit h the influx of new complex customer programs from a leading PC manufacturer. In certain cases users were required to manually setup items and or change the setups controls aft er the items were import ed into Oracle via Standard Item Import process. Enhancing the Item creation process had become a call of the hour to address these concerns. A new solution was implemented to handle Real Time Item Creation, aut omate complex setups like Serial/Asset control, Substitute Items, Cat egories, using PRE and POS T Item creation rules. One of the design goals was to drive the entire logic based on Custom Setups and use Oracle Inventory Item API calls, instead of depending on the batch Item Import process. Making the design highly scalable, of course was a prime part of the agenda too.

Enhanced Process Design and Setups

Enhancing the Item Creation process by using Oracle API Calls instead of Oracle It ems Interface improves the process greatly by producing a better turn around time in individual item creation and child org assignments. Fig 2.0 gives an overall view of the new architecture that has been designed. This new process design can incorporate custom logic for a varied set of business programs.

COLLABORATE 10 OAUG Forum

Copyright 2010 by Radhe Lanka

Page 3 of 8

For instance Customer A needs Asset Tagging rules to be set around Item Setups and this in turn could mean something like creating Manufacturer Part Number records in Inventory tables. Another Customer B would require its parts be setup under multiple Inventory Organizations with some having serial control and some Asset tagged also. These could be easily setup and turned ON or OFF based on the newly designed as you will see below

ERP Setups The entire architecture has been designed to work based on a Process Metadat a (Custom Setups) definition to handle setups and drive the whole Inventory It em creation and Maintenance process as needed by the business programs. The Process Metadat a has been designed to hold business rules under 3 Custom tables as described below. Busine ss Programs Setup: This is the Primary Setup component within the Proc ess Metadata which uniquely identifies a Customer Business Program (or even a Project within a program) under the key element called Org Destination Code. The Description column (as you see in the table below) holds the necessary description attributed to the Customer Program. This lookup also holds some Generic elements that work as common elements designed to work across all business programs.
Org Destination Code WWT_1 WWT_2 WWT_3 WWT_4 Description ALL ITEMS FORM ITEMS ORDER IMPORT CUSTOMER XYZ Source GENERIC FORM COP Stop on Failure? Y N N N Delete Interface N N Y N

Busine ss Programs to Inventory Organizations Mappings: This Process Metadat a lookup assigns the key element Org Destination Code, from the main Customer Program lookup above, to a list of Child Inventory Organizations and default Item templates. Adding a new Invent ory Org or removing one is just a matter of end dating the lookup dat a or disabling it by setting enabled flag attributes. The table below gives some of the columns that have been included as a part of this Process Metadata look up table.
Org Destination Code WWT_4 WWT_4 WWT_4 WWT_4 WWT_N WWT_N Inventory Organization Code 01 08 24 29 01 99 Item Template Enabled? Y Y N N Y Y

XYZ_Template Drop_Ship_Template Serial_At_receipt < org level default template> ATO_Items

Busine ss Program to Item Supply Chain Attribute s Mapping: This lookup handles all the Pre and Post Item processing business rules and setups that are required per customer program and per Inventory Organization that the program needs the items assigned to. The subsequent sections detail the usage of the Pre and Post assignments in the overall Item creation and maintenance process, that are setup in this lookup
Org Destination Code WWT_1 WWT_1 WWT_1 WWT_4 Process Type PRE-PROCESS PRE-PROCESS POST-PROCESS POST-PROCESS Seq 10 20 10 10 WHERE Clause Program Unit Clean_Items eStore_Check Set_Category Set_Assets Stop on Failure Y Y N N Enabled? Y Y Y N Page 4 of 8

ORG=101 ORG<>101

COLLABORATE 10 OAUG Forum

Copyright 2010 by Radhe Lanka

WWT_N WWT_N

POST-PROCESS PRE-PROCESS

10 10

Set_SubItems Set_ATO_Part

N Y

Y Y

The above three process metadata lookups group is designed to hold all the necessary setups that Items will need during the course of their creation and maintenance. These will get used in Order Import Defaulting Rules, Order Cleanup and Oracle Items Form and also during Mass Item Uploads. Any program that needs a new set of rules can be added to these lookups.

Technical Aspects
The entire gamut of Item Creation functionality is provided by a set of PL/SQL programs that can be invok ed with a large range or parameters and the core logic is driven based on the process metadata lookups listed in the previous section. Object Types have been utilized in the packages to give flexibility in processing dynamic and static SQL statements either passed via parameter calls or via Process metadat a setups. Object Ty pe is a physical definition of record in the database. Table of Object type is a physical definition table of rec ords in the database. Both these are utilized in item creation because of the support to SQL on Table of Object type (both Static and Dynamic). The data passed int o the Item Creation process in the form of Table of Objects facilitates the SQL joins directly (eliminating the need of looping and parsing before evaluation) For example S elect * From TABLE (CAS T ( p_it em_tbl AS wwt_item_tab_type)) Here p_item_tbl is inbound data and wwt_item_tab_type is the physical definition of the table of objects in the DB.

COLLABORATE 10 OAUG Forum

Copyright 2010 by Radhe Lanka

Page 5 of 8

The whole process works using four sub-processes as shown in the Fig 3.0 above. Step 1 - Rec ord Validation and Child Org Explosion Step 2 - Pre-Process Execution Step 3 - Item Creation/ Update via Oracle API Calls Step 4 - Post-Processing and Response Applications that require Item Creation and Maint enance make calls to a Core Package Process Items that takes the execution through the aforementioned sub processes. However there is a great provision within the Process Items call where the source application can request only a particular sub-process execution. For instance a parameter Sub Proc ess Stage has been included in the design to allow for such specific requirements. This is particularly useful in instances like Item Maintenance where items pre-exist and only some post-Processing (assigning Catalogs or creating Approved Supplier Lists) is required. Similarly there could be a requirement where only the item needs to be creat ed in a new inventory org and just the API call needs to be execut ed. The Sub Processes are discussed below. Validation and Child Org Explosion Sub-P roce ss In this sub-process the Process Meta Data, where all the Business Programs are setup to utilize the item creation process, gets used and the exec ution goes on to select all the inventory organizations and the associated It em Templates setup that are required by the process requesting It em Creation. A record set is built here based on the Org Destination Code parameter (shown in tables above under section ERP Setups) passed to the Proc ess Items code. The item is exploded into multiple invent ory item records beginning with the Master Org record and then child records. Special design considerations have been put into the logic where if the calling program sends only a particular Inventory Org, that overrides the Org Explosion process and just considers that inventory org for all item creation processing. If the Master Org is sent or if the Inventory Org parameter is left blank in the call, the org explosion happens and the child orgs get included. Pre-Process Execution The Pre-Process handles all pre-item creation default rules that the source application requires and the entire set of rules are fetched from the Lookups as displayed in tables under the section ERP setups. Rules like Serial Control Setup, Item KFF Segment Rules (for instance a leading Networking Products company business program requires the items to be setup as XY Z under inventory item segment 4), Unit of Measure rules, Item Segment cleanup (cleaning up invalid characters from the Description and the actual KFF segments) and several others can be setup under pre-processing setups which get executed sequentially, thereby preparing the item records with all the necessary functionality. Some of the functions that are to be ex ecuted for ALL items regardless of the calling program request are included in a special Pre-Process package, referred to in the Meta Data setups as GENE RIC. Here is where functionality like Item KFF Segment Cleansing, Description Column Character truncation (if exceeding the limit of 150 characters) etc occur. If multiple Pre-Processing steps are included in the Setups, the order of execution is GENERIC first, Source Program Specific Next and then lastly the Lookup Parameter Specific.

Item Creation/Update via Oracle API Calls This stage is where the Records sets that are prepared for item creation/updat e are submitted to Oracle via the Standard API call - ego_item_pub.process_i tem. Based on the parameters that were set by the source application that makes calls to the main package, the corresponding Item attributes are set and inventory organizations/templates assigned and the It em API creates or Updat es the items as necessary. Return messages from the API call are captured and stored in variables to be later referenced in the subsequent sub-process and then the response is sent back to the calling application.
COLLABORATE 10 OAUG Forum Copyright 2010 by Radhe Lanka Page 6 of 8

Post-Proce ssing and Re sponse Once the Data Validation, Inventory Org Explosion, Pre-Proc essing, Item Creation via API are complete the process then proceeds to execute the Post-Processing Steps. Here the setups again dictate what is required to be ex ecuted for a particular calling application. Several features can be added to the item definition here. For Instance S etting Custom Asset Controls, enabling MFG Part Numbers, Assigning to Catalogs and Categories, Building Item Relationships (Substitute Items, Reciprocal Parts etc) can be done. All that can be achieved after an Item has been created can be handled via the Post- Process execution steps.

Key De sign Consi derations One of the key parameters/setups that has been included is Fail on Error. When the Process Items package is executing this setup indicates if the control can move to the next step in the pre/post processing steps if there is an error in the current step. This works when the current record is getting processed for item creation. Then there is a global Business Program level setup Fail All Records which when set to Y indicates if for a set of records being submitted if a particular stage in Pre/Post processing fails, then fail (a ROLLBA CK gets issued within the PL/SQL Code) the entire set of rec ords getting created. In the Oracle Master Items Form a Custom Trigger has been included to fire during the master item creation proc ess. When the user creates a Master Organization record the custom Post Item Insert trigger picks the record and proceeds with exploding Child Orgs, perform Pre-P rocessing, submit API Calls and finally complete Post-Processing. Internally the Trigger Fails the Master Record record and takes over control from the form. This way any Pre and Post Item Rules that have been setup get utilized and

Scalability and Ease of Use:

The whole process of setting up new Customer Programs requiring Inventory Item Definitions has been simplified with the new design. The Metadata Lookups govern the whole process. All that is required is adding new Customer Program, an Org Definition Code and assign them Inventory Organizations at a minimum. Programs needing more complex pre and post processing sequences can register more setups in the Metadata Lookups and use several of the public procedures and functions that have been created. Further, turning off a Customer Program simply requires end dating the Process Metadata lookup codes for a Business Program (identified by the Org Destination Code key element in the met adata). Setting a new invent ory Organiz ation as a child organization is enabling it in the Org Destination Lookups and either use a default template or add a specific template the business program needs. The opportunities to expand the logic are endless. Identified Usage: 1. Order Import Proce ss: Item Creation as a part of Order Import. The prior mechanism of creating items during order import process was to submit new items via the Oracle Item Import Process with several hard-coded values in the calls. Any new changes meant code changes or handling them via Oracle Items Form as Post Process. New Child organization required by Customer Programs meant manually assigning the items before the orders are imported. Further, the orders had to wait in queue until the item import process completed and if there were any item errors, the wait time was more. With the new design in place all this manual effort and order queue time issues have been addressed.

COLLABORATE 10 OAUG Forum

Copyright 2010 by Radhe Lanka

Page 7 of 8

Now, Order Import places It em Requests via the new package calls and the items are created real time and the results are seen right away where Orders are imported right after the item creation call. Child Organizations get assigned, serial control, asset controls are set and the Items and Orders are ready to be transacted. 2. Mass Item Upload: Existing Mass Item uploads run based on the Oracle Item Import process using the Int erface tables. This process is effective although is limited by the parameters that are given to each rec ord in the interface tables and then running validation programs and another set of post item programs that handle setups around categories/catalogs/relations hips etc. With the new design and functionality offered mass item loads could us e the main Process Items calls offered by the new package. However we have obs erved that passing a large number of item records to the package is causing performanc e issues where the AP I call is slow. This is currently being addressed. 3. Oracle Items Form: The new item creation logic has been included in the Oracle Items table Mtl_System_Items custom On-Ins ert Trigger. This trigger will be used for Child Org Item Creation and give a handle to all the P re and Post Processing procedures associated with the current program. The Customer Program specific Org Destination Code reference is entered into DFF Attribute. 4. Import Order Cleanup Utility: Customer Purchase Orders that ent er into WWT systems are staged first into a set of Custom Tables. Several defaulting rules are applied and the records are submitted to Item Creation before the Order Import process kicks in. Any errors that are enc ount ered during this import process are seen via this custom utility called OCU (Order Cleanup Utility). Here the users can invok e the entire Item Creation logic to create items via the custom tool and set attributes as the business program needs. Behind the scene the Process Items package that handles the whole process kicks in and does its magic!!!

Conclusions
With the new process handling item setups via AP I call instead of Item Import concurrent programs and enabling business programs via custom Process Metadata setups has significantly improved our Inventory Setups and thereby Order Fulfillment processes. Setting up new customer programs or changes to existing ones from the Inventory Setup Perspective are no longer a concern to our business managers and IT Teams. Earlier the issues were around how to manage new setups and at the same time not affect existing setups (caused due to code changes). Overall we have seen the benefits below from the new initiative. Relieved Item Import run load on the system (which was running about 18000 times per week). All Item Maintenanc e logic can be identified under one main process and a set of custom setups. The modular design implemented has enabled us to make changes very localized to a particular business program or even a set of specific items and not affect the whole process. Improved Processing Time - Inventory Item Creation and Child Orgs assignments. Reduced Errors via Standard It em Creation Form. Our Logistics team deals with a lot of duplicate Item Child Org errors today. These got addressed. Real Time Item Creation - User sees Errors on the Form per Item, instead of the Logistics team that is used correcting them, seeing them in Interface tables.

COLLABORATE 10 OAUG Forum

Copyright 2010 by Radhe Lanka

Page 8 of 8