Professional Documents
Culture Documents
Boral OSN Onboarding
Boral OSN Onboarding
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
contents
3.1.1 Steps to Register with OSN 6
6 Testing Process 11
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.
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).
page 4 Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009)
Electronic Document Exchange | Boral & Suppliers
>>
The OSN supports the following transaction flows:
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
Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009) page 5
>>
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.
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.
page 6 Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009)
Electronic Document Exchange | Boral & Suppliers
>>
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.
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.
Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009) page 7
>>
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.
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.
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.
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.
page 8 Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009)
Electronic Document Exchange | Boral & Suppliers
>>
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
Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009) page 9
>>
5 Six Simple Steps to become Boral’s electronic trading partner –
The Process & Contacts
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.
page 10 Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009)
Electronic Document Exchange | Boral & Suppliers
>>
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
This phase enables testing of communications, syntax and compatibility of information between business applications.
Small test samples (ideally, one or two invoices) are optimal.
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.
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.
Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009) page 11
>>
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.
<CNTROLAREA> The fields included in this area provide information about the XML
document
<BSR> Required Shows the Business Service Request name per OAGI
<SENDER> Required Provides information on the system that sends the document
<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
page 12 Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009)
Electronic Document Exchange | Boral & Suppliers
>>
OAGIS PROCESS_PO_007 Required? Description
<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)
<USERAREA> Optional The following fields are provided by Oracle in this USERAREA
Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009) page 13
>>
OAGIS PROCESS_PO_007 Required? Description
<PARTNER> – Supplier Optional This data type provides information about the trading partner.
Two occurrences of the partner data type are required – Supplier
and SoldTo
page 14 Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009)
Electronic Document Exchange | Boral & Suppliers
>>
OAGIS PROCESS_PO_007 Required? Description
<CONTACT> – Supplier Optional This data type provides contact information for this Supplier
Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009) page 15
>>
OAGIS PROCESS_PO_007 Required? Description
<ADDRESS> – SoldTo Optional The following rows list fields for the address data type related to
the partner
<CONTACT> – SoldTo Optional The following rows list fields for the contact data type related
to the partner SoldTo
<PARTNER> – BillTo Optional Bill-to location in Oracle Applications. All the organization
information is obtained from the SoldTo organization itself
<PARTNRID> Required Unique identifier for the Bill To Location ID in Oracle Applications
<ADDRESS> – BillTo Optional The following rows list fields for the address data type related to
the partner BillTo
page 16 Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009)
Electronic Document Exchange | Boral & Suppliers
>>
OAGIS PROCESS_PO_007 Required? Description
<POTERM> Required The POTERM data type represents payment due dates and
discounts
<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
<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
<UOMVALUE> Optional Numeric indicator of the value of the factor when amount is
expressed in terms of multiples of the UOM
Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009) page 17
>>
OAGIS PROCESS_PO_007 Required? Description
<ITEM> Optional Identifier of the product. All segments are concentrated to display
the item
<USERAREA> Optional The following fields are provided by Oracle Applications within this
USERAREA
<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
page 18 Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009)
Electronic Document Exchange | Boral & Suppliers
>>
OAGIS PROCESS_PO_007 Required? Description
<DFFLINE> Optional
<DFFITEM> Optional
<KFFITEM> Optional
<POLINESCHD> Optional Data type for requested ship date information for this PO line,
using the following fields
<QUANTITY> Required Quantity of the item ordered, using the following fields
<USERAREA> Optional The following fields are provided by Oracle in the USERAREA
<PARTNER> – ShipTo Optional The following fields related to the ShipTo partner data type are
provided by Oracle Applications within this USERAREA
Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009) page 19
>>
OAGIS PROCESS_PO_007 Required? Description
<ONETIME> Optional Indicator of whether this partner is established for this transaction
only. This is always
<ADDRESS> – ShipTo Optional The ADDRESS element contains the following fields
<DIFFDISTRIBUTION> Optional
page 20 Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009)
Electronic Document Exchange | Boral & Suppliers
>>
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.
The following header level extrinsic fields can be used to exchange additional header information:
<Extrinsic name=”ATTRIBUTE1”/> Optional
<Extrinsic name=”ATTRIBUTE2”/> Optional
<Extrinsic name=”ATTRIBUTE3”/> Optional
<Extrinsic name=”ATTRIBUTE4”/> Optional
<Extrinsic name=”ATTRIBUTE5”/> Optional
<Extrinsic name=”ATTRIBUTE6”/> Optional
<Comments> Optional
Used to capture the description of the PO, if provided by the buyer.
Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009) page 21
>>
<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.
The following line level extrinsic attribute fields can be used to exchange additional line information:
<Extrinsic name=”ATTRIBUTE1”/> Optional
<Extrinsic name=”ATTRIBUTE2”/> Optional
<Extrinsic name=”ATTRIBUTE3”/> Optional
<Extrinsic name=”ATTRIBUTE4”/> Optional
<Extrinsic name=”ATTRIBUTE5”/> Optional
<Extrinsic name=”ATTRIBUTE6”/> Optional
<SupplierList> Required
Captures all Supplier related information in the following fields:
<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.
page 22 Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009)
Electronic Document Exchange | Boral & Suppliers
>>
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.
<CNTROLAREA> The fields included in this area provide information about the XML
document
<BSR> Required Shows the Business Service Request name per OAGI
<SENDER> Required Provides information on the system that sends the document
<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
<AMOUNT (DOCUMENT) > Required This segment is the control total of the debit amounts.
Required within the journal entry using transaction currency
monetary amounts
Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009) page 23
>>
OAGIS PROCESS_INVOICE_002 Required? Description
<PARTNER> Optional This data type provides information about the trading partner
<ONETIME> Required Indicator of whether this partner is established for this transaction
only
<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
<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
page 24 Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009)
Electronic Document Exchange | Boral & Suppliers
>>
OAGIS PROCESS_INVOICE_002 Required? Description
<DESCRIPTN > Optional A free-form description of the transaction or any portion of the
transaction
<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
<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
Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009) page 25
>>
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.
<OrderIDInfo> Optional
Identifies the buyer’s purchase order number.
<UnitOfMeasure> Required
The unit of measure of the item being invoiced.
<UnitPrice> Required
Price per unit of the item being invoiced.
<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.
page 26 Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009)
Electronic Document Exchange | Boral & Suppliers
>>
<NetAmount> Optional
Total net amount that is calculated from gross amount minus discounts.
<InvoiceDetailSummary> Required
<Tax> Required
<ShippingAmount> Optional
Total shipping charge.
<NetAmount> Required
Total net amount that is calculated from gross amount minus discounts.
<DueAmount> Optional
Supplier Detailed Process & Procedure Document | Version 1.0 (July 2009) page 27
eBC 04442 08.09