Shop Floor Manager (OSFM) and
Business to Business (B2B)
Tips and Fabless Semiconductor
Implementation Example
Jerry Edwards
1
Definitions:
• Shop Floor Manager (OSFM): Lot centric and lot/serial
number centric manufacturing product
• Stage: Product physical state and unit of measure.
Semiconductor stages include:
• FAB, BUMP, SORT, DIE, ASSEMBLY, TEST, FGI
• Flow: Product stage sequence / consistent network
routings in each stage
• Binning: Process that results in multiple output parts
based on process results (usually test)
2
Definitions: …continued
• Event: Action affecting a product lot that vendor must
report (Receipt, Start, Move, Completion, Ship, etc.)
• Data element: specific data column required in an event.
Events have multiple data elements.
• Business to Business Communications (B2B):
Subcontractor manufacturing event communication and
processing into Oracle applications.
• Rosettanet 7B1 PIP: Process information protocol for
manufacturing events.
• Adaptor: Custom software to generate Oracle
application transactions based on vendor reported
events
3
Presentation Scope:
• OSFM Best Practices
• Product structure
• Network routing scope
• OSFM Tips and tricks
Mapping subcontractors into OSFM
• Single inventory organization for all vendors
• Vendor specific inventory organizations
• B2B Process Outline
• Fabless Semiconductor (B2B) Functional
Specifications and Solution Design Example
• B2B Process Outline Details
4
OSFM Product Structure Suggestions
• Define separate part numbers for each stage where lots will flow in
and out of stock (subinventories) and where wafers are converted
to unassembled die (physically on the wafer but counted in dies)
• Typical stages: FAB / BUMP / SORT / DIE/ASSEMBLED DIE /
TESTED DIE / FINISHED DIE
• Network routing scope:
• Start and complete work orders at the same subcon for a single
part number (stage)
• Move from stockroom to stockroom between subcons
• Keep routings simple: add operations to track lot progress,
separate scrap transactions by value adding operation,
separate operation yields, and to separate pay points.
• Define alternate paths if required
5
OSFM TIPS & TRICKS
• Co-Products: Use co-product %’s to enter test binning expected
results to drive over-planning by ASCP.
• Note: user must enter primary bill via co-products form to use
this feature. User cannot enter bill via bill of material form and
then add co-product %’s in co-products form.
• WIP Lot Bonus:
• Starting job value is based on previous operation
• Start network routings with dummy IN operation and use WIP
Lot Bonus at subsequent operations only. Do not use WIP Lot
Bonus into the first operation as component value is excluded
resulting in inaccurate job costs. Each network routing requires
minimum 3 operations other than wafer-to-die conversion.
6
OSFM TIPS & TRICKS
• Binning Process Options:
• During Work Order: Perform WIP Split and update assembly
(resulting part number) for each bin. Note: Update assembly
treats update as a move so do not use update assembly at
queue intra-operation step of an operation with OSP resource or
you will duplicate purchasing activity. Work around: Move lot
out of queue intra-operation step to prevent duplicate
purchasing activity.
• Post Work order: Complete work order, then perform Inventory
lot split and Inventory lot translate for each bin to change the
part numbers.
• OSP Receiving:
• Assign OSP resources so that quantity moved in will be correct
OSP requisition quantity. For example: assembly charges for
good quantity only. Assign OSP to operation after assembly.
• Automate OSP receipts based on blanket releases.
7
OSFM TIPS & TRICKS
• Supervisor Workbench versus Move form
• Viewing many job versus playing transactions for specific jobs
8
OSFM TIPS & TRICKS
• Supervisor Workbench versus Move form
• Move form faster for playing specific job moves.
9
OSFM TIPS & TRICKS
• Partial Move Behavior
• Move quantity retains mother lot name (not updateable) instead
of a default child lot name. This is mismatch to real world lot
naming as move quantity is usually the child lot.
10
OSFM TIPS & TRICKS
• Lot Create Work Order default lot name
• Default lot name assumes a split. If using full lot drop the suffix.
11
OSFM TIPS & TRICKS
• Problem with Combine move and scrap at an operation
where outside processing resource is linked.
• OSP requisition is incorrectly the post (after) scrap quantity
instead of the correct pre-scrap quantity.
12
OSFM TIPS & TRICKS
• Recommended Custom Reports:
• Work Order Location (current operation) for all
released jobs
• Actual yield versus estimated yield by job and part
number based on user entered date range.
– Columns include quantity and value actual versus expected
– Individual lot based job rows with subtotals by part number
• For Automated B2B include a form to perform:
– Query errored events
– Correct event errors by changing column data
– Change event status to trigger event validation reprocessing.
13
Suggested Enhancements
• Sub-lots: Use for die parts
• Enables user to track good die by wafer in die bank. Each
wafer is a die sub-lot. User selects sub-lots when selecting lots
and lot create form accumulates quantities into the child lot.
Today user cannot track good die by wafer unless treating each
wafer as a separate lot (not feasible).
• Co-products
• Enable user to enter co-products and expected binning %’s for
parent (resulting) parts where bills of material already exist that
were NOT created via the co-products form.
• Lot Create:
• Default mother lot number into resulting lot field.
• Add default split lot extension if user enters a quantity less than
full lot (add extension when user tabs from quantity field)
14
Suggested Enhancements
• Genealogy network (source and where used)
• Explode with single select in the top row
• Control with profile option
15
Vendor mapping to OSFM
Options
• Single inventory organization for all vendors
• One Inventory organization per vendor
• Hybrid:
• Separate inventory organizations for major vendors
• Single inventory organization for smaller volume vendors
• Note: This requires a dual design for B2B automation to
support both mapping designs simultaneously
16
Mapping subcontractors to OSFM
– Single inventory organization for all vendors
• Represent vendors via subinventory names to represent
vendor / product stage
• Setup an intransit subinventory to track lots moving between
vendors
• + for monthly close
– One inventory organization to close
– Note: Organization Hierarchies are available in HR to
automatically close all inventory organizations in a
hierarchy
• - (negative) For Advance Supply Chain Planning
– Sourcing rules apply to inventory organizations so ASCP
cannot recommend vendors via sourcing rules
– Excludes product transit time among vendors
– Prevents easy-to-use subcon specific resource capacity
planning in network routings
17
Mapping subcontractors to OSFM
• Separate inventory organizations for each vendor
• Subinventories represent product stage at each subcon
• - for product costs (more complex)
– Mitigate by maintaining costs in the item master
organization and using copy cost to pull costs into each
subcon inventory organization
– Supply chain cost rollup is available when sourcing
chains are complete
• - for monthly close (multiple organizations to close). Mitigate
by setting up organization hierarchies in HR so user can
close a hierarchy (one transaction)
• + for Advanced supply chain planning
– Sourcing rules for vendor inventory organization
– Explicit transit times
– Facilitates subcon specific resource capacity planning
18
Mapping subcontractors to OSFM
• Separate inventory organizations for each vendor
• + for customer required subcon specific supply chains
• Enter a customer specific orderable part
• Enter supply chain specific sub-assemblies
• Enable supply chain specific parts in correct subcons
(only)
19
B2B Process Outline
1.
2.
3.
4.
5.
6.
7.
Collecting subcon event data
Staging tables database
Subcon event processing
Subcon B2B performance measurement
Backup Processes
Subcon bring-up for manual and automated reporting
B2B Project suggestions
20
Fabless Semiconductor (B2B) Functional
Specifications and Solution Design Example
Fabless Semiconductor Business process Scope:
–
Subcontractor manufacturing event communication
–
Staging Table scope, event validation, error correction, generating
and sequencing lot based Oracle application transactions
–
Oracle transaction upload via application program interfaces into
Oracle purchasing, inventory, and OSFM application modules
21
Fabless Semiconductor (B2B) Functional
Specifications and Solution Design Example
•
•
•
•
•
Business Process Overview
Staging Tables Scope
Manufacturing Event 7B1 Process Flow
Process Flow Details
B2B Event Handler Process
–
Execute preceding events filter process
• Reported stage/event
• Allowed preceding event
• Lot last successful event
–
–
•
Perform Level 2 Content Validation
Oracle Transactions Logic for each Stage/Event
Automated Purchase Order Receiving for Outside processing
services
22
Fabless Semiconductor (B2B) Functional
Specifications and Solution Design Example
•
Business Process Overview
–
Subcontractor event reporting and collection as per industry
standard format 7B1.
–
Perform format (level 1) validation
–
Report level 1 errors to subcontractors
–
Stage level 1 pass events in a new database
–
Track event status
–
Perform event matrix test:
• Content check for valid stage and event
• Filter events prior to data content validation (level 2) based
on predecessor event maps
• Place events that fail predecessor event check into pending
status
• Queue passing events for level 2 (further content validation)
23
Fabless Semiconductor (B2B) Functional Specifications
and Solution Design Example
•
Business Process Overview
–
Perform data content validation (level 2) on events that pass
predecessor event check
•
For level 2 pass events: For events that pass level 2 validation:
Change transaction status code to indicate PASS (VA in example)
•
Sequence events
– Sort events by event_id within lot number within part number
(requires securing an event id from subcontractors that is easily
sorted)
•
For each event generate appropriate Oracle transactions (map
events to required Oracle transactions)
•
Upload transactions to application program interfaces
•
Track interface results
•
Update event status
•
Track event success history
•
Maintain event error history
24
Fabless Semiconductor (B2B) Functional
Specifications and Solution Design Example
•
Business Process Overview
–
–
–
Provide subcontractor event quality reports
B2B Management Workbench
•
Subcon setup
•
Error correction
•
Reset event status to force level 2 validation
•
Pending Event handler.
•
Maintain Lookup tables.
Logic requirements for B2B Error Handler
•
Update event status to error
•
Generate user friendly error explanations
•
Provide user access to correct errors and resubmit events for level 2
validation by changing data and event status code
25
Fabless Semiconductor (B2B) Functional Specifications
and Solution Design Example
•
Staging Tables Scope
–
–
Dynamic data
•
Subcontractor Reported events
– Subcontractor events as reported
– Subcontractor event errors
– Subcontractor event current data content and status
– Subcontractor events successfully interfaced into Oracle applications
(history table)
Static (Setup Data)
•
Event Filtering matrices: For each stage (FAB, SORT, etc.) and event
(RECEIPT, etc.)
– Allowed Preceding Events (Predecessor) by flow/stage/event
•
Level 2 (Content) Error codes and messages
•
Subcon site data
– Subcon mapping to inventory organization. Each subcon is represented
as a separate inventory organization: Site DUNS # is tied to the vendor
(subcon) site setup which, in turn, identifies the inventory organization.
26
Fabless Semiconductor (B2B) Functional
Specifications and Solution Design Example
•
Staging Tables Scope: example of as reported event columns
27
Fabless Semiconductor (B2B) Functional
Specifications and Solution Design Example
•
Staging Tables Scope…continued
–
–
–
–
Flow/stage/event allowed predecessor events
Last successful event by lot
Events with errors (history for quality reporting)
Other look up tables where look up is 100% consistent
28
Fabless Semiconductor (B2B) Functional
Specifications and Solution Design Example
•
Manufacturing Event 7B1 Process Flow (Client example)
29
Fabless Semiconductor (B2B) Functional Spec
Application Server Integration
30
Fabless Semiconductor (B2B) Functional Spec
BPEL Transformation / Populate Staging tables
31
Fabless Semiconductor (B2B) Functional Spec
BPEL Transformation / Populate Staging tables
32
Fabless Semiconductor (B2B) Functional
Specifications and Solution Design Example
•
Process Flow Details
–
Subcontractor event reporting and collection as per industry
standard format 7B1.
–
Perform format (level 1) validation available from standard B2B
software
•
Expected File format
•
File Parsing Error
•
Zero Byte check
•
Mandatory Fields as per 7B1 RosettaNet standards
requirement (we are optional rows to meet business
requirement which we will verify in level 2 content
validation/check)
33
Fabless Semiconductor (B2B) Functional
Specifications and Solution Design Example
•
Process Flow Details
–
BPEL Transformation and population of the staging table :
•
Transport to message queue successful
•
Check for staging db available
– if it is up then insert into staging
– If the staging db is not up then BPEL will wait for some
time and sending an email
•
Successful load to B2B tables (Pass messages)
•
Incorrect File according per DSPG requirements
•
Future enhancement #1: Check for daily transmission from
subcon to validate communications even if subcon has no
events to report.
–
Communicate level 1(format) errors to subcontractors
34
Fabless Semiconductor (B2B) Functional
Specifications and Solution Design Example
•
Process Flow Details
–
–
Insert level 1 pass events in a new database (staging tables)
Track event status: Proposed statuses
– NE = new Loaded into staging tables
– QU = Passed event matrix test: Ready for level 2 validation Passed
event matrix check
– PE = Pending, Failed filter process due to incompatible last successful
event (for the event lot)
– VA = Validated: ready for sequencing and submitting to Oracle
application interfaces
– ER = Error (content)
– IN = Sequenced (event id within lot number for each part number) and
submitted to application interfaces (API’s)
– FA = Failed Oracle interface
– SU = Successfully processed into Oracle applications
– ME = Manual entry , not further action required .
– NA = As we got from the sub contactor we nothing to do with it.
– None; Applicable to internal build event where we search for work order
35
requirement from Build request file and none exists.
Fabless Semiconductor (B2B) Functional
Specifications and Solution Design Example
•
B2B Event Handler Process
–
Filter events prior to data content validation (level 2) based on
predecessor event maps
–
Setup, for each stage (FAB, SORT, ASSY, FG, PREASSEMBLY) and event (RECEIVE, START, MOVE, etc.)
combination generate a look up table (matrix) containing
allowed predecessor stage/events for the reported stage/event
combination.
36
Fabless Semiconductor (B2B) Functional
Specifications and Solution Design Example
•
B2B Event Handler Process
–
Filter events prior to data content validation (level 2) based on
predecessor event maps
–
Setup, for each stage (FAB, SORT, ASSY, FG, PREASSEMBLY) and event (RECEIVE, START, MOVE, etc.)
combination generate a look up table (matrix) containing
allowed predecessor stage/events for the reported stage/event
combination.
–
Perform Level 2 data content validation
•
Global (all events) validation logic and Event Specific validation
logic
37
Fabless Semiconductor (B2B) Functional
Specifications and Solution Design Example
•
B2B Event Handler Process
–
•
For validated events generate required Oracle transactions
•
Receipt event: Generate appropriate receipt
•
Start event: Generate lot based job
•
Etc.
Automated Purchase Order Receiving for Outside processing
(OSP) services
–
–
Generate automated blanket releases for OSP via standard blanket
release, sourcing rule, and sourcing assignment setups)
Generate outside processing blanket release receipts as soon as the
blanket release occurs
38
Fabless Semiconductor (B2B) Functional
Specifications and Solution Design Example
(last example slide)
•
B2B Event Handler Process: Error Correction HTML form
39
B2B Process Outline…Best Practice
1.
2.
3.
4.
5.
6.
7.
Collecting subcon event data
Staging tables database
Subcon event processing
Subcon B2B performance measurement
Backup Processes
Subcon bring-up for manual and automated reporting
B2B Project suggestions
40
B2B Process Outline…
1.
Collecting vendor event data…
•
Define stages and events within each stage by product line
•
Define product lines: Product line scope:
• same stage sequence
• same events within each stage
• products with the same stage sequence and events
constitute a product flow
•
•
Define stage and event matrix
Define valid predecessor events for each stage/event
•
Define event data elements
• Oracle transaction data elements
• B2B data elements
41
B2B Process Outline…
1.
Collecting vendor event data…continued
Sample Stage and Event Matrix
42
B2B Process Outline…
1.
Collecting vendor event data…continued
•
Define data elements for each stage and event combination
43
B2B Process Outline…
1.
Collecting vendor event data…
Stage and event example: SHIP at FAB
EVENT CODE
SHIP
Vendor ID
This field represents the Partner’s DUNS number and needs to
be reported by every partner.
Vendor Location ID
This field represents the Location DUNS number for Vendor
Site location at which the respective manufacturing stage is
being processed.
To Vendor ID
This field represents the ship-to vendor’s Location DUNS
number.
44
B2B Process Outline…
1.
Collecting vendor event data… continued
SHIP at FAB: Stage and event Example continued…
Transaction ID
Vendors need to report a transaction identifier that will be
unique for all the events that are being reported by the
vendor. This field eliminates confusion between user and
vendor when errors occur with a transaction.
Transaction Date and Time
Vendors need to report all the transactions in GMT time and in
24 hr format. Code the value as per xml format
‘YYYYMMDDThhmmssZ’.
Part Number
This field represents a user part number being purchased as
per PO line provided to the FAB vendor .
Manufacturer Part Number:
This field represents the FAB part number assigned by the
Wafer Foundry that cross references to the user part
number.
45
B2B Process Outline…
1. Collecting vendor event data… continued
SHIP at FAB: Stage and event Example continued…
Lot Stage Identifier
This field represents physical location of the lot in the
manufacturing cycle. This is a hardcoded field and needs to be
reported as “FAB” all the time for all transactions being
reported as shipment from the FAB vendors.
Lot Type Classification
This field represents the classification of the Lot and has two
possible choices,
Engineering
Production
This is needed if vendors cannot omit engineering lots from
reporting.
Lot Number
This field represents the FAB assigned lot number to the lot that is
being shipped by the FAB vendor. Each event requires a
unique lot number. Do not report the same part number, lot
number for multiple shipments.
46
B2B Process Outline…
1. Collecting vendor event data…continued
SHIP at FAB: Stage and event Example continued…
Lot Quantity
This field represents the full lot quantity being shipped for the
purchased part number
PO Number
This field represents the NetLogic PO number for the purchased
wafer. and lot
PO Line Number (optional)
This field represents the NetLogic assigned PO Line number for the
purchased part number and lot. Note: automation will be
easier if the FAB vendor can supply the PO line number in
addition to the PO number.
REPEAT FOR ALL PRODUCT LINE STAGE/EVENTS
47
B2B Process Outline…
1.
Collecting vendor event data…continued
•
Generate vendor reporting requirements document to include:
•
Reporting rules by stage
•
Stage and event data elements with explicit definitions
•
Provide spreadsheet event samples
48
B2B Process Outline…
1.
Collecting vendor event data…
•
Generate Network Routing Flow document
• Routing flow for each product line, stage, and flow
• Enables vendors to map their routings to OSFM
network routings
• Multiple vendor operations may occur for each OSFM
operation
• OSFM operations are based on tracking locations,
operation yields, scrap locations, operation lead times,
and manufacturing service pay points.
49
B2B Process Outline…
1.
Collecting vendor event data…
•
Generate vendor communications bring up document:
• Manual reporting
• Automated reporting
50
B2B Process Outline…
1.
Collecting vendor event data…
•
Manual Reporting
• Require event reporting that builds foundation for and
eases transition to automated reporting
• Do not derive Oracle application transactions from vendor
snapshots (shop floor picture or lot location report)
• Error prone
• User accepts ownership for playing the correct
transaction rather than the vendor accepting
responsibility to report correct event data and sequence
51
B2B Process Outline…
1.
•
Collecting vendor event data…
Select data collection process and event data format and
language
•
Data Collection Process Options
• File Transfer Protocol (FTP) or secure FTP
• Vendor places file on a server
• User retrieves the file from the server
•
B2B Software (Web Services) TIBCO, BEA, IBM, etc.
• Vendor communicates specific data package
• B2B software authenticates, validates, and passes
event to a B2B database
52
B2B Process Outline…
1.
•
Collecting vendor event data…
Event Data Formats and language
• .CSV files, comma delimited flat files matching user
proscribed format and text language
• RosettaNet Partner Interface Process (PIP): Map event
data elements to pre-defined 7B1 rows.
• Each PIP specification includes a business document
and a detailed business process that includes
interaction, data transmission, security and errorhandling requirements.
• Language: usually XML
53
B2B Process Outline…
1.
–
Collecting vendor event data…
Data Formats and language
• Extensible Markup Language (XML)
• XML was designed to describe data and to focus on
what data is.
• The Main Difference Between XML and HTML
• XML was designed to carry data.
• XML is not a replacement for HTML.
XML and HTML were designed with different goals:
• XML was designed to describe data and to focus on
what data is.
HTML was designed to display data and to focus on
how data looks.
• HTML is about displaying information, while XML is
about describing information.
54
B2B Process Outline
1.
•
Collecting vendor event data…
XML Example:
• <note>
• <to>Tove</to>
• <from>Jani</from> <heading>Reminder</heading>
• <body>Don't forget me this weekend!</body> </note>
• The note has a header and a message body. It also has
sender and receiver information. But still, this XML
document does not DO anything. It is just pure information
wrapped in XML tags. Someone must write a piece of
software to send, receive or display it.
55
B2B Process Outline…
1.
•
Collecting vendor event data…
Data Formats
• RosettaNet 7B1
• Simple Object Access Protocol (SOAP) 1.1
• XML based protocol that consists of three parts: an
envelope that defines a framework for describing what
is in a message and how to process it, a set of
encoding rules for expressing instances of applicationdefined data types, and a convention for representing
remote procedure calls and responses.
• ebXML Business Process Specification Schema (BPSS)
ebXML
• (Electronic Business using eXtensible Markup
Language), is a modular suite of specifications that
enables enterprises of any size and in any geographical
location to conduct business over the Internet.
56
B2B Process Outline…
1.
Collecting vendor event data…
•
Generate a trading partner agreement (TPA) with each
vendor.
• Communication process (FTP, Web Service, etc.)
• Event content
• Communication frequency (daily, per shift, etc.)
• Error Handling
• Level 1: format
• Level 2: content
• Vendor bring up and certification process
57
B2B Process Outline…
2. Vendor event database
•
Event Processing
•
Level 1 Validation of vendor events
• File Format
• Data file uniqueness
• File Parsing (corrupt data)
• Successful insert to vendor data base
• Send response to vendor for each reported event
58
B2B Process Outline
2. Vendor event database…
•
Event storage
•
Convert vendor reported event into an input record for
the vendor database.
•
Insert vendor reported events into a common database
independent of the manner in which vendors reported
the event. This is often referred to as a canonical
database.
59
B2B Process Outline…
2. Vendor event database…
•
Event storage…continued
• Store events as reported but enable error correction
process to change event data elements PRIOR to
generating and uploading Oracle applications
transactions.
• Generally vendors resend events for level 1 errors only
• Vendors resend events with new transaction ID’S for a
level 2 (content) errors.
60
B2B Process Outline…
2.
Vendor event database…
•
Maintain event status codes (details in next section)
•
Event archive and purge: Provide process to archive data
and reduce active database size.
61
B2B Process Outline…
3.
Vendor event processing
•
Event status: Maintain vendor reported event processing
status codes per event
•
New: Loaded into staging tables: passed level 1 validation
•
Pending: Event is out of sequence based on Product line,
stage, and event allowed predecessor events.
•
Error: Data content (based on level 2 validation)
•
Queue: Event ready for level 2 validation
•
Ready for Upload to Oracle applications
•
Error: Upload error in Oracle open interface
•
Successful Upload: Loaded successfully through open
interface into Oracle application
62
B2B Process Outline…
3.
Vendor event processing…
•
Error Checking: Design Level 2 (content) validation to
ensure generated Oracle applications transactions will
process successfully through Oracle application open
interface tables.
•
Design level 2 error checks by product line, stage, and
event. (samples follow)
63
B2B Process Outline…
3.
Vendor event processing…
•
Receipt
• Validate correct event sequence (check last successful
event and pre-defined event sequence table)
• Valid part#/Lot#/Quantity
• Correct vendor mapping ( INV ORG and vendor
subinventory mapping)
• Report lot attributes if required at reported stage
64
B2B Process Outline…
3.
Vendor event processing…
•
Split/Merge processing
• Validate correct event sequence (check last successful
event and pre-defined event sequence table)
• Valid part#/Lot#/Quantity
• Required fields available
• Meets pre-defined split and merge business rules
65
B2B Process Outline…
3.
Vendor event processing…
•
Start: Work order start
• Validate correct event sequence (check last successful
event and pre-defined event sequence table)
• Valid part#/Lot#/Quantity
• Required fields available
• Valid bill of material and routing
• Valid component part#, lot, quantity, or component lots
(multiple components)
• Report lot attributes if required at reported stage
66
B2B Process Outline…
3.
Vendor event processing…
•
Map events to Oracle transactions: Adaptor will generate
appropriate Oracle transactions or series of transactions
for successful event. Examples follow:
• Receipt: Inventory receipt
• Split: Inventory lot or work order lot split
• Merge: Inventory lot or work order lot merge
• Start: work order start
• Move: work order move
• Complete: work order move/complete
• Ship: Inventory lot transfer or inter-org transfer
67
B2B Process Outline…
3.
Vendor event processing…
•
Error correction process requirements
•
Track errors in the vendor event database by maintaining
error codes and explanations
•
Link appropriate error code to vendor event records where
errors are identified
68
B2B Process Outline…
3.
Vendor event processing…
•
Error correction process requirements...continued
•
Develop user form based interface to:
• Query errored events and enter data corrections. The
goal is to correct errors rather then deleting records and
having vendors resend. Each vendor input event is a
unique transaction regardless of transaction data.
•
User resets event status code so that adaptor next run
will recheck this event and if successful generate
Oracle transaction and upload to Oracle applications
69
B2B Process Outline…
3.
Vendor event processing…
•
Event sequencing requirements: Sequence events by
maintaining product line and stage allowed event sequence
matrices. This is a key process.
•
For some events multiple predecessor and successor
events are possible.
•
Generate Oracle applications transactions for events that
pass level 2 validation.
70
B2B Process Outline…
3.
Vendor event processing…
•
Load transactions to Oracle interfaces
•
Identify errors in Oracle interface: Record data and remove
errored records from Oracle open interfaces. Report errors
so that users can correct input data or address and Oracle
software based problem.
•
Event status changes: Update event status as event is
processed into Oracle applications
71
B2B Process Outline…
4.
Vendor B2B performance measurement
•
Generate reports that measure vendor reporting results
• Timely reports
•
Accuracy by stage and event and part#.
•
Report comparing vendor system on hand balances
and open work orders with Oracle application onhand balances and open work orders.
72
B2B Process Outline…
5. Backup Processes
•
Vendor reporting: alternate reporting method if automated
reporting is down. May be possible depending on volume
•
Vendor event processing if automated system is down for
extended period. Playing transactions directly into Oracle
applications.
•
Holding events when ERP system is down.
73
B2B Process Outline…
6. Vendor bring-up for manual and automated reporting
•
Key Documents for vendors
• B2B MFG Vendor reporting requirements document
• Reporting rules by stage and event
• Event reporting details by stage and event
• Event sample spreadsheet
• User Product Routing flows
• Vendor communications process
74
B2B Process Outline…
7. B2B Project suggestions
•
•
•
•
•
•
•
Vendors need to understand user part numbers, product
structures, and network routings.
Vendors report user part numbers and lot numbers and user
operation codes (work order move events)
Generate consistent reporting process across all vendors
Allow time for rigorous event testing
Parallel testing with real data is wise particularly if volume is
high
Expect high error volume at first
Go live when you can correct errors within one day and..
• Error correction is effective and fast
• Vendors respond quickly to reported errors
75
B2B Process Outline
•
•
•
•
Contact Information
Jerry Edwards
jkedwards2002@hotmail.com
650-799-6699 (cell)
76