Brake Parts Inc.

BPIoS Project
Solution Design Document
 BPI Solution Design Document

August 20, 2021Document Control

Change Record

Date Version Updated By Description of Change

07/15/2013 1.0 David Griffiths Original
07/23/2013 1.1 David Griffiths FIN draft complete
08/08/2013 1.2 David Griffiths P2P and O2C complete
08/22/2013 1.3 David Griffiths Updated to reflect new and updated
design documents

Reviewers

Date Reviewed By Organization Position

537521414.docx August 21, 2013 Page 2 of 113

 BPI Solution Design Document

Contents

Document Control..........................................................................................................................................................2
Change Record........................................................................................................................................................2
Reviewers................................................................................................................................................................2
Contents......................................................................................................................................................................... 3
Preface............................................................................................................................................................................8
Intended Audience..................................................................................................................................................8
Related Information Sources..................................................................................................................................8
Project Background.......................................................................................................................................................10
Implementation Methodology..............................................................................................................................10
EBS System Overview...................................................................................................................................................12
Core Modules........................................................................................................................................................12
HR Foundation......................................................................................................................................................14
E-Business Tax.......................................................................................................................................................14
Sub-Ledger Accounting.........................................................................................................................................14
Design Considerations..................................................................................................................................................15
Constraints & Dependencies.................................................................................................................................15
Goals & Guidelines................................................................................................................................................15
System Architecture.....................................................................................................................................................16
Oracle Business Suite Architecture.......................................................................................................................16
HR Foundation.................................................................................................................................................18
Data Conversion Design........................................................................................................................................19
Data Delivery Design.............................................................................................................................................21
Enterprise Business Suite (EBS) Solution Components....................................................................................21
BI Publisher......................................................................................................................................................21
Legacy System Integration....................................................................................................................................22
Process Overview..........................................................................................................................................................23

537521414.docx August 21, 2013 Page 3 of 113

 BPI Solution Design Document

Order-Cash Design........................................................................................................................................................24
Description............................................................................................................................................................24
Process Flow.........................................................................................................................................................25
Context Diagram...................................................................................................................................................25
Touch Points.........................................................................................................................................................25
Data Conversion....................................................................................................................................................27
Security................................................................................................................................................................. 28
Subsystem Design – Standard Design Components..............................................................................................29
Customer Master.............................................................................................................................................29
Orders..............................................................................................................................................................31
Pricing..............................................................................................................................................................32
Shipping...........................................................................................................................................................35
Sales Accounting..............................................................................................................................................37
Invoicing...........................................................................................................................................................39
Standard Returns.............................................................................................................................................41
Subsystem Design – BPI Specific Design Components..........................................................................................43
Check Fill Percent.............................................................................................................................................43
Container Quantities........................................................................................................................................43
Days on Hold....................................................................................................................................................44
Free Freight Minimums....................................................................................................................................44
Release Backorders..........................................................................................................................................45
Use Membership Number................................................................................................................................46
Mailing Subscription........................................................................................................................................46
Ship-To.............................................................................................................................................................47
Off-List Price Hold............................................................................................................................................47
Default Country of Origin.................................................................................................................................47
Dropped Not Shipped Report..........................................................................................................................48
Check Harmonized Code..................................................................................................................................48
Reset Request Date..........................................................................................................................................48
Reset PO Numbers...........................................................................................................................................48
Pick Slip Report................................................................................................................................................49

537521414.docx August 21, 2013 Page 4 of 113

 BPI Solution Design Document

Cash Application..............................................................................................................................................49
Tronitec Interface............................................................................................................................................50
Aging by Sales Channel Report.........................................................................................................................51
Procure-Pay Design.......................................................................................................................................................52
Description............................................................................................................................................................52
Process Flow.........................................................................................................................................................53
Touch Points.........................................................................................................................................................54
Data Conversion....................................................................................................................................................55
Security................................................................................................................................................................. 57
Subsystem Design – Standard Design Components..............................................................................................58
Item Definition.................................................................................................................................................58
Item Numbering...............................................................................................................................................58
Item Categories................................................................................................................................................58
Costing.............................................................................................................................................................59
Requisitions.....................................................................................................................................................61
Approved Supplier Lists...................................................................................................................................63
Purchase Orders...............................................................................................................................................63
Receiving..........................................................................................................................................................64
Replenishment.................................................................................................................................................65
Offshore Shipping............................................................................................................................................67
Trouble Board..................................................................................................................................................68
Asset Creation..................................................................................................................................................69
Subsystem Design – BPI-Specific Design Components..........................................................................................70
Blanket Purchase Agreement (BPA) Upload/Download...................................................................................70
Remittance Advice Email..................................................................................................................................70
Account Generator..........................................................................................................................................70
Printed Purchase Order....................................................................................................................................71
Core Returns....................................................................................................................................................71
Country of Origin.............................................................................................................................................71
Receiving Transaction Personalization.............................................................................................................71
Sub-inventory Transfer Personalization...........................................................................................................72

537521414.docx August 21, 2013 Page 5 of 113

 BPI Solution Design Document

Global Spend Reports......................................................................................................................................72

ASN for GOL Suppliers......................................................................................................................................72
Item Material Cost Upload...............................................................................................................................72
GM Quantity on Hand......................................................................................................................................72
Chassis Integration...........................................................................................................................................73
Oracle Inter-Org Transfers Download and Upload...........................................................................................73
Oracle Inventory Adjustments Upload.............................................................................................................73
Oracle Inventory Reconciliation Upload...........................................................................................................73
Oracle Item Download.....................................................................................................................................74
Oracle Pick Release Download and Upload......................................................................................................74
Oracle PO Receipts Download and Upload......................................................................................................74
Plan-Build...................................................................................................................................................................... 75
Description............................................................................................................................................................75
Process Flow.........................................................................................................................................................75
Touch Points.........................................................................................................................................................76
Data Conversion....................................................................................................................................................77
Security................................................................................................................................................................. 78
Subsystem Design – Standard Design Components..............................................................................................79
Bills of Material and Routing Definitions..........................................................................................................79
Engineering Change Orders.............................................................................................................................82
Forecasting.......................................................................................................................................................83
Master Demand Scheduling.............................................................................................................................84
Distribution Requirements Planning................................................................................................................84
Stanford Manufacturing...................................................................................................................................86
Chowchilla Manufacturing...............................................................................................................................88
Dirty Core Teardowns......................................................................................................................................90
Postponement (White Box Re-Branding & Upgraded Rotors).........................................................................92
Cost Management............................................................................................................................................95
Subsystem Design – BPI-Specific Design Components..........................................................................................98
GM Forecast Upload........................................................................................................................................98
Naperville Returns Report................................................................................................................................98

537521414.docx August 21, 2013 Page 6 of 113

 BPI Solution Design Document

Forecast Consumption Report.........................................................................................................................98

Job Travelers....................................................................................................................................................99
Discrete Job Shortage Report...........................................................................................................................99
ECO implementation Notification....................................................................................................................99
Financial Management Design....................................................................................................................................101
Description..........................................................................................................................................................101
Process Flow.......................................................................................................................................................102
Touch Points.......................................................................................................................................................105
Data Conversion..................................................................................................................................................106
Security...............................................................................................................................................................107
Subsystem Design – Standard Design Components............................................................................................108
Chart of Accounts..........................................................................................................................................108
Translation & Consolidation...........................................................................................................................109
Asset Management........................................................................................................................................110
Bank Statement Reconciliation......................................................................................................................111
Period Close...................................................................................................................................................112

537521414.docx August 21, 2013 Page 7 of 113

 BPI Solution Design Document

Preface

Intended Audience

This document is designed to serve multiple audiences and purposes:

• It should serve as orientation material for new project members, imparting to them enough
information about the project architecture to understand how subsystem design and integration.
• It should serve as a project overview for reviewers outside the core BPI implementation team,
providing a concise description of how key business processes are supported.
• It should serve as objective evidence that the project team has followed through on the goal of
implementing functionality described in the business requirements.

The document provides the level of detail appropriate for the aforementioned purposes. It does not
attempt to duplicate information contained in other project deliverables, nor provide rationales for
design decisions. Where appropriate, other project deliverables are referenced for more detailed
information regarding specific solution components and decisions impacting their design.

Related Information Sources

The definition of the future state solution includes the following documents, which provide additional
information about the solution architecture described in this document:

Process Maps
Process Maps provide diagrammatical decompositions of the major business processes supported
by BPIoS. Each Functional Track business process is comprised of the following components:

 One Master Process Map depicting primary business processes

 One Process Map for each business process that’s been decomposed into sub-processes
 Swim lanes representing actors (e.g. functional owner, user, or department)

Business Requirements Documents

Business Requirements Documents (BR-01) describe the business processes, process flows,
business requirements, reporting requirements, security requirements, interface requirements and
conversion requirements for each sub-process identified in the Process Maps. One Business
Requirement Document has been developed for each Oracle module.

Configuration Scripts
Configuration Scripts (CS-01) describe the Oracle configurations necessary to support BPIs specific
requirements described in the Business Requirements Documents. They identify the sequence in
which configurations must be performed, the required system responsibilities, the system

537521414.docx August 21, 2013 Page 8 of 113

 BPI Solution Design Document

navigations and the appropriate configuration values. One Configuration Script has been
developed for each oracle module.

537521414.docx August 21, 2013 Page 9 of 113

 BPI Solution Design Document

Security Matrices
Security Matrices (SM-01) define the rules used to control system access. For each module, they
describe the set of responsibilities (system roles) that will have access to information and
functionality contained within the module. The sets of functions, processes and reports that can be
accessed by each responsibility are identified. Finally, the list of users who will be granted each
responsibility is provided. One Security Matrix has been developed for each Oracle module.

Decision Acceptance Documents

Decision Acceptance Documents (DADs) provide business cases and comprehensive information on
the background and rational for significant design decisions. They are prescribed by the Decision
Making Framework as the authorized vehicle for supporting high impact decision-making by
documenting business requirements, assumptions, impacts, constraints, solution options and
recommendations when more than one viable option exists.

Data Conversion Strategy and Overview

The Data Conversion Strategy and Overview (CV-01) provides requirements, scope, objectives,
strategy and approach for the data conversion effort.

537521414.docx August 21, 2013 Page 10 of 113

 BPI Solution Design Document

Project Background

After its acquisition from Affinia Group, Brake Parts International (BPI) needed to replace their
legacy systems with independently licensed systems. Oracle E-Business Suite was selected as
part of BPIs long-term architecture to replace a range of in-house and hosted systems that were
previously licenses by Affinia.

The Brake Parts International Oracle System (BPIoS) Program was initiated in 2012 as the first
phase or E-Business integration to provide a platform for the manufacturing, procurement, sales
and financial functions.

BPIoS leverages a single instance of Oracle Corporation’s E-Business Suite Release 12 to

replace an instance of Oracle R12, that was implemented as a temporary AP solution, and retire a
number of legacy systems. In doing so, the program aims to achieve the following goals:

 Implement an integrated suite of Commercial Off-The-Shelf (COTS) financial,

management and planning applications with a consistent user interface and minimal
customizations.
 Adopt consistent business processes aligned with internal requirements and industry best
practices
 Improve the quality, timeliness and ease of access to information for ongoing decision
support
 Increase the automation of routine manual business processes
 Enable flexibility in business systems for meeting current and future business models.

Implementation Methodology

The implementation methodology is based upon six major project phases: Definition, Analysis,
Design, Build, Validate and Deploy.

Manage Project
Support/Mentor

Manage Change/Communications
Define

Plan Analyze Design Build Test Deploy

Manage System Infrastructure

537521414.docx August 21, 2013 Page 11 of 113

 BPI Solution Design Document

This document reflects the baseline of the new system at the conclusion of the Definition, Analysis
and Design phases. As subsequent validation is performed during the Build, Validate and Deploy
phases, enhances may be made to the design.

The implementation decomposes the Oracle modules into four tracks, based primarily along the
following Oracle product lines:

 Plan-Build: BOM, Supply Chain Planning, Work in Process, Engineering

 Procurement: Purchasing, Inventory, Cost Management and Accounts Payable
 Order-Cash: Order Management, Advanced Pricing, Shipping Execution and Accounts
Receivable
 Financial Management: General Ledger, Fixed Assets and Cash Management

E-Business Tax and Human Resources Foundation, which support multiple process tracks, will
also be implemented.

Despite the product-based decomposition defined above, many business processes are
dependent on solutions that cross-functional and/or technical boundaries. This document aims to
identify the primary cross-track designs required to support BPIs end-end business process
requirements.

537521414.docx August 21, 2013 Page 12 of 113

 BPI Solution Design Document

EBS System Overview

Core Modules

The following core Oracle modules are included in the BPIoS implementation:

Plan-Build Modules
Work in Process Oracle Work in Process is the core of Oracle’s Discrete
Manufacturing solution. Oracle Work in Process by itself provides a
complete production management system focused on improving
productivity, quality, and responsiveness while maximizing throughput
and production.
Bills of Material Oracle Bills of Material support the definition of bills for manufactured
and sold products.
Supply Chain Planning Oracle Supply Chain Planning is the main planning engine used to
plan supply (POs, Requisitions, Work Orders) based on demand
(forecasts, sales orders).
Engineering Oracle Engineering facilitates Engineering Change Orders and
prototyping items, BOMs and work orders to build prototypes before a
product can be released to manufacturing.
Procure-Pay Modules
Purchasing Oracle Purchasing supports the procure-pay cycle. As the core of the
Oracle Advanced Procurement suite, which includes modules which
may be implemented in subsequent BPIoS projects, Oracle
Purchasing provides storage for policy and supplier information, a
workbench for buyers, and consolidated visibility into spend.
Inventory Oracle Inventory is a comprehensive inventory management system
that supports increased inventory accuracy and customer service
levels while providing tools to reduce carrying costs, labor costs, and
inventory write-offs.
Cost Management Oracle Cost Management provides supports costing for Inventory,
Work in Process, Purchasing, and Order Management, along with the
creation of associated journal entries in the General Ledger.
Accounts Payable Oracle Payables integrates with Oracle Purchasing to match supplier
invoices to purchase orders and receipts, process electronic and
physical payments and support payment-related business rules.

537521414.docx August 21, 2013 Page 13 of 113

 BPI Solution Design Document

Order-Cash Modules
Order Management Oracle Order Management drives the order fulfillment process. It
provides the capabilities for customers, partners and employees to
select the right products and services, negotiate the best prices and
ensure timely fulfillment.
Advanced Pricing Oracle Advanced Pricing provides a logical and flexible framework to
handle complex and tailored pricing scenarios through price books
and pricing strategies.
Shipping Execution Oracle Shipping Execution automates all shipping- related processes,
including trip management, picking, packing and shipping
confirmation.
Accounts Receivable Oracle Receivables provides functionality to centrally manage
customer information and support invoicing, receipt and collection
activities.
Advanced Collections Oracle Advanced Collections extends the Receivables functionality to
allow collection activities to be planned, executed and recorded in a
customer-centric environment.

Financial Management Modules

Cash Management Oracle Cash Management is an enterprise wide solution for
managing liquidity and controlling cash. It provides direct access to
expected cash flows, supports analysis of cash requirements and
enables reconciliation between the bank and oracle ledgers.
Fixed Assets Oracle Assets utilizes a central source of asset data to support
standard management tasks such as transfers, disposals and
reclassifications. Journal entries, including depreciation, are
interfaced directly into the General Ledger.
General Ledger Oracle General Ledger integrates with Oracle Projects, Procurement
and Financials applications to provide integrated inquiry, reporting
and analysis of financial results, with drill-down to source transactions
generated by originating modules.

Some additional standard Oracle components will be implemented to support the modules listed above
and address some of the identified business requirements:

537521414.docx August 21, 2013 Page 14 of 113

 BPI Solution Design Document

HR Foundation

The Oracle HR Foundation consists of components within Oracle Enterprise Business Suite that
provide a foundation to manage the workforce and the work structures into which they are deployed.
The HR Foundation is accessible by all Oracle modules and provides necessary components to support
procurement, project management and financial business processes.

HR Foundation includes a number of forms and tables to enter and maintain information for these
areas. Some modules need access to HRMS forms and tables, while others utilize HRMS data
structures. Among the data structures supported are employees, organizations, jobs, positions,
locations and grades. BPI will utilize HR Foundation to store information about employees,
organizations and locations for use across all modules.

E-Business Tax

E-Business Tax provides a centralized rule repository to support Order to Cash and Procure to Pay
business requirements in General Ledger, Order Management, Payables, Purchasing and Receivables
modules, along with other Oracle modules that BPI is not implementing as part of the BPIoS project.

Tax Management Repository Reports Dashboards

Validate Calculate Determine Additional

Services Taxes Taxes Recovery Services

Tax Registration
Rules Engine Regimes
Place of
Taxable
Rates Metadata
Supply Recovery
Taxes Basis Taxonomy & Rules

Configuration Party Product Place Process

Recover OU Tax
Definition/Setup Tag Regime Tax Jurisdiction Tax Status Tax Rate
Rate Accts

Sub-Ledger Accounting

Oracle Sub-Ledger Accounting (SLA) is a rules-based accounting engine that centralizes the definition
and maintenance of accounting rules utilized by sub-ledgers/modules.

SLA is an intermediate step between the sub-ledgers and the General Ledger. Journal entries are
created in SLA for each sub-ledger transaction that requires accounting and then transferred to Oracle
General Ledger. Each sub-ledger transaction that requires accounting is represented by a complete
and balanced sub-ledger journal entry.

Enforcement of the rules is automated by SLA, which creates the accounting entries for sub-ledger
transactions when the Create Accounting process is run.

537521414.docx August 21, 2013 Page 15 of 113

 BPI Solution Design Document

Design Considerations

Constraints & Dependencies

The following overriding constraints and dependencies have been factored into the complete
design solution. Where appropriate, the BPI Decision Framework was utilized to balance competing
priorities:

 Supporting integration with legacy systems

 Minimizing the short term impact on legacy systems, especially those due for eventual
retirement within the EBSS scope
 Balancing the availability of legacy system resources with ongoing operational needs
 Reflecting future plans for extending or enhancing the software
 Working within existing project timelines
 Working with existing project resources
 Nightly Extract-Transform-Load process (see Data Delivery Design)

The need to produce a design that not only addressed the business requirements in scope for the
current project, but also provides a foundation for future BPI projects had a significant impact on
solution design. Several solutions components were either introduced as temporary solutions, or
carried forward from the legacy environment, with the ultimate goal of retiring them when COTS
solution components are introduced later in the program. Temporary solution components and
configurations are identified later in this document.

Goals & Guidelines

The following goals, guidelines, principles, or priorities dominated or embodied the design of the
BPIoS solution:

 Align with long term solution architecture and project goals

 Minimize customizations
 Simplify solutions
 Minimize impact on existing and new users
 Minimize ongoing maintenance
 Minimize ongoing support

537521414.docx August 21, 2013 Page 16 of 113

 BPI Solution Design Document

System Architecture

Oracle Business Suite Architecture

The Oracle Business Suite architecture utilizes standard Out-Of-The-Box components (modules) and
interfaces. In general, the standard Oracle design of interactions between these modules has also
been utilized. Exceptions to this approach are noted below and in the relevant subsystem design
element later in this document.

Shipping
Execution

Accounts
Receivable/
Advanced
Collections

Order
Advanced Pricing
Management

Engineering Work in Process

Cash Management

BOM Inventory Cost Management

General Ledger

Supply Chain
Fixed Assets
Planning

Purchasing Accounts Payable

537521414.docx August 21, 2013 Page 17 of 113

 BPI Solution Design Document

Source Destination Description

Purchasing Accounts Payable Purchase orders and receipts
Purchasing Inventory Receipts
Inventory Purchasing Inter-org shipments
WIP Cost Management WIP accounting classes, job variances
Order Management Cost Management Invoice only sales
Shipping Execution Cost Management Shipments
Cost Management General Ledger Journal entries
Cost Management WIP Material costs, resource costs
Engineering WIP Engineering BOMs & routings
Inventory WIP Items, inventory balances, transactions
WIP Purchasing Outside processing
Cost Management Purchasing Standard costs
Engineering Purchasing Resources
Order Management Shipping Execution Inventory orders
Order Management Accounts Receivable Non-inventory orders
Order Management Inventory Shipments, reservations, demand
BOM Order Management Model, option class and kit bills
BOM WIP Standard bills
Engineering BOM BOMs, Routings
Inventory Order Management On-hand quantity, available to order
Inventory Cost Management Transaction rates
Cost Management Inventory Costs
Inventory BOM Items
Engineering Inventory Engineering items
Inventory Engineering Items
Shipping Execution Accounts Receivable Inventory orders
Advanced Pricing Order Management Order prices
Accounts Payable General Ledger Journal entries
Inventory General Ledger Journal entries
Accounts Payable Cash Management Payments
Accounts Payable Fixed Assets Asset-related expenditures
Fixed Assets General Ledger Depreciation, Adjustment, Retirement journal
entries
Order Management Accounts Receivable Invoices and credit memos
Accounts Receivable General Ledger Journal entries for invoices, receipts and
adjustments
Accounts Receivable Cash Management Receipts
SCP WIP Work orders
Order Management SCP Orders
Inventory SCP Stock
BOM SCP BOMs, Routings

537521414.docx August 21, 2013 Page 18 of 113

 BPI Solution Design Document

HR Foundation

Source Destination Description

HR Foundation Purchasing People, Organizations, Locations
HR Foundation Accounts Payable People
HR Foundation Inventory Organizations, Locations
HR Foundation Engineering People
HR Foundation Order Management People
HR Foundation Accounts Receivable People
HR Foundation WIP Labor Rates

537521414.docx August 21, 2013 Page 19 of 113

 BPI Solution Design Document

Data Conversion Design

Converted data falls into three categories: master data, transactional data and historical data. Master
data contains distinct, individual items about which information is stored, such as customers, suppliers
and fixed assets. Transactional data refers to financial and non-financial events related to master data.
Historical data is a combination of master data and transactional data that is no longer being actively
utilized, but is required for reference purposes.

Converted Data

Work Stream Module Item Source

Procure-Pay Purchasing Approved Supplier Lists TOLAS
Price Lists TOLAS
Purchase Orders TOLAS
Blanket Purchase Orders TOLAS
Inventory Items TOLAS
Item Transaction Defaults TOLAS
Item Categories TOLAS
Item Costs TOLAS
On-Hand Balances TOLAS
Stock Locators TOLAS
Accounts Payable Suppliers CAP, AGAP, TOLUS, BPICS
Supplier Banks TOLAS and/or Oracle?
Open Invoices
Order-Cash Order Carrier Freight Rates TOLAS
Management
Price Lists TOLAS
Open Orders TOLAS
Shipments TOLAS
Accounts Customers TOLAS
Receivable
Open Transactions TOLAS
Financial Fixed Assets Assets
Management
General Ledger Period Balances TOLAS
Plan-Build BOM Bills BPICS
Routings BPICS
SCP Sales History BPICS
Sourcing Rule Assignments BPICS
PDS OE Interchange BPICS
Comp Interchange BPICS
Pricing Interchange BPICS
Vehicle Applications BPICS

537521414.docx August 21, 2013 Page 20 of 113

 BPI Solution Design Document

Historical data
 Except where noted above historical data will not be converted into the R12 environment.
 Historical data will be extracted into a separate custom schema.

Exceptions and refinements to these rules will be elaborated later in this document. For additional
details about the data conversion strategy, refer to CV01 Data Conversion Strategy and Overview.

537521414.docx August 21, 2013 Page 21 of 113

 BPI Solution Design Document

Data Delivery Design

A range of reporting tools and data sources will be leveraged to support BPIoS reporting requirements.
The primary tools/data sources will be the Enterprise Business Suite and BI Publisher.

Enterprise Business Suite (EBS) Solution Components

Enterprise Business Suite reports will be utilized to satisfy requirements that need to reflect real-time
data. Standard reports will be utilized where possible. For situations when standard reports don’t fully
satisfy business requirements, standard reports will be copied and used as a foundation for subsequent
extension and modification. This approach minimizes development effort. Where no standard report
exists to act as a foundation, a BI Publisher report will be developed.

BI Publisher
Oracle Business Intelligence (BI) Publisher is an Oracle tool for authoring, managing, and delivering
formatted output such as reports, shipping documents, checks, letters, invoices, forms and other
documents. It allows end users to design layouts using Microsoft Word, Microsoft Excel, or Adobe
Acrobat. Output can be reviewed online, published to a portal, or delivered to multiple destinations like
printers, e-mail or fax.

See FSR02 AP Remittance Advice Email BPI for detailed design information.

537521414.docx August 21, 2013 Page 22 of 113

 BPI Solution Design Document

Legacy System Integration

The overall BPIoS architecture encompasses a number of legacy systems. Some of these will be
retired by Oracle functionality introduced during the BPIoS project, and some will remain as
temporary or long-term solution elements.

In order to accommodate these systems, existing interfaces are generally supported ‘as-is’,
meaning that the format of interface files generated by and consumed by legacy systems will
remain unchanged. Files received by Oracle will be processed to ensure they contain all required
information and values have been translated appropriately. Files generated by Oracle will be
translated to ensure they can be received by existing legacy systems without the need for
modifications and extensive testing. Exceptions to this approach have been noted in this
document.

The following diagram depicts the BPIoS architecture after the completion of BPIoS. The design
of each solution component will highlight specific integration points with legacy systems
throughout the remainder of this document.

BPIoS Legacy Integration Points

BPI Systems Future State 05/15/2013

echoMountain

HTTP Server
IPO Images.brakepartsinc.com

Finance G&A

App Server
ADP – Payroll/Clock FTN Magnolia CMS
FedEx brakepartsinc.com
QSI Raybestosbrakes.com
Napabrakes.com
Aimcobrakes.com
William & Assoc. Brakepartsinc.com.mx
intranet

Exchange GOL
Process
Server
Magento eCommerce LDAP
TroniTech 11

Cforia Cash Books 10

09 Oracle MySQL
Chase 11g 5.6
Image Server
12 13 14
General
08 Ledger
07 Payables Receivables

Purchasing Order
01 LabelVision
Management
02
03
HR
Fixed Advanced
(Partial) ADSI/Ship Direct
Assets Pricing
04
Oracle eBusiness Suite Applications
04
ADMS
Engineering Inventory 06 Planning

Oracle EBS
Bill of Work in Mexico
MSCA &
Material Process
India

EDI
Gateway UFIDA China

04
05
06 06 Engineering/CAD

GENTRAN

537521414.docx August 21, 2013 Page 23 of 113

 BPI Solution Design Document

Process Overview

The swim-lane diagram below depicts the logical integrated business process flow within the BPIoS environment. Note, however, that each step is iterative
and can be repeated many times within an overall process cycle. The individual subsystem designs described later in this document decompose the end-end
flow by module and in some cases by specific sub-process.

Overview

System Configuration & Order Capture Supply Chain Management Order Fulfillment Operations Management Financial Management Period End Close
Master Data Convernsion/
Entry

Engineering
Schedule P2B Period-
Execute Jobs Change
Jobs End Close
Orders

Perform
Master Data Process Process Invoices Cash Receipts O2C Period GL
Start Order Entry Planning Shipping Collections GL Close End
Maintenance Returns (see BR01) (see BR01) End Close Processing
(see BR01)

Bank Statement
Reconciliation
(see BR01)

Order Inventory
Fulfillment Management

Payment
Receiving - PO Invoice Processing P2P Period
Procurement Processing
(See BR01) (see BR01) End Close
(see BR01)

Asset
Management

The reference numbers indicated in each step refer to high-level steps in the detailed track-specific Business Requirements documents. For the complete set
of process flows showing their decomposition into sub-processes, refer to BR01 PO Requirements BPI, BR01 IN Requirements BPI, BR01 OM Requirements
BPI, BR01 AP Requirements BPI, BR01 AR Requirements BPI, BR01 CE Requirements BPI, BR01 FA Requirements BPI, BR01 GL Requirements BPI.

537521414.docx August 21, 2013 Page 24 of 113

 BPI Solution Design Document

Order-Cash Design

Description

The Order-to-Cash modules consist of Order Management, Advanced Pricing, Shipping Execution,
Accounts Receivable and Advanced Collections. Together, they support the following business
processes:

Module Business Processes

Order Management Price list maintenance, order processing, return processing
Advanced Pricing Price list rules maintenance
Shipping Execution Shipping management
Accounts Receivable Customer maintenance, invoicing, cash receipts and applications,
adjustment processing and month end close
Advanced Collections Customer account collections

Financial transactions will flow into the General Ledger from Order Management and Advanced
Shipping via the Cost Management module, and the Accounts Receivable sub-ledger via standard
system interfaces.

In accordance with BPIoS project goals, standard Oracle Order-Cash software configurations will be
utilized to provide baseline functionality. In certain areas, this has been extended to support high-value
BPI-specific business requirements. Extensions to the software will be noted below in applicable sub-
system designs.

537521414.docx August 21, 2013 Page 25 of 113

 BPI Solution Design Document

Process Flow

Order-to-Cash Level 1 Process Flow

Order Management

Enter Sales
Start Book & Schedule Pick Release
Orders
Inventory

Process Move Update Inventory

Pick Confirm
Orders Levels
Shipping

Process Deliveries Ship Order Ship Confirm Interface Trip Stop

Accounts Receivable

Customer
Customer Follow- Financial
Generate Invoice Receipts & Cash End
Up Reconciliation
Application

Context Diagram

537521414.docx August 21, 2013 Page 26 of 113

 BPI Solution Design Document

Touch Points

Source Destination Description

Bills of Material Order Management Model, option class and kit bills
Inventory Order Management On-hand quantity, available to order
Advanced Pricing Order Management Order prices
Order Management Shipping Execution Inventory orders
Order Management Inventory Shipments, reservations, demand
Order Management Accounts Receivable Invoices, credit memos
Order Management Purchasing Drop-ship requisitions
Order Management Cost Management Invoice only sales
Shipping Execution Cost Management Shipments
Shipping Execution Accounts Receivable Invoices
Accounts Receivable General Ledger Journal entries for invoices, receipts and
adjustments
Accounts Receivable Cash Management Receipts

537521414.docx August 21, 2013 Page 27 of 113

 BPI Solution Design Document

Data Conversion

Customers
Active customers will be converted from TOLAS, which will include, but not be limited to those with
open invoices. The customer architecture will be restructured in Oracle, so the conversion process will
be used to restructure BPIs legacy data using the new rules.

Price Lists
<Add content>

Carrier Freight Rates

<Add content>

Open Orders
<Add content>

Open Transactions
Open invoices and credit memos will be converted from TOLUS. Only lines with remaining balances
will be converted into Oracle; fully paid lines will not be converted.

Open Receipts
Customer receipts that have not been completely applied to invoices, including “on-account” receipts,
will be converted from TOLUS.

See CV01 Data Conversion Strategy and Overview, FSC04 – AR Customer Conversion, FS01C05 –
Open Transactions for detailed business requirements and solution design.

537521414.docx August 21, 2013 Page 28 of 113

 BPI Solution Design Document

Security

Order-Cash security will be managed using custom responsibilities. Users are granted access to one
or many responsibilities. Responsibilities provide all users with the same level of functional access as
each responsibility is configured to allow access to specific system functions. Some responsibilities will
be based upon standard (seeded) Oracle responsibilities, but custom versions will be created in order
to support future maintenance and enhancements.

Order Management

Responsibility Description Audience

BPI OM XXXXXX Ability to…
BPI OM XXXXXX Ability to…
BPI OM XXXXXX Ability to…
BPI OM XXXXXX Ability to…
BPI OM XXXXXX Ability to…
BPI OM XXXXXX Ability to…

See SM01 BPI OM Responsibilities for detailed security design.

Advanced Pricing

Responsibility Description Audience

BPI QP XXXXXX Ability to…
BPI QP XXXXXX Ability to…

See SM01 BPI QP Responsibilities for detailed security design.

Shipping Execution

Responsibility Description Audience

BPI WSH XXXXXX Ability to…
BPI WSH XXXXXX Ability to…

See SM01 BPI WSH Responsibilities for detailed security design.

Accounts Receivable

Responsibility Description Audience

BPI AR XXXXXX Ability to…
BPI AR XXXXXX Ability to…

See SM01 BPI AR Responsibilities for detailed security design.

537521414.docx August 21, 2013 Page 29 of 113

 BPI Solution Design Document

Subsystem Design – Standard Design Components

Customer Master

Oracle Trading Community Architecture (TCA) is a data model that supports the management of
complex information about the parties, or customers, who belong to your commercial community,
including organizations, locations, and the network of hierarchical relationships among them. This
information is maintained in the TCA Registry, which is the single source of trading community
information for Oracle E-Business Suite applications. These applications, as well as TCA itself, provide
user interfaces, batch data entry functionality, and other features for you to view, create, and update
Registry information.

In doing so, it provides the following benefits:

 Provides a foundation for a single source for customer information.

 Represent all trading partners as a “Party” (organizations, people, groups, relationships) and
allows them to be managed the same way.
 Enables many-to-many relationships, thereby reducing data duplication and simplifying data
maintenance.
 Supports unlimited classifications for reporting purposes.
 Establishes an extensible data model to support various business data requirements.

BPI will utilize TCA information during Accounts Receivable and Order Management processes to
house customer information. While customers can be defined and maintained in both modules, BPI
customer maintenance will be owned exclusively by the Accounts Receivable group.

Three entities drive in the TCA model: Party, Account, and Relationship.

Party
A Party is a trading partner that can enter into a business relationship with BPI, and can be of three
types.

 Person - A unique individual of interest to BPI.

 Organization - A legal entity recognized by some government authority.
 Group - A combination of two or more people, organizations or groups

Account
An account represents the financial portion of a party’s purchases and payments, and stores details
about a relationship between a party and BPI. A party may have one or more accounts. The account
also maintains information about the terms and conditions of doing business with the party, along with
attributes such as contacts, bank accounts, payment methods, telephone numbers, and relationships
for each account.

537521414.docx August 21, 2013 Page 30 of 113

 BPI Solution Design Document

Relationship
A relationship represents the type of business relationship that a party can enter in to with another
party. It supports multiple relationships with accounts for a trading partner that transacts business in
more than one capacity.

Context Diagram

Party
Group Party Person Party Organization
Party

Location
Party Party
Person Relationship
Profile Type

Party Site Organization

Party
Profile

Party
Relationship
Customer
Account
Organization
Account Person
Contact Point Relationship
Type
Telex Number

URL
Account Relationship
Phone Contact

EDI Contact
Customer Account Site
eMail Contact

BPI Customer Hierarchy

BPI will utilize customers, sites and relationships to represent its business relationships with customers.

Customers will be created for independent/stand-alone customers as well as customers that are
members of buying groups. Buying groups themselves will also be created as customers.

Customer sites, which are each associated with one customer, will be created to reflect Bill-To and/or
Ship-To addresses.

Customer relationships will be defined to reflect real-world relationships between customers.

Relationships grant authority for one customer to perform actions for another customer, such as one
customer handling the billing for another, or allowing one customer to pay for another. Relationships
will allow BPI to support the needs of buying groups and customers with multiple stores. Relationships
will be defined after customer records have been converted.

Orders

537521414.docx August 21, 2013 Page 31 of 113

 BPI Solution Design Document

The Sales Order Workbench will be used to enter, view and update sales orders and returns. The
workbench supports orders for standard items, both shippable and non-shippable, and configurations.
It can be used to adjust pricing, assign sales credits, record payment information, attach notes,
schedule shipments, query item availability, and make reservations, including selection of sub-
inventories.

When orders are booked, Order Management performs validation to ensure the order is complete (e.g.
all required fields have been entered, configurations are complete). After an order has been booked, it
becomes eligible for the next step in the order-to-cash workflow unless a hold has been applied. Holds
may be applied for a variety of reasons, such as a price change, and will need to be addressed before
an order can proceed in the workflow.

Drop shipments, which are designated by the order source type, determine whether an order will be
fulfilled from inventory or directly from one of BPIs manufacturing locations.

Orders reference customers maintained in TCA (ship-to and bill-to locations), price lists maintained in
Advanced Pricing and items maintained in Inventory.

Context Diagram

537521414.docx August 21, 2013 Page 32 of 113

 BPI Solution Design Document

Pricing

BPI employs a variety of pricing, discount and rebate strategies that exceed the capabilities of the
Order Management module. To address this gap, Oracle Advanced Pricing will be utilized to maintain
BPIs price lists and price-related rules.

Oracle Advanced Pricing supports Order Management by providing a pricing engine that executes
pricing and promotional calculations.

The pricing engine receives transaction information from Order Management, prepares pricing
requests, selects price lists and modifier lists, and applies price adjustments to the transaction. The
pricing engine evaluates the following questions to determine a price:

1. Who qualifies for prices and benefits?

2. What’s the product hierarchy and what pricing attributes pertain to an item or service?
3. How should the order price or order line price be adjusted?

The pricing engine uses four primary components to determine a price: Price lists, Modifiers, Formulas
and Qualifiers.

Price lists consist of a header, that defines general information such as effective dates and currency,
and lines that define item and/or item category prices. Due to their size and complexity, BPI will load
price lists from Excel using an extension to standard Oracle functionality.

Modifiers consist of price adjustments (e.g. discounts, surcharges), benefits (e.g. free goods, coupons),
freight and special charges that can be applied immediately to pricing requests or accrued for later
disbursement.

Formulas consist of mathematical expressions that can be utilized to calculate the list prices of items
and discounts applied to them, and can be linked to a price list line or modifier line.

Qualifiers consist of eligibility rules governing who can receive a particular price, discount, promotion, or
benefit.

537521414.docx August 21, 2013 Page 33 of 113

 BPI Solution Design Document

The pricing engine:

1. Prepares the price request structure

Order management submits price requests, which the pricing engine configures into a pricing
request structure. The pricing request structure provides information about all the qualifiers and
product pricing attributes.
2. Selects applicable price lists and modifier lists
This function selects which price lists are eligible for the current pricing request. It uses the
qualifiers and pricing attributes to select an eligible list of prices or modifiers that it can apply to
the pricing request lines according to the certain rules.
3. Determines base list price
This function takes the validated price list lines and applies them to the pricing request lines.
The list price on a price list can be specified as unit price, percent price, or formula.
4. Applies benefits and adjustments (from modifier lists) to list price to determine the sales price.
This function takes the validated modifier list lines and applies them to the pricing request lines
to provide price adjustments, such as discounts, price breaks, surcharges, coupons, item and
term substitutions, and other item discounts. Discount and surcharge modifiers affect the selling
price; freight charge modifiers do not affect the selling price.
5. Calculates the final selling price

Context Diagram

537521414.docx August 21, 2013 Page 34 of 113

 BPI Solution Design Document

Process Flow

Order Fulfillment/Other Pricing Application

Build Qualifier Hierarchy, Product Hierarchy, Derive Attribute

Values

Pricing Request

Engine Setup

Price Lists
Select Eligible Lines

Modifiers

Evaluate Incompatibility
Formulae

Qualifiers
Fetch Modifier Details

Products

Calculate Price
Pricing Attributes

Return List Price and Adjustments

Touch Points

Source Destination Description

Excel Advanced Pricing Price lists
Order Management Advanced Pricing Pricing request
Advanced Pricing Order Management List price & adjustments

See BR01 – OM Requirements BPI, CS01 – OM Setup Configuration Document for detailed design
information.

537521414.docx August 21, 2013 Page 35 of 113

 BPI Solution Design Document

Shipping

The Shipping Execution module will be used to manage shipping related information and create
shipping transactions. Once inventory orders reach ‘awaiting shipping’ status in Order management,
they become available for shipping in Shipping Execution.

Trip and Delivery Planning will be used to create trips and deliveries, assign delivery lines to a delivery
or a container and schedule pick-ups and drop-offs.

Pick Release will be used to release eligible delivery lines based on defined picking criteria, select the
Release Sequence Rule to control the order in which picking lines are allocated to inventory and enter
or validate shipped quantities, back ordered quantities, staged quantities, and inventory control
information for delivery lines (after pick release).

Pick Wave Move Orders are generated into the Inventory module. The Oracle Shipping Execution pick
release process generates a Pick Wave Move Order to move the material from its source location to the
Staging sub-inventory. In effect, this is a sub-inventory transfer through a pre-approved and ready to
transact move order.

Ship Confirm will be used to assign delivery lines to trips and deliveries, auto-create a trip and close
stops and confirm or back order a delivery.

Ship Confirm process calls two interfaces, which are invoked by the Invoice Interface workflow.
1. INV: Inventory release/trip interface (COGS is subsequently sent to the General Ledger from
Cost Management).
2. AR: Invoices and Credit Memos are sent to the AR interface tables.

Context Diagram

537521414.docx August 21, 2013 Page 36 of 113

 BPI Solution Design Document

Process Flow

Shipping
Accounts Receivable

AutoInvoice End
Order Management

Order Entry &

Start Close Line
Booking

Release Sales
Pick Confirm Ship Confirm
Order
Shipping

Release to Move Order

Packing
Warehouse Transactions

Touch Points

Source Destination Description

Order Management Shipping Execution Inventory orders
Shipping Execution Accounts Receivable Invoices (inventory orders)
Order Management Accounts Receivable Invoices (invoice only)
Order Management Inventory Pick move orders

See X, Y and Z for detailed design information.

537521414.docx August 21, 2013 Page 37 of 113

 BPI Solution Design Document

Sales Accounting

Shipping tasks are executed as part of Order Management and Shipping Execution. However, the
functions to generate the Cost of Goods Sold accounting entries are driven by Inventory and Cost
Management, and the functions to drive Revenue are performed within Accounts Receivable (via Sub
Ledger Accounting). No accounting transactions flow from Order Management to General Ledger.

When one or more order lines are ship confirmed in Order Management, information regarding the
shipped quantity is passed to the Inventory module. The data passed to Inventory includes the shipped
quantity, shipped date, picking information etc. At the time of shipment, the journal entries related to
Inventory use a pre-defined Deferred COGS account.

When Oracle Receivables recognizes all or part of the sales revenue associated with a sales order line,
a set of processes in Cost Management compares the COGS recognition percentage for each sales
order line and accounting period combination to the current earned revenue percentage. When the
compared percentages are different, the process raises a COGS recognition event and creates a
transaction adjusts the ratio of earned and deferred COGS to match that of earned and deferred
revenue. The proportion of total shipment cost that is recognized as COGS will always match the
proportion of total billable quantity that is recognized as revenue.

Context Diagram

537521414.docx August 21, 2013 Page 38 of 113

 BPI Solution Design Document

Touch Points

Source Destination Description

Order Management Shipping Execution Inventory orders
Shipping Execution Accounts Receivable Invoices (inventory orders)
Order Management Accounts Receivable Invoices (invoice only orders)
Shipping Execution Inventory Shipments
Inventory Cost Management Inventory sales
Cost Management General Ledger Journal entries
Accounts Receivable General Ledger Journal entries

See BR01 – INV Requirements BPI, BR01 – OM Requirements BPI, CS01 – INV Setup Configuration
Document, CS01 – OM Setup Configuration Document for detailed design information.

537521414.docx August 21, 2013 Page 39 of 113

 BPI Solution Design Document

Invoicing

Orders and returns processed by BPI impact company revenue, receivables, COGS and cash. In order
to ensure these accounts are correctly stated, a consolidated view of the financial impact of
transactions originating from Order Management is maintained by Accounts Receivable in conjunction
with Cost Management.

The Accounts Receivable module is Oracle’s platform for managing company revenue and receivables
and generating associated journal entries. It also supports the invoice processing, cash application and
collections activities for company-wide AR activities (including those originating in Order management).

Invoice processing in Order Management is the process by which data from Orders and Returns are
interfaced to Oracle Receivables for the creation of invoices and credit memos to recognize revenue
and manage sales credits. Invoice processing is implemented as a periodically-scheduled workflow
activity (Invoice Interface). The Invoice Interface activity collects order, return, and freight charges
information from Order Management tables and transfers them as lines to Oracle Receivables via an
interface table.

Lines from the interface table by Accounts Receivables by a program called AutoInvoice. Order
Management does not pass account distribution data. Accounts Receivable has another interface table
which can optionally be used to specify revenue account distributions. If a distribution is not provided for
an invoice line, AutoInvoice provides a default distribution account and applies it to the transaction line.

Accounts Receivable users can review the data in the interface tables, and identify any errors that
prevented interfaced invoices or credit memos from being processed (e.g. a transaction falling in a
closed period or a currency being referenced for which a conversion rate is not defined).

Context Diagram

537521414.docx August 21, 2013 Page 40 of 113

 BPI Solution Design Document

Process Flow

Invoice & Credit Memo Generation

Order Management

Start Order Entry Book Order Invoice Only?

No

Yes
Shipping Execution

Ship Confirm

Transfer
Oracle

Invoices to
AR Interface
Tables
Accounts Receivable

Submit Review & Correct

End
AutoInvoice Rejections

Touch Points

Source Destination Description

Order Management Shipping Execution Inventory orders
Shipping Execution Accounts Receivable Invoices (inventory orders)
Order Management Accounts Receivable Invoices (invoice only)

See BR01 – OM Requirements BPI, BR01 – AR Requirements BPI, CS01 – OM Setup Configuration
Document, CS01 – AR Setup Configuration Document for detailed design information.

537521414.docx August 21, 2013 Page 41 of 113

 BPI Solution Design Document

Standard Returns

Background

When a customer returns a product using a Return Material Authorization (RMA), it is received and
restocked using the inventory module, and refunded using a Credit Memo in Accounts Receivable.

When the RMA is entered in Order Management and booked, it is made visible to the receiving clerks in
the warehouse (expected quantity to receive, RMA number, Item ID, etc.)

Items are returned into Inventory using the Purchasing Receipts window. Oracle Purchasing
communicates quantities received in this window to Order Management. Entries in this window affect
the order lines in Order Management. If any partial amount of the returning quantity is accepted, Order
management splits the lines into one part that is fully received and one part that is not. When the full
returning quantity is accepted, the remaining line is then fulfilled.

The COGS Account Generator process is called when the item is received into inventory via the
Receipts Form. The COGS Account Generator derives the General Ledger account ID. When the RMA
references a Sales Order, an attempt is made to derive the COGS Account from the sales order
information and not the RMA information.

Order Management interfaces Credit memo lines to Oracle Receivables for any returns that include the
seeded Invoicing activity for the Order Lines workflow. Upon completion of the Invoicing Activity, the
AutoInvoice process imports the data into Oracle Receivables.

Context Diagram

537521414.docx August 21, 2013 Page 42 of 113

 BPI Solution Design Document

Touch Points

Source Destination Description

Order Management Shipping Execution Inventory orders
Shipping Execution Accounts Receivable Invoices (inventory orders)
Order Management Accounts Receivable Invoices (invoice only)

See BR01 – OM Requirements BPI, BR01 – AR Requirements BPI, CS01 – OM Setup Configuration
Document, CS01 – AR Setup Configuration Document for detailed design information.

537521414.docx August 21, 2013 Page 43 of 113

 BPI Solution Design Document

Subsystem Design – BPI Specific Design Components

Check Fill Percent

Many BPI customers have order fulfillment rate targets as part of their service level agreements. Rate
targets vary across customers, but a single rate applies to all applicable orders for that customer. BPI’s
goal is to fulfill each order at, or above, the target percentage for a given customer.

An Oracle extension to standard functionality, together with standard configuration elements, will be
used to place holds on orders where the target fill percentage is not met.

If there is a fulfillment target is defined for a customer, and the order type is subject to fulfillment rate
targets, the Oracle extension will check the reservations and availability. If the total of the reservations
and availability equal or exceed the fulfillment target, the order will be booked. If not, a ‘Fill Target
Violation’ hold will be placed on the order, unless it has already had a ‘Fill Target Validation’ hold
applied and released.

See BR01 – OM Requirements BPI, FSE12 – OM Check Fill Percentage and CS01 – OM Setup
Configuration Document for detailed design information.

Container Quantities
BPI’s customers can receive discounts and/or additional rebates for ordering a full container at a time.
Usually, the container is sent from the manufacturing sites, in either China or India, directly to the
customer or their agent.

In order to receive any ‘container’ discounts, the items in the container 1) must be ordered in a full or
half pallet quantity and 2) must fill the container (full pallet + half pallet count must equal 20 full pallets).

The container orders may be imported electronically or entered manually. These orders will be treated
as ‘dropship’ orders in Oracle. A purchase requisition is automatically created for dropship orders when
they are booked. The buyers take the requisition and create a purchase order for the items. These
purchase orders are created for a dummy ‘dropship’ warehouse (as specified on the order). When a
shipping notice is received, someone must receive the shipped quantities into the dummy warehouse.
An ASN is sent to the customer, along with the pallet barcodes. The receipts are also used in place of
ship confirmations to generate the invoice.

An Oracle extension, implemented via a custom concurrent process, to standard functionality, together
with standard configuration elements, will be used to place a ‘Container Pallet Violation’ hold on orders
where the total order quantity does not amount to a full container. Orders that have already had the
‘Container Pallet Validation’ hold applied and released will not have it applied again.

If an order is placed on ‘Container Pallet Violation’ hold, the user can a) simply release the hold and
rebook the order, allowing the entered quantities even though the order is not for a full container or b)
add items to the order, manually release the hold after the order quantities will fill the container, and
rebook the order.

537521414.docx August 21, 2013 Page 44 of 113

 BPI Solution Design Document

The customers that can have multiple orders in one container will see all those orders go on hold. The
holds must be released manually after someone makes sure the container is full.

NAPA and CARQUEST can submit multiple orders to fill a container. In this scenario, the container will
be shipped to a common DC and be distributed from there. These orders will be entered under an
order type (Family Pallet) that is not identified as a container order. These are automatically passed to
requisitions and should be grouped together manually to create a full container.

See BR01 – OM Requirements BPI, FSE13 – OM Container Quantities and CS01 – OM Setup
Configuration Document for detailed design information.

Days on Hold
Holds may be placed on orders for a variety of standard and BPI-specific reasons. For example, an
order exceeds an order limit, a customer has been placed on credit hold, or a ‘Container Pallet
Violation’ or ‘Container Pallet Violation’ hold has been placed. To ensure that orders that have been
placed on hold are not overlooked, BPI requires a mechanism to notify customer service if orders have
been on credit hold for a specified number of days.

To accommodate this requirement, an Oracle extension to standard functionality, implemented via a

custom concurrent process and standard configuration elements, will be used to generate and send an
email alert to Customer Service when predetermined conditions have been met.

Two BPI-specific (descriptive flex-) fields will be created for each hold type: ‘Escalate At’ and ‘Escalate
To’. The ‘Escalate At’ field will allow a threshold (number of days) to be specified for how long an order
may remain on that hold type prior to an alert being generated. The ‘Escalate To’ field will allow an
Oracle responsibility to be identified; when an escalation alert is generated, all users who have been
granted that responsibility will receive the alert. Each hold type may have different values set for the
two BPI-specific (descriptive flex-) fields.

All on-hold orders will be checked daily by the custom concurrent process to identify any that have a
hold with the two fields populated. The system will compare the current date to the date the order was
created. If an on-hold order has a hold with both ‘Escalate At’ and ‘Escalate To’ set, the current date
will be compared to the order creation date. If the difference in the dates equals or exceeds the
‘Escalate At’ value, an alert will be e-mailed to all the users granted the responsibility specified in the
‘Escalate To’ field. Alerts will be sent anytime an order meets the criteria. Hence, an order past the
escalate date will trigger an e-mails every day until the hold is released.

See BR01 – OM Requirements BPI, FSE14 – OM Days on Hold and CS01 – OM Setup Configuration
Document for detailed design information.

Free Freight Minimums

Some BPI customers are eligible to receive free freight on any standard order if the total order value is
at or above a minimum set for them. For some customers, that minimum can vary for certain orders
(jobbers).

537521414.docx August 21, 2013 Page 45 of 113

 BPI Solution Design Document

The freight terms will default to the order based on the defaulting rules and the customer/order setup. If
a customer is subject to the free freight minimums, that customer’s orders will be set to default to ‘free
freight’. The ‘Free Freight Minimums’ extension will then check the order and it will be put on hold if it
does not reach the minimum value.

To accommodate this requirement, an Oracle extension to standard functionality, implemented via a

custom concurrent process and standard configuration elements, will be used to place holds on orders
from customers that are subject to free freight but which do not meet the qualifying minimum order
amount that qualifies.

The concurrent process will check the order value when the user/system books the order. A hold will
be placed on the order if 1) the freight terms on the order are identified as ‘free freight’, 2) the customer
is subject to free freight minimums, 3) the order does not meet the minimum order value required for
free freight and 4) the order has not been on ‘Frt Minimum Violation’ hold before.

The minimum for free freight is found by looking at the order header for a jobber code. If the jobber
code is found, the minimum set for that jobber code is used. If there is no jobber code on the order,
then the minimum from the customer is used. If there is no minimum set for the customer, then the free
freight hold is not applied.

If an order is placed on ‘Frt Minimum Violation’ hold, the user can a) simply release the hold and allow
the free freight even though the order does not meet the required minimum value specified for the
customer, b) change the freight terms to something other than free freight (prepaid) and release the
hold, or c) add items to the order and manually release the hold after the order value is above the
minimum. After releasing the hold, the order must be re-booked.

Certain customers are allowed to ‘spread’ the minimum value across multiple orders. All these orders
will go on hold and the users will be responsible for determining if the total value exceeds the minimum.
If so, the user simply releases the holds and rebooks the order. If not, the freight terms can be reset
appropriately before the holds are released.

See BR01 – OM Requirements BPI, FSE15 – OM Free Freight Minimums and CS01 – OM Setup
Configuration Document for detailed design information.

Release Backorders
BPI has a requirement to ship backorders when they can be shipped with a new order. To that end, all
backorder lines will be placed on hold and those holds will need to be released automatically when
there is a new order for the same ship-to, from the same warehouse, and there is inventory available for
the backordered item.

To accommodate this requirement, an Oracle extension to standard functionality, implemented via a

custom concurrent process and standard configuration elements, will be used to release backorder
holds on order lines when the above conditions are met. The concurrent process will check all
unreleased backorder holds. If any of the held lines have corresponding new orders, the new order has
the same ship-to and ship-from and there is available inventory for the held line, the hold will be
released.

537521414.docx August 21, 2013 Page 46 of 113

 BPI Solution Design Document

See BR01 – OM Requirements BPI, FSE16 – OM Release Backorders and CS01 – OM Setup
Configuration Document for detailed design information.

Use Membership Number

BPI customers may belong to two or more buying groups. Oracle requires a Sold-To customer, a Ship-
To address and a Bill-To address for an order to be placed. For BPI’s Oracle implementation, the Sold-
To customer will be defined as the buying group, which will hold the pricing data, fill rates, and the item
cross references.

Customers typically provide their buying group membership number to identify themselves when
placing an order. Since the membership number has been used for so long, requiring users to enter
the buying group would necessitate manual research to enter it on the order.

To avoid adding a manual step to the process, an Oracle extension to standard functionality,
implemented via a custom concurrent process and standard configuration elements, will be used to
identify the customer information from the membership number, which will be entered into a Descriptive
Flex-Field. The concurrent process will use a membership number to identify and populate the correct
Sold-To customer and Ship-To location automatically. The Bill-To location will be determined by the
Ship-To location. The ‘Backorders Allowed’ flag that is set on the Sold-To customer will be copied onto
the order so that it can be set at the order level.

If a membership number is duplicated under two different buying groups, the user will need to select the
correct store from the list.

If the membership number is changed and the order is in the entered status, reset the Sold-To
customer, Ship-To location and ‘Backorders allowed’ flag will be reset.

See BR01 – OM Requirements BPI, FSE17 – OM Use Membership Numbers and CS01 – OM Setup
Configuration Document for detailed design information.

Mailing Subscription
BPI needs to maintain a list identifying the parties (people and companies) that want new versions of
their publications (catalogs, price sheets, etc.) as they become available. BPI uses the list to create
mailing labels for all these parties, which specifying the publications and the quantities of each that
each party has requested.

To accommodate the requirement, a unique price list will be created called ‘Mailing Subscriptions’. It
will be used to maintain the subscription information in Oracle, but will be secured so only a few people
have access to it an inactive so it won’t appear alongside active price lists elsewhere in Oracle.

Lines will be added to the price list for each combination of publication and customer address. Each
publication will be identified as a separate Category. The price on the line will be used to identify the
quantity of the publication a particular customer wants to receive, and a descriptive Flex Field on the
price list line will store the name that will appear on the mailing. The price list will be linked to an
address on the customer record; If the mailings go to an existing ship-to or bill-to address, it will be

537521414.docx August 21, 2013 Page 47 of 113

 BPI Solution Design Document

used, but if the mailings go to a different address, it will need to be created (and identified as a
marketing address) on the customer record prior to it being referenced on the Mailing Subscriptions
price list.

A custom concurrent process will be created to print labels in two formats. One label will print for any
address that has a new version of any of the specified publications. For example, if new versions of
three different catalogs and one address subscribes to all of them, only one label will be printed. Both
label formats will show the items and quantities.

See BR01 – OM Requirements BPI, FS02E7 – QP Mailing Subscription and CS01 – QP Setup
Configuration Document for detailed design information.

Ship-To

BPI Customer Service has traditionally identified customers by their customer number. As part of the
conversion into Oracle, customers will be structured using Trading Community Architecture (TCA) and
will have new numbers assigned. Additionally, another layer (the buying group) will placed above the
customer in the SA hierarchy. In standard Oracle order entry forms, that buying group is needed before
a ship-to customer can be identified. Customer service will not necessarily know the buying groups for
all their ship-to customers, so an extension will be developed to default the buying group from the ship-
to customer that is entered for an order.

See BR01 – OM Requirements BPI, FSE32 – OM Ship-To and CS01 – OM Setup Configuration
Document for detailed design information.

Off-List Price Hold

BPI has a requirement to be able to change an item price from that on the list price. In Oracle, this can
only be accomplished by changing the price list on the order line to one that allows manual pricing.
However, when this scenario occurs, the order must go on hold for pricing approval.

To accommodate this requirement, an extension will be developed to place a hold on orders where any
lines have had list prices overridden.

See BR01 – OM Requirements BPI, FSE34 – OM Off-List Price Hold and CS01 – OM Setup
Configuration Document for detailed design information.

Default Country of Origin

An items country of origin (COO) must be printed on shipping labels and associated shipping
documents for many international shipments. To accommodate this requirement, the primary COO,
which will be stored on the item, will be defaulted to the delivery detail record. If necessary, it can then
be changed if a picked item was not from the default COO. The extension will mimic BPIs legacy
business process.

537521414.docx August 21, 2013 Page 48 of 113

 BPI Solution Design Document

See BR01 – OM Requirements BPI, FSE44 – OM Default COO and CS01 – OM Setup Configuration
Document for detailed design information.

Dropped Not Shipped Report

The “Dropped, not Shipped” report will show orders that have been pick released, but not ship
confirmed. Parameters will allow it to be run for any warehouse.

See BR01 – OM Requirements BPI, FSR40 – OM WSH Dropped Not Shipped Report and CS01 – OM
Setup Configuration Document for detailed design information.

Check Harmonized Code

BPI needs to track the harmonized code and tariff treatment for internationally shipped items. Both
attributes will be maintained using price lists. If neither attribute is known for an international shipment,
it will be held and the issue addressed prior to shipment to avoid subsequent holds at the border

In order to meet this requirement, an extension will be developed to verify that the necessary
information is available, and place a hold if it is not.

See BR01 – OM Requirements BPI, FSE31 – OM Check Harmonized Code and CS01 – OM Setup
Configuration Document for detailed design information.

Reset Request Date

Some customers use a default number of days to calculate order lead times, rather than providing a
request date in each order.

In order to accommodate both order-specific and customer-specific defaults, an extension will be

developed to determine the request date if it is not provided.

See BR01 – OM Requirements BPI, FSE53 – OM Reset Request Date and CS01 – OM Setup
Configuration Document for detailed design information.

Reset PO Numbers

Some customers reuse PO numbers. Duplicate PO numbers for a vendor are not allowed in Oracle as
they would compromise the integrity of the system. In order to accommodate duplicate PO numbers, a
customer extension will be developed to ’reset’ existing PO numbers for a vendor by adding a suffix,
thus making the new PO with a re-used PO number unique.

See BR01 – OM Requirements BPI, FSE54 – OM Reset PO Numbers and CS01 – OM Setup
Configuration Document for detailed design information.

537521414.docx August 21, 2013 Page 49 of 113

 BPI Solution Design Document

Pick Slip Report

The standard Oracle Pick Slip Report does not provide the sequencing or information necessary for BPI
to maintain their existing level of optimization during the picking process. In order to overcome this
limitation, a custom version of the Pick Slip Report will be developed to replicate BPIs existing report.

See BR01 – OM Requirements BPI, FSR52 – WSH Pick Slip Report and CS01 – OM Setup
Configuration Document for detailed design information.

Cash Application

BPI customers submit combined payments for multiple invoices. Payments are typically remitted as a
result of a Statement rather than an individual invoice.

The current lockbox process does not support automated cash application against multiple (identified)
invoices. The file generated by JP Morgan contains one invoice number for each customer payment.
Customers send a separate remittance advice via EDI or Excel, which is uploaded to match payments
to individual invoices. The remittance advice can contain more than 7000 lines.

The standard Oracle lockbox import process will be used to import the file. The import step will
populate a standard interface table.

A custom lockbox matching rule will be defined. The custom lockbox matching rule will be specified in
the customer profile in the lockbox matching option field.

The standard Oracle lockbox process contains an extension (hook) that gets called when custom
matching rules exist. The extension will be modified to process based on the custom matching rule.
A second custom process will be created to process the remittance files received. The process will
load the remittance information into a custom table. The process will need to be able to import two
different file layouts. The first is the EDI format provided by NAPA and GM/AC Delco. The second
format will be a comma delimited text file that will be generated from the Excel remittance information
received by BPI.

The custom process will have parameters to allow users to specify the customer numbr, receipt
number, and the data file name to import. The customer number and receipt number will be used to
link the data file to the receipt record in the interim cash receipts table.

The lockbox extension will then create the detailed application records for the receipt from the data in
the custom table. If the receipt detail does not exist in the matching table, the process should return an
exception for that receipt.

After the Lockbox process is run, users will be able to review the receipts using the Quickcash form.
When the remittance information is processed for all receipts in a batch, the user will post the batch.
The posting process will update customer’s account and close all the paid invoices.

537521414.docx August 21, 2013 Page 50 of 113

 BPI Solution Design Document

Process Flow

BPI – Proposed Oracle Lockbox Processing

Customer

Send Send
Generate
Payment for Remittance
Payment
Processing Information

Process
Payment
Bank

Generate
Lockbox
Payment File
IT Operations

Retrieve file,
place on
server

Load
Place
Format Remittance
remittance file
remittance file Info to
on
custom table
AR/Credit

Custom matching looks at data in custom table

Lockbox Submit
Import executes Validation; Review
Post Batch
Lockbox File custom Create applications
matching rule Interim Rcpt

See BR01 – AR Requirements BPI, FSI05 – AR Lockbox Interface, CS01 – AR Setup Configuration
Document for detailed design information.

Tronitec Interface

BPI utilizes third parties (Tronitec and LKCS) to print, mail and image invoices. Tronitec performs the
imaging process, then passes information to LKCS for printing and mailing. In order to continue this
process once oracle is implemented, a custom program will be developed to extract invoice information.
The files it creates will be sent to Tronitec, and subsequently to LKCS.

See BR01 – AR Requirements BPI, FS01I 04 – AR – Invoices to TroniTech and CS01 – AR Setup
Configuration Document for detailed design information.

537521414.docx August 21, 2013 Page 51 of 113

 BPI Solution Design Document

Aging by Sales Channel Report

BPI records a journal entry each month to accrue for customer payment discounts. In order to generate
the information necessary to create the journals, an aging report is required by sales channel, which is
not a standard Oracle report.

In order to accommodate this requirement, a custom aging report will be created, which will be based
upon the standard report.

See BR01 – AR Requirements BPI, FSR31 – Aging by Sales Channel Report and CS01 – AR Setup
Configuration Document for detailed design information.

537521414.docx August 21, 2013 Page 52 of 113

 BPI Solution Design Document

Procure-Pay Design

Description

The Procurement modules consist of Purchasing, Inventory and Accounts Payable. Together, they
support the following business processes:

Module Business Processes

Purchasing Requisitions, purchase orders, receipts
Inventory ABC analysis, cycle counting, physical inventory, replenishment planning,
receiving, item definition and maintenance, miscellaneous transactions,
consignment
Cost Management
Accounts Payable Supplier maintenance, invoice processing, payment processing, 1099
reporting

Financial transactions will flow into the General Ledger from the Procurement, Inventory and Accounts
Payable sub-ledgers via standard system interfaces.

The majority of requisitions will be generated from the Inventory module via the inventory replenishment
process. A combination of planning and replenishment features, including min-max planning and
reorder point planning will be utilized at BPI.

537521414.docx August 21, 2013 Page 53 of 113

 BPI Solution Design Document

Process Flow

Procure-Pay Level 1 Process Flow

Suppliers

Accept Order Fulfill Order Bill Customer Receive Payment

Warehouse

Requisition
Goods or
Services
Accounts
Payable

Invoice Payment
End
Processing Processing
Purchasing

Order Goods
Receiving
or Services
Inventory

Item Inventory
Inventory Physical
Start Definition & Replenishme Consignment ABC Analysis Cycle Count
Transactions Inventory
Maintenance nt Planning

537521414.docx August 21, 2013 Page 54 of 113

 BPI Solution Design Document

Touch Points

Source Destination Description

Purchasing Accounts Payable Purchase orders and receipts
Purchasing Inventory Receipts
Inventory Purchasing Requisitions, inter-org shipments
Inventory WIP Items, inventory balances, transactions
WIP Purchasing Outside processing requisitions
Cost Management Purchasing Standard costs
Engineering Purchasing Resources
Order Management Inventory Shipments, reservations, demand
Inventory Order Management On-hand quantity, available to order
Inventory Cost Management Transaction rates
Cost Management Inventory Costs
Inventory BOM Items
Engineering Inventory Engineering items
Inventory Engineering Items
Accounts Payable General Ledger Journal entries
Cost Management General Ledger Journal entries
Accounts Payable Cash Management Payments
Accounts Payable Fixed Assets Asset-related expenditures
Supply Chain Purchasing Requisitions
Planning

537521414.docx August 21, 2013 Page 55 of 113

 BPI Solution Design Document

Data Conversion

Suppliers
Supplier information (including sites and contacts) will be converted from several source legacy
systems (Central AP/CAP, TOLUS and BPICS). CAP, which stores pay sites, will be used as the
conversion master. All active suppliers in CAP, which will include those referenced by open invoices,
purchase orders and requisitions, will be included in the conversion. Purchasing sites from TOLUS and
BPICS will be added to the conversion file prior to the upload into Oracle.

Supplier Banks
Supplier banking information to support ACH payments will be converted from the Oracle R12
Payments-Only System, where it exists, for suppliers included in the initial supplier conversion.

On-Hand Balances
On hand stock balances will only be converted. The inventory on-hand stock balances will be loaded at
the end of the last inventory period. The items will be loaded into the corresponding sub-inventory,
according to the final sub-inventory mapping.

Item UOM Conversions

Item UOM Conversions will be loaded into Oracle Inventory as part of the initial conversion process.
from legacy applications. Intra-class conversion will define a conversion for a specific item within a unit
of measure class; Inter class conversion will define a conversion for a specific item between unit of
measure classes.

Items
The item conversion will reference a pre-defined item template for each item. The item template will
standardize the item setup in Oracle and allow default attribute values to be defined. Item attributes that
cannot be defined within item templates will be included in the item conversion data.

Item Costs
Frozen item costs for Buy items will be converted into Oracle Inventory. Data archival reports will be
run just before extract from BPI legacy system. Dirty core items in CHW will have the material cost
converted into the CORE material sub-element

Item Cross-Reference
For Chowchilla Core Returns, a cross-reference is required to determine what core/bracket is returned
to inventory when a customer returns a caliper (the customer returns the core, but for Oracle RMA
purposes the caliper item number will be entered). A core returns cross reference will be configured to
support business requirement; cross reference information will be loaded as part of the initial
conversion process.

Item Transaction Defaults

Item Transaction Defaults will be loaded into to Oracle Inventory as part of the initial conversion
process. For each item transaction default type (receiving), an item can have only one value
Convert receiving item transaction default; For the DC’s, this value will be subinventory = DOCK and
locator = DOCK and for Stanford and Chowchilla , the value will need to be defined in the source data.

537521414.docx August 21, 2013 Page 56 of 113

 BPI Solution Design Document

Item Primary Pick Location

This functional specification addresses the requirement to convert The item primary pick location will be
loaded into Oracle Inventory as part of the initial conversion process; BPI needs to default and print the
primary pick location of the item for several inventory related transactions and reports.

Requisition Template
Once indirect items and associated suppliers have been converted, requisition templates will be loaded
into Oracle Purchasing as part of the initial conversion to facilitate the PO creation process.

Open Purchase Orders

Purchase Order (PO) conversion will include all open (not received and not invoiced) purchase orders.
Converted POs will include production items and MRO items. All converted POs will be automatically
approved in Oracle as part of the conversion process.

Blanket Purchase Agreements

Blanket Purchase Agreements (BPAs) will be used to reflect existing PO price lists. BPAs will be
created for production items as well as any converted MRO items. All BPAs will be automatically
approved in Oracle as part of the conversion process. Converted BPAs will not have any price breaks
The BPA conversion will be comprised of two source files: One for existing PO price lists and the
another file for consignment items.

Approved Supplier List

The Approved Supplier List (ASL) associates items and services with the companies who supply them.
Once items, suppliers and blanket purchase agreements have been converted, the ASL will be loaded
as part of the initial conversion process.

Open Invoices
All open invoices (unpaid or partially paid invoices with a remaining balance) will be converted from
Central AP/CAP. Payments will not be moved forward into Oracle as part of this conversion. Any
partially paid invoices will be fully paid from Central AP/CAP and Oracle R12 Payments-Only prior to
conversion. Pre-payments will be documented off-line and manually entered into Oracle.

Employees
To facilitate procure-pay, plan-build, order-cash and financial management processes, it’s necessary to
convert employee data. Oracle Purchasing uses employee data for purchase order approvals and to
establish buyer information. Oracle Payables use employees as a reference on expense reports and to
create suppliers for reimbursements.

See CV01 Data Conversion Strategy and Overview, FS01C – INV Item UOM Conversion, FSC02 – AP
Open Balances Conversion BPI, FSC03 – AP Supplier Conversion BPI, FSC11 – INV Consigned Item
On-Hand Conversion, FSC13 – INV Item Costs, FSC14 – INV Item Cross Reference, FSC15 – INV
Item Primary Pick Location, FSC16 – INV Item Transaction Defaults, FSC17 – INV Item Conversion,
FSC27 – PO Approved Supplier List, FSC28 – PO Blanket Purchase Agreements, FSC29 – PO Open
Purchase Orders, FSC31 – PO Requisition Template for detailed business requirements and solution
design.

Security

537521414.docx August 21, 2013 Page 57 of 113

 BPI Solution Design Document

Procure-pay security will be managed using custom responsibilities. Users are granted access to one
or many responsibilities. Responsibilities provide all users with the same level of functional access as
each responsibility is configured to allow access to specific system functions. Some responsibilities will
be based upon standard (seeded) Oracle responsibilities, but custom versions will be created in order
to support future maintenance and enhancements.

Purchasing

Responsibility Description Audience

BPI PO XXXXXX Ability to…
BPI PO XXXXXX Ability to…
BPI PO XXXXXX Ability to…

See SM01 BPI PO Responsibilities for detailed security design.

Inventory

Responsibility Description Audience

BPI INV XXXXXX Ability to…
BPI INV XXXXXX Ability to…

See SM01 BPI INV Responsibilities for detailed security design.

Cost Management

Responsibility Description Audience

BPI CST XXXXXX Ability to…
BPI CST XXXXXX Ability to…

See SM01 BPI CST Responsibilities for detailed security design.

Accounts Payable

Responsibility Description Audience

BPI AP XXXXXX Ability to…
BPI AP XXXXXX Ability to…
BPI AP XXXXXX Ability to…

See SM01 BPI AP Responsibilities for detailed security design.

537521414.docx August 21, 2013 Page 58 of 113

 BPI Solution Design Document

Subsystem Design – Standard Design Components

Item Definition

Items are utilized within Oracle’s Procure-Pay, Plan-Build and Order-Cash processes, but the Inventory
module is the owner of the Item Master, where items and parts are defined and maintained. Each raw
material, purchased part, manufactured subassembly, phantom subassembly and finished good must
be identified by an item number. Item definition involves defining each item master, and then assigning
that item to each inventory organization where it will be utilized. Items will be defined in the ‘virtual’ item
master organization. Once defined, the will be assigned to BPIs physical ‘child’ organizations.

The item master has well over a hundred attributes that store discrete pieces of data (e.g. description,
unit of measure, and minimum or maximum order quantities). These attributes can be maintained
globally, or maintained individually for the item in each inventory organization. Once defined and
assigned, item attributes controlled at the item master level will apply to all organizations to which the
item is assigned, whereas item attributes controlled at the organization level will apply to each individual
organization. If an Organization level attribute is controlled at the item master level, the new value will
be used when the item is assigned to a new organization.

Item Numbering
Oracle item numbers will be defined using the current BPI customer or stocking part number with a 2
character prefix to identify the brand (where it doesn’t already exist). The organization-wide Oracle item
format will become XX-YYYYY, where XX is the brand designator and YYYYY is the current BPI
customer or stocking part number. The item structure defined for BPIoS will subsequently apply to
India and Mexico when they are migrated into the same Oracle environment.

Item Categories
Each item can be enabled for appropriate functional areas/Oracle modules using item-level attributes,
which are set as part of the item definition process. The following table shows how BPI will utilize item
defining attributes:

Functional Area Item Defining Attribute Enabling Value

Inventory Inventory Item Yes
Purchasing Purchased Internal Ordered Item Yes
Master Scheduling/ MRP MRP Planning Method MRP Planning
MPS Planning
Cost Management Costing Enabled Yes
Engineering Engineering Item Yes
Order Management Customer Ordered Item Yes

See BR01 – INV Requirements BPI and CS01 – INV Setup Configuration Document for detailed design
information.

537521414.docx August 21, 2013 Page 59 of 113

 BPI Solution Design Document

Costing

Oracle Cost Management’s main functionality is to manage perpetual and periodic costing for Inventory,
Work in Process, Purchasing, and Order Management. It supports costing methods such as average,
standard, and LIFO/FIFO. Using Oracle Cost Management, multiple cost elements and sub-elements
can be defined to capture various business scenarios. Examples of cost elements include materials,
material overheads, resources and outside processing. For each element, sub-elements can also be
created to capture more details about cost. BPI’s will utilize integration between Cost Management and
the following modules:

Purchasing
When a purchase order is received, the transaction updates the account and values accordingly. In the
same way, Cost Management checks and verifies whether there’s a difference in the purchase amount
and the value that already exists in inventory. If so, it creates a variance. This variance is only created
in the case of standard costing. If average cost or LIFO/FIFO costing is used, the item will be valued on
the amount that was given on purchase order.

Inventory
Order Management is responsible for managing accounting transactions for Oracle Inventory and
transferring them to the General Ledger. Various costing methods may be utilized, such as average,
standard, LIFO, FIFO, and periodic costing. Costing for products and the costing history is also
maintained in Cost Management.

Work in Process
Items that are issued to WIP for manufacturing are valued in Cost Management. These are charged to
a component of WIP and Cost Management performs the valuation. The same procedure takes place
for materials, overheads, outside processing, and resources. In the same way, when the goods are
returned from a job or a batch, Oracle Cost Management values them and they arrive to the stores as
finished goods.

Transaction
Work in Process
Value

Resource, Overhead
Outside Processing
Transactions Cost Management
Material
Transactions

Transaction
Inventory
Value

537521414.docx August 21, 2013 Page 60 of 113

 BPI Solution Design Document

Payables
When invoices against the purchase order arrive and enter in to Oracle Payables, they are matched
with receipts. Upon matching, Cost Management verifies whether the amounts for which goods are
received are paid or not. If a difference exists, it places a hold on such transactions.

Order Management/Shipping Execution

When one or more order lines are ship confirmed in Order Management, the cost of goods sold
associated with the sales order line is debited by Cost Management to a deferred COGS account
pending the invoicing and recognition of the sales order revenue in Oracle Receivables.

General Ledger
All the accounting entries from the Purchasing, Inventory, and WIP sub-ledgers are eventually
transferred to the General Ledger by the Cost Management module. After running the "create
accounting" process in Cost Management, the accounting entries can be transferred to GL in the form
of batches.

537521414.docx August 21, 2013 Page 61 of 113

 BPI Solution Design Document

Requisitions

BPI will utilize both purchase and internal requisitions.

For purchase requisitions, BPI users will select an item to order along with the quantity and delivery
location, supplier and supplier site. BPI can also choose a price from a list of historical purchase order
prices. For MRO related purchases where an item does not exist in Oracle, BPI will enter a PO
commodity and description instead of an item. In the Distributions window, BPI will let the Requisition
Account Generator create the accounts for the requisition lines. Once the requisition is complete, it will
be sent through the approval process.

For internal requisitions, Purchasing users will create internal requisitions, which are handled as internal
sales orders, and are sourced from inventory rather than from outside suppliers. Requisitions will be
imported from other Oracle modules (see below) using a standard Requisition Import process:

 Planning will generate (approved) requisitions automatically based on planning requirements.

 Inventory will generate requisitions based on replenishment requirements.
 Work in Process will generate requisitions for outside processing.

Requisition templates will be utilized for common purchases. Requisition templates will be converted
into Oracle as part of the initial go-live, and can also be created on demand by authorized users within
the Purchasing module.

BPI will use the position hierarchy to manage the approval process for requisitions that aren’t
automatically approved.

537521414.docx August 21, 2013 Page 62 of 113

 BPI Solution Design Document

Process Flow

See BR01 – PO Requirements BPI and CS01 – PO Setup Configuration Document for detailed design
information.

537521414.docx August 21, 2013 Page 63 of 113

 BPI Solution Design Document

Approved Supplier Lists

BPI maintains lists that associate the items and services they buy with the companies who supply them.
Such data, when stored in a controlled, global repository containing relevant details about each ship-
from/ship-to/item relationship, is known as an Approved Supplier List (ASL). For each item defined on
an ASL, BPI will set the Release Generation Method to Automatic Release. This will let BPI
automatically generates approved blanket releases for items that are sourced to a single supplier.

Purchase Orders

BPI will generally create standard purchase orders for one-time purchase of various items. BPI can
create standard purchase orders when they know the details of the goods or services they require,
estimated costs, quantities, delivery schedules, and accounting distributions.

BPI will create blanket purchase agreements when they know the detail of the goods or services they
plan to buy from a specific supplier in a period, but do not yet know the detail of the delivery schedules.
BPI can use blanket purchase agreements to specify negotiated prices for their items before actually
purchasing them.

BPI will be able to issue a blanket release against a blanket purchase agreement to place the actual
order.

BPI will use the Sourcing Rule and Sourcing Rule/Bill of Distribution Assignments forms to create
sourcing rules in order to achieve automatic sourcing. BPI will also use the Approved Supplier List and
Supplier-Item Attributes windows to specify source document information for a particular item, supplier,
and site.

The system will be configured to create releases each time the requisition import process is run. For
example, when BPI implements planned orders as requisitions in the MRP Planner Workbench, they
can automatically create the releases at the same time they create the requisitions. Oracle
automatically creates and approves the releases for all blanket-sourced, approved requisitions as part
of the Requisition Import process. Oracle automatically sources the requisition line to a blanket
agreement if the supplier for the item is in the Approved Supplier List and if sourcing rules is set up for
the item.

To accelerate the PO process, BPI buyers will use a feature called AutoCreate to quickly create
standard purchase orders from any available standard (not internal) purchase requisition lines. The
purchase requisition lines can be for predefined items or one-time items as well as outside processing
items. Buyers can also copy one purchase order to another. For example, if BPI wants to renew a
blanket purchase agreement with hundreds of lines, they can copy the previous agreement to a new
document and change the effective dates.

537521414.docx August 21, 2013 Page 64 of 113

 BPI Solution Design Document

Process Flow

See BR01 – PO Requirements BPI and CS01 – PO Setup Configuration Document for detailed design
information.

Receiving

BPI can receive all or a partial list of open lines on any purchase order. BPI can also receive substitute
items and goods or services they have not ordered. Oracle Inventory allows BPI to match goods they
receive on the receiving dock to a purchase order they might be fulfilling. You can then record transfers
and deliveries. BPI can also record returns and record adjustments and corrections.

The new receiving process will combine existing manual processes for item “check in” along with the
standard Oracle receiving process.

See BR01 –INV Requirements BPI and CS01 – INV Setup Configuration Document for detailed design
information.

537521414.docx August 21, 2013 Page 65 of 113

 BPI Solution Design Document

Replenishment

Oracle Inventory automatically generates requisitions to replenish inventory levels using the orders
suggested by min-max planning, reorder point planning, and replenishment counting. Requisitions may
request stock from another internal organization or from an outside supplier, based on item sourcing
rules defined at the item-subinventory, subinventory, item, or organization levels.

All items, subinventories, and organizations may have item sourcing information specified for them. At
each level, items can be replenished from inventory or purchased from a supplier. In case of a conflict
between the levels, Oracle Inventory uses the following order of precedence:

1. Sourcing information specified in the item-subinventory relationship

2. Sourcing information specified in the subinventory definition
3. Sourcing information specified in the item definition
4. Sourcing information specified in the organization parameters

If an item is to be replenished from inventory, Oracle Inventory creates an internal requisition for the
item from the source location.

If the item source is a supplier, Oracle Inventory creates a requisition to order the items from an outside
supplier when reorder is necessary

The Min-Max Planning report can trigger the replenishment process by creating pre-approved Move
Orders to fulfill the suggested replenishment quantity.

Stanford will use min-max planning for their Maintenance items. Min max planning will be used for
MRO related items.

537521414.docx August 21, 2013 Page 66 of 113

 BPI Solution Design Document

Process Flow

See BR01 – INV Requirements BPI and CS01 – INV Setup Configuration Document for detailed design
information.

537521414.docx August 21, 2013 Page 67 of 113

 BPI Solution Design Document

Offshore Shipping

BPI may ship some products directly to customers from its China, India and Mexico suppliers, and/or
allow customers to collect product at a supplier port.

The Oracle Order Management and Purchasing modules integrate to support this requirement via Drop
Shipments. Drop Shipments are orders for items that BPI suppliers ship directly to the customer, either
because BPI doesn't stock or currently don't have the items in inventory, or because it's more cost
effective for the supplier to ship the item to the customer directly.

Drop Shipments will be created as Sales Orders during the Order Management process. The Purchase
Release process in Order Management will create requisitions in Purchasing. Drop Shipments will be
marked with the Source Type of External in Order Management and Supplier in Purchasing.

Drop shipping functionality will enable BPI to take an order from a customer and fulfill it directly from a
supplier. Hence, BPI will be able to receive orders for items that they do not stock or for which they
lack sufficient inventory, and have a supplier provide the items directly to the customer.

The supply and demand details for drop ship orders are not visible to Oracle Planning. Therefore, a
separate logical (dummy) organization will be used for shipping drop ship orders and be omitted from
the planning process.

Process Flow

See BR01 –INV Requirements BPI and CS01 – INV Setup Configuration Document for detailed design
information.

537521414.docx August 21, 2013 Page 68 of 113

 BPI Solution Design Document

Trouble Board

BPI invoices currently go on hold for quantity and price variances. Quantity, by item and line, is
checked between the invoice, purchase order, and receipt. If they differ the invoice goes on hold. Price
is compared between the purchase order and invoice. If they differ the invoice goes on hold. When
invoices go on hold in the legacy system they are placed on the ‘Troubleboard’. Responsible parties
are required to watch the ‘Troubleboard’ and resolve issues for their invoices by selecting whether the
purchase order or the invoice is the correct document. This decision results in the system automatically
creating a debit or credit memo.

The expectation is that purchase orders will be used whenever practical. Invoice/PO matching will be
used where PO’s exist. This will reduce the effort in manually entering all of the details on each invoice.
Since the PO will have required approvals and coding, the invoice will no longer have these
requirements. For all invoices without PO’s, BPI would like to have an online approval process which
can be managed using Oracle AME. A range of solutions exist for instances when quantity and price
variances do occur in Oracle, including the use of the standard Match Hold report to identify holds
resulting from variances.

See BR01 – AP Requirements BPI for detailed design information.

537521414.docx August 21, 2013 Page 69 of 113

 BPI Solution Design Document

Asset Creation

One of the standard interfaces within Oracle Applications is a feed of new assets from the Accounts
Payable module to Fixed Asset module. This process ensures traceability from the Fixed Assets
module back to the original Procure–Pay transactions, reduced data entry and ensured data
consistency.

The Create Mass Additions from Invoice Distributions program transfers invoices with distribution lines
charged to the GL CIP account from Payables to Fixed Assets. The GL asset-type account must be set
up for an existing asset category, and must be either an asset clearing account or a construction-in-
process (CIP) clearing account.

A checkbox on the invoice line (‘Track as Asset’) indicates that a line should be transferred to Fixed
Assets. If an invoice is entered in the Invoice Workbench, Payables automatically enables the check
box when an Asset type account is entered.

Process Flow

Accounts Payable-Fixed Assets Interface

Payables User

Submit ‘Create
Mass Additions
Start Validate Invoice(s) Transfer to GL
from Invoice
Distributions

Create Mass
Oracle

Additions
from Invoice
Distributions
Fixed Assets User

Prepare Mass Review Mass

End
Additions Additions

See FS01 – AP Requirements BPI for detailed design information.

537521414.docx August 21, 2013 Page 70 of 113

 BPI Solution Design Document

Subsystem Design – BPI-Specific Design Components

Blanket Purchase Agreement (BPA) Upload/Download

Due to the volume of data, BPI has a requirement to maintain item pricing information in Excel and
upload it into Oracle Purchasing.

To accommodate this requirement, custom concurrent processes will be developed to download BPAs
from Oracle into Excel for pricing maintenance, upload revised BPAs from Excel to Oracle and upload
new BPAs from Excel to Oracle.

See BR01 – PO Requirements BPI, FS01I – PO Upload and Download BPI Item Updates, CS01 – PO
Setup Configuration Document for detailed design information.

Remittance Advice Email

BPI requires that a remittance advice is emailed to a supplier contact detailing the invoices being paid
when suppliers are paid by ACH or Wire.

To meet this requirement, an XML template will be defined. This will be used by the standard Oracle
Separate Remittance Advice program to create and deliver a formatted email remittance advice. The
remittance advice will list the payment number, date, and total amount of the payments sent on that
day. The email will also include a detailed listing of the individual invoice numbers and details that
make up the total payment amount.

See BR01 – AP Requirements BPI, FSR02 – AP Remittance Advice Email BPI and CS01 – AP Setup
Configuration Document for detailed design information.

Account Generator
The default Account Generator processes in Oracle Purchasing build a charge, budget, accrual, and
variance account for each purchase order, release, and requisition distribution based on the
distribution's Expense, Inventory, or Shop Floor destination type.

BPI requires the Account Generator to build the inventory charge account for Expense purchases
based on the requestor. For Inventory charge account construction, the Account Generator further
distinguishes between asset and expense purchases based on the item and sub-inventory provided for
the distribution. If an expense item is selected, the Account Generator disregards the sub-inventory and
builds an expense charge account.

When the Account Generator locates a source account based on the distribution destination type, it
copies complete code combinations (full Accounting Flexfields) from designated fields to destination
Accounting Flexfields. The default Oracle Purchasing process does not build individual flexfield
segments.

See BR01 – PO Requirements BPI, FSE18 – PO Account Generator, CS01 – PO Setup Configuration
Document for detailed design information.

537521414.docx August 21, 2013 Page 71 of 113

 BPI Solution Design Document

Printed Purchase Order

A single purchase order format will be used throughout the organization. To accommodate this
requirement, an XML Publisher template will be created to format the standard Oracle XML output.

See BR01 – PO Requirements BPI, FSR07 – PO Printed Purchase Order, CS01 – PO Setup
Configuration Document for detailed design information.

Core Returns
Core returns in Chowchilla require the ability to receive Caliper items on an Oracle RMA in order to
credit the customer, receive and deliver Caliper items NOT on the Oracle RMA, reject Caliper items and
enter a reason code for their rejection, print the number of caliper items rejected and their respective
reason codes on the customer invoice, “convert” Caliper items to their respective dirty core items and
associated brackets and transact them into inventory. To accommodate these requirements, an
extension to standard Oracle functionality will be created.

See BR01 – INV Requirements BPI, FSE08 – INV Core Returns, CS01 – INV Setup Configuration
Document for detailed design information.

Country of Origin
BPI has a requirement that the Country of Origin (COO) be printed on shipping labels. The COO will be
configured as item attribute, and included in the initial item conversion. A custom process will be
developed to copy the COO from the item definition onto orders so that it may be included on the
shipping label.

See BR01 – INV Requirements BPI, FSE09 – INV Country of Origin, CS01 – INV Setup Configuration
Document for detailed design information.

Receiving Transaction Personalization

BPI will store material in its primary picking location whenever possible. If the primary picking location
is full, BPI will store material in a stocking location. When BPI performs a receiving transaction,
whenever possible, it would like to store material in this primary picking location.

In the Oracle Receiving Transactions form, a personalization will be developed to have the item’s
primary picking locator default into the locator field.

See BR01 – INV Requirements BPI, FSE10 – INV Receiving Transaction Personalization, CS01 – INV
Setup Configuration Document for detailed design information.

537521414.docx August 21, 2013 Page 72 of 113

 BPI Solution Design Document

Sub-inventory Transfer Personalization

BPI will store material in its primary picking location whenever possible. If the primary picking location
is full, BPI will store material in a stocking location. BPI will need to perform a sub-inventory transfer in
order to move material from its stocking location to it primary pick location. A form personalization will
be developed to facilitate this requirement.

See BR01 – INV Requirements BPI, FSE11 – INV Sub-inventory Transfer Personalization, CS01 – INV
Setup Configuration Document for detailed design information.

Global Spend Reports

BPI has a requirement to review supplier spend for different product categories. The requirement
includes the ability to query information using a variety of parameters and sort orders, and present
totals based on the selected data.

To support this requirement, Inventory will define a commodity code which will be assigned to each item
in the item master. Purchasing will make the commodity code required on the PO and Payables will
make it required on the invoice line, along with the Ship-To field on the invoice line. Two custom
reports will be developed to utilize this information and meet the reporting requirement.

See BR01 – AP Requirements BPI, FS01R – AP Global Spend Report, FS01R – AP Item Driven Global
Spend Report CS01 – AP Setup Configuration Document for detailed design information.

ASN for GOL Suppliers

An inbound interface will be developed to support the requirement for to upload inbound EDI 856 (Ship
Notice/Manifest) from GOL supplier shipments into Oracle Purchasing so DC’s can receive the
shipments.

See BR01 – INV Requirements BPI, FSE43 – INV ASN for GOL Suppliers, CS01 – INV Setup
Configuration Document for detailed design information.

Item Material Cost Upload

BPI receives cost files from India, Mexico, and China of their respective material costs, which will need
to be uploaded into Oracle after it has been formatted in Excel.

To support this requirement, an interface will be created to load an Excel based cost file of new material
costs to upload to Oracle.

See BR01 – CST Requirements BPI, FSI31 – CST Upload Item Material Costs, CS01 – CST Setup
Configuration Document for detailed design information.

GM Quantity on Hand
BPI provides nightly feeds of item quantities-on-hand to four customers (GM, Napa, AutoZone and
Amazon). Each customer has its own business rules for the extract and transmission method.

537521414.docx August 21, 2013 Page 73 of 113

 BPI Solution Design Document

In order to meet this requirement, a custom process will be developed to download the on-hand
information and transmit it to the four customers using a predetermined format and transmission
method for each.

See BR01 – INV Requirements BPI, FSI32 – INV GM Quantity On Hand, CS01 – INV Setup
Configuration Document for detailed design information.

Chassis Integration

BPI is the 3PL (third party logistics) provider for Affinia’s Chassis group. Chassis runs BAAN as their
ERP system, but BPI will manage their logistics within Oracle. To accommodate this, Chassis items will
be loaded and defined in the Oracle item master using a dedicated Chassis item template. Chassis
items will be assigned a category of Chassis in order to differentiate them for reporting purposes. In
order to reflect Chassis-related transactions in BAAN that originate in Oracle, and vice-versa, a set of
interfaces will be developed to replicate transactions and/or their impacts to master data.

Oracle Inter-Org Transfers Download and Upload

The Chassis BAAN system initiates inter-org transfers (via internal sales orders), which
need to be reflected in Oracle. Inter-org transfers may also be initiated in Oracle for
Chassis-related organization, and hence need to be reflected in the BAAN system. To
support this requirement, a two-way interface will be developed between Oracle and
BAAN. Sales orders will be imported from BAAN to Oracle, and relevant receipts will be
interfaced from Oracle to BAAN.

See BR01 – INV Requirements BPI, FSE11 – INV Chassis – Oracle Inter-Org Transfers
Download and Upload, CS01 – INV Setup Configuration Document for detailed design
information.

Oracle Inventory Adjustments Upload

When BPI makes adjustments to inventory it carries in a Chassis organization, the BAAN
system needs to be made aware of the changes to reflect the changes accordingly. To
accommodate this requirement, an interface will be developed from Oracle to BAAN to
send adjustments made to Chassis items.

See BR01 – INV Requirements BPI, FSE12 – INV Chassis – Oracle Inventory
Adjustments Upload, CS01 – INV Setup Configuration Document for detailed design
information.

Oracle Inventory Reconciliation Upload

The Chassis BAAN system needs to be provided with quantity-on-hand information from
Oracle for chassis items in order to reconcile with the master information it maintains. To
accommodate this requirement, an interface will be developed from Oracle to BAAN to
send quantity-on-hand information to BAAN for items associated with the Chassis item
category.

537521414.docx August 21, 2013 Page 74 of 113

 BPI Solution Design Document

See BR01 – INV Requirements BPI, FSE13 – INV Chassis – Oracle Inventory
Reconciliation Upload, CS01 – INV Setup Configuration Document for detailed design
information.

Oracle Item Download

The BAAN system will be used by Chassis as its system of record. Any additions and/or
changes to inventory items in BAAN will need to be reflected into Oracle. BPI will also
need to maintain Chassis items in Oracle to support processes covered by the 3PL
agreement. To accommodate these requirements, a two-way interface will be developed
from BAAN to Oracle Inventory to exchange new and updated chassis item information.

See BR01 – INV Requirements BPI, FSE14 – INV Chassis – Oracle Item Download,
CS01 – INV Setup Configuration Document for detailed design information.

Oracle Pick Release Download and Upload

Chassis will perform pick releases in BAAN. This information needs to be reflected in
Oracle to support the shipping process in the Oracle environment. BAAN will
subsequently be made aware of shipments when they occur. To accommodate these
requirements, a two-way interface will be developed between BAAN to Oracle to send
pick release information from BAAN to Oracle, and return ship confirmations from Oracle
to BAAN.

See BR01 – INV Requirements BPI, FSI15 – INV Chassis – Oracle Pick Release
Download and Upload, CS01 – INV Setup Configuration Document for detailed design
information.

Oracle PO Receipts Download and Upload

Chassis will send PO information to BPI, which will need to be loaded into Oracle.
Subsequently, BPI will perform Oracle receipt transactions for Chassis related inter-
organization transfers and supplier PO receipts. This receipt information will need to be
provided to Chassis so that they can reconcile it in BAAN. To accommodate this
requirement, a two-way interface will be developed between BAAN to Oracle to send
POs from BAAN to Oracle, and send receipts from Oracle to BAAN.

See BR01 – INV Requirements BPI, FSI16 – INV Chassis – PO Receipts Download and
Upload, CS01 – INV Setup Configuration Document for detailed design information.

537521414.docx August 21, 2013 Page 75 of 113

 BPI Solution Design Document

Plan-Build

Description

The Plan-Build modules consist of Bills of Material (BOM), Work in Process (WIP), Supply Chain
Planning (SCP) and Engineering. Together, they support the following business processes:

Module Business Processes

BOM BOM maintenance, routing maintenance
DRP Planners workbench
WIP Work orders
Engineering Engineering change orders

Process Flow

537521414.docx August 21, 2013 Page 76 of 113

 BPI Solution Design Document

Touch Points

Source Destination Description

WIP Cost Management WIP accounting classes, job variances
Order Management Cost Management Invoice only sales
Shipping Execution Cost Management Shipments
Cost Management General Ledger Journal entries
Cost Management WIP Material costs, resource costs
Engineering BOM Bills
Engineering WIP Bills, routings
Inventory WIP Items, inventory balances, transactions
WIP Purchasing Outside processing
BOM Order Management Model, option and kit bills
BOM WIP Standard bills
Cost Management Purchasing Standard costs
Engineering Purchasing Resources
Inventory Cost Management Transaction rates
Cost Management Inventory Costs
Engineering Inventory Engineering items
Inventory Engineering Items

Each touch point will be detailed further in specific subsystem design sections of this document.

537521414.docx August 21, 2013 Page 77 of 113

 BPI Solution Design Document

Data Conversion

Bills
<Add content>

Routings
<Add content>

Sales History
<Add content>

Sourcing Rule Assignments

Souring rules for ‘Transfer-From’ (internal organizations) and ‘Buy-From’ (external suppliers) sourcing
will be loaded into Oracle as part of the initial conversion for each item in each inventory organization.
There is no single, complete source of sourcing rule information, so sourcing rules will need to be
created prior to loading into Oracle.

OE Interchange
<Add content>

Comp Interchange
<Add content>

Pricing Interchange
<Add content>

Vehicle Applications
<Add content>

See FSC33 – Sourcing Rule Assignments Conversion, Y and Z for detailed design.

537521414.docx August 21, 2013 Page 78 of 113

 BPI Solution Design Document

Security

Plan-Build security will be managed using responsibilities. Users are granted access to one or many
responsibilities. Responsibilities provide all users with the same level of functional access as each
responsibility is configured to allow access to specific system functions. Some responsibilities will be
based upon standard (seeded) Oracle responsibilities, but custom versions will be created in order to
support future maintenance and enhancements.

Engineering

Responsibility Description Audience

BPI ENG XXXXX Ability to x, y and z
BPI ENG XXXXX Ability to x, y and z

See SM01 BPI ENG Responsibilities for detailed security design.

BOM

Responsibility Description Audience

BPI BOM XXXXX Ability to x, y and z
BPI BOM XXXXX Ability to x, y and z

See SM01 BPI BOM Responsibilities for detailed security design.

MRP

Responsibility Description Audience

BPI MRP XXXXX Ability to x, y and z
BPI MRP XXXXX Ability to x, y and z

See MRP for detailed security design.

WIP

Responsibility Description Audience

BPI WIP XXXXX Ability to x, y and z
BPI WIP XXXXX Ability to x, y and z

See WIP for detailed security design.

537521414.docx August 21, 2013 Page 79 of 113

 BPI Solution Design Document

Subsystem Design – Standard Design Components

Bills of Material and Routing Definitions

Oracle Bills of Material supports the definition of multi-level bills of material and associated routings that
model BPIs manufacturing process. The application builds upon the organization and item definitions in
the Inventory module and provides information to Cost Management, Work in Process, and the
planning modules.

Within Oracle Bills of Material, additional characteristics will be defined, including the workday calendar
used by each inventory organization, the manufacturing departments and resources (labor and
machinery) used to make products. The capacity of each resource will also be defined and used as the
basis of resource constraints used in Planning.

A separate bill of material will be defined for each subassembly and finished product; A bill of material
will identify the component or child parts and the required quantity per unit of the assembly or parent.

Effective dates will support model pending changes in the product structure, and allow the planning
applications to time-phase those changes. The bill of material will also specify a yield factor for each
component. It includes an optional link to the routing operation where the component is consumed, and
the WIP Supply Type for each component, indicating how the material is supplied to WIP (e.g whether
the material is explicitly issued or back-flushed at point of use). These characteristics will affect the
processing of jobs or repetitive schedules in Work in Process as well as the planning process.

Oracle Bills of Material will also maintain product routings. A routing lists the sequence of steps required
to manufacture a product from its components; it specifies the department where each step occurs and
lists the resources needed at each department. This resource information is used by Work in Process
and Scheduling to schedule jobs and is used to calculate planning lead times from routings, It is also
the basis of the resource and overhead cost calculations in Cost Management.

Standard, Common and Alternate BOM types will be utilized by BPI. These types will initially be
defined/ maintained in the Oracle Engineering module for new assembly items.

Standard BOMs used for Oracle Pick-to-Order (PTO) functionality will have to be defined/maintained in
the Item Master (IMO) organization, since IMO is the item validation organization for the Oracle Order
Management module. All other BOMs will be defined/ maintained in the manufacturing and/or
distribution center organizations where they are used for Distribution Requirements Planning (DRP)
and/or Work-in-Process functions.

Within Standard Primary and/or Alternate BOMs, there will be some phantom subassembly levels for
end-items manufactured at the Stanford facility, and possibly the Chowchilla facility as well.

Within Standard and Common Primary and/or Alternate BOMs, substitute components will sometimes
be included. Substitute components are for reference information only, and are not considered by the
Oracle Planning system being implemented at this time. BOM Attachments will sometimes be used for
certain product or process-oriented documentation. BOM Attachments can be files or textual notes
associated to BOM header or component level information.

537521414.docx August 21, 2013 Page 80 of 113

 BPI Solution Design Document

Routings will only be defined/maintained in the Oracle BOM module (not in Oracle Engineering).
Alternate Routings will be used, specifically for manufacture of end-items at Stanford and Chowchilla.
Primary and Alternate Routings will frequently be created using the Copy Routing function. Common
Routings will sometimes be used, with item-specific settings for Completion Subinventories. The main
known use of Common Routings is for re-packaging operations at Distribution Centers.

Process Flows
Define Bills of Material Process

start Determine Inventory

Specify Use Common List component
Organization for no Alternate BOM? no
assembly item BOM? item
BOM

yes yes

Specify Common Specify Alternate

BOM name
end

Validate or specify
Update Yield
Does Routing Specify component component item
no information
exist? item usage Material Control
(if not = 1)
information

yes

Reference Routing
Op Seq to BOM no Planning
no
component? BOM?

yes yes

Reference Routing Specify BOM

Op Seq to BOM component Planning Attachments? yes Specify Attachments
component % values

no end

Define Routings Process

start Determine Inventory

Specify Use Common Alternate List
Organization for no no
assembly item Routing? Routing? OperationSeq
Routing

yes yes

Specify Common Specify Alternate

Routing name
end

no

List Resources:
Validate or specify
* Seq Specify Resource(s)
WIP Countpoint, More
* Resource Scheduling yes A
Autocharge, operations?
* Basis Information
Backflush
* Usage Rate

no

Attachments? yes Specify Attachments

no end

537521414.docx August 21, 2013 Page 81 of 113

 BPI Solution Design Document

See BR01 – BOM Requirements BPI and CS01 – BOM Setup Configuration Document for detailed
design information.

537521414.docx August 21, 2013 Page 82 of 113

 BPI Solution Design Document

Engineering Change Orders

The Oracle Engineering module provides a separate environment for defining items, bills of material,
and routings prior to their release to production and supports controlled changes to bills through the use
of Engineering Change Orders (ECOs).

After conversion into Oracle, new items, bills, and routings will first be defined as engineering items,
bills, or routings prior to being released to manufacturing. While this process uses the same database
tables as released/manufacturing objects, it will allow separate security and accessibility. Releasing an
item, bill, or routing to manufacturing will make the object accessible to all users who have access to
manufacturing data.

Engineering Change Orders support changes to bills of material (component items, quantities and
effective dates) in a controlled environment. An ECO can identify changes to one or more bills of
material in order to group related product changes. The ECO will enable the rescheduling or canceling
of a set of changes as a unit. It will also identify whether the ECO should update WIP jobs and
repetitive schedules when it’s implemented. Oracle Workflow provides the approval process for ECOs
to control the release process.

The Oracle Engineering Transfer to Manufacturing process is used to move an Engineering Prototype
Item and/or BOM from Oracle Engineering to Oracle Manufacturing (Inventory and Bills of Material
modules, respectively). The requirement for Oracle Engineering is to provide this separation between
engineering prototype items/BOMs and those that have been released to production. The Transfer to
Manufacturing process is performed within the Oracle Engineering Change Order (ECO).

See BR01 – ENG Requirements BPI and CS01 – ENG Setup Configuration Document for detailed
design information.

537521414.docx August 21, 2013 Page 83 of 113

 BPI Solution Design Document

Forecasting

Forecast data will be calculated or otherwise created using an external forecasting tool. Forecast data
will then be loaded from the forecasting tool into Oracle. Forecasts Set bucketing in Oracle will be
“Daily”, and forecast entries imported will have valid data for Organization, Forecast Set, Forecast,
Item, Date, and Quantity.

Forecasts will include projected shipments to external customers, any rollouts of new inventory stocking
programs and (optionally) projected usage of component materials for Min-Max planned items at
Distribution Centers. Forecast will not include projected shipments on internal sales orders (and
internal sales orders will not consume forecast entries).

Forecast Sets will be consumed on an on-going basis (as customer orders are booked/scheduled).
Consumption rules will initially be 30 Days Forward/30 Days Backward, with 100% Outlier. Custom
reporting will be required to monitor forecast consumption between forecast update/replacement cycles,
to support ability for user analysis and decision-making regarding update of forecasts between cycles.

Higher-volume items will generally be forecasted, while low-volume items that cannot reasonably have
enough demand history for statistical forecast computations will generally be given a safety stock level
for purposes of maintaining some supply on-hand. This determined will be made by the Product
Demand and Inventory Planning business team.

The Ollie Wight Sales and Operations Planning (S&OP) tool may need to be supported by the export of
sales history and other data from the Oracle system. This could include Oracle DRP plan information
and potentially the aggregation of same to a product group level. However, it is yet to be determined
whether or not the S&OP tool will be used – or – if custom reporting using Oracle DRP plan information
(including aggregation) will be developed to support the S&OP business process instead.

Process Flow

Forecasting for Oracle DRP

start
DRP
Run concurrent request(s):
New forecast Prepare/approve Ready to load to planning
yes yes Import Oracle Forecast Sets/
cycle? Forecasts Oracle? process
Forecasts from Excel

no no

Run concurrent
request(s): Modify
yes Update Forecast(s)
Monitor Forecast Forecast(s)?
Consumption

no

See BR01 – SCP Requirements BPI and CS01 – SCP Setup Configuration Document for detailed
design information.

537521414.docx August 21, 2013 Page 84 of 113

 BPI Solution Design Document

Master Demand Scheduling

Master Demand Schedules (MDS) will be used to load demand of unshipped customer orders and
unconsumed forecast, for the manufacturing sites and distribution centers (inventory organizations)
planned by Oracle DRP. A separate MDS will exist for each of these organizations.

The MDS will be associated with the inventory organizations for the manufacturing sites and
Distribution Centers, to serve as the source schedule for Oracle DRP planning.

The MDS will be re-loaded for each routine DRP plan generation. The MDS loads will be scheduled
concurrent requests that will exist for each DRP planned organization (the MDS loads will not include
forecast consumption, as the forecasts will already be consumed on an on-going basis).

See BR01 – SCP Requirements BPI and CS01 – SCP Setup Configuration Document for detailed
design information.

Distribution Requirements Planning

DRP will be used by each of the manufacturing plants and distribution centers, which are linked
together by sourcing rules, into a single supply chain network.

Items planned by DRP will be those that are components of end-items manufactured at the plants and
re-packaged at the distribution centers (Distribution Centers); and that are stocked (however
temporarily) and shipped from the manufacturing plants and Distribution Centers to other internal
organizations and/or external customers. Items that are drop-shipped directly from external suppliers to
customers will not be DRP-planned, nor will indirect/MRO type materials.

There will be one central DRP plan, defined in the Midwest Distribution Center (MDC) inventory
organization. The DRP plan will be re-generated on a daily basis.

DRP will use Master Demand Schedules (MDS) as sole sources of independent demand, with one
MDS specified as the source schedule to each DRP-planned inventory organization. Each MDS will be
automatically updated prior to each routine generation of the DRP plan.

After DRP plan generation, each planned inventory organization will:

1. Review and analyze DRP plan exceptions, and perform actions to reschedule and/or cancel
discrete jobs, purchase requisitions/purchase orders, and internal requisitions/internal sales
orders, as appropriate, to avoid build or purchase of unneeded inventory and to re-balance
supply with demands.
2. Review and analyze DRP plan actions, and revise/modify and release planned orders, as
appropriate and in a timely manner, to maintain proper balance of demand and supply of all
DRP planned items for each planned organization.
3. Optionally use the DRP order “firming” feature, such that some rescheduled and/or newly
created orders might be locked in place to avoid further/unnecessary DRP Exception

537521414.docx August 21, 2013 Page 85 of 113

 BPI Solution Design Document

messaging, when the orders will not be rescheduled further (or even cancelled) to otherwise
improve demand/supply balancing.

The DRP plan will be configured to generate the routing-based capacity requirements plan (CRP)
information.

Standard Oracle concurrent programs for will automatically import requisitions, jobs and internal sales
orders generated by the DRP plan into the WIP and Purchasing modules.

Process Flow

Oracle Distribution Requirements Planning (DRP)

Query DRP Planner Workbench

start DRP plan re- for Exceptions:
generation yes * Orders to be cancelled
completed? * Orders to be rescheduled-in
*Orders to be rescheduled-out

no

Exception: Can/should
Orders to be yes orders be yes Cancel orders
cancelled? cancelled?

no

(Optional):
Firm orders not to A
be cancelled

Exception: Can/should
A Orders to be orders be yes Reschedule orders
rescheduled? rescheduled?

no

(Optional):
Firm orders not to B
be rescheduled

Query DRP Planner

Can/should Finalize planned
Workbench for Planned Perform demand/
B planned orders yes orders size and
Orders with near-term supply analysis
be released? scheduling
Suggested Start Dates

no

Is item
manufactured? Release planned
no orders

yes

Assess components (Optional):

availability Firm orders not to
end
be rescheduled or
cancelled

Assess capacity
availability

See BR01 – MRP Requirements BPI and CS01 – MRP Setup Configuration Document for detailed
design information.

537521414.docx August 21, 2013 Page 86 of 113

 BPI Solution Design Document

Stanford Manufacturing

Standard (discrete) jobs will be used to support production of Mixes and Brake Sets. Standard jobs will
typically be created automatically by the Oracle WIP Mass Load program after planned orders have
been released from the Oracle Distribution Requirements Planning (DRP) system Planner Workbench.
However, Jobs can also be created manually.

Standard Jobs will be auto-numbered (here will not be intelligent prefixes associated with the Job
numbers). There will be a single (unique) WIP Accounting Class for Stanford. Jobs may (optionally)
be linked to customer order lines to reserve supply where the manufactured product will be shipped
direct to the customer.

Existing “Batch Tickets” for Mixes will continue as an off-line process, although the Batch Ticket number
may be manually referenced in Oracle at the Job header level for Mix Jobs.

A paper-based Job Traveler packet will be generated and include Job header information, component
pick list (if required), routing operations, components used by operation, and any printed notes and
attachments. Engineering drawings that are included in Job Traveler packets will need to be manually
printed and attached to the packets (there will be no interface between Oracle and the system used for
engineering drawings).

For end-item Job Traveler packets, customer-requested product information labels will be manually
affixed to the Job Traveler along with “Stamp Box” information and “sub-travelers” to provide routing
operations and component item requirements for phantom subassemblies. The Job Traveler
documents will be bar-coded. Oracle MSCA will be used at terminal stations for data scan/input, but
there will not be any RF devices used for shop floor reporting of WIP transactions.

Bills of Material (BOMs) will exist for all manufactured items. Phantom subassemblies will exist for
Brake Sets. Non-phantom component items will most likely be Assembly Pull back-flushed, however,
some may be Push-Issued.

Mixes will be lot-controlled outside of Oracle. The Mix Job number in Oracle will be the lot number, and
Mix lot number(s) used for Brake Sets Jobs will be referenced via manual entry to the Brake Sets Job.
Assuming that Mix will be Assembly Pull back-flushed to the Brake Sets Job, entry of the Mix lot
number(s) will be made in Oracle within the Comments field in the WIP Material Requirements form.
The Mix lot numbers information can be entered in the Comments field at any time, even after
completion of the Brake Sets Job if necessary.

Routings will exist for all manufactured items. Shop floor reporting will include shop floor move
transactions at certain key count points, but not typically at all of the routing operations. All routing
operations will be available for shop floor reporting, thus it will remain optional to report or not at a given
operation. Costed resources will be charged at standard rate, whether associated with count point
operations or not (they will be charged in a back-flushed manner if not associated with count point
operations).

Work-order-Less Completions will be used for over-production of phantom subassemblies on a

Standard Job (in order to charge resources and issue component materials). These items will be
stored in a sub-inventory and push-issued to the next end-item job that manufactures the same

537521414.docx August 21, 2013 Page 87 of 113

 BPI Solution Design Document

phantom subassembly. It may be necessary to perform WIP Material and Operations maintenance to
the affected job to reduce the defaulted number of non-phantom components of the same subassembly
and remove (or zero-out usage rates) of the resources for the operations that pertain to the same
subassembly.

WIP Completion transactions will be performed to the Stage sub-inventory (not locator-controlled) for
Mix Jobs. WIP Completion transactions will be performed to the Finished Goods (FG) sub-inventory
(not locator-controlled) for Brake Sets Jobs.

Process Flow

Standard Discrete Jobs – Stanford Manufacturing

Phase

start
* DRP WIP Mass Load
Review component Perform WIP
Planning/Scheduling

(Mixes) Material Finalize schedule Move INGREDIENTS

availability for Mix yes Completion B
* DRP Capacity Plan available? dates & Release Job to point-of-use
Ingredients transactions
(Mix Resources)

no

Planning/ A Assembly Pull

Purchasing INGREDIENTS
processes Job
Job Traveler
Traveler w/Lot
Numbers
Manufacturing

Add Batch Ticket no.

Perform Shop Floor Moves
A Manufacture Mix to Job header
at Countpoint operations
information

* DRP WIP Mass Load Perform WIP

Planning/Scheduling

(Brake Sets) Review component Material Finalize schedule Move components Completion
* DRP Capacity Plan availability for Brake Sets available? dates & Release Job to point-of-use transactions
(Brake Set Resources)
yes
end
no
D1, D2
B E
Planning/ Assembly Pull
C1, C2
Purchasing components
processes Job
Job Traveler
Traveler

Manufacture :
Add Mix Job no. as Mix
Painted Pads Perform Shop Floor Moves Move Painted Pads Perform Packing
E Lot no. in WIP Material
(phantom at Countpoint operations to Packing Cell operations
Requirements Comments
subassyies)
Manufacturing

no

Job
Job Sub-Travelers
Sub-Travelers Overproduction of Perform Workorder-
phantom Less Completion
subassembly? transactions

yes
Planning/Scheduling

Use Perform WIP Push Issue

C1 subassemblies in yes component material & subassembly C2 Ship direct to Attach Job(s) to
D1 yes
stock? Resource usage updates quantity to Job customer? sales order

no

no D2

See BR01 – WIP Requirements BPI and CS01 – WIP Setup Configuration Document for detailed
design information.

537521414.docx August 21, 2013 Page 88 of 113

 BPI Solution Design Document

Chowchilla Manufacturing

Standard (discrete) jobs in the Oracle WIP module will be used for teardown (disassembly) of “dirty
cores” (see next section) and for remanufacturing Caliper assemblies.

Standard jobs will typically be created automatically by the Oracle WIP Mass Load program, after
planned orders are released from the Oracle Distribution Requirements Planning (DRP) system Planner
Workbench, for remanufactured Caliper assemblies and for “clean” Housing and Bracket items (as
components of remanufactured Caliper assemblies). However, Jobs can also be created manually.

Standard Jobs may (optionally) be linked to customer order lines to reserve supply where the
manufactured product will be shipped direct to the customer. This pertains only to remanufactured
Caliper assemblies.

There will be a paper-based Job Traveler packet for all Standard Jobs, which will include job header
information, component pick list (if required); routing operations; components used by operation (if
required) and any printed notes/attachments. Engineering drawings that are included in Job Traveler
packets will need to be manually printed and attached to the packets (there will be no interface between
Oracle and the system used for engineering drawings).

For remanufactured Calipers assembly Job Traveler packets, “Stamp Box” information must be
included in the printed information. This is not applicable to Job Traveler packets for dirty core teardown
operations.

The Job Traveler documents will be bar-coded. Oracle MSCA will be used at terminal stations for data
scan/input (there will not be any RF devices used for shop floor reporting of WIP transactions).

Bills of Material will exist for all manufactured items. Phantom subassemblies may exist for
remanufactured Caliper assemblies. Non-phantom component items will most likely be Assembly Pull
back-flushed, however, some may be Push-Issued.

There may be some Oracle lot-controlled items as components of remanufactured Caliper assemblies,
but there are no special functional requirements associated with this for Chowchilla.

Routings will exist for all manufactured items. Shop floor reporting will include shop floor move
transactions at certain key count points, but not typically at all of the routing operations. All routing
operations will be available for shop floor reporting, thus it will remain optional to report or not at a given
operation.

Costed resources will be charged at standard rate, whether associated with count-point operations or
not (they will be charged in a back-flushed manner if not associated with count-point operations).

Work-order-less completions will be used for any over-production of phantom subassemblies on a

standard job for remanufactured Calipers assemblies (in order to charge resources and issue
component materials). These items will be stored in a sub-inventory and push-issued to the next end-
item Job that manufactures the same phantom subassembly. It may be necessary to perform WIP
Material and Operations maintenance to the affected job, to reduce the defaulted number of non-

537521414.docx August 21, 2013 Page 89 of 113

 BPI Solution Design Document

phantom components of same subassembly and remove (or zero-out usage rates) of the resources for
the operations that pertain to the same subassembly.

WIP Completion transactions will be performed to the Finished Goods (FG) sub-inventory (not locator-
controlled) for remanufactured Calipers assemblies.

Outside processing will be involved in the manufacture of some Calipers products.

Process Flow

Standard Discrete Jobs – Chowchilla Manufacturing

Phase

start
* DRP WIP Mass Load
Review component Perform WIP
(Caliper Assys) Material Finalize schedule Move components
availability for Completion
Planning/Scheduling

* DRP Capacity Plan available? dates & Release Job to point-of-use

Caliper Assys transactions
(Cell Resources)

no end

A1,A2
Planning/
Purchasing Assembly Pull
processes Job
Job Traveler
Traveler components
Manufacturing

Is outside
Perform Shop Floor Moves Complete
Assemble Calipers processing no
at Countpoint operations manufacturing
involved?

yes
Purchasing/
Receiving

Purchasing for
Outside Services
Planning/Scheduling

Ship direct to Attach Job(s) to

A1 yes
customer? sales order

no A2

See BR01 – WIP Requirements BPI and CS01 – WIP Setup Configuration Document for detailed
design information.

537521414.docx August 21, 2013 Page 90 of 113

 BPI Solution Design Document

Dirty Core Teardowns

Standard (discrete) jobs in the Oracle WIP module will be used to perform teardown (dismantle/
disassembly) of “dirty” Caliper Housing and Bracket assemblies (“cores”) at the Chowchilla
manufacturing facility.

New items will be created to designate “clean” Housing and Bracket components of remanufactured
Caliper assemblies. The existing “core” items will represent “dirty” Housing and Bracket assemblies.

BOMs will exist specifying dirty cores are components of the (new) clean core items, and thus WIP
Material Requirements will exist for the Standard Jobs to make clean cores from dirty cores. BOMs for
some Housings and Brackets will not have dirty core components where the products have not been in
production long enough to be able to acquire the dirty cores. The existing BOMs for these situations
are already supposed to specify the Housings and Brackets as purchased items.

A routing will exist to make clean cores from teardown of dirty cores on Standard Jobs.

A custom Job Traveler will be required that includes bar-coded operations but no Stamp Box
information nor product labels, as required for remanufactured Caliper assembly Jobs. The Job
Traveler will have pick list information that includes the dirty core as the component of the clean core.

The dirty core component item will be either push-issued or Assembly-Pull back-flushed, to issue it from
stock to the teardown Job. This will be decided for the items and BOMs conversion specifications
(where defaulted values are specified as item and/or BOM attributes).

If any components of the dirty core are to be immediately transacted to stock (within the Standard Job
to teardown the dirty core), they will need to be added as WIP Material Requirements with negative
component usage quantities, and transacted from the Job using WIP negative component issue
transactions. Any WIP Material Requirements that are not transacted will need to be removed from the
Job (to avoid erroneous transactions). Components of the dirty cores that are reclaimed/refurbished
may be transacted to stock independently of the Jobs, using Oracle Miscellaneous Receipts. This
would normally be done for reclaimed items that require plating, and Pistons and their component items
that may undergo teardown independently of the dirty cores on Standard Jobs (therefore they may be
no WIP Material Requirements with negative component usage quantities that need to be added to the
teardown Jobs, nor transacted to stock using the WIP negative component issue transactions).

WIP completion transactions to post WIP assembly item quantities (clean cores) to stock from the
Standard Jobs will be performed in the same manner as any other Standard Job.

Further processing of Standard Jobs for teardown operations will be performed as normal and same as
for remanufactured Caliper assemblies, (i.e. optional shop floor move transactions; scrap of Job
assemblies; return to stock of un-used components (dirty cores); Job closure; etc.)

537521414.docx August 21, 2013 Page 91 of 113

 BPI Solution Design Document

Process Flow

Standard Discrete Jobs for Dirty Cores Teardown – Chowchilla Manufacturing

Phase

start
* DRP WIP Mass Load
Planning/Scheduling

Perform WIP
(clean cores) Push Issue dirty Core to Std Job Finalize schedule Move dirty Cores to
A Completion B
* DRP Capacity Plan (optional method) dates & Release Job point-of-use
transactions
(Teardown Resources)

Assembly Pull dirty cores

Job
Job Traveler
Traveler (optional method)

Purchasing
Aggregate reclaimed processes
Manufacturing

items for Plating

Perform dirty Core Perform Shop Floor Moves

B
teardown operaitons at Countpoint operations

Aggregate Pistons for

Perform off-line Piston
off-line disassembly
disassembly operations
(optional)

Transact reclaimed Update Material Requirements: Perform Negative

Planning/Scheduling

components within yes Add reclaimed items Component Issue for Perform Misc Receipt
Standard Job? (negative usage quantities) reclaimed items transactions

no

A A
end

See BR01 – WIP Requirements BPI and CS01 – WIP Setup Configuration Document for detailed
design information.

537521414.docx August 21, 2013 Page 92 of 113

 BPI Solution Design Document

Postponement (White Box Re-Branding & Upgraded Rotors)

Min-Max Planning will be used to support the postponement/white-box re-branding program for
Distribution Centers that will stock minimal inventory of brand boxed items where a single white boxed
item can be re-packaged to make multiple brand boxed items. In addition Min-Max Planning will be
used to replenish stocks for a limited amount of upgraded Rotors, using Oracle Outside Processing
functionality to upgrade standard Rotors. The purpose of the postponement program is to reduce
overall inventory levels while improving flexibility to meet customer demands for a larger variety of
products at lower total cost.

Bills of Material (BOMs) and routings will exist for the Min-Max planned items at the applicable
Distribution Centers. Components on these BOMs will include the white boxed items, standard grade
Rotor items and packaging items (boxes and labels), as applicable. Target minimum and maximum
supply levels will be set at the item level.

Forecast for the components of Min-Max planned items will need to be maintained for each applicable
DC, and included in the Master Demand Schedule (MDS) as the source schedule for DRP planning of
the Distribution Centers. Sourcing rules will drive demand for these component items to external and/or
internal suppliers through DRP planning (the component items are not Min-Max planned).

The Min-Max Planning report will be run at the applicable Distribution Centers to provide the suggested
replenishment quantities. The report will be generated to create Discrete Jobs for the replenishment
process.

The Assembly Pull back-flush method will be used for issuing component materials to the Jobs
associated with re-packaging product for Min-Max replenishment at the Distribution Centers.
Therefore, component item inventory will appear to be in stock until the WIP Move/Assembly
Completion transactions are performed.

The Push Issue method will be used for issuing standard grade Rotors to the Jobs associated with
outside processing for Min-Max replenishment of upgraded Rotors at the Distribution Centers. The
Push Issue method will be used since the outside processing incurs a relatively lengthy cycle time (2-3
weeks). Therefore, component inventory will be relieved on a more timely basis.

Standard Jobs will be used at Distribution Centers for white-box re-branding. White boxed product will
be issued to applicable jobs from DC stock using Assembly Pull back-flush, and the brand boxed
product will be completed to stock at the same DC. The DC can run the Min-Max Planning report for
this process. Standard Jobs used for this process will typically be created automatically by the Oracle
WIP Mass Load program after planned orders have been released from the Oracle Distribution
Requirements Planning (DRP) system Planner Workbench. However, the Planner will need to identify
the white or brand boxed items to use as components to be re-packaged, adding the WIP Material
Requirements to the Jobs, and using the Assembly Pull back-flush method for issuing them from DC
stock. The Planner should Release these Jobs when ready for DC execution.

Standard Jobs will also be used at Distribution Centers to make upgraded Rotors from standard grade
Rotors, using Oracle Outside Processing functionality. These standard jobs will typically be created by
Min-Max Planning. The standard Rotor will be Push-Issued as a component of the job, and the

537521414.docx August 21, 2013 Page 93 of 113

 BPI Solution Design Document

upgraded Rotor will be completed to stock at the DC after outside processing has been performed. The
DC can run the Min-Max Planning report to initiate this process.

Both white-box re-branding and upgraded rotor jobs will have pre-defined routings and use simple one-
step (combined) Shop Floor Move and WIP Completion transactions.

Pre-defined BOMs will exist for all of the above scenarios except re-packaging. It is not expected that
Standard Jobs would be linked to customer order lines to reserve supply for any of these scenarios.

There will be a paper-based Job Traveler packet for all Standard Jobs, which will include Job header
information, component pick list, routing operations and any packaging instructions defined as e-
Documents that attach to the jobs. Labels will need to print with the Job Traveler packets, or upon
demand. (Labels will be items on the BOMs). The Job Traveler documents will be bar-coded. Oracle
MSCA will be used at terminal stations for data scan/input (there will not be any RF devices used for
shop floor reporting of WIP transactions).

Process Flows

Min-Max Planning for Postponement

Phase

start
Update Organization
Identify Develop Min-Max Update Organization Forecast
Item attributes for Assign Planner Code
Product Demand &
Inventory Planning

Organization Items planning item Items to enable components of Min-

target stocking to Organization Item
for Postponement attributes Min-Max Planning Max Planned items
levels

end

537521414.docx August 21, 2013 Page 94 of 113

 BPI Solution Design Document

Standard Discrete Jobs – Distribution Center

Phase

start
Run Min-Max Planning Report
Verify component Component
with Restock = Yes no A
material availability items available?
(by DC)

yes

Perform Job WIP

Schedule batches of
Distribution Centers

Perform packaging Move/Assembly

packaging work (from end
operations Completion
Min-Max Report)
Release Jobs & Print transactions
Job Traveler packet

Job Traveler
packet Jobs include Purchasing Pick Rotors for Receiving
Upgraded yes processes upgrade & send to process
Rotors? OSP supplier

no

A Advise Planner Cancel unneeded Jobs

See BR01 –SCP Requirements BPI, BR01 –WIP Requirements BPI, CS01 – SCP Setup Configuration
Document and CS01 – WIP Setup Configuration Document for detailed design information.

537521414.docx August 21, 2013 Page 95 of 113

 BPI Solution Design Document

Cost Management

Oracle Cost Management is the primary point of integration between Oracle Manufacturing and
Financial applications. It helps maintain the standard or average cost for items and collects cost
information from Inventory, Purchasing, and Work in Process to transfer to Oracle General Ledger.

Oracle Cost Management provides five system-defined cost elements: Material, Resource (e.g., Labor),
Overhead, Material Overhead, and Outside Processing. These elements model the typical constituents
of a part’s cost. Unlimited sub-elements of these elements can be defined; for example, you might have
different types of labor or machinery as sub-elements of the Resource element or different overheads,
representing different types of expenses to absorb. You can define an unlimited number of cost types,
or sets of costs, for historical or simulation purposes. For example, in a standard cost environment you
will have a Frozen cost for valuation, but you might have historical costs, a pending cost to develop next
year’s standard, and simulated cost types for what-if analysis.

Oracle Cost Management evaluates transactions, assigns the appropriate cost, and transfers the
costed transactions periodically to the General Ledger. Similarly, most WIP movement transactions also
have financial implications; they typically involve the application of resources and absorption of
overhead. Cost Management also values these transactions and transfers the results to the General
Ledger.

Item Costing

When BPI defines an item, Oracle Cost Management creates an associated cost record. If no inventory
transactions have occurred, BPI can set the frozen standard cost for the item. If inventory transactions
have occurred, BPI must define a cost in a cost type other than Frozen and perform a cost update to
load a frozen cost for the item.

BPI will define the following costing sub-elements: Material, Material Overhead, Resources, Overhead
and Outside Processing.

 The raw material/component cost at the lowest level of the bill of material will be determined
from the unit cost of the component item. BPI will define a material sub-element called
MATERIAL. In Chowchilla, BPI will define a material sub-element called CORE for material
costs for dirty core items.

 BPI will use material overhead for any costs attributed to direct material costs. BPI will define
the following material overheads calculated as a percentage of the total cost: DC/ORG
BURDEN, DUTY, FREIGHT IN, and OCEAN.

 Direct resource costs, such as people (labor), machines, space, or miscellaneous charges,
required to manufacture products. Resources can be calculated as the standard resource rate
times the standard units on the routing, per operation, or as a fixed charge per item or lot
passing through an operation. Stanford and Chowchilla will define costed resources as per
their manufacturing requirements and apply the appropriate resource cost. The DC’s may also
define costed resources to track labor cost for replenishing branded product and repackaging
branded product.

537521414.docx August 21, 2013 Page 96 of 113

 BPI Solution Design Document

 The overhead cost of resource and outside processing, calculated as a percentage of the
resource or outside processing cost, as a fixed amount per resource unit, or as a fixed charge
per item or lot passing through an operation. Overhead is used as a means to allocate
department costs or activities. For example, BPI can define multiple overhead sub-elements to
cover both fixed and variable overhead, each with its own rate.

 Outside Processing (OSP) is the cost of outside processing purchased from a supplier. Outside
processing may be a fixed charge per item or lot processed, a fixed amount per outside
processing resource unit, or the standard resource rate times the standard units on the routing
operation. To implement outside processing costs, BPI must define a routing operation, and
use an outside processing resource. BPI will define OSP resources to track labor costs for
upgraded rotors that they purchase the coating and machining service from suppliers..

Cost Rollup

Bills and routings define the foundation for cost rollups, elemental distribution, and all related
manufacturing costing functions. The primary routing for the assembly determines the standard
resource, outside processing, and resource overhead costs of that assembly.

When BPI submits a cost rollup, they may include or not include unimplemented engineering change
orders. The cost rollup also considers the effective date. Components and resources with effective
dates on or before the rollup date are included in the rollup. The cost rollup does not include disabled
components or resources.

For phantom assemblies, the cost rollup includes the material costs and the routing costs in the cost of
higher-level assemblies. WIP charges and values phantom assembly material costs and phantom
assembly routing costs at this level.

Purchased assemblies show different elemental costs when BPI buys the assemblies rather than builds
or makes them.

 Buy Assembly: The total cost consists of the material and material overhead cost elements
only.
 Make Assembly: The total cost consists of the material, material overhead, resource, overhead,
and outside processing cost elements.

Therefore, the value of the material cost element may differ in buy versus make situations. The value of
the material cost element affects job cost, period close distributions, and variances.

Standard Cost Update

The standard cost update procedure lets BPI define and roll up pending costs, simulate changes to
standard costs for analysis, and then update pending costs to the Frozen standard cost type. BPI can
also define pending rates for resources and overhead.

537521414.docx August 21, 2013 Page 97 of 113

 BPI Solution Design Document

BPI can report pending adjustments to simulate a change in standard costs. These reports enable BPI
to preview the changes that the standard cost update would perform for current inventory balances.
These same three reports are run as part of a cost update.

Cost Management does not update the standard costs of those items for which BPI does not define a
cost. The standard cost is updated to zero only if BPI defines a zero cost for the item.

Period Close

The period close process for perpetual costing will allow BPI to summarize costs related to inventory
and manufacturing activities for a given accounting period.

Generally, BPI should open and close periods for each separate inventory organization independently.
By keeping only one period open, BPI can ensure that their transactions are dated correctly and posted
to the correct accounting period. (For month-end adjustment purposes, BPI can temporarily hold
multiple open periods.)

The accounting periods and the period close process in Cost Management use the same periods, fiscal
calendar, and other financial information found in General Ledger (GL). Inventory and Work in Process
(WIP) transactions automatically create accounting entries. All accounting entries have transaction
dates that belong in one accounting period. BPI can report and reconcile their transaction activity to an
accounting period and GL.

Process Flow

See BR01 – CST Requirements BPI and CS01 – CST Setup Configuration Document for detailed
design information.

537521414.docx August 21, 2013 Page 98 of 113

 BPI Solution Design Document

Subsystem Design – BPI-Specific Design Components

GM Forecast Upload
BPI receives order information from GM in EDI format, which includes records that are not firm. These
are treated as forecast demand. When orders become firm, they are included in the next EDI
transmission, and the forecast is relieved. A mechanism is required to provide visibility of GMs forecast
orders within Oracle.

To accommodate this requirement, a custom interface will be developed to populate an Oracle DRP
Forecast in the Stanford inventory organization, with forecast type data records transmitted via
Electronic Data Interchange (EDI) from GM. A Forecast within a Forecast Set in the Stanford Oracle
inventory organization will be populated for GM with the EDI-transmitted information. The forecast will
be utilized for information purposes only, so the Forecast Set will not be enabled for consumption by
sales order demands, and will not be loaded to the Master Demand Schedule (MDS) that is the source
demand schedule for the daily DRP plan.

See BR01 –SCP Requirements, FS01I – DRP Interface GM EDI Forecast and CS01 – SCP Setup
Configuration Document for detailed design information

Naperville Returns Report

A custom report will be developed to provide a forward-looking view of material requirements, if any, for
inventory at Naperville, so that appropriate decisions can be made regarding ship-to locations that
might best balance overall demand and supply across the BPI supply chain. This will help avoid
unnecessary material purchases, manufacturing, storage and transportation costs and bypass the need
for one-by-one lookups for each item involved. It will contain DRP planned orders for items that have
been returned to Naperville plus items of the same item categorization for Brand, Grade and Material.

The planned orders will be presented on the report for these items and their inventory organizations, in
a time-phased manner (as presented by DRP) that indicates earliest planned order start dates. The on-
hand inventory of the items at Naperville will also be included on the report.

See BR01 – SCP Requirements, FSR27 – DRP Naperville Returns Report and CS01 – SCP Setup
Configuration Document for detailed design information

Forecast Consumption Report

Forecast consumption occurs when sales order demands are matched to forecast entries, and the
sales order demand quantity decrements the forecast entry quantity for which the matching has
occurred. In cases where the matched sales order demand exceeds, or does not match, the forecast
entry quantity, Oracle creates over-consumption records. Forecast consumption details are available
for inquiry in the Forecast Sets/Forecasts forms of the Master Scheduling/MRP module, and there is a
report that also shows this type information, but there is no standard Oracle report that shows forecast
consumption exception situations,

To address this gap, a custom report will be developed to export the consumption information from the
Oracle Master Scheduling/MRP module to a pre-formatted Excel file.

537521414.docx August 21, 2013 Page 99 of 113

 BPI Solution Design Document

See BR01 – SCP Requirements, FSR28 – DRP Forecast Consumption Report and CS01 – SCP Setup
Configuration Document for detailed design information

Job Travelers

The manufacturing plants (Stanford and Chowchilla), and distribution centers (DCs), will need Job
Traveler document sets that are not supported by standard Oracle functionality. They will need to
include certain documents and bar-coded information functionality. In addition, Stanford, Chowchilla,
and the DCs each have unique requirements, such as stampbox information, requiring a specific format
for each.

To accommodate this requirement, the standard Discrete Job Packet, consisting of the Discrete Job
Pick List Report, Discrete Job Routing Sheet, and Discrete Job Shortage Report, will be modified to
print the appropriate information depending on plant or DC/location.

See BR01 – WIP Requirements, FS01R – WIP Job Travelers and CS01 – WIP Setup Configuration
Document for detailed design information.

Discrete Job Shortage Report

The manufacturing plants (Stanford and Chowchilla) require the ability to identify and analyze
component material shortages for a user-specified set of Standard Discrete Jobs. Although Oracle
Work-in-Process (WIP) supports this functionality along with a variety of practical user input parameters
and sort criteria, the standard Oracle report output is restrictive and cannot be exported to Excel. In
addition, a key user input parameter is not available for the standard Oracle shortage reporting
functionality.

To accommodate this requirement, a modified version of the standard Oracle WIP Discrete Job
Shortage Report will be created with an additional parameter and the ability to export results to Excel.

See BR01 – WIP Requirements, FS01R – WIP Discrete Job Shortage Report and CS01 – WIP Setup
Configuration Document for detailed design information.

ECO implementation Notification

BPI has a requirement to continue the existing process of notifying, via email, certain internal and
external personnel when an ECO has been implemented. The list may vary by ECO type. This
requirement is not supported by standard Oracle functionality.

In order to satisfy the requirement, a custom table will be used to maintain a list of email addresses that
need to be notified when an ECO has been implemented. An extension will also be developed to
determine when an ECO moves to ‘implemented’ status, and create emails to the applicable list of
addresses maintained in the custom table.

See BR01 – ENG Requirements, FSE48 – ECO Implementation Notification and CS01 – ENG Setup
Configuration Document for detailed design information.

537521414.docx August 21, 2013 Page 100 of 113

 BPI Solution Design Document

537521414.docx August 21, 2013 Page 101 of 113

 BPI Solution Design Document

Financial Management Design

Description

The Financials modules consist of Fixed Assets, Accounts Receivable, Cash Management and General
Ledger. Together, they support the following business processes:

Module Business Processes

Fixed Assets Asset additions, tracking and maintenance, retirements and
reinstatements, period end processing
Cash Management Bank account maintenance, bank account reconciliation, cash forecasting,
cash position
General Ledger Chart of Accounts (COA) definition and maintenance, journal entry
processing, account analysis and reconciliation, period end processing

Financial transactions will flow into the General Ledger from the Fixed Assets and Cash Management
sub-ledgers/modules via standard system interfaces.

In accordance with BPI project goals, standard Oracle Financials software configurations are utilized to
provide baseline functionality. In certain areas, this has been extended to support high-value BPI-
specific business requirements. Extensions to the software will be noted below in applicable sub-
system designs.

537521414.docx August 21, 2013 Page 102 of 113

 BPI Solution Design Document

Process Flow

General Accounting – Level 1

GA 1.0

Start Perform
Maintenance
General Accounting / Finance

GA 2.0 GA 4.0

Perform
Perform Period
Transaction
End Processing
Processing

GA 3.0

Perform Account
Analysis/
Reconciliation

Other APL
Systems:
Billing
CN Validation
Internal Customers

External
Systems And End
Reporting
Business
End
Intelligence

537521414.docx August 21, 2013 Page 103 of 113

 BPI Solution Design Document

Fixed Assets Level 1 Process Flow

General
Accounting
Asset Accounting

Accounts Asset Tracking & Period End

Start Asset Additions End
Payable Maintenance Processing

Asset System Retirements & Capital

Maintenance Reinstatements Planning
Business Unit

Change or
Dispose of Asset
Transfer Asset
Corporate

Develop Policies &

procedures

537521414.docx August 21, 2013 Page 104 of 113

 BPI Solution Design Document

CA Cash Management – Level 1

Financial
Planning
FP Cash
Forecasts

Bank Bank
Prior Day Account Account
Bank

Bank "Cash"
Balances/Current Balances/Activity Statements
Transfer Funds Prior Day's Bank
Day's Activity Activity Information

Start

CA 1.6
General Accounting

CA1.1 System CA 1.2 CA 1.3 CA 1.4 CA 1.5

Record Cash Perform Account

Perform Account Develop Cash Mobilize & Perform Bank Develop Cash
Receipts/ Analysis
Maintenance Position Transfer Funds Reconciliation Forecast
Disbursements

Concentration, CA 1.7
Receipt &
Disbursement Develop
Account Report Management
Reports

Accounting Accounting Accounting

Information "Book" Information Information
End

537521414.docx August 21, 2013 Page 105 of 113

 BPI Solution Design Document

Touch Points

Source Destination Description

Cost Management General Ledger Journal entries
Accounts Payable General Ledger Journal entries
Inventory General Ledger Journal entries
Accounts Payable Cash Management Payments
Accounts Payable Fixed Assets Asset-related expenditures (self-constructed and
purchased)
Fixed Assets General Ledger Depreciation, Adjustment, Retirement journal
entries
Accounts Receivable General Ledger Journal entries for invoices, receipts and
adjustments
Accounts Receivable Cash Management Receipts

537521414.docx August 21, 2013 Page 106 of 113

 BPI Solution Design Document

Data Conversion

Banks
Banks and bank account information for BPIs operating account at JP Morgan will be manually
converted from TOLAS. Bank and bank account information for supplier and employee accounts will be
converted from the Accounts Payable module in the interim Oracle instance. All bank accounts will be
converted into the Cash Management module in the new environment, which acts as a central location
for all bank-related data in R12.

Fixed Assets
Mass additions lines will be used to create assets within Oracle Assets using the current asset values at
the time of the Affinia split. All assets will be revalued in FAS prior to being converted into Oracle.
Assets will be converted into the Corporate book, then copied into the Tax, AMT and ACE books.

GL History
Period balances will be loaded using Dataloader. Historical data will not converted into the Enterprise
Business Suite.

See CV01 Data Conversion Strategy and Overview, FS01-, FS01-, and FS01- for detailed business
requirements and solution design.

537521414.docx August 21, 2013 Page 107 of 113

 BPI Solution Design Document

Security

Financials security will be managed using custom responsibilities. Users are granted access to one or
many responsibilities. Responsibilities provide all users with the same level of functional access as
each responsibility is configured to allow access to specific system functions. Some responsibilities will
be based upon standard (seeded) Oracle responsibilities, but custom versions will be created in order
to support future maintenance and enhancements.

Fixed Assets

Responsibility Description Audience

BPI FA XXXXXX Ability to…
BPI FA XXXXXX Ability to…
BPI FA XXXXXX Ability to…
BPI FA XXXXXX Ability to…
BPI FA XXXXXX Ability to…

See SM01 BPI FA Responsibilities for detailed security design.

Cash Management

Responsibility Description Audience

BPI CE XXXXXX Ability to…
BPI CE XXXXXX Ability to…
BPI CE XXXXXX Ability to…
BPI CE XXXXXX Ability to…
BPI CE XXXXXX Ability to…

See SM01 BPI CE Responsibilities for detailed security design.

General Ledger

Responsibility Description Audience

BPI GL XXXXXX Ability to…
BPI GL XXXXXX Ability to…
BPI GL XXXXXX Ability to…
BPI GL XXXXXX Ability to…
BPI GL XXXXXX Ability to…
BPI GL XXXXXX Ability to…
BPI GL XXXXXX Ability to…

See SM01 BPI GL Responsibilities for detailed security design.

537521414.docx August 21, 2013 Page 108 of 113

 BPI Solution Design Document

Subsystem Design – Standard Design Components

Chart of Accounts

In Oracle Applications, the Chart of Accounts (COA) refers to a segmented combination of values that
serve as the basis for recording and reporting financial transactions in the General Ledger. Every
transaction, whether originating in the General Ledger, the sub-ledgers/modules or external systems,
will be given a code combination from the Sub Ledger Accounting engine. The code combination
identifies which values to utilize each COA segment.

The Chart of Account design for the R12 environment is at a more summarized level than the legacy
environment. This can be achieved because the source transactions will be stored in Oracle sub-
ledgers, which allows detailed reporting to be moved from the General ledger to the sub-ledgers. The
new design is shown below:

Segment Length
Company 3
Location 2
A value set will be defined for each segment to ensure that only pre-
Account 5
Department 4 determined values and combinations can be used to record transactions.
Sub-Department 3 These are not expected to change frequently.
Inter-Company 3
Future 4 The Future1 segment will not be utilized and will be populated
with zeros. This segment was created specifically to
accommodate future changes in the BPI business model that might necessitate COA structural
revisions as standard Oracle EBS architecture makes the addition of segments extremely complex
once transactions have been generated in the system.

In order to integrate with legacy systems that are built upon the legacy COA design, translation rules
must be defined to map from old segment values to new and vice versa.

See BR01 – GL Requirements BPI and CS01 – GL Setup Configuration Document for detailed design
information.

537521414.docx August 21, 2013 Page 109 of 113

 BPI Solution Design Document

Translation & Consolidation

Translation
Oracle supports the ability to enter journals in a foreign currency. The pre-requisites for this are that the
currency must be enabled in the system. Initially, the following currencies will be enabled in the BPI US
Ledger:

 USD – US Dollars
 MXN – Mexican Peso
 CNY – Yuan Renminbi
 HKD – Hong Kong Dollar
 EUR – Euro
 GBP – Pound Sterling
 CAD – Canadian Dollar
 JPY - Japanese Yen
 STAT – Statistical Currency

When entering a foreign currency journal entry, the user will be required to specify a conversion rate
type. A type of Corporate will require that an exchange rate exist between the journal entry currency
and the ledger currency for the journal entry date. Corporate rates are used throughout the system.

Consolidation
BPI will maintain financial information in at least four ledgers (and currencies). As a result, a process to
consolidate that information into one ledger and one currency is required for financial reporting
purposes.

Part of the consolidation process will include the Translation of the non-US Dollar based ledgers into
US Dollars. The translated balances will then be accessed for financial reporting purposes.

In order to properly translate balances, the ability to specify period end conversion rates, period
average conversion rates, and historical exchange rates for some accounts is required.

As part of the consolidation process, journal entries will be required to post to elimination company
values to remove the intercompany activity. Where possible, the generation of these entries should be
automated in the system.

Financial Statement Reports will need to be designed in order to show the consolidated results, and the
break out of the consolidating entities.

537521414.docx August 21, 2013 Page 110 of 113

 BPI Solution Design Document

Consolidation Process

FSG Column definitions will point to

Confirm all
US Ledger GL User
Confirm Run translated ledgers in order to display
activity Update Run translated balances.
Translations Consolidating
entered and Period Rates Revaluation
complete FSG
posted Data Access set will be used to provide read
only access to non-USD based ledgers.
Enter Month End Revalue non-USD
and Period currency balances
Average rates for
ledger currency to
USD
Non-USD Based Ledgers

Confirm all
activity Update Run Run
entered and Period Rates Revaluation Translation
posted

Enter Month End Revalue non- Translate balances

and Period ledger currency to USD
Average rates for balances
ledger currency to
USD

See BR01 – GL Requirements BPI and CS01 – GL Setup Configuration Document for detailed design
information.

Asset Management

Oracle Assets will be used to manage all BPIs financial and tax-related asset information. Four asset
books will be created to manage the data for both corporate reporting and tax purposes: Corporate,
Tax, ACE and AMT.

Assets will be converted from FAS into the Corporate book, then copied into the tax books. New assets
will typically be interfaced from the Accounts Payable module once the invoice paying them have been
validated and accounted. Invoice lines interfaced from Accounts Payable will be prepared in the Mass
Additions Workbench prior to being posted into the Corporate book and copied into the Tax books (see
below).

Similarly, most updates to asset information will be performed in the corporate book before being
copied to the Tax books (see below).

At month-end, depreciation will be computed for the Corporate book using standard Oracle processes.
Following successful computation of depreciation, the transactions for the month that were entered to
the Corporate book will be copied into the Tax books using the Mass Copy feature of the Oracle Asset
system. Mass Copy will populate the Tax books by adding asset modifications or new assets to the
Tax books from the Corporate book. Finally, depreciation for the Tax books will be computed. BPI will
run depreciation on the tax books quarterly. Following depreciation in all books, journal entries can be
generated for the month’s transactions and for the adjustments to Tax transactions.

BR01 – FA Requirements BPI and CS01 – FA Setup Configuration Document

537521414.docx August 21, 2013 Page 111 of 113

 BPI Solution Design Document

Bank Statement Reconciliation

Statements from JP Morgan Chase will be downloaded each day to for reconciliation and to support
cash forecasting and positioning. Customer receipt transactions, miscellaneous receipts, payroll
summary transfer amounts, investment sweeps will be available for reconciliation.

Electronic bank statements will be downloaded from JP Morgan each day and loaded into the Cash
Management module. Bank statement lines will be reconciled automatically using a standard Oracle
process against payments processed in Accounts Payable and invoices generated in Accounts
Receivable. Lines that cannot be matched by the Oracle auto-reconciliation process will be matched
manually.

Bank Reconciliation

Bank Sends File

Start with Statement
Bank

Details

Run Concurrent Run Concurrent

Request to Load Request to Import Run Manually Clear
Bank Statement to Bank Statement for Autoreconciliation Remaining Items
Interface Tables Processing
Accounting

Flag Statement as
End Complete Once
Fully Reconciled

See BR01 CE Requirements and FS01 – CA Bank Statement Interface for detailed design information.

537521414.docx August 21, 2013 Page 112 of 113

 BPI Solution Design Document

Period Close

Period end close processing will be comprised of manual steps, such as account reconciliations; and
system steps, such as physically closing a subledger (e.g. AP, FA, INV) period in Oracle.

The subledgers need to be closed in a specific sequence in order for information to flow through the
system properly. For example, since AP invoices are a source for Fixed Asset additions, all AP invoice
entry needs to be completed prior to the Mass Additions upload being executed in Fixed Assets.

The individual modules have accounting processes that will need to be executed to transfer
transactions into the Sub-Ledger Accounting (SLA) module and then through to the general ledger.
The processes will be scheduled to run at regular intervals (daily/weekly), and then manually executed
at month end.

In order to close periods in Oracle, all transactions within the period need to be accounted for in the
system. Some modules, like Accounts Payable, have the ability to sweep unprocessed transactions
into the next period; other modules like Accounts Receivable do not and will require the users to correct
any issue or to manually change the transaction into the next period.

Match to POs, receipts accrue uninvoiced receipts

Purchasing

Account for invoices,

Cash payments
Payables
Management

Bank reconcilation creates

accounting entries in AP; Fixed Assets General Ledger
Often occurs after initial Feed asset invoices to FA Account for assets,
AP close depreciation

Account for inventory, wip, cogs

Inventory

Revenue Recognition /
COGS Recognition
Processes

Account for revenue, AR, cash receipts

Order
Receivables
Management

Accounting processes run from:

Accounts Receivable --- Submit Accounting

Accounts Payable --- Create Accounting
Fixed Assets --- Create Accounting – Fixed Assets
Cost Management (covers Inventory, WIP, Purchasing) --- Create Accounting – Cost Management

See BR01 – GL Requirements BPI and CS01 – GL Setup Configuration Document for detailed design
information.

537521414.docx August 21, 2013 Page 113 of 113