Description of the order

Introduction

The order request is send from a Buyer to a Seller. The receipt of the order request by the Seller is acknowledged with an Acknowledgement or Negative-Acknowledgement message.

Process

The order request is submitted by the Buyer to Onetrail. Onetrail confirms the technical receipt of the order request, process the order request and submit it to the Seller. Once the Seller has confirmed the technical receipt of the order request, Onetrail TPN™ will generate an Acknowledgment and submit this to the Buyer.

In case Onetrail does not confirm the technical receipt of the order request, the Buyer needs to take care of resubmitting the order request. In case the Seller refuses the order request, Onetrail will generate a Non-Acknowledgment and submit this to the Buyer. The Buyer needs to take care of the proper actions and create a new or modified order request. This can differ per Seller, because some Sellers cannot accept the same purchase order number more than once, in that case a new purchase order needs to be created by the Buyer.

Process management

Once the order request is technically accepted by Onetrail, a time-alert is started with the process monitor. Once the order is technically confirmed (can be either "accept"/"reject") by the Seller, the time-alert is removed from the process monitor. If the time-alert is not removed within the specified time frame, the process monitor will generate an exception and the Onetrail support department will take appropriate actions.

Order scenarios

Onetrail supports the following order scenarios:

1. Drop Shipment Order (direct shipment)
2. Warehouse Order
3. Special Bid Order
4. Special Deal Order
5. eCarepack Order
6. Reservation Order
7. Build To Order

The scenarios can be combined, except 1 with 2 and 3 with 4.

Also the following flags are available:

• Ship Complete (both on header and line level)

Content

The companies and addresses used in the orders are referenced by Global Location Numbers (formerly known as EAN/ILN address codes). These codes can be supplied by Onetrail unless your company already has GLN's numbers. These given GLN's can only be used to communicate with Onetrail.

The following GLN's are relevant to the Order Request:

• To identify the Buyer:
  • XML: fromRole
  • EDIFACT: UNB020, S002, 0004
• To identify the Seller:
  • XML: toRoleEDIFACT: UNB030, S003, 0010

• Where the goods are shipped to in case of Warehouse Shipment:
  • XML: ShipTo
  • EDIFACT: NAD+ST
• Where the Invoice needs to be send to:
  • XML: BillTo
  • EDIFACT: NAD+IV

Format & Syntax

XML

The format of the standard Onetrail XML messages is XML version 1.0. The encoding must be UTF-8.

EDIFACT

Besides XML Onetrail also supports a standard Edifact D97A INVOIC besides a lot of other industry standards. For more information about supported standards we refer to: Available Industry Standards

Communication

Besides SOAP and REST web services , Onetrail also supports HTTPS, FTP, AS2 and other communication protocols.

Examples

Supported processes

In this section we describe the various supported processes and how to use them for the Order Message. Each process is described in the subsections below. For more information about which Seller supports which process types for the Order Message, please refer to: Supported order processes by suppliers

Drop Shipment Delivery

Drop Shipment Delivery is used by the Buyer to ask the Seller to ship ordered products directly to the Buyer's Customer. The Buyer must add the End-User address information in the Purchase Order to inform the Seller about the location where to send the ordered products.

XML usage:

Fixed values
<isDropShip><AffirmationIndicator>: "Yes" in case of direct shipments else "No"
Variable values
Name and Address fields in <shipTo><PartnerDescription> block.

EDIFACT usage:

Do not include:
Segment group 2: NAD
Party qualifier: ST

Must include:
Segment group 2: NAD
Party qualifier: UD
Example: NAD+UD+++Onetrail B.V.+Handelsweg 6-1+Zeist++3707 NH+NL'

End-User Reference

Onetrail is able to receive and process End-User Reference in the Buyer's Purchase Order. When the Buyer asks the Seller to ship the ordered products as a Drop Shipment to the End-User, the End-User Reference on the Despatch Advice generated by the Seller is helpful on receiving the goods at the end user.

XML usage:

Variable value
<GlobalPurchaseOrderTypeCode>: Any of the Order Types
Fixed value:
<GlobalDocumentReferenceTypeCode>: "Work Order"
Variable values
<GlobalDocumentReference><ProprietaryDocumentIdentifier>: Reference of end customer

EDIFACT usage:

Include:
Segment group 1: RFF
Reference qualifier: CO
Example: RFF+CO:EndUser 1234567'

Warehouse Delivery

Warehouse Delivery is used when the Buyer asks the Seller (i.e. a Distributor) to ship the ordered products to the Buyer's own Warehouse(s). This can also be fixed delivery addresses at Buyers customers known by the Seller.

XML usage:

Fixed value:
<shipTo><PartnerDescription><BusinessDescription><GlobalBusinessIdentifier>: GLN of the warehouse or known / agreed upon delivery location

EDIFACT usage:

Do not include:
Segment group 2: NAD
Party qualifier: UD
Must include:
Segment group 2: NAD
Party qualifier: ST
Example: NAD+ST+8713783719640::9'

Special Bid Order

The Special Bid Order is used when a Manufacturer provides a Special Bid (i.e. Special Bid Price for certain products under (Special Terms and Conditions) for Specific End-User(s). A Special Bid Order is used in the IT Business vertical markets. Manufacturers/Vendors like i.e. HP have special agreements (contracts) with Specific End-Users (i.e. ‘Shell’). The Manufacturer/Vendor makes use of their Channel (i.e. Distributors and Resellers) for the delivery of the Special Bid products. This is because the Manufacturer/Vendor is using the regular stock products which are in stock at the Distributor. The deal allows Specific End-User to buy products at a different price instead of the regular price. The Distributor will support the lower price for all goods delivered for the Specific End-User by claiming the difference from the Manufacturer/Vendor. The delivery to the End-User is done by a Reseller. Subsequently, the Reseller needs to report in the Purchase Order to the Distributor that the order is for a Specific End-User. By adding End-User contract number information in the Purchase Order, the Distributor knows that they can give price support to the Reseller and they can claim the difference from the Manufacturer by validating the contract information.

XML usage:

Fixed values:
<GlobalPurchaseOrderTypeCode>: "Special Bid Order"
<GlobalDocumentReferenceTypeCode>: "Contract"
Variable values
<GlobalDocumentReference><ProprietaryDocumentIdentifier>: Contract number (i.e. OPG)

EDIFACT usage:

Include:
Segment group 1: RFF
Reference qualifier: CT
Example: RFF+CT:SpecBid 1234567'

Special Deal Order

The Order Type ‘Special Deal’ is used when a Buyer is sending a Purchase Order to the Seller with i.e. an agreed special price or special handling by the Distributor. By using this Order type the ERP system of the Distributor can recognize that special handling is necessary.

XML usage:

Fixed values:
<GlobalPurchaseOrderTypeCode>: "Special Deal Order"
<GlobalDocumentReferenceTypeCode>: "Quote"
Variable values
<GlobalDocumentReference><ProprietaryDocumentIdentifier>: Quote number

EDIFACT usage:

Include:
Segment group 1: RFF
Reference qualifier: AAG
Example: RFF+AAG:SpecDeal 1234567'

Care Pack Orders

In addition to a product, there is the possibility to order Care Packs (i.e. Warranty License). The Seller needs to know for whom (i.e. End-User) the Care Pack is ordered. This extra information (i.e. End-User Reference) is mandatory in the Purchase Order for Care Pack Orders.

XML usage:

Variable values
<SecondaryBuyer><PartnerDescription>: Name of (Carepack) Buyer
Name and Address fields in underlying <shipTo><PartnerDescription> block.

EDIFACT usage:

Include
Segment group 2: NAD
Party qualifier: UD
Example: NAD+UD+++Onetrail B.V.+Handelsweg 6-1+Zeist++3707 NH+NL'

Software License Order

The Software License Order type is used to order a Software License (in the IT Channel). A Software License is a Build to Order (BTO) software deal based on several values where an End-User specific agreement is established between the Manufacturer and the End-User. Based on the use of the License Order type the Seller can recognize for which End-User the Buyer orders the Software License.

XML usage:

Fixed values
<GlobalPurchaseOrderTypeCode>: "New License Order"
<GlobalDocumentReferenceTypeCode>: "Ultimate Customer Order"
Variable values
<GlobalDocumentReference><ProprietaryDocumentIdentifier>: License number
<isLicence><AffirmationIndicator>: "Yes" in case of license order else "No"
For care-pack orders this flag can be set to "No"

Renewal Order

The Renewal Order type is used to renew a Software License (in the IT Channel). A Software License is a Build to Order (BTO) software deal based on several values where an End-User specific agreement is established between the Manufacturer and the End-User. Based on the use of the License Order type the Seller can recognize for which End-User the Buyer renews the Software License.

XML usage:

Fixed values
<GlobalPurchaseOrderTypeCode>: "Renewal Order"
<GlobalDocumentReferenceTypeCode>: "Ultimate Customer Order"
Variable values
<GlobalDocumentReference><ProprietaryDocumentIdentifier>: License number
<isLicence><AffirmationIndicator>: "Yes" in case of license order else "No"
For care-pack orders this flag can be set to "No"

ESD Order

ESD is the abbreviation for Electronic Software Distribution. The ESD Order type is used to order products online, e.g. software delivery, upgrade, and management service devised by Distributors or Manufacturers. For instance, when a Reseller or Retailer is selling access to Microsoft’s Cloud solution Office 365, there is no physical supply of goods. The ESD Order type enables the Distributor or Manufacturer to recognize that they only have to send an approval link back. The End-User can start using the purchased software instantly.

XML usage:

Same as regular Order

EDIFACT usage:

Same as regular Order

Project Order

The Project Order type is used to refer to a project in the Order. This order type is supported by Onetrail only for Technical Services and Construction markets. For example, if the Order refers to a project, one can specify the project by adding the project number in the Order.

XML usage:

Variable values
<GlobalPurchaseOrderTypeCode>: Any of the Order Types
Fixed value
<GlobalDocumentReferenceTypeCode>: "Project"
Variable value
<GlobalDocumentReference><ProprietaryDocumentIdentifier>: Project number

EDIFACT usage:

Include:
Segment group 1: RFF
Reference qualifier: AEP
Example: RFF+AEP:Project 1234567'

Collect Order

The Collect Order type is used by the Customer or End-User to collect ordered products directly from the Seller. For example, the Collect Order type can be used in the Purchase Order by the Buyer, Customer or End-User who prefer to collect the ordered products from the Distributor or Manufacturer. The Collect Order type informs the Distributor or Manufacturer that direct action is needed.

XML usage:

Mainly Technical Installation Use! Check with Onetrail if you want to use this option

EDIFACT usage:

Include Segment group 26: TOD
Delivery or transport terms function code: 2
Include Segment group 2: NAD
Party qualifier: SF

Reservation Order (Call-off)

Reservation Orders (call-off orders) are used to place orders for already agreed-upon products and quantities between Seller and Buyer. The Buyer receives (via phone or email) a reservation/quote number that needs to be used as a reference when placing the order.

XML usage:

Fixed values
<GlobalPurchaseOrderTypeCode>: "Reservation Order"
<GlobalDocumentReferenceTypeCode>: "Reservation"
Variable values
<GlobalDocumentReference><ProprietaryDocumentIdentifier>: Reservation number

EDIFACT usage:

Include:
Segment group 1: RFF
Reference qualifier: AEO
Example: RFF+AEO:Reserved 1234567'

Onetrail Order Change / Cancel

The Order Change type is used for the communication of any changes on outstanding orders.
The options are:

• Adding order lines
• Changing quantity or delivery date of existing order lines
• Deleting order lines
• Changing only the Delivery Address
• Changing from Warehouse-delivery to Dropshipment
• Deleting all order lines in an existing order will change the Order Change into an ‘Order Cancel’ request.

The condition for an Order Change message is that it contains the same Purchase Order Number as the original Order Request.
When the Purchase Order Number mentioned in Order Change does not match the Purchase Order Number in the original Order Request, the Order Change can’t be linked and will not be properly processed.

XML usage:

Variable values
<GlobalPurchaseOrderTypeCode>: "Purchase Order"
Fixed value
<GlobalDocumentFunctionCode>: "Change"
<GlobalPurchaseOrderStatusCode>: "Add" (One or more lines are added to original OrdReq by the Buyer) "Change" (One or more lines are changed (quantity/price/deldate) or deleted from original OrdReq by the Buyer, or Delivery Address is changed) "Delete" (All order lines are deleted from original OrdReq by Buyer)
Variable values
<GlobalDocumentReferenceTypeCode>: Depending on original Order
<GlobalDocumentReference><ProprietaryDocumentIdentifier>: Reference belonging to above reference type

Ship Complete or Partial On Order Level

The reference Ship Complete or Partial On Order Level can be used in the Buyer’s Purchase Order to inform the Seller that the delivery of the Order needs to be done complete or partial.

XML usage:

Fixed value
<OrderShippingInformation><GlobalSpecialFulfillmentRequestCode>: "Complete" (One delivery per order) or "Partial" (Backorders are allowed)

EDIFACT usage:

Include:
Segment group 16: SCC
Delivery requirements: BK or SC
Example: SCC+10+BK'

Planned Delivery

Planned Delivery is a delivery with a date in the future. In the Buyer’s Purchase Order the use of the delivery date in the requested delivery date field informs the Seller that the delivery of a specific Order (line) needs to be done on a specific date in the future. Header and/or Line level.

XML usage:

Variable value
<requestedEvent><TransportationEvent><GlobalTransportEventCode>: "Ship" (When goods need to leave Sellers warehouse) or "RequestedDelivery" (When goods need to arrive in Buyers warehouse)
<requestedEvent><TransportationEvent><DateStamp>: Enter the requested delivery date in field

EDIFACT usage:

Include:
On line level use Segment 28: DTM
Date time period qualifier: 2
Example: DTM+2:20200204:102'

Special Delivery

Some Sellers allow you to ask for special Delivery (times) or shipping conditions on their orders. This is done by adding a mutual agreed code between Buyer and Seller to the Order. The so called Delivery Types. Most UK Sellers support this process, for more information and other countries please contact Onetrail. Examples can be codes for: Next day Pre-Noon delivery, Same day before 12:00, Same day afternoon, Saturday, etc. etc.

XML usage:

Variable value
<OrderShippingInformation><GlobalShipmentTermsCode><GlobalShippingServiceLevelCode>: Depending on the Seller this element can be used to specify special shipping conditions (Delivery Types). Check with Onetrail for more detail which codes can be used.

Supported Product Codes in the Order Message

Onetrail supports the following product codes in the Order Message:

• Seller Product Codes: Stock Keeping Unit number (SKU), internal Seller ERP product code.
• Manufacturers / Vendor Product Codes: Manufacturer Part Number (MFPN) / Vendor Part Number (VPN) /OEM.
• GTIN / EAN Product Codes: Global Trade Item Number (GTIN) / European Article Number (EAN) a unique product code supplied by GS1.
• Buyer Product Codes: Buyers own product code.

XML usage:

Variable value
<ProductIdentification><PartnerProductIdentification><GlobalPartnerClassificationCode>: "Seller" or "Manufacturer" or "EAN" or "Buyer"
<ProductIdentification><PartnerProductIdentification><ProprietaryProductIdentifier>: Enter the above related part number in field

EDIFACT usage:

Include:
Segment group 28: LIN
Item number type: SA
Include:
Segment group 28: PIA
Item number type: BP or EN or VN
Example: LIN+1++800640-605:SA'
Example: PIA+1+800640-605:VN'

Conversion Manufacturer Part Number into Stock Keeping Unit or GTIN

Sellers can ask for a conversion from Manufacturer Part Numbers (MFPN) into Stock Keeping Unit (SKU) and/or GTIN if a Seller’s business process is based on SKU codes and/or GTIN instead of MFPN. Onetrail supports the conversion of MFPNs into SKUs and/or GTIN in the Buyer’s Purchase Order.

For example, when it's not possible for a Buyer to send the Seller product code and/or GTIN in the Purchase Order it's sent to Onetrail with MFPNs. After the conversion of the MFPNs into SKUs and/or GTIN by Onetrail the Seller receives SKUs and/or GTIN instead of MFPNs in the Buyer’s Purchase Order.

Price Validation

Price Validation on the order is done by some Sellers by informing the Buyers pricing is correct or false.
There are connected Sellers that are able to accept Orders with real-time Price Validation in their system. Onetrail supports those Sellers by real-time informing the Buyer. For example, some Sellers are able to accept Orders with price differences versus calculated prices in their system. Some Sellers automatically change prices in Orders into calculated prices in their system.
In the last case, the Seller overrules the price sent by the Buyer. Most Sellers technically accept the order and will use e-mail or phone to talk about the price difference(s) with the Buyer.

Kill-Fill On Order Level

Onetrail supports Kill-Fill On Order Level by informing the Buyers what conditions are used by the connected Sellers. Kill-Fill On Order Level is supported by some Onetrail connected Sellers. The reference Kill-Fill can be used on the Order. This Order type informs the Seller only to accept Orders for those ordered products which are in stock. All ordered products which are out of stock will be automatically deleted from the Order.

If you want to use Kill-Fill please contact Onetrail to see if your Seller(s) support this process.

Kill-Fill On Order Line Level

Onetrail supports Kill-Fill On Order Line Level by informing the Buyers what conditions are used by the connected Sellers. Kill-Fill On Order Line Level is supported by some Onetrail connected Sellers. The reference Kill-Fill On Order Line Level can be used on the Order. This reference informs the Seller only to accept ordered products on Line Level which are in stock. All ordered products which are out of stock on a specific Order Line will be automatically deleted from the Order.

If you want to use Kill-Fill please contact Onetrail to see if your Seller(s) support this process.

ACK/NACK on Submission or after Order Processing

Not all Sellers have the same procedure about the first response after the Buyer has send an Order. There are Sellers who give an acceptance message without a real validation of the Order. Other Sellers are giving back an acceptance message with validation.
Via Onetrail the Buyer knows what Seller is using which procedure. Based on these settings Onetrail uses an Order Acknowledgement (ACK) or Negative Acknowledgement (NACK) procedure.
For every Order delivered to the Sellers, Onetrail checks the technical delivery of the Order to the Seller. Through this procedure the Buyer knows that the Order is technically delivered to the Sellers as agreed between Onetrail and the Seller.
The technical delivery only means it arrived at the respective Seller and not always acceptance and validation of the Order.