Shop Floor Manager (OSFM) and Business to Business (B2B) Tips and Fabless Semiconductor Implementation Example

1
Shop Floor Manager (OSFM) and Business to
Business (B2B) Tips and Fabless Semiconductor
Implementation Example

• Jerry Edwards

2

• 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)

3

• 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

4

• 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

5

• 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

6

• 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.

7

• 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.
  

8

• OSFM TIPS TRICKS
• Supervisor Workbench versus Move form
• Viewing many job versus playing transactions for
  specific jobs

9

• OSFM TIPS TRICKS
• Supervisor Workbench versus Move form
• Move form faster for playing specific job
  moves.

10

• 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.

11

• OSFM TIPS TRICKS
• Lot Create Work Order default lot name
• Default lot name assumes a split. If using full
  lot drop the suffix.

12

• 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
13

• 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
  re-processing.

14

• 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)

15

• Suggested Enhancements
• Genealogy network (source and where used)
• Explode with single select in the top row
• Control with profile option

16

• 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

17

• 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

18

• 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

19

• 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
20

• B2B Process Outline
• 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

21

• 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

22

• 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

23

• 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)

24

• 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

25

• 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

26

• 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.

27

• Fabless Semiconductor (B2B) Functional
  Specifications and Solution Design Example
• Staging Tables Scope example of as reported
  event columns

28

• Fabless Semiconductor (B2B) Functional
  Specifications and Solution Design Example
• Staging Tables Scopecontinued
• 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

29

• Fabless Semiconductor (B2B) Functional
  Specifications and Solution Design Example
• Manufacturing Event 7B1 Process Flow (Client
  example)

30

• Fabless Semiconductor (B2B) Functional Spec
• Application Server Integration

31

• Fabless Semiconductor (B2B) Functional Spec
• BPEL Transformation / Populate Staging tables

32

• Fabless Semiconductor (B2B) Functional Spec
• BPEL Transformation / Populate Staging tables

33

• 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)

34

• 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

35

• 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 (APIs)
• 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 requirement from Build
  request file and none exists.

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,
  PRE-ASSEMBLY) and event (RECEIVE, START, MOVE,
  etc.) combination generate a look up table
  (matrix) containing allowed predecessor
  stage/events for the reported stage/event
  combination.

37

• 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,
  PRE-ASSEMBLY) 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

38

• 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

39

• Fabless Semiconductor (B2B) Functional
  Specifications and Solution Design Example (last
  example slide)
• B2B Event Handler Process Error Correction HTML
  form

40

• B2B Process OutlineBest Practice
• 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

41

• B2B Process Outline
• 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
42

• B2B Process Outline
• Collecting vendor event datacontinued
• Sample Stage and Event Matrix

43

• B2B Process Outline
• Collecting vendor event datacontinued
• Define data elements for each stage and event
  combination

44

• B2B Process Outline
• Collecting vendor event data
• Stage and event example SHIP at FAB
• EVENT CODE
• SHIP
• Vendor ID
• This field represents the Partners 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 vendors
  Location DUNS number.

45

• B2B Process Outline
• 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.

46

• B2B Process Outline
• 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.

47

• B2B Process Outline
• Collecting vendor event datacontinued
• 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

48

• B2B Process Outline
• Collecting vendor event datacontinued
• Generate vendor reporting requirements document
  to include
• Reporting rules by stage
• Stage and event data elements with explicit
  definitions
• Provide spreadsheet event samples

49

• B2B Process Outline
• 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.

50

• B2B Process Outline
• Collecting vendor event data
• Generate vendor communications bring up document
• Manual reporting
• Automated reporting

51

• B2B Process Outline
• 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

52

• B2B Process Outline
• 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

53

• B2B Process Outline
• 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 error-handling requirements.
• Language usually XML

54

• B2B Process Outline
• 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.

55

• B2B Process Outline
• Collecting vendor event data
• XML Example
• ltnotegt
• lttogtTovelt/togt
• ltfromgtJanilt/fromgt ltheadinggtReminderlt/headinggt
• ltbodygtDon't forget me this weekend!lt/bodygt
  lt/notegt
• 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.

56

• B2B Process Outline
• 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 application-defined 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.

57

• B2B Process Outline
• 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

58

• 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

59

• 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.

60

• B2B Process Outline
• 2. Vendor event database
• Event storagecontinued
• 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 IDS
  for a level 2 (content) errors.

61

• 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.

62

• 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

63

• 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)

64

• 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

65

• 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

66

• 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

67

• 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

68

• 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

69

• 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

70

• 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.

71

• 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

72

• 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
  on-hand balances and open work orders.

73

• 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.

74

• 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

75

• 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

76

• B2B Process Outline
• Contact Information
• Jerry Edwards
• jkedwards2002_at_hotmail.com
• 650-799-6699 (cell)