PO INTF 002-FS-V6.2-Receipt-Inbound-Data

Exhibit 10

RFP #1163-17-GMK Comprehensive Facilities Asset Management System

Author: ABT

Creation Date: October 28, 2009

Last Updated: June 24, 2016

Document Ref: PO_INTF_002

Version: 6.2

King County BRC Functional Specification

Inbound Receiving Transactions PO_INTF_002

Functional Specification

Version #: 6.2 Page ii

Document History Each time there is an update to the contents, a formal review or approval, notate the information below. Follow agreed BRC versioning rules.

Date Name Version Action 10/28/09 ABT Previous Documents 5/6/10 Tishelle Betterman 4.6 Make Locator Code optional. Add PO line, shipments, and subinventory. 9/28/10 Tishelle Betterman 5.0 Change all name fields to PS Employee Number. Per approved Change

Request# 457. 6/13/2011 Baba Konatham 5.1 QA review and changes. Samples files updated as per latest spec.

Employee Number used instead of Employee Name 10/30/2012 Jeff Stevens 5.2 Interface Stabilization 12/1/14 Patti Oquist 5.3 Changes per CRSs and Requirements Meeting 4/15/2015 Heidi Marchetti 5.3 Re-formatting and continuing changes per requirements 4/29/15 Heidi Marchetti 6.0 Finalized changes to functional spec 6/3/15 – 6/16/15

Heidi Marchetti 6.0 Design clarifications – added user stories and use cases. No changes to requirements.

6/17/15 Heidi Marchetti 6.1 Changes based on peer review comments 12/16/15 Heidi Marchetti 6.1 Corrections based on tests of current functionality 6/24/15 Heidi Marchetti 6.2 Unable to do corrections and returns at this time. Removing this

information from the FS. If the info is needed in the future, refer to version 6.1 in the Archive.

Reviews Date Name Title 4/29/15 Patti Oquist Functional Analyst III 6/17/15 Julia Cordero Functional Analyst III


Version #: 6.2 Page iii

Table of Contents Introduction ........................................................................................................................................ 4

Purpose ............................................................................................................................................ 4

References ....................................................................................................................................... 4

Definitions, Abbreviations and Acronyms ..................................................................................... 5

Business Requirements ....................................................................................................................... 6

User Stories ..................................................................................................................................... 6

Business Rules ................................................................................................................................. 6

Flows ................................................................................................................................................ 8

Requirements List for Enhancements and Defect Resolution ...................................................... 8

Use Cases ......................................................................................................................................... 9

Basic Technical Requirements .......................................................................................................... 20

Fields To Be Provided .................................................................................................................... 20

Data Validation Rules ................................................................................................................... 22

File Format & Name Convention .................................................................................................. 22

Sample Receipt Data ..................................................................................................................... 23


Version #: 6.2

Page 4

Introduction

This document defines the functional specifications for an inbound PO receipt interface from department side systems to EBS. File data according to these specifications shall be transferred and loaded to the Oracle Apps Server. Alternatively, development teams may extract data and publish as Web Services. The PO Receipts interface shall load the data into Oracle ERP custom staging tables. The transaction data shall be mapped into the appropriate GL accounts, and the PO Receipts interface shall call the Oracle PO Receiving Open Interface program to import the transactions to the Oracle EBS Purchasing module. Application Module Name Oracle Purchasing

Application Program Interface Receiving Open Interface: RCVTPO

Purpose The PO_INTF_002 interface was designed to allow purchasing receipt information to be interfaced from side systems into Oracle EBS, in order to eliminate duplicate data entry in side systems and EBS. Imported receipts will update the related PO, which will affect PO status and availability for invoice matching. Receiving transactions for creating new receipts may be created for either Inventory or Expense PO’s. Side Systems currently using this interface are:

• VMM5 • PFEAM • FFASTER

References Business Requirements for enhancements and defects are located in:

B:\EBS\RICE_ID\INTERFACES\PO_INTF_002_REDESIGN - PO Receipts Import Interface

Multiple RFW’s for enhancements and defects were consolidated into two CSR’s, located here:

B:\EBS\CSR RFW Documentation Testing\4126 - PO_INTF_002 Multiple Defects Multiple RFWs

B:\EBS\CSR RFW Documentation Testing\4130 - PO_INTF_002 Multiple Enhancements


Version #: 6.2

Page 5

Definitions, Abbreviations and Acronyms Given below are acronyms or other terms requiring definition that are used in this document.

Acronym or Term Description or Definition

BPEL Business Process Execution Language, used for file transfer process flow into and out of EBS

BRC Business Resource Center

CSR Change Service Request

CSV Comma Separated Values, which is a standard file format

DOT Department of Transportation

EBS Oracle E-Business Suite

FFASTER or FASTER Side system name used by DOT – Fleet

GL General Ledger

INV Inventory

PFEAM or EAM Side system name used by DOT – Power and Facilities

PO Purchase Order

PO_INTF_002 Inbound PO interface for receiving transactions

PO_INTF_003 Outbound PO interface summarizing PO-related activity in EBS

RFW Request for Work

VMM5 or M5 Side system name used by DOT – Vehicle Maintenance

Web Services Method of communication between two devices over a network; an alternative to CSV file transfers


Version #: 6.2

Page 6

Business Requirements

Attention: This section will require approval from the Business Owner that the documented business requirement details have been captured accurately before Functional Design work moves forward.

User Stories

As a(n) <User Type or Role> I want <Interaction and Output>

So that <Desired Outcome>

Agency receiver of goods and services

To be able to enter PO receipts for expense and inventory transactions in EBS using information from my side system

I can eliminate manual duplication of data entry


To be able to correct EBS PO receipts via interface from my side system



To be able to indicate a return to supplier on my EBS PO via interface from my side system


Interface user Meaningful error messages I know immediately how to go about resolving issues

Interface user Controls to be in place for how to input data

Junk data is not loaded into EBS

Business Rules Rule 1 – Source Systems Use of the Oracle Purchasing Receiving Transactions Interface to Import Purchase Order Receipts from the following source-systems:

• PFEAM (DOT – Power and Facilities) • VMM5 (DOT – Vehicle Maintenance) • FFASTER (DOT – Fleet) • Participants may be added or removed as required.


Version #: 6.2

Page 7

Interface Operations

1. For CSV file loads, the Oracle Purchasing Receiving Transactions Interface process shall be initiated through a concurrent request with a parameter field to select a specific source system.

2. Web Services payloads shall be pushed from the side system.

Rule 2 – Pre-Requisites For receipt transactions, an approved purchase order must exist in EBS. Purchase orders referenced by this interface may not have more than one deliver-to location or accounting distribution per line.


1. Transactions of type RECEIVE require a PO number. Each RECEIVE transaction shall refer to one Purchase Order line and to one distribution line on the corresponding purchase order line. The PO may be partially received, but it may not be fully received.

Rule 3 – Inventory, Catalog Expense, or Non-Catalog Expense Receipts Transactions may reference an inventory PO. Transactions may also reference a catalog or a non-catalog expense PO. Inventory and catalog expense PO receiving transactions must reference the valid Item Master item that was used in the PO. Non-catalog expense PO receiving transactions may reference a user-defined item that is not in the Item Master.


1. Each receipt transaction shall be validated against the inventory or expense organization used in the original PO or receipt, and the item number for inventory or catalog expense. Item description is optional for non-catalog expense and is not validated.

2. All interface transactions shall use the same organization, and the same item number or description, as the original referenced documents.

Rule 4 – Transaction Types For transaction type = RECEIVE, the quantity must be positive (greater than 0).


Note: For Inventory records, a “RECEIVE” transaction type assumes Direct Delivery (i.e. rcv_transactions_interface.auto_transact_code=DELIVER). Rule 5 – Errors Errors shall be identified, and notification of the error delivered to the originator via email. Error messages shall also be available through a concurrent request. Transactions that pass pre-validation shall be processed rather than returned.


Records within a file or payload that do not generate errors will be processed, while those with


Version #: 6.2

Page 8

errors must be resubmitted in a new file or payload. The entire file or payload will be rejected if there are errors, even if some lines pass validation. Rule 6 – Limitations The net quantity received may not be more than the quantity ordered, and it may not be a negative number.


Each RECEIVE transaction may not exceed the open (available to receive) quantity on the purchase order line.

Flows Process Flow Diagram

King County Responsibilities

<Entity> Tables

Custom Staging Tables

Extract Data: - Web Service- FTP - DB Link- JDBC

Transfer data to Oracle Server

Data Format-Flat File-XML-DB Records

OracleApplications

Server

Load into Oracle

DatabaseEnd

Start

Oracle Purchasing

Tables

RCV_Headers_InterfaceRCV_Transactions_InterfacePO_Interface_Errors

PO Receipts Process

Legacy Database

ERP Oracle Database

ERP Oracle Database

1 2

4 5

Map legacy GL accounts

to Oracle

3

Requirements List for Enhancements and Defect Resolution

ID

– N

umbe

r

Function – Feature – Requirement

U

se C

ase

Ref

eren

ce

Comments

Business Requirements B0001 Increase item number field in BPEL to 81

characters N/A 2015 - Technical standardization requirement from BRC

B0002 Increase packing slip number field in staging table to 25 characters

N/A 2015 - Technical standardization requirement from BRC

B0003 Validate the receipt transaction date against open INV and GL periods

NEG-008 2015 Defect


Version #: 6.2

Page 9

B0004 Allow flat files to use an inventory locator without being rejected with an invalid locator error

POS-014 2015 Defect - Are web services also rejected?

B0005 Reject files or batches that contain a negative quantity for a correction or return

NEG-005 2015 Defect? 6/24/16 NOTE: No longer applicable, as we are not allowing corrections or returns.

B0006 Send a notification email when files fault on upload in Stage 1 or 2 validation

N/A 2015 – Technical standardization requirement from BRC. Part of interface support improvement project.

B0007 Allow corrections and returns via interface POS-002, 003, 006,

007

2015 Enhancement 6/24/16 NOTE: This is not possible without a much larger overhaul of the interface, adding multiple new required fields. This will not be completed at this time.

B0008 Standardize batch names for web service and flat file to include side system, interface ID, and date/time stamp

N/A 2015 - Technical standardization requirement from BRC. Part of interface support improvement project.

Use Cases

Use Case ID Use Case Name POS-001 Create a new inventory receipt POS-002 Correct an existing inventory receipt POS-003 Create a new expense receipt (catalog item) POS-004 Create a new expense receipt (non-catalog / no item number) POS-005 Three inventory transactions, one of each type, on a single file POS-006 Three expense transactions, one of each type, on a single file POS-007 Inventory and expense receipts both on one file POS-008 Expense item description with comma, surrounded by double quotes POS-009 Flat file CSV includes an inventory locator NEG-001 One or more required fields blank NEG-002 Various fields exceed character limits NEG-003 Wrong record type for corresponding destination type NEG-004 Attempt to receive PO with multiple distributions NEG-005 Receive more than the quantity available on the PO NEG-006 Various transactions with transaction date in a closed INV or GL period NEG-007 Various expense fields that must be validated contain invalid values NEG-008 Various inventory fields that must be validated contain invalid values NEG-009 Attempting to receive against POs that are closed for receiving Test Scripts Location

B:\EBS\RICE_ID\INTERFACES\PO_INTF_002_ - PO Receipts Import Interface\Testing\Test Scripts PO_INTF_002 fixes_enhancements.xlsx

Use Case ID: POS-001 Use Case Name: Create a new inventory receipt

Created By: Heidi Marchetti Last Updated By: Date Created: 6/15/2015 Date Last Updated:

Actors: Side system agencies Description: Create a new receipt for an inventory PO


Version #: 6.2

Page 10

Preconditions: The PO is in approved status and has not been fully received Postconditions: The PO will show the correct receipt information Normal Course: A receipt is created, and the user receives an email confirming that

the interface was successful. Alternative Courses:

Exceptions: Includes:

Business Rules: Special Requirements: VMM5 must use inventory org TVM. FFASTER must use one of the

orgs FLT, FLM, or FLW. PFEAM must use inventory org TPF. Subinventory is dependent upon inventory org.

Assumptions: Direct delivery is used, meaning both receive and deliver Notes and Issues:

Use Case ID: POS-002 Use Case Name: Correct an existing inventory receipt


Actors: Side system agencies Description: Correct an existing receipt that was previously entered against an

inventory PO Preconditions: The PO is in approved status and has been either partially received

or fully received Postconditions: The PO will show the correct receipt information Normal Course: The receipt is updated and shows both the correction quantity and

the new net quantity received. The user receives an email confirming that the interface was successful.

Alternative Courses: Exceptions:

Includes: Business Rules:

Special Requirements: VMM5 must use inventory org TVM. FFASTER must use one of the orgs FLT, FLM, or FLW. PFEAM must use inventory org TPF. Subinventory is dependent upon inventory org.

Assumptions: Both the receive and deliver parts of the receipt are corrected Notes and Issues:

Use Case ID: POS-003 Use Case Name: Create a new expense receipt (catalog item)


Actors: Side system agencies


Version #: 6.2

Page 11

Description: Create a receipt for an expense PO that has used a pre-defined item number

Preconditions: The PO is in approved status and has not been fully received Postconditions: The PO will show the correct receipt information Normal Course: The interface validates the item number in the file against the item

number in the corresponding PO line. A receipt is created and the user receives an email confirming that the interface was successful.

Alternative Courses: Item description is left blank, and it is derived by the interface Exceptions:


Special Requirements: Assumptions:

Notes and Issues:

Use Case ID: POS-004 Use Case Name: Create a new expense receipt (non-catalog / no item number)


Actors: Side system agencies Description: Create a receipt for an expense PO that does not include a pre-

defined item number Preconditions: The PO is in approved status and has not been fully received

Postconditions: The PO will show the correct receipt information Normal Course: The interface validates the item description in the file against the

item description in the corresponding PO line. A receipt is created and the user receives an email confirming that the interface was successful.




Notes and Issues:

Use Case ID: POS-005 Use Case Name: Three inventory transactions, one of each type, on a single file


Actors: Side system agencies


Version #: 6.2

Page 12

Description: Three transactions are created for three different inventory PO’s. One is a new receipt, one is a correction, and one is a return. Each transaction is a separate line on the interface file.

Preconditions: The PO’s are in approved status. The PO for the new receipt has not been fully received. The other two PO’s have been either partially received or fully received.

Postconditions: Each PO will show the correct receipt information Normal Course: One receipt is created and two receipts are updated with the

correct information. The user receives an email confirming that the interface was successful.



Special Requirements: VMM5 must use inventory org TVM. FFASTER must use one of the orgs FLT, FLM, or FLW. PFEAM must use inventory org TPF. Subinventory is dependent upon inventory org.

Assumptions: For the correction transaction, both the Receive and Deliver parts of the receipt are corrected. For the return transaction, Return to Vendor is used, NOT Return to Receiving.

Notes and Issues:

Use Case ID: POS-006 Use Case Name: Three expense transactions, one of each type, on a single file


Actors: Side system agencies Description: Three transactions are created for three different expense PO’s.

One is a new receipt, one is a correction, and one is a return. Each transaction is a separate line on the interface file.

Preconditions: The PO’s are in approved status. The PO for the new receipt has not been fully received. The other two PO’s have been either partially received or fully received.

Postconditions: Each PO will show the correct receipt information Normal Course: One receipt is created and two receipts are updated with the

correct information. The user receives an email confirming that the interface was successful.



Special Requirements:


Version #: 6.2

Page 13

Assumptions: For the correction transaction, both the Receive and Deliver parts of the receipt are corrected. For the return transaction, Return to Vendor is used, NOT Return to Receiving.

Notes and Issues:

Use Case ID: POS-007 Use Case Name: Inventory and expense receipts both on one file


Actors: Side system agencies Description: Two transactions are created. One is a new receipt for an

inventory PO, and the other is a new receipt for an expense PO. Each transaction is a separate line on the interface file.

Preconditions: The PO’s are in approved status and have not been fully received. Postconditions: Each PO will show the correct receipt information Normal Course: Two receipts are created with the correct information. The user

receives an email confirming that the interface was successful. Alternative Courses:


Business Rules: Special Requirements: VMM5 must use inventory org TVM. FFASTER must use one of the

orgs FLT, FLM, or FLW. PFEAM must use inventory org TPF. Subinventory is dependent upon inventory org.

Assumptions: Notes and Issues:

Use Case ID: POS-008 Use Case Name: Expense item description with comma, surrounded by double quotes


Actors: Side system agencies Description: A PO for an expense item has an item description containing a

comma. In the interface file, the description field is surrounded by double quotes.

Preconditions: The PO is in approved status and has not been fully received Postconditions: The PO will show the correct receipt information Normal Course: The interface validates the item description in the file against the

item description in the corresponding PO line. There is no error or offsetting of fields due to the comma because it is contained within double quotes. A receipt is created and the user receives an email confirming that the interface was successful.

Alternative Courses:


Version #: 6.2

Page 14


Business Rules: Special Requirements:


Use Case ID: POS-009 Use Case Name: Flat file CSV includes an inventory locator


Actors: Side system agencies Description: Create a new receipt for an inventory PO, and include a valid

locator value on the flat file CSV. Preconditions: The PO is in approved status and has not been fully received

Postconditions: The PO will show the correct receipt information Normal Course: The interface will validate the locator value and does not give an

error. A receipt is created and the user receives an email confirming that the interface was successful.



Special Requirements: VMM5 must use inventory org TVM. FFASTER must use one of the orgs FLT, FLM, or FLW. PFEAM must use inventory org TPF. Subinventory and locator are dependent upon inventory org.


Use Case ID: NEG-001 Use Case Name: One or more required fields blank


Actors: Side system agencies Description: Multiple test files will be submitted. Each required field will be left

null in a separate test file. At least one test file will contain multiple null required fields.

Preconditions: The PO is in approved status and has not been fully received. All other fields in the file are complete and accurate.

Postconditions: No receipts will be created Normal Course: The interface will produce an error and email the error report to

the user. The error message will be dependent upon the field(s) left null (e.g. “Interface Source Code cannot be NULL”).


Version #: 6.2

Page 15




Notes and Issues: Be sure to test special fields used for inventory or expense only

Use Case ID: NEG-002 Use Case Name: Various fields exceed character limits


Actors: Side system agencies Description: Multiple test files will be submitted. Each field that does not have

a specified list of values will be tested for field length on a separate file.

Preconditions: The PO is in approved status and has not been fully received. All other fields in the file are complete and accurate.

Postconditions: No receipts will be created Normal Course: The interface will produce an error and email the error report to

the user. The error message will be dependent upon the field that is too long (e.g. “Item Description cannot exceed 240 characters”).




Notes and Issues: Be sure to test special fields used for inventory or expense only

Use Case ID: NEG-003 Use Case Name: Wrong record type for corresponding destination type


Actors: Side system agencies Description: Attempt to create a receipt for an expense PO using ‘B1’, and

attempt to create a receipt for an inventory PO using ‘B2’. Preconditions: The PO is in approved status and has not been fully received. All

other fields in the file are complete and accurate. Postconditions: No receipts will be created Normal Course: The interface will validate the record type in the file against the

destination type of the PO. It will produce an error and email the error report to the user. The error message will be similar to


Version #: 6.2

Page 16

“Incorrect record type: XX for destination: XX” (e.g. “Incorrect record type: B1 for destination: Expense”)




Notes and Issues:

Use Case ID: NEG-004 Use Case Name: Attempt to receive PO with multiple distributions


Actors: Side system agencies Description: Attempt to create a receipt for the full quantity of a multi-

distribution, one-line PO Preconditions: An expense PO with one line and 2 distributions has been created

and is in approved status. Postconditions: No receipt will be created Normal Course: The interface will check the number of distributions on the PO. It

will produce an error and email the error report to the user. The error message will be similar to, “Purchase order XXX has more than one distribution per line. Receipts may not be created via interface for PO lines containing multiple distributions.”




Notes and Issues:

Use Case ID: NEG-005 Use Case Name: Receive more than the quantity available on the PO


Actors: Side system agencies Description: Receive a quantity greater than the quantity ordered on a PO. Or,

receive a quantity greater than the quantity ordered minus the net quantity received on a PO.

Preconditions: The PO is in approved status and has not been fully received Postconditions: No receipt will be created


Version #: 6.2

Page 17

Normal Course: The interface will validate the quantity available to receive on the PO. An error report will be emailed to the user. The error message will be similar to, “Quantity received exceeds available quantity ordered on PO XX”.




Notes and Issues: Test both inventory and expense receipts

Use Case ID: NEG-006 Use Case Name: Various transactions with transaction date in a closed INV or GL period


Actors: Side system agencies Description: Various files submitted where the transaction date is in a prior

(closed) or future (never opened) Inventory or GL period Preconditions: PO’s are in approved status, and the interface files are otherwise

complete and accurate. Prior closed periods and future never-opened periods for Inventory and GL exist

Postconditions: No receipt will be created Normal Course: The interface will validate the transaction date against open

inventory and GL periods. If the periods are not open, an error will be produced and an error report emailed to the user. The error message will be similar to, “Transaction date: XXXX-XX-XX does not fall within an open accounting period. Please check your date and re-submit.”

Alternative Courses: The interface changes the receipt date to the sysdate if it would otherwise error out due to being in a closed period.


Business Rules: Special Requirements:

Assumptions: Notes and Issues: For inventory receipts, test Inventory and GL periods. For expense

receipts, test only GL periods.

Use Case ID: NEG-007 Use Case Name: Various expense fields that must be validated contain invalid values



Version #: 6.2

Page 18

Actors: Side system agencies Description: For expense receipts, various fields that reference a list of values

contain a value that is not found in that list Preconditions: PO’s are in approved status, and the interface files are otherwise

complete and accurate. Postconditions: No receipt will be created Normal Course: The interface will validate the values provided against what is in

EBS. Any values that do not match will produce an error message, and an error report will be emailed to the user. Error messages will vary depending on which fields are invalid. (e.g. “The vendor name: XX is invalid”)




Notes and Issues:

Use Case ID: NEG-008 Use Case Name: Various inventory fields that must be validated contain invalid values


Actors: Side system agencies Description: For inventory receipts, various fields that reference a list of values

contain a value that is not found in that list Preconditions: PO’s are in approved status, and the interface files are otherwise

complete and accurate. Postconditions: No receipt will be created Normal Course: The interface will validate the values provided against what is in

EBS. Any values that do not match will produce an error message, and an error report will be emailed to the user. Error messages will vary depending on which fields are invalid. (e.g. “The vendor name: XX is invalid”)




Notes and Issues:

Use Case ID: NEG-009


Version #: 6.2

Page 19

Use Case Name: Attempting to receive against POs that are closed for receiving Created By: Heidi Marchetti Last Updated By:

Date Created: 6/15/2015 Date Last Updated: Actors: Side system agencies

Description: Interface files reference PO shipments that are in a status other than “Open” or “Closed for Invoicing”.

Preconditions: The PO is in one of the statuses “Approved”, “Cancelled”, “Closed”, or “Finally Closed”. The PO shipment is in one of the statuses “Closed”, “Finally Closed”, “Closed for Receiving”, or “Cancelled”.

Postconditions: No receipt will be created Normal Course: The interface will validate the status of the PO and the line(s) being

received. Any value other than “Open” or “Closed for Invoicing” will produce an error. An error report will be emailed to the user. The error message will be similar to, “Purchase Order: XX Line: XX is not available to receive.”


Includes: Business Rules


Notes and Issues: Test both inventory and expense receipts


Version #: 6.2

Page 20

Basic Technical Requirements

Fields To Be Provided The following columns shall be provided for each INVENTORY PO Receipt Transaction:

Field Order

Field Name Data Type Length Required? Description

1 Record Type TEXT 5 Required Value shall be 'B1' for Inventory destination

2 INTERFACE SOURCE CODE TEXT 25 Required Side system interface code used to identify the source.

3 VENDOR NAME TEXT 240 Required Vendor Name on PO 4 TRANSACTION TYPE TEXT 25 Required Column indicates the transaction

purpose code. The only valid value is: RECEIVE

5 TRANSACTION DATE DATE 10 Required Column indicates the date of the transaction. The date may be in the past or future, but it must be in an open Purchasing and General Ledger period and, for Inventory transactions, also be in an open Inventory period. Format: YYYY-MM-DD

6 EMPLOYEE NUMBER TEXT 30 Required The PeopleSoft Employee Number for the person sending the receipts record, including leading zeroes.

7 DOCUMENT NUMBER (PO NUMBER)

TEXT 20 Required The column DOCUMENT NUM indicates the purchase order number against which to receive. Must be a valid number in EBS.

8 LINE NUM NUMBER Required PO Line Number. 9 SHIPMENT NUM NUMBER Required PO Shipment Number. 10 DISTRIBUTION NUM NUMBER Required PO Distribution Line Number. 11 ITEM NUM TEXT 30 Required ITEM NUM indicates an Item

Master item number. 12 QUANTITY NUMBER Required Quantity of item to be received.

Must be a positive quantity (greater than zero).

13 UNIT OF MEASURE TEXT 25 Required Unit of Measure must match what is used on the PO, or have a defined conversion in EBS.

14 PACKING SLIP TEXT 25 Optional Packing Slip Number


Version #: 6.2

Page 21

15 LOCATOR CODE (inventory only)

TEXT 10 Conditionally Required

Location into which item is being received. This field is required for Inventory receipts only if the item ordered is locator controlled.

16 DESTINATION SUBINVENTORY (inventory only)

TEXT 10 Required Subinventory Code. This field is required for all Inventory receipts.

The following columns shall be provided for each EXPENSE PO Receipt Transaction:

Field Order

Field Name Data Type Length Required? Description

1 Record Type Text 5 Required Value shall be 'B2' for Expense destination

2 INTERFACE SOURCE CODE TEXT 25 Required Side system interface code used to identify the source.

3 VENDOR NAME TEXT 240 Required Vendor Name on PO 4 TRANSACTION TYPE TEXT 25 Required Column indicates the transaction

purpose code. The only valid value is: RECEIVE

5 TRANSACTION DATE DATE 10 Required Column indicates the date of the transaction. The date may be in the past or future, but it must be in an open Purchasing and General Ledger period. Format: YYYY-MM-DD

6 EMPLOYEE NUMBER TEXT 30 Required The PeopleSoft Employee Number for the person sending the receipts record, including leading zeroes.

7 DOCUMENT NUMBER (PO NUMBER)

TEXT 20 Required The column DOCUMENT NUM indicates the purchase order number against which to receive. Must be a valid number in EBS.

8 LINE NUM NUMBER Required PO Line Number. 9 SHIPMENT NUM NUMBER Required PO Shipment Number. 10 DISTRIBUTION NUM NUMBER Required PO Distribution Line Number. 11 ITEM NUM TEXT 30 Conditionally

Required ITEM NUM indicates an Item Master item number. Required only if the PO Line being received contains a value for item number (Catalog Expense).

12 QUANTITY NUMBER Required Quantity of item to be received. Must be a positive quantity (greater than zero).


Version #: 6.2

Page 22

13 UNIT OF MEASURE TEXT 25 Required Unit of Measure must match what is used on the PO, or have a defined conversion in EBS.

14 PACKING SLIP TEXT 25 Optional Packing Slip Number 15 AMOUNT

(expense only) NUMBER Required Line Amount being received

(quantity received multiplied by unit price of the PO line).

16 ITEM DESCRIPTION (expense only)

TEXT 240 Optional This field is optional and will not be validated.

Data Validation Rules The following validation shall be required:

• PO, PO Lines, PO Shipments, and PO Distributions are “Open” or “Closed for Invoicing”

• Quantity received may not exceed quantity ordered or net un-received quantity (Note: quantity received may be a multiple or divisor of quantity ordered, if a valid Unit of Measure conversion is present in EBS).

• Receipt dates shall fall within the current open Purchasing, GL, and (where applicable) Inventory period.

• The ship-to location for any PO referenced by B1 transactions must be a valid inventory location, with a corresponding subinventory code. Likewise, B2 transactions may not reference an inventory location.

File Format & Name Convention • Master Data elements shall conform to King County Standard and Naming Convention

per published project document.

• Side system must provide receipts as a Web Service or flat file.

• File naming standards, plus Header and Footer requirements per published project document ‘ABT Oracle EBS Interface File Standards’

• Each data field is separated by a comma, and each line is a receipt line.

• Tabs are not allowed in the file.

• Blank spaces are not allowed between field value and comma or between comma and field value. For example, the following are not valid:

Other ,Other

Other, Other

The correct format is: Other,Other

• The data fields must be ordered based on the above tables.


Version #: 6.2

Page 23

• Required fields must have values. Optional fields can be blank, but they must keep the field positions by using a comma. Conditionally required fields would need data based on the data itself. (Details are explained in the description)

• Commas are used as data field separators, so if the data field contains a comma, the data needs to be enclosed by double quotes. For example:

“Other,Other” would be treated as one field.

Sample Receipt Data The following is a sample of receipt data contained in a .csv file. The data file contains column headers, which should not be part of the data file generated for the actual interface. It is only being included on this sample file for reference.

Field names: Record Type, INTERFACE SOURCE CODE, VENDOR NAME, TRANSACTION TYPE, TRANSACTION DATE, EMPLOYEE_NAME, DOCUMENT_NUMBER, LINE_NUM, SHIPMENT_NUM, DISTRIBUTION_NUM, ITEM_NUM, QUANTITY, UNIT_OF_MEASURE, PACKING_SLIP, LOCATOR_CODE/AMOUNT, DESTINATION_SUBINVENTORY/ITEM_DESCRIPTION Sample inventory data: B1,VMM5,Vendor ABC,RECEIVE,2010-01-12,123456,209001,2,213,1,KCWUL001,1,EA,,,VM Sample expense data: B2,VMM5,Vendor XYZ,RECEIVE,2010-01-12,123456,209000,4,211,1,,5,EA,,,White Ball Expense Item Sample data in correct CSV format, including header and footer: HDR,PO,PO_INTF_002,IN,DOT,VMM5,PORECPT,2015-03-30 13:47:00,[email protected] B1,VMM5,Vendor ABC,RECEIVE,2010-01-12,123456,209001,2,213,1,KCWUL001,1,EA,,,VM B2,VMM5,Vendor XYZ,RECEIVE,2010-01-12,123456,209000,4,211,1,,5,EA,,,White Ball Expense Item FTR,2,0,0,0,0,0