E. Loading / Accept and Complete Load

Definitions and assumptions

Master data setup

Each Seller/Loader should define their loading locations
Each Seller links products with one or more loading locations where the product can be loaded

Using 3rd Party Loaders

The task for loading of the equipment can be fulfilled by the Seller (or Chemical plant) but can also be outsourced to a 3^rd party tank storage operator, a logistics service provider or even a 3^rd party tolling operator. For the sake of uniformity let’s call the 3^rd party companies a 3^rd party Loader.

Loading instruction to Loaders:

The approach depends on whether a 3^rd party Loader is used or not:

Scenario 1: The Seller is also the Loader
- In this case loadings are organized at the Seller – ChemCo sites, the loading requests are handled internally.
Scenario 2: The Seller uses a 3^rd Party Loader
- In case a 3^rd party Loader is involved, there is a contractual agreement in place and a loading request is sent from the Seller to that 3^rd party Loader
- Such request for loading or “load request instruction” to a 3rd party Loader is currently a simple email instruction, a delivery note indicating what needs to be loaded, a transport order instruction or even an extended ERP system screen from the Seller where loading requests can be consulted “on line”.

eECD pre-validation

As a rule of thumb, we should avoid waiting time for drivers during loading and we should consider this as a joint responsibility and benefit. Doing eECD validation checks just prior loading should be avoided and the truck driver/subcontractor should be able to pre-check the validity of his eECD prior arrival to the loading location and this based upon a search on “Equipment ID, Transport Order reference and loading location”. By doing so we avoid last minute eECD rejects and frustrations…. As from the moment the eECD is generated and linked to the next load, all licensed parties, transactionally linked to the transport and the loading reference (transport company, driver, shipper, loader) should receive validity warning where relevant, when opening the booklet of that equipment. The scope of these activities is described in the diagram on a blue background.

Below we describe two flows: one where Seller == Loader and one where a 3^rd Party Loader is involved

Loader == Seller

Action	Comment
[ 1 ] The driver announces himself at the gate Check IN of the Seller with the transport order reference. If the transport order reference is found valid according to the latest customer order info, the driver is allowed to enter the gate and drives to the indicated loading place/station as per site instructions.	Note: this step does not require the use of the eECD application. On the other hand, in case an eECD document existence check is done at the “Gate check in” together with an equipment ID check, the eECD application might already be used.
[ 2 ] Check planned load Once the driver arrives at the loading station, the Loading Operator logs into the eECD application and looks up the eECD booklet based upon the transport order reference and/or equipment ID.	At login, the loading operator is automatically linked to the right Seller and this on the basis of the user set up. That said, the loading station can have a regular login and can see a (short) worklist of plannd loads.
If the combination is not valid, there is a possibility we are dealing with a (last minute) equipment change. In that case, the EquipmentOperator despatcher will need to move the planned load from the original equipment booklet to the new equipment (see step H).	Recommendation from the transport companies is to always contact the dispatcher in case the order reference and equipment ID on the eECD do not match.
The user/loader operator now has the possibility to view, download or print the eECD.
[ 3 ] The Loading Operator checks the eECD to validate whether the equipment ID fits the cleaning requirements (per compartment) for this planned load. Cleaning validation warnings should appear here. The operator also checks forbidden preloads etc.
If the eECD (cleaning) is not acceptable, the truck is sent back and eECD can – depending on the reason – be used for another load. Button for rejection by the loader triggers status “*Load rejected*”, but this does not invalidate the eECD. Field with “reason for rejection” should be completed and an explanation is added by the loading operator. (message notification goes to the dispatcher who assigned the load)
If the eECD is accepted, the truck is prepared for loading. “accept” button by the loader. Booklet will be updated with status “*Load accepted*”.
[ 4 ] Truck is physically loaded (one compartment or full truck)
[ 5 ] Loader opens the booklet again and invalidates the eECD by clicking “Load Completed”.	Also at this stage the eECD can be rejected while a reason for rejection is required to be added by the loading operator.
[ 6 ] If, per exception, the invalidation by the loading operator is not done after complete loading and gate “check-out” - it should be done, at the latest, when the equipment is presented at the CleanCo for the next cleaning. In addition, a non-conformity is sent to the loader/seller as this is not acceptable from a data integrity point of view. In phase 2, narrow geofencing controls can be a solution.	The platform will automatically invalidate a previous eECD if a new cleaning action is completed. An autocomplete load XML message is being created through Elemica to automate this “complete load” step at the laoding place

Use of 3^rd party loader

Action	Comment
[ 1’ ] The driver announces himself at the gate Check IN of the 3^rd party Loader with the transport order reference. The Gate Check IN logs into the eECD application and looks up the eECD booklet based upon the transport order reference and/or equipment ID. Loading reference and transport order reference should be the same. This check can also be done at check-in. Corresponds with step 2 of previous scenario.	Note that this step *does* require the use of the eECD application in the case of a 3^rd party Loader
If the transport order/loading reference does not match the equipment ID as assigned by the dispatcher in Step D, the driver is not allowed to load and need to contact his dispatcher to assign his equipment ID to the right transport order reference.	Note: Recommendation from the transport companies is to always contact the dispatcher in case the order reference and equipment ID on the ECD do not match.
If the transport order/Loading reference is found valid and correctly linked to the right equipment ID physically present for load pick up, the driver is allowed to drive to the indicated loading place as per gate instructions.
The check IN has the possibility to download or print the eECD.
Move to [ 3 ] in previous scenario.

This flow is a variation of the ‘Seller == Loader’ flow, but mainly because the validation is done in two steps. We assume this is an approach that may also be interesting for larger Seller/Loaders who have a Viewer user role at a gate (basic validation) and a more thorough control at the actual loading point (LoadingOperator).