CTMS - User contributions [en-gb]

256287

2009-02-05T16:47:17Z

Kingj: New page: = 256287-NW-7KGE7N Fixed Routes to Run with Zip codes = Copyright OBS Logistics © 2007 The information contained herein is the property of OBS Logistics and is supplied without liabilit...

= 256287-NW-7KGE7N Fixed Routes to Run with Zip codes =

Copyright OBS Logistics © 2007

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
Fixed Routes currently utilises either locations or regions at stop level, the postal regions work based on the first sector of the UK post code, for example B or CV whereas the planning region can be defined against these i.e. MID for Midlands comprising both B and CV. There are now possibilities of deploying MTS in the likes of Portugal and Poland where ZIP Codes are defined differently and so within MTS there will be a requirement to define Fixed Routes by ZIP region and hence there may be different sectors of the ZIP code that need to be referenced dependent on the country. The same code or translation will also need to be applied when defining planning regions.

== Solution ==
The Fixed routes functionality should be able to handle any changes to the postal or planning regions. Providing the regions are set up correctly.
However, the postal and planning regions currently will not work for post (zip) codes that are numeric or that use digits other than the first two digits of the post code. The logic behind the postal and planning regions will be changed to allow the use of numeric postcodes.
Firstly the country code will be held against the postal \ planning region combinations on the table geo_plan_region.
A new table, and maintenance screen will be created that will store the details of a country’s postcode and define which parts of the post code are relevant when defining the postal region
The locations screen works out the postal region based on the post code entered. The new table will be used to determine which parts of the postcode should be used when working out the postal region. The postal region can then be used to determine the planning region based on the data in geo_plan_region.

== Scope ==
This change will be applied to system version 10.6.

= FUNCTIONAL DESCRIPTION =

To make the maintenance of postal and planning regions easier, the country code will be held against the postal \ planning region combination in Static Data Maintenance.

IMAGE

A new tab will be added to the Country Code screen to allow the maintenance of the postal regions. Each country can have a postcode format assigned and within this format the relevant characters can be chosen.

IMAGE

The maintenance table will contain the Country code, the post code type and the relevant character of the postcode.

If more than one character of the postcode is relevant multiple entries can be made.

So for GB we would store

GB CHAR 1
GB CHAR 2

For Poland

PL NUM 1

This would indicate that the first 2 characters are relevant for the UK, if they are Letters. While the first character is relevant for Poland.

Within the Locations screen the postal region is calculated based on the postcode entered. Currently it will only look at the first two characters of the postcode if the characters are letters (i.e. for UK postcodes).

This will be changed to be dynamic. The postal region will be populated based on the format held against the country code.

IMAGE

References
IMAGE

Glossary
IMAGE

Document History
IMAGE

Authorised By

IMAGE

HCRPRD Release - 16/01/2009

2009-02-05T16:43:38Z

Kingj: /* Programmes Released */

== Requested Developments ==

'''[[249378|256632 (PA-7KLFLE) Facility to update 1st Stop departure time''']]

'''[[257584|257584 (EI-7L8HBY)RIO-Booking Msg for Kraft BIC orders''']]

'''[[256287|256287 (NW-7KGE7N) Fixed Routes to run with ZIP codes''']]

'''[[247211|247211 (SS-7B6L2V)Control Order Creation Date''']]

'''[[256637|256637 (PA-7KPHJ8)EFX Pop-Up box''']]

'''[[256471|256471 (PA-7K2BG3)Create a drop down box at log-On''']]

'''[[249378|249378 (PA-7DDFH9)Data Export for EFX Interface''']]

'''[[246306|246306 (NW-7BCMAT)Booking EDI to incl Customer''']]

'''[[247174|247174 (NW-7CHEWZ)Add Weight and Spec Inst to Booking Import''']]

'''[[252344|252344 (PA-7DJLS6)Set Parameters for Trip Status change''']]

'''[[249771 |249771 (AS-765E9J)Fix to Owning Depot issue''']]

== Programmes Released ==

{| border="1"
!Program||Version
|-
|[[TRIPSUM.fmx]]||2.128
|-
|[[TRIP_PLAN]].fmx||1.35
|-
|[[TRIP_OVERVIEW]].fmx||1.11
|-
|INT_MSG.sql||1.48
|-
|GEO.sql||2.34
|-
|IMP.sql||2.68
|-
|[[STATIC_DATA_MAINT]].fmx||1.7
|-
|[[Geography]].fmx||2.11
|-
|[[Locations.fmx]]||2.53
|-
|AT_GEO_PLAN_REGION_256287.sql||1.1
|-
|CT_GEO_COUNTRY_POSTCODE_256287.sql||1.1
|-
|[[ORDERS]].fmx||2.104
|-
|[[ORDTEMPL]].fmx||2.39
|-
|DATA_ADM_FUNCTION_256637.sql||1.1
|-
|ADM.sql||2.14
|-
|[[ACC_CTRL]].fmx||2.31
|-
|[[ORI_STATS]].fmx||2.14
|-
|256474_CREATE_TABLE_ADM_USER_PROFILE.sql||1.1
|-
|256471_ALTER_TABLES||1.1
|-
|DATA_ADM_SYSTEM_PARAM_249378||1.1
|-
|[[INT_ERROR]].fmx||1.27.6
|-
|246306.sql||1.1
|-
|[[BOOKINGS]].fmx||2.19
|-
|[[LOCATION]].fmx||2.48
|-
|[[TRIPDTL]].fmx||2.56
|-
|TRM.sql||2.82
|-
|DATA_ADM_SYSTEM_PARAM_252344.sql||1.1
|-
|RTE.sql||2.3
|}

246306

2009-02-05T16:40:05Z

Kingj:

= 246306-NW-7BCMAT Booking EDI to inc Customer =

Copyright OBS Logistics © 2007

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
Associate the Customer with Booking records so that when Orders are created from Bookings the Customer is taken from the original record rather than from the ORD_DEFAULT_CUST system parameter. This change would need to be made to any interfaces, the Bookings Import and also the Manual Entry mechanism, for all of these it should be possible to enter the Customer but not mandatory with a blank value defaulting to the system parameter value.

To future proof this it would probably make sense to add the Cost Centre in the same way.

== Solution ==
These enhancements are required to improve the bookings transaction capture and to optionally allow the customer (and cost centre) to be defined at source. Currently this information is derived as TIs are generated.

Nick has requested that the changes are applied to the current booking function in use for Dixons (which itself formed the basis of the Proof of Concept database) and released to this POC system to support the next stage of MTS evaluation with Portugal.

Functional areas of change are;

• Booking EDI flow to include customer and cost centre extra columns, validation and interface errors tab – values to default if not provided from master data.
• Booking form to allow customer and cost centre insert, amend and display and associated searches and lookups to be modified to include these fields
• TI generation process to use customer and cost centre values from booking.
• Booking Import function to be extended to capture customer and cost centre from csv file.

== Scope ==
This change will be applied to system version 10.6.

= FUNCTIONAL DESCRIPTION =

== EDI Changes ==

=== New Booking Type Screen ===
A new tab called Booking Type tab will be added to the Static Data Maint form which is similar to the Order Type tab (see below).

IMAGE

As well as having the new Booking Type (currently ‘DXN_BOOKING’) it will also have a few extra fields. Decode Name is currently ‘DSG’ and is passed through to package IMP.DECODE_VALUE to determine any translations that need applying on provided location fields. Default Product Type is to override the system wide parameter ‘DSG_DEF_PRD_TYPE’ which is currently used. Default DU Type is to override the system wide parameter ‘DSG_DEF_DU_TYPE’ which is currently used. Default Cost Centre and default Customer (both optional) to override the currently used system wide defaults within create TI’s. Only to be used if not provided in the detail file.

An example of the configuration is shown below :-
IMAGE

Booking Type Decode Name Default Product Type Default DU Type Default Cost Centre Default Customer
DXN_BOOKING DSG ELECTRICAL CUBE EXEL DSGCUST
PGL_BOOKING POR CHILLED PALLET * *

* Are optional and can be left blank

=== Changes to INT_MSG Package (and related changes to BKG) ===
In the READ_BOOKING_DETAIL procedure :-

The Customer and Cost Centre will now be read from the detail section of the bookings EDI between <BOOKSTART> and <BOOKEND> as additional columns (9 and 10).

Currently in format :- From Location, To Location, Quantity, Delivery Date, Product Type, DU Type , Booking Reference and Trans Shipment Flag.

These new fields will be stored on INT_BOOKING_DETAIL in the new columns and if not provided then it will use the defaults from related INT_BKG_MSG_TYPE table. If neither have been set then it will use the system wide registry settings ‘BKG_DEF_COST’ and ‘BKG_DEF_CUST’ which must be setup.

These new fields will need to be passed through the BKG.APPLY_PROD_SUM, BKG.CREATE_PRODUCT_SUMMARY and BKG.CREATE_BOOKING procedures in order for the insert into SCH_BOOKING. These are already overloaded functions so we just need to overload them again for the extra 2 parameters.

Example of current DSG Booking :-

<RECHEADSTART>DSGLV,DXN_BOOKINGS,1<RECHEADEND>
<BOOKSTART>07099,02404,1.103,12-12-2099,RDCAA,,02404123456,N<BOOKEND>
<EOF>

=== Changes to INT_ERROR Form ===
We will need to check Cost Centre and Customer fields on the INT_BOOKING_DETAIL to ensure that the user doing the query has access to these interface errors.

The new fields Cost Centre and Customer will need to be displayed in the detail section of the screen for the DSG Bookings Tab (which will be renamed just Bookings) :-

IMAGE

Note – It is assumed unlikely that a booking EDI message will contain mixed cost centre and customer information, some that the user has access to and some not.

== Bookings Form ==

=== Booking Form Query ===

Additional selection criteria will be added to the top of the existing Bookings form for Customer and Cost Centre. If the user is only allowed access to a single Customer or Cost Centre then these fields will be automatically populated and they will not be allowed to change them.

This will allow the user to filter down the displayed Bookings by both Customer and also by Cost Centre.

IMAGE

The ‘View Summary’ button will be used to show the new fields from SCH_BOOKING.

The ‘View Summary’ canvas will be used to show the two new fields Cost Centre and Customer from SCH_BOOKING in two additional columns :-

IMAGE

=== Bookings Form New / Edit ===
Currently the ‘New’ button brings up the following canvas which will need the Cost Centre and Customer fields adding with appropriate validation.

IMAGE

Currently the Edit button brings up the following canvas and this will need the new fields Cost Centre and Customer adding with appropriate validation.

IMAGE

=== Generate TI’s ===

The ‘Create TI’s’ button on the Bookings form calls the procedure GEN_TI.CREATE_BOOKING_TI’s which will need changing to use the Customer and Cost Centre fields from the SCH_BOOKING table when creating new records on the SCH_ORD table rather than defaulting from system registry values as now.

== Changes to IMPORT Functionality ==
The standing data to support the new fields will need adding to allow the new fields Customer and Cost Centre to be selected for inclusion on a Bookings format (see Data section above for details).

The IMP.PROCESS_BOOKINGS procedure will need changing to extract these fields from the csv if defined on appropriate format and provided in the file.

The process will then use these fields (if not provided then default to system wide registry settings ‘BKG_DEF_COST’ and ‘BKG_DEF_CUST’) to pass through to the already changed procedure BKG.APPLY_PROD_SUM (see changes to BKG package in section above) for the creation of the booking.

A sample format for Bookings is :-

IMAGE

The new fields Cost Centre and Customer will now be able to be entered as a Field Types against formats which have an Imp Type of ‘Booking’.

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==
IMAGE

== Authorised By ==

IMAGE

246306

2009-02-05T16:37:10Z

Kingj: New page: = 246306-NW-7BCMAT Booking EDI to inc Customer = Copyright OBS Logistics © 2007 The information contained herein is the property of OBS Logistics and is supplied without liability for ...

247174

2009-02-05T16:08:40Z

Kingj: New page: = 247147-NW-7CHEWZ Booking EDI to inc Weight and Special Instructions = Copyright OBS Logistics © 2007 The information contained herein is the property of OBS Logistics and is supplied ...

= 247147-NW-7CHEWZ Booking EDI to inc Weight and Special Instructions =

Copyright OBS Logistics © 2007

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
Add weight and special instructions to Booking Import function and Bookings Code.

Weight is currently held against a booking but cannot be imported. Weight should be added to both the import function and interface format. If a booking is split across multiple orders then the weight should be apportioned according to DU split.
Special instructions should be added to the booking record and also the import and interface formats. The special instructions should be applied to all orders created from the booking record and subsequent orders treated in the same way – i.e. references highlighted to indicate special instructions exist

== Solution ==
Weight. The weight field is already available on the bookings form but when bookings / edi messages loaded, the weight field is set to zero. The import and EDI functions will be enhanced to accommodate weight (and suggest volume) values. Weight (and volume) will be set against the booking record. As TIs are generated, should multiple orders be created, the total weight will be distributed according to the split of DUs.

Special Instructions. The booking database table (product summary) will be extended to accommodate a varchar(4000) field to store the special instructions. The product summary form will be enhanced to allow special instructions to be keyed, amended and viewed. The form dimensions will remain unchanged and scroll bars will enable navigation through larger text entries. The import and EDI load functions will be changed to accommodate a special instruction field. As TIs are generated, any special instructions on the booking will be copied to the special instructions field on the orders.

Functional areas of change are;

• Booking EDI flow to include weight (and Volume?) and special instructions extra columns, validation and interface errors tab – values to default if not provided from master data.
• Booking form to allow weight (and Volume?) and special instructions insert, amend and display and associated searches and lookups to be modified to include these fields
• TI generation process to use weight (and Volume?) and special instructions values from booking.
• Booking Import function to be extended to capture weight (and Volume?) and special instructions from csv file.

Volume. Volume will be available to be loaded through EDI or through the CSV import as an optional field. If a value is passed into MTS, this value will be set in bookings and used in the TI generation (apportioned where necessary by DUs). MTS has an algorithm to derive a default volume automatically. This needs to be reviewed and remain an available function where volume is not specifically set in the bookings interfaces.

== Scope ==
This change will be applied to system version 10.6.

= FUNCTIONAL DESCRIPTION =

== EDI ChangesChanges to INT_MSG Package (and related changes to BKG) ==
In the READ_BOOKING_DETAIL procedure :-

The Weight (and Volume?) and Special Instructions will now be read from the detail section of the bookings EDI between <BOOKSTART> and <BOOKEND> as additional columns (11 and 12).

Currently in format :- From Location, To Location, Quantity, Delivery Date, Product Type, DU Type , Booking Reference, Trans Shipment Flag, Customer and Cost Centre

These new fields will be stored on INT_BOOKING_DETAIL in the new columns.

These new fields will need to be passed through the BKG.APPLY_PROD_SUM, BKG.CREATE_PRODUCT_SUMMARY and BKG.CREATE_BOOKING procedures in order for the insert into SCH_BOOKING. These are already overloaded functions so we just need to overload them again for the extra 2 parameters.

Example of current DSG Booking :-

<RECHEADSTART>DSGLV,DXN_BOOKINGS,1<RECHEADEND>
<BOOKSTART>07099,02404,1.103,12-12-2099,RDCAA,,02404123456,N<BOOKEND>
<EOF>

=== Changes to INT_ERROR Form ===
We will need to check weight (and Volume?) and special instructions fields on the INT_BOOKING_DETAIL to ensure that the user doing the query has access to these interface errors.

The new fields Weight (and Volume?) and special instructions will need to be displayed in the detail section of the screen for the DSG Bookings Tab:-

IMAGE

== Bookings Form ==

=== Bookings Form New / Edit ===
Currently the ‘New’ button brings up the following canvas which will need the Special Instructions field to be added. The weight (and Volume?) field already exists.

IMAGE

Currently the Edit button brings up the following canvas and this will need the new field special Instructions adding with appropriate validation.

IMAGE

=== Generate TI’s ===

The ‘Create TI’s’ button on the Bookings form calls the procedure GEN_TI.CREATE_BOOKING_TI’s which will need changing to use the Weight (and Volume?) and special instructions fields from the SCH_BOOKING table when creating new records on the SCH_ORD table.

In the situation where multiple TIs (orders) are generated from a booking, the weight (and volume?) will be apportioned in line with the DU apportionment (which is current functionality). Any special instructions from bookings will be carried forward to associated orders when generating TIs.

Where the generate TIs function currently generates multiple orders to satisfy X-dock routes, each of the orders will be created with weight (and volume?) and special instructions.

Changes to IMPORT Functionality
The standing data to support the new fields will need adding to allow the new fields Weight (and Volume?) and special instructions to be selected for inclusion on a Bookings format (see Data section above for details).

The IMP.PROCESS_BOOKINGS procedure will need changing to extract these fields from the csv if defined on appropriate format and provided in the file.

The process will then use these fields to pass through to the already changed procedure BKG.APPLY_PROD_SUM (see changes to BKG package in section above) for the creation of the booking.

A sample format for Bookings is :-

IMAGE

The new fields Weight (and Volume?) and Special instructions will now be able to be entered as a Field Types against formats which have an Imp Type of ‘Booking’.

References
IMAGE

Glossary
IMAGE

Document History
IMAGE

Authorised By
IMAGE

249771

2009-02-05T16:01:03Z

Kingj: New page: = 249771-AS-765E9J Fix to Owning Depot Issue = Copyright OBS Logistics © 2007 The information contained herein is the property of OBS Logistics and is supplied without liability for er...

= 249771-AS-765E9J Fix to Owning Depot Issue =

Copyright OBS Logistics © 2007

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
Amend the code referenced in the Trip Manipulation, Trip Planning and Trip Summary forms so that the Owning Depot is applied to a trip based on the following:

1. When a Carrier is applied to a Trip the Owning Depot should be the Hub Location assigned to that Carrier (in resource maintenance), this is regardless of whether Start and End at Hub is enforced.
2. If a Trip is created and saved with a Carrier that does not have a Hub Location (i.e. Haulier) the Owning Depot should default to the first RDC stop on the Trip, regardless of whether this is PK or DL.
3. If there are no stops on the Trip associated with an RDC location the user should not be able to save the Trip without manually assigning an Owning Depot, this should be reflected in a message which I believe is currently in place: "Changes cannot be saved as Owning Depot is NULL".

As part of this development the functionality currently used to prompt a user to enter a carrier when creating a Trip should be added to the Apply via x-dock locations function. In addition to this the code should be amended to prevent a Trip being saved without a Carrier having been applied (Fixed Routes will need to be checked as part of this to ensure it will follow the correct rule).

== Solution ==
The existing code, in Trip Manipulation, Trip Planning and Trip Summary forms, will be changed so that the owning deport is applied to the trip based on the rules below.
1. When a Carrier is applied to a Trip the Owning Depot will be defaulted to the Hub Location assigned to that Carrier (from table RES_CARRIER column HUB_LOCATION), this is regardless of whether start and End at Hub is enforced.
2. If a Trip is created and saved with a Carrier that does not have a Hub Location (i.e. Haulier) the Owning Depot will default to the first RDC stop on the Trip, regardless of whether this is PK or DL.
3. If there are no stops on the Trip associated with an RDC location then the message "Changes cannot be saved as Owning Depot is NULL" will be displayed and the user will not be able to save the Trip without manually assigning an Owning Depot.

A new field will be added to the Apply x-dock pop-up window to accommodate the carrier. The User will be forced to enter a carrier before the trip can be saved.

== Scope ==
This change will be applied to system version 10.6.

= FUNCTIONAL DESCRIPTION =

== Owning Depot. ==
The owning depot will be taken from one of three places. The first place that will be used is the Hub location that has been assigned to the carrier. This is stored on the REC_CARRIER table, column HUB_LOCATION. This value will be used regardless of whether the start and end hub has been enforced.

IMAGE

If the Carrier on the trip does not have a hub assigned, the owning depot will be set to the first RDC stop on the TRIP.

Finally if the carrier does not have a hub assigned and there is no Stops associated with an RDC, a message will be displayed prompting the user to assign a depot manually. The user will not be able to save the trip until an owning depot is assigned.

An owning depot field will be added to the Trip Summary screen to allow the users to manually enter the owning depot if required. The Trip Manipulation and planning screens already have an owning depot field.

When creating a X-dock trip the user will be able to add a carrier to the trip(s). A new field will be added to the X-dock pop up screen to allow the carrier to be entered. If a carrier is entered the owning depot will default as detailed above. If no carrier is entered the owning depot will default to the first RDC stop on the trip. If the owning depot is still NULL no changes will be allowed to the trip until the owning depot is manually entered by the user.

IMAGE

As part of this change the fixed routes screen will be changed to follow the same rules mentioned, above.

IMAGE

== References ==
IMAGE

== Glossary ==

IMAGE

== Document History ==
IMAGE

== Authorised By ==

IMAGE

256471

2009-02-05T15:47:13Z

Kingj: New page: = 256471 PA-7K2BG3 Create a drop down box at log-On = Copyright OBS Logistics © 2008 The information contained herein is the property of OBS Logistics and is supplied without liability...

= 256471 PA-7K2BG3 Create a drop down box at log-On =

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
Create a Drop-Down Box at Log-on to allow the user to choose the profile required, if the user has visibility of more than 1 sched-group. Allow selection of ALL, as current, or individual choice from list. Allow the ability to switch profiles in an open session.

Added by SS 21/10/08 : This should not be restricted to just schedule group but should take into account all access settings per user.

== Solution ==
Each user will have the option to create several profiles that will be associated with their username. Within each profile the user will choose the system parameters that are unique to that profile.
A new tab will be added to the edit user screen that will allow the profiles to be edited. The Profile required can be chosen from a drop down list and then the parameters edited as needed.
Also a button will be added to allow the creation of new profiles. One of the profiles will be chosen as the default profile for the user, and this will be used when first logging into the system.
A new field will be added to the MTS front screen, ORI_STATS. This field will allow the user to choose which profile they wish to use during the session. The field can also be changed within the session.
The user parameters are used in various screens throughout the system. When they are referenced, the user’s active profile will be used to determine which parameters are to be used. This will all be controlled from within the package ADM to minimise the amount of program changes required.

== Scope ==
This change will be applied to system version 10.6.

= FUNCTIONAL DESCRIPTION =

Each user will have the ability to add several profiles, with each profile containing its own set of system parameters.

To facilitate this, a new tab will be added to the Edit User screen. Within this tab the user will be able to choose a profile from the list, and add \ edit the parameters for this profile. A button will also be included that will allow the user to add new profiles. Once these profiles have been created they will be available in the list for selection by the user.

One of the user profiles will be chosen as the default profile, and this profile will be used when the user first logs into the system.

IMAGE

The new tab will be placed here.

The new tab will be similar in layout to the existing User parameters tab.

IMAGE

The existing user parameter tab will be kept so that users who do not have a profile set up can use the parameters as required.

The Ori_stats screen will be altered to allow the users to choose which profile they are using during the session. When the profile is selected it will be flagged as active and will then be used in the current session to determine which user parameters are to be used. The default profile will be active when the user first logs on to the system.

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==

IMAGE

256637

2009-02-05T15:40:54Z

Kingj: New page: = 256637 PA-7KPHJ8 EFX Pop-Up box = Copyright OBS Logistics © 2008 The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omi...

= 256637 PA-7KPHJ8 EFX Pop-Up box =

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
MTS planning - EFX Pop-Up box - Hide or grey-out 'Trip Cost Man' as a fixed selection, and Hide or grey-out 'Forecast' as a fixed selection

1: When allocating a Trip to EFX the Pop-up box offers several options for Cost - hardcode the cost option as 'Trip Cost Man' and hide or grey-out the selection also hardcode 'Forecast' as the status type again hide or grey-out the selection. This leaves 3 boxes for input - Deadline Date, Deadline Time and Rate

2: re-adjust the 'Tabbing' sequence to navigate from 'deadline Date' to 'deadline time' to 'rate'

Added by SS 24.10.08 - It may be beneficial to have these controlled by parameters within MTS.

Quicker input of data when the various options are not relevant in this situation

== Solution ==
Current functionality in TRIP_SUM and TRIP_PLAN, for EFX Payment Details, are as follows:

• The EFX Pop Up Box, named ‘Payment Details’ in the Trip Screens is only displayed when the checkbox next to ‘EFX Ref.’ is selected and the current Trip has a Carrier of ‘EFX’
• This ‘Payment Details’ box is pre-populated with Event Ref (Sched_Name || ‘-‘ || Trip_Id), Debit Account (Cost Centre) and Credit Account (Carrier_Id), which are greyed out and not editable.
• The user is able to enter a Payment Type and Status, selectable from the drop-down lists
• The user is able to input an Expiry Date, Time and Amount
• When saved table ACC_PAYMENT is updated with the info in the ‘Payment Details’ box

The Payment Type drop-down list currently contains the following:
AM Deliv AL, Demurrage, Extra Drops, FUELSurch, Fuel Surch, Fuel Surchrg, Premium, Returns, Timed AL, Trip Haul Al, Trip Haul Ma, Trip Haulage

The Payment Status drop-down list currently contains the following:
Forecast, Actual, Provisional

Part 1 – EFX Pop-Up Box Input Fields
The EFX Pop Up Box will be amended so that when it is displayed, the following items are greyed out and not editable:
Event Ref which relates to ‘Sched_Name || ‘-‘ || Trip_Id e.g. ‘081027-MAN-00234567’
Debit Account which relates to the Cost Centre of the Trip
Credit Account which relates to the Carrier_Id assigned to the Trip
Type will be hard coded as ‘Trip Haul Ma’
Status will be hard coded as ‘Forecast’

Therefore, the only fields that will be editable are:
Amount, Expiry Date, Expiry Time

The only situation, where the Type and Status are not hard-coded and greyed out will be governed by a User Group having the function ACC_DIFF_EFX_PAYMENT promoted to their Group. If a user is in a particular group with this function promoted, then they will have the ability to select the Type and Status from the drop-down lists.

This therefore requires a new function to be included in table ADM_FUNCTION, with FN_NAME of ‘ACC_DIFF_EFX_PAYMENT’ and DESCRIPTION of ‘Ability to amend Payment Type and Status for a Trip with a Carrier Id of EFX, in the TRIP screens’.

This function will then be available in the ‘Functions’ tab of the Group Maintenance screen for promoting.

Part 2 – Tabbing Issue
When the EFX Pop Up Box is displayed, the tab sequence between fields will be as follows;

When Type and Status Hard-coded:
Expiry Date – Expiry Time – Amount – OK – Cancel (Back to Expiry Date at Beginning)
When Type and Status Editable:
Type – Status – Expiry Date – Expiry Time – Amount – OK – Cancel (Back to Expiry Date at Beginning)

== 1.3 Scope ==
This change will be applied to system version 10.6 on CONTST and once approved CONPRD.

= FUNCTIONAL DESCRIPTION =

== Sample Layout ==
Below is a screenshot of how the ‘Functions’ tab within the Group Maintenance form will display when the new function has been created, and is ready to be promoted:

IMAGE

Below is an example of how the EFX pop-up will be displayed without the promotion of the new function:

IMAGE

Below is how the EFX Pop-Up Box will be displayed when the user has the new function ACC_DIFF_EFX_Payment promoted to their user group:

IMAGE

The tabbing sequence between fields within the EFX Pop-Up Box will be as follows:

When Type and Status Hard-coded:
Expiry Date – Expiry Time – Amount – OK – Cancel (Back to Expiry Date at Beginning)

When Type and Status Editable:
Type – Status – Expiry Date – Expiry Time – Amount – OK – Cancel (Back to Expiry Date at Beginning)

This is achieved by setting the ‘Next Navigation Item’ property within the Property Palette for each field in the Pop-Up. Below you can see that the Next Navigable item from the ‘Expiry Date’ will be ‘Expiry Time’:

IMAGE

== Code Amendments ==
Below is a preliminary outline of the code required to set up the EFX Pop-Up box either with the Payment Type and Status hard-coded or else selectable from drop-down lists depending on the new function.

BEGIN

IF :TRIP_DTL.EFX_SEND_FLAG = 'Y' THEN

IF :trip_dtl.carrier_id = 'EFX' THEN --Only proceed if carrier is EFX
F_POP_PAYMENT_TYPES;
Go_Block( 'PAYMENT_DETAIL' );
:PAYMENT_DETAIL.EVENT_REF := :TRIP_DTL.SCHED_NAME || '-' || :TRIP_DTL.TRIP_ID;
:PAYMENT_DETAIL.Debit_Acc := :TRIP_DTL.COST_CENTRE;
:PAYMENT_DETAIL.Credit_Acc := :TRIP_DTL.CARRIER_ID;
:PAYMENT_DETAIL.entered_date := SYSDATE;
:PAYMENT_DETAIL.revenue_date := TRUNC( SYSDATE );
:PAYMENT_DETAIL.narrative_1 := :PAYMENT_DETAIL.event_ref;

SELECT COUNT(*) INTO counter
FROM acc_payment ap
WHERE ap.event_ref = :TRIP_DTL.SCHED_NAME || '-' || :TRIP_DTL.TRIP_ID
AND UPPER(PAYMENT_TYPE) = 'TRIP HAUL MA’
AND ap.parent_payment IS NOT NULL;

IF NOT ADM.FN_ACCESS ('ACC_Diff_EFX_Payment', NULL, NULL) THEN

IF counter <> 0 THEN
SELECT payment_type, amount, status
INTO :PAYMENT_DETAIL.payment_type, :PAYMENT_DETAIL.amount, :PAYMENT_DETAIL.status
FROM acc_payment ap
WHERE ap.event_ref = :TRIP_DTL.SCHED_NAME || '-' || :TRIP_DTL.TRIP_ID
AND UPPER(PAYMENT_TYPE) = 'TRIP HAUL MA'
AND ap.parent_payment IS NOT NULL;
ELSE
:PAYMENT_DETAIL.payment_type := 'Trip Haul Ma';
:PAYMENT_DETAIL.amount := NULL;
:PAYMENT_DETAIL.status := 'Forecast';
END IF;

SET_ITEM_PROPERTY ('PAYMENT_DETAIL.PAYMENT_TYPE', ENABLED, PROPERTY_FALSE);
SET_ITEM_PROPERTY ('PAYMENT_DETAIL.PAYMENT_TYPE', NAVIGABLE,
PROPERTY_FALSE);
SET_ITEM_PROPERTY ('PAYMENT_DETAIL.STATUS', ENABLED, PROPERTY_FALSE);
SET_ITEM_PROPERTY ('PAYMENT_DETAIL.STATUS', NAVIGABLE, PROPERTY_FALSE);

ELSE
IF counter <> 0 THEN
SELECT payment_type, amount, status
INTO :PAYMENT_DETAIL.payment_type, :PAYMENT_DETAIL.amount, :PAYMENT_DETAIL.status
FROM acc_payment ap
WHERE ap.event_ref = :TRIP_DTL.SCHED_NAME || '-' || :TRIP_DTL.TRIP_ID
AND UPPER(PAYMENT_TYPE) = 'TRIP HAUL MA'
AND ap.parent_payment IS NOT NULL;
ELSE
:PAYMENT_DETAIL.payment_type := NULL;
:PAYMENT_DETAIL.amount := NULL;
:PAYMENT_DETAIL.status := NULL;
END IF;
END IF;

UPDATE sch_trip
SET EFX_SEND_FLAG = 'Y'
WHERE sched_name = :TRIP_DTL.sched_name
AND trip_id = :TRIP_DTL.trip_id;

FC_Commit.Do_Enable;
ELSE

:trip_dtl.efx_send_flag := 'N';
Set_Alert_Property( 'ERR_MSG', ALERT_MESSAGE_TEXT, 'To use this option Carrier must be EFX ');
v_Retnum := Show_Alert( 'ERR_MSG' );
RETURN;
END IF;
END IF;

END;

The following sql script will need to be run against the test and live databases to insert the new function into table ADM_FUNCTION this is to allow the promotion to user groups if desired in the future:

INSERT INTO ADM_FUNCTION (fn_name, description, active)
VALUES (‘ACC_Diff_EFX_Payment’,‘Ability to amend Payment Type and Status for a Trip with a Carrier Id of EFX, in the TRIP screens’,’Y’);

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==

IMAGE

247211

2009-02-05T15:33:44Z

Kingj:

= 247211-SS-7B6L2V Control Order Date Creation =

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
A new system parameter should be introduced called ORD_FUTURE_LIMIT_DAYS which will control the number of days in the future from the current date for which an order can be created. This should be configurable by customer at database level. If this is set to 20 and a user tries to create an order for 25 days in the future an error message should be displayed telling the user that this cannot be done as the max value for creating orders in the future has been exceeded, possibly telling them what the value is.

There is an existing parameter called LBO_FUTURE_ORDER_LIMIT_DAYS which may possibly provide some code that can be re-used or copied. Dave can this limit be set to 365 days from the date of creation / receipt of orders

== Solution ==
Create a new record in the ADM_USER_PARAM table called for a parameter called ORD_FUTURE_LIMIT_DAYS. This parameter must be modifiable by the user in the Administration → System → Parameters screen. The value of this parameter will be 365.

In the orders form , when adding a new order record and the schedule date is populated, a function will run which adds the ORD_FUTURE_LIMIT_DAYS parameter value to todays date and compares the value with the schedule date. If the schedule date is greater, then an error is displayed which will tell the user the maximum schedule date allowed – todays date + the value of the ORD_FUTURE_LIMIT_DAYS

This check must be applied to all areas where orders are created:

1. Bookings
When the user selects Create TI’s, a pop up screen is displayed where the user is able to enter a schedule , at this point, the schedule check will be run.

2. Manual Keying
The orders screen as described above, when a new order is created the schedule check will be launched to confirm that the order is created within the limits of the parameter.

3. CSV Imports
The IMP package runs a function called Process_TI_Order where the order records to be imported are processed. Within this function we would include a cursor which will loop through each order record and perform the schedule check. If there is an error with the schedule date this will be handled by the package in the same way that existing errors are handled.

The IMP package also calls a function Process Bookings where booking records are processed before being imported into the system. A cursor will be created to check the schedule name on each booking record. As above, errors will be handled in the same way that existing errors are handled in the package.

4. Change Schedule Date
This is current development where users will be able to change the schedule date of a planned trip. This check will be added to the functionality.

5. Templates
In the templates screen, when the user selects to generate orders from a template, a pop screen appears where the user must enter the schedule and then select generate again. At this point , before the order is generated , the schedule check will be run.

== Scope ==
This change will be applied to system version 10.5.0 on CONTST and once approved CONPRD.

= FUNCTIONAL DESCRIPTION =
This development is based on three requirements.

• A new system parameter is available for limiting the creation of orders in the future
• This parameter can be amended by the customer
• The parameter will be used to validate the schedule name of all new orders. This includes orders added manually via the order screen, orders imported via CSV files, orders created via bookings and orders created from templates.

== Adding the New Record ==

Insert into ADM_SYSTEM_PARAM (PARAM_NAME, VALUE, DATA_TYPE, MAX_LENGTH, DISPLAY, USER_MODIFIABLE, DESCRIPTION)
Values (‘ORD_FUTURE_LIMIT_DAYS’ , ‘365’,’N’,5,’Y’,’Y’,’Maximum Number of days in the future that an order can be created’)

== Validating the Schedule Date ==

=== Form Validation ===

For instances when the schedule date is added via a form, by user input, when-validate triggers will be used to capture the schedule date and convert the information to s date format.

The check will then be run, which will add the parameter value(ORD_FUTURE_LIMIT_DAYS) to the system date and then compare this new date with the schedule date. When a number is added to a date, the system defaults the value to be in days.

If the schedule date is greater, an error will be issued and the value of the maximum date allowed will be displayed.

Form Validation is relevant to manual orders, bookings and order templates.

For Order templates, the schedule date validation will be added to the when-validate-item trigger on GENERATE_ORDERS.sched_date.

For Bookings, the schedule date validation will be added to the when-list-changed trigger on CREATE_ORDERS.sched_name.

For Manual Entry, the schedule date validation will be added to a new when-validate-item trigger on SCH_ORD_UPD.sched_name.

=== Import Validation ===

For imports, the schedule date has already been assigned and we cannot validate the value at the point of data entry. For imports the validation will be carried out within the IMP package which controls data imports.

There are two imports which are relevant to the Schedule Name and they are the Bookings import and the Orders import. These two imports are validated in two functions within the IMP package.

The functions are Process_TI_Orders and Process_Bookings. Within both functions, the import data is validated one row at a time, schedule name is extracted from the import file and basic validation is applied (IsNull)

At the point where the schedule name is extracted, we will check the value of the sched_name against the current date + ord_future_limit_days. In the declarations of each function we will include a cursor to extract the system date and a cursor to extract the value of ord_future_limit. The cursors will be fetched at the beginning of the functions.

=== Date Variables ===

V_SCHED_DATE := TO_DATE(:SCH_ORD_UP.SCHED_NAME, DD/MM/YY)

Cursor CURRENT is
Select current_date from dual;

V_current date;

Open CURRENT;
Fetch CURRENT into v_current

Cursor ORD_FUTURE_LIMIT is
Select value from ADM_SYSTEM_PARAM
Where param_name = ‘ORD_FUTURE_LIMIT_DAYS’

v_days integer;

Open ORD_FUTURE_LIMIT
Fetch ORD_FUTURE_LIMIT into v_days;

V_MAX_DATE := v_current_date + v_days;

If v_sched_date > v_max_date

Message ( ‘You have exceeded the maximum number of days in the future that an order can be created. Maximum date is ‘|| v_max_date);

End if;

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==
IMAGE

== Authorised By ==

IMAGE

247211

2009-02-05T15:33:19Z

Kingj: New page: = 247211-SS-7B6L2V Control Order Date Creation = Copyright OBS Logistics © 2008 The information contained herein is the property of OBS Logistics and is supplied without liability for e...

252336

2009-02-05T15:27:00Z

Kingj: /* QUOTE & DOCUMENT HISTORY */

= 252336 PA-7DGNK2 Change Schedule Date of a Scheduled Trip =

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
For Trips in Statuses PLANNED, TENDERED and ACCEPTED To be able to retain a scheduled Trip ID with associated orders and transfer as one to an alternative schedule date if required after the trip has been built and a loading schedule issued for the original date.
Invoke change by 'Right-Click' Drop-down box [Change Schedule Date]
When the Trip schedule date is changed automatically update the Order Scheduled delivery date for all orders on the Trip.
Delete any resources added into the Trip on the original schedule date and revert CARRIER to OWNING DEPOT on new schedule date

== Solution ==
Changing the Schedule name (SCHED_NAME) of a specific trip can be done, but due to referential integrity (links between data) we will have to follow specific steps to complete the change.
Several tables have keys which are based on a combination of the SCHED_NAME and TRIP_ID fields. In these tables we cannot simply update SCHED_NAME as this would violate existing constraints and the Oracle Database would not allow the change.

To work around this we must make a copy of the record(s) we want to change. In the copy record we then update the SCHED_NAME. Once the record has been created and updated, we can remove the original record.

To ensure that we comply with all the data constraints we must copy and update the records from the top (SCH_TRIP table) down and then delete the original records from the bottom (SCH_TRIP_STOP, SCH_TRIP_AUDIT tables) up to SCH_TRIP table.

Several tables, where SCHED_NAME is a simple foreign key, the SCHED_NAME can be updated without requiring copies and deletions.

To allow you to understand the scope of this change, the referential integrity issues will effect 9 tables, with another 11 tables requiring some manipulation and updating. (please see diagram attatched)

In addition to the record changes above, we need to identify which orders have been assigned to the trip using the SCH_HAULAGE_ACTIVITY table. We then update the SCHED_NAME in the SCH_ORD table for all the identified orders and update the late delivery field to match the new schedule.

To update the late delivery field, we intend to amend the date part only, to match the new SCHED_NAME and retain the time from the original schedule.
Set Driver_id, trailer_id and tractor_id to Null in the old record in SCH_TRIP table and set Trailer_id to Null in the new record in the SCH_TRIP_STOP table.
Update Carrier_ID on new SCH_TRIP record to equal the OWNING_DEPT.
These changes will all be completed within a new Package on the form and will be launched from the Trip Tree menu. A new menu option will be added called – ‘Change Schedule date’. Selecting this option will launch the new package.

IMAGE

== Scope ==
This change will be applied to system version 10.5.0 on CONTST and once approved CONPRD.

= SET-UP =

== Pre-requisites ==
None

== Menu Structure ==
Pop up menu Trip Tree Menu will be amended to include a new menu item called ‘Change Schedule Date’ When this is launched, the status of the existing scheduled trip will be checked. If the status is not ‘PLANNED’, ‘TENDERED’ or ‘ACCEPTED’ the user will be told they cannot change the date. If the trip is the required status, a small input form will launch where the user can enter the new schedule date.

== Data ==

The new schedule date will be stored in a non-database item and used as reference for amending the relevant records. The schedule date field , on the new screen will include a list of values, which will be populated based on the schedules available in the database. The user must select a value form this list.

=== Copying data. ===

In the following tables, we will create records based on the new schedule date, where all other values are the same for the trip that is being amended.

Insert into SCH_TRIP (sched_name, trip_id)
VALUES (:change_schedule.new_schedule, :trip_dtl.trip_id)

Commit;

Update SCH_TRIP
SET (all other fields) =
SELECT (all other fields FROM SCH_TRIP where sched_name =:trip_dtl.sched_name and trip_id = :trip_dtl.trip_id)
where sched_name =:change_schedule.new_schedule and trip_id = :trip_dtl.trip_id;

Commit;

There are now two records on the table for the same trip, one referencing the original Schedule name and one referencing the new schedule name. We must continue this process for all tables which reference the schedule_name as part of its primary key.

Before we can carry out the above steps we must first use cursors to check if the selected trip/ schedule have any related records in each table. Only if we find a related record do we insert and update. Otherwise we do nothing with the table.

=== Updating Data ===

Having identified the rest of the tables which reference the schedule name, we must update the relevant record(s) to reference the new schedule_name.

The order records associated with the selected trip must be updated to reflect the new schedule date and a new late delivery time. The order table does not include the trip id, so identifying the relevant orders will require linking three tables, SCH_TRIP_STOP, SCH_HAULAGE_ACTIVITY, SCH_ORD. Once the relevant records in SCH_ORD have been identified, validation will be required to ensure that the amended LATE DELIVERY DATE meets all the existing checks. We are not intending to make any changes to the late delivery time, this will simply inherit the existing value.

The last updates to be completed will remove all resources from the old trip and amending the carrier to be the owning company. In this instance, resources refers to drivers, tractors and trailers. As the old records are to be deleted, this will in fact remove the resources from the original trip.

=== Deleting Data ===

In several tables, there are now two trip records, each referencing a different schedule name . This will be confusing as users will not be aware which is the relevant trip. For this reason , all duplicate trip records , where the old schedule is referenced will be deleted.

Just as when we inserted data, we did so in s specific order, deleting data must also be carried out in a specific order, starting with the following tables

ACC_INVOICE_TRIP
PNL_COST_APPORT
SCH_TRIP_AUDIT
PNL_REV_APPORT
RTE_ROUTE_TRIP
TMP_SCHED_TRIP
SCH_ORD_NON_CONFORM
SCH_TRIP_STOP

And ending with the SCH_TRIP table.

= FUNCTIONAL DESCRIPTION =
This change will allow the user to select a trip, enter a different schedule date and move all the related trip information to the new schedule date. This process will be completed in three steps.

1. The user selects the trip from the trip tree and from the right click menu selects the option ‘Change Schedule Date’. If the trip is in the correct status, an input form is launched.

2. The user selects the new schedule date from the list of schedule dates available. For a schedule date to be available in the list, it must exist in the SCH_SCHEDULE table.

3. The user selects OK . In the background a package is launched which carries out all the required data changes. As the final change is deleting the record that is currently on display in the form, this is an event the OK command button must handle.

== OK Command Button ==

After carrying out all the data changes as described in the previous Data section, this button must handle the event where the record that is currently being displayed on the form is deleted.
This will be achieved by clearing the data block, then setting the schedule name to be the new schedule and executing a query. This code will run after all the data changes have been committed.

== Cancel Command Button ==

This will allow the user to cancel the schedule date change, but only before they select OK. Once OK has been selected, this cannot be cancelled. Users would be able to use the ‘Change Schedule Date’ functionality to revert the trip back to its original schedule date.

IMAGE

The above screen shot shows a trip selected in the trip tree and the right click function which launches a pop up menu. This is where the option to ‘Change Schedule Date’ will be available.

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==
{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

257584

2009-02-05T15:25:45Z

Kingj: New page: =257584 EI-7L8HBY Booking MSG for Kraft BIC Orders= Copyright OBS Logistics © 2008 The information contained herein is the property of OBS Logistics and is supplied without liability fo...

=257584 EI-7L8HBY Booking MSG for Kraft BIC Orders=

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
Request for an MTS flow that sends booking information message to ESI, for KRAFT BIC orders, that have their Trip Status as 'ENROUTE'. In case of cross docked orders, only details for the delivery to the TO_LOC destination of the order should be reported. This message should also be sent for rebooked orders and any added rebook suffix in the EXTERNAL_REF should be removed before being reported.

Please note that there are some manually built orders for KRAFT BIC, with EXTERNAL_REF which did not come into MTS through the 'KRAFT ORDERS' inbound interface. We would not want these orders reported in this outbound interface.

The file format should be comma delimited and containing 38 fields as shown in attached sample file. The data in all fields are wrapped with quotation marks. The format for reporting the 'LATE_DEL' field should be "YYYYMMDD HH24:MM:SS" . The LOCATION_NAME field reported is the value in the GEO_LOCATION table where the SCH_ORD.TO_LOC matches the SCH_TRIP_STOP.LOCATION_ID. The decimal-separator for reporting the 'RPE' field should be a comma (e.g. 12,5 not 12.5)

The attached sample .txt file shows the required MTS field variables, hard-coded values and their positions that will be expected in the output .CSV for this interface..
The file should be generated for orders that meet the following criteria:
A) The Trip Status is 'ENROUTE'
B) CUSTOMER = KRAFT BIC
C) The SCH_ORD.EXTERNAL_REF should have come through the inbound 'KRAFT ORDERS' interface or a rebooked version ( Here any added suffix should be removed)
D) The date part of the SCH_ORD.LATE_DEL is equal to or greater than the current Date

The naming convention for the output file will be: Sendung_'YYMMDDHHMM'.CSV.
This interface should be developed as a stand alone development. Sample output file attached.

== Solution ==

Within the Trip screens, Trip Planning, Trip Manipulation and Waterfall, whenever the status is changed to EN-ROUTE a procedure will be run. The procedure will check if the trip has any KRAFT-BIC orders. If not, the procedure will close.

If there are KRAFT-BIC orders, the next check will be that the value of LATE_DEL is greater than or equal to today. If this is not the case, the procedure will close.

If the LATE_DEL and Customer criteria are met, the next check is that the ORDER has been created via the INBOUND INTERFACE. To identify these records we will check that SOURCE_SYSTEM equals KRAFT SAP. This will exclude all MANUAL and TEMPLATE BATCH records.

If the above criteria is met, the oms_ref, external_ref, late_del, to_loc and booking_ref will be inserted into INT_ORDER_HEADER with a RECORD_STATUS of ‘SEND’

PROCESS_OUTBOUND_ORDER within Package INT_MSG will be amended to select all KRAFT-BIC orders from INT_ORDER_HEADER where the RECORD_STATUS is SEND.

Using the OMS_REF in this table, we will retrieve the CARRIER_CODE and TOTAL_RPE_QTY.

TO_LOC will be used to find the LOCATION_NAME, COUNTY_CODE, POSTCODE and TOWN from GEO_LOCATIONS.

Within the PROCESS_OUTBOUND_ORDER procedure, the data will also be formatted to the specifications, including adding quotation marks and written out to the csv file. An exisiting DATABASE job runs every 15 minutes and calls PROCESS_OUTBOUND_ORDER.

The CSV file will have the naming convention :
Sendung_’YYMMDDHHMM’.CSV. This file will be made up of the following information:

"26427",
"00000",
"",
"EXTERNAL_REF",
"LATE_DEL",
"0",
"GB73",
"",
"",
"",
"",
"",
"",
"",
"",
"LOCATION_NAME",
"",
"",
"COUNTRY_CODE",
"POSTCODE",
"TOWN",
"",
"BOOKING_REF",
"",
"",
"”,
"",
"",
"",
"",
"",
"",
"",
"",
"RPE",
"",
"",
"CARRIER_CODE"

The data will be written to this file in the order as stated in the attachment; some hard coded data will be included with the field data. The file will be written out to the folder as determined by the system parameter MTS_OUTBOUND_ORDER_PATH. This is currently set as WEBINT/<DATABASE>/INTERFACE/OUT.

Once the record has been successfully added to the csv file, the RECORD_STATUS in INT_ORDER_HEADER will be updated to SENT. The RECORD_ID will be updated to the filename. Launching the procedure only when the status is changed to EN-ROUTE will ensure that the trip records are added to the CSV file once.

== Scope ==
This change will be applied to system version {enter the version} on {enter the test database e.g. CONTST} and once approved {enter the production database e.g.: CONPRD}.

= FUNCTIONAL DESCRIPTION =
In the Trip Planning, Manipulation and Waterfall screens, when the trip status is changed to EN-ROUTE a process will run in the background.

This process will check the customer, late delivery date and source as described earlier. If the criteria is met a record will be written to the INT_ORDER_HEADER table which will identify the order and the customer as KRAFT-BIC.

Every 15 minutes a database is launched which will run the procedure PROCESS_OUTBOUND_ORDER.

This procedure will check the INT_ORDER_HEADER table for any KRAFT records with a status of SEND. This record will be selected along with further details, using the information stored in the record and the data will be written to a CSV file.

Once the record has been copied to the CSV file the INT_ORDER_HEADER table will be updated; record status will be updated to SENT and the filename inserted as the record id.

Changes will be made to the TRIP_PLAN.fmb, TRIPSUM.fmb and WATERFALL.fmb
Screens. The package INT_MSG, specifically the PROCESS_OUTBOUND_HEADER function.

== QUOTE & DOCUMENT HISTORY ==

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==
IMAGE

== Authorised By ==

IMAGE

HCRPRD Release - 16/01/2009

2009-02-05T15:15:17Z

Kingj: /* Programmes Released */

== Requested Developments ==

'''[[249378|256632 (PA-7KLFLE) Facility to update 1st Stop departure time''']]

'''[[257584|257584 (EI-7L8HBY)RIO-Booking Msg for Kraft BIC orders''']]

'''[[256287|256287 (NW-7KGE7N) Fixed Routes to run with ZIP codes''']]

'''[[247211|247211 (SS-7B6L2V)Control Order Creation Date''']]

'''[[256637|256637 (PA-7KPHJ8)EFX Pop-Up box''']]

'''[[256471|256471 (PA-7K2BG3)Create a drop down box at log-On''']]

'''[[249378|249378 (PA-7DDFH9)Data Export for EFX Interface''']]

'''[[246306|246306 (NW-7BCMAT)Booking EDI to incl Customer''']]

'''[[247174|247174 (NW-7CHEWZ)Add Weight and Spec Inst to Booking Import''']]

'''[[252344|252344 (PA-7DJLS6)Set Parameters for Trip Status change''']]

'''[[249771 |249771 (AS-765E9J)Fix to Owning Depot issue''']]

== Programmes Released ==

{| border="1"
!Program||Version
|-
|[[TRIPSUM.fmx]]||2.128
|-
|[[TRIP_PLAN]].fmx||1.35
|-
|[[TRIP_OVERVIEW]].fmx||1.11
|-
|INT_MSG.sql||1.48
|-
|GEO.sql||2.34
|-
|IMP.sql||2.68
|-
|[[STATIC_DATA_MAINT]].fmx||1.7
|-
|[[Geography]].fmx||2.11
|-
|[[Locations.fmx]]||2.53
|-
|AT_GEO_PLAN_REGION_256287.sql||1.1
|-
|CT_GEO_COUNTRY_POSTCODE_256287.sql||1.1
|-
|[[ORDERS]].fmx||2.104
|-
|[[ORDTEMPL]].fmx||2.39
|-
|DATA_ADM_FUNCTION_256637.sql||1.1
|-
|ADM.sql||2.14
|-
|[[ACC_CTRL]].fmx||2.31
|-
|[[ORI_STATS]].fmx||2.14
|-
|256474_CREATE_TABLE_ADM_USER_PROFILE.sql||1.1
|-
|256471_ALTER_TABLES||1.1
|-
|DATA_ADM_SYSTEM_PARAM_249378||1.1
|-
|[[INT_ERROR]].fmx||1.27.6
|-
|246306.sql||1.1
|-
|[[BOOKINGS]].fmx||2.19
|-
|[[INT_ERROR]].fmx||1.27
|-
|[[LOCATION]].fmx||2.48
|-
|[[TRIPDTL]].fmx||2.56
|-
|TRM.sql||2.82
|-
|DATA_ADM_SYSTEM_PARAM_252344.sql||1.1
|-
|RTE.sql||2.3
|}

HCRPRD Release - 16/01/2009

2009-02-05T15:07:13Z

Kingj: /* Programmes Released */

== Requested Developments ==

'''[[249378|256632 (PA-7KLFLE) Facility to update 1st Stop departure time''']]

'''[[257584|257584 (EI-7L8HBY)RIO-Booking Msg for Kraft BIC orders''']]

'''[[256287|256287 (NW-7KGE7N) Fixed Routes to run with ZIP codes''']]

'''[[247211|247211 (SS-7B6L2V)Control Order Creation Date''']]

'''[[256637|256637 (PA-7KPHJ8)EFX Pop-Up box''']]

'''[[256471|256471 (PA-7K2BG3)Create a drop down box at log-On''']]

'''[[249378|249378 (PA-7DDFH9)Data Export for EFX Interface''']]

'''[[246306|246306 (NW-7BCMAT)Booking EDI to incl Customer''']]

'''[[247174|247174 (NW-7CHEWZ)Add Weight and Spec Inst to Booking Import''']]

'''[[252344|252344 (PA-7DJLS6)Set Parameters for Trip Status change''']]

'''[[249771 |249771 (AS-765E9J)Fix to Owning Depot issue''']]

== Programmes Released ==

{| border="1"
!Program||Version
|-
|TRIP_OVERVIEW.fmx||1.1
|-
|[[TRIPSUM.fmx]]||2.128
|-
|[[TRIP_PLAN]].fmx||1.35
|-
|[[TRIP_OVERVIEW]].fmx||1.11
|-
|INT_MSG.sql||1.48
|-
|GEO.sql||2.34
|-
|IMP.sql||2.68
|-
|STATIC_DATA_MAINT.fmx||1.7
|-
|Geography.fmx||2.11
|-
|Locations.fmx||2.53
|-
|AT_GEO_PLAN_REGION_256287.sql||1.1
|-
|CT_GEO_COUNTRY_POSTCODE_256287.sql||1.1
|-
|ORDERS.fmx||2.104
|-
|BOOKINGS.fmx||2.2
|-
|ORDTEMPL.fmx||2.39
|-
|IMP.sql||2.67
|-
|DATA_ADM_FUNCTION_256637.sql||1.1
|-
|ADM.sql||2.14
|-
|ACC_CTRL.fmx||2.31
|-
|ORI_STATS.fmx||2.14
|-
|256474_CREATE_TABLE_ADM_USER_PROFILE.sql||1.1
|-
|256471_ALTER_TABLES||1.1
|-
|INT_MSG.sql||1.47
|-
|DATA_ADM_SYSTEM_PARAM_249378||1.1
|-
|INT_ERROR.fmx||1.27
|-
|STATIC_DATA_MAINT.fmx||1.6
|-
|246306.sql||1.1
|-
|BOOKINGS.fmx||2.19
|-
|INT_ERROR.fmx||1.27
|-
|LOCATION.fmx||2.48
|-
|IMP||???
|-
|TRIPDTL.fmx||2.56
|-
|TRM.sql||2.82
|-
|DATA_ADM_SYSTEM_PARAM_252344.sql||1.1
|-
|TRM.sql||2.82
|-
|RTE.sql||2.3
|}

HCRPRD Release - 16/01/2009

2009-02-05T15:05:33Z

Kingj: /* Additional Fixes */

== Requested Developments ==

'''[[249378|256632 (PA-7KLFLE) Facility to update 1st Stop departure time''']]

'''[[257584|257584 (EI-7L8HBY)RIO-Booking Msg for Kraft BIC orders''']]

'''[[256287|256287 (NW-7KGE7N) Fixed Routes to run with ZIP codes''']]

'''[[247211|247211 (SS-7B6L2V)Control Order Creation Date''']]

'''[[256637|256637 (PA-7KPHJ8)EFX Pop-Up box''']]

'''[[256471|256471 (PA-7K2BG3)Create a drop down box at log-On''']]

'''[[249378|249378 (PA-7DDFH9)Data Export for EFX Interface''']]

'''[[246306|246306 (NW-7BCMAT)Booking EDI to incl Customer''']]

'''[[247174|247174 (NW-7CHEWZ)Add Weight and Spec Inst to Booking Import''']]

'''[[252344|252344 (PA-7DJLS6)Set Parameters for Trip Status change''']]

'''[[249771 |249771 (AS-765E9J)Fix to Owning Depot issue''']]

== Programmes Released ==

{| border="1"
!Program||Version
|-
|TRIP_PLAN.fmx||1.3
|-
|TRIP_OVERVIEW.fmx||1.1
|-
|[[TRIPSUM.fmx]]||2.128
|-
|[[TRIP_PLAN]].fmx||1.35
|-
|[[TRIP_OVERVIEW]].fmx||1.11
|-
|INT_MSG.sql||1.48
|-
|GEO.sql||2.34
|-
|IMP.sql||2.68
|-
|STATIC_DATA_MAINT.fmx||1.7
|-
|Geography.fmx||2.11
|-
|Locations.fmx||2.53
|-
|AT_GEO_PLAN_REGION_256287.sql||1.1
|-
|CT_GEO_COUNTRY_POSTCODE_256287.sql||1.1
|-
|ORDERS.fmx||2.104
|-
|BOOKINGS.fmx||2.2
|-
|ORDTEMPL.fmx||2.39
|-
|TRIP_PLAN.fmx||1.32
|-
|IMP.sql||2.67
|-
|TRIP_PLAN.fmx||1.33
|-
|DATA_ADM_FUNCTION_256637.sql||1.1
|-
|ADM.sql||2.14
|-
|ACC_CTRL.fmx||2.31
|-
|ORI_STATS.fmx||2.14
|-
|256474_CREATE_TABLE_ADM_USER_PROFILE.sql||1.1
|-
|256471_ALTER_TABLES||1.1
|-
|TRIP_PLAN.fmx||1.34
|-
|INT_MSG.sql||1.47
|-
|TRIP_PLAN.fmx||1.25
|-
|DATA_ADM_SYSTEM_PARAM_249378||1.1
|-
|INT_ERROR.fmx||1.27
|-
|STATIC_DATA_MAINT.fmx||1.6
|-
|246306.sql||1.1
|-
|BOOKINGS.fmx||2.19
|-
|INT_ERROR.fmx||1.27
|-
|LOCATION.fmx||2.48
|-
|IMP||???
|-
|TRIPDTL.fmx||2.56
|-
|TRM.sql||2.82
|-
|DATA_ADM_SYSTEM_PARAM_252344.sql||1.1
|-
|TRM.sql||2.82
|-
|TRIP_PLAN.fmx||1.28
|-
|RTE.sql||2.3
|}

HCRPRD Release - 16/01/2009

2009-02-05T14:58:04Z

Kingj: /* Developments */

== Requested Developments ==

'''[[249378|256632 (PA-7KLFLE) Facility to update 1st Stop departure time''']]

'''[[257584|257584 (EI-7L8HBY)RIO-Booking Msg for Kraft BIC orders''']]

'''[[256287|256287 (NW-7KGE7N) Fixed Routes to run with ZIP codes''']]

'''[[247211|247211 (SS-7B6L2V)Control Order Creation Date''']]

'''[[256637|256637 (PA-7KPHJ8)EFX Pop-Up box''']]

'''[[256471|256471 (PA-7K2BG3)Create a drop down box at log-On''']]

'''[[249378|249378 (PA-7DDFH9)Data Export for EFX Interface''']]

'''[[246306|246306 (NW-7BCMAT)Booking EDI to incl Customer''']]

'''[[247174|247174 (NW-7CHEWZ)Add Weight and Spec Inst to Booking Import''']]

'''[[252344|252344 (PA-7DJLS6)Set Parameters for Trip Status change''']]

'''[[249771 |249771 (AS-765E9J)Fix to Owning Depot issue''']]

== Additional Fixes ==

{| border="1"
!Program||Version
|-
|TRIPSUM.fmx||2.123
|-
|TRIP_PLAN.fmx||1.3
|-
|TRIP_OVERVIEW.fmx||1.1
|-
|TRIPSUM.fmx||2.128
|-
|[[TRIP_PLAN]].fmx||1.35
|-
|[[TRIP_OVERVIEW]].fmx||1.11
|-
|INT_MSG.sql||1.48
|-
|GEO.sql||2.34
|-
|IMP.sql||2.68
|-
|STATIC_DATA_MAINT.fmx||1.7
|-
|Geography.fmx||2.11
|-
|Locations.fmx||2.53
|-
|AT_GEO_PLAN_REGION_256287.sql||1.1
|-
|CT_GEO_COUNTRY_POSTCODE_256287.sql||1.1
|-
|ORDERS.fmx||2.104
|-
|BOOKINGS.fmx||2.2
|-
|ORDTEMPL.fmx||2.39
|-
|TRIPSUM.fmx||2.125
|-
|TRIP_PLAN.fmx||1.32
|-
|IMP.sql||2.67
|-
|TRIPSUM.fmx||2.126
|-
|TRIP_PLAN.fmx||1.33
|-
|DATA_ADM_FUNCTION_256637.sql||1.1
|-
|ADM.sql||2.14
|-
|ACC_CTRL.fmx||2.31
|-
|ORI_STATS.fmx||2.14
|-
|256474_CREATE_TABLE_ADM_USER_PROFILE.sql||1.1
|-
|256471_ALTER_TABLES||1.1
|-
|TRIPSUM.fmx||2.127
|-
|TRIP_PLAN.fmx||1.34
|-
|INT_MSG.sql||1.47
|-
|TRIPSUM.fmx||2.115
|-
|TRIP_PLAN.fmx||1.25
|-
|DATA_ADM_SYSTEM_PARAM_249378||1.1
|-
|INT_ERROR.fmx||1.27
|-
|STATIC_DATA_MAINT.fmx||1.6
|-
|246306.sql||1.1
|-
|BOOKINGS.fmx||2.18
|-
|BOOKINGS.fmx||2.19
|-
|INT_ERROR.fmx||1.27
|-
|LOCATION.fmx||2.48
|-
|IMP||???
|-
|TRIPDTL.fmx||2.56
|-
|TRM.sql||2.82
|-
|DATA_ADM_SYSTEM_PARAM_252344.sql||1.1
|-
|TRM.sql||2.82
|-
|TRIP_PLAN.fmx||1.28
|-
|TRIPSUM.fmx||2.121
|-
|RTE.sql||2.3
|}

HCRPRD Release - 16/01/2009

2009-02-05T14:57:44Z

Kingj: /* Requested Developments */

== Developments ==

'''[[249378|256632 (PA-7KLFLE) Facility to update 1st Stop departure time''']]

'''[[257584|257584 (EI-7L8HBY)RIO-Booking Msg for Kraft BIC orders''']]

'''[[256287|256287 (NW-7KGE7N) Fixed Routes to run with ZIP codes''']]

'''[[247211|247211 (SS-7B6L2V)Control Order Creation Date''']]

'''[[256637|256637 (PA-7KPHJ8)EFX Pop-Up box''']]

'''[[256471|256471 (PA-7K2BG3)Create a drop down box at log-On''']]

'''[[249378|249378 (PA-7DDFH9)Data Export for EFX Interface''']]

'''[[246306|246306 (NW-7BCMAT)Booking EDI to incl Customer''']]

'''[[247174|247174 (NW-7CHEWZ)Add Weight and Spec Inst to Booking Import''']]

'''[[252344|252344 (PA-7DJLS6)Set Parameters for Trip Status change''']]

'''[[249771 |249771 (AS-765E9J)Fix to Owning Depot issue''']]

== Additional Fixes ==

{| border="1"
!Program||Version
|-
|TRIPSUM.fmx||2.123
|-
|TRIP_PLAN.fmx||1.3
|-
|TRIP_OVERVIEW.fmx||1.1
|-
|TRIPSUM.fmx||2.128
|-
|[[TRIP_PLAN]].fmx||1.35
|-
|[[TRIP_OVERVIEW]].fmx||1.11
|-
|INT_MSG.sql||1.48
|-
|GEO.sql||2.34
|-
|IMP.sql||2.68
|-
|STATIC_DATA_MAINT.fmx||1.7
|-
|Geography.fmx||2.11
|-
|Locations.fmx||2.53
|-
|AT_GEO_PLAN_REGION_256287.sql||1.1
|-
|CT_GEO_COUNTRY_POSTCODE_256287.sql||1.1
|-
|ORDERS.fmx||2.104
|-
|BOOKINGS.fmx||2.2
|-
|ORDTEMPL.fmx||2.39
|-
|TRIPSUM.fmx||2.125
|-
|TRIP_PLAN.fmx||1.32
|-
|IMP.sql||2.67
|-
|TRIPSUM.fmx||2.126
|-
|TRIP_PLAN.fmx||1.33
|-
|DATA_ADM_FUNCTION_256637.sql||1.1
|-
|ADM.sql||2.14
|-
|ACC_CTRL.fmx||2.31
|-
|ORI_STATS.fmx||2.14
|-
|256474_CREATE_TABLE_ADM_USER_PROFILE.sql||1.1
|-
|256471_ALTER_TABLES||1.1
|-
|TRIPSUM.fmx||2.127
|-
|TRIP_PLAN.fmx||1.34
|-
|INT_MSG.sql||1.47
|-
|TRIPSUM.fmx||2.115
|-
|TRIP_PLAN.fmx||1.25
|-
|DATA_ADM_SYSTEM_PARAM_249378||1.1
|-
|INT_ERROR.fmx||1.27
|-
|STATIC_DATA_MAINT.fmx||1.6
|-
|246306.sql||1.1
|-
|BOOKINGS.fmx||2.18
|-
|BOOKINGS.fmx||2.19
|-
|INT_ERROR.fmx||1.27
|-
|LOCATION.fmx||2.48
|-
|IMP||???
|-
|TRIPDTL.fmx||2.56
|-
|TRM.sql||2.82
|-
|DATA_ADM_SYSTEM_PARAM_252344.sql||1.1
|-
|TRM.sql||2.82
|-
|TRIP_PLAN.fmx||1.28
|-
|TRIPSUM.fmx||2.121
|-
|RTE.sql||2.3
|}

HCRPRD Release - 16/01/2009

2009-02-05T14:57:19Z

Kingj: /* Additional Fixes */

== Requested Developments ==
'''
256632 (PA-7KLFLE) Facility to update 1st Stop departure time'''
TRIPSUM.fmx 2.123
TRIP_PLAN.fmx 1.30
TRIP_OVERVIEW.fmx 1.10

'''257584 (EI-7L8HBY) RIO-Booking Msg for Kraft BIC orders'''
TRIPSUM.fmx 2.128
TRIP_PLAN.fmx 1.35
TRIP_OVERVIEW.fmx 1.11
INT_MSG.sql 1.48

'''256287 (NW-7KGE7N) Fixed Routes to run with ZIP codes'''
GEO.sql 2.34
IMP.sql 2.68
STATIC_DATA_MAINT.fmx 1.7
Geography.fmx 2.11
Locations.fmx 2.53
AT_GEO_PLAN_REGION_256287.sql 1.1
CT_GEO_COUNTRY_POSTCODE_256287.sql 1.1

'''247211 (SS-7B6L2V) Control Order Creation Date'''
ORDERS.fmx 2.104
BOOKINGS.fmx 2.20
ORDTEMPL.fmx 2.39
TRIPSUM.fmx 2.125
TRIP_PLAN.fmx 1.32
IMP.sql 2.67

'''256637 (PA-7KPHJ8) EFX Pop-Up box'''
TRIPSUM.fmx 2.126
TRIP_PLAN.fmx 1.33
DATA_ADM_FUNCTION_256637.sql 1.1

'''256471 (PA-7K2BG3) Create a drop down box at log-On'''
ADM.sql 2.14
ACC_CTRL.fmx 2.31
ORI_STATS.fmx 2.14
256474_CREATE_TABLE_ADM_USER_PROFILE.sql 1.1
256471_ALTER_TABLES 1.1
TRIPSUM.fmx 2.127
TRIP_PLAN.fmx 1.34

'''249378 (PA-7DDFH9) Data Export for EFX Interface'''
INT_MSG.sql 1.47
TRIPSUM.fmx 2.118
TRIP_PLAN.fmx 1.25
DATA_ADM_SYSTEM_PARAM_249378.sql 1.1

'''246306 (NW-7BCMAT) Booking EDI to incl Customer'''
INT_ERROR.fmx 1.27
STATIC_DATA_MAINT.fmx 1.6
246306.sql 1.1
BOOKINGS.fmx 2.18

'''247174 (NW-7CHEWZ) Add Weight and Spec Inst to Booking Import'''
BOOKINGS.fmx 2.19
INT_ERROR.fmx 1.27
LOCATION.fmx 2.48
IMP ???

'''252344 (PA-7DJLS6) Set Parameters for Trip Status change'''
TRIPDTL.fmx 2.56
TRM.sql 2.82
DATA_ADM_SYSTEM_PARAM_252344.sql 1.1

'''249771 (AS-765E9J) Fix to Owning Depot issue'''
TRM.sql 2.82
TRIP_PLAN.fmx 1.28
TRIPSUM.fmx 2.121
RTE.sql 2.3

== Developments ==

'''[[249378|256632 (PA-7KLFLE) Facility to update 1st Stop departure time''']]

'''[[257584|257584 (EI-7L8HBY)RIO-Booking Msg for Kraft BIC orders''']]

'''[[256287|256287 (NW-7KGE7N) Fixed Routes to run with ZIP codes''']]

'''[[247211|247211 (SS-7B6L2V)Control Order Creation Date''']]

'''[[256637|256637 (PA-7KPHJ8)EFX Pop-Up box''']]

'''[[256471|256471 (PA-7K2BG3)Create a drop down box at log-On''']]

'''[[249378|249378 (PA-7DDFH9)Data Export for EFX Interface''']]

'''[[246306|246306 (NW-7BCMAT)Booking EDI to incl Customer''']]

'''[[247174|247174 (NW-7CHEWZ)Add Weight and Spec Inst to Booking Import''']]

'''[[252344|252344 (PA-7DJLS6)Set Parameters for Trip Status change''']]

'''[[249771 |249771 (AS-765E9J)Fix to Owning Depot issue''']]

== Additional Fixes ==

{| border="1"
!Program||Version
|-
|TRIPSUM.fmx||2.123
|-
|TRIP_PLAN.fmx||1.3
|-
|TRIP_OVERVIEW.fmx||1.1
|-
|TRIPSUM.fmx||2.128
|-
|[[TRIP_PLAN]].fmx||1.35
|-
|[[TRIP_OVERVIEW]].fmx||1.11
|-
|INT_MSG.sql||1.48
|-
|GEO.sql||2.34
|-
|IMP.sql||2.68
|-
|STATIC_DATA_MAINT.fmx||1.7
|-
|Geography.fmx||2.11
|-
|Locations.fmx||2.53
|-
|AT_GEO_PLAN_REGION_256287.sql||1.1
|-
|CT_GEO_COUNTRY_POSTCODE_256287.sql||1.1
|-
|ORDERS.fmx||2.104
|-
|BOOKINGS.fmx||2.2
|-
|ORDTEMPL.fmx||2.39
|-
|TRIPSUM.fmx||2.125
|-
|TRIP_PLAN.fmx||1.32
|-
|IMP.sql||2.67
|-
|TRIPSUM.fmx||2.126
|-
|TRIP_PLAN.fmx||1.33
|-
|DATA_ADM_FUNCTION_256637.sql||1.1
|-
|ADM.sql||2.14
|-
|ACC_CTRL.fmx||2.31
|-
|ORI_STATS.fmx||2.14
|-
|256474_CREATE_TABLE_ADM_USER_PROFILE.sql||1.1
|-
|256471_ALTER_TABLES||1.1
|-
|TRIPSUM.fmx||2.127
|-
|TRIP_PLAN.fmx||1.34
|-
|INT_MSG.sql||1.47
|-
|TRIPSUM.fmx||2.115
|-
|TRIP_PLAN.fmx||1.25
|-
|DATA_ADM_SYSTEM_PARAM_249378||1.1
|-
|INT_ERROR.fmx||1.27
|-
|STATIC_DATA_MAINT.fmx||1.6
|-
|246306.sql||1.1
|-
|BOOKINGS.fmx||2.18
|-
|BOOKINGS.fmx||2.19
|-
|INT_ERROR.fmx||1.27
|-
|LOCATION.fmx||2.48
|-
|IMP||???
|-
|TRIPDTL.fmx||2.56
|-
|TRM.sql||2.82
|-
|DATA_ADM_SYSTEM_PARAM_252344.sql||1.1
|-
|TRM.sql||2.82
|-
|TRIP_PLAN.fmx||1.28
|-
|TRIPSUM.fmx||2.121
|-
|RTE.sql||2.3
|}

HCRPRD Release - 16/01/2009

2009-02-05T14:42:22Z

Kingj: /* Additional Fixes */

== Requested Developments ==
'''
256632 (PA-7KLFLE) Facility to update 1st Stop departure time'''
TRIPSUM.fmx 2.123
TRIP_PLAN.fmx 1.30
TRIP_OVERVIEW.fmx 1.10

'''257584 (EI-7L8HBY) RIO-Booking Msg for Kraft BIC orders'''
TRIPSUM.fmx 2.128
TRIP_PLAN.fmx 1.35
TRIP_OVERVIEW.fmx 1.11
INT_MSG.sql 1.48

'''256287 (NW-7KGE7N) Fixed Routes to run with ZIP codes'''
GEO.sql 2.34
IMP.sql 2.68
STATIC_DATA_MAINT.fmx 1.7
Geography.fmx 2.11
Locations.fmx 2.53
AT_GEO_PLAN_REGION_256287.sql 1.1
CT_GEO_COUNTRY_POSTCODE_256287.sql 1.1

'''247211 (SS-7B6L2V) Control Order Creation Date'''
ORDERS.fmx 2.104
BOOKINGS.fmx 2.20
ORDTEMPL.fmx 2.39
TRIPSUM.fmx 2.125
TRIP_PLAN.fmx 1.32
IMP.sql 2.67

'''256637 (PA-7KPHJ8) EFX Pop-Up box'''
TRIPSUM.fmx 2.126
TRIP_PLAN.fmx 1.33
DATA_ADM_FUNCTION_256637.sql 1.1

'''256471 (PA-7K2BG3) Create a drop down box at log-On'''
ADM.sql 2.14
ACC_CTRL.fmx 2.31
ORI_STATS.fmx 2.14
256474_CREATE_TABLE_ADM_USER_PROFILE.sql 1.1
256471_ALTER_TABLES 1.1
TRIPSUM.fmx 2.127
TRIP_PLAN.fmx 1.34

'''249378 (PA-7DDFH9) Data Export for EFX Interface'''
INT_MSG.sql 1.47
TRIPSUM.fmx 2.118
TRIP_PLAN.fmx 1.25
DATA_ADM_SYSTEM_PARAM_249378.sql 1.1

'''246306 (NW-7BCMAT) Booking EDI to incl Customer'''
INT_ERROR.fmx 1.27
STATIC_DATA_MAINT.fmx 1.6
246306.sql 1.1
BOOKINGS.fmx 2.18

'''247174 (NW-7CHEWZ) Add Weight and Spec Inst to Booking Import'''
BOOKINGS.fmx 2.19
INT_ERROR.fmx 1.27
LOCATION.fmx 2.48
IMP ???

'''252344 (PA-7DJLS6) Set Parameters for Trip Status change'''
TRIPDTL.fmx 2.56
TRM.sql 2.82
DATA_ADM_SYSTEM_PARAM_252344.sql 1.1

'''249771 (AS-765E9J) Fix to Owning Depot issue'''
TRM.sql 2.82
TRIP_PLAN.fmx 1.28
TRIPSUM.fmx 2.121
RTE.sql 2.3

== Developments ==

'''[[249378|256632 (PA-7KLFLE) Facility to update 1st Stop departure time''']]

'''[[257584|257584 (EI-7L8HBY)RIO-Booking Msg for Kraft BIC orders''']]

'''[[256287|256287 (NW-7KGE7N) Fixed Routes to run with ZIP codes''']]

'''[[247211|247211 (SS-7B6L2V)Control Order Creation Date''']]

'''[[256637|256637 (PA-7KPHJ8)EFX Pop-Up box''']]

'''[[256471|256471 (PA-7K2BG3)Create a drop down box at log-On''']]

'''[[249378|249378 (PA-7DDFH9)Data Export for EFX Interface''']]

'''[[246306|246306 (NW-7BCMAT)Booking EDI to incl Customer''']]

'''[[247174|247174 (NW-7CHEWZ)Add Weight and Spec Inst to Booking Import''']]

'''[[252344|252344 (PA-7DJLS6)Set Parameters for Trip Status change''']]

'''[[249771 |249771 (AS-765E9J)Fix to Owning Depot issue''']]

== Additional Fixes ==

{| border="1"
!Program||Version
|-
|TRIPSUM.fmx||2.123
|-
|TRIP_PLAN.fmx||1.3
|-
|TRIP_OVERVIEW.fmx||1.1
|-
|TRIPSUM.fmx||2.128
|-
|[[TRIP_PLAN]].fmx||1.35
|-
|[[TRIP_OVERVIEW]].fmx||1.11
|-
|INT_MSG.sql||1.48
|-
|GEO.sql||2.34
|-
|IMP.sql||2.68
|-
|STATIC_DATA_MAINT.fmx||1.7
|-
|Geography.fmx||2.11
|-
|Locations.fmx||2.53
|-
|AT_GEO_PLAN_REGION_256287.sql||1.1
|-
|CT_GEO_COUNTRY_POSTCODE_256287.sql||1.1
|-
|ORDERS.fmx||2.104
|-
|BOOKINGS.fmx||2.2
|-
|ORDTEMPL.fmx||2.39
|-
|TRIPSUM.fmx||2.125
|-
|TRIP_PLAN.fmx||1.32
|-
|IMP.sql||2.67
|-
|TRIPSUM.fmx||2.126
|-
|TRIP_PLAN.fmx||1.33
|-
|DATA_ADM_FUNCTION_256637.sql||1.1
|-
|ADM.sql||2.14
|-
|ACC_CTRL.fmx||2.31
|-
|ORI_STATS.fmx||2.14
|-
|256474_CREATE_TABLE_ADM_USER_PROFILE.sql||1.1
|-
|TRIPSUM.fmx||2.128
|-
|[[TRIP_PLAN]].fmx||1.35
|-
|[[TRIP_OVERVIEW]].fmx||1.11
|-
|INT_MSG.sql||1.48
|-
|GEO.sql||2.34
|-
|IMP.sql||2.68
|-
|STATIC_DATA_MAINT.fmx||1.7
|-
|Geography.fmx||2.11
|-
|Locations.fmx||2.53
|-
|AT_GEO_PLAN_REGION_256287.sql||1.1
|-
|CT_GEO_COUNTRY_POSTCODE_256287.sql||1.1
|-
|ORDERS.fmx||2.104
|-
|BOOKINGS.fmx||2.2
|-
|ORDTEMPL.fmx||2.39
|-
|TRIPSUM.fmx||2.125
|-
|TRIP_PLAN.fmx||1.32
|-
|IMP.sql||2.67
|-
|TRIPSUM.fmx||2.126
|-
|TRIP_PLAN.fmx||1.33
|-
|DATA_ADM_FUNCTION_256637.sql||1.1
|-
|ADM.sql||2.14
|}

HCRPRD Release - 16/01/2009

2009-02-05T13:39:55Z

Kingj: /* Developments */

HCRPRD Release - 16/01/2009

2009-02-05T13:39:29Z

Kingj: /* Developments */

HCRPRD Release - 16/01/2009

2009-02-05T13:24:48Z

Kingj: /* Developments */

HCRPRD Release - 16/01/2009

2009-02-05T13:21:19Z

Kingj: /* Requested Developments */

249804

2009-02-05T11:37:13Z

Kingj:

= 249804 PA-7DJDPE Amend Debrief Screen - TRIPDTL v2.54 =

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
Amend Debrief Screen - TRIPDTL v2.54 - Reduce level of input, but retain ability to change by exception

Default into Order Debrief Screen.
When accessed from amended OVERVIEW v1.6(Waterfall) screen, open Trip highlighted in waterfall screen.
Pre populate 'Actual' times, 'Actual Weight' and 'Actual Volume' from 'Planned' where appropriate.
Move 'Set Status' button to more prominent position on Right hand side.
Widen or amend font of POD column to allow 'POD' label to be visible when highlighted.
Add Message on screen to 'Change Actual values if incorrect'
Allow multiple selection of orders for POD confirmation.

== Solution ==
When the Trip Debrief (TRIPDTL) screen is opened, whether from the Main Menu or when called from another screen, it will always default into the ‘Order Debrief’ tab, instead of the current ‘General’ tab.

The ‘Set Status’ button and associated Status drop down list will be moved to the right hand side of the screen, so it is more prominent. The 2 buttons originally next to ‘Set Status’ will be aligned on the left hand side; these include ‘Add Order’ and ‘Calc Time’.

When the ‘Debrief’ button in the Waterfall (TRIP_OVERVIEW) screen is clicked, the Trip Debrief (TRIPDTL) screen will be opened and the Trip Details of the currently selected Trip will be passed in.

A new button will be placed on the TRIPDTL screen, on the left side of the Save button below the Actuals input area. It will be named ‘Set Actuals’, and when clicked will pre-populate all the Actual Arrive and Depart Times, and Save these. It will also include the functionality to allow the user to Debrief by Exception.

This is achieved through the following process:
User enters Actual Date/Times only at stops that do not match their Planned Date/Times
User clicks new ‘Set Actuals’ button and the system automatically pre-populates the other stops Actuals.

System will not pre-populate Stop Actuals if they can not be met when compared to previous stop Actuals entered manually by the user
E.g If the manually entered Actual Depart time at Stop 2 is after the Planned Arrive time at Stop 3, the system will not pre-populate Stop 3 Actuals as it is not possible to meet this Planned Arrive deadline when compared to the Actual Depart Time at Stop 2.

In the Order Debrief tab 2 new buttons will be added to allow pre-population of Actual Quantities:
• The first one will be placed directly below the ‘Actual Despatched’ input area and named ‘Set Desp’. This will pre-populate ‘Actual Despatched’, ‘Actual Weight’ and ‘Actual Volume’ for all Order Lines. This also has the Debrief by Exception functionality, where if the user manually enters Actuals for 1 order line and clicks ‘Set Desp’ all other Order Line quantities will be pre-populated, except those manually entered.
• The second button will be placed below the ‘Actual Delivered’ input area and named ‘Set Del’. This button will only pre-populate ‘Actual Delivered’ quantities, and again, it has the Debrief by Exception functionality.

‘POC’ and ‘POD’ column buttons will be amended so that the Text is visible when an Order Line is in focus.

Also in the Order Debrief tab, 2 new buttons will be placed below the current ‘POC’ and ‘POD’ columns of buttons. They will be named ‘POC All’ and ‘POD All’. They will have the same functionality as the current ‘POC’ and ‘POD’ buttons, except that instead of only applying a POC/POD to the corresponding Order Line, they will apply a POC or POD to all Order Lines in the Order Debrief tab. If some Order Lines have a POC/POD already applied, then the ‘POC All’/’POD All’ will only apply POC/POD to those that do not have a POC/POD. Please note than these 2 buttons will not include the functionality to Remove All POC/POD. This will have to be done by individual line using the current ‘POC’ or ‘POD’ buttons next to an Order Line.

The current ‘Non-Conformance’ button and ‘POD/CMR No.’ Text Box will be moved down a line to make space for the new buttons.

Finally, there will be an overall ‘Set All Actuals’ button placed on the bottom right hand side of the TRIPDTL screen. This will be used to pre-populate all Actuals with the current Planned Quantities. This is only to be used if there is no Exceptions during Debrief as it will pre-populate all Stops ‘Actual Arrive Dates/Times’ and ‘Depart Times’, all Orders ‘ Actual Despatched’, ‘Actual Delivered’, ‘Actual Weight’ and ‘Actual Volumes’ and then automatically Save all Actuals.

RIO includes change request for ‘Add Message on screen to 'Change Actual values if incorrect'’, but this will not be required due to the nature of the new functionality.

== Scope ==
This change will be applied to system version 10.6 on CONTST and once approved CONPRD. This was requested by Consumer Networks, but as this is an improvement to current functionality, it will be released over time to all contracts, excluding SAR as it has its own code stream for screen TRIPDTL.

= FUNCTIONAL DESCRIPTION =

== New Functionality ==

Below is a sample screenshot of the new TRIPDTL screen display – once opened.

Changes include:
Opening with ‘Order Debrief’ tab in focus
Set status button moved right, and other buttons realigned
‘POC’ and ‘POD’ buttons amended so text on label can be read
New ‘Set Actuals’ and ‘Set All Actuals’ buttons at bottom of form
New ‘Set Desp’, ’Set Del’, ‘POC All’ and ‘POD All’ buttons on Order Debrief tab

IMAGE

This screen can also be called from the Waterfall (TRIP_OVERVIEW) screen - by clicking the ‘Debrief’ button. The screen will open on the ‘Order Debrief’ tab, and the Trip Details of the trip selected in the Overview screen will be passed in. The screen will not be in Read Only mode, so the user will be able to input Actuals

=== Process Flow for ‘Set Actuals’ button ===

Below is a sample screenshot of a trip with the Order Details and Trip Stop details displayed. User enters Actuals for 2 stops, as these are exceptions, meaning that the planned Arr/Dep times were not met.

IMAGE

Clicking the ‘Set Actuals’ button will pre-populate all other stop Actuals, except Stop 2 and Stop 6. This is because the planned arrive times can not be met when compared to the depart times on the previous stop, which the exceptions have been entered for. E.g. Stop 1 Actual Depart is at 03:30, and will not be able to meet the Planned Arrive time of 03:23 at stop 2.

The other stop Actuals (Stop 3, 4 and 7) will be pre-populated as these times can, in theory, be met - as the driver was only 7 minutes behind at stop 1 and 11 minutes behind at stop 5. It is possible for the driver to make up the time and Arr/Dep the other stops at the Planned times. Below is a sample screenshot, after the ‘Set Actuals’ button is clicked.

IMAGE

The user will now have to fill in Stop 2 and Stop 6 Actuals manually.

If the ‘Set Actuals’ button is clicked when no Exceptions have been entered, then all stop Actuals will pre-populate with the Planned times.

=== Process Flow for ‘Set Desp’ and ‘Set Del’ buttons ===

The ‘Set Desp’ and ‘Set Del’ buttons on the ‘Order Debrief’ tab will work in a similar fashion. When a user enters some despatched quantities, and clicks the ‘Set Desp’ button, all other values will be pre-populated with the Planned values.

Below is a sample screenshot of what the user has entered, and the following screenshot is an example of how the Actuals would display as - after the ‘Set Desp’ button is clicked:

IMAGE
IMAGE

The ‘Set Del’ button has the same functionality as the ‘Set Desp’, where it will populate all Delivered Actuals that have not already been entered.

=== Process Flow for ‘POC All’ and ‘POD All’ buttons ===

The ‘POC All’ and ‘POD All’ buttons will apply a POC or POD for all orders in the ‘Order Debrief’ tab. If a few orders already have a POC or POD applied, the ‘POC All’/’POD All’ will apply a POC or POD to those that do not.

Note: these buttons do not have the functionality to remove all POC/POD. This will have to be performed individually, per order, using the existing ‘POC’ or ‘POD’ button.

Below is a sample screenshot after all POC’s are applied using the ‘POC All’ button:

IMAGE

All current error trapping functionality will remain on this screen. E.g. Trying to Apply a POC when no Actual Date/Times entered will display message ‘You must specify the Actual Arrive Date’.

=== Process Flow for ‘Set All Actuals’ button ===
Finally, the button ‘Set All Actuals’ will be used to pre-populate all actual values, and perform an automatic save. This is to be used only if there have been no exceptions on Stop times, despatched quantities or delivered quantities. Below is a sample screenshot of a trip with no actual data entered - it is again followed by a screenshot displaying the trip details, if the ‘Set All Actuals’ button was clicked:

IMAGE
IMAGE

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE
== Document History ==

IMAGE

== Authorised By ==

{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

249804

2009-02-05T09:37:57Z

Kingj:

= 249804 PA-7DJDPE Amend Debrief Screen - TRIPDTL v2.54 =

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
Amend Debrief Screen - TRIPDTL v2.54 - Reduce level of input, but retain ability to change by exception

Default into Order Debrief Screen.
When accessed from amended OVERVIEW v1.6(Waterfall) screen, open Trip highlighted in waterfall screen.
Pre populate 'Actual' times, 'Actual Weight' and 'Actual Volume' from 'Planned' where appropriate.
Move 'Set Status' button to more prominent position on Right hand side.
Widen or amend font of POD column to allow 'POD' label to be visible when highlighted.
Add Message on screen to 'Change Actual values if incorrect'
Allow multiple selection of orders for POD confirmation.

== Solution ==
When the Trip Debrief (TRIPDTL) screen is opened, whether from the Main Menu or when called from another screen, it will always default into the ‘Order Debrief’ tab, instead of the current ‘General’ tab.

The ‘Set Status’ button and associated Status drop down list will be moved to the right hand side of the screen, so it is more prominent. The 2 buttons originally next to ‘Set Status’ will be aligned on the left hand side; these include ‘Add Order’ and ‘Calc Time’.

When the ‘Debrief’ button in the Waterfall (TRIP_OVERVIEW) screen is clicked, the Trip Debrief (TRIPDTL) screen will be opened and the Trip Details of the currently selected Trip will be passed in.

A new button will be placed on the TRIPDTL screen, on the left side of the Save button below the Actuals input area. It will be named ‘Set Actuals’, and when clicked will pre-populate all the Actual Arrive and Depart Times, and Save these. It will also include the functionality to allow the user to Debrief by Exception.

This is achieved through the following process:
User enters Actual Date/Times only at stops that do not match their Planned Date/Times
User clicks new ‘Set Actuals’ button and the system automatically pre-populates the other stops Actuals.

System will not pre-populate Stop Actuals if they can not be met when compared to previous stop Actuals entered manually by the user
E.g If the manually entered Actual Depart time at Stop 2 is after the Planned Arrive time at Stop 3, the system will not pre-populate Stop 3 Actuals as it is not possible to meet this Planned Arrive deadline when compared to the Actual Depart Time at Stop 2.

In the Order Debrief tab 2 new buttons will be added to allow pre-population of Actual Quantities:
• The first one will be placed directly below the ‘Actual Despatched’ input area and named ‘Set Desp’. This will pre-populate ‘Actual Despatched’, ‘Actual Weight’ and ‘Actual Volume’ for all Order Lines. This also has the Debrief by Exception functionality, where if the user manually enters Actuals for 1 order line and clicks ‘Set Desp’ all other Order Line quantities will be pre-populated, except those manually entered.
• The second button will be placed below the ‘Actual Delivered’ input area and named ‘Set Del’. This button will only pre-populate ‘Actual Delivered’ quantities, and again, it has the Debrief by Exception functionality.

‘POC’ and ‘POD’ column buttons will be amended so that the Text is visible when an Order Line is in focus.

Also in the Order Debrief tab, 2 new buttons will be placed below the current ‘POC’ and ‘POD’ columns of buttons. They will be named ‘POC All’ and ‘POD All’. They will have the same functionality as the current ‘POC’ and ‘POD’ buttons, except that instead of only applying a POC/POD to the corresponding Order Line, they will apply a POC or POD to all Order Lines in the Order Debrief tab. If some Order Lines have a POC/POD already applied, then the ‘POC All’/’POD All’ will only apply POC/POD to those that do not have a POC/POD. Please note than these 2 buttons will not include the functionality to Remove All POC/POD. This will have to be done by individual line using the current ‘POC’ or ‘POD’ buttons next to an Order Line.

The current ‘Non-Conformance’ button and ‘POD/CMR No.’ Text Box will be moved down a line to make space for the new buttons.

Finally, there will be an overall ‘Set All Actuals’ button placed on the bottom right hand side of the TRIPDTL screen. This will be used to pre-populate all Actuals with the current Planned Quantities. This is only to be used if there is no Exceptions during Debrief as it will pre-populate all Stops ‘Actual Arrive Dates/Times’ and ‘Depart Times’, all Orders ‘ Actual Despatched’, ‘Actual Delivered’, ‘Actual Weight’ and ‘Actual Volumes’ and then automatically Save all Actuals.

RIO includes change request for ‘Add Message on screen to 'Change Actual values if incorrect'’, but this will not be required due to the nature of the new functionality.

== Scope ==
This change will be applied to system version 10.6 on CONTST and once approved CONPRD. This was requested by Consumer Networks, but as this is an improvement to current functionality, it will be released over time to all contracts, excluding SAR as it has its own code stream for screen TRIPDTL.

= FUNCTIONAL DESCRIPTION =

== New Functionality ==

Below is a sample screenshot of the new TRIPDTL screen display – once opened.

Changes include:
Opening with ‘Order Debrief’ tab in focus
Set status button moved right, and other buttons realigned
‘POC’ and ‘POD’ buttons amended so text on label can be read
New ‘Set Actuals’ and ‘Set All Actuals’ buttons at bottom of form
New ‘Set Desp’, ’Set Del’, ‘POC All’ and ‘POD All’ buttons on Order Debrief tab

IMAGE

This screen can also be called from the Waterfall (TRIP_OVERVIEW) screen - by clicking the ‘Debrief’ button. The screen will open on the ‘Order Debrief’ tab, and the Trip Details of the trip selected in the Overview screen will be passed in. The screen will not be in Read Only mode, so the user will be able to input Actuals

=== Process Flow for ‘Set Actuals’ button ===

Below is a sample screenshot of a trip with the Order Details and Trip Stop details displayed. User enters Actuals for 2 stops, as these are exceptions, meaning that the planned Arr/Dep times were not met.

IMAGE

Clicking the ‘Set Actuals’ button will pre-populate all other stop Actuals, except Stop 2 and Stop 6. This is because the planned arrive times can not be met when compared to the depart times on the previous stop, which the exceptions have been entered for. E.g. Stop 1 Actual Depart is at 03:30, and will not be able to meet the Planned Arrive time of 03:23 at stop 2.

The other stop Actuals (Stop 3, 4 and 7) will be pre-populated as these times can, in theory, be met - as the driver was only 7 minutes behind at stop 1 and 11 minutes behind at stop 5. It is possible for the driver to make up the time and Arr/Dep the other stops at the Planned times. Below is a sample screenshot, after the ‘Set Actuals’ button is clicked.

IMAGE

The user will now have to fill in Stop 2 and Stop 6 Actuals manually.

If the ‘Set Actuals’ button is clicked when no Exceptions have been entered, then all stop Actuals will pre-populate with the Planned times.

=== Process Flow for ‘Set Desp’ and ‘Set Del’ buttons ===

The ‘Set Desp’ and ‘Set Del’ buttons on the ‘Order Debrief’ tab will work in a similar fashion. When a user enters some despatched quantities, and clicks the ‘Set Desp’ button, all other values will be pre-populated with the Planned values.

Below is a sample screenshot of what the user has entered, and the following screenshot is an example of how the Actuals would display as - after the ‘Set Desp’ button is clicked:

IMAGE
IMAGE

The ‘Set Del’ button has the same functionality as the ‘Set Desp’, where it will populate all Delivered Actuals that have not already been entered.

=== Process Flow for ‘POC All’ and ‘POD All’ buttons ===

The ‘POC All’ and ‘POD All’ buttons will apply a POC or POD for all orders in the ‘Order Debrief’ tab. If a few orders already have a POC or POD applied, the ‘POC All’/’POD All’ will apply a POC or POD to those that do not.

Note: these buttons do not have the functionality to remove all POC/POD. This will have to be performed individually, per order, using the existing ‘POC’ or ‘POD’ button.

Below is a sample screenshot after all POC’s are applied using the ‘POC All’ button:

IMAGE

All current error trapping functionality will remain on this screen. E.g. Trying to Apply a POC when no Actual Date/Times entered will display message ‘You must specify the Actual Arrive Date’.

=== Process Flow for ‘Set All Actuals’ button ===
Finally, the button ‘Set All Actuals’ will be used to pre-populate all actual values, and perform an automatic save. This is to be used only if there have been no exceptions on Stop times, despatched quantities or delivered quantities. Below is a sample screenshot of a trip with no actual data entered - it is again followed by a screenshot displaying the trip details, if the ‘Set All Actuals’ button was clicked:

IMAGE
IMAGE

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==

{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

251628

2009-02-05T09:37:22Z

Kingj:

= '''251628 PA-7FZBNZ Amend Order Tracking Screen''' =

'''Copyright OBS Logistics © 2007'''

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==

Amend ORDER TRACKING screen TRACKING V2.55 - add to search facility.

Add to Search drop Down Box - [CUSTOMER] & [OMS REF] and associated searches

Added by NW - 27/06/08: The OMS Ref can be added to the existing search drop down. The Customer search should be added as a filter rather than a search and added to the form above the current Carrier filter. This is because the Customer is static data whereas the references are not taken from a list.

== Solution ==

After investigation into the different searches available in the search drop down list, there is no need to add OMS REF to the existing search drop down, as this functionality is currently there in the form of the ‘Order Ref’ search item. Inputting an OMS REF into the editable text box and selecting Order Ref in the search drop down allows the user to search by OMS REF. Suggest changing the text of ‘Order Ref’ to ‘OMS Ref’ in the Search Drop Down List of the TRACKING screen to avoid any confusion.

Below shows what each item in the Search List corresponds to in relation to an Order or a Trip:
Order Ref  OMS Ref (of an Order)
Trip Reference  Bill of Lading (of a Trip)
Customer Ref  External Ref (of an Order)
Carrier Ref  Carrier Ref (of a Trip)
Bill of Lading (Order)  Bill of Lading (of an Order)
Container No (Order)  Container No (of an Order)
Container No (Trip)  Container No (of a Trip)
Booking Ref  Booking Ref (of an Order)

We will also include a search by ‘Order ID’ (e.g. EX__S934037) in this drop down so that the available search options are in line with the search options available in the Trip Debrief (TRIPDTL) screen.

Add filter to TRACKING screen just above current Carrier filter to allow users to filter by Customer. The drop down list will display a list of Customers in a lookup table. The list of Customers in the lookup table will also be filtered according to the current users CUSTOMER and CUST_GROUP parameters set up in the Access Control screen.
Refreshing the screen after a Customer is selected in this filter, will only show trips in the lower part of the screen for the customer referenced in the filter.

== Scope ==

This change will be applied to system version 10.6 on CONTST and once approved CONPRD. The nature of this change does not impact on the current functionality of the screen and therefore makes it applicable to all MTS environments.

= FUNCTIONAL DESCRIPTION =

== New Functionality ==

The screenshot below shows the current Search drop down list in the TRACKINGS screen and those search items currently available:

IMAGE

The new drop down list will display the item ‘OMS Ref’ instead of ‘Order Ref, it is OMS Ref that is searched on when the Order Ref is selected. Changing the text to ‘OMS Ref’ will avoid any confusion.

The new Search list will also include a search by ‘Order Id’ - this will bring the list of search options into line with the search options currently available on the TRIPDTL screen. An example Order Id is EX__S934037.

Below is a screenshot sample of what the Search List will display (including these two changes):

IMAGE

Below is a screenshot displaying the top section of the current TRACKING screen that holds the search and filter information:

IMAGE

After the addition of the ‘Customer Filter’, above the current Carrier Filter, the TRACKING screen will display as follows:

IMAGE

The fields ‘From Date’ and ‘To Date’ will require moving slightly to the right to allow space for the new Customer filter on the screen.

== Procedure for Customer Filter ==

Create a new Item on Data Block TRACKING_CTRL called CUSTOMER_ID with an associated Customer Lookup. The CUSTOMER_ID will reference an LOV. The LOV will set up the list of Customers available in the Lookup table, depending on the parameters CUST and CUST_GROUP, set up in Access Control for the current user using the TRACKING screen.

Below is a preliminary example of the procedure that will need to be constructed within the POP_LISTS Program Unit to set up the Customer List:

PROCEDURE Customer_List IS
-----------------------------------------------------------------------------
-- Populate the Customer List with all available customers
-----------------------------------------------------------------------------
v_retnum NUMBER;
v_customer_string ADM_USER_PARAM_TYPE.sql_string%TYPE;
v_cust_group_string ADM_USER_PARAM_TYPE.sql_string%TYPE;
v_default VARCHAR2(2000);
v_sql_string VARCHAR2(2000);
v_no_of_params NUMBER;
v_total NUMBER;
v_query VARCHAR2( 1000 );

BEGIN
-----------------------------------------------------------------------------
MESSAGE( 'Populating Customer List...', NO_ACKNOWLEDGE );
Set_Application_Property( CURSOR_STYLE, 'BUSY' );

v_List_Grp := Find_Group( 'CUSTOMER1' );
IF NOT Id_Null( v_List_Grp ) THEN
Delete_Group( v_List_Grp );
END IF;

v_customer_string := ADM.Get_Multiple_User_Param( 'CUSTOMER', v_default, v_sql_string, v_no_of_params);

v_cust_group_string := ADM.Get_Multiple_User_Param( 'CUST_GROUP', v_default, v_sql_string, v_no_of_params);

IF v_cust_group_string = 'ALL' THEN
IF v_customer_string = 'ALL' THEN
v_List_Grp := Create_Group_From_Query( 'CUSTOMER1',
'SELECT DISTINCT customer_id, customer_name
FROM org_customer
ORDER BY 2' );
ELSE
v_List_Grp := Create_Group_From_Query( 'CUSTOMER1',
'SELECT DISTINCT customer_id, customer_name
FROM ORG_Customer
WHERE customer_id ' || v_customer_string ||
' ORDER BY 2' );
END IF;
ELSE
IF v_customer_string = 'ALL' THEN
v_List_Grp := Create_Group_From_Query( 'CUSTOMER1',
'SELECT DISTINCT customer_id, customer_name
FROM ORG_Customer
WHERE cust_group ' || v_cust_group_string ||
' ORDER BY 2' );
ELSE
v_List_Grp := Create_Group_From_Query( 'CUSTOMER1',
'SELECT DISTINCT customer_id, customer_name
FROM ORG_Customer
WHERE customer_id ' || v_customer_string ||
' AND cust_group ' || v_cust_group_string ||
' ORDER BY 2' );
END IF;
END IF;
-----------------------------------------------------------------------------
v_retcode := Populate_Group( v_List_Grp );
Set_LOV_Property( 'CUSTOMERS', GROUP_NAME, 'CUSTOMER1' );
-----------------------------------------------------------------------------

v_total := Get_Group_Row_Count(v_List_Grp);

CLEAR_MESSAGE;
Set_Application_Property( CURSOR_STYLE, 'DEFAULT' );

EXCEPTION
WHEN OTHERS THEN
Set_Application_Property( CURSOR_STYLE, 'DEFAULT' );
ADM.WRITE_MSG( 'ORD_DETAIL', 'ERROR', 'WOE populating customer list. '||SQLERRM );
MESSAGE( 'WOE populating customer list. '||SQLERRM, no_acknowledge );

END Customer_List;

Also, include in Procedure F_REFRESH_STOP_LIST the selected customer from the Filter, when the ‘Refresh’ button is clicked:

IF :TRACKING_CTRL.CUSTOMER_ID IS NOT NULL THEN
v_where_clause := v_where_clause ||
' AND Customer_id = ''' || :TRACKING_CTRL.CUSTOMER_ID || '''';
END IF;

== Update for Search By ‘Order ID’ ==

Requires an update of elements in List Items SEARCH_BY on the TRACKING_CTRL Data Block. ‘Order ID’ will need to be included and reference ORDER_ID on table SCH_ORD. Here the text of ‘Order Ref’ will also be changed to ‘OMS Ref’. Below is a screenshot of the Elements in List Property Palette after the update:

IMAGE

IMAGE

==References==
IMAGE

==Glossary==
IMAGE

==Document History==
IMAGE

==Authorised By==

{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

254565

2009-02-05T09:36:15Z

Kingj: /* QUOTE & DOCUMENT HISTORY */

=''' 254565 - PA-7JARJ4 Find Button in the Trip Overview Screen''' =

Copyright OBS Logistics © 2007

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==

1. If a Date range is specified in the Waterfall Screen FROM to DATE fields the FIND button should restrict its search to this date range. Similarly, if the Waterfall Screen has a specified Schedule date then the search invoked by the FIND button should be restricted to this Schedule date. If both date option fields are left blank then the search should be global.
Added by Suk Sandhu 11/09 - I would suggest schedule and date range be included in find pop up window, populated with data from the main form, with users able to search on that range or blank those fields for an open search.

2. The search criteria listed in the FIND drop down box do not relate to the Waterfall screen environment. HIDE all options other than: Trailer ID, Driver ID, Carrier ID, Tractor ID. When used these should retrieve the specified detail in the schedule/date range being displayed

Added by Suk Sandhu : I would suggest leaving this drop down as it is at the moment as there is likely to be a requirement form various sites to query some of the categories listed

== Solution ==
Three new fields will be added to the find pop-up on the Trip Overview screen. These will be From Date, To Date and schedule.
These fields will initially be populated with the data from the corresponding fields on the main page of the Trip overview screen. If the from and to date are populated they will be included in the criteria for the search. If the Schedule is populated this will be used.
If no values are entered for these fields, either in the main screen or in the pop-up, the search will not be restricted and will be a global search on all trips.
The Find drop down will remain unchanged at present.

== Scope ==
This change will be applied to system version 10.6 on CONTST and once approved CONPRD.

= FUNCTIONAL DESCRIPTION =

Three new fields will be added to the Find pop up screen on the Trip overview screen. These will be Schedule, From Date and To Date.

IMAGE

When the popup is first accessed the values for these fields will be defaulted from the main Trip Overview screen.
IMAGE

If the From and To date are entered the Schedule will become null, and if the schedule is entered the Date range will become null. The user will only be able to search on either the schedule or the date range.

All 3 fields can be set to NULL, which will invoke a search on all trips for the given criteria.

If the search finds multiple results, a pop up screen will be displayed showing all the results found in descending schedule order (i.e. most recent schedules first). The appropriate record can then be selected and the screen will redirect o the Schedule \ Trip chosen.

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==
IMAGE

== Authorised By ==
{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

252344

2009-02-05T09:35:46Z

Kingj:

= 252344-PA-7DJLS6 Change to Trip Status =

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
To encourage completion of data input into each trip by controlling minimal input requirement to allow Status change.

Planned to Tendered: Addition of Carrier including Own Fleet,Subcontractor or EFX/CNFX(Internal)

Tendered to Accepted: Own Fleet - Addition of Driver, Tractor ID, Trailer ID, Subcontracted - Confirmation of Carrier and Trip Cost

Accepted to EnRoute: Addition of Trip departure Time - all carriers, add in Subcontractor Driver/Vehicle/trailer - optional - Error Message on screen [Please Complete Carrier Details], Error Message on screen [Please Add Departure Details] when Status being changed to ENROUTE if departure times are incomplete.

EnRoute to Completed: Only possible in Debrief screen when Debrief details are complete. Error Message on screen [Please Confirm or Amend debrief details] if incomplete
Final Status change within Debrief screen to Confirmed.

Include the option to Configure Debrief Confirmation without POD (where appropriate) Error Message on screen where applicable [Please complete POD Confirmation] This error to be capable of being switched off where POD's are not required to change Trip status to CONFIRMED

Confirmed releases Orders for invoice and changes Forecast Values to Actual (Link to Oracle specifications pending)

Only allow status changes: PLANNED TO TENDERED, PLANNED TO ACCEPTED, TENDERED TO ACCEPTED, ACCEPTED TO EN-ROUTE,EN-ROUTE TO COMPLETED, COMPLETED TO CONFIRMED

Add additional Tab in System Parameters.

Parameter to be set at a high-level of admin rights

== Solution ==
All programs that change the trip status (Trip Planning, Trip Summary, Trip Manipulation, Trip Waterfall, Trip Debrief and EFX Acceptance edi flow) call the procedure SET_TRIP_STATUS within the TRM package.

We already have system parameters called ‘TRM_DRIVER_RQD_FOR_ENROUTE_OR_ACC’, ‘TRM_TRACTOR_RQD_FOR_ENROUTE_OR_ACC’, ‘TRM_TRAILER_RQD_FOR_ENROUTE_OR_ACC’ and ‘TRM_SET_TO_COMPLETED’.

This existing functionality will be extended in the TRM package to also check if the Carrier ID is the same as the Owning Depot (Own Fleet) for a trip. If it is Own fleet then the Driver, Tractor, Trailer will error when changing status to EN-ROUTE and no errors will be displayed when moving to status ACCEPTED or for trips being done by sub-contractors.

NB) The trailer validation currently checks all stops for a trip but this will be changed to only check the first stop which will probably be the SU stop and at the same time it will check that the actual departure time is set for this first stop when moving up to EN-ROUTE status.

Additional validation will also be added to the EN-ROUTE status check to ensure that the Carrier ID is populated.

Additional validation will be added to the COMPLETE status check to ensure that all of the debrief fields have been populated.

The check for the POC/POD flags when setting to COMPLETED status which already uses the TRM_SET_TO_COMPLETED system parameter when set to 'POC/POD' will be extended to return an error message if POC/POD flags are not set. The trip debrief form will then either display the returned error message as an error or a warning depending on whether the call failed or not.

== Scope ==
This change will be applied to system version MTS V10.6.0 for Consumer.

= FUNCTIONAL DESCRIPTION =

== TRM Package ==
Already within the TRM package there is a procedure called SET_TRIP_STATUS that is used by everything in the system to validate and perform any requests to change the status of a trip.

This code will be amended to add the new required functionality depending on a new system parameter called ‘TRM_NEW_TRIP_STATUS_CHECKS’.

Moving a trip on from status ‘PLANNED’ to status ‘TENDERED’ already has all of the required code (Carrier ID check) so does not need any changes.

‘TENDERED’/’PLANNED’ to ‘ACCEPTED’ already uses 3 system parameters called ‘TRM_DRIVER_RQD_FOR_ENROUTE_OR_ACC’,
‘TRM_TRACTOR_RQD_FOR_ENROUTE_OR_ACC’ and
‘TRM_TRAILER_RQD_FOR_ENROUTE_OR_ACC’.

These are used to determine if each of those resources is required to have been entered in order to move the trip status on the ACCEPTED from either TENDERED or PLANNED.

If the new system parameter TRM_NEW_TRIP_STATUS_CHECKS is set to ‘Y’ then this code can be totally ignored when moving to ACCEPTED status as the resources are no longer required to have be entered until the EN-ROUTE stage.

‘ACCEPTED’/’PLANNED’ to ‘EN-ROUTE’ is coded in exactly the same way as when moving to status ACCEPTED.

This will be extended to check to see if the Owning Depot for the Trip matches the Carrier ID for the trip. If they match then the trip is considered to be being done by DHL’s own fleet rather than an external sub-contractor.

NB) If somehow one of these fields has not been set than an appropriate error message will be returned as these 2 fields should have been set at trip creation stage.

If the TRM_NEW_TRIP_STATUS_CHECKS is set to ‘Y’ and the trip is being done by a sub-contractor then there is now no need to check the resources (regardless of the resource system parameters) as the resources are now only required to be entered for own fleet trips.

If the trip is being done by DHL’s own fleet and the appropriate system parameters are set then the corresponding resource must have been entered before allowing the status to be updated otherwise an error is returned to the calling program.

When the driver (SCH_TRIP.DRIVER_ID) has not been entered for an Own Fleet trip and the TRM_DRIVER_RQD_FOR_ENROUTE_OR_ACC flag is set to ‘Y’ then the following error will be returned :-

‘Can not change the trip to status EN-ROUTE as the Driver ID is required for Own Fleet trips’.

When the tractor (SCH_TRIP.TRACTOR_ID) has not been entered for an Own Fleet trip and the TRM_TRACTOR_RQD_FOR_ENROUTE_OR_ACC flag is ‘Y’ then the following error will be returned :-

‘Can not change the trip to status EN-ROUTE as the Tractor ID is required for Own Fleet trips’.
The trailer ID is entered at trip stop level not at the trip level so the code will need to check the first stop (usually the ‘Start Up’ stop) to see if a Trailer ID (SCH_TRIP_STOP.TRAILER_ID) has been entered and if not when the TRM_TRAILER_RQD_FOR_ENROUTE_OR_ACC is set to ‘Y’ then the message can say :-

‘Can not change the trip to status EN-ROUTE as the Trailer ID is required for Own Fleet trips’.

Also additional code will be added to ensure that the first stop also has an actual departure time (SCH_TRIP_STOP.ACTUAL_DEPART). If it does not and the TRM_NEW_TRIP_STATUS_CHECKS is set to ‘Y’ then return the error :-

‘Can not change the trip to status EN-ROUTE until the departure time from the first stop has been entered’.

NB) This last error applies to both Own fleet and Subcontractor trips.

’EN-ROUTE’ to ‘COMPLETED’ can only be done once all of the actual date/times have been entered in the debrief screen.

If the TRM_NEW_TRIP_STATUS_CHECKS flag is set to ‘Y’ then check all of the trip stops and ensure that they all have an actual arrival (SCH_TRIP.ACTUAL_ARRIVE) and departure (SCH_TRIP.ACTUAL_DEPART) date/times set. If not then error with :-

‘Can not change this trip to status COMPLETED until all of the actual arrival and departure date/times have been entered’.

‘COMPLETED’ to ‘CONFIRMED’ already has code to check the ‘TRM_SET_TO_COMPLETED’ system parameter.

If this parameter is set to ‘POC/POD’ then the code already ensures that all POC and POD flags have been set for all orders on the trip before allowing the trip to be moved to CONFIRMED status.

The only code change required is to return a error message (not an actual error) when all of the POC/POD flags are not set regardless of the system parameter in order for the Trip Debrief Screen to give a warning to the user that not all POC/POD flags are set.

== Trip Debrief Form ==

An error message may be returned by the TRM.SET_TRIP_STATUS even though the call to the package was successful.

If this occurs then the message should be displayed as a warning in order to inform the user that they are setting the trip to status ‘COMPLETED’ without having ticked all of the POC/POD flags for all of the orders on the trip.

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==
{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

252217

2009-02-05T09:35:13Z

Kingj:

= 252217 PA-7DWATD Amend Allocate Resource Screen =

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
Re-design the 'Allocate Resource' screen 'TRIP_RES v1.4’ to enable all resource Driver/Tractor/Trailer to be allocated to a trip in the same screen, invoked from the ‘Trip Overview (Waterfall)’ screen pre-populated with Trip details for the Trip highlighted in the ‘Trip Overview (Waterfall)’ screen - Schedule, Trip ID, Status fields, & Driver, Tractor, Trailer fields if any one already resourced.

Pre-populate the listings with Location-based Drivers and Tractors (poplist) and Trailer numbers bound by Trailer Type selected when the Trip was planned.

Add an 'Allocated' field (Tick-Box) alongside each resource to show, as a prompt only, that a resource has already been used. For example, if one user has allocated a driver to a trip that will take him less than a full shift, if this driver is marked as 'allocated' another user would not then additionally allocate him to an 8 hour shift, but it would leave the driver available for a short run on return from his first load. Similarly Tractors and Trailers can be used several times within a schedule but users would be aware if they were already committed to another trip.

Added by PA - Check current functionality of Driver/Tractor being displayed in 'Bold' if allocated - if the function is the same as expected from an ‘Allocated’ field then delete addition of ‘Allocated’ field (tick-box).

Allow Status change to ‘TENDERED’ or ‘ACCEPTED’ only, with or without any resource added as the eventual resource is not always known until the point of departure. The status change control will not allow the trip to be moved to an ‘En-Route’ status without complete resource entry.

== Solution ==
The ‘HEADER’ section of the ‘ALLOCATE RESOURCE’ screen will be changed to include the ‘Carrier Id’ and ‘Trailer Type’ of the ‘Trip Id’ should any have been assigned. It will be possible to change the ‘Trailer Type’ of the ‘Trip Id’ in this screen if a ‘Trailer Id’ has not been assigned: this will enable the user to find the ‘Trailer Id’ required if it is for a different ‘Trailer Type’.

The ‘ALLOCATE RESOURCE’ screen will also be changed so that the ‘Id’, ‘Surname’, ‘Forename’ (i.e. ‘Driver’ details) and ‘Tractor Id’ columns are pre-populated upon entry to the screen with valid records for the ‘Carrier Id’ of the ‘Trip Id’. However, the ‘Driver’ details displayed will also include those drivers with a job title of ‘CONTRACT’ as well as ‘DRIVER’. If the ‘Carrier Id’ does not have any drivers assigned to it then none will be displayed for selection.

Likewise, the ‘Trailer Id’ will be pre-populated with valid records for the ‘Trailer Type’ of the first stop of the ‘Trip Id’ should one have been set, however, if one has not been set then all ‘Trailer Ids’ will be displayed for selection. The ‘Trailer Id’ will be further validated for the ‘Carrier Group’ of the ‘Carrier Id’ set. If a ‘Trailer Id’ is then selected it will be assigned to the first stop of the trip; this is because only the ‘Trailer Id’ of the first stop of the trip is displayed in the screen.

The pre-population and maintenance of the resources for the trip will follow the functionality of the ‘poplist’ display type of the ‘Carrier Id’ regardless of whether it is set to be ‘freetext’; this means that the resources may only be selected from the details displayed and none may be entered as ‘freetext’.

It will be ensured that all details for the selection of resources are not marked as inactive.
If the ‘Driver Id’ (i.e. ‘Surname’ and ‘Forename’), ‘Tractor Id’ and ‘Trailer Id’ are assigned to a ‘Trip Id’ for the ‘Schedule’ that is concurrent with the ‘Trip Id’ selected then the records will be highlighted in grey (i.e. ‘bold’) so that the users know that there is a restriction present; therefore, the layout of the screen will not be changed to include an ‘Allocated’ column.

The ‘Status’ of a ‘Trip Id’ may be progressed to ‘TENDERED’ from ‘PLANNED’ without ‘Driver Id’ (i.e. ‘Surname’ and ‘Forename’), ‘Tractor Id’ and ‘Trailer Id’ assigned but it must have a ‘Carrier ID’ and a ‘Start Time’ set.

The ‘Status’ of a ‘Trip Id’ will be changed so that it may be progressed to ‘ACCEPTED’ from ‘PLANNED’ or ‘TENDERED’ without ‘Driver Id’ (i.e. ‘Surname’ and ‘Forename’), ‘Tractor Id’ and ‘Trailer Id’ assigned but it must have a ‘Start Time’ set. Note that this new validation will be applied throughout MTS.

The ‘Status’ of a ‘Trip Id’ may be progressed to ‘EN-ROUTE’ from ‘PLANNED’ or ‘ACCEPTED’ but not without ‘Driver Id’ (i.e. ‘Surname’ and ‘Forename’), ‘Tractor Id’ and ‘Trailer Id’ assigned, therefore the validation for the progression to ‘ACCEPTED’ may be removed.

== Scope ==
This change will be applied to system version 10.6 on CONTST and once approved CONPRD. This form will be applicable to all MTS environments, as the nature of this change is an addition to functionality and will reduce input time.

= FUNCTIONAL DESCRIPTION =

== New Functionality ==
Below is a screenshot of what the current TRIP_RES screen looks like. All data has been cleared out:

IMAGE

This screen will be made longer so that ‘Carrier Id’ and ‘Trailer Type’ can be included in the header section. When the screen is opened from the TRIP_OVERVIEW screen, the details for the selected trip will be passed in, and these fields will be populated if they have been assigned.

The newly added ‘Trailer Type’ in the header will have a lookup button next to it that will show a list of all trailer types, when clicked. This will only be active if a Trailer ID has not already been assigned to the Trip. This allows the possibility of changing the trailer type if the trailer id they require does not appear in the ‘Trailer Id’ column for assigning.

The Driver (Id, Surname, Forename) and Tractor data will be pre-populated upon entry to this screen. The data displayed here corresponds to data associated with the Carrier Id assigned to the Trip. Drivers and Tractors can be associated with a Carrier Id within the Maintenance > Resources screen. Currently only Drivers with a Job Title of DRIVER are displayed, but this will be amended to also include Drivers with a Job Title of CONTRACT.

If the Amend Resources screen is opened and the Carrier Id of the selected trip has no Drivers or Tractors assigned to their carrier, then the lists will be empty and the user will not be able to assign a Driver or Tractor in this screen.

Likewise, the Trailer Id list will be pre-populated with those associated to the Trailer Type assigned to the first stop of the trip. If the trip has no Trailer Type set, then all Trailer Ids will be displayed in the list for selection. This list can be filtered using the new lookup button next to the Trailer Type in the header. Selecting a particular Trailer Type will amend the list so that it only displays Trailers associated to the selected Trailer Type. If the user assigns a Trailer to the trip without making use of the Trailer Type lookup button then, when a Save is invoked, the Trailer Type in the header will be updated according to the selected Trailer. The list of Trailers displayed for selection is also further validated according to the Carrier Group of the Carrier Id for the trip. The select Trailer Id will be assigned to the first stop of the trip.

Also note that for population of data in all lists in the Amend Resources screen, only data that is active will be displayed. The Maintenance > Resources screen can be referenced to see how all data is associated.

Resources can only be added through selection from the pop-lists. It will not be possible to assign resources in this screen using free-text.

Below is an example of the layout of what the new screen should look like:

IMAGE

If the Driver (Id, Surname, Forename, Tractor and Trailer are assigned to a Trip for the Schedule that is concurrent with the schedule of the trip selected, then these records will be highlighted in grey with bold text, so that it is evident to the user’s, those resources that have a restriction.

Below is what the screen should look like:
Note that the lookup button next to the Trailer Type is inactive as the trip already has a Trailer assigned.

IMAGE

'''PLEASE NOTE – all Trip Status changes in screen TRIP_RES will done in accordance with the conditions set out in RIO PA-7DJLS6 (252344 Set Parameter for Trip Status change).'''

== Code Additions and Amendments ==
The addition of the new ‘Trailer Type’ lookup requires a new button to be added to the TRIP_RES screen. When this is clicked it will call a newly created LOV named TRAILER_TYPE. This LOV will contain the following query:

SELECT rt.trailer_type, rt.description
FROM res_trailer_type rt
WHERE rt.inactive != ‘Y’
ORDER BY rt.trailer_type;

This will open a lookup table of all active trailer types.

When a ‘Trailer Type’ is selected this will list all associated active ‘Trailer Id’s’ in the list for selection.
The following query will be used on the Trailer Data Block to filter the list of Trailer Id’s shown according to the Trailer Type selected in the header:

SELECT rt.trailer_id
FROM res_trailer rt
WHERE (NVL(rt.inactive. ‘N’) <> ‘Y’)
AND rt.trailer_type = :SCH_TRIP_STOP.trailer_type
AND EXISTS
(
SELECT 1
FROM res_trailer_carrier_group g,
WHERE g.trailer_id = rt.trailer_id
AND (NVL(g.inactive. ‘N’) <> ‘Y’)
AND g.name = (SELECT rc.group_name
FROM res_carrier rc
WHERE rc.carrier_id = :SCH_TRIP.carrier_id)
)
ORDER BY rt.trailer_id

The list of Drivers currently displayed for selection in TRIP_RES, is those associated with the current Carrier and with a job title of DRIVER. This will be updated to also include Drivers with a job title of CONTRACT, and also will not include those that have been set as inactive. The sql select statement required to display this will be:

SELECT p.id, p.surname, p.forename
FROM res_person p
WHERE UPPER( p.job_title ) = 'DRIVER'
OR UPPER( p.job_title ) = 'CONTRACT'
AND (NVL(p.inactive. ‘N’) <> ‘Y’)
AND EXISTS
(
SELECT 1
FROM res_person_carrier pc
WHERE p.id = pc.id
AND pc.carrier_id = :SCH_TRIP.carrier_id
)
ORDER BY p.surname, p.forename

== Trigger Updates ==
The following triggers will be applied to Data Block Trailer:

PRE-QUERY - will create a string of trailer ids that are currently in use between the currently selected trip start time and trip end time
POST-QUERY - will highlight in grey and bold those trailer ids that appear in the string created during pre-query.

This will then bring to the user’s attention those trailer ids that are in use between the selected trip start and end time and therefore have restrictions on them.

The code for the PRE-QUERY trigger will take the following form:

DECLARE

CURSOR c_alloc_trailers IS
SELECT trailer_id
FROM sch_trip
WHERE trailer_id IS NOT NULL
AND start_time BETWEEN :sch_trip.start_time AND :sch_trip.finish_time
OR ( start_time + ( elapsed_time / 1440 ) )
BETWEEN :sch_trip.start_time AND :sch_trip.finish_time;

BEGIN

:ctrl.tractor_str := NULL;

FOR cr_alloc_tractors IN c_alloc_tractors LOOP
:ctrl.tractor_str := :ctrl.tractor_str || '/' || cr_alloc_tractors.tractor_id;
END LOOP;

:ctrl.tractor_str := :ctrl.tractor_str || '/';

END;

The code for the POST-QUERY trigger will take the following form:

DECLARE

BEGIN
IF INSTR( :ctrl.tractor_str, :tractor.tractor_id || '/' ) > 0 THEN

SET_ITEM_INSTANCE_PROPERTY( 'TRAILER.TRAILER_ID', CURRENT_RECORD, VISUAL_ATTRIBUTE, 'ALLOCATED' );

END IF;
END;

Where VISUAL_ATTRIBUTE of type ALLOCATED it set to display the current record in bold with a grey background as described below:

IMAGE

== References ==

IMAGE
== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==
{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

255572

2009-02-05T09:34:18Z

Kingj: /* QUOTE & DOCUMENT HISTORY */

= 255572-PA-7JUG5V ADD Trip id barcode to TripSheet =

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
1: Add Code 39 (3 of 9) Barcode to CN Trip Sheet (MTS Modules/Reports/CN Trip Sheet) of Trip ID (MAN-00XXXXXX) to enable this to be read and decoded by the LOTS system scanner.Suggest position to the right of Report header, approx 4cm x 1cm.

2: CN Trip Sheet pdf Report (MTS Modules/Reports/CN Trip Sheet) change [Booking Window] to [Booked Time] and amend field link to read respective field in MTS ie [Late_Del] (time only)

Added by SS - Barcode should only hold trip no eg MAN-123456.
A new trip sheet containing barcode should be created this report should be based on CN Trip Sheet report. However the new report should contain the barcode in the top right corner of the report. Version number and time of report will need to be relocated.

== Solution ==

A new version of TRIP_SHEET.RDF will be created called TRIP_SHEET_BAR.RDF

Add BARCODE

The barcode will be displayed at the top of the report , to print this is the margin will cause a conflict in Oracle reports as the trip-id is being displayed in detail of the report, this conflict will have to be resolved to print the barcode in the desired place. A brief description of the required steps is listed below:

• Create a function to read in data and return the data in barcode 39 format. This function will be stored on the database.
• Download the BARCODE 39 font
• In the report, create a formula column CF_TRIP_BARCODE. The formula of this column will run the BARCODE function, reading in TRIP_ID as the data source.
• The barcode 39 data will be returned into a data field F_TRIP_BAR_CODE which will be displayed in the margin of the report. The source of F_TRIP_BAR_CODE will be the formula column CF_TRIP_BARCODE. This field will be assigned the barcode font -IDAutomationHC39M.

Amend Booking Window

Within the trip stop detail, the Booking Window will be amended to display Booked Time, and the time part of the late delivery field will be displayed under the Booked Time heading.

• Add LATE_DEL from SCH_ORD to the data model, SCH_ORD is already a data source so the relevant where statements exist.
• Change the Boiler Plate text from ‘Booking Window’ to ‘Booked Time’ and create a data field sourced by LATE_DEL., this will be displayed in the TRIP STOP repeating frame.

== Scope ==
This change will be applied to system version 10.5 on CONTST and once approved CONPRD.

= FUNCTIONAL DESCRIPTION =
This RIO can be split into the following tasks

== Display the TRIP_ID as a BARCODE ==

The format of this BARCODE must support code 39. For the barcode to be displayed on the report the following steps must be completed:

Down load a version of BARCODE 39 font for use in the report
Create a function which will read in the TRIP_ID and output a format which can be read by the BARCODE font. Function BARCODE_39 will be created in the database.

Use a Formula field in Oracle reports to run the barcode function, the formula field will be created with the following properties and will call the function BARCODE_39 and apply it to trip_id.

NAME CF_TRIP_BARCODE
PL/SQL RETURN BARCODE_39(|| :TRIP_ID ||);

Create a data field which will be sourced by the formula field. Both the data field and formula fields must be set up as char. The formula field will specifically have the following properties

Name F_TRIP_BARCODE
Source CF_TRIP_BARCODE
Type CHAR
Length 22
Font IDAutomationHC39M

We must ensure that the report will compile on the development, test and production servers. This may require the new BARCODE font to be loaded onto the different servers.

== Displaying the BARCODE in the requested place. ==

The requirements have requested that the barcode is displayed in the margin of the report. Margins should only be used for displaying static text like headings or parameter values but the nature of the report is that trip id will change for each record.

The easiest way to display the trip bar code and keep the existing report format is to leave the margin as it is and move the data currently displayed within the Trip Detail section to create space at the top of the Trip Detail section for the trip_id. This will mean that the trip bar code is displayed slightly lower in the report than originally requested, but the report will retain all existing formatting surrounding page set up and margin display.

The report displayed below is a sample of the positioning of the bar code in the report. The black block is where the bar code will appear,

IMAGE

== Changes to the Booking Window ==

The late delivery field has already been formatted to display the time only within the data model.
The trip stop data is formatted depending on the trip stop type – SU or non SU.
This has been done to ensure that the SU trip stop always appears first in the report. Currently within the report the only order information which is displayed against the SU stop is total weight. Following this formatting, we will be displaying late del for non SU stops only.
A conditional formatting trigger will ensure that the late del time is not displayed for SU trip stop records.

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==
{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

250391

2009-02-05T09:33:57Z

Kingj:

= 250391-PA-7DGNZZ Remove Case Sensitive Searches =

Copyright OBS Logistics © 2007

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
Searches being carried out in Maintenance/Locations, are case sensitive in all fields, meaning that a search may fail due to this when the Location does however exist in another case format. Can lead to unnecessary addition and Duplication of an existing Location ID. Added by PA: Should be applied to all fields of the LOCATIONS form which are capable of being 'searched' using the search buttons.

== Solution ==
Users will be able to query a specified field and retrieve all relevant records regardless of the case the query text has been entered in. This will be achieved by amending the property palette functionality available for each field.

The changes will be applied to the Locations form, specifically the following fields :

Location id
Location Name
Route Code
Postal Region
Planning Region

Address Line 1
Address Line 2
Address Line 3
Town
County
PostCode

== Scope ==

This change will be applied to system version MTS V10.5.0 on CONTST and once approved CONPRD. The Locations form will be updated to version 2_48

= FUNCTIONAL DESCRIPTION =
All searchable fields within the Locations screen and specifically the address tab will no longer be limited to case sensitive searches.

Entering search text in lowercase will also return Upper case matches and similarly, entering uppercase search text will also return lowercase matches.

IMAGE

The above screenshot shows the fields which will have the case sensitivity removed.

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==
{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

250391

2009-02-05T09:29:14Z

Kingj:

= 250391-PA-7DGNZZ Remove Case Sensitive Searches =

Copyright OBS Logistics © 2007

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
Searches being carried out in Maintenance/Locations, are case sensitive in all fields, meaning that a search may fail due to this when the Location does however exist in another case format. Can lead to unnecessary addition and Duplication of an existing Location ID. Added by PA: Should be applied to all fields of the LOCATIONS form which are capable of being 'searched' using the search buttons.

== Solution ==
Users will be able to query a specified field and retrieve all relevant records regardless of the case the query text has been entered in. This will be achieved by amending the property palette functionality available for each field.

The changes will be applied to the Locations form, specifically the following fields :

Location id
Location Name
Route Code
Postal Region
Planning Region

Address Line 1
Address Line 2
Address Line 3
Town
County
PostCode

== Scope ==

This change will be applied to system version MTS V10.5.0 on CONTST and once approved CONPRD. The Locations form will be updated to version 2_48

= FUNCTIONAL DESCRIPTION =
All searchable fields within the Locations screen and specifically the address tab will no longer be limited to case sensitive searches.

Entering search text in lowercase will also return Upper case matches and similarly, entering uppercase search text will also return lowercase matches.

IMAGE

The above screenshot shows the fields which will have the case sensitivity removed.

= QUOTE & DOCUMENT HISTORY =

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==
{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

255572

2009-02-05T09:27:44Z

Kingj:

= 255572-PA-7JUG5V ADD Trip id barcode to TripSheet =

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
1: Add Code 39 (3 of 9) Barcode to CN Trip Sheet (MTS Modules/Reports/CN Trip Sheet) of Trip ID (MAN-00XXXXXX) to enable this to be read and decoded by the LOTS system scanner.Suggest position to the right of Report header, approx 4cm x 1cm.

2: CN Trip Sheet pdf Report (MTS Modules/Reports/CN Trip Sheet) change [Booking Window] to [Booked Time] and amend field link to read respective field in MTS ie [Late_Del] (time only)

Added by SS - Barcode should only hold trip no eg MAN-123456.
A new trip sheet containing barcode should be created this report should be based on CN Trip Sheet report. However the new report should contain the barcode in the top right corner of the report. Version number and time of report will need to be relocated.

== Solution ==

A new version of TRIP_SHEET.RDF will be created called TRIP_SHEET_BAR.RDF

Add BARCODE

The barcode will be displayed at the top of the report , to print this is the margin will cause a conflict in Oracle reports as the trip-id is being displayed in detail of the report, this conflict will have to be resolved to print the barcode in the desired place. A brief description of the required steps is listed below:

• Create a function to read in data and return the data in barcode 39 format. This function will be stored on the database.
• Download the BARCODE 39 font
• In the report, create a formula column CF_TRIP_BARCODE. The formula of this column will run the BARCODE function, reading in TRIP_ID as the data source.
• The barcode 39 data will be returned into a data field F_TRIP_BAR_CODE which will be displayed in the margin of the report. The source of F_TRIP_BAR_CODE will be the formula column CF_TRIP_BARCODE. This field will be assigned the barcode font -IDAutomationHC39M.

Amend Booking Window

Within the trip stop detail, the Booking Window will be amended to display Booked Time, and the time part of the late delivery field will be displayed under the Booked Time heading.

• Add LATE_DEL from SCH_ORD to the data model, SCH_ORD is already a data source so the relevant where statements exist.
• Change the Boiler Plate text from ‘Booking Window’ to ‘Booked Time’ and create a data field sourced by LATE_DEL., this will be displayed in the TRIP STOP repeating frame.

== Scope ==
This change will be applied to system version 10.5 on CONTST and once approved CONPRD.

= FUNCTIONAL DESCRIPTION =
This RIO can be split into the following tasks

== Display the TRIP_ID as a BARCODE ==

The format of this BARCODE must support code 39. For the barcode to be displayed on the report the following steps must be completed:

Down load a version of BARCODE 39 font for use in the report
Create a function which will read in the TRIP_ID and output a format which can be read by the BARCODE font. Function BARCODE_39 will be created in the database.

Use a Formula field in Oracle reports to run the barcode function, the formula field will be created with the following properties and will call the function BARCODE_39 and apply it to trip_id.

NAME CF_TRIP_BARCODE
PL/SQL RETURN BARCODE_39(|| :TRIP_ID ||);

Create a data field which will be sourced by the formula field. Both the data field and formula fields must be set up as char. The formula field will specifically have the following properties

Name F_TRIP_BARCODE
Source CF_TRIP_BARCODE
Type CHAR
Length 22
Font IDAutomationHC39M

We must ensure that the report will compile on the development, test and production servers. This may require the new BARCODE font to be loaded onto the different servers.

== Displaying the BARCODE in the requested place. ==

The requirements have requested that the barcode is displayed in the margin of the report. Margins should only be used for displaying static text like headings or parameter values but the nature of the report is that trip id will change for each record.

The easiest way to display the trip bar code and keep the existing report format is to leave the margin as it is and move the data currently displayed within the Trip Detail section to create space at the top of the Trip Detail section for the trip_id. This will mean that the trip bar code is displayed slightly lower in the report than originally requested, but the report will retain all existing formatting surrounding page set up and margin display.

The report displayed below is a sample of the positioning of the bar code in the report. The black block is where the bar code will appear,

IMAGE

== Changes to the Booking Window ==

The late delivery field has already been formatted to display the time only within the data model.
The trip stop data is formatted depending on the trip stop type – SU or non SU.
This has been done to ensure that the SU trip stop always appears first in the report. Currently within the report the only order information which is displayed against the SU stop is total weight. Following this formatting, we will be displaying late del for non SU stops only.
A conditional formatting trigger will ensure that the late del time is not displayed for SU trip stop records.

= QUOTE & DOCUMENT HISTORY =

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==
{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

252217

2009-02-05T09:26:41Z

Kingj:

= 252217 PA-7DWATD Amend Allocate Resource Screen =

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
Re-design the 'Allocate Resource' screen 'TRIP_RES v1.4’ to enable all resource Driver/Tractor/Trailer to be allocated to a trip in the same screen, invoked from the ‘Trip Overview (Waterfall)’ screen pre-populated with Trip details for the Trip highlighted in the ‘Trip Overview (Waterfall)’ screen - Schedule, Trip ID, Status fields, & Driver, Tractor, Trailer fields if any one already resourced.

Pre-populate the listings with Location-based Drivers and Tractors (poplist) and Trailer numbers bound by Trailer Type selected when the Trip was planned.

Add an 'Allocated' field (Tick-Box) alongside each resource to show, as a prompt only, that a resource has already been used. For example, if one user has allocated a driver to a trip that will take him less than a full shift, if this driver is marked as 'allocated' another user would not then additionally allocate him to an 8 hour shift, but it would leave the driver available for a short run on return from his first load. Similarly Tractors and Trailers can be used several times within a schedule but users would be aware if they were already committed to another trip.

Added by PA - Check current functionality of Driver/Tractor being displayed in 'Bold' if allocated - if the function is the same as expected from an ‘Allocated’ field then delete addition of ‘Allocated’ field (tick-box).

Allow Status change to ‘TENDERED’ or ‘ACCEPTED’ only, with or without any resource added as the eventual resource is not always known until the point of departure. The status change control will not allow the trip to be moved to an ‘En-Route’ status without complete resource entry.

== Solution ==
The ‘HEADER’ section of the ‘ALLOCATE RESOURCE’ screen will be changed to include the ‘Carrier Id’ and ‘Trailer Type’ of the ‘Trip Id’ should any have been assigned. It will be possible to change the ‘Trailer Type’ of the ‘Trip Id’ in this screen if a ‘Trailer Id’ has not been assigned: this will enable the user to find the ‘Trailer Id’ required if it is for a different ‘Trailer Type’.

The ‘ALLOCATE RESOURCE’ screen will also be changed so that the ‘Id’, ‘Surname’, ‘Forename’ (i.e. ‘Driver’ details) and ‘Tractor Id’ columns are pre-populated upon entry to the screen with valid records for the ‘Carrier Id’ of the ‘Trip Id’. However, the ‘Driver’ details displayed will also include those drivers with a job title of ‘CONTRACT’ as well as ‘DRIVER’. If the ‘Carrier Id’ does not have any drivers assigned to it then none will be displayed for selection.

Likewise, the ‘Trailer Id’ will be pre-populated with valid records for the ‘Trailer Type’ of the first stop of the ‘Trip Id’ should one have been set, however, if one has not been set then all ‘Trailer Ids’ will be displayed for selection. The ‘Trailer Id’ will be further validated for the ‘Carrier Group’ of the ‘Carrier Id’ set. If a ‘Trailer Id’ is then selected it will be assigned to the first stop of the trip; this is because only the ‘Trailer Id’ of the first stop of the trip is displayed in the screen.

The pre-population and maintenance of the resources for the trip will follow the functionality of the ‘poplist’ display type of the ‘Carrier Id’ regardless of whether it is set to be ‘freetext’; this means that the resources may only be selected from the details displayed and none may be entered as ‘freetext’.

It will be ensured that all details for the selection of resources are not marked as inactive.
If the ‘Driver Id’ (i.e. ‘Surname’ and ‘Forename’), ‘Tractor Id’ and ‘Trailer Id’ are assigned to a ‘Trip Id’ for the ‘Schedule’ that is concurrent with the ‘Trip Id’ selected then the records will be highlighted in grey (i.e. ‘bold’) so that the users know that there is a restriction present; therefore, the layout of the screen will not be changed to include an ‘Allocated’ column.

The ‘Status’ of a ‘Trip Id’ may be progressed to ‘TENDERED’ from ‘PLANNED’ without ‘Driver Id’ (i.e. ‘Surname’ and ‘Forename’), ‘Tractor Id’ and ‘Trailer Id’ assigned but it must have a ‘Carrier ID’ and a ‘Start Time’ set.

The ‘Status’ of a ‘Trip Id’ will be changed so that it may be progressed to ‘ACCEPTED’ from ‘PLANNED’ or ‘TENDERED’ without ‘Driver Id’ (i.e. ‘Surname’ and ‘Forename’), ‘Tractor Id’ and ‘Trailer Id’ assigned but it must have a ‘Start Time’ set. Note that this new validation will be applied throughout MTS.

The ‘Status’ of a ‘Trip Id’ may be progressed to ‘EN-ROUTE’ from ‘PLANNED’ or ‘ACCEPTED’ but not without ‘Driver Id’ (i.e. ‘Surname’ and ‘Forename’), ‘Tractor Id’ and ‘Trailer Id’ assigned, therefore the validation for the progression to ‘ACCEPTED’ may be removed.

== Scope ==
This change will be applied to system version 10.6 on CONTST and once approved CONPRD. This form will be applicable to all MTS environments, as the nature of this change is an addition to functionality and will reduce input time.

= FUNCTIONAL DESCRIPTION =

== New Functionality ==
Below is a screenshot of what the current TRIP_RES screen looks like. All data has been cleared out:

IMAGE

This screen will be made longer so that ‘Carrier Id’ and ‘Trailer Type’ can be included in the header section. When the screen is opened from the TRIP_OVERVIEW screen, the details for the selected trip will be passed in, and these fields will be populated if they have been assigned.

The newly added ‘Trailer Type’ in the header will have a lookup button next to it that will show a list of all trailer types, when clicked. This will only be active if a Trailer ID has not already been assigned to the Trip. This allows the possibility of changing the trailer type if the trailer id they require does not appear in the ‘Trailer Id’ column for assigning.

The Driver (Id, Surname, Forename) and Tractor data will be pre-populated upon entry to this screen. The data displayed here corresponds to data associated with the Carrier Id assigned to the Trip. Drivers and Tractors can be associated with a Carrier Id within the Maintenance > Resources screen. Currently only Drivers with a Job Title of DRIVER are displayed, but this will be amended to also include Drivers with a Job Title of CONTRACT.

If the Amend Resources screen is opened and the Carrier Id of the selected trip has no Drivers or Tractors assigned to their carrier, then the lists will be empty and the user will not be able to assign a Driver or Tractor in this screen.

Likewise, the Trailer Id list will be pre-populated with those associated to the Trailer Type assigned to the first stop of the trip. If the trip has no Trailer Type set, then all Trailer Ids will be displayed in the list for selection. This list can be filtered using the new lookup button next to the Trailer Type in the header. Selecting a particular Trailer Type will amend the list so that it only displays Trailers associated to the selected Trailer Type. If the user assigns a Trailer to the trip without making use of the Trailer Type lookup button then, when a Save is invoked, the Trailer Type in the header will be updated according to the selected Trailer. The list of Trailers displayed for selection is also further validated according to the Carrier Group of the Carrier Id for the trip. The select Trailer Id will be assigned to the first stop of the trip.

Also note that for population of data in all lists in the Amend Resources screen, only data that is active will be displayed. The Maintenance > Resources screen can be referenced to see how all data is associated.

Resources can only be added through selection from the pop-lists. It will not be possible to assign resources in this screen using free-text.

Below is an example of the layout of what the new screen should look like:

IMAGE

If the Driver (Id, Surname, Forename, Tractor and Trailer are assigned to a Trip for the Schedule that is concurrent with the schedule of the trip selected, then these records will be highlighted in grey with bold text, so that it is evident to the user’s, those resources that have a restriction.

Below is what the screen should look like:
Note that the lookup button next to the Trailer Type is inactive as the trip already has a Trailer assigned.

IMAGE

'''PLEASE NOTE – all Trip Status changes in screen TRIP_RES will done in accordance with the conditions set out in RIO PA-7DJLS6 (252344 Set Parameter for Trip Status change).'''

== Code Additions and Amendments ==
The addition of the new ‘Trailer Type’ lookup requires a new button to be added to the TRIP_RES screen. When this is clicked it will call a newly created LOV named TRAILER_TYPE. This LOV will contain the following query:

SELECT rt.trailer_type, rt.description
FROM res_trailer_type rt
WHERE rt.inactive != ‘Y’
ORDER BY rt.trailer_type;

This will open a lookup table of all active trailer types.

When a ‘Trailer Type’ is selected this will list all associated active ‘Trailer Id’s’ in the list for selection.
The following query will be used on the Trailer Data Block to filter the list of Trailer Id’s shown according to the Trailer Type selected in the header:

SELECT rt.trailer_id
FROM res_trailer rt
WHERE (NVL(rt.inactive. ‘N’) <> ‘Y’)
AND rt.trailer_type = :SCH_TRIP_STOP.trailer_type
AND EXISTS
(
SELECT 1
FROM res_trailer_carrier_group g,
WHERE g.trailer_id = rt.trailer_id
AND (NVL(g.inactive. ‘N’) <> ‘Y’)
AND g.name = (SELECT rc.group_name
FROM res_carrier rc
WHERE rc.carrier_id = :SCH_TRIP.carrier_id)
)
ORDER BY rt.trailer_id

The list of Drivers currently displayed for selection in TRIP_RES, is those associated with the current Carrier and with a job title of DRIVER. This will be updated to also include Drivers with a job title of CONTRACT, and also will not include those that have been set as inactive. The sql select statement required to display this will be:

SELECT p.id, p.surname, p.forename
FROM res_person p
WHERE UPPER( p.job_title ) = 'DRIVER'
OR UPPER( p.job_title ) = 'CONTRACT'
AND (NVL(p.inactive. ‘N’) <> ‘Y’)
AND EXISTS
(
SELECT 1
FROM res_person_carrier pc
WHERE p.id = pc.id
AND pc.carrier_id = :SCH_TRIP.carrier_id
)
ORDER BY p.surname, p.forename

== Trigger Updates ==
The following triggers will be applied to Data Block Trailer:

PRE-QUERY - will create a string of trailer ids that are currently in use between the currently selected trip start time and trip end time
POST-QUERY - will highlight in grey and bold those trailer ids that appear in the string created during pre-query.

This will then bring to the user’s attention those trailer ids that are in use between the selected trip start and end time and therefore have restrictions on them.

The code for the PRE-QUERY trigger will take the following form:

DECLARE

CURSOR c_alloc_trailers IS
SELECT trailer_id
FROM sch_trip
WHERE trailer_id IS NOT NULL
AND start_time BETWEEN :sch_trip.start_time AND :sch_trip.finish_time
OR ( start_time + ( elapsed_time / 1440 ) )
BETWEEN :sch_trip.start_time AND :sch_trip.finish_time;

BEGIN

:ctrl.tractor_str := NULL;

FOR cr_alloc_tractors IN c_alloc_tractors LOOP
:ctrl.tractor_str := :ctrl.tractor_str || '/' || cr_alloc_tractors.tractor_id;
END LOOP;

:ctrl.tractor_str := :ctrl.tractor_str || '/';

END;

The code for the POST-QUERY trigger will take the following form:

DECLARE

BEGIN
IF INSTR( :ctrl.tractor_str, :tractor.tractor_id || '/' ) > 0 THEN

SET_ITEM_INSTANCE_PROPERTY( 'TRAILER.TRAILER_ID', CURRENT_RECORD, VISUAL_ATTRIBUTE, 'ALLOCATED' );

END IF;
END;

Where VISUAL_ATTRIBUTE of type ALLOCATED it set to display the current record in bold with a grey background as described below:

IMAGE

= QUOTE & DOCUMENT HISTORY =

== References ==

IMAGE
== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==
{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

252344

2009-02-05T09:25:11Z

Kingj: /* APPENDIX B QUOTE & DOCUMENT HISTORY */

= 252344-PA-7DJLS6 Change to Trip Status =

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
To encourage completion of data input into each trip by controlling minimal input requirement to allow Status change.

Planned to Tendered: Addition of Carrier including Own Fleet,Subcontractor or EFX/CNFX(Internal)

Tendered to Accepted: Own Fleet - Addition of Driver, Tractor ID, Trailer ID, Subcontracted - Confirmation of Carrier and Trip Cost

Accepted to EnRoute: Addition of Trip departure Time - all carriers, add in Subcontractor Driver/Vehicle/trailer - optional - Error Message on screen [Please Complete Carrier Details], Error Message on screen [Please Add Departure Details] when Status being changed to ENROUTE if departure times are incomplete.

EnRoute to Completed: Only possible in Debrief screen when Debrief details are complete. Error Message on screen [Please Confirm or Amend debrief details] if incomplete
Final Status change within Debrief screen to Confirmed.

Include the option to Configure Debrief Confirmation without POD (where appropriate) Error Message on screen where applicable [Please complete POD Confirmation] This error to be capable of being switched off where POD's are not required to change Trip status to CONFIRMED

Confirmed releases Orders for invoice and changes Forecast Values to Actual (Link to Oracle specifications pending)

Only allow status changes: PLANNED TO TENDERED, PLANNED TO ACCEPTED, TENDERED TO ACCEPTED, ACCEPTED TO EN-ROUTE,EN-ROUTE TO COMPLETED, COMPLETED TO CONFIRMED

Add additional Tab in System Parameters.

Parameter to be set at a high-level of admin rights

== Solution ==
All programs that change the trip status (Trip Planning, Trip Summary, Trip Manipulation, Trip Waterfall, Trip Debrief and EFX Acceptance edi flow) call the procedure SET_TRIP_STATUS within the TRM package.

We already have system parameters called ‘TRM_DRIVER_RQD_FOR_ENROUTE_OR_ACC’, ‘TRM_TRACTOR_RQD_FOR_ENROUTE_OR_ACC’, ‘TRM_TRAILER_RQD_FOR_ENROUTE_OR_ACC’ and ‘TRM_SET_TO_COMPLETED’.

This existing functionality will be extended in the TRM package to also check if the Carrier ID is the same as the Owning Depot (Own Fleet) for a trip. If it is Own fleet then the Driver, Tractor, Trailer will error when changing status to EN-ROUTE and no errors will be displayed when moving to status ACCEPTED or for trips being done by sub-contractors.

NB) The trailer validation currently checks all stops for a trip but this will be changed to only check the first stop which will probably be the SU stop and at the same time it will check that the actual departure time is set for this first stop when moving up to EN-ROUTE status.

Additional validation will also be added to the EN-ROUTE status check to ensure that the Carrier ID is populated.

Additional validation will be added to the COMPLETE status check to ensure that all of the debrief fields have been populated.

The check for the POC/POD flags when setting to COMPLETED status which already uses the TRM_SET_TO_COMPLETED system parameter when set to 'POC/POD' will be extended to return an error message if POC/POD flags are not set. The trip debrief form will then either display the returned error message as an error or a warning depending on whether the call failed or not.

== Scope ==
This change will be applied to system version MTS V10.6.0 for Consumer.

= FUNCTIONAL DESCRIPTION =

== TRM Package ==
Already within the TRM package there is a procedure called SET_TRIP_STATUS that is used by everything in the system to validate and perform any requests to change the status of a trip.

This code will be amended to add the new required functionality depending on a new system parameter called ‘TRM_NEW_TRIP_STATUS_CHECKS’.

Moving a trip on from status ‘PLANNED’ to status ‘TENDERED’ already has all of the required code (Carrier ID check) so does not need any changes.

‘TENDERED’/’PLANNED’ to ‘ACCEPTED’ already uses 3 system parameters called ‘TRM_DRIVER_RQD_FOR_ENROUTE_OR_ACC’,
‘TRM_TRACTOR_RQD_FOR_ENROUTE_OR_ACC’ and
‘TRM_TRAILER_RQD_FOR_ENROUTE_OR_ACC’.

These are used to determine if each of those resources is required to have been entered in order to move the trip status on the ACCEPTED from either TENDERED or PLANNED.

If the new system parameter TRM_NEW_TRIP_STATUS_CHECKS is set to ‘Y’ then this code can be totally ignored when moving to ACCEPTED status as the resources are no longer required to have be entered until the EN-ROUTE stage.

‘ACCEPTED’/’PLANNED’ to ‘EN-ROUTE’ is coded in exactly the same way as when moving to status ACCEPTED.

This will be extended to check to see if the Owning Depot for the Trip matches the Carrier ID for the trip. If they match then the trip is considered to be being done by DHL’s own fleet rather than an external sub-contractor.

NB) If somehow one of these fields has not been set than an appropriate error message will be returned as these 2 fields should have been set at trip creation stage.

If the TRM_NEW_TRIP_STATUS_CHECKS is set to ‘Y’ and the trip is being done by a sub-contractor then there is now no need to check the resources (regardless of the resource system parameters) as the resources are now only required to be entered for own fleet trips.

If the trip is being done by DHL’s own fleet and the appropriate system parameters are set then the corresponding resource must have been entered before allowing the status to be updated otherwise an error is returned to the calling program.

When the driver (SCH_TRIP.DRIVER_ID) has not been entered for an Own Fleet trip and the TRM_DRIVER_RQD_FOR_ENROUTE_OR_ACC flag is set to ‘Y’ then the following error will be returned :-

‘Can not change the trip to status EN-ROUTE as the Driver ID is required for Own Fleet trips’.

When the tractor (SCH_TRIP.TRACTOR_ID) has not been entered for an Own Fleet trip and the TRM_TRACTOR_RQD_FOR_ENROUTE_OR_ACC flag is ‘Y’ then the following error will be returned :-

‘Can not change the trip to status EN-ROUTE as the Tractor ID is required for Own Fleet trips’.
The trailer ID is entered at trip stop level not at the trip level so the code will need to check the first stop (usually the ‘Start Up’ stop) to see if a Trailer ID (SCH_TRIP_STOP.TRAILER_ID) has been entered and if not when the TRM_TRAILER_RQD_FOR_ENROUTE_OR_ACC is set to ‘Y’ then the message can say :-

‘Can not change the trip to status EN-ROUTE as the Trailer ID is required for Own Fleet trips’.

Also additional code will be added to ensure that the first stop also has an actual departure time (SCH_TRIP_STOP.ACTUAL_DEPART). If it does not and the TRM_NEW_TRIP_STATUS_CHECKS is set to ‘Y’ then return the error :-

‘Can not change the trip to status EN-ROUTE until the departure time from the first stop has been entered’.

NB) This last error applies to both Own fleet and Subcontractor trips.

’EN-ROUTE’ to ‘COMPLETED’ can only be done once all of the actual date/times have been entered in the debrief screen.

If the TRM_NEW_TRIP_STATUS_CHECKS flag is set to ‘Y’ then check all of the trip stops and ensure that they all have an actual arrival (SCH_TRIP.ACTUAL_ARRIVE) and departure (SCH_TRIP.ACTUAL_DEPART) date/times set. If not then error with :-

‘Can not change this trip to status COMPLETED until all of the actual arrival and departure date/times have been entered’.

‘COMPLETED’ to ‘CONFIRMED’ already has code to check the ‘TRM_SET_TO_COMPLETED’ system parameter.

If this parameter is set to ‘POC/POD’ then the code already ensures that all POC and POD flags have been set for all orders on the trip before allowing the trip to be moved to CONFIRMED status.

The only code change required is to return a error message (not an actual error) when all of the POC/POD flags are not set regardless of the system parameter in order for the Trip Debrief Screen to give a warning to the user that not all POC/POD flags are set.

== Trip Debrief Form ==

An error message may be returned by the TRM.SET_TRIP_STATUS even though the call to the package was successful.

If this occurs then the message should be displayed as a warning in order to inform the user that they are setting the trip to status ‘COMPLETED’ without having ticked all of the POC/POD flags for all of the orders on the trip.

= QUOTE & DOCUMENT HISTORY =

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==
{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

252344

2009-02-05T09:24:56Z

Kingj: /* APPENDIX A TABLE UPDATES REQUIRED */

= 252344-PA-7DJLS6 Change to Trip Status =

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
To encourage completion of data input into each trip by controlling minimal input requirement to allow Status change.

Planned to Tendered: Addition of Carrier including Own Fleet,Subcontractor or EFX/CNFX(Internal)

Tendered to Accepted: Own Fleet - Addition of Driver, Tractor ID, Trailer ID, Subcontracted - Confirmation of Carrier and Trip Cost

Accepted to EnRoute: Addition of Trip departure Time - all carriers, add in Subcontractor Driver/Vehicle/trailer - optional - Error Message on screen [Please Complete Carrier Details], Error Message on screen [Please Add Departure Details] when Status being changed to ENROUTE if departure times are incomplete.

EnRoute to Completed: Only possible in Debrief screen when Debrief details are complete. Error Message on screen [Please Confirm or Amend debrief details] if incomplete
Final Status change within Debrief screen to Confirmed.

Include the option to Configure Debrief Confirmation without POD (where appropriate) Error Message on screen where applicable [Please complete POD Confirmation] This error to be capable of being switched off where POD's are not required to change Trip status to CONFIRMED

Confirmed releases Orders for invoice and changes Forecast Values to Actual (Link to Oracle specifications pending)

Only allow status changes: PLANNED TO TENDERED, PLANNED TO ACCEPTED, TENDERED TO ACCEPTED, ACCEPTED TO EN-ROUTE,EN-ROUTE TO COMPLETED, COMPLETED TO CONFIRMED

Add additional Tab in System Parameters.

Parameter to be set at a high-level of admin rights

== Solution ==
All programs that change the trip status (Trip Planning, Trip Summary, Trip Manipulation, Trip Waterfall, Trip Debrief and EFX Acceptance edi flow) call the procedure SET_TRIP_STATUS within the TRM package.

We already have system parameters called ‘TRM_DRIVER_RQD_FOR_ENROUTE_OR_ACC’, ‘TRM_TRACTOR_RQD_FOR_ENROUTE_OR_ACC’, ‘TRM_TRAILER_RQD_FOR_ENROUTE_OR_ACC’ and ‘TRM_SET_TO_COMPLETED’.

This existing functionality will be extended in the TRM package to also check if the Carrier ID is the same as the Owning Depot (Own Fleet) for a trip. If it is Own fleet then the Driver, Tractor, Trailer will error when changing status to EN-ROUTE and no errors will be displayed when moving to status ACCEPTED or for trips being done by sub-contractors.

NB) The trailer validation currently checks all stops for a trip but this will be changed to only check the first stop which will probably be the SU stop and at the same time it will check that the actual departure time is set for this first stop when moving up to EN-ROUTE status.

Additional validation will also be added to the EN-ROUTE status check to ensure that the Carrier ID is populated.

Additional validation will be added to the COMPLETE status check to ensure that all of the debrief fields have been populated.

The check for the POC/POD flags when setting to COMPLETED status which already uses the TRM_SET_TO_COMPLETED system parameter when set to 'POC/POD' will be extended to return an error message if POC/POD flags are not set. The trip debrief form will then either display the returned error message as an error or a warning depending on whether the call failed or not.

== Scope ==
This change will be applied to system version MTS V10.6.0 for Consumer.

= FUNCTIONAL DESCRIPTION =

== TRM Package ==
Already within the TRM package there is a procedure called SET_TRIP_STATUS that is used by everything in the system to validate and perform any requests to change the status of a trip.

This code will be amended to add the new required functionality depending on a new system parameter called ‘TRM_NEW_TRIP_STATUS_CHECKS’.

Moving a trip on from status ‘PLANNED’ to status ‘TENDERED’ already has all of the required code (Carrier ID check) so does not need any changes.

‘TENDERED’/’PLANNED’ to ‘ACCEPTED’ already uses 3 system parameters called ‘TRM_DRIVER_RQD_FOR_ENROUTE_OR_ACC’,
‘TRM_TRACTOR_RQD_FOR_ENROUTE_OR_ACC’ and
‘TRM_TRAILER_RQD_FOR_ENROUTE_OR_ACC’.

These are used to determine if each of those resources is required to have been entered in order to move the trip status on the ACCEPTED from either TENDERED or PLANNED.

If the new system parameter TRM_NEW_TRIP_STATUS_CHECKS is set to ‘Y’ then this code can be totally ignored when moving to ACCEPTED status as the resources are no longer required to have be entered until the EN-ROUTE stage.

‘ACCEPTED’/’PLANNED’ to ‘EN-ROUTE’ is coded in exactly the same way as when moving to status ACCEPTED.

This will be extended to check to see if the Owning Depot for the Trip matches the Carrier ID for the trip. If they match then the trip is considered to be being done by DHL’s own fleet rather than an external sub-contractor.

NB) If somehow one of these fields has not been set than an appropriate error message will be returned as these 2 fields should have been set at trip creation stage.

If the TRM_NEW_TRIP_STATUS_CHECKS is set to ‘Y’ and the trip is being done by a sub-contractor then there is now no need to check the resources (regardless of the resource system parameters) as the resources are now only required to be entered for own fleet trips.

If the trip is being done by DHL’s own fleet and the appropriate system parameters are set then the corresponding resource must have been entered before allowing the status to be updated otherwise an error is returned to the calling program.

When the driver (SCH_TRIP.DRIVER_ID) has not been entered for an Own Fleet trip and the TRM_DRIVER_RQD_FOR_ENROUTE_OR_ACC flag is set to ‘Y’ then the following error will be returned :-

‘Can not change the trip to status EN-ROUTE as the Driver ID is required for Own Fleet trips’.

When the tractor (SCH_TRIP.TRACTOR_ID) has not been entered for an Own Fleet trip and the TRM_TRACTOR_RQD_FOR_ENROUTE_OR_ACC flag is ‘Y’ then the following error will be returned :-

‘Can not change the trip to status EN-ROUTE as the Tractor ID is required for Own Fleet trips’.
The trailer ID is entered at trip stop level not at the trip level so the code will need to check the first stop (usually the ‘Start Up’ stop) to see if a Trailer ID (SCH_TRIP_STOP.TRAILER_ID) has been entered and if not when the TRM_TRAILER_RQD_FOR_ENROUTE_OR_ACC is set to ‘Y’ then the message can say :-

‘Can not change the trip to status EN-ROUTE as the Trailer ID is required for Own Fleet trips’.

Also additional code will be added to ensure that the first stop also has an actual departure time (SCH_TRIP_STOP.ACTUAL_DEPART). If it does not and the TRM_NEW_TRIP_STATUS_CHECKS is set to ‘Y’ then return the error :-

‘Can not change the trip to status EN-ROUTE until the departure time from the first stop has been entered’.

NB) This last error applies to both Own fleet and Subcontractor trips.

’EN-ROUTE’ to ‘COMPLETED’ can only be done once all of the actual date/times have been entered in the debrief screen.

If the TRM_NEW_TRIP_STATUS_CHECKS flag is set to ‘Y’ then check all of the trip stops and ensure that they all have an actual arrival (SCH_TRIP.ACTUAL_ARRIVE) and departure (SCH_TRIP.ACTUAL_DEPART) date/times set. If not then error with :-

‘Can not change this trip to status COMPLETED until all of the actual arrival and departure date/times have been entered’.

‘COMPLETED’ to ‘CONFIRMED’ already has code to check the ‘TRM_SET_TO_COMPLETED’ system parameter.

If this parameter is set to ‘POC/POD’ then the code already ensures that all POC and POD flags have been set for all orders on the trip before allowing the trip to be moved to CONFIRMED status.

The only code change required is to return a error message (not an actual error) when all of the POC/POD flags are not set regardless of the system parameter in order for the Trip Debrief Screen to give a warning to the user that not all POC/POD flags are set.

== Trip Debrief Form ==

An error message may be returned by the TRM.SET_TRIP_STATUS even though the call to the package was successful.

If this occurs then the message should be displayed as a warning in order to inform the user that they are setting the trip to status ‘COMPLETED’ without having ticked all of the POC/POD flags for all of the orders on the trip.

= APPENDIX B QUOTE & DOCUMENT HISTORY =

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==
{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

252344

2009-02-05T09:24:44Z

Kingj: /* SETUP */

= 252344-PA-7DJLS6 Change to Trip Status =

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
To encourage completion of data input into each trip by controlling minimal input requirement to allow Status change.

Planned to Tendered: Addition of Carrier including Own Fleet,Subcontractor or EFX/CNFX(Internal)

Tendered to Accepted: Own Fleet - Addition of Driver, Tractor ID, Trailer ID, Subcontracted - Confirmation of Carrier and Trip Cost

Accepted to EnRoute: Addition of Trip departure Time - all carriers, add in Subcontractor Driver/Vehicle/trailer - optional - Error Message on screen [Please Complete Carrier Details], Error Message on screen [Please Add Departure Details] when Status being changed to ENROUTE if departure times are incomplete.

EnRoute to Completed: Only possible in Debrief screen when Debrief details are complete. Error Message on screen [Please Confirm or Amend debrief details] if incomplete
Final Status change within Debrief screen to Confirmed.

Include the option to Configure Debrief Confirmation without POD (where appropriate) Error Message on screen where applicable [Please complete POD Confirmation] This error to be capable of being switched off where POD's are not required to change Trip status to CONFIRMED

Confirmed releases Orders for invoice and changes Forecast Values to Actual (Link to Oracle specifications pending)

Only allow status changes: PLANNED TO TENDERED, PLANNED TO ACCEPTED, TENDERED TO ACCEPTED, ACCEPTED TO EN-ROUTE,EN-ROUTE TO COMPLETED, COMPLETED TO CONFIRMED

Add additional Tab in System Parameters.

Parameter to be set at a high-level of admin rights

== Solution ==
All programs that change the trip status (Trip Planning, Trip Summary, Trip Manipulation, Trip Waterfall, Trip Debrief and EFX Acceptance edi flow) call the procedure SET_TRIP_STATUS within the TRM package.

We already have system parameters called ‘TRM_DRIVER_RQD_FOR_ENROUTE_OR_ACC’, ‘TRM_TRACTOR_RQD_FOR_ENROUTE_OR_ACC’, ‘TRM_TRAILER_RQD_FOR_ENROUTE_OR_ACC’ and ‘TRM_SET_TO_COMPLETED’.

This existing functionality will be extended in the TRM package to also check if the Carrier ID is the same as the Owning Depot (Own Fleet) for a trip. If it is Own fleet then the Driver, Tractor, Trailer will error when changing status to EN-ROUTE and no errors will be displayed when moving to status ACCEPTED or for trips being done by sub-contractors.

NB) The trailer validation currently checks all stops for a trip but this will be changed to only check the first stop which will probably be the SU stop and at the same time it will check that the actual departure time is set for this first stop when moving up to EN-ROUTE status.

Additional validation will also be added to the EN-ROUTE status check to ensure that the Carrier ID is populated.

Additional validation will be added to the COMPLETE status check to ensure that all of the debrief fields have been populated.

The check for the POC/POD flags when setting to COMPLETED status which already uses the TRM_SET_TO_COMPLETED system parameter when set to 'POC/POD' will be extended to return an error message if POC/POD flags are not set. The trip debrief form will then either display the returned error message as an error or a warning depending on whether the call failed or not.

== Scope ==
This change will be applied to system version MTS V10.6.0 for Consumer.

= FUNCTIONAL DESCRIPTION =

== TRM Package ==
Already within the TRM package there is a procedure called SET_TRIP_STATUS that is used by everything in the system to validate and perform any requests to change the status of a trip.

This code will be amended to add the new required functionality depending on a new system parameter called ‘TRM_NEW_TRIP_STATUS_CHECKS’.

Moving a trip on from status ‘PLANNED’ to status ‘TENDERED’ already has all of the required code (Carrier ID check) so does not need any changes.

‘TENDERED’/’PLANNED’ to ‘ACCEPTED’ already uses 3 system parameters called ‘TRM_DRIVER_RQD_FOR_ENROUTE_OR_ACC’,
‘TRM_TRACTOR_RQD_FOR_ENROUTE_OR_ACC’ and
‘TRM_TRAILER_RQD_FOR_ENROUTE_OR_ACC’.

These are used to determine if each of those resources is required to have been entered in order to move the trip status on the ACCEPTED from either TENDERED or PLANNED.

If the new system parameter TRM_NEW_TRIP_STATUS_CHECKS is set to ‘Y’ then this code can be totally ignored when moving to ACCEPTED status as the resources are no longer required to have be entered until the EN-ROUTE stage.

‘ACCEPTED’/’PLANNED’ to ‘EN-ROUTE’ is coded in exactly the same way as when moving to status ACCEPTED.

This will be extended to check to see if the Owning Depot for the Trip matches the Carrier ID for the trip. If they match then the trip is considered to be being done by DHL’s own fleet rather than an external sub-contractor.

NB) If somehow one of these fields has not been set than an appropriate error message will be returned as these 2 fields should have been set at trip creation stage.

If the TRM_NEW_TRIP_STATUS_CHECKS is set to ‘Y’ and the trip is being done by a sub-contractor then there is now no need to check the resources (regardless of the resource system parameters) as the resources are now only required to be entered for own fleet trips.

If the trip is being done by DHL’s own fleet and the appropriate system parameters are set then the corresponding resource must have been entered before allowing the status to be updated otherwise an error is returned to the calling program.

When the driver (SCH_TRIP.DRIVER_ID) has not been entered for an Own Fleet trip and the TRM_DRIVER_RQD_FOR_ENROUTE_OR_ACC flag is set to ‘Y’ then the following error will be returned :-

‘Can not change the trip to status EN-ROUTE as the Driver ID is required for Own Fleet trips’.

When the tractor (SCH_TRIP.TRACTOR_ID) has not been entered for an Own Fleet trip and the TRM_TRACTOR_RQD_FOR_ENROUTE_OR_ACC flag is ‘Y’ then the following error will be returned :-

‘Can not change the trip to status EN-ROUTE as the Tractor ID is required for Own Fleet trips’.
The trailer ID is entered at trip stop level not at the trip level so the code will need to check the first stop (usually the ‘Start Up’ stop) to see if a Trailer ID (SCH_TRIP_STOP.TRAILER_ID) has been entered and if not when the TRM_TRAILER_RQD_FOR_ENROUTE_OR_ACC is set to ‘Y’ then the message can say :-

‘Can not change the trip to status EN-ROUTE as the Trailer ID is required for Own Fleet trips’.

Also additional code will be added to ensure that the first stop also has an actual departure time (SCH_TRIP_STOP.ACTUAL_DEPART). If it does not and the TRM_NEW_TRIP_STATUS_CHECKS is set to ‘Y’ then return the error :-

‘Can not change the trip to status EN-ROUTE until the departure time from the first stop has been entered’.

NB) This last error applies to both Own fleet and Subcontractor trips.

’EN-ROUTE’ to ‘COMPLETED’ can only be done once all of the actual date/times have been entered in the debrief screen.

If the TRM_NEW_TRIP_STATUS_CHECKS flag is set to ‘Y’ then check all of the trip stops and ensure that they all have an actual arrival (SCH_TRIP.ACTUAL_ARRIVE) and departure (SCH_TRIP.ACTUAL_DEPART) date/times set. If not then error with :-

‘Can not change this trip to status COMPLETED until all of the actual arrival and departure date/times have been entered’.

‘COMPLETED’ to ‘CONFIRMED’ already has code to check the ‘TRM_SET_TO_COMPLETED’ system parameter.

If this parameter is set to ‘POC/POD’ then the code already ensures that all POC and POD flags have been set for all orders on the trip before allowing the trip to be moved to CONFIRMED status.

The only code change required is to return a error message (not an actual error) when all of the POC/POD flags are not set regardless of the system parameter in order for the Trip Debrief Screen to give a warning to the user that not all POC/POD flags are set.

== Trip Debrief Form ==

An error message may be returned by the TRM.SET_TRIP_STATUS even though the call to the package was successful.

If this occurs then the message should be displayed as a warning in order to inform the user that they are setting the trip to status ‘COMPLETED’ without having ticked all of the POC/POD flags for all of the orders on the trip.

= APPENDIX A TABLE UPDATES REQUIRED =

No table changes are required for this development.

= APPENDIX B QUOTE & DOCUMENT HISTORY =

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==
{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

252336

2009-02-05T09:24:18Z

Kingj:

= 252336 PA-7DGNK2 Change Schedule Date of a Scheduled Trip =

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
For Trips in Statuses PLANNED, TENDERED and ACCEPTED To be able to retain a scheduled Trip ID with associated orders and transfer as one to an alternative schedule date if required after the trip has been built and a loading schedule issued for the original date.
Invoke change by 'Right-Click' Drop-down box [Change Schedule Date]
When the Trip schedule date is changed automatically update the Order Scheduled delivery date for all orders on the Trip.
Delete any resources added into the Trip on the original schedule date and revert CARRIER to OWNING DEPOT on new schedule date

== Solution ==
Changing the Schedule name (SCHED_NAME) of a specific trip can be done, but due to referential integrity (links between data) we will have to follow specific steps to complete the change.
Several tables have keys which are based on a combination of the SCHED_NAME and TRIP_ID fields. In these tables we cannot simply update SCHED_NAME as this would violate existing constraints and the Oracle Database would not allow the change.

To work around this we must make a copy of the record(s) we want to change. In the copy record we then update the SCHED_NAME. Once the record has been created and updated, we can remove the original record.

To ensure that we comply with all the data constraints we must copy and update the records from the top (SCH_TRIP table) down and then delete the original records from the bottom (SCH_TRIP_STOP, SCH_TRIP_AUDIT tables) up to SCH_TRIP table.

Several tables, where SCHED_NAME is a simple foreign key, the SCHED_NAME can be updated without requiring copies and deletions.

To allow you to understand the scope of this change, the referential integrity issues will effect 9 tables, with another 11 tables requiring some manipulation and updating. (please see diagram attatched)

In addition to the record changes above, we need to identify which orders have been assigned to the trip using the SCH_HAULAGE_ACTIVITY table. We then update the SCHED_NAME in the SCH_ORD table for all the identified orders and update the late delivery field to match the new schedule.

To update the late delivery field, we intend to amend the date part only, to match the new SCHED_NAME and retain the time from the original schedule.
Set Driver_id, trailer_id and tractor_id to Null in the old record in SCH_TRIP table and set Trailer_id to Null in the new record in the SCH_TRIP_STOP table.
Update Carrier_ID on new SCH_TRIP record to equal the OWNING_DEPT.
These changes will all be completed within a new Package on the form and will be launched from the Trip Tree menu. A new menu option will be added called – ‘Change Schedule date’. Selecting this option will launch the new package.

IMAGE

== Scope ==
This change will be applied to system version 10.5.0 on CONTST and once approved CONPRD.

= SET-UP =

== Pre-requisites ==
None

== Menu Structure ==
Pop up menu Trip Tree Menu will be amended to include a new menu item called ‘Change Schedule Date’ When this is launched, the status of the existing scheduled trip will be checked. If the status is not ‘PLANNED’, ‘TENDERED’ or ‘ACCEPTED’ the user will be told they cannot change the date. If the trip is the required status, a small input form will launch where the user can enter the new schedule date.

== Data ==

The new schedule date will be stored in a non-database item and used as reference for amending the relevant records. The schedule date field , on the new screen will include a list of values, which will be populated based on the schedules available in the database. The user must select a value form this list.

=== Copying data. ===

In the following tables, we will create records based on the new schedule date, where all other values are the same for the trip that is being amended.

Insert into SCH_TRIP (sched_name, trip_id)
VALUES (:change_schedule.new_schedule, :trip_dtl.trip_id)

Commit;

Update SCH_TRIP
SET (all other fields) =
SELECT (all other fields FROM SCH_TRIP where sched_name =:trip_dtl.sched_name and trip_id = :trip_dtl.trip_id)
where sched_name =:change_schedule.new_schedule and trip_id = :trip_dtl.trip_id;

Commit;

There are now two records on the table for the same trip, one referencing the original Schedule name and one referencing the new schedule name. We must continue this process for all tables which reference the schedule_name as part of its primary key.

Before we can carry out the above steps we must first use cursors to check if the selected trip/ schedule have any related records in each table. Only if we find a related record do we insert and update. Otherwise we do nothing with the table.

=== Updating Data ===

Having identified the rest of the tables which reference the schedule name, we must update the relevant record(s) to reference the new schedule_name.

The order records associated with the selected trip must be updated to reflect the new schedule date and a new late delivery time. The order table does not include the trip id, so identifying the relevant orders will require linking three tables, SCH_TRIP_STOP, SCH_HAULAGE_ACTIVITY, SCH_ORD. Once the relevant records in SCH_ORD have been identified, validation will be required to ensure that the amended LATE DELIVERY DATE meets all the existing checks. We are not intending to make any changes to the late delivery time, this will simply inherit the existing value.

The last updates to be completed will remove all resources from the old trip and amending the carrier to be the owning company. In this instance, resources refers to drivers, tractors and trailers. As the old records are to be deleted, this will in fact remove the resources from the original trip.

=== Deleting Data ===

In several tables, there are now two trip records, each referencing a different schedule name . This will be confusing as users will not be aware which is the relevant trip. For this reason , all duplicate trip records , where the old schedule is referenced will be deleted.

Just as when we inserted data, we did so in s specific order, deleting data must also be carried out in a specific order, starting with the following tables

ACC_INVOICE_TRIP
PNL_COST_APPORT
SCH_TRIP_AUDIT
PNL_REV_APPORT
RTE_ROUTE_TRIP
TMP_SCHED_TRIP
SCH_ORD_NON_CONFORM
SCH_TRIP_STOP

And ending with the SCH_TRIP table.

= FUNCTIONAL DESCRIPTION =
This change will allow the user to select a trip, enter a different schedule date and move all the related trip information to the new schedule date. This process will be completed in three steps.

1. The user selects the trip from the trip tree and from the right click menu selects the option ‘Change Schedule Date’. If the trip is in the correct status, an input form is launched.

2. The user selects the new schedule date from the list of schedule dates available. For a schedule date to be available in the list, it must exist in the SCH_SCHEDULE table.

3. The user selects OK . In the background a package is launched which carries out all the required data changes. As the final change is deleting the record that is currently on display in the form, this is an event the OK command button must handle.

== OK Command Button ==

After carrying out all the data changes as described in the previous Data section, this button must handle the event where the record that is currently being displayed on the form is deleted.
This will be achieved by clearing the data block, then setting the schedule name to be the new schedule and executing a query. This code will run after all the data changes have been committed.

== Cancel Command Button ==

This will allow the user to cancel the schedule date change, but only before they select OK. Once OK has been selected, this cannot be cancelled. Users would be able to use the ‘Change Schedule Date’ functionality to revert the trip back to its original schedule date.

IMAGE

The above screen shot shows a trip selected in the trip tree and the right click function which launches a pop up menu. This is where the option to ‘Change Schedule Date’ will be available.

== QUOTE & DOCUMENT HISTORY ==

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==
{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

254565

2009-02-05T09:19:25Z

Kingj: /* QUOTE & DOCUMENT HISTORY */

=''' 254565 - PA-7JARJ4 Find Button in the Trip Overview Screen''' =

Copyright OBS Logistics © 2007

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==

1. If a Date range is specified in the Waterfall Screen FROM to DATE fields the FIND button should restrict its search to this date range. Similarly, if the Waterfall Screen has a specified Schedule date then the search invoked by the FIND button should be restricted to this Schedule date. If both date option fields are left blank then the search should be global.
Added by Suk Sandhu 11/09 - I would suggest schedule and date range be included in find pop up window, populated with data from the main form, with users able to search on that range or blank those fields for an open search.

2. The search criteria listed in the FIND drop down box do not relate to the Waterfall screen environment. HIDE all options other than: Trailer ID, Driver ID, Carrier ID, Tractor ID. When used these should retrieve the specified detail in the schedule/date range being displayed

Added by Suk Sandhu : I would suggest leaving this drop down as it is at the moment as there is likely to be a requirement form various sites to query some of the categories listed

== Solution ==
Three new fields will be added to the find pop-up on the Trip Overview screen. These will be From Date, To Date and schedule.
These fields will initially be populated with the data from the corresponding fields on the main page of the Trip overview screen. If the from and to date are populated they will be included in the criteria for the search. If the Schedule is populated this will be used.
If no values are entered for these fields, either in the main screen or in the pop-up, the search will not be restricted and will be a global search on all trips.
The Find drop down will remain unchanged at present.

== Scope ==
This change will be applied to system version 10.6 on CONTST and once approved CONPRD.

= FUNCTIONAL DESCRIPTION =

Three new fields will be added to the Find pop up screen on the Trip overview screen. These will be Schedule, From Date and To Date.

IMAGE

When the popup is first accessed the values for these fields will be defaulted from the main Trip Overview screen.
IMAGE

If the From and To date are entered the Schedule will become null, and if the schedule is entered the Date range will become null. The user will only be able to search on either the schedule or the date range.

All 3 fields can be set to NULL, which will invoke a search on all trips for the given criteria.

If the search finds multiple results, a pop up screen will be displayed showing all the results found in descending schedule order (i.e. most recent schedules first). The appropriate record can then be selected and the screen will redirect o the Schedule \ Trip chosen.

== QUOTE & DOCUMENT HISTORY ==

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==
IMAGE

== Authorised By ==
{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

254565

2009-02-05T09:18:54Z

Kingj:

=''' 254565 - PA-7JARJ4 Find Button in the Trip Overview Screen''' =

Copyright OBS Logistics © 2007

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==

1. If a Date range is specified in the Waterfall Screen FROM to DATE fields the FIND button should restrict its search to this date range. Similarly, if the Waterfall Screen has a specified Schedule date then the search invoked by the FIND button should be restricted to this Schedule date. If both date option fields are left blank then the search should be global.
Added by Suk Sandhu 11/09 - I would suggest schedule and date range be included in find pop up window, populated with data from the main form, with users able to search on that range or blank those fields for an open search.

2. The search criteria listed in the FIND drop down box do not relate to the Waterfall screen environment. HIDE all options other than: Trailer ID, Driver ID, Carrier ID, Tractor ID. When used these should retrieve the specified detail in the schedule/date range being displayed

Added by Suk Sandhu : I would suggest leaving this drop down as it is at the moment as there is likely to be a requirement form various sites to query some of the categories listed

== Solution ==
Three new fields will be added to the find pop-up on the Trip Overview screen. These will be From Date, To Date and schedule.
These fields will initially be populated with the data from the corresponding fields on the main page of the Trip overview screen. If the from and to date are populated they will be included in the criteria for the search. If the Schedule is populated this will be used.
If no values are entered for these fields, either in the main screen or in the pop-up, the search will not be restricted and will be a global search on all trips.
The Find drop down will remain unchanged at present.

== Scope ==
This change will be applied to system version 10.6 on CONTST and once approved CONPRD.

= FUNCTIONAL DESCRIPTION =

Three new fields will be added to the Find pop up screen on the Trip overview screen. These will be Schedule, From Date and To Date.

IMAGE

When the popup is first accessed the values for these fields will be defaulted from the main Trip Overview screen.
IMAGE

If the From and To date are entered the Schedule will become null, and if the schedule is entered the Date range will become null. The user will only be able to search on either the schedule or the date range.

All 3 fields can be set to NULL, which will invoke a search on all trips for the given criteria.

If the search finds multiple results, a pop up screen will be displayed showing all the results found in descending schedule order (i.e. most recent schedules first). The appropriate record can then be selected and the screen will redirect o the Schedule \ Trip chosen.

= QUOTE & DOCUMENT HISTORY =

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==
IMAGE

== Authorised By ==
{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

249804

2009-02-05T09:17:45Z

Kingj:

= 249804 PA-7DJDPE Amend Debrief Screen - TRIPDTL v2.54 =

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
Amend Debrief Screen - TRIPDTL v2.54 - Reduce level of input, but retain ability to change by exception

Default into Order Debrief Screen.
When accessed from amended OVERVIEW v1.6(Waterfall) screen, open Trip highlighted in waterfall screen.
Pre populate 'Actual' times, 'Actual Weight' and 'Actual Volume' from 'Planned' where appropriate.
Move 'Set Status' button to more prominent position on Right hand side.
Widen or amend font of POD column to allow 'POD' label to be visible when highlighted.
Add Message on screen to 'Change Actual values if incorrect'
Allow multiple selection of orders for POD confirmation.

== Solution ==
When the Trip Debrief (TRIPDTL) screen is opened, whether from the Main Menu or when called from another screen, it will always default into the ‘Order Debrief’ tab, instead of the current ‘General’ tab.

The ‘Set Status’ button and associated Status drop down list will be moved to the right hand side of the screen, so it is more prominent. The 2 buttons originally next to ‘Set Status’ will be aligned on the left hand side; these include ‘Add Order’ and ‘Calc Time’.

When the ‘Debrief’ button in the Waterfall (TRIP_OVERVIEW) screen is clicked, the Trip Debrief (TRIPDTL) screen will be opened and the Trip Details of the currently selected Trip will be passed in.

A new button will be placed on the TRIPDTL screen, on the left side of the Save button below the Actuals input area. It will be named ‘Set Actuals’, and when clicked will pre-populate all the Actual Arrive and Depart Times, and Save these. It will also include the functionality to allow the user to Debrief by Exception.

This is achieved through the following process:
User enters Actual Date/Times only at stops that do not match their Planned Date/Times
User clicks new ‘Set Actuals’ button and the system automatically pre-populates the other stops Actuals.

System will not pre-populate Stop Actuals if they can not be met when compared to previous stop Actuals entered manually by the user
E.g If the manually entered Actual Depart time at Stop 2 is after the Planned Arrive time at Stop 3, the system will not pre-populate Stop 3 Actuals as it is not possible to meet this Planned Arrive deadline when compared to the Actual Depart Time at Stop 2.

In the Order Debrief tab 2 new buttons will be added to allow pre-population of Actual Quantities:
• The first one will be placed directly below the ‘Actual Despatched’ input area and named ‘Set Desp’. This will pre-populate ‘Actual Despatched’, ‘Actual Weight’ and ‘Actual Volume’ for all Order Lines. This also has the Debrief by Exception functionality, where if the user manually enters Actuals for 1 order line and clicks ‘Set Desp’ all other Order Line quantities will be pre-populated, except those manually entered.
• The second button will be placed below the ‘Actual Delivered’ input area and named ‘Set Del’. This button will only pre-populate ‘Actual Delivered’ quantities, and again, it has the Debrief by Exception functionality.

‘POC’ and ‘POD’ column buttons will be amended so that the Text is visible when an Order Line is in focus.

Also in the Order Debrief tab, 2 new buttons will be placed below the current ‘POC’ and ‘POD’ columns of buttons. They will be named ‘POC All’ and ‘POD All’. They will have the same functionality as the current ‘POC’ and ‘POD’ buttons, except that instead of only applying a POC/POD to the corresponding Order Line, they will apply a POC or POD to all Order Lines in the Order Debrief tab. If some Order Lines have a POC/POD already applied, then the ‘POC All’/’POD All’ will only apply POC/POD to those that do not have a POC/POD. Please note than these 2 buttons will not include the functionality to Remove All POC/POD. This will have to be done by individual line using the current ‘POC’ or ‘POD’ buttons next to an Order Line.

The current ‘Non-Conformance’ button and ‘POD/CMR No.’ Text Box will be moved down a line to make space for the new buttons.

Finally, there will be an overall ‘Set All Actuals’ button placed on the bottom right hand side of the TRIPDTL screen. This will be used to pre-populate all Actuals with the current Planned Quantities. This is only to be used if there is no Exceptions during Debrief as it will pre-populate all Stops ‘Actual Arrive Dates/Times’ and ‘Depart Times’, all Orders ‘ Actual Despatched’, ‘Actual Delivered’, ‘Actual Weight’ and ‘Actual Volumes’ and then automatically Save all Actuals.

RIO includes change request for ‘Add Message on screen to 'Change Actual values if incorrect'’, but this will not be required due to the nature of the new functionality.

== Scope ==
This change will be applied to system version 10.6 on CONTST and once approved CONPRD. This was requested by Consumer Networks, but as this is an improvement to current functionality, it will be released over time to all contracts, excluding SAR as it has its own code stream for screen TRIPDTL.

= FUNCTIONAL DESCRIPTION =

== New Functionality ==

Below is a sample screenshot of the new TRIPDTL screen display – once opened.

Changes include:
Opening with ‘Order Debrief’ tab in focus
Set status button moved right, and other buttons realigned
‘POC’ and ‘POD’ buttons amended so text on label can be read
New ‘Set Actuals’ and ‘Set All Actuals’ buttons at bottom of form
New ‘Set Desp’, ’Set Del’, ‘POC All’ and ‘POD All’ buttons on Order Debrief tab

IMAGE

This screen can also be called from the Waterfall (TRIP_OVERVIEW) screen - by clicking the ‘Debrief’ button. The screen will open on the ‘Order Debrief’ tab, and the Trip Details of the trip selected in the Overview screen will be passed in. The screen will not be in Read Only mode, so the user will be able to input Actuals

=== Process Flow for ‘Set Actuals’ button ===

Below is a sample screenshot of a trip with the Order Details and Trip Stop details displayed. User enters Actuals for 2 stops, as these are exceptions, meaning that the planned Arr/Dep times were not met.

IMAGE

Clicking the ‘Set Actuals’ button will pre-populate all other stop Actuals, except Stop 2 and Stop 6. This is because the planned arrive times can not be met when compared to the depart times on the previous stop, which the exceptions have been entered for. E.g. Stop 1 Actual Depart is at 03:30, and will not be able to meet the Planned Arrive time of 03:23 at stop 2.

The other stop Actuals (Stop 3, 4 and 7) will be pre-populated as these times can, in theory, be met - as the driver was only 7 minutes behind at stop 1 and 11 minutes behind at stop 5. It is possible for the driver to make up the time and Arr/Dep the other stops at the Planned times. Below is a sample screenshot, after the ‘Set Actuals’ button is clicked.

IMAGE

The user will now have to fill in Stop 2 and Stop 6 Actuals manually.

If the ‘Set Actuals’ button is clicked when no Exceptions have been entered, then all stop Actuals will pre-populate with the Planned times.

=== Process Flow for ‘Set Desp’ and ‘Set Del’ buttons ===

The ‘Set Desp’ and ‘Set Del’ buttons on the ‘Order Debrief’ tab will work in a similar fashion. When a user enters some despatched quantities, and clicks the ‘Set Desp’ button, all other values will be pre-populated with the Planned values.

Below is a sample screenshot of what the user has entered, and the following screenshot is an example of how the Actuals would display as - after the ‘Set Desp’ button is clicked:

IMAGE
IMAGE

The ‘Set Del’ button has the same functionality as the ‘Set Desp’, where it will populate all Delivered Actuals that have not already been entered.

=== Process Flow for ‘POC All’ and ‘POD All’ buttons ===

The ‘POC All’ and ‘POD All’ buttons will apply a POC or POD for all orders in the ‘Order Debrief’ tab. If a few orders already have a POC or POD applied, the ‘POC All’/’POD All’ will apply a POC or POD to those that do not.

Note: these buttons do not have the functionality to remove all POC/POD. This will have to be performed individually, per order, using the existing ‘POC’ or ‘POD’ button.

Below is a sample screenshot after all POC’s are applied using the ‘POC All’ button:

IMAGE

All current error trapping functionality will remain on this screen. E.g. Trying to Apply a POC when no Actual Date/Times entered will display message ‘You must specify the Actual Arrive Date’.

=== Process Flow for ‘Set All Actuals’ button ===
Finally, the button ‘Set All Actuals’ will be used to pre-populate all actual values, and perform an automatic save. This is to be used only if there have been no exceptions on Stop times, despatched quantities or delivered quantities. Below is a sample screenshot of a trip with no actual data entered - it is again followed by a screenshot displaying the trip details, if the ‘Set All Actuals’ button was clicked:

IMAGE
IMAGE

= QUOTE & DOCUMENT HISTORY =

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==

{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

251628

2009-02-05T09:13:21Z

Kingj: /* APPENDIX B QUOTE & DOCUMENT HISTORY */

= '''251628 PA-7FZBNZ Amend Order Tracking Screen''' =

'''Copyright OBS Logistics © 2007'''

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==

Amend ORDER TRACKING screen TRACKING V2.55 - add to search facility.

Add to Search drop Down Box - [CUSTOMER] & [OMS REF] and associated searches

Added by NW - 27/06/08: The OMS Ref can be added to the existing search drop down. The Customer search should be added as a filter rather than a search and added to the form above the current Carrier filter. This is because the Customer is static data whereas the references are not taken from a list.

== Solution ==

After investigation into the different searches available in the search drop down list, there is no need to add OMS REF to the existing search drop down, as this functionality is currently there in the form of the ‘Order Ref’ search item. Inputting an OMS REF into the editable text box and selecting Order Ref in the search drop down allows the user to search by OMS REF. Suggest changing the text of ‘Order Ref’ to ‘OMS Ref’ in the Search Drop Down List of the TRACKING screen to avoid any confusion.

Below shows what each item in the Search List corresponds to in relation to an Order or a Trip:
Order Ref  OMS Ref (of an Order)
Trip Reference  Bill of Lading (of a Trip)
Customer Ref  External Ref (of an Order)
Carrier Ref  Carrier Ref (of a Trip)
Bill of Lading (Order)  Bill of Lading (of an Order)
Container No (Order)  Container No (of an Order)
Container No (Trip)  Container No (of a Trip)
Booking Ref  Booking Ref (of an Order)

We will also include a search by ‘Order ID’ (e.g. EX__S934037) in this drop down so that the available search options are in line with the search options available in the Trip Debrief (TRIPDTL) screen.

Add filter to TRACKING screen just above current Carrier filter to allow users to filter by Customer. The drop down list will display a list of Customers in a lookup table. The list of Customers in the lookup table will also be filtered according to the current users CUSTOMER and CUST_GROUP parameters set up in the Access Control screen.
Refreshing the screen after a Customer is selected in this filter, will only show trips in the lower part of the screen for the customer referenced in the filter.

== Scope ==

This change will be applied to system version 10.6 on CONTST and once approved CONPRD. The nature of this change does not impact on the current functionality of the screen and therefore makes it applicable to all MTS environments.

= FUNCTIONAL DESCRIPTION =

== New Functionality ==

The screenshot below shows the current Search drop down list in the TRACKINGS screen and those search items currently available:

IMAGE

The new drop down list will display the item ‘OMS Ref’ instead of ‘Order Ref, it is OMS Ref that is searched on when the Order Ref is selected. Changing the text to ‘OMS Ref’ will avoid any confusion.

The new Search list will also include a search by ‘Order Id’ - this will bring the list of search options into line with the search options currently available on the TRIPDTL screen. An example Order Id is EX__S934037.

Below is a screenshot sample of what the Search List will display (including these two changes):

IMAGE

Below is a screenshot displaying the top section of the current TRACKING screen that holds the search and filter information:

IMAGE

After the addition of the ‘Customer Filter’, above the current Carrier Filter, the TRACKING screen will display as follows:

IMAGE

The fields ‘From Date’ and ‘To Date’ will require moving slightly to the right to allow space for the new Customer filter on the screen.

== Procedure for Customer Filter ==

Create a new Item on Data Block TRACKING_CTRL called CUSTOMER_ID with an associated Customer Lookup. The CUSTOMER_ID will reference an LOV. The LOV will set up the list of Customers available in the Lookup table, depending on the parameters CUST and CUST_GROUP, set up in Access Control for the current user using the TRACKING screen.

Below is a preliminary example of the procedure that will need to be constructed within the POP_LISTS Program Unit to set up the Customer List:

PROCEDURE Customer_List IS
-----------------------------------------------------------------------------
-- Populate the Customer List with all available customers
-----------------------------------------------------------------------------
v_retnum NUMBER;
v_customer_string ADM_USER_PARAM_TYPE.sql_string%TYPE;
v_cust_group_string ADM_USER_PARAM_TYPE.sql_string%TYPE;
v_default VARCHAR2(2000);
v_sql_string VARCHAR2(2000);
v_no_of_params NUMBER;
v_total NUMBER;
v_query VARCHAR2( 1000 );

BEGIN
-----------------------------------------------------------------------------
MESSAGE( 'Populating Customer List...', NO_ACKNOWLEDGE );
Set_Application_Property( CURSOR_STYLE, 'BUSY' );

v_List_Grp := Find_Group( 'CUSTOMER1' );
IF NOT Id_Null( v_List_Grp ) THEN
Delete_Group( v_List_Grp );
END IF;

v_customer_string := ADM.Get_Multiple_User_Param( 'CUSTOMER', v_default, v_sql_string, v_no_of_params);

v_cust_group_string := ADM.Get_Multiple_User_Param( 'CUST_GROUP', v_default, v_sql_string, v_no_of_params);

IF v_cust_group_string = 'ALL' THEN
IF v_customer_string = 'ALL' THEN
v_List_Grp := Create_Group_From_Query( 'CUSTOMER1',
'SELECT DISTINCT customer_id, customer_name
FROM org_customer
ORDER BY 2' );
ELSE
v_List_Grp := Create_Group_From_Query( 'CUSTOMER1',
'SELECT DISTINCT customer_id, customer_name
FROM ORG_Customer
WHERE customer_id ' || v_customer_string ||
' ORDER BY 2' );
END IF;
ELSE
IF v_customer_string = 'ALL' THEN
v_List_Grp := Create_Group_From_Query( 'CUSTOMER1',
'SELECT DISTINCT customer_id, customer_name
FROM ORG_Customer
WHERE cust_group ' || v_cust_group_string ||
' ORDER BY 2' );
ELSE
v_List_Grp := Create_Group_From_Query( 'CUSTOMER1',
'SELECT DISTINCT customer_id, customer_name
FROM ORG_Customer
WHERE customer_id ' || v_customer_string ||
' AND cust_group ' || v_cust_group_string ||
' ORDER BY 2' );
END IF;
END IF;
-----------------------------------------------------------------------------
v_retcode := Populate_Group( v_List_Grp );
Set_LOV_Property( 'CUSTOMERS', GROUP_NAME, 'CUSTOMER1' );
-----------------------------------------------------------------------------

v_total := Get_Group_Row_Count(v_List_Grp);

CLEAR_MESSAGE;
Set_Application_Property( CURSOR_STYLE, 'DEFAULT' );

EXCEPTION
WHEN OTHERS THEN
Set_Application_Property( CURSOR_STYLE, 'DEFAULT' );
ADM.WRITE_MSG( 'ORD_DETAIL', 'ERROR', 'WOE populating customer list. '||SQLERRM );
MESSAGE( 'WOE populating customer list. '||SQLERRM, no_acknowledge );

END Customer_List;

Also, include in Procedure F_REFRESH_STOP_LIST the selected customer from the Filter, when the ‘Refresh’ button is clicked:

IF :TRACKING_CTRL.CUSTOMER_ID IS NOT NULL THEN
v_where_clause := v_where_clause ||
' AND Customer_id = ''' || :TRACKING_CTRL.CUSTOMER_ID || '''';
END IF;

== Update for Search By ‘Order ID’ ==

Requires an update of elements in List Items SEARCH_BY on the TRACKING_CTRL Data Block. ‘Order ID’ will need to be included and reference ORDER_ID on table SCH_ORD. Here the text of ‘Order Ref’ will also be changed to ‘OMS Ref’. Below is a screenshot of the Elements in List Property Palette after the update:

IMAGE

= QUOTE & DOCUMENT HISTORY =

IMAGE

==References==
IMAGE

==Glossary==
IMAGE

==Document History==
IMAGE

==Authorised By==

{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

252347

2009-02-04T14:43:39Z

Kingj:

= '''252347 PA-7DGPFT Add Trip Revenue to Trip Finance''' =

'''Copyright OBS Logistics © 2008'''
The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
The Finance Tab in Trip Manipulation and Trip planning to show Trip revenue and trip cost (subbed)

Currently 2 Fields visible on Finance Tab of a Trip:

1: Currently Operational- Trip Cost (Payments) - Populated by Carrier related Contract or Manual input of agreed Subcontractor Rates - Sum of PAYMENTS v2.23 Trip Based

2: Revenue - Currently un-used (Greyed-out)- Develop to show sum of all Revenues from all the Orders on the Trip.
See Attachment
Change Label to REVENUE
Sum of PAYMENTS v2.23 (Order Based) for all Orders allocated to the trip

More financial awareness when a Trip is being planned.

== Solution ==

Amend screens Trip Manipulation (TRIPSUM) and Trip Planning (TRIP_PLAN) to include the following changes:

Label currently ‘Cost’ changed to display ‘Trip Cost’.
Label currently ‘Revenue’ changed to display ‘Trip Revenue’
Current Greyed out area will be used to display the Revenue of all Orders on the current Trip. This will display in format 123.45 but will remain greyed out along with the current greyed out ‘Payments’ button, so it can not be edited by the user, as it will only be used for financial awareness.

Package ACC.sql will need to be updated as calculating the Trip Revenue requires a call to it when the Finance tab is selected. A new function will be created that will sum all Revenue payments for all Orders on a particular trip. The value will be taken from field ORD_REVENUE in table SCH_ORD. The value held in this field corresponds to the value held in the ‘Revenue’ field on the ‘Finance’ tab within the ORDERS screen.

== Scope ==

This change will be applied to system version 10.6 on CONTST and once approved CONPRD. This form will be applicable to all MTS environments, as the nature of this change does not impact on the current functionality of the form. This field will only be viewed, and can not be edited.

= FUNCTIONAL DESCRIPTION =

== New Functionality ==

The sample screenshot below displays the TRIPSUM screen with the new functionality included - to sum all order payments on the one trip, then display in the greyed out field - for financial awareness. Trip MAN-00665530 on Sched 080428 is the provided example (from COLV):

IMAGE

Also notice, the change to the text labels, ‘Trip Cost’ and ‘Trip Revenue’.

From the screen shots below, note 3 orders that are on this Trip. Summing all Order Revenues will calculate an overall total 300.94, same figure as displayed above.

IMAGE

IMAGE

IMAGE

== New Function ==

The following Function ‘F_GET_TRIP_REVENUE’ will be used in forms TRIP_PLAN and TRIPSUM. It will be passed in a Trip ID (e.g. MAN-00012345) where it will sum field ORD_REVENUE from all Orders on the current trip.

FUNCTION F_GET_TRIP_REVENUE(i_trip_id IN VARCHAR2) RETURN NUMBER IS

v_trip_revenue SCH_ORD.ORD_REVENUE%TYPE;

CURSOR c_trip_revenue( cp_trip_id VARCHAR2 ) IS
SELECT SUM(SO.ORDER_REVENUE)
FROM SCH_ORD SO, SCH_HAULAGE_ACTIVITY SHA, SCH_TRIP_STOP STS
WHERE SO.OMS_REF = SHA.OMS_REF
AND SHA.STOP_ID = STS.STOP_ID
AND SHA.ACTIVITY_NAME = ‘Load’
AND STS.TRIP_ID = cp_trip_id;

BEGIN

OPEN c_trip_revenue ( i_trip_id );
FETCH c_trip_revenue INTO v_trip_revenue;
CLOSE c_trip_revenue;

RETURN (v_trip_revenue);

EXCEPTION
WHEN OTHERS THEN
RETURN (NULL);

END;

== Trigger Updates ==

General structure the code will take for displaying Trip Revenue functionality in:
• POST-QUERY trigger on the TRIP_DTL tabs in TRIP_PLAN and TRIPSUM

:TRIP_DTL.TRIP_REVENUE := F_GET_TRIP_REVENUE( :TRIP_DTL.trip_id );

== Trigger Amendments ==

Currently, there is a WHEN-BUTTON-PRESSED trigger on button ‘Apply’ next to MTM Cost in the Finance tab. It includes the code below, which returns values into TRIP_REVENUE, TRIP_COST and ALLOCATABLE_COST:

:TRIP_DTL.Trip_Revenue := ACC.Get_Event_Revenue( :TRIP_DTL.SCHED_NAME || '-' || :TRIP_DTL.TRIP_ID, :TRIP_DTL.Cost_centre, 'DUE' );

:TRIP_DTL.Trip_Cost := ACC.Get_Event_Cost ( :TRIP_DTL.SCHED_NAME || '-' || :TRIP_DTL.TRIP_ID, :TRIP_DTL.Cost_centre, 'DUE' );

:TRIP_DTL.Allocable_Cost := ACC.Get_Allocable_Event_Cost ( :TRIP_DTL.SCHED_NAME || '-' || :TRIP_DTL.TRIP_ID, :TRIP_DTL.Cost_centre );

The code to return a value for TRIP_DTL.Trip_Revenue will be removed.

Reasoning behind this, is, after investigation into the procedure it calls in ACC, it will always return the value 0.00. This figure is always returned because the calculation is summing all the order revenues on the trip from table ACC_PAYMENT, where the field EVENT_REF is equal to :TRIP_DTL.SCHED_NAME || '-' || :TRIP_DTL.TRIP_ID (e.g. 080104-MAN-00012345). An EVENT_REF in this format is only stored for Trip Payments. All Order Payments store an OMS Ref in the EVENT_REF field.

This code will be removed. If the new functionality displays 123.45 as the Trip Revenue, and then the user clicks the ‘Apply’ MTM Cost button, the Trip Revenue of 123.45 will be over-written with 0.00.

QUOTE & DOCUMENT HISTORY =

IMAGE

== References ==
IMAGE

== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==

{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

251628

2009-02-04T14:42:51Z

Kingj:

= '''251628 PA-7FZBNZ Amend Order Tracking Screen''' =

'''Copyright OBS Logistics © 2007'''

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==

Amend ORDER TRACKING screen TRACKING V2.55 - add to search facility.

Add to Search drop Down Box - [CUSTOMER] & [OMS REF] and associated searches

Added by NW - 27/06/08: The OMS Ref can be added to the existing search drop down. The Customer search should be added as a filter rather than a search and added to the form above the current Carrier filter. This is because the Customer is static data whereas the references are not taken from a list.

== Solution ==

After investigation into the different searches available in the search drop down list, there is no need to add OMS REF to the existing search drop down, as this functionality is currently there in the form of the ‘Order Ref’ search item. Inputting an OMS REF into the editable text box and selecting Order Ref in the search drop down allows the user to search by OMS REF. Suggest changing the text of ‘Order Ref’ to ‘OMS Ref’ in the Search Drop Down List of the TRACKING screen to avoid any confusion.

Below shows what each item in the Search List corresponds to in relation to an Order or a Trip:
Order Ref  OMS Ref (of an Order)
Trip Reference  Bill of Lading (of a Trip)
Customer Ref  External Ref (of an Order)
Carrier Ref  Carrier Ref (of a Trip)
Bill of Lading (Order)  Bill of Lading (of an Order)
Container No (Order)  Container No (of an Order)
Container No (Trip)  Container No (of a Trip)
Booking Ref  Booking Ref (of an Order)

We will also include a search by ‘Order ID’ (e.g. EX__S934037) in this drop down so that the available search options are in line with the search options available in the Trip Debrief (TRIPDTL) screen.

Add filter to TRACKING screen just above current Carrier filter to allow users to filter by Customer. The drop down list will display a list of Customers in a lookup table. The list of Customers in the lookup table will also be filtered according to the current users CUSTOMER and CUST_GROUP parameters set up in the Access Control screen.
Refreshing the screen after a Customer is selected in this filter, will only show trips in the lower part of the screen for the customer referenced in the filter.

== Scope ==

This change will be applied to system version 10.6 on CONTST and once approved CONPRD. The nature of this change does not impact on the current functionality of the screen and therefore makes it applicable to all MTS environments.

= FUNCTIONAL DESCRIPTION =

== New Functionality ==

The screenshot below shows the current Search drop down list in the TRACKINGS screen and those search items currently available:

IMAGE

The new drop down list will display the item ‘OMS Ref’ instead of ‘Order Ref, it is OMS Ref that is searched on when the Order Ref is selected. Changing the text to ‘OMS Ref’ will avoid any confusion.

The new Search list will also include a search by ‘Order Id’ - this will bring the list of search options into line with the search options currently available on the TRIPDTL screen. An example Order Id is EX__S934037.

Below is a screenshot sample of what the Search List will display (including these two changes):

IMAGE

Below is a screenshot displaying the top section of the current TRACKING screen that holds the search and filter information:

IMAGE

After the addition of the ‘Customer Filter’, above the current Carrier Filter, the TRACKING screen will display as follows:

IMAGE

The fields ‘From Date’ and ‘To Date’ will require moving slightly to the right to allow space for the new Customer filter on the screen.

== Procedure for Customer Filter ==

Create a new Item on Data Block TRACKING_CTRL called CUSTOMER_ID with an associated Customer Lookup. The CUSTOMER_ID will reference an LOV. The LOV will set up the list of Customers available in the Lookup table, depending on the parameters CUST and CUST_GROUP, set up in Access Control for the current user using the TRACKING screen.

Below is a preliminary example of the procedure that will need to be constructed within the POP_LISTS Program Unit to set up the Customer List:

PROCEDURE Customer_List IS
-----------------------------------------------------------------------------
-- Populate the Customer List with all available customers
-----------------------------------------------------------------------------
v_retnum NUMBER;
v_customer_string ADM_USER_PARAM_TYPE.sql_string%TYPE;
v_cust_group_string ADM_USER_PARAM_TYPE.sql_string%TYPE;
v_default VARCHAR2(2000);
v_sql_string VARCHAR2(2000);
v_no_of_params NUMBER;
v_total NUMBER;
v_query VARCHAR2( 1000 );

BEGIN
-----------------------------------------------------------------------------
MESSAGE( 'Populating Customer List...', NO_ACKNOWLEDGE );
Set_Application_Property( CURSOR_STYLE, 'BUSY' );

v_List_Grp := Find_Group( 'CUSTOMER1' );
IF NOT Id_Null( v_List_Grp ) THEN
Delete_Group( v_List_Grp );
END IF;

v_customer_string := ADM.Get_Multiple_User_Param( 'CUSTOMER', v_default, v_sql_string, v_no_of_params);

v_cust_group_string := ADM.Get_Multiple_User_Param( 'CUST_GROUP', v_default, v_sql_string, v_no_of_params);

IF v_cust_group_string = 'ALL' THEN
IF v_customer_string = 'ALL' THEN
v_List_Grp := Create_Group_From_Query( 'CUSTOMER1',
'SELECT DISTINCT customer_id, customer_name
FROM org_customer
ORDER BY 2' );
ELSE
v_List_Grp := Create_Group_From_Query( 'CUSTOMER1',
'SELECT DISTINCT customer_id, customer_name
FROM ORG_Customer
WHERE customer_id ' || v_customer_string ||
' ORDER BY 2' );
END IF;
ELSE
IF v_customer_string = 'ALL' THEN
v_List_Grp := Create_Group_From_Query( 'CUSTOMER1',
'SELECT DISTINCT customer_id, customer_name
FROM ORG_Customer
WHERE cust_group ' || v_cust_group_string ||
' ORDER BY 2' );
ELSE
v_List_Grp := Create_Group_From_Query( 'CUSTOMER1',
'SELECT DISTINCT customer_id, customer_name
FROM ORG_Customer
WHERE customer_id ' || v_customer_string ||
' AND cust_group ' || v_cust_group_string ||
' ORDER BY 2' );
END IF;
END IF;
-----------------------------------------------------------------------------
v_retcode := Populate_Group( v_List_Grp );
Set_LOV_Property( 'CUSTOMERS', GROUP_NAME, 'CUSTOMER1' );
-----------------------------------------------------------------------------

v_total := Get_Group_Row_Count(v_List_Grp);

CLEAR_MESSAGE;
Set_Application_Property( CURSOR_STYLE, 'DEFAULT' );

EXCEPTION
WHEN OTHERS THEN
Set_Application_Property( CURSOR_STYLE, 'DEFAULT' );
ADM.WRITE_MSG( 'ORD_DETAIL', 'ERROR', 'WOE populating customer list. '||SQLERRM );
MESSAGE( 'WOE populating customer list. '||SQLERRM, no_acknowledge );

END Customer_List;

Also, include in Procedure F_REFRESH_STOP_LIST the selected customer from the Filter, when the ‘Refresh’ button is clicked:

IF :TRACKING_CTRL.CUSTOMER_ID IS NOT NULL THEN
v_where_clause := v_where_clause ||
' AND Customer_id = ''' || :TRACKING_CTRL.CUSTOMER_ID || '''';
END IF;

== Update for Search By ‘Order ID’ ==

Requires an update of elements in List Items SEARCH_BY on the TRACKING_CTRL Data Block. ‘Order ID’ will need to be included and reference ORDER_ID on table SCH_ORD. Here the text of ‘Order Ref’ will also be changed to ‘OMS Ref’. Below is a screenshot of the Elements in List Property Palette after the update:

IMAGE

= APPENDIX B QUOTE & DOCUMENT HISTORY =

IMAGE

==References==
IMAGE

==Glossary==
IMAGE

==Document History==
IMAGE

==Authorised By==

{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

251628

2009-02-04T14:42:19Z

Kingj:

= '''251628 PA-7FZBNZ Amend Order Tracking Screen''' =

'''Copyright OBS Logistics © 2007'''

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==

Amend ORDER TRACKING screen TRACKING V2.55 - add to search facility.

Add to Search drop Down Box - [CUSTOMER] & [OMS REF] and associated searches

Added by NW - 27/06/08: The OMS Ref can be added to the existing search drop down. The Customer search should be added as a filter rather than a search and added to the form above the current Carrier filter. This is because the Customer is static data whereas the references are not taken from a list.

== Solution ==

After investigation into the different searches available in the search drop down list, there is no need to add OMS REF to the existing search drop down, as this functionality is currently there in the form of the ‘Order Ref’ search item. Inputting an OMS REF into the editable text box and selecting Order Ref in the search drop down allows the user to search by OMS REF. Suggest changing the text of ‘Order Ref’ to ‘OMS Ref’ in the Search Drop Down List of the TRACKING screen to avoid any confusion.

Below shows what each item in the Search List corresponds to in relation to an Order or a Trip:
Order Ref  OMS Ref (of an Order)
Trip Reference  Bill of Lading (of a Trip)
Customer Ref  External Ref (of an Order)
Carrier Ref  Carrier Ref (of a Trip)
Bill of Lading (Order)  Bill of Lading (of an Order)
Container No (Order)  Container No (of an Order)
Container No (Trip)  Container No (of a Trip)
Booking Ref  Booking Ref (of an Order)

We will also include a search by ‘Order ID’ (e.g. EX__S934037) in this drop down so that the available search options are in line with the search options available in the Trip Debrief (TRIPDTL) screen.

Add filter to TRACKING screen just above current Carrier filter to allow users to filter by Customer. The drop down list will display a list of Customers in a lookup table. The list of Customers in the lookup table will also be filtered according to the current users CUSTOMER and CUST_GROUP parameters set up in the Access Control screen.
Refreshing the screen after a Customer is selected in this filter, will only show trips in the lower part of the screen for the customer referenced in the filter.

== Scope ==

This change will be applied to system version 10.6 on CONTST and once approved CONPRD. The nature of this change does not impact on the current functionality of the screen and therefore makes it applicable to all MTS environments.

= FUNCTIONAL DESCRIPTION =

== New Functionality ==

The screenshot below shows the current Search drop down list in the TRACKINGS screen and those search items currently available:

IMAGE

The new drop down list will display the item ‘OMS Ref’ instead of ‘Order Ref, it is OMS Ref that is searched on when the Order Ref is selected. Changing the text to ‘OMS Ref’ will avoid any confusion.

The new Search list will also include a search by ‘Order Id’ - this will bring the list of search options into line with the search options currently available on the TRIPDTL screen. An example Order Id is EX__S934037.

Below is a screenshot sample of what the Search List will display (including these two changes):

IMAGE

Below is a screenshot displaying the top section of the current TRACKING screen that holds the search and filter information:

IMAGE

After the addition of the ‘Customer Filter’, above the current Carrier Filter, the TRACKING screen will display as follows:

IMAGE

The fields ‘From Date’ and ‘To Date’ will require moving slightly to the right to allow space for the new Customer filter on the screen.

== Procedure for Customer Filter ==

Create a new Item on Data Block TRACKING_CTRL called CUSTOMER_ID with an associated Customer Lookup. The CUSTOMER_ID will reference an LOV. The LOV will set up the list of Customers available in the Lookup table, depending on the parameters CUST and CUST_GROUP, set up in Access Control for the current user using the TRACKING screen.

Below is a preliminary example of the procedure that will need to be constructed within the POP_LISTS Program Unit to set up the Customer List:

PROCEDURE Customer_List IS
-----------------------------------------------------------------------------
-- Populate the Customer List with all available customers
-----------------------------------------------------------------------------
v_retnum NUMBER;
v_customer_string ADM_USER_PARAM_TYPE.sql_string%TYPE;
v_cust_group_string ADM_USER_PARAM_TYPE.sql_string%TYPE;
v_default VARCHAR2(2000);
v_sql_string VARCHAR2(2000);
v_no_of_params NUMBER;
v_total NUMBER;
v_query VARCHAR2( 1000 );

BEGIN
-----------------------------------------------------------------------------
MESSAGE( 'Populating Customer List...', NO_ACKNOWLEDGE );
Set_Application_Property( CURSOR_STYLE, 'BUSY' );

v_List_Grp := Find_Group( 'CUSTOMER1' );
IF NOT Id_Null( v_List_Grp ) THEN
Delete_Group( v_List_Grp );
END IF;

v_customer_string := ADM.Get_Multiple_User_Param( 'CUSTOMER', v_default, v_sql_string, v_no_of_params);

v_cust_group_string := ADM.Get_Multiple_User_Param( 'CUST_GROUP', v_default, v_sql_string, v_no_of_params);

IF v_cust_group_string = 'ALL' THEN
IF v_customer_string = 'ALL' THEN
v_List_Grp := Create_Group_From_Query( 'CUSTOMER1',
'SELECT DISTINCT customer_id, customer_name
FROM org_customer
ORDER BY 2' );
ELSE
v_List_Grp := Create_Group_From_Query( 'CUSTOMER1',
'SELECT DISTINCT customer_id, customer_name
FROM ORG_Customer
WHERE customer_id ' || v_customer_string ||
' ORDER BY 2' );
END IF;
ELSE
IF v_customer_string = 'ALL' THEN
v_List_Grp := Create_Group_From_Query( 'CUSTOMER1',
'SELECT DISTINCT customer_id, customer_name
FROM ORG_Customer
WHERE cust_group ' || v_cust_group_string ||
' ORDER BY 2' );
ELSE
v_List_Grp := Create_Group_From_Query( 'CUSTOMER1',
'SELECT DISTINCT customer_id, customer_name
FROM ORG_Customer
WHERE customer_id ' || v_customer_string ||
' AND cust_group ' || v_cust_group_string ||
' ORDER BY 2' );
END IF;
END IF;
-----------------------------------------------------------------------------
v_retcode := Populate_Group( v_List_Grp );
Set_LOV_Property( 'CUSTOMERS', GROUP_NAME, 'CUSTOMER1' );
-----------------------------------------------------------------------------

v_total := Get_Group_Row_Count(v_List_Grp);

CLEAR_MESSAGE;
Set_Application_Property( CURSOR_STYLE, 'DEFAULT' );

EXCEPTION
WHEN OTHERS THEN
Set_Application_Property( CURSOR_STYLE, 'DEFAULT' );
ADM.WRITE_MSG( 'ORD_DETAIL', 'ERROR', 'WOE populating customer list. '||SQLERRM );
MESSAGE( 'WOE populating customer list. '||SQLERRM, no_acknowledge );

END Customer_List;

Also, include in Procedure F_REFRESH_STOP_LIST the selected customer from the Filter, when the ‘Refresh’ button is clicked:

IF :TRACKING_CTRL.CUSTOMER_ID IS NOT NULL THEN
v_where_clause := v_where_clause ||
' AND Customer_id = ''' || :TRACKING_CTRL.CUSTOMER_ID || '''';
END IF;

== Update for Search By ‘Order ID’ ==

Requires an update of elements in List Items SEARCH_BY on the TRACKING_CTRL Data Block. ‘Order ID’ will need to be included and reference ORDER_ID on table SCH_ORD. Here the text of ‘Order Ref’ will also be changed to ‘OMS Ref’. Below is a screenshot of the Elements in List Property Palette after the update:

IMAGE

= APPENDIX A TABLE UPDATES REQUIRED =

No table changes are required for this development.

= APPENDIX B QUOTE & DOCUMENT HISTORY =

IMAGE

==References==
IMAGE

==Glossary==
IMAGE

==Document History==
IMAGE

==Authorised By==

{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

250391

2009-02-04T12:31:18Z

Kingj: /* Authorised By */

= 250391-PA-7DGNZZ Remove Case Sensitive Searches =

Copyright OBS Logistics © 2007

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
Searches being carried out in Maintenance/Locations, are case sensitive in all fields, meaning that a search may fail due to this when the Location does however exist in another case format. Can lead to unnecessary addition and Duplication of an existing Location ID. Added by PA: Should be applied to all fields of the LOCATIONS form which are capable of being 'searched' using the search buttons.

== Solution ==
Users will be able to query a specified field and retrieve all relevant records regardless of the case the query text has been entered in. This will be achieved by amending the property palette functionality available for each field.

The changes will be applied to the Locations form, specifically the following fields :

Location id
Location Name
Route Code
Postal Region
Planning Region

Address Line 1
Address Line 2
Address Line 3
Town
County
PostCode

== Scope ==

This change will be applied to system version MTS V10.5.0 on CONTST and once approved CONPRD. The Locations form will be updated to version 2_48

= SET-UP =

== Pre-requisites ==
None

== Menu Structure ==
Unchanged

== Data ==
No data changes – changes are functional.

= FUNCTIONAL DESCRIPTION =
All searchable fields within the Locations screen and specifically the address tab will no longer be limited to case sensitive searches.

Entering search text in lowercase will also return Upper case matches and similarly, entering uppercase search text will also return lowercase matches.

IMAGE

The above screenshot shows the fields which will have the case sensitivity removed.

= APPENDIX A TABLE UPDATES REQUIRED =

No table changes are required for this development

= APPENDIX B QUOTE & DOCUMENT HISTORY =

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==
{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

255572

2009-02-04T12:30:55Z

Kingj: /* Authorised By */

= 255572-PA-7JUG5V ADD Trip id barcode to TripSheet =

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
1: Add Code 39 (3 of 9) Barcode to CN Trip Sheet (MTS Modules/Reports/CN Trip Sheet) of Trip ID (MAN-00XXXXXX) to enable this to be read and decoded by the LOTS system scanner.Suggest position to the right of Report header, approx 4cm x 1cm.

2: CN Trip Sheet pdf Report (MTS Modules/Reports/CN Trip Sheet) change [Booking Window] to [Booked Time] and amend field link to read respective field in MTS ie [Late_Del] (time only)

Added by SS - Barcode should only hold trip no eg MAN-123456.
A new trip sheet containing barcode should be created this report should be based on CN Trip Sheet report. However the new report should contain the barcode in the top right corner of the report. Version number and time of report will need to be relocated.

== Solution ==

A new version of TRIP_SHEET.RDF will be created called TRIP_SHEET_BAR.RDF

Add BARCODE

The barcode will be displayed at the top of the report , to print this is the margin will cause a conflict in Oracle reports as the trip-id is being displayed in detail of the report, this conflict will have to be resolved to print the barcode in the desired place. A brief description of the required steps is listed below:

• Create a function to read in data and return the data in barcode 39 format. This function will be stored on the database.
• Download the BARCODE 39 font
• In the report, create a formula column CF_TRIP_BARCODE. The formula of this column will run the BARCODE function, reading in TRIP_ID as the data source.
• The barcode 39 data will be returned into a data field F_TRIP_BAR_CODE which will be displayed in the margin of the report. The source of F_TRIP_BAR_CODE will be the formula column CF_TRIP_BARCODE. This field will be assigned the barcode font -IDAutomationHC39M.

Amend Booking Window

Within the trip stop detail, the Booking Window will be amended to display Booked Time, and the time part of the late delivery field will be displayed under the Booked Time heading.

• Add LATE_DEL from SCH_ORD to the data model, SCH_ORD is already a data source so the relevant where statements exist.
• Change the Boiler Plate text from ‘Booking Window’ to ‘Booked Time’ and create a data field sourced by LATE_DEL., this will be displayed in the TRIP STOP repeating frame.

== Scope ==
This change will be applied to system version 10.5 on CONTST and once approved CONPRD.

= SET-UP =

== Pre-requisites ==
None

== Menu Structure ==
Unchanged

== Data ==
The new report will be added to the standing data to allow it to be selected from the standard reports form. The selection criteria for the report will by the same as that for TRIP_SHEET

= FUNCTIONAL DESCRIPTION =
This RIO can be split into the following tasks

== Display the TRIP_ID as a BARCODE ==

The format of this BARCODE must support code 39. For the barcode to be displayed on the report the following steps must be completed:

Down load a version of BARCODE 39 font for use in the report
Create a function which will read in the TRIP_ID and output a format which can be read by the BARCODE font. Function BARCODE_39 will be created in the database.

Use a Formula field in Oracle reports to run the barcode function, the formula field will be created with the following properties and will call the function BARCODE_39 and apply it to trip_id.

NAME CF_TRIP_BARCODE
PL/SQL RETURN BARCODE_39(|| :TRIP_ID ||);

Create a data field which will be sourced by the formula field. Both the data field and formula fields must be set up as char. The formula field will specifically have the following properties

Name F_TRIP_BARCODE
Source CF_TRIP_BARCODE
Type CHAR
Length 22
Font IDAutomationHC39M

We must ensure that the report will compile on the development, test and production servers. This may require the new BARCODE font to be loaded onto the different servers.

== Displaying the BARCODE in the requested place. ==

The requirements have requested that the barcode is displayed in the margin of the report. Margins should only be used for displaying static text like headings or parameter values but the nature of the report is that trip id will change for each record.

The easiest way to display the trip bar code and keep the existing report format is to leave the margin as it is and move the data currently displayed within the Trip Detail section to create space at the top of the Trip Detail section for the trip_id. This will mean that the trip bar code is displayed slightly lower in the report than originally requested, but the report will retain all existing formatting surrounding page set up and margin display.

The report displayed below is a sample of the positioning of the bar code in the report. The black block is where the bar code will appear,

IMAGE

== Changes to the Booking Window ==

The late delivery field has already been formatted to display the time only within the data model.
The trip stop data is formatted depending on the trip stop type – SU or non SU.
This has been done to ensure that the SU trip stop always appears first in the report. Currently within the report the only order information which is displayed against the SU stop is total weight. Following this formatting, we will be displaying late del for non SU stops only.
A conditional formatting trigger will ensure that the late del time is not displayed for SU trip stop records.

= APPENDIX A TABLE UPDATES REQUIRED =

No table changes are required for this development

= APPENDIX B QUOTE & DOCUMENT HISTORY =

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==
{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

252217

2009-02-04T12:30:21Z

Kingj: /* Authorised By */

= 252217 PA-7DWATD Amend Allocate Resource Screen =

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
Re-design the 'Allocate Resource' screen 'TRIP_RES v1.4’ to enable all resource Driver/Tractor/Trailer to be allocated to a trip in the same screen, invoked from the ‘Trip Overview (Waterfall)’ screen pre-populated with Trip details for the Trip highlighted in the ‘Trip Overview (Waterfall)’ screen - Schedule, Trip ID, Status fields, & Driver, Tractor, Trailer fields if any one already resourced.

Pre-populate the listings with Location-based Drivers and Tractors (poplist) and Trailer numbers bound by Trailer Type selected when the Trip was planned.

Add an 'Allocated' field (Tick-Box) alongside each resource to show, as a prompt only, that a resource has already been used. For example, if one user has allocated a driver to a trip that will take him less than a full shift, if this driver is marked as 'allocated' another user would not then additionally allocate him to an 8 hour shift, but it would leave the driver available for a short run on return from his first load. Similarly Tractors and Trailers can be used several times within a schedule but users would be aware if they were already committed to another trip.

Added by PA - Check current functionality of Driver/Tractor being displayed in 'Bold' if allocated - if the function is the same as expected from an ‘Allocated’ field then delete addition of ‘Allocated’ field (tick-box).

Allow Status change to ‘TENDERED’ or ‘ACCEPTED’ only, with or without any resource added as the eventual resource is not always known until the point of departure. The status change control will not allow the trip to be moved to an ‘En-Route’ status without complete resource entry.

== Solution ==
The ‘HEADER’ section of the ‘ALLOCATE RESOURCE’ screen will be changed to include the ‘Carrier Id’ and ‘Trailer Type’ of the ‘Trip Id’ should any have been assigned. It will be possible to change the ‘Trailer Type’ of the ‘Trip Id’ in this screen if a ‘Trailer Id’ has not been assigned: this will enable the user to find the ‘Trailer Id’ required if it is for a different ‘Trailer Type’.

The ‘ALLOCATE RESOURCE’ screen will also be changed so that the ‘Id’, ‘Surname’, ‘Forename’ (i.e. ‘Driver’ details) and ‘Tractor Id’ columns are pre-populated upon entry to the screen with valid records for the ‘Carrier Id’ of the ‘Trip Id’. However, the ‘Driver’ details displayed will also include those drivers with a job title of ‘CONTRACT’ as well as ‘DRIVER’. If the ‘Carrier Id’ does not have any drivers assigned to it then none will be displayed for selection.

Likewise, the ‘Trailer Id’ will be pre-populated with valid records for the ‘Trailer Type’ of the first stop of the ‘Trip Id’ should one have been set, however, if one has not been set then all ‘Trailer Ids’ will be displayed for selection. The ‘Trailer Id’ will be further validated for the ‘Carrier Group’ of the ‘Carrier Id’ set. If a ‘Trailer Id’ is then selected it will be assigned to the first stop of the trip; this is because only the ‘Trailer Id’ of the first stop of the trip is displayed in the screen.

The pre-population and maintenance of the resources for the trip will follow the functionality of the ‘poplist’ display type of the ‘Carrier Id’ regardless of whether it is set to be ‘freetext’; this means that the resources may only be selected from the details displayed and none may be entered as ‘freetext’.

It will be ensured that all details for the selection of resources are not marked as inactive.
If the ‘Driver Id’ (i.e. ‘Surname’ and ‘Forename’), ‘Tractor Id’ and ‘Trailer Id’ are assigned to a ‘Trip Id’ for the ‘Schedule’ that is concurrent with the ‘Trip Id’ selected then the records will be highlighted in grey (i.e. ‘bold’) so that the users know that there is a restriction present; therefore, the layout of the screen will not be changed to include an ‘Allocated’ column.

The ‘Status’ of a ‘Trip Id’ may be progressed to ‘TENDERED’ from ‘PLANNED’ without ‘Driver Id’ (i.e. ‘Surname’ and ‘Forename’), ‘Tractor Id’ and ‘Trailer Id’ assigned but it must have a ‘Carrier ID’ and a ‘Start Time’ set.

The ‘Status’ of a ‘Trip Id’ will be changed so that it may be progressed to ‘ACCEPTED’ from ‘PLANNED’ or ‘TENDERED’ without ‘Driver Id’ (i.e. ‘Surname’ and ‘Forename’), ‘Tractor Id’ and ‘Trailer Id’ assigned but it must have a ‘Start Time’ set. Note that this new validation will be applied throughout MTS.

The ‘Status’ of a ‘Trip Id’ may be progressed to ‘EN-ROUTE’ from ‘PLANNED’ or ‘ACCEPTED’ but not without ‘Driver Id’ (i.e. ‘Surname’ and ‘Forename’), ‘Tractor Id’ and ‘Trailer Id’ assigned, therefore the validation for the progression to ‘ACCEPTED’ may be removed.

== Scope ==
This change will be applied to system version 10.6 on CONTST and once approved CONPRD. This form will be applicable to all MTS environments, as the nature of this change is an addition to functionality and will reduce input time.

= SET-UP =

== Pre-requisites ==
None

== Menu Structure ==
Unchanged

== Data ==
Unchanged

= FUNCTIONAL DESCRIPTION =

== New Functionality ==
Below is a screenshot of what the current TRIP_RES screen looks like. All data has been cleared out:

IMAGE

This screen will be made longer so that ‘Carrier Id’ and ‘Trailer Type’ can be included in the header section. When the screen is opened from the TRIP_OVERVIEW screen, the details for the selected trip will be passed in, and these fields will be populated if they have been assigned.

The newly added ‘Trailer Type’ in the header will have a lookup button next to it that will show a list of all trailer types, when clicked. This will only be active if a Trailer ID has not already been assigned to the Trip. This allows the possibility of changing the trailer type if the trailer id they require does not appear in the ‘Trailer Id’ column for assigning.

The Driver (Id, Surname, Forename) and Tractor data will be pre-populated upon entry to this screen. The data displayed here corresponds to data associated with the Carrier Id assigned to the Trip. Drivers and Tractors can be associated with a Carrier Id within the Maintenance > Resources screen. Currently only Drivers with a Job Title of DRIVER are displayed, but this will be amended to also include Drivers with a Job Title of CONTRACT.

If the Amend Resources screen is opened and the Carrier Id of the selected trip has no Drivers or Tractors assigned to their carrier, then the lists will be empty and the user will not be able to assign a Driver or Tractor in this screen.

Likewise, the Trailer Id list will be pre-populated with those associated to the Trailer Type assigned to the first stop of the trip. If the trip has no Trailer Type set, then all Trailer Ids will be displayed in the list for selection. This list can be filtered using the new lookup button next to the Trailer Type in the header. Selecting a particular Trailer Type will amend the list so that it only displays Trailers associated to the selected Trailer Type. If the user assigns a Trailer to the trip without making use of the Trailer Type lookup button then, when a Save is invoked, the Trailer Type in the header will be updated according to the selected Trailer. The list of Trailers displayed for selection is also further validated according to the Carrier Group of the Carrier Id for the trip. The select Trailer Id will be assigned to the first stop of the trip.

Also note that for population of data in all lists in the Amend Resources screen, only data that is active will be displayed. The Maintenance > Resources screen can be referenced to see how all data is associated.

Resources can only be added through selection from the pop-lists. It will not be possible to assign resources in this screen using free-text.

Below is an example of the layout of what the new screen should look like:

IMAGE

If the Driver (Id, Surname, Forename, Tractor and Trailer are assigned to a Trip for the Schedule that is concurrent with the schedule of the trip selected, then these records will be highlighted in grey with bold text, so that it is evident to the user’s, those resources that have a restriction.

Below is what the screen should look like:
Note that the lookup button next to the Trailer Type is inactive as the trip already has a Trailer assigned.

IMAGE

'''PLEASE NOTE – all Trip Status changes in screen TRIP_RES will done in accordance with the conditions set out in RIO PA-7DJLS6 (252344 Set Parameter for Trip Status change).'''

== Code Additions and Amendments ==
The addition of the new ‘Trailer Type’ lookup requires a new button to be added to the TRIP_RES screen. When this is clicked it will call a newly created LOV named TRAILER_TYPE. This LOV will contain the following query:

SELECT rt.trailer_type, rt.description
FROM res_trailer_type rt
WHERE rt.inactive != ‘Y’
ORDER BY rt.trailer_type;

This will open a lookup table of all active trailer types.

When a ‘Trailer Type’ is selected this will list all associated active ‘Trailer Id’s’ in the list for selection.
The following query will be used on the Trailer Data Block to filter the list of Trailer Id’s shown according to the Trailer Type selected in the header:

SELECT rt.trailer_id
FROM res_trailer rt
WHERE (NVL(rt.inactive. ‘N’) <> ‘Y’)
AND rt.trailer_type = :SCH_TRIP_STOP.trailer_type
AND EXISTS
(
SELECT 1
FROM res_trailer_carrier_group g,
WHERE g.trailer_id = rt.trailer_id
AND (NVL(g.inactive. ‘N’) <> ‘Y’)
AND g.name = (SELECT rc.group_name
FROM res_carrier rc
WHERE rc.carrier_id = :SCH_TRIP.carrier_id)
)
ORDER BY rt.trailer_id

The list of Drivers currently displayed for selection in TRIP_RES, is those associated with the current Carrier and with a job title of DRIVER. This will be updated to also include Drivers with a job title of CONTRACT, and also will not include those that have been set as inactive. The sql select statement required to display this will be:

SELECT p.id, p.surname, p.forename
FROM res_person p
WHERE UPPER( p.job_title ) = 'DRIVER'
OR UPPER( p.job_title ) = 'CONTRACT'
AND (NVL(p.inactive. ‘N’) <> ‘Y’)
AND EXISTS
(
SELECT 1
FROM res_person_carrier pc
WHERE p.id = pc.id
AND pc.carrier_id = :SCH_TRIP.carrier_id
)
ORDER BY p.surname, p.forename

== Trigger Updates ==
The following triggers will be applied to Data Block Trailer:

PRE-QUERY - will create a string of trailer ids that are currently in use between the currently selected trip start time and trip end time
POST-QUERY - will highlight in grey and bold those trailer ids that appear in the string created during pre-query.

This will then bring to the user’s attention those trailer ids that are in use between the selected trip start and end time and therefore have restrictions on them.

The code for the PRE-QUERY trigger will take the following form:

DECLARE

CURSOR c_alloc_trailers IS
SELECT trailer_id
FROM sch_trip
WHERE trailer_id IS NOT NULL
AND start_time BETWEEN :sch_trip.start_time AND :sch_trip.finish_time
OR ( start_time + ( elapsed_time / 1440 ) )
BETWEEN :sch_trip.start_time AND :sch_trip.finish_time;

BEGIN

:ctrl.tractor_str := NULL;

FOR cr_alloc_tractors IN c_alloc_tractors LOOP
:ctrl.tractor_str := :ctrl.tractor_str || '/' || cr_alloc_tractors.tractor_id;
END LOOP;

:ctrl.tractor_str := :ctrl.tractor_str || '/';

END;

The code for the POST-QUERY trigger will take the following form:

DECLARE

BEGIN
IF INSTR( :ctrl.tractor_str, :tractor.tractor_id || '/' ) > 0 THEN

SET_ITEM_INSTANCE_PROPERTY( 'TRAILER.TRAILER_ID', CURRENT_RECORD, VISUAL_ATTRIBUTE, 'ALLOCATED' );

END IF;
END;

Where VISUAL_ATTRIBUTE of type ALLOCATED it set to display the current record in bold with a grey background as described below:

IMAGE

= APPENDIX A =
TABLE UPDATES REQUIRED

No table changes are required for this development.

= APPENDIX B =
QUOTE & DOCUMENT HISTORY

== References ==

IMAGE
== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==
{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

252344

2009-02-04T12:29:43Z

Kingj: /* Authorised By */

= 252344-PA-7DJLS6 Change to Trip Status =

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
To encourage completion of data input into each trip by controlling minimal input requirement to allow Status change.

Planned to Tendered: Addition of Carrier including Own Fleet,Subcontractor or EFX/CNFX(Internal)

Tendered to Accepted: Own Fleet - Addition of Driver, Tractor ID, Trailer ID, Subcontracted - Confirmation of Carrier and Trip Cost

Accepted to EnRoute: Addition of Trip departure Time - all carriers, add in Subcontractor Driver/Vehicle/trailer - optional - Error Message on screen [Please Complete Carrier Details], Error Message on screen [Please Add Departure Details] when Status being changed to ENROUTE if departure times are incomplete.

EnRoute to Completed: Only possible in Debrief screen when Debrief details are complete. Error Message on screen [Please Confirm or Amend debrief details] if incomplete
Final Status change within Debrief screen to Confirmed.

Include the option to Configure Debrief Confirmation without POD (where appropriate) Error Message on screen where applicable [Please complete POD Confirmation] This error to be capable of being switched off where POD's are not required to change Trip status to CONFIRMED

Confirmed releases Orders for invoice and changes Forecast Values to Actual (Link to Oracle specifications pending)

Only allow status changes: PLANNED TO TENDERED, PLANNED TO ACCEPTED, TENDERED TO ACCEPTED, ACCEPTED TO EN-ROUTE,EN-ROUTE TO COMPLETED, COMPLETED TO CONFIRMED

Add additional Tab in System Parameters.

Parameter to be set at a high-level of admin rights

== Solution ==
All programs that change the trip status (Trip Planning, Trip Summary, Trip Manipulation, Trip Waterfall, Trip Debrief and EFX Acceptance edi flow) call the procedure SET_TRIP_STATUS within the TRM package.

We already have system parameters called ‘TRM_DRIVER_RQD_FOR_ENROUTE_OR_ACC’, ‘TRM_TRACTOR_RQD_FOR_ENROUTE_OR_ACC’, ‘TRM_TRAILER_RQD_FOR_ENROUTE_OR_ACC’ and ‘TRM_SET_TO_COMPLETED’.

This existing functionality will be extended in the TRM package to also check if the Carrier ID is the same as the Owning Depot (Own Fleet) for a trip. If it is Own fleet then the Driver, Tractor, Trailer will error when changing status to EN-ROUTE and no errors will be displayed when moving to status ACCEPTED or for trips being done by sub-contractors.

NB) The trailer validation currently checks all stops for a trip but this will be changed to only check the first stop which will probably be the SU stop and at the same time it will check that the actual departure time is set for this first stop when moving up to EN-ROUTE status.

Additional validation will also be added to the EN-ROUTE status check to ensure that the Carrier ID is populated.

Additional validation will be added to the COMPLETE status check to ensure that all of the debrief fields have been populated.

The check for the POC/POD flags when setting to COMPLETED status which already uses the TRM_SET_TO_COMPLETED system parameter when set to 'POC/POD' will be extended to return an error message if POC/POD flags are not set. The trip debrief form will then either display the returned error message as an error or a warning depending on whether the call failed or not.

== Scope ==
This change will be applied to system version MTS V10.6.0 for Consumer.

= SETUP =

== Pre-requisites ==
None.

== Menu Structure ==
Unchanged.

== Data ==
None.

= FUNCTIONAL DESCRIPTION =

== TRM Package ==
Already within the TRM package there is a procedure called SET_TRIP_STATUS that is used by everything in the system to validate and perform any requests to change the status of a trip.

This code will be amended to add the new required functionality depending on a new system parameter called ‘TRM_NEW_TRIP_STATUS_CHECKS’.

Moving a trip on from status ‘PLANNED’ to status ‘TENDERED’ already has all of the required code (Carrier ID check) so does not need any changes.

‘TENDERED’/’PLANNED’ to ‘ACCEPTED’ already uses 3 system parameters called ‘TRM_DRIVER_RQD_FOR_ENROUTE_OR_ACC’,
‘TRM_TRACTOR_RQD_FOR_ENROUTE_OR_ACC’ and
‘TRM_TRAILER_RQD_FOR_ENROUTE_OR_ACC’.

These are used to determine if each of those resources is required to have been entered in order to move the trip status on the ACCEPTED from either TENDERED or PLANNED.

If the new system parameter TRM_NEW_TRIP_STATUS_CHECKS is set to ‘Y’ then this code can be totally ignored when moving to ACCEPTED status as the resources are no longer required to have be entered until the EN-ROUTE stage.

‘ACCEPTED’/’PLANNED’ to ‘EN-ROUTE’ is coded in exactly the same way as when moving to status ACCEPTED.

This will be extended to check to see if the Owning Depot for the Trip matches the Carrier ID for the trip. If they match then the trip is considered to be being done by DHL’s own fleet rather than an external sub-contractor.

NB) If somehow one of these fields has not been set than an appropriate error message will be returned as these 2 fields should have been set at trip creation stage.

If the TRM_NEW_TRIP_STATUS_CHECKS is set to ‘Y’ and the trip is being done by a sub-contractor then there is now no need to check the resources (regardless of the resource system parameters) as the resources are now only required to be entered for own fleet trips.

If the trip is being done by DHL’s own fleet and the appropriate system parameters are set then the corresponding resource must have been entered before allowing the status to be updated otherwise an error is returned to the calling program.

When the driver (SCH_TRIP.DRIVER_ID) has not been entered for an Own Fleet trip and the TRM_DRIVER_RQD_FOR_ENROUTE_OR_ACC flag is set to ‘Y’ then the following error will be returned :-

‘Can not change the trip to status EN-ROUTE as the Driver ID is required for Own Fleet trips’.

When the tractor (SCH_TRIP.TRACTOR_ID) has not been entered for an Own Fleet trip and the TRM_TRACTOR_RQD_FOR_ENROUTE_OR_ACC flag is ‘Y’ then the following error will be returned :-

‘Can not change the trip to status EN-ROUTE as the Tractor ID is required for Own Fleet trips’.
The trailer ID is entered at trip stop level not at the trip level so the code will need to check the first stop (usually the ‘Start Up’ stop) to see if a Trailer ID (SCH_TRIP_STOP.TRAILER_ID) has been entered and if not when the TRM_TRAILER_RQD_FOR_ENROUTE_OR_ACC is set to ‘Y’ then the message can say :-

‘Can not change the trip to status EN-ROUTE as the Trailer ID is required for Own Fleet trips’.

Also additional code will be added to ensure that the first stop also has an actual departure time (SCH_TRIP_STOP.ACTUAL_DEPART). If it does not and the TRM_NEW_TRIP_STATUS_CHECKS is set to ‘Y’ then return the error :-

‘Can not change the trip to status EN-ROUTE until the departure time from the first stop has been entered’.

NB) This last error applies to both Own fleet and Subcontractor trips.

’EN-ROUTE’ to ‘COMPLETED’ can only be done once all of the actual date/times have been entered in the debrief screen.

If the TRM_NEW_TRIP_STATUS_CHECKS flag is set to ‘Y’ then check all of the trip stops and ensure that they all have an actual arrival (SCH_TRIP.ACTUAL_ARRIVE) and departure (SCH_TRIP.ACTUAL_DEPART) date/times set. If not then error with :-

‘Can not change this trip to status COMPLETED until all of the actual arrival and departure date/times have been entered’.

‘COMPLETED’ to ‘CONFIRMED’ already has code to check the ‘TRM_SET_TO_COMPLETED’ system parameter.

If this parameter is set to ‘POC/POD’ then the code already ensures that all POC and POD flags have been set for all orders on the trip before allowing the trip to be moved to CONFIRMED status.

The only code change required is to return a error message (not an actual error) when all of the POC/POD flags are not set regardless of the system parameter in order for the Trip Debrief Screen to give a warning to the user that not all POC/POD flags are set.

== Trip Debrief Form ==

An error message may be returned by the TRM.SET_TRIP_STATUS even though the call to the package was successful.

If this occurs then the message should be displayed as a warning in order to inform the user that they are setting the trip to status ‘COMPLETED’ without having ticked all of the POC/POD flags for all of the orders on the trip.

= APPENDIX A TABLE UPDATES REQUIRED =

No table changes are required for this development.

= APPENDIX B QUOTE & DOCUMENT HISTORY =

IMAGE

== References ==

IMAGE

== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==
{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}

252336

2009-02-04T12:29:04Z

Kingj: /* Authorised By */

= 252336 PA-7DGNK2 Change Schedule Date of a Scheduled Trip =

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied

= FUNCTIONAL OVERVIEW =

== Client Requirement ==
For Trips in Statuses PLANNED, TENDERED and ACCEPTED To be able to retain a scheduled Trip ID with associated orders and transfer as one to an alternative schedule date if required after the trip has been built and a loading schedule issued for the original date.
Invoke change by 'Right-Click' Drop-down box [Change Schedule Date]
When the Trip schedule date is changed automatically update the Order Scheduled delivery date for all orders on the Trip.
Delete any resources added into the Trip on the original schedule date and revert CARRIER to OWNING DEPOT on new schedule date

== Solution ==
Changing the Schedule name (SCHED_NAME) of a specific trip can be done, but due to referential integrity (links between data) we will have to follow specific steps to complete the change.
Several tables have keys which are based on a combination of the SCHED_NAME and TRIP_ID fields. In these tables we cannot simply update SCHED_NAME as this would violate existing constraints and the Oracle Database would not allow the change.

To work around this we must make a copy of the record(s) we want to change. In the copy record we then update the SCHED_NAME. Once the record has been created and updated, we can remove the original record.

To ensure that we comply with all the data constraints we must copy and update the records from the top (SCH_TRIP table) down and then delete the original records from the bottom (SCH_TRIP_STOP, SCH_TRIP_AUDIT tables) up to SCH_TRIP table.

Several tables, where SCHED_NAME is a simple foreign key, the SCHED_NAME can be updated without requiring copies and deletions.

To allow you to understand the scope of this change, the referential integrity issues will effect 9 tables, with another 11 tables requiring some manipulation and updating. (please see diagram attatched)

In addition to the record changes above, we need to identify which orders have been assigned to the trip using the SCH_HAULAGE_ACTIVITY table. We then update the SCHED_NAME in the SCH_ORD table for all the identified orders and update the late delivery field to match the new schedule.

To update the late delivery field, we intend to amend the date part only, to match the new SCHED_NAME and retain the time from the original schedule.
Set Driver_id, trailer_id and tractor_id to Null in the old record in SCH_TRIP table and set Trailer_id to Null in the new record in the SCH_TRIP_STOP table.
Update Carrier_ID on new SCH_TRIP record to equal the OWNING_DEPT.
These changes will all be completed within a new Package on the form and will be launched from the Trip Tree menu. A new menu option will be added called – ‘Change Schedule date’. Selecting this option will launch the new package.

IMAGE

== Scope ==
This change will be applied to system version 10.5.0 on CONTST and once approved CONPRD.

= SET-UP =

== Pre-requisites ==
None

== Menu Structure ==
Pop up menu Trip Tree Menu will be amended to include a new menu item called ‘Change Schedule Date’ When this is launched, the status of the existing scheduled trip will be checked. If the status is not ‘PLANNED’, ‘TENDERED’ or ‘ACCEPTED’ the user will be told they cannot change the date. If the trip is the required status, a small input form will launch where the user can enter the new schedule date.

== Data ==

The new schedule date will be stored in a non-database item and used as reference for amending the relevant records. The schedule date field , on the new screen will include a list of values, which will be populated based on the schedules available in the database. The user must select a value form this list.

=== Copying data. ===

In the following tables, we will create records based on the new schedule date, where all other values are the same for the trip that is being amended.

Insert into SCH_TRIP (sched_name, trip_id)
VALUES (:change_schedule.new_schedule, :trip_dtl.trip_id)

Commit;

Update SCH_TRIP
SET (all other fields) =
SELECT (all other fields FROM SCH_TRIP where sched_name =:trip_dtl.sched_name and trip_id = :trip_dtl.trip_id)
where sched_name =:change_schedule.new_schedule and trip_id = :trip_dtl.trip_id;

Commit;

There are now two records on the table for the same trip, one referencing the original Schedule name and one referencing the new schedule name. We must continue this process for all tables which reference the schedule_name as part of its primary key.

Before we can carry out the above steps we must first use cursors to check if the selected trip/ schedule have any related records in each table. Only if we find a related record do we insert and update. Otherwise we do nothing with the table.

=== Updating Data ===

Having identified the rest of the tables which reference the schedule name, we must update the relevant record(s) to reference the new schedule_name.

The order records associated with the selected trip must be updated to reflect the new schedule date and a new late delivery time. The order table does not include the trip id, so identifying the relevant orders will require linking three tables, SCH_TRIP_STOP, SCH_HAULAGE_ACTIVITY, SCH_ORD. Once the relevant records in SCH_ORD have been identified, validation will be required to ensure that the amended LATE DELIVERY DATE meets all the existing checks. We are not intending to make any changes to the late delivery time, this will simply inherit the existing value.

The last updates to be completed will remove all resources from the old trip and amending the carrier to be the owning company. In this instance, resources refers to drivers, tractors and trailers. As the old records are to be deleted, this will in fact remove the resources from the original trip.

=== Deleting Data ===

In several tables, there are now two trip records, each referencing a different schedule name . This will be confusing as users will not be aware which is the relevant trip. For this reason , all duplicate trip records , where the old schedule is referenced will be deleted.

Just as when we inserted data, we did so in s specific order, deleting data must also be carried out in a specific order, starting with the following tables

ACC_INVOICE_TRIP
PNL_COST_APPORT
SCH_TRIP_AUDIT
PNL_REV_APPORT
RTE_ROUTE_TRIP
TMP_SCHED_TRIP
SCH_ORD_NON_CONFORM
SCH_TRIP_STOP

And ending with the SCH_TRIP table.

= FUNCTIONAL DESCRIPTION =
This change will allow the user to select a trip, enter a different schedule date and move all the related trip information to the new schedule date. This process will be completed in three steps.

1. The user selects the trip from the trip tree and from the right click menu selects the option ‘Change Schedule Date’. If the trip is in the correct status, an input form is launched.

2. The user selects the new schedule date from the list of schedule dates available. For a schedule date to be available in the list, it must exist in the SCH_SCHEDULE table.

3. The user selects OK . In the background a package is launched which carries out all the required data changes. As the final change is deleting the record that is currently on display in the form, this is an event the OK command button must handle.

== OK Command Button ==

After carrying out all the data changes as described in the previous Data section, this button must handle the event where the record that is currently being displayed on the form is deleted.
This will be achieved by clearing the data block, then setting the schedule name to be the new schedule and executing a query. This code will run after all the data changes have been committed.

== Cancel Command Button ==

This will allow the user to cancel the schedule date change, but only before they select OK. Once OK has been selected, this cannot be cancelled. Users would be able to use the ‘Change Schedule Date’ functionality to revert the trip back to its original schedule date.

IMAGE

The above screen shot shows a trip selected in the trip tree and the right click function which launches a pop up menu. This is where the option to ‘Change Schedule Date’ will be available.

= APPENDIX A TABLE UPDATES REQUIRED =

No Table Changes are Required for this development.

= APPENDIX B QUOTE & DOCUMENT HISTORY =

IMAGE

References

IMAGE

== Glossary ==

IMAGE

== Document History ==

IMAGE

== Authorised By ==
{| border="1"
| '''''Dave Meir'''''
| Development Manager
|-
| '''Suk Sandhu'''
| TMSCC MTS Product Manager
|}