Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Tip

On this page:

Table of Contents
maxLevel2

Onetrail TPN™ Validator

The Onetrail TPN™ Validator is used to validate your messages on both technical and business process level.
The required constraints are set by the XSD and the Business rules are defined by the Onetrail TPN™ Delivery department.
The constraints and business validation rules which has been setup will
be used for the respective OT messages:

  • OrdReq,
  • OrdRsp,
  • DesAdv
  • INV.

This function of the Onetrail Trading Partner Network™ offers you a way to validate your messages
with the Onetrail TPN™ format, checking form, content and syntax, allowing you to get acquainted with the language step by step.
Using only the examples on our Onetrail TPN™ Documentation Center (ODC) developers can only theoretically anticipate on what responses would look like.
Please go to: Onetrail TPN™ Examples for the XML Examples.

Onetrail TPN™ Simulator

To fulfill the need for a one-to-one relation between test-files and responses, we have developed the Onetrail TPN™ Simulator, operating in
conjunction with the Onetrail TPN™ Validator. When a prospect or a customer sends a test-message to the Onetrail TPN™ Test Seller or the Onetrail TPN™ Test Buyer,
the Onetrail TPN™ Validator performs the first check. When no errors are found, the message is sent to the Onetrail TPN™ Simulator.
The message is processed and for example Order Response, Despatch advice and Invoice are generated just as a real Seller would.
The created messages are immediately sent back to you soyou can recognize the used test-data from the original order to clearly
synchronize both ends of communication.

For the Onetrail TPN™ Test Seller we have several different scenarios available when using the Onetrail TPN™ Simulator. You can choose a
scenario by varying the number of lines in a test-order.

  • One order line will activate scenario 1 in which the order is
    accepted as -is by the Seller.
  • Two order lines will activate scenario 2 where the delivery dates
    are changed from requested date by the Seller.
  • Three order lines will activate scenario 3 which leads to a Partial
    delivery, generating 2 Order responses explaining the split, 2
    Despatch Advices (one for each delivery), and 2 Invoices to complete
    the entire Test-order cycle.

Ten scenarios currently exist to choose from, setup by using our knowledge and experience with Suppliers to prepare new customers for any possible situations.
For all possible scenarios please go to: Onetrail TPN™ Test Seller guide more information.
All simulated response-messages refer back to the original order (unless we changed it according to the used scenario) like order numbers, product numbers, quantities, prices, delivery-addresses and so on.
This gives you an good idea of the reality and a way for you to recognize and successfully link your own business logic to the Onetrail TPN™ logic.
Two important differences with reality:
1. Ordered Products to the Onetrail TPN™ test Seller will not really be
delivered
2. Invoices generated by the Onetrail TPN™ test Seller do not have to
be paid.



Anchor
SellerGuide
SellerGuide

Onetrail TPN™ Test Seller Guide

Introduction

You have chosen to process Purchase Orders through Onetrail TPN™. Once the relevant Order messages translations have been developed by you
and/or by Onetrail TPN™ the next step is to ensure quality of operations both from a technical as well as procedural side.

Onetrail TPN™ has established a test facility for Onetrail TPN™ ODE (Order Data Exchange) related messages. This test facility allows you,
as the Buyer, to execute real-time test scenarios related to the order process with responses coming from the Onetrail TPN™ Test Seller.

These test scenarios have been developed taking into account known process exceptions that may occur during day to day business.
In individual situations the (ERP) system used may not be capable to automatically handle all scenario’s. Wherever this applies it is
important to establish manual procedures to properly capture and manage such events.

Test procedures

Once you have been setup to send Purchase Orders (PO), test PO’s can be posted to the Onetrail TPN™ “Acceptance” environment. There are several
PO process scenarios available. The response coming back from the Onetrail TPN™ Test Seller depends on the number of order lines in the PO. (See below under “Test Scenarios”)

General information

Remarks

  • Make sure PO’s are not send to a real Seller (Supplier). Always use the GLN code provided by Onetrail TPN™ related to the “Onetrail TPN™
    Test Seller” (GLN: *8714253023236*) when posting Purchase Orders for testing purposes. In case you would use the ‘live’ GLN code from
    a Seller (Supplier) connected to Onetrail TPN™, the PO will be delivered to that Seller and the goods as well as the invoice for
    those goods will be delivered!
  • If you want certain specific responses (output) back from the Onetrail TPN™ Test Seller the PO needs to be posted using the
    appropriate scenario. Example: Scenario 3 is designed for “partial delivery”, PO’s need to be posted using the code “Partial”.
  • PO’s posted (correctly) with the appropriate scenario they will immediately result in Order Response, Despatch Advice and Invoice
    response message. The XML response messages can be retrievedimmediately using the known by you Buyers GLN code (from the
    Onetrail TPN™ “Acceptance” environment).
  • A report will be send via e-mail to the e-mail address stated inOnetrail TPN™ settings for validation purposes. The report states
    whether all fields are filled correctly and gives an overview ofmandatory / optional fields. You will also find information about
    certain optional fields which Onetrail TPN™ advises to fill.

Validation options

The Onetrail TPN™ Test Seller offers the following validations for the
PO message:

  • Validity of the XML Format. Remark: When you use Web services
    (SOAP), the XML validation is done via the SOAP connector
  • Check if Mandatory fields are properly used
  • The correct use of shipping delivery methods: Complete / Partial,
    Drop ship Yes / No (If Drop ship is set to ‘Yes’ delivery address
    information has to be filled.
  • Changes in delivery schedule
  • Special PO types (Standard, Special Bid, Special Deal)
  • Correct PO posting procedures (scenario dependent)

Test scenario’s

Below you'll find the various test scenario’s. The various scenarios have been build based on the number of order lines used in the PO.
Scenario 1 is generated by posting a PO with one order line, scenario 2 by posting a PO with two order lines etc...

When you need additional charges, discounts or levies in the simulated invoice message for testing, they can be triggered in any combination by
using the remarks element with the proper value for the ‘context’-attribute in your PO. Standard amounts will be returned on
your invoice for Freight Charge, Discount and Levy using text values you provide:

XML Example:

<remarks>
   <remark context="Charge">Transportcosts</remark>
   <remark context="Discount">LoyalCustomer</remark>
   <remark context="Levy">Environmental Fee</remark>
</remarks>

Scenario 1 – Standard PO, Seller accepts PO as is

  • Input: Standard PO with one order line.
  • Response messages (arrive in subsequent order):
    1. One Order Acknowledgement message (send via e-mail).
    2. One Order Status message.
    3. One Despatch Advice message - Serial Numbers added for each productIn Order.
    4. One Invoice message - Serial Numbers added for each product in Order.

Scenario 2 – Seller changes delivery dates

  • Input: Standard PO with two order lines.
  • Response messages:
    1. One Order Acknowledgement message (send via e-mail)
    2. One Order Status message
         2 i). Order line 1: Seller changes delivery date to 2044-04-04
         2 ii). Order line 2: Seller moves delivery date with 30 days
    3. One Despatch Advice message - Only Line 2 (+30 days)
    4. One Invoice message - Only Line 2 (+30 days)

Scenario 3 – Seller puts on Backorder & changes Price

  • Input: PO with three order lines with the delivery code “Partial” (you allow the Seller to perform Partial Delivery):
  • Set delivery code to “Partial”
  • Set number of products on order line 1 to greater than 1 (i.e. 2 or more)
  • Response messages:
    1. One Order Acknowledgement message (send via e-mail)
    2. Two Order Status messages
         2 i). Order line 1: one product of line one will be put on back order,
         2 ii). When QTY > 1 the Orderline will be split, delivery date for back ordered product will be 2044-04-04 in the 1st OrdRsp,
                2nd OrdRsp will be sent to communicate actual delivery date for back  ordered item.
         2 iii). Order line 2 and 3: Price changed by Seller (Default to 123.45) including Totals and Tax
    3. Two Despatch Advice messages
    4. Two Invoice messages

Scenario 4 – Seller returns “Unknown Item” error

  • Input: Standard PO with four order lines
  • Response messages:
    1. One Order Acknowledgement error message (send via e-mail)
          1. Order line 1: Product is ‘Unknown’ by the Seller, only an Order Acknowledgement (error) will be sent, order is fully rejected. (Only ACK: “Connection Exception 501E: Item Number Unknown)

Scenario 5 – Seller changes a Product

  • Input: Standard PO with five order lines
  • Response messages:
    1. One Order Acknowledgement message (send via e-mail)
    2. One Order Status message
         2 i). Order line 1: Product is changed by Seller (ProductIDD6S54AA#ABB)
         2 ii). Order line 2-5: no change
    3. One Despatch Advice message
    4. One Invoice message

Scenario 6 – Seller returns no original order line number

  • Input: Standard PO with six order lines
  • Response messages:
    1. One Order Acknowledgement message (send via e-mail)
    2. One Order Status message
         2 i). Supplier returns no order line numbers
         2 ii). Action: verify if in this case the order is still being updated or an exception occurs.
    3. One Despatch Advice message
    4. One Invoice message

Scenario 7 – Seller includes Promotional product

  • Input: Standard PO with seven order lines
  • Response messages:
    1. One Order Acknowledgement message(send via e-mail)
    2. One Order Status message
          2 i). Supplier adds a free promotional product, which leads to an Order Status including a new (unknown) product.
    3. One Despatch Advice message - Serial Numbers added for each product in Order.
    4. One Invoice message - Serial Numbers added for each product in Order.

Scenario 8 – Seller changes warehouse to drop ship

  • Input: Warehouse PO with eight order lines
     1. Set delivery address to “Warehouse” by using Ship To EAN code
  • Response messages:
    1. One Order Acknowledgement message(send via e-mail)
    2. One Order Status message
          2 i). Supplier changes a warehouse order to a drop shipment address.
    3. One Despatch Advice message - Serial Numbers added for each product in Order.
    4. One Invoice message - Serial Numbers added for each product in Order.

Scenario 9 – Seller Cancels entire order in 2nd Response

  • Input: Standard PO with nine order lines
  • Remark: Seller initially accepts, then rejects entire order, delivery will not take place.
  • Response messages:
    1. One Order Acknowledgement message(send via e-mail)
    2. Two Order Status messages.

Scenario 10 – End Of Life product, Seller cancels part of order

  • Input: Standard PO with ten order lines
  • Remark: Set number of products on order line one to greater than one (i.e. two or more).
  • Response messages:
    1. One Order Acknowledgement message(send via e-mail)
    2. One Order Status message
          2 i). First order line will be split giving delivery date for ordered quantity -1 and EOL (Delete) status for one item.
    3. One Despatch Advice message (line 1: ordered quantity - 1)
    4. One Invoice message (line 1: ordered quantity - 1)