letroni ouent excange - boral ouent excange ... 8.2 cxml purchase order request file format 21 ......

Electronic Document ExchangeBetween Boral & SuppliersSupplier Detailed Process & Procedure Document Version 1.0 (July 2009)

>>

Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009) Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009)

Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009) page 3

>>Electronic Document Exchange | Boral & Suppliers

Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009)

cont

ents

1 Objective 4

2 Introduction 4

2.1 Why trade electronically? What are the benefits? 4

2.2 How can Supplier’s trade electronically with Boral? 4

2.2.1 Oracle Supplier Network 4

3 Pre-requisites for electronic trading 6

3.1 Registration with Oracle Supplier Network (OSN) 6

3.1.1 Steps to Register with OSN 6

3.1.2 Steps to Setup Trading Partners 7

3.2 Boral‘s Compatible File Formats 8

3.2.1 Boral Purchase Orders Compatible File Formats 8

3.2.2 Boral Invoice Compatible File Formats 8

3.3 Catalogue Setup 9

3.3.1 Boral Hosted Catalogues 9

3.3.2 Supplier Hosted Catalogues 9

3.4 Supplier’s Account Structure 9

4 Oracle Support Network (OSN) Support 9

5 Six Simple Steps to become Boral‘s electronic trading partner – 10

The Process & Contacts

6 Testing Process 11

6.1 Integration Testing 11

6.2 (User Acceptance) Testing – UAT 11

7 Appendix I – Terms & Definitions 11

8 Appendix II– Related Reference & Documents 12

8.1 OAG PROCESS PO 007 12

8.2 cXML Purchase Order Request File Format 21

8.3 OAG PROCESS INVOICE 002 23

8.4 cXML Invoice Request File Format 26

>>


1 Objective The objective of this document is to act as a detailed guide for vendors/Suppliers that wish to trade electronically i.e using electronic product catalogues, electronic purchase orders and invoices.

2 Introduction Boral offers a range of electronic services for it’s Suppliers that facilitate fast, efficient and speedy exchange of business documents like purchase orders and invoices.

2.1 Why trade electronically? What are the benefits? Trading electronically allows company’s to be more competitive in today’s business environment. The benefits of which include:

• Saves time: This is one of the first benefits to be realised. Data is transferred between systems with significant improvements in speed and accuracy.

• Reduces costs: Savings can be achieved through reduced human handling, reduced errors and improved document processing and transportation.

• Improves customer service and strengthens Supplier relationships: The sharing of electronic documents and information strengthens the ties between partners and encourages stronger levels of commitment.

• Improves productivity: Staff time is freed up with reduced processing requirements.

• Minimises errors: It minimises data entry, communication and administration errors.

• Fast and secure electronic transfer: It provides Suppliers with secure electronic data transfer between Boral’s accounts payable and a Supplier’s account receivable system. This option makes it easy to match and reconcile invoices, purchase orders and payments.

• Reduces delays in payments: Automatic match between invoice, PO and receipt reduces errors and disputes and therefore facilitates payment within terms with potential improvements in cash flow.

2.2 How can Supplier’s trade electronically with Boral? Boral generally uses the Oracle Supplier Network (OSN) to facilitate transacting electronically with its customers. The OSN allows a single communication point that lets Boral and its Suppliers exchange electronic business documents over secure internet connections.

2.3 Oracle Supplier Network (OSN)The Oracle Supplier Network (OSN) is an online service offering managed by Oracle providing electronic message setup, transformation and routing services. OSN is an open community for Oracle customers and their trading partners that is provided at no charge to our Suppliers.

The OSN uses common XML message formats to underpin the exchange of documents. Trading partners can choose from one of the following supported XML standards:

• OpenApplicationsGroup(OAG)

• CommerceXML(cXML)

It is the responsibility of the Supplier to ensure that their electronic file format comply with one of the above standards to ensure that Purchase Orders and Invoices can be transferred, received and matched.

Where the Supplier is unable to communicate using one of the above standards, the Supplier may choose to use a 3rd party vendor (VAN) to translate the file into one of the above file formats. Where the Supplier chooses to use a 3rd party vendor (VAN), the Supplier will be responsible for any translation costs and ongoing transaction fees for the translation of files by the 3rd party vendor (VAN).




The OSN supports the following transaction flows:

Inbound to OSN Activity by OSN Outbound from OSN

OAG PROCESS PO Pass Through OAG PROCESS PO Refer to Appendix 8.1 for file formats

OAG PROCESS PO Transformation cXML OrderRequestRefer to Appendix 8.2 for file formats

OAG PROCESS INVOICE Pass Through OAG PROCESS INVOICERefer to Appendix 8.3 for file formats

cXML InvoiceDetailRequest Transformation cXML OrderRequestRefer to Appendix 8.4 for file formats

Note: It is anticipated that Boral will expand the document types it exchanges electronically over time. However, at the moment the document types are limited to electronic catalogues, purchase orders and invoices.

When sending messages to the OSN, the sender uses an envelope or cXML header to describe the sending party, receiving party and other information to identify the contents. For Oracle Application trading partners sending messages to the OSN, the Oracle Transport Adaptor creates the envelope automatically.

One of 3 delivery mechanisms can be used to send messages to the OSN. These are:

1. HTTP/S posting

2. Oracle Transport Adaptor

3. Oracle SN Web Mailbox

>>


3 Pre-requisites for electronic trading Supplier’s need to consider the following pre-requisites before they can start trading electronically with Boral.

• Registration with OSN: Suppliers will be required to be registered with Oracle Supplier Network (OSN)

• Boral’s compatible file formats: Boral supports specific file formats when exchanging documents through the OSN. These formats are compliant with international standards and detailed information about them is available on request or can be downloaded from our web site.

• Supplier’s catalogue setup: Boral supports two models for accessing your electronic catalogues.

These are:

1 Boral hosted catalogue: uses a simple electronic template into which Suppliers load their product and pricing information. This is then sent to Boral to be loaded directly into our purchasing system.

2 Supplier hosted catalogue: Suppliers maintain their catalogue of goods and services on their own system and provide Boral personnel access online via the internet.

• Supplier’s account structure: is agreed between Boral and our Supplier based on the number of sites.

3.1 Registration with Oracle Supplier Network (OSN) In order to transfer transaction information via the OSN, Suppliers must first register their company details on the OSN. The OSN offers a self registration process for trading partners to register their company details.

3.1.1 Steps to Register with OSN To register your company, navigate to the OSN page at http://osn.oracle.com and click the “Register your Company” link.

The following fields are displayed on the Registration page under “Company Profile” Tab as shown in below screenshot:

• Company Name – Enter the complete, formal name of your company.

• Address Lines, City, State, ZIP (Post code), Country – Enter your postal (mail) address.

• Identifier Type – The OSN allows the Company to choose the credential they want to use for uniquely identifying themselves on the OSN. The identifier types available to choose from include DUNS number, telephone number, Global Location Number, Tax Identifier, or Miscellaneous. Choose the identifier type that your company wishes to use from the list.

• Identifier Value – Enter the identifier value that corresponds to the Identifier Type.

• Oracle Applications Customer? – Indicate whether your company uses Oracle eBusiness Suite Applications.

• Customer Support Identifier (CSI) – Enter your CSI number if your company has an active support contract for Oracle Applications.

CSI is an identifier assigned by Oracle to it’s application users. If you are not an Oracle application user please leave this field blank.




The following fields are displayed on the Registration page under “User Profile” Tab as shown in below screenshot:

Title – Enter your company title or position.

First Name, Middle Name, Last Name – Enter your name as the trading partner administrator.

Email Address – Enter your email address.

Username – Enter a username for logging into your OSN account.

Password, Confirm Password – Enter a password to use to authenticate you when logging onto the OSN. It should be between 6 -12 characters in length.

Important: Electronic XML documents that you send to the OSN must include your OSN Username and Password for authenticating the sender as a valid trading partner registered on the OSN.

After completing the registration page, click the “Submit” button.

If successful, the “Oracle Supplier Network Temporary Terms of Use” message appears. Read the terms, select the “Accept” box if you agree to all of the terms and click the “Submit” button.

A confirmation page indicates that your registration has been submitted for review. After review of your Registration, you will receive an e-mail notification. If approved, the notification informs you that your account has been activated and that you can log in to begin your account setup.

3.1.2 Steps to Setup Trading Partners

The “Trading Partner” Tab shown below lets you find and select companies on the Oracle Supplier Network to initiate the exchange of business documents. Identifying your trading partners is the final setup step before your company can begin processing transactions over the Oracle Supplier Network.

>>


Trading Partner Management on the Oracle Supplier Network includes:

• The“My Partners” Tab, where you can add, remove, and approve trading partner relationships and Suppliers can request iSupplier Portal accounts.

• The“Routing Rules” Tab, which shows the communication paths for transactions with your approved trading partner relationships, as well as broken routes.

• The“iSP Wallet” Tab, where Suppliers maintain their iSupplier Portal accounts for instant access to their customers’ iSP sites.

3.2 Boral’s Compatible File FormatsIt is the responsibility of the Supplier to ensure that their electronic file format comply with one of the above standards to ensure that Purchase Orders and Invoices can be transferred and received.

Boral communicates with the OSN using the Open Application Group (OAG) XML standard for inbound and outbound messages. The OSN has a real time message transformer that converts from the cXML standard to the preferred OAG XML standard of the receiving party.

3.2.1 Boral Purchase Order Compatible File Formats

Boral Purchase Orders will be provided to Suppliers via the OSN. Suppliers may choose to receive the purchase order electronically in one of the following formats from the OSN:

1. OAG Process_PO_007 XML

2. cXML OrderRequest

For further information in respect of the mapping between the above OAG Process_PO_007 XML file format and the cXML OrderRequest file format, please refer to Oracle Supplier Network XML Solutions Guide version 9.0 at https://osn.oracle.com/snw/tpadmin/.

For Purchase order specific data types, Please refer to appendix 8.1.

For cXML Purchase Order Request File Formats, Please refer to appendix 8.2.

3.2.2 Boral Invoice Compatible File Formats

Invoice transactions are sent by Suppliers to buying organizations for products or services provided. Supplier Invoice transactions are provided to Boral via the OSN. Suppliers may choose to send their invoices electronically in one of the following formats:

1. OAG Process_Invoice_002 XML

2. cXML InvoiceDetailRequest

For further information in respect of the mapping between the above OAG PROCESS_INVOICE_002 XML file format and the cXML InvoiceDetailRequest file format, please refer to Oracle Supplier Network XML Solutions Guide version 9.0 at https://osn.oracle.com/snw/tpadmin/.

Where the Supplier chooses to use the cXML format for invoices, the OSN will convert the invoice into the OAG PROCESS_INVOICE_002 XML format and forward it through to Boral for processing. If the OAG PROCESS_INVOICE_002 XML format is chosen by the Supplier for invoices, the OSN will simply pass the file through to Boral for processing.

In order for Boral to process Supplier Invoices via the OSN, the Invoices must meet the following requirements:

1. Invoice must relate to a Purchase Order.

2. All invoices in a message must be from the same Supplier and Supplier site.

3. Custom code conversions need to be defined as part of the trading partner setup.

4. Tax Groups are not supported.

5. Invoices in a message are limited to one Boral Business Organisation.

3.1.2 Steps to Setup Trading Partners ...




6. The invoice file must contain the following XML elements:

<PROCESS_INVOICE>

INVHEADER (invoice header)

INVCHARGE (freight/miscellaneous charge line)

INVLINE (item line)

INVTAX within INVLINE (This tax line will have the same LINE_GROUP_NUMBER as the Item line)

INVTAX (tax line(s)) (This tax line will not have a LINE_GROUP_NUMBER because it will be prorated across all taxable Item lines in this invoice.)

</PROCESS_INVOICE>

The following are examples of document structures that are not supported:

INVTAX and INVCHARGE within INVHEADER

INVTAX within INVCHARGE

INVCHARGE within INVLINE

7. Boral’s invoice format does not support tax on tax.

8. Boral does not support invoices matched to Blanket Purchase Orders.

3.3 Catalogue SetupCataloguing allows creation of a purchase order from an electronic catalogue. Boral supports two models for accessing electronic catalogues. These are:

1. Boral Hosted Catalogue

2. Supplier Hosted Catalogue

3.3.1 Boral Hosted Catalogues

Boral Hosted Catalogues are best suited for direct material (such as goods related items) products with pre negotiated or stable priced items for which blanket purchase agreements and quotations already exist in Boral’s Oracle Purchasing system.

Boral Hosted Catalogues use a simple electronic template. Suppliers can load their product and pricing information directly into Boral’s purchasing system. Simple templates are also available to enable Suppliers to maintain and update product and pricing information once the initial catalogue has been uploaded.

3.3.2 Supplier Hosted Catalogues

Suppliers maintain their catalogue of goods and services on their own system and provide Boral purchasing personnel with internet access to it. Boral can then pull information relating to goods, services and pricing directly from the Supplier’s catalogue into Boral’s purchasing system where a Purchase Order is raised and sent electronically to the Supplier.

3.4 Supplier’s Account StructureSuppliers are able to set up to a maximum of 15 locations to electronically exchange documents via OSN. If a Supplier has more than 15 locations then they should contact their technical contact from Boral to discuss setup requirements.

4 Oracle Support Network (OSN) Support Licensed Oracle Applications users that are registered users of Oracle SN and are current on Oracle Technical Support, may obtain technical support for Oracle SN through MetaLink. Registered trading partners may submit issues and questions through the on-line web form (“Contact Us”) on the Oracle SN site. You will receive a notification, via email, within one (1) business day from an Oracle representative regarding your submission.

>>


5 Six Simple Steps to become Boral’s electronic trading partner – The Process & Contacts

SIX STEPS TO BECOME BORAL’S ELECTRONIC TRADING PARTNER

Step 1 Contact Boral

Suppliers can begin electronic trading relationship by contacting any of the following people at Boral.

Amanda CurrallBoral e-Commerce Collaboration ManagerPhone 02 9033 4933Email: [email protected]

Hayden BellBoral Construction Materials Limited Strategic Sourcing Analyst Phone 02 9033 4454 Mobile 0401 896 384Email: [email protected]

Jeremy HydeBoral LtdStrategic Sourcing System Specialist Phone 02 9033 4445Email: [email protected]

Step 2 Kick-off meeting with Boral

Boral organises a kick-off meeting with Suppliers.

The objective of this meeting is to determine the following:•Scopeofwork•Roles&responsibilitiesofBoral&Supplier•Supplier’saccountandpaymentstructure•UnderstandthenatureoftradingrelationshipbetweenBoral

and Supplier•Understandspecifictradingbusinessrules•FormationofBoralandSupplierTechnicalteams.

Step 3 Commence setup

Both Technical Teams liaise with each other and initiate setup at both end

Step 4 Commence testing

Both Technical Teams liaise with each other and commence testing so that Boral can:•AccessSupplier’sproductinformation•Createaccurateelectronicpurchaseorders•Receiveassociatedinvoices.

Step 5 Weekly catch up with Boral

Once setup commences, weekly meetings are organised between Boral and Supplier team members to see how each party is tracking until final sign-off is received.

Step 6 Final sign-off

On completion of successful testing a final session is held between Boral and Supplier representatives to confirm set up and receive sign-off.




6 Testing Process The purpose of Testing is to verify that both Boral and the Supplier have the necessary software and hardware required to send, receive, and translate their trading partner transactions through the OSN.

Prior to commencing testing, both trading partners will work together to develop a test plan and test scenarios for the purpose of testing. Whilst these test scenarios will cover the standard transactions, they will also try and encompass any particular business rules or purchasing processes particular to the trading partner relationship. Testing process involves two phases which are discussed below:

1. Integration Testing

2. (User Acceptance) Testing – UAT

6.1 Integration Testing The purpose of this phase is to ensure that:

• TestPurchaseOrderscanberaisedeitherviaaSystemCatalogueorOnlinePunch-outCataloguefromtheBoraltestsystem and transmitted electronically to the Supplier via the OSN. Once received by the Supplier, that they can then be uploaded into the Supplier’s System to create an order.

• InvoicescanbegeneratedfromtheSupplier’ssystemandtransmittedelectronicallytotheOSNfromwhichtheyareable to be uploaded into the Boral Test system and processed for payment.

This phase enables testing of communications, syntax and compatibility of information between business applications. Small test samples (ideally, one or two invoices) are optimal.

6.2 (User Acceptance) Testing – UAT The purpose of this phase is to ensure that various business scenarios are tested to simulate the different type of live transactions that would be encountered on a day to day basis.

These scenarios or transactions will need to take into account any particular business rules or purchasing processes particular to the trading relationship. UAT testing for both parties will be carried out in parallel to test the full end to end process.

Once both parties are happy that testing phases have been completed successfully and all issues addressed, signoff can be obtained to proceed to the “GO LIVE” stage.

7 Appendix I – Terms & Definitions

No. Term Definition

1 OSN Acronym for Oracle Supplier Network, an electronic exchange which allows the transfer of XML messages between Oracle Application Customers and their trading partners.

2 XML eXtensible Markup Language or XML is a standard language used for passing data between applications, particularly those that communicate across the internet. It allows designers to create their own customized tags, enabling the definition, transmission, validation, and interpretation of data between applications and between organizations.

3 cXML Short for commerce XML, a set of document type definitions for the XML specification. cXML works as a meta-language that defines necessary information about a product. It will be used to standardize the exchange of catalogue content and to define request/response processes for secure electronic transactions over the internet. The processes includes purchase orders, change orders, acknowledgments, status updates, ship notifications and payment transactions.

4 OAG The Open Applications Group is a not-for-profit standards development organization focused on building enterprise ready process-based business language standards for both B2B and A2A integration.

5 Trading partner

Oracle Application Customers or their Suppliers who are set up within the Oracle Supplier Network, to enable the electronic transmission and validation of messages between applications and organizations.

>>


8 Appendix I – Related Reference & Documents

8.1 OAG PROCESS PO 007The following table describes the data types (fields) that are used to generate the Process_PO_007. For complete information on the OAG BOD, refer to the Business Object Definition included within the Open Application Group Integration Specification Release 7.2.1 at http://www.oagi.org.

OAGIS PROCESS_PO_007 Required? Description

<CNTROLAREA> The fields included in this area provide information about the XML document

<BSR> Required Shows the Business Service Request name per OAGI

<VERB value=”PROCESS”> Required Value is “PROCESS”

<NOUN value=”PO”> Required Value is “PO”

<REVISION value=“007”> Required Value is “007”

<SENDER> Required Provides information on the system that sends the document

<LOGICALID> Required Sender system identifier

<COMPONENT> Required Sender application name. Value is “PURCHASING”

<TASK> Required Event or Action. Value is POISSUE

<REFERENCEDID> Required Unique reference ID for this document

<CONFIRMATION> Required Confirmation when document is received. Value is 0, meaning none is required

<LANGUAGE> Required Language in which the text fields are transmitted

<CODEPAGE> Required Character set used in this XML document

<AUTHID> Required System ID of sender. Value is APPS

<DATETIME (CREATION)> Required Creation date and time of the XML document

<DATAAREA><PROCESS_PO>

Required The fields included in this area provide information about the data included in the XML document

<POORDERHDR> Required This data type provides header-level purchase order (PO) information. One PO header data type is required per document

<DATETIME (DOCUMENT)> Optional Timestamp for PO creation

<OPERAMT> Optional Total amount of the PO

<VALUE> Optional Monetary amount of the PO





<NUMOFDEC> Optional Number of decimals (applied to Value field)

<SIGN> Optional Indicator (+ or -) of whether the amount is positive or negative

<CURRENCY> Optional Three-character International Standards Organization (ISO) currency code

<UOMVALUE> Optional Numeric value indicator of the value of the factor when amount is expressed in terms of multiples of the unit of measure (UOM)

<UOMNUMDEC> Optional Number of decimals in the UOMVALUE field

<UOM> Optional Unit of measure (units of the quantitative amount)

<POID> Required Unique ID for the purchase order

<POTYPE> Required Indicator of various types of POs. STANDARD or BLANKET is used here

<ACKREQUEST> Optional Acknowledgement required (Y/N)

<CONTRACTS> Optional Supplier’s contract document number, to be used only if this is a release from the blanket order

<DESCRIPTION> Optional Description for the PO header

<NOTES1 – NOTES9> Optional Notes to the Supplier

<PORELEASE> Optional Indicates new release for Blanket

<USERAREA> Optional The following fields are provided by Oracle in this USERAREA

<DATETIME (ACTSTART)> Optional Start active date for the Blanket

<DATETIME (ACTEND)> Optional End active date for the Blanket

<FOB> Optional FOB shipping terms

<DESCRIPTN> Optional FOB description

<TERMID> Optional FOB terms

<FTTERM> Optional Freight payment terms

<DESCRIPTN> Optional Freight description

<TERMID> Optional Freight terms

<EXCHRATE> Optional Currency exchange rate

<DATETIME (EXCHRATEDATE)> Optional Date for the exchange rate

>>



<DATETIME (APPREQ)> Optional Acceptance due by date. Qualifier = ‘APPREQ’

<CONFIRM> Optional PO confirmed. Y/N

<DFFPOHEADER> Optional PO header-level descriptive flexfield (DFF) attributes

<ATTRIBUTE1> Optional PO header-level flexfield

<ATTRIBUTE2> Optional PO header-level flexfield

<PCARDHDR> Optional This segment contains P-card detail

<MEMBERNAME> Optional Member name on the P-card

<PCARDNUM> Optional P-card number

<DATETIME> Optional Expiration date of the P-card

<PCARD BRAND> Optional Brand of the P-card

<PARTNER> – Supplier Optional This data type provides information about the trading partner. Two occurrences of the partner data type are required – Supplier and SoldTo

<NAME> Required Name of the Supplier

<ONETIME> Required Indicator if used only one time

<PARTNID> Required Supplier ID

<PARTNRTYPE> Required Type of partner. Value is Supplier

<CURRENCY> Required Preferred operating currency

<PARTNRIDX> Optional Unique identifier of Supplier

<TAXID> Optional Tax identifier of the Supplier

<USERAREA> Optional Oracle provided fields

<DFFVENDOR> Optional PO Supplier-level descriptive flexfield attributes (16)

<ATTRIBUTE1> Optional PO Supplier-level flexfields

<ATTRIBUTE2> Optional FOB description

<CUSTOMERNUM> Optional Buyer’s ID in Supplier’s system

<ADDRESS> – Supplier Optional Supplier site info

<ADDRLINE1– ADDRLINE9> Required Lines of site address





<CITY> Required City within the address

<COUNTRY> Required Country within the address

<DESCRIPTN> Optional Supplier site name

<FAX1> Optional Fax numbers of the Supplier site

<POSTALCODE> Optional Postal code within the address

<REGION> Optional Region within the address

<STATEPROVN> Optional State within the address

<TELEPHONE1 – TELEPHONE9> Required Telephone numbers for this address

<USERAREA> Optional PO Supplier site-level descriptive flexfield attributes (16)

<DFFVENDORSITE> PO Supplier site-level flexfields

<ATTRIBUTE1> Optional PO Supplier site-level flexfields

<ATTRIBUTE2-16> Optional PO Supplier site-level flexfields

<CONTACT> – Supplier Optional This data type provides contact information for this Supplier

<NAME> Required Contact name for the Supplier

<EMAIL> Required Email address for the Supplier contact

<FAX1 - FAX9> Optional Fax number for the Supplier

<TELEPHONE1 – TELEPHONE9> Optional Telephone number for the Supplier

<PARTNER> – SoldTo Optional Buyer information

<NAME1> Required Name of the buyer company

<ONETIME> Required Indicator of whether this partner is established for this transaction only

<PARTNRID> Required Unique identifier for the partner in Oracle Applications

<PARTNRTYPE> Required Identifier for the type of partner. Value is SoldTo

<CURRENCY> Required Preferred operating currency of the partner

<PARTNRIDX> Optional Unique identifier of the partner

>>



<ADDRESS> – SoldTo Optional The following rows list fields for the address data type related to the partner

<ADDRLINE1 – ADDRLINE3> Optional Lines of the address

<CITY> Optional City within the address

<COUNTRY> Optional Country within the address


<STATEPROVN> Optional State within the address

<TELEPHONE1 – TELEPHONE9> Optional Telephone numbers for this address

<CONTACT> – SoldTo Optional The following rows list fields for the contact data type related to the partner SoldTo

<NAME1> Required Full name of the buyer

<EMAIL> Required E-mail address for the contact

<TELEPHONE1 – TELEPHONE9> Optional Telephone number of the contact

<PARTNER> – BillTo Optional Bill-to location in Oracle Applications. All the organization information is obtained from the SoldTo organization itself

<NAME1> Optional Name of the buyer company


<PARTNRID> Required Unique identifier for the Bill To Location ID in Oracle Applications

<PARTNRTYPE> 7 Required Identifier for the type of partner. Value is BillTo

<CURRENCY> Required Preferred operating currency of the partner


<ADDRESS> – BillTo Optional The following rows list fields for the address data type related to the partner BillTo

<ADDRLINE1 – ADDRLINE3> Optional Lines of the address








STATEPROVN> Optional State within the address


<PARTNER> – Carrier Optional Carrier information is passed in this segment

<NAME1> Optional Name of the carrier


<PARTNRID> Required Not used by Oracle Applications, but required by OAGI. It is assigned a fixed value of 0

PARTNRTYPE> Required Identifier for the type of partner. Value is Carrier

<POTERM> Required The POTERM data type represents payment due dates and discounts

<DESCRIPTN> Required Description of payment terms

<TERMID> Required Identifier for payment terms

<POORDERLIN> Required This data type provides details of a PO line. At least one PO line data type is required. This data type will occur one or more times and contains the following fields

<QUANTITY> Required Quantity of the item ordered, using the following fields

<VALUE> Required Numeric value of the quantity

<NUMOFDEC> Required One-character numeric value that indicates the number of decimals in the value field

<SIGN> Required Indicator (+ or -) of whether the quantity is positive or negative

<UOM> Required Unit of measure that indicates the units of the quantity

<OPERAMT (UNIT)> Required Unit price of the item. Following are the fields included in this segment

<VALUE> Optional Monetary unit amount of the PO line

<NUMOFDEC> Optional Indicator of the number of decimals in the value field

<SIGN> Optional Indicator (+ or -) of whether the amount is positive or negative

<CURRENCY> Optional Three-character ISO currency code

<UOMVALUE> Optional Numeric indicator of the value of the factor when amount is expressed in terms of multiples of the UOM

<UOMNUMDEC> Optional Number of decimals in the UOMVALUE field

>>



<UOM> Optional Unit of measure indicator (units of the quantitative amount)

<POLINENUM> Optional Line number of the PO

<HAZRDMATL> Required Hazardous material class description

<ITEMRV> Optional Item revision number

<NOTES1 – NOTES9> Optional Note to Supplier

<DESCRIPTN> Optional Description of the item

<ITEM> Optional Identifier of the product. All segments are concentrated to display the item

<ITEMX> Required Supplier’s item number

<USERAREA> Optional The following fields are provided by Oracle Applications within this USERAREA

<REQUESTOR> Optional Requestor of this line

<CATEGORYID> Optional Item category unique identifier

<CONTRACTPONUM> Optional Contract PO number for this line

<CONTRACTPOLINENUM> Optional Contract PO line number for this order

<VENDORQUOTENUM> Optional Supplier’s quote number for this line

<LISTPRICE> Optional List price of the item

<MARKETPRICE> Optional Market price of the item

<PRICENOTTOEXCEED> Optional Unit price not to exceed this amount

<NEGPRICE> Optional Negotiable price indicator, using Y (for Yes) or N (for No). Only applicable to blankets. Known as Price Override in Oracle Purchasing

<TAXABLE> Optional Indicator of whether this item is taxable, using Y (for Yes) or N (for No)

<TXNREASONCODE> Optional Transaction reason code, used to group requisition lines for auto creating POs

<TYPE1099> Optional Type 1099, Y/N

<LINEORDERTYPE> Optional Line order type, such as Goods or Services

<HAZRDUNNUM> Optional UN hazard number





<HAZARDUNDESC> Optional UN hazard description

<DFFLINE> Optional

<ATTRIBUTE 1> Optional Descriptive flexfields at the line level

<ATTRIBUTE2-16> Optional Descriptive flexfields at the line level

<DFFITEM> Optional

<ATTRIBUTE 1> Optional Descriptive flexfields at the item level

<ATTRIBUTE2-16> Optional Descriptive flexfields at the item level

<KFFITEM> Optional

<ATTRIBUTE1-20> Optional Key flex fields at the item level

<POLINESCHD> Optional Data type for requested ship date information for this PO line, using the following fields

<DATETIME (NEEDDELV)> Optional Need-by delivery date

<QUANTITY> Required Quantity of the item ordered, using the following fields

<VALUE> Required Numeric value of the quantity

<NUMOFDEC> Required One-character numeric indicator of the number of decimals in the value field

<SIGN> Required Indicator (+ or -) of whether the quantity is positive or negative

<UOM> Required Unit of measure indicator of the units of the quantity

<PSCLINENUM> Required Line number on the delivery schedule of the PO

<USERAREA> Optional The following fields are provided by Oracle in the USERAREA

<DATETIME (PROMSHIP)> Optional Promise date

<DATETIME (APPROVAL)> Optional Last acceptance date

<PRICEOVRRD> Optional For future use

<TAXABLE> Optional Taxable indicator, Y/N

<TAXCODE> Optional Tax code if taxable is Y

<PARTNER> – ShipTo Optional The following fields related to the ShipTo partner data type are provided by Oracle Applications within this USERAREA

>>



<NAME> Optional Name of the ShipTo partner

<ONETIME> Optional Indicator of whether this partner is established for this transaction only. This is always

<PARTNRID> Optional Unique identifier for the partner in Oracle Applications

<PARTNRTYPE> Optional Identifier for the type of partner. Value is ShipTo

<CURRENCY> Optional Preferred operating currency of the partner


<ADDRESS> – ShipTo Optional The ADDRESS element contains the following fields

<ADDRLINE1 – ADDRLINE3> Optional Lines of address for the partner ShipTo




<STATEPROVN> Optional State or providence within the address


<DISTPROJECT> Optional Used only if Projects installed

<REQUESTOR> Optional Requester

<DISTNUM> Optional Distribution number

<PROJECTNUM> Optional Project number

<PROJECTTYPE> Optional Project type

<TASKNUM> Optional Project task number

<QUANTITY> Optional Quantity ordered for this distribution line

<CONVRATE> Optional Currency conversion rate

<DATETIME(EXRATEDATE)> Optional Currency conversion date

<DESTTYPE> Optional Destination type code, such as Inventory or Expense

<DIFFDISTRIBUTION> Optional

<ATTRIBUITE1> Optional Distribution descriptive flexfields (16)

<ATTRIBUTE2-16> Optional Distribution descriptive flexfields (16)




8.2 cXML Purchase Order Request File FormatThe following section provides information on some of the common data types (fields) in the cXML OrderRequest document created by the OSN. For complete information on the cXML Order Request, refer to the cXML specifications at http://www.cxml.org.

Field Descriptions

<OrderRequestHeader> Required

Includes the following attributes: The orderID attribute represents the purchase order number. The orderDate attribute is the date the purchase order was created. The orderType attribute is set to, “regular” or “release” (if order is against a master agreement). The type attribute is set to “new”, or “update” (if order is a change order).

<Total> Optional

Represents the total amount of the purchase order, not including tax and shipping.

<ShipTo> Required

Represents the address of the ShipTo entity. ShipTo address information is always populated in both the header and lines of the OrderRequest. The header ShipTo address information is derived from line 1 ShipTo address.

<BillTo> Required

Represents the address of the Bill To entity.

<Shipping> Optional

Describes the carrier used to ship the line items. Cost of shipping information is not passed from the OAG order.

<Payment> Optional

Represents the payment method.

<Pcard> Optional

The number attribute represents the procurement card number and the expiration represents the expiration date of the card used to pay for the items being requested.

<Contact> Optional

Represents contact information for the buyer – includes name, address, email, and phone information. Contact role information is not passed from the OAG order.

<Extrinsic name = “ACKREQD”> Optional

An extrinsic element used to indicate whether an acceptance from the Supplier is required or not. Value is Y/N.

<Extrinsic name =”ACKBYDATE”> Optional

An extrinsic element used to indicate the date the acceptance from the Supplier must be returned.

<Extrinsic name=”SUPPNOTE”> Optional

An extrinsic element used to capture PO header notes to a Supplier.

The following header level extrinsic fields can be used to exchange additional header information:

<Extrinsic name=”ATTRIBUTE1”/> Optional






<Comments> Optional

Used to capture the description of the PO, if provided by the buyer.

>>


<ItemOut> Required

Includes the following attributes:

The quantity attribute represents the number of items being requested.

The aggrementItemNumber attribute represents the blanket purchase item number if the purchase order is a release. The requestedDeliveryDate attribute is used to capture the need by delivery date.

<ItemID><SupplierPartID> Optional

The Supplier’s part number for the item.

<ItemDetail> Required

<Unit Price> Required

Used to capture the price per unit of the item.

<Description> Required

The description of the item.

<UnitofMeasure> Required

The unit of measure used for the item.

<Extrinsic name=”LINENUM”> Optional

An extrinsic element used to capture the purchase order line number.

<Extrinsic name=”SHIPMENTNUM”> Optional

An extrinsic element used to capture the purchase order shipment line number.

<Extrinsic name=”BUYERPARTNUM”> Optional

An extrinsic element used to capture the buyer’s internal part number.

The following line level extrinsic attribute fields can be used to exchange additional line information:







<SupplierList> Required

Captures all Supplier related information in the following fields:

<Supplier ><Name> Required

The name of the Supplier company

<SupplierID> Required

The identifier assigned by buyer’s Oracle Procurement application for Supplier.

<SupplierLocation> Required

Used to capture Supplier address, phone, and fax information.

<Contact> Optional

<Tax><TaxDetail> Optional

The TaxDetail element uses the purpose attribute to indicate whether the line item is subject to tax. The category attribute indicates the tax code being applied to the line item.

<Comments> Optional Used to capture line item notes for the Supplier.




8.3 OAG PROCESS INVOICE 002 Field Descriptions

The following table describes the data types (fields) in the DTD that are used by Boral to consume the PROCESS_INVOICE_002 message. For complete information on the OAG BOD, refer to the Business Object Definition included within the Open Applications Group Integration Specification Release 7 .2.1.

OAGIS PROCESS_INVOICE_002 Required? Description

<CNTROLAREA> The fields included in this area provide information about the XML document

<BSR> Required Shows the Business Service Request name per OAGI

<VERB value=”PROCESS”> Required Value is “PROCESS”

<NOUN value=”INVOICE”> Required Value is “INVOICE”

<REVISION value=“002”> Required Value is “002”

<SENDER> Required Provides information on the system that sends the document

<LOGICALID> Required Sender system identifier

<COMPONENT> Required Sender application name. Value is “INVOICE”

<TASK> Required Event or Action. Value is “PROCESS”

<REFERENCEDID> Required Unique reference ID for this document

<CONFIRMATION> Required Confirmation when document is received. Value is 0, meaning none is required

<LANGUAGE> Required Language in which the text fields are transmitted

<CODEPAGE> Required Character set used in this XML document

<AUTHID> Required System ID of sender. Value is “APPS”

<DATETIME (CREATION)> Required Creation date and time of the XML document

<DATAAREA><PROCESS_INVOICE>

Required The fields included in this area provide information about the data included in the XML document

<INVHEADER> Required This data type provides header-level invoice information. One invoice header data type is required per document

<DATETIME (DOCUMENT)> Required Timestamp for invoice creation

<AMOUNT (DOCUMENT) > Required This segment is the control total of the debit amounts.Required within the journal entry using transaction currency monetary amounts

>>



<DATETIME (DOCUMENT)> Required Timestamp for invoice creation

<DOCUMENTID> Required A general identifier of a document number, for this document it contains the Supplier’s invoice number

<DESCRIPTN> Optional Description for the invoice header

<DOCTYPE> Optional DOCTYPE is a classification of the document or business transaction

<PARTNER> Optional This data type provides information about the trading partner

<NAME index=”1”> Required Name of the trading partner


<PARTNRID> Optional Unique identifier for the partner in Oracle Applications

<PARTNRTYPE> Optional Type of partner. Value is “Supplier”

<INVCHARGE> Optional This data type provides a summarization of the charge amounts across all INVLINES

<AMOUNT (EXTENDED) > Required This segment is the total of the item amount multiplied by the number of items

<CHARGETYPE> Optional Identifies the type charge applied to an item or document line item

<DESCRIPTN> Optional A free-form description of the transaction or any portion of the transaction

<LINENUM> Optional Line number of the invoice this charge pertains to

<INVLINE> Optional Represents the detail lines of the invoice

<AMOUNT (EXTENDED)> Required Represents the total for the invoice line. It’s the quantity being invoiced times the unit price, including tax

<OPERAMT (UNIT) > Optional The unit price or cost of the item being billed on this invoice

<QUANTITY (UNIT) > Optional The quantity of the item being billed on this invoice

<LINENUM> Required Represents the invoice line number

<DESCRIPTN> Optional A free-form description of the transaction or any portionof the transaction

<ITEM> Optional The Supplier’s identifier of the product being invoiced

<ITEMX> Optional The buyer’s identifier of the product being invoiced





<DOCUMNTREF> Optional The information required to reference a business partner document or document component that pertains to the invoice line

<DOCTYPE> Required Represents the classification of the business document. Value is “PurchaseOrder”

<DOCUMENTID> Required Document number identifier

<PARTNRID> Required Identifier of the partner that the PARTNRTYPE defines

<PARTNRTYPE> Required Identifies the type of partner entity. Value is “Customer”

<DESCRIPTN > Optional A free-form description of the transaction or any portion of the transaction

<LINENUM> Optional Represents the purchase order line number

<SCHLINENUM> Optional number

Represents the purchase order shipment line

<INVTAX> Optional Contains information pertaining to any tax information

<AMOUNT TAX) > Required Represents the total tax amount for this invoice line

<AMOUNT (TAXBASE) > Optional Represents the total amount that is taxable

<QUANTITY (PERCENT) > Optional Represents the tax percentage being used for the invoice line

<DESCRIPTN> Optional A free-form description of the transaction or any portionof the transaction

<LINENUM> Optional Represents the line number of the invoice the tax is being applied

<TAXCODE> Optional Represents the tax identifier for the item being billed

<TAXJRSDCTN> Optional Represents the tax jurisdiction of the business partner

>>


8.4 cXML Invoice Request File Format The following section provides information on some of common data types (fields) in the cXML InvoiceDetailRequest document. For complete information on the cXML InvoiceDetailRequest, refer to the cXML specifications at http://www.cxml.org

Field Descriptions

<InvoiceDetailRequestHeader>

Provides header information that pertains to the entire invoice. The invoiceID attribute is a Supplier generated identifier for the invoice. The invoiceDate attribute is the date and time the invoice was created.

<InvoicePartner> Optional

Represents the partner involved in invoicing.

<Contact role =”remitTo”> Required

Partner contact information that is important to the transaction. In this mapping the role=”remitTo” is mapped to the OAG PARTNER, where PARTNRTYPE=”Supplier”.

<InvoiceDetailOrder> Conditionally Required

Provides invoice information for an order with item details. This is used only when isHeaderInvoice attribute is false.

<InvoiceDetailOrderInfo> Conditionally Required

Provides information about the purchase order that include order reference and any other related information. This is used only when isHeaderInvoice attribute is true.

<OrderIDInfo> Optional

Identifies the buyer’s purchase order number.

<InvoiceDetailItem> Conditionally Required

Represents the invoice line item details. The quantity attribute represents the number of items being invoiced on a transaction. The invoiceLineNumber attribute represents the line number of the invoice the detail information is pertaining.

<UnitOfMeasure> Required

The unit of measure of the item being invoiced.

<UnitPrice> Required

Price per unit of the item being invoiced.

<Tax> <TaxAmount> Required

Total tax amount for the Tax segment.

<Description> Required

Description of the tax.

<TaxDetail> Optional

Detailed tax information. The purpose attribute indicates the tax detail purpose. The category indicates the type of tax being applied. The percentageRate attribute indicates the percentage rate of the tax being used to calculate the tax amount.

<TaxableAmount> Optional

The amount that is taxable.

<TaxAmount> Required

Tax amount.

<InvoiceDetailItemReference> Required

Represents the line item references for an invoice line item.

<SupplierPartID> Required

The Supplier part number.




<NetAmount> Optional

Total net amount that is calculated from gross amount minus discounts.

<InvoiceDetailHeaderOrder> Conditionally Required

<OrderIDInfo> Optional

Identifies the buyer’s purchase order number.

<InvoiceDetailOrderSummary> Conditionally Required

Provides header level summary information for an order at the invoice line level. Only available when isHeaderInvoice attribute is true.

<InvoiceDetailSummary> Required

<Tax> Required

Total tax information.

<ShippingAmount> Optional

Total shipping charge.

<NetAmount> Required

Total net amount that is calculated from gross amount minus discounts.

<DueAmount> Optional