© 2007 Recycled Paper Greetings Internal and Confidential 1 Scan Based Trading An Oracle...

© 2007 Recycled Paper Greetings Internal and Confidential

1

Scan Based Trading An Oracle Consignment Inventory Solution

NCOAUG, August 15th, 2008

Karen S. Janssen, Director of IT Infrastructure

Anand Dharwadkar, Manager of IT Development


2

Agenda

• Understanding Scan Based Trading

• RPG’s Challenge

• High Level Solution Design

• Setup Considerations

• Maintenance and Conversion Considerations

• Other Considerations

• Epilogue: RPG’s results

• Questions and Answers


3

Understanding Scan Based Trading


4


• What is Scan Based Trading?– Scan Based Trading (SBT) is defined as the process where suppliers

maintain ownership of inventory within retailers' warehouses or stores until items are scanned at the point of sale.

– Typically, Scan Based Trading programs use EDI solutions as the key component to synchronize information between a retailer and its Scan Based Trading suppliers.

• 816 Organizational Structure

• 832 Catalogs

• 852 Product Activity Data (POS)

• 861 Receiving Advice

• 810 Invoice

• 820 Payment Advice


5


• What are some benefits?

Increased Sales Improved Retailer Relationships

Improved visibility of product sales Reduced Order Processing Costs

Reduced cost of stock overages Lowered Cost of Inventory

Improved Time to Market Improved Financial Metrics


6

Understanding SBT

Selling Organization

Inventory View

Inventory Organization

Sub Inventories

Product ships from warehouse to customer store

Inventory Transfers


7

Understanding SBT

Point Of Sale View

POS Data

Invoice

Master Inventory

Scrapped


8

RPG’s Challenge


9

RPG’s Challenge

Business Perspective

• Increasing pressure from larger retailer customers to move to a Scan Based Trading model of doing business

• Each SBT retailer had unique, customer-specific requirements– Store Conversion along side new store openings

– Data requirements

– Rollout schedules

– EDI exchange frequency and schedules

• RPG needed to maintain the standard order processing, shipping and inventory management for non-SBT customers


10

RPG’s Challenge

Technology Perspective

• RPG had made a significant investment in Oracle Technology Stack and therefore needed to leverage existing functionality in core Oracle Application modules to meet SBT Process requirements – Mission critical systems included Financials, Order Management, Inventory, WIP, BOM,

Workflow, Incentive Compensation

– Recently Invested heavily in a 11i/9i/10g upgrade

– Oracle 9i Application Database

– 10g Application Server

– Oracle Developer

– Discoverer

– 10g Oracle Warehouse Builder

– 10g Data Warehouse

– 11.5.10.2 Oracle Applications


11

RPG’s Challenge

Solution Approach

– Engaged a consulting team to conduct a feasibility assessment on SBT programs

– During the study, a collaborative, cross-functional team gathered requirements and mapped and gapped to various programs

– Feasibility study indicated that the Oracle Core Consignment Inventory Solution would meet RPG’s requirements. (Through the study, it was determined that Oracle’s Collaborative Planning was not needed to meet RPG’s need.)

– Developed a proof of concept pilot

– Demonstrated solution through the pilot and made adjustments

– Built Solution

– Implementation Solution

– Scheduled and slow customer store conversion rollout


12

RPG’s High Level Solution Design


13

Solution Design - Overview

Merchandise Order System

University ParkWarehouse

SBT Sub inventory Customer Rooftop 1

SBT InventoryOrganization

SBT Sub inventory Customer Rooftop 2

Customer Ship To

Customer Ship To

Retailer Customer

Ship OnlyOrders

Ship Only Orders

Field Hand Held ScannerOrders

Manual Orders

Customer Order of what was sold

Bill Only Invoice

POS Data / SBT OrderMiscellaneous

Receipt

MiscellaneousReceipts

Bill only Invoice

POS Data / SBT Order

1 2

3

4

5


14

Solution Design – Orders

nCamp

Telxon

Orders

Manual Orders

Orders

Order ImportOracle Order Management

Book & Validate

Pick ReleaseShip

Confirmation

Miscellaneous Receipt

Transaction Error?

Exception Handling

Close / End

1 2

3

Fiel

dU

nive

rsity

Pa

rkB

road

way

Yes

No

4

COGS Clearing acct

Field Hand Held ScannerOrders

Demand/Replenishment Order Fulfillment

RP

G

He

ad

qu

art

ers

Merchandise Order System


15

Solution Design – Point of Sale Invoicing

POS Data

Loader Program

Staging TablePre

ProcessorHVOP Order

Import

1

Cus

tom

er /

Pres

cien

tU

nive

rsity

Pa

rkB

road

way 2

InvoiceWorkflow /

Sales & Commissions

Workflow / Inv Interface

End

RPG_CUS_SBT RPG_CUS_POS

Point of Sale (POS) Order Creation and Customer Invoicing

Cu

sto

me

r E

DI

RP

G

He

ad

qu

art

ers


16

Solution Design - POS EDI Transactions

POS signifies data on product as it is scanned at the cash register. SBT means customer will only pay for what they sell.

Depending on the trading partner, POS data is received inbound using one of two methods:

852 – The 852 document contains date of sale, UPC, price, quantity sold and store id.

POS Data Gentran Oracle Billing

Customer sends 852

Third-Party VAN

sends 810Oracle Billing

• 810 – The 810 document contains the same data as on the 852, plus an invoice number for each rooftop.

Gentran


17

Setup Considerations


18


SBT Customer

Address Site(Rooftop 1)

InventoryOrganization



Address Site(Rooftop n)

Sub Inventory Location(Rooftop 1)

Sub Inventory Location (Rooftop 2)

Sub Inventory Location(Rooftop 3)

Sub Inventory Location(Rooftop n)

Item 1Item 2

Item 1Item 2

Item 1Item 2


19


Description AppInitial Setup

Ongoing Maintenance

Method

Define Customer AR Y N Oracle FormEstablish Customer Sites (Single Ship To & Bill To) AR Y N Oracle Form

Define Inventory Location INV Y N Oracle FormDefine Master Customer Organization, (Inventory Organization Classification, INV Y N Oracle Form

Create Subinventory for Rooftop INV Y N Custom ScriptLink Subinventory to Rooftop at Customer Ship To (DFF) AR Y N Oracle Form

Item Creation INV NA NA Oracle Data LoaderAssign Inventory Items to Customer Organization INV Y Y Oracle Form

Define Costs Sub Element INV Y N Oracle ProgramDefine Item Cost & Update Concurrent Manager Program INV Y Y Oracle Form

Item Update Stock (misc receipt / issue) INV Y Y Oracle FormDefine Order Transaction Types - SBT Consumption OM Y N Oracle Form

Define Documents OM Y N Oracle Form

Assign Sequences OM Y N Oracle Form

Define Receivables Transaction Types AR Y N Oracle Form

Load Initial Demand Orders OM Y N Custom Script


20

Conversion and Maintenance Considerations


21


Sl No Element Module Method

1 Add / Expire Inventory Items INV Oracle Forms/Script

2 Load Cost Information (both UP and Consigned Inv.Orgs) INV Oracle Program

3 Stock Adjustments INV Oracle Forms

4 Inventory Reconciliations at Sub-inventory level (rooftops) INV Oracle Forms

5 Period Closures for each Customer Organizations INV Oracle Forms

6 POS Order Processing OM Oracle HVOP

7 Demand Orders (though Ncamp) OM Oracle HVOP

8 Cycle Counts Inv Custom Script

9 Physical Inventory Inv Custom Script

10 Credits OM Script


22


A word about Oracle’s High Volume Order Processor

Oracle’s HVOP provides a streamlined and simple process

– Tuned

– ideal if 90% of orders are common or standard

• Some features are not integrated

– Constraint checking

– iPayment Integration

• Some functionality is not optimized with HVOP

– Basic and Advanced Pricing

– Shipping Integration

– More detail on HVOP is available in an Oracle white paper on CD


23


Customer Store Conversion

Make a conscientious and informed decision on what stores are candidates for conversion.

• Carefully consider:

• Time needed to complete store conversion activity and plan accordingly

•Plan activity to the minutest of detail

•Determine what to do with replenishment orders during the store conversion activity

• Do you want to stock the store in preparation for the conversion

• Do you want to black out ordering during the conversion cycle

• Very early in the cycle, determine to do with the product that already exists in the store that is converting.

• Identify what the customer’s EDI capabilities and required lead times


24


Daily Inventory Transactions and Credit Memos Management

Inventory Transactions will be generating daily as either a materials transfer to a sub inventory, a decrement to inventory due to a sale, or an inventory return (credit memo or scrap). Orders will be generated for shipment to the customers store and a Bill-only invoice will be generated at the point of sale.

• Carefully consider:

• Processing Impact to Production Schedules

• Impact to closing period activity

• Adjustments for COGS

• Automated process could possibly take Inventory levels below tolerance

• Impact of setting up a new items for release

• Impacts to cycle counts and physical inventory activity

• DATA VOLUME

• Data retention requirements and Purging frequencies


25

Other Considerations

– Consignment Inventory and Collaborative Planning requires R11.5..x.x upgrade

– Increased disk space requirements for miscellaneous receipts, SBT POS data, Inventory Organizations, sub inventory transactions, and invoices

– Impact to financial forecasting analysis and reporting. For example, carry COGS of inventory at a rooftop versus a order from the warehouse that is invoiced upon shipment.

– Challenges with servicing existing non-SBT customers while implementing new scan based trading partners

– What to do with existing inventory in rooftops that has already been shipped and invoiced.


26

Epilogue

A word about Oracle’s Collaborative Planning – RPG’s Perspective


27

Epilogue

A word about Oracle’s Collaborative Planning – RPG’s Perspective

ADVANTAGES

• User friendly GUI to interact with customers and suppliers

• Easy manual execution for replenishment and inventory visibility

DISADVANTAGES

• Extremely data and memory intensive

• Min/Max plans only at Organization level

• Untested Customer VMI Solution


28

Epilogue

– Since May 2007, RPG has converted to a Scan Based Trading business model with over 2000 customer stores

– Recent metrics have indicated that, for at least one of our major customer, sales have been up +13%

– Process is solid enough that RPG can now handle converting customer stores at a rate of 150 stores per week.

– Collecting POS data has allowed RPG react quickly to market trends

– Hot topics can be quickly identified, and within in days the merchandise can be moved into other customer stores

– Slow movers can be identified, analyzed for trends and management decisions on what to do with the merchandise can be made proactively.


29

Questions?

• Q&A

• Contact Information

– Karen Janssen

– Office: 773-868-8457

– Email; [email protected]

– Anand Dharwadkar

– Office: 773-868-8379

– Email: [email protected]

© 2007 Recycled Paper Greetings Internal and Confidential 1 Scan Based Trading An Oracle...

Documents

Transcript of © 2007 Recycled Paper Greetings Internal and Confidential 1 Scan Based Trading An Oracle...