Boral OSN Onboarding

Electronic
Document
Exchange
Between
Boral & Suppliers
Supplier Detailed Process & Procedure Document
Version 1.0 (July 2009)
page 1
>>
page 2 Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009)
Electronic Document Exchange | Boral & Suppliers
>>
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
contents
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
Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009) page 3
>>
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
oral offers a range of electronic services for it’s Suppliers that facilitate fast, efficient and speedy exchange of business
B
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:
• S
aves time: This is one of the first benefits to be realised. Data is transferred between systems with significant
improvements in speed and accuracy.
• R
educes 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.
• F
ast 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.
• R
educes 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?

oral generally uses the Oracle Supplier Network (OSN) to facilitate transacting electronically with its customers.
B
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.
he OSN uses common XML message formats to underpin the exchange of documents. Trading partners can choose from one
T
of the following supported XML standards:
• Open Applications Group (OAG)
• Commerce XML (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.
here the Supplier is unable to communicate using one of the above standards, the Supplier may choose to use a 3rd party
W
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 OrderRequest

OAG PROCESS INVOICE Pass Through OAG PROCESS INVOICE

cXML InvoiceDetailRequest Transformation cXML OrderRequest

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)
• B
oral’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.
• C
ustomer Support Identifier (CSI) – Enter your CSI number if your company has an active support contract for Oracle
Applications.
SI is an identifier assigned by Oracle to it’s application users. If you are not an Oracle application user please leave this
C
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:
3.1.2 Steps to Setup Trading Partners ...
• T
he “My Partners” Tab, where you can add, remove, and approve trading partner relationships and Suppliers can request
iSupplier Portal accounts.
• T
he “Routing Rules” Tab, which shows the communication paths for transactions with your approved trading partner
relationships, as well as broken routes.
• T
he “iSP Wallet” Tab, where Suppliers maintain their iSupplier Portal accounts for instant access to their customers’
iSP sites.
3.2 Boral’s Compatible File Formats

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

Cataloguing 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 Structure

Suppliers 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 Suppliers can begin electronic trading relationship by contacting any of
the following people at Boral.
Contact Boral
Amanda Currall
Boral e-Commerce Collaboration Manager
Phone 02 9033 4933
Email: amanda.currall@boral.com.au
Hayden Bell
Boral Construction Materials Limited
Strategic Sourcing Analyst
Phone 02 9033 4454 Mobile 0401 896 384
Email: hayden.bell@boral.com.au
Jeremy Hyde
Boral Ltd
Strategic Sourcing System Specialist
Phone 02 9033 4445
Email: jeremyhyde@boral.com.au
Step 2 Boral organises a kick-off meeting with Suppliers.
Kick- off meeting with Boral The objective of this meeting is to determine the following:
• Scope of work
• Roles & responsibilities of Boral & Supplier
• Supplier’s account and payment structure
• Understand the nature of trading relationship between Boral
and Supplier
• Understand specific trading business rules
• Formation of Boral and Supplier Technical teams.
Step 3 Both Technical Teams liaise with each other and initiate setup at both end
Commence setup
Step 4 Both Technical Teams liaise with each other and commence testing so that
Boral can:
Commence testing
• Access Supplier’s product information
• Create accurate electronic purchase orders
• Receive associated invoices.
Step 5 Once setup commences, weekly meetings are organised between Boral
and Supplier team members to see how each party is tracking until final
Weekly catch up with Boral
sign-off is received.
Step 6 On completion of successful testing a final session is held between Boral

and Supplier representatives to confirm set up and receive sign-off.
Final 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:
• T
est Purchase Orders can be raised either via a System Catalogue or Online Punch-out Catalogue from the Boral test
system 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.
• Invoices can be generated from the Supplier’s system and transmitted electronically to the OSN from which they are able
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 Oracle Application Customers or their Suppliers who are set up within the Oracle Supplier Network,
partner to enable the electronic transmission and validation of messages between applications and organizations.
>>
8 Appendix I – Related Reference & Documents
8.1 OAG PROCESS PO 007
The 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> Required The fields included in this area provide information about the data
<PROCESS_PO> 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

transaction only
<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

transaction only
<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 Format
The 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> Required The fields included in this area provide information about the data
<PROCESS_INVOICE> 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
<ONETIME> Required Indicator of whether this partner is established for this transaction
only
<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 portion

of 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 Represents the purchase order shipment line

number
<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 portion

of 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
eBC 04442 08.09
© Boral Limited 2009

Boral OSN Onboarding

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Boral OSN Onboarding

Enviado por

Direitos autorais:

Formatos disponíveis

Electronic

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

2.1 Why trade electronically? What are the benefits?

2.2 How can Supplier’s trade electronically with Boral?

2.3 Oracle Supplier Network (OSN)

Inbound to OSN Activity by OSN Outbound from OSN

OAG PROCESS PO Pass Through OAG PROCESS PO

OAG PROCESS PO Transformation cXML OrderRequest

OAG PROCESS INVOICE Pass Through OAG PROCESS INVOICE

cXML InvoiceDetailRequest Transformation cXML OrderRequest

3.1 Registration with Oracle Supplier Network (OSN)

3.1.1 Steps to Register with OSN

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

3.1.2 Steps to Setup Trading Partners

3.2 Boral’s Compatible File Formats

3.2.1 Boral Purchase Order Compatible File Formats

3.2.2 Boral Invoice Compatible File Formats

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 Setup

3.3.1 Boral Hosted Catalogues

3.3.2 Supplier Hosted Catalogues

3.4 Supplier’s Account Structure

4 Oracle Support Network (OSN) Support

SIX STEPS TO BECOME BORAL’S ELECTRONIC TRADING PARTNER

Step 2 Boral organises a kick-off meeting with Suppliers.

Step 6 On completion of successful testing a final session is held between Boral

6.1 Integration Testing

6.2 (User Acceptance) Testing – UAT

7 Appendix I – Terms & Definitions

OAGIS PROCESS_PO_007 Required? Description

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

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

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

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

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

<CODEPAGE> Required Character set used in this XML document