What is The Oasis...?
The OASIS is the 3T process for integrating with Event.
Order data in and routed data out.
​
​
What is Event..?
Event is the 3T Transport Management Platform.
It can receive from you orderline / sku level data, pack and consolidate it to create shipments for routing optimisation through the selection of the optimial equipment type and carrier.
It can update these orderlines from triggers sent by you and re-optimise these shipments and routes.
​
It has custom build Packaging, consolidation and both carrier and routing optimisation algorithms
What will you need?
You will need to be able to send Event accurate, live order information.
​
-
A new order, when 1st received
-
Any updates to that order already sent to Event [changes to date, quantity, manufacturing estimate etc]
-
To tell Event if it has been cancelled
-
To confirm to Event that it has been despatched [the actual despatch quantity and the POD reference]
Where do we start?
The integration is an order file.
It is also the life cycle of this order as it goes from being a NEW order, through UPDATED [maybe Req Date or quantity] to being despatched [COMPLETE].
​
The OASIS is made up of several sections:
-
The design of the xml order files
-
Required data fields
-
Optional data fields
-
Custom data fields
-
-
​The send of the xml order files​
-
The export of the planned data back from Event
Who needs to create the integration?
The requirement is to create an OASIS format output that can be imported into Event.
This can either be actioned by your internal IT or through a 3rd party comany that can do the translation from your format and process into the Oasis format
In the below example, you can see a 3rd party translation company in GREEN. If the integration is direct between Event and your WMS / ERP, the GREEN section would be ignored.
Where do i get the specification?
This is the specification for designing your integration
​
Inbound order files [NEW, UPDATE, COMPLETE, CANCEL]
The OASIS schema
04-01-2021
Sheet 1 = The specification. Design what you want to send.The data fields available, what they mean.
Sheet 2 = an example of a NEW xml creation from the schema
Sheet 3 = an example of a COMPLETE xml created from the schema
Do you have any examples of actual files?
Below are examples of NEW / UPDATE and CANX prefix files using the most popular data fields
These are the same with differemt prefixes
​
The COMPLETE file has some different data filelds
The OASIS schema
NEW / UPDATE / CANX
21-11-2020
.DAF file
The OASIS schema
COMPLETE
22-11-2020
.DAF file
You can use the specification above to map the 'required' data and then decide on what other information you want to provide that means something to you.
For example, providing a delivery date for your orders, tell us if the order goes 'on hold' or add 'product' information.
Once you have decided on the data to send in addition to the required information, you can build your order xml. Examples of these xml's can also be found above to help you.
​
OASIS integration has 3 levels of complexity:
-
Required data (i.e. source and delivery address)
-
Optional data (i.e. delivery instructions)
-
Custom data (i.e. specific data to you, such as reference numbers)
The OASIS process flow
NEW
Data flow and validation
OASIS
Send once
Send multiple
Send multiple
or
Routed orders
Send once
Send once
Despatched order
Optional
Send once
Example data
Unique order number
Coll date
Del Date
Pickup address
Destination address
Handling unit total
Product desctiption
...
...
Unique order number
Coll date
Del Date
Pickup address
Destination address
Handling unit total
Product desctiption
...
...
UPDATE or CANCEL
ROUTE file
Carrier name
Coll date
Del Date
Route No
Stop No
Order numbers
Products
...
...
Unique order number
Coll date
Del Date
Pickup address
Destination address
DespatchedHU total
Despatched Product
...
...
COMPLETE
What does Required mean?
This is the start of the process. Here we provide you with the data fields that must be included in the build of your Event integration
This is the base information we require to make Event work so you can deliver orders to customers
What does Optional mean?
This is the 2nd part of the process, the Optional data stage. Here we have provided you with the data fields that are most frequently used in enhancing Event integrations.
For example you may want to add product information, not just HU level or maybe a collection date or delivery instructions.
You have the option to decide...
What does Custom mean?
The OASIS integration looks to provide you with the most common types of data for your order and in most cases this is enough.
But for some customers, they have data types specific to them. For those we have created Custom Fields
Custom fields need to be added to the correct section. If you are adding a new item that relates to a product, add it to the product section, if a reference, in the reference section...
What does NEW, UPDATE etc actually mean?
Orderlines from order book integration
Address
Coll date
Del date
Booking times
Equipment
Order numbers
Incoterms
...
Validation [schema]
Can an order be consolidated to an existing order already received?
NO
YES
Find matching orderline and consolidate orderlines on the route
Packaging will take all the orderlines provided and calculate the optimal 'package'. Looking at size, stacking, rotation, tilt, to provide a volume.
Pack the order to calculate the volume. Create a new Stop
Check fit on existing route, vehicle size. Recalculate packing and add back to existing route.
We use our own global address database and Google servies to validate addresses provided.
Set collection / delivery dates from transit times
Auto reoptimise the updated Stop within the day plan
Closest together Stops
Booking windows
Size of Stop
Stop instructions
Vehicle capacity
Best carrier reallocation
...
Check all ACTVE routes for best Stop placement
Can Stop be reoptimised in current ACTIVE day plan?
NO
YES
NEW prefix to an order file
This is a brand new order that has never been sent to Event.
For an order number [which MUST be unique] you will only ever send 1 NEW order file
If you send a NEW and then another NEW for the same order number we will ingore the 2nd order file
In this case you should have sent an UPDATE after the NEW
​
How does Event know?
We use the order number to identify if we have already got it in Event.
​
What if I have different products for the same order number, so multiple new orders for the same order number?
Then you will identify them by using the <LINE_No> field in the specification to differentiate.
​
-
0123456_1 - Product A
-
Required <CUS_ORD_NO>0123456​</CUS_ORD_NO>
-
Optional <LINE_NO>1</LINE_NO>
-
-
0123456_2 - Product B
-
0123456_3 - Product C
​
UPDATE prefix to an order file
This is a change made to an existing NEW.
For example, your customer service team update the required delivery date on an order. You will generate and send the same format as the NEW file but with a PREFIX of UPDATE and the new required delivery date.
Not just the required delivery date field but the whole order message again.
Our process will check the order number, look for the prefix and then identify the update made. Then make this update in Event for the operations team.
​
How does Event deal with these updates in a LIVE environment?
In Event we use different status to represent where in the process the order currently sits.
We actio the update in different ways based on its current status.
​
COMPLETE prefix to an order file
This is a change made to an existing NEW or UPDATE
It is specifically sent at the point the order is despatched for delivery [this is usually the despatch team updating what actually left the warehouse]
For example, An order is loaded onto a vehicle. The planned quantity is 12 plts but only 10 are ready in time for loading, so despatch will update your system with 10 plts. You create a new order message, prefix COMPLETE and update the DESPATCHED fields with 10.
​
The format is the same as NEW and UPDATE apart from the following fields need to be completed:
​
-
<QTY_DELIVERED> - you will need to tell HU's us what was despatched for delivery
-
<DEL_QUANTITY> - you can optionally tell us what Product quantity was actually despatched
-
<DESP_NOTE_NO> - you will need to tell us the POD reference that your users will search for a POD by.
​
Example
-
<HANDLING_UNITS>
-
<QTY_DELIVERED>10​</QTY_DELIVERED>
-
and if you are using Products field
-
<PRODUCTS>
-
<DEL_QUANTITY>​2000</DEL_QUANTITY>​
-
​
What about short deliveries. How do you send the remaining items on the order number?
So sometimes not all the product for a delivery is ready at the point of departure.
Its goes short.
So the COMPLETE order message [from above] will say 12 plts to deliver but only 10 plts were despatched.
That means you still have 2 plts to send.
​
In this situation you have 2 options in OASIS:
-
To close the order in your system and to create a new order number for the 2 plts.
-
To use the <PREV_DESPATCH> field to show that it
​
Previous Despatch lets you indicate to OASIS that you want the same order / line number to NOT be ignored [remember, as we already have that combination as a COMPLETE].
By setting the Previous Despatch OASIS will now use order / line / prev destach to check for uniqueness. If that combinatin is unique, allow import.
​
Example for 12plts
​
-
<LINE>​
-
<CUS_ORD_NO>0123456​</CUS_ORD_NO>
-
<LINE_NO>1<LINE_NO>​​
-
<PREV_DESPATCH/>
-
​
Now at point of despatch only 10plts where ready. You have a remaining 2plys that you still want to deliver on the same order / line number combination.
​
-
<LINE>​
-
<CUS_ORD_NO>0123456​</CUS_ORD_NO>
-
<LINE_NO>1<LINE_NO>​​
-
<PREV_DESPATCH>1</PREV_DESPATCH>
-
​
CANCEL prefix to an order file
This is a change made to an existing NEW or NEW. Not to a COMPLETE.
It is the same format, with just a different prefix, 'CANCEL'.
This prefix is to be used when an order / line is fully cancelled.
If it is cancelled for tomorrow because the customer wants it 6 days later, then its an UPDATE, so update the date
If you delete the order in your system, please sent that to Event as a CANCEL.
​
What if the order message fails?
Event has an import error function that picks up on failed schema and bad data for correction
What file name do I use?
The file name will be your agreed Account name and a date/time stamp.
The time to seconds.
Example:
'ACMEPACKAGING-NEW-11102020234712'
'ACMEPACKAGING-UPDATE-11102020234712'
'ACMEPACKAGING-COMPLETE-11102020234712'
'ACMEPACKAGING-CANCEL-11102020234712'
What am I creating?
You will use the specification to design your own integration based on the data you want to send.
Making sure you have included all the required data fields.
​
You are creating a service to generate and send an xml file from a trigger in your business for:
​
-
A NEW order is created
-
An order is UPDATED
-
An order is CANCELLED
-
An order is COMPLETED [Despatched]
How am I sending it?
It will be either ftp or sftp.
You can set this up or we can for you
​
It is triggered each time a new order is created, updated, despatched or cancelled.
or use our API...
You can use our API if you prefer.
You will need to subscribe and get an account, then you can follow the documentation to design and test.
What data can i receive back?
When all the routing and scheduling is complete you will want to know how the orders were combined to create routes.
We can provide data back to you at 2 different points in the process:
-
At the point a route is accepted by a carrier
-
This will provide data by route on what orders, when, the cost and delivered by who​​​
-
-
At the point a invoice is created
-
This will provide information on cost additions and final invoice costs​
-
​
The OASIS export schema
Transport file
31-01-2022
The OASIS export schema
Transport file example
22-01-2022
.TXT file
The OASIS .xsd
Transport file
31-05-2022
.TXT file
The OASIS
Transport file example, simple
08-02-2022
.TXT file
The OASIS
Transport file example multi HU and Stops
08-02-2022
.TXT file
The OASIS export schema
Invoice file
tbc
The OASIS export schema
Invoice file example
tbc
​
A Transport file is sent to you at the point the carrier accepts the route offer
What do you do now?
Lets get started.
Define your operational process to create your integration
Use the spreadsheet to get the required data
Decide if you need any of the optional data or have custom requirements.
Use the xml examples to help build your order message files.
When you are ready to test, we can provide an environment for you.
​
​
We can help check and validate your integration.
Send us your OASIS integration spreadsheet
Create the xml using the example and send to us for each prefix for an example order
Ask us any questions
Contact details for OASIS support
How does OASIS affects Event status?
Event is controlled by its many different status. These control the stage in the Event process where an order sits and therefore how it is affected by the different prefixes OASIS uses.
​
This will help you understand the impact a late UPDATE will have if a carrier is due to collect it in 20 mins
How does OASIS affects Event status?
or
Error handling
Format validation
Order packing metaheuristics
Order consolidation service
Carrier selection
Send once
Order routing
Address validation
Default or Custom update rules
Default or Custom update rules
Send multiple
Send once
Sent when carrier accepts route
NEW, MODIFY, CANCEL
Send multiple
Provides the despatched qty
Provides Despatch note information
Despatched order
Optional