290936

DHL C-TMS

C-TMS Consolidation Process & Rules

FUNCTIONAL SPECIFICATION - 10.7

07/11/11 - 2.0
Reference: FS 290936 NW-8KEMAG

FUNCTIONAL OVERVIEW

Client Requirement

It is assumed that this RIO will be managed in conjunction with the Project Rigel System Requirements Document v1.0 or higher.

Create a new rule based consolidation process in C-TMS which will primarily be automated but will allow a manual override. This should include rules based on a Client Compatibility Matrix maintained at Customer Level and a Product Compatibility Matrix maintained at Product Level.

Shipment status and other specified rules should also be considered including the user maintenance of these.

Solution

A new consolidation process will be created to combine similar transport orders into shipments for scheduling onto trips (but consideration will be required about whether functionality will be controlled by the cost centre).

N.B. In relation to scheduling it is envisaged that Baxter would be excluded from standard automated scheduling with the exception of sameday (order is due for delivery on current day) orders which would be scheduled to a nominated parcel carrier. There should then be an option to run the scheduling engine and include any BAX unscheduled orders. This should also work the other way around and enable HUK orders to be scheduled on BAX vehicles if required.

The consolidation process will be run as an EDI batch job to process orders automatically at set times per day, or the process may be run manually via a button in a new ‘Shipment Consolidation/Enquiry’ screen.

Some of the conditions will be:

• Orders must be in a status of UNSCHEDULED to be able to be added to a Shipment. ( just the order being added to the shipment; it is presumed that the order being added to the shipment must be UNSCHEDULED.)
• Shipment must be in a status of OPEN for automatic consolidation or PENDING / OPEN for manual consolidation to be able to have Orders added to it.
• Consolidation will primarily take place at Client / Customer level.
• If multiple Clients / Customers can be consolidated together this should be configured against the Client / Customer in question. This needs to be validated against the existing Client / Customer list within C-TMS. Flag to allow consolidation with other customers and then list of specific customers allowed.
• Unique ‘From’ Location on Orders must be the same.
• Unique ‘To’ Location on Orders must be the same.
• Delivery Date must be the same.
• Delivery time windows must at least overlap and then delivery should take place within the most constrained, feasible window. Delivery window will need to be set on the shipment record.
• A consolidation matrix is required for product types / temperature types.
• Orders must have the same Carrier if the Carrier is specified.
• Once Orders have been consolidated into a Shipment, when this is collected by the Carrier it should be on a single vehicle.
• Orders should be of the same DHL Service Level in order to be consolidated.

The ‘from’ and ‘to’ locations must be the same delivery point down to Ward / Department level as will be defined by the location ID.

There will be additional rules in place during consolidation to control the maximum size of a Shipment so that it cannot exceed the maximum capacity of a vehicle.

A “Manually Modified” flag will be added to the orders on the trip so that the new scheduling engine within C-TMS will not try automatically to reschedule any orders or shipments that have been amended manually. This flag will be set as soon as a user carries out a transaction such as unscheduling an order from a shipment so as to prevent the scheduling engine from trying to automatically reschedule the order. A user will have the ability to uncheck this flag if required in the ‘shipment’ screen accessed via the trip planning screens.

To be able to edit the details of a shipment it must be removed from a trip and be in a status of ‘OPEN’ or ‘PENDING’.

The status of the shipment may be one of the following:

• OPEN – Available for scheduling and manipulation
• PENDING – Status manually set by user to prevent the shipment from being automatically closed
• CLOSED – No more orders may be added to the shipment because its limit has been reached (e.g. capacity constraints)
• PACKED – Label Printed
• DESPATCHED – Trip is En-Route

A new database table called ‘SCH_SHIPMENT_STATUS’ will be required to store the description of the shipment status and a new column will be added to the existing database table ‘SCH_SHIPMENT’ to store the status set.

Shipment modification should be access controlled by two separate functions. This will enable any regression of status, if a user has the relevant access. Note that a shipment will not normally be regressed from Despatched as the re-book process will be used however the capability should be available.

To be able to edit the details of an order it must be removed from a shipment and be in a status of ‘UNSCHEDULED’.

If a shipment is modified after it has been picked and the labels produced there will be a requirement to be able to request new labels. In order to carry out this modification in the first place the shipment status must be regressed accordingly based on the rules stated above. . N.B. Once the transport orders have been consolidated into shipments the scheduling engine will be run automatically. (See RIO NW-8KENH2 for further details.)

The ‘EDI Maintenance’ screen will be changed to allow the entry of processes from which the consolidation process may be maintained and started as required. This screen will enable polling for other processes to be possible when they are developed. To allow a process to be run for a specific interval window the following changes will be required:

• A new ‘Direction’ of ‘Internal’ will be available
• A new ‘Frequency Type‘ of ‘Interval Window’ will be available
• A new ‘Flow Type’ of ‘PROCESS’ will be available
• A new field called ‘Interval Start Time’ will be displayed
• A new field called ‘Interval Stop Time’ will be displayed
• New ‘Process Values’ will be entered via the ‘Params’ button for the ‘PROCESS’
• A new database job will be created when the ‘Start’ button is pressed
• A new Package called DP_PROCESS will be created to control the processing of the processes.

Where orders are being keyed into C-TMS it is assumed that an interface mechanism is not in place and therefore Pack Confirmation must take place manually. A “Pack Confirm” button will be added to the manual order entry form, once pressed the order will be scheduled onto a shipment, and its trip, and a carrier label produced to the printer assigned to the user. The Pack Confirmation function should check to see if the order has been scheduled automatically (unlikely as it will just have been keyed in), if this is the case a label should be printed, if the order has not been scheduled then the scheduling engine should be triggered, the order scheduled and a label produced. There should also be the option to specify a carrier prior to Pack Confirmation.

Scope

This change will be applied to system version 10.7

SET-UP

Data

System parameter ORD_ALLOW_SHIPMENTS will be added. This can be configured at cost centre level.

A new Customer of CONSOL will be created as dummy value for consolidated orders that have different customers.

A new flow type PROCESS will be added to EDI_FLOW_TYPES. The COMMAND_SQL will call DP_PROCESS.RUN_PROCESS which is a new procedure. See 3.5

A new order status of CONSOLIDATED will be added to SCH_ORD_STATUS

New system parameters will be added to ADM_SYSTEM_PARAM

• CON_SAME_SERVICE_LEVEL – Is same service level required for consolidation
• CON_SAME_DEL_DATE – Is same delivery date required for consolidation
• CON_OVERLAP_TIME_WINDOW – are overlapping time windows required for consolidation.
• CON_SAME_TO_LOC – Is same delivery location required for consolidation
• CON_SAME_FROM_LOC – is same collection location required for consolidation.
• CON_MAX_VOLUME – maximum volume of a shipment
• CON_MAX_WEIGHT – maximum weight of a shipment
• CON_MAX_RPE – maximum RPE of a shipment

FUNCTIONAL DESCRIPTION

A new automated process will be created that will combine similar orders into a shipment or shipments. These shipments will then be available for scheduling onto trips.

The consolidation process will be run at set times and in addition a manual run will be available from the new Shipment Enquiry screen.

Consolidation will be controlled by a system parameter, which can also be configured by cost centre, there will also be additional rules at client / customer and carrier level. Initially consolidation will only be applied to own fleet but it must be an available option for Prospero. A new system parameter ORD_ALLOW_SHIPMENTS will be added to the ADM_SYSTEM_PARAM table. This can be set for the whole system, or configured for a cost centre.

Consolidtaion Rules

To allow the consolidation of orders certain rules will be used to determine whether consolidation is possible and whether an order can be included in a shipment.

The rules are:-

• Orders must be in a status of UNSCHEDULED to be able to be added to a Shipment.
• Shipment must be in a status of OPEN or PENDING to be able to have Orders added to it. The shipment status will move to CLOSED when set manually, once the maximum capacity has been reached or when a new batch job runs on a predetermined frequency automatically closing outstanding shipments.
• Consolidation will primarily take place at Client / Customer level.
• If multiple Clients / Customers can be consolidated together this should be configured against the Client / Customer in question. This needs to be validated against the existing Client / Customer list within C-TMS (see 3.7 for details).
• Unique ‘From’ Location on Orders must be the same.
• Unique ‘To’ Location on Orders must be the same.
• Delivery Date must be the same.
• Delivery time windows must at least overlap and then delivery should take place within the most constrained, feasible window.
• A consolidation matrix is required for product types (see 3.8 for details)
• Orders must have the same Carrier if the Carrier is specified. The carrier held against SCH_ORD_REFERENCE will be checked against the other orders in the shipment. If no carrier is specified the order can be included with orders that do contain a carrier.
• Once Orders have been consolidated into a Shipment, when this is collected by the Carrier it should be on a single vehicle.
• Orders should be of the same Service Level in order to be consolidated.

When considering an order for consolidation the Max RPE of the trailers or the Max DU size configured against the Carrier (see 3.9) will be used to determine whether the order can be included on the shipment. The RPE of the existing orders on the shipment and the order being consolidated must be below the Max RPE for the trailers.

Several system parameters will be setup to allow some of the consolidation rules to be switched on or off. The following parameters will be added.

• CON_SAME_SERVICE_LEVEL – Is the same service level required for consolidation
• CON_SAME_DEL_DATE – Is the same delivery date required for consolidation
• CON_OVERLAP_TIME_WINDOW – are overlapping time windows required for consolidation.
• CON_SAME_TO_LOC – Is the same delivery location required for consolidation
• CON_SAME_FROM_LOC – Is the same collection location required for consolidation.
• CON_MAX_VOLUME – maximum volume of a shipment
• CON_MAX_WEIGHT – maximum weight of a shipment
• CON_MAX_RPE – maximum RPE of a shipment.

These parameters will be taken into account when deciding whether an order can be included in a shipment.

Any orders that are included in a shipment will be locked and no changes will be allowed. If an amendment is required to an order the order must be removed from the shipment before editing.

To create a shipment a new order will be created using the From Location, To Location and Delivery date of the orders being included in the shipment. The delivery time windows on the order will be set as the latest Early Del and earliest Late Del for all the orders in the shipment. The collection windows will be set as per the new time derivation RIO (291212 NW-8KNCK4). The early collection date will be the date the order is created and the late collection date will match the late delivery date.

The status of the orders that have been consolidated will be changed to CONSOLIDATED to indicate that they are part of a shipment. No changes will be allowed to the order while it is part of a shipment.

Each order line from the orders that have been consolidated will be included in the lines of the shipment. A new column will be added to SCH_ORDER_LINE to store the original order reference. This will allow the orders included in the shipment to be tracked.

Consolidation Process

Creating Shipments

The consolidation process can be run manually or automatically. The two processes will work in the same way. A new package DP_SHIPMENT will be created that will contain all the program units required to maintain and run the consolidation process. A function RUN_CONSOLIDATION will be called to start the consolidation process. All unscheduled orders will be considered for consolidation, unless a specific schedule is selected.

Two new parameters will be added to control how many days in the past and future will be considered for consolidation. If a specific delivery date is passed into the consolidation process these parameters will determine which orders are to be consolidate. When running the process automatically the current date will be used.

• Schedule range
• From Location
• To Location
• Customer
• Delivery Date (which drives the range controlled by the parameter above)

These parameters are not mandatory and can be left blank.

The function will return a Boolean value to indicate if the run was successful. The function will allow the input of the following parameters

The consolidation process will loop through all the available orders. For each order a check will be made to determine if a shipment exists that can accommodate this order. The consolidation rules will be taken into consideration when looking for available shipments. If a shipment is available the order will be added to the shipment. The process will look for any Open shipments regardless of whether the shipments are scheduled onto a trip.

If a shipment is not available for this order, the process will then look for other orders that could be combined into a shipment with this order. Again the consolidation rules must be considered, for each order. If one or more orders match the order being processed, they will be combined to create a shipment.

If a shipment is available for this order the order will be added to the shipment by creating an order line on the shipment order that contains the details of the order being consolidated.

Where an order can be scheduled onto multiple shipments the one with the earliest delivery date and time should be selected.

When considering shipments that are currently scheduled onto a trip, if the shipment is crossdocked the capacity of the trailers for all trips containing this shipment must be considered.

When one or more orders have been found that can be consolidated into a shipment a new “Shipment" order will be created. The order header will contain a new unique OMS Reference, and the From Location, To Location, Sched Name and Cost Centre of the orders being consolidated. These should all be the same for each of the orders being consolidated. If all orders have the same customer then this customer will be assigned to the new shipment order. If the customer is different the customer against the shipment order will show as CONSOL.

Each order line from the orders being consolidated will then be assigned to the shipment order. All of the order line information from the consolidated orders will be stored as a line in the shipment order.

When the shipment is closed, a process will run that combines lines of the same DU Type into one line. The new line will have the combined quantity, weight, volume and RPE of all the lines that have been combined.

The lines with a DU TYPE of ‘Carton’ have been combined to create a single line.

Add parameter to recalculate DU’s at Shipment level. This will look to create a DU consolidation at shipment level so three orders each for a small box could become one shipment of one large box dependent on the associated DU mapping and potentially packing rules. This is to be scoped as a framework for future enhancements and will not initially be required for Rigel or Prospero. N.B. Further discussions with DHL are taking place regarding this functionality.

The status of the consolidated orders will be changed to ‘CONSOLIDATED’, this will ensure they can easily be identified and are not included in the scheduling process.

A new column SHIPMENT_STATUS will be added to SCH_ORD to hold the shipment status. This status will be visible in the orders screen.

A new column SHIPMENT_REF will be added to SCH_ORD. When an order is added to a shipment the shipments OMS ref will be entered against the consolidation order. If during the consolidation process an order cannot be included with any other orders or shipments the SHIPMENT_REF will be set to its own OMS_REF.

The order delivery windows will be set as the latest Early Del and earliest Late Del that can overlap all of the orders on the shipment. Each time a new order is added to the shipment these dates will be revised based on the consolidated orders windows.

The order collection windows of the shipment order will be set as the date the shipment is created and Late Del date of the shipment.

If an order is available to be added to a shipment but the shipment is at maximum capacity the order will be left off the shipment. If more than one order is available to go into a full shipment, a second shipment will be created to accommodate these orders. This will continue until all orders have been consolidated.

When a shipment is first created or when an order is added to a shipment a record will be written to the SCH_SHIPMENT_AUDIT table to provide a record of changes to the shipment.

The SCH_SHIPMENT_AUDIT record will contain

• Audit ID – Generated sequence number.
• Shipment ID – Oms Reference of the shipment
• Action – Indication that a shipment has been created or an order added.
• Shipment Change – Change description or any errors or warnings related to the action. Will include the order oms reference if an order is added or deleted from the shipment.
• Created Time – Time of action.
• Created By – Username of the user performing the action
• Other changes to key fields on shipment order to be audited i.e. order 123456 added, latest delivery time changed from 14:00 to 13:00

A new trigger TRG_SCH_ORD_AUDIT_SHIPMENT will be created on the SCH_ORD table. When an order that contains a shipment status is added or removed a record will be written to the shipment audit table.

A new database job will be created that will run every hour. The job will call a new procedure in DP_SHIPMENT that will set any shipments at a status of OPEN to a status of CLOSED. Any shipments at status PENDING will not be closed by this job.

Removing Orders from a Shipment

When an order is removed from a shipment, the corresponding order line will be removed from the shipment order. If the Shipment Order’s lines have been combined by DU_TYPE, the values from the order being removed will be deducted from the shipment lines.

The Shipment_Reference on the consolidated order will be blanked out, breaking the link between the shipment and the order.

When an order is removed from the shipment a record will be written to the SCH_SHIPMENT_AUDIT table to provide a record of changes to the shipment. The new trigger TRG_SCH_ORD_AUDIT_SHIPMENT will add a record to the shipment audit.

The SCH_SHIPMENT_AUDIT record will contain

• Audit ID – Generated sequence number.
• Shipment ID – Oms Reference of the shipment
• Action – Indication that an order was deleted.
• Shipment Change – Change description or any errors or warnings related to the action. Will include the order oms reference if an order is added or deleted from the shipment.
• Created Time – Time of action.
• Created By – Username of the user performing the action.
• Other changes to key fields on shipment order to be audited i.e. order 123456 removed, latest delivery time changed from 13:00 to 14:00

Shipment Screen

A new screen will be written to maintain the shipment order details. The form will contain several tabs each containing the different data required to control the shipment creation.

Shipment Status Tab

A new table will be created to store the shipment statuses that are available. The following statuses will be added to the table with a description of their use.

• OPEN – Shipment Open

A shipment’s initial status will be Open, allowing orders to be added or removed.

• PENDING – Status manually set by user to prevent the shipment from being automatically closed
• CLOSED – Shipment Closed
• PACKED – Label Printed

Once all the labels have been printed for the shipment the status will change to Packed. Shipment must be in a status of OPEN to be able to have Orders added to it. The shipment status will move to CLOSED when set manually, once the maximum capacity has been reached or when a new batch job runs on a predetermined frequency automatically closing outstanding shipments (excluding manually modified shipments).

• DESPATCHED – Trip Departed

Finally when the trip containing the order moves to status En-route the shipment status will change to Despatched.

A tab will be available on the Shipment maintenance that will show the Shipment statuses. Users will not be able to edit these statuses.

Shipment Run Audit Tab

A tab will be added to the Shipment Screen that will show the details of each consolidation run. The tab will included the start and finish times, the number of shipments created and any warnings or errors created.

A new table will be created call SCH_SHIPMENT_RUN AUDIT to store the details of the consolidation runs.

When a consolidation run is started, either automatically or manually, the start date and time will be stored. When the run is finished the date and time will also be recorded. The audit should keep a count of the number of shipments created in the run.

The audit will also keep a record of any warnings or errors returned by the consolidation process. These will include any shipments that could not be completed due to size restrictions.

Shipment Enquiry Tab

Shipment Enquiry

A new Shipment Enquiry tab will be created within the Shipment screen in CTMS. This tab will allow users to view the shipments and the orders contained within the shipment.

The screen will contain a header section that will allow the shipments to be filtered. The following fields will be available to search on:-

• One of the Order References (OMS Ref, Cust Ref,)
• Shipment Ref
• Schedule
• Cost Centre
• From Location
• To Location
• Customer
• Delivery Date
• Carrier (Held against the order)

Using these variables the user can select the shipments to look at. The screen will show a record for each order on the shipments that match the parameters entered.

The following fields will be included in the screen.

• Shipment ID
• Shipment Status
• Carrier
• From Location
• To Location
• Delivery Date
• Customer (Will show NULL if multiple customers have been consolidated in the shipment).

When a shipment is selected, the orders included in that shipment will be displayed in a window next to the list of shipments. (see diagram).

The following fields will be included in the Order Detail window.

• OMS Ref
• External Ref
• Cost Centre
• Customer
• Early Avail
• Late Avail
• Early Del
• Late Del
• Line No
• Product Type
• DU Type
• Quantity
• Weight
• Volume
• RPE

If an order on the shipment contains more than one detail line, all lines will show in the Order Window.

Alongside each Order there will be a check box labelled remove. Users can select one or more orders that they wish to remove from the shipment. A button on the Order Window will allow the orders to be removed from the shipment. When the orders are removed from the shipment a new field against the order called ‘Manual Modified’ will be set to ‘Y’. This will prevent the order being reconsolidated onto the shipment when the process next runs.

When removing an order from the shipment, the order line holding the removed orders information (identified using the OMS_REF stored against the line) will be deleted from the shipment. The original order’s status will then be set to Unscheduled. This will allow the order to be edited and included on further shipments if required.

If the shipment is not at a status of Open or Pending then the ‘Remove’ check box and button will be disabled.

Warning message to be created and stored against the shipment audit to allow identification of previously labelled DU’s that have been unscheduled but no new label has been printed. A message will be shown to the user when an order is removed from the shipment indicating that the labels have been printed for this shipment.

If all orders are removed the shipment order will be deleted.

A right click option will be added to the shipment id, which will contain a Shipment Audit option. Choosing this option will show a popup window containing the audit information for the Shipment. The fields included will be

• Audit ID – Generated sequence number.
• Shipment ID – Oms Reference of the shipment
• Action – Indication that a shipment has been created or an order added.
• Shipment Change – Change description or any errors or warnings related to the action. Will include the order oms reference if an order is added or deleted from the shipment.
• Created Time – Time of action.
• Created By – Username of the user performing the action
• Other changes to key fields on shipment order to be audited as previously detailed

Manual Consolidation Run

A button will be included in the new Shipment Enquiry screen labelled Manual Consolidation. This will be used to execute the consolidation process manually.

When pressing this button the user will be offered the choice to run the consolidation process, the scheduling process or both. If the user chooses to run both the consolidation will run immediately followed by the scheduling engine.

The user will be able to select criteria for which they want the consolidation and/or shipment to run. A pop up window will contain the following options will:-

• Schedule range
• From Location
• To Location
• Customer
• Delivery Date (which drives the range controlled by the parameter above)

This will allow the user to consolidate only certain orders if required. If the options are left blank the consolidation process will run for all unscheduled orders that are not currently included in a shipment. The schedule will default to the current days schedule.

Pressing ‘OK’ in the pop up window will call the same procedure as the automatic consolidation process, passing in the parameters above (if entered). The same consolidation rules will apply as with the automatic consolidation process.

Merging Shipments

The screen will allow two or more shipments to be combined into one shipment. The user will be able to select the shipments they want to combine, and a button will be available to confirm the consolidation.

The consolidation rules that apply when consolidating orders will apply when consolidating the shipments.

• Shipment must be in a status of OPEN or PENDING to be consolidated.
• Consolidation will primarily take place at Client / Customer level.
• If multiple Clients / Customers can be consolidated together this should be configured against the Client / Customer in question. This needs to be validated against the existing Client / Customer list within C-TMS (see 3.7 for details).
• Unique ‘From’ Location on Orders must be the same.
• Unique ‘To’ Location on Orders must be the same.
• Delivery Date must be the same.
• Delivery time windows must at least overlap and then delivery should take place within the most constrained, feasible window.
• A consolidation matrix is required for product types / temperature types. (see 3.8 for details)
• Shipments must have the same Carrier if the Carrier is specified. The carrier held against SCH_ORD_REFERENCE will be checked against the other orders in the shipment. If no carrier is specified the order can be included with orders that do contain a carrier.
• Once shipments have been consolidated, when this is collected by the Carrier it should be on a single vehicle.
• Shipments should be of the same Service Level in order to be consolidated.

When consolidating shipments the maximum RPE of the trailers will be taken into account, however if the RPE of the shipment was greater than the maximum allowed a warning message would be displayed to the user and the consolidation would continue.

When consolidating shipments, the first shipment chosen will be used to incorporate the other shipment or shipments. As the from location, to location and dates are the same, the line details from one shipment can be transferred to the other. The shipments that are no longer required will be deleted, leaving the consolidated shipment. Changes such as date and time to be captured in audit log.

Automatic Conolidation Process

The ‘EDI Maintenance’ screen will be changed to allow the entry of processes from which the consolidation process may be maintained and started as required. This screen will enable polling for other processes to be possible when they are developed. To allow a process to be run for a specific interval window the following changes will be required:

• A new ‘Direction’ of ‘Internal’ will be available
• A new ‘Frequency Type‘ of ‘Interval Window’ will be available
• A new ‘Flow Type’ of ‘PROCESS’ will be available
• A new field called ‘Interval Start Time’ will be displayed
• A new field called ‘Interval Stop Time’ will be displayed
• New ‘Process Values’ will be entered via the ‘Params’ button for the ‘PROCESS’
• A new database job will be created when the ‘Start’ button is pressed
• A new Package called DP_PROCESS will be created to control the processing of the processes.

Each process set up in this screen will contain a parameter which indicates which package should be called to run the process; in this case it will be ‘DP_SHIPMENT’. This will be passed into DP_PROCESS and used to call the correct package and procedure when the database job runs. At the moment it is assumed that the automatic consolidation process will not pass in any parameters to DP_SHIPMENT and will run for all orders meaning no further parameters will be required.

This screen will allow the automatic consolidation process to be stopped and started as required.

Changes to Order Screen

To accommodate both orders and shipments being displayed in the Orders screen (ORDERS.fmx), some changes are required.

The Order Summary screen already shows the order status. Orders that are included in a shipment will have a status of CONSOLIDATED; this will make them identifiable in the screen.

The search option will be altered to include a check box which will control the visibility of orders in the screen. By default only shipments will be displayed, and to view orders the check box will be ticked. This will then include orders as well as shipments in the screen.

If a consolidated order is selected in the screen and the user attempts to edit the details a warning message indicating the consolidated orders can not be edited will be displayed to the user. The user will be able to view the order details but all fields will be protected against update. Validate existing access control functions to ensure no overlap or conflict.

A button will be provided in the screen that will allow the order to be removed from the shipment. When this button is pressed the order’s status will be changed back to Unscheduled. All of the order lines that were against a shipment will be removed from the shipment. The order can only be removed from the shipment if the shipment status is OPEN or PENDING. If the shipment status is at another status a warning message will be displayed and the action will be stopped (this will be managed as a manual exception covered within SOP’s within the operation).

A new field called Shipment Status will be added to the Order Details screen. This will show the status of the shipment. For consolidated orders the field will show the status of the shipment that the order has been included in.

When a shipment or consolidated order is being viewed, double clicking the Shipment Status will call the shipment enquiry screen. This will allow the user to easily see the shipment details and the other orders included in the shipment.

If a shipment is being viewed a double click option will be added to the lines on the shipment. Double clicking on the line will take the user to the order details for the line.

Changes to Customer Screen

A button will be added to the customers screen (CUST_COST.fmx) labelled consolidation. Pressing this button will show a pop up window which will allow the compatible consolidation customers to be entered.

The pop up window will consist of a customer id field, customer id for consolidation and a customer name. The customer ID field will include an LOV to allow a look up to take place.

When saved the records will be added to the new table ORG_CUSTOMER_CONSOLIDATION. A record will also be written as a reverse of the record being entered, this will indicate that the consolidation works both ways.

A check box will also be included labelled ‘ALL’, when this is checked the customer is considered to be compatible with all other customers when consolidating.

Changes to Product Screen

A change will be made to the products screen (PRODUCT.fmx). A new button will be added labelled Add Restrictions. This button will call a pop up window that will allow the list of products that are compatible with the current selected product type to be entered.

One or more restricted products can be added in this screen. If the product type can be consolidated with any other product types an ‘ALL’ check box will be available. This box will be ticked by default.

The pop up window will contain the Product Type, Temperature Type and Product Name. An LOV will be available to allow users to look up product types.

Changes to Resource Screen

A new field will be added to the carrier edit screen to allow the maximum DU size for a carrier to be entered.

This will be used when deciding whether an order can be added to a shipment, if a carrier has already been assigned.

Changes to Trip Screens

The scheduled order section of the Trip Sum and Trip Planning screens will also be changed to allow a user to drill down into the Shipment Enquiry screen rather than the orders screen when the order is a shipment order.

If the order on the trip is a shipment order double clicking on the order will bring up the Shipment Enquiry screen, showing the details of this shipment.

Shipment Status and Shipment Ref will be added to the list of configurable fields in the unscheduled orders section of the screen. This will allow them to be displayed as required.

This will also apply when viewing the order details from the Execution screen. If the order is a shipment order the Shipment Enquiry screen will be displayed when choosing the View Order Details option.

DU Mapping

Orders entered into C-TMS either manually, via .CSV import or from WISE will contain specific DU information. Orders from Unison will be treated slightly differently:

Unison will calculate the pallet equivalent of the order based on the volumetric data and pallet type held against the SKU. This value will be passed to C-TMS and rounded up to the nearest integer to give the pallet DU quantity for an order.

A separate RIO will be raised to apply additional logic and functionality within Unison to derive the associated box types and quantities for parcel orders which will also be passed to C-TMS.

An additional calculation will need to take place in C-TMS around mapping inner and outer DU’s, this should be managed via a table mapping inner DU’s to outer DU’s to work as part of consolidated shipment management. This will take place at Shipment Order level. This will prevent shipments scheduled to parcel carriers automatically becoming pallets due to the new max shipment DU size constraint. A recalculation function should be available to allow recalculation at shipment order level in the instance where a shipment order is manually moved from a carrier to own fleet.

DOCUMENT HISTORY

Version	Date	Status	Reason	Initials
0.1	14/09/11	Draft	Initial version	DNG
0.1	30/09/11	Draft	Review of the initial version	PJH
1.2	04/11/11	Amendment	Changes after review	DNG
2.0	07/11/11	Issue	Issued to client	PJH

AUTHORISED BY

Matt Crisford	Development Manager
Peter Greer	TMSCC MTS Product Manager