Pool Point

From UG

(Difference between revisions)
Jump to: navigation, search
(→Figure: PP)
(→Ver 2)
Line 265: Line 265:
= Ver 2 =
= Ver 2 =
-
Parent mantis: 4168
+
Parent mantis: '''4168'''
 +
 
 +
== Definitions ==
 +
 
 +
=== Non Stop ===
 +
 
 +
CT is moving '''Non stop''' if it moves from Pick Up to Delivery Location with one carrier (truck/plane/ship) without a stop that needs to be recorded in the system.
 +
 
 +
In this case trip has one '''leg'''.
 +
 
 +
=== Multi Stop ===
 +
 
 +
In this case CT has a stop that we want to register in the system.
 +
 
 +
In some cases stops result in change of a carrier.
 +
 
 +
Such trips have more than one leg:
 +
 
 +
"Pick Up Location -> Stop1 -> Stop2 -> ... Stop N -> ... -> Delivery Location"
 +
 
 +
One special type of stop is a [[#Pool Point]].
 +
 
 +
=== Pool Point ===
 +
 
 +
Pool Point is a special location that is used for transferring and consolidation of CTs/commodities.
 +
 
 +
See example below.
 +
 
 +
[[File:Pool point.jpg| 600px]]
== Ver 2 Business Needs ==
== Ver 2 Business Needs ==
Line 278: Line 306:
** tag CT as "delivered" / send "delivered" message to client users only if delivered to Delivery Location (not a Pool Point)
** tag CT as "delivered" / send "delivered" message to client users only if delivered to Delivery Location (not a Pool Point)
-
== Ver 2 Solution ==
+
== Ver 2 Systems Analysis ==
-
Technical Note#1
+
=== Implementing Multi Stops ===
-
---------------
+
 
-
It was suggested to increment database structure to be able to collect info about multi stop.
+
It was suggested to increment database structure to be able to collect info about [[#Multi Stop]].
-
(such as  "Pick Up -> Stop1 -> Stop2 -> ... Stop N -> ... -> Delivery")
+
 
-
For just 2 leg trips such as "Pick Up -> Pool Point/Stop -> Delivery" we could have created a simpler solution.
+
For just 2 leg trips such as "Pick Up -> Pool Point/Stop -> Delivery" we could have created a simpler solution. But this would limit us in the future.  
-
But this would limit us in the future.  
+
 
-
Note that this will be used across all MOTs in the future.
+
Note that this will be used across all MOTs in the future.
 +
 
 +
== Ver 2 Solution ==

Revision as of 19:35, 1 July 2013


Contents

Info

"Pool Point" is a project. Main goal is to add Pool Point concept to the CT2 system.

First attempt was in 2010. See #Ver 1. This was never implemented.

Second attempt is current (2013). See #Ver2.

Ver 1

Mantis: 2597

This has been put on Hold = Status X as MO wants for Descartes to provide this feature.

Business Requirements

This about adding the concept and functionality into CT2 for pool point shipments according to the Arden domestic business process.

Core Business Need: Currently the Arden domestic team is using the TMS to create and tender loads from the same origin company/city going to VA and/or ME by using a pool point. One trucker who collects all of the pickups through out the day and another trucker who picks up all of them to deliver. Since the Arden team creates multiple pool point loads throughout the day from different origins, the TM will always create 2 loads - one from the pickup location to the pool point and the other from the pool point to the delivery location. But in reality the delivery will only be 1 or maybe 2 trailer loads, as the pool point has consolidated them and this is causing inaccurate trailer counts for reporting purposes.

Pool Point Criteria

Currently there is 1 pool point - Jewels Transportation, who are in Newark, NJ. They collect all of the Tri-State area (NY, NJ, CT) pickups and once the shipments are back in their warehouse, they load empty trailers for the delivery carriers (Lawrence Transportation &/or Albert Farms).

There is a multi level process on how the system should check to see if a shipment should route through a pool point.

  • 1st the system should check CT record against the #PP_conditions
    • If CT record meets the #Regular_conditions, the system should not route through the pool point.
    • If record meets the #PP_conditions the system should route through the pool point.

Note: It is possible that CT record meets the #PP_conditions and the business side does not want to send through the pool point for a few different reasons.

  • One reason could be that the shipment is very urgent.
  • Another reason could be that it's not cost effective, as the size of the shipment (number of pallets and gross weight) are high, but fall into the exception category.

Exceptions

The system would check the CT record to see if it meets the Exception Criteria of the #PP_conditions.

If Y, the system should:

  • Not send to the TM
  • Give some sort of an alert on the TDS
  • Give option to users to route through pool point or not
    • Upon users confirmation, send to TM accordingly

PP conditions

I somewhat defined the conditions under #Pool_Point_Criteria and have better defined them here. If a CT record meets the following criteria and is less than the exception criteria below, then the shipment should route the CT through a pool point.

If CT record CT_bo#Shipper_State = NY, NJ, or CT

OR

If CT record CT_bo#Shipper_State = TN, GA, NC, SC, or VA

OR

If CT record CT_bo#Shipper_State = NY, NJ, or CT

OR

If CT record CT_bo#Shipper_State = TN, GA, NC, SC, or VA

Exception Criteria:

CT record meets #PP_conditions but has:

OR

CT record meets #PP_conditions but has:

Regular conditions

If CT record CT_bo#Shipper_State = NY, NJ, or CT

OR

If CT record CT_bo#Shipper_State = TN, GA, NC, SC, or VA

OR

If CT record, CT_bo#Shipper_State = NY, NJ, or CT

And Commodity#Plts = 28 And Commodity#Stackable = N And Commodity#Gross_Lb = 44,000

OR

If CT record CT_bo#Shipper_State = TN, GA, NC, SC, or VA


Use Cases

UC 1 CT Record 5 is shipping from NJ, at 56 stackable plts at 41000 lbs.

This CT's criteria would be an "exception" under the #PP_conditions and Jag Operator will review if CT needs to go through a PP or not.

UC 2 CT Record 2 is shipping from NY, at 3 plts at 325 lbs.

This CT's criteria meets the #PP_conditions and no need for Jag operator to review, it should send automatically to the TM sub CT records 2a & 2b.

UC 3 CT Record 9 is shipping from NJ at 15 stackable plts at 11000 lbs

This CT's criteria meets the #PP_conditions in full as it is also less then the exceptions criteria and is sent to the TM as sub CT records 9a & 9b.

Jag operator checks to find that if they were to route this through the PP, it would cost Elizabeth Arden more money than if they were to route by sending a truck load.

Now jag operator needs to cancel the sub CT records (9a & 9b) that were sent to the TM and has to route the CT record # 9 as if it was sent to the TM under the #Regular_conditions.

Descartes advised if/when an operator cancels a shipment # (CT record) in the TM, they cannot send any type of status message back to CT, as they only send message once a shipment (CT record) is apart of a load.

So in this case, there is no need to use the sub CT records 9a & 9b. So how these “sub CT records” (the a & b) be handled from our side, as Descartes cannot provide an update message that the shipments were canceled in the TM?

UC 4 CT Record 6 is shipping from CT at 1 plt at 125 lbs

This CT's criteria meets the #PP_conditions and is sent to the TM as sub CT records 6a & 6b.

An hour later, Jag operator receives an e-mail or phone call from Elizabeth Arden who says that this shipment is needed ASAP at their facility.

Jag operator checks with PP trucker & delivery trucker to see if they can get this picked up today and delivered tomorrow, but pickup trucker cannot pickup today.

Now jag operator needs to cancel the sub CT records (6a & 6b) that were sent to the TM and has to route the CT record # 6 as if it was sent to the TM under the #Regular_conditions.

Descartes advised if/when an operator cancels a shipment # (CT record) in the TM, they cannot send any type of status message back to CT, as they only send message once a shipment (CT record) is apart of a load.

So in this case, there is no need to use the sub CT records 9a & 9b. So how these “sub CT records” (the a & b) be handled from our side, as Descartes cannot provide an update message that the shipments were canceled in the TM?

Design Ideas

Have the system check every approved CT record to see if meets the #Pool Point Criteria before sending them to the TM.

  • If record meets the #Pool Point Criteria:
    • the system create 2 sub records of the same CT record in the background.
      • One from the pickup location to the pool point.
      • Another from the pool point to the deliver to location.
    • Then send the 2 background records to the TM for Jag operators to create loads and tender to carriers.
  • When TMS load plans are received & status messages, the system would update the original CT # 121245 only as the 2 are sub records in the background.

IE: CT 121245 has 8 pallets at 1500 lbs, coming from Edison, NJ and is going to Roanoke, VA. The system would creates CT # 121245a at 8 pallets at 1500 lbs, coming from Edison, NJ going to the pool point, Jewels Transportation in Newark, NJ and send to the TMS. At that same time, the system would create CT # 121245b at 8 pallets at 1500 lbs, coming from the pool point Jewels Transportation in Newark, NJ, going to the deliver to location in Roanoke, VA and send to the TMS.

  • Need some sort of a way to "override the systems pool point decision" in the case of business needs.

SA Notes

Summary

1) Add admin panel Pool Point with Pool Point adresses and states criteria, the total number of pallets & total gross weight criteria.
  • (do we need to add Exceptions criteria to admin panel or its must be hardcoded ?)
    • Answer 1: Yes, pls add to admin panel, do not hard code so we may change if necessary according to business rules
2) what should we to do if CT was edited (total GW and other) ?
  • Answer 2: Recheck the changes to see if it makes any difference according to the pool point criteria.
    • If yes, do not send the changes to TMS and give some sort of message to the internal user, so they can update according to the business process.
    • If no, send the changes to TMS, the same way we handle it now.
      • To advise, it would be only the internal users who would make changes to this information.
3) Can TMS work with CT# that contains characters? by example, '111111a'.
  • Answer 3: Yes they can work with alphanumeric shipment #'s

Implementation

What we need to do in:

Admin

Add admin tab with tables:

1) Pool Points:
  • Name
  • Adress
2) States criteria:
  • original state,
  • destination state,
  • Pool Point.
3) Parameters (min(for request operator) , max (for reject Pool Point)):
  • Total gross weight,
  • Total pallet count (non-stack),
  • Total pallet count (stackable)

Shipments

  • New CT fields (GenTab ?):
    • Pool Point
    • Actual Pool Point Delivery Date
    • Actual Pool Point PickUp Date

TDS dashboard

  • add collumn "Pool Point" with number of approved CTs whose need operator's attention to create Pool Point.

LA Notes

PP - Pool Point.

3 cases

Looks like we have 3 cases:

Regular algorithm

  • forward CT as it gets approved directly to TMS

PP algorithm

  • for one CTX create 2 "child records": one CTXa from Pick Up to PP, another CTXb from PP to Delivery
  • forward CTXa to TMS for immediate processing (need to order pick up ASAP)
  • forward CTXb to TMS for later processing (operator will order pick up from PP to delivery at "Pool time" in TMS)

Pool time

In general it would be some kind of schedule regulating when to move CTs accumulated at PP and route various destinations.

In case of "Jewels pool point" it happens once a day at 4pm.

This should not be captured in the system.

Exception algorithm

Post every such CT on special dashboard

Several times a day before Pool Time operators will examine CTs posted to dashboard. Per CT or group of CTs they will make decision and direct system to use #Regular algorithm or #PP algorithm

Pick ups

TBD

RFP

Proposal required before coding.

Marc has asked Descartes to correct the TM according to our (and other customers) business needs and to put the CT2 PP concept on hold. --Denise 12:01, 9 December 2010 (EST)

Ver 2

Parent mantis: 4168

Definitions

Non Stop

CT is moving Non stop if it moves from Pick Up to Delivery Location with one carrier (truck/plane/ship) without a stop that needs to be recorded in the system.

In this case trip has one leg.

Multi Stop

In this case CT has a stop that we want to register in the system.

In some cases stops result in change of a carrier.

Such trips have more than one leg: 

"Pick Up Location -> Stop1 -> Stop2 -> ... Stop N -> ... -> Delivery Location"

One special type of stop is a #Pool Point.

Pool Point

Pool Point is a special location that is used for transferring and consolidation of CTs/commodities.

See example below.

Ver 2 Business Needs

  • add a concept of Pool Point to CT2
    • store them in the system with associated address and name
  • when load info is passed from TMS to CT2:
    • identify if this load is:
      • from Pick Up to Delivery Location (1 leg regular trip) or
      • from Pick Up to Pool Point or from Pool Point to Delivery Location (2 leg trips)
    • tag CT as "delivered" / send "delivered" message to client users only if delivered to Delivery Location (not a Pool Point)

Ver 2 Systems Analysis

Implementing Multi Stops

It was suggested to increment database structure to be able to collect info about #Multi Stop.

For just 2 leg trips such as "Pick Up -> Pool Point/Stop -> Delivery" we could have created a simpler solution. But this would limit us in the future.

Note that this will be used across all MOTs in the future.

Ver 2 Solution

Retrieved from "https://wiki.jaguarfreight.com/Pool_Point"
Personal tools