Pool Point
From UG
(→Pool Point Criteria) |
(→Pool Point Criteria) |
||
Line 18: | Line 18: | ||
There is a multi level process on how the system should check to see if a shipment should go through a pool point. | There is a multi level process on how the system should check to see if a shipment should go through a pool point. | ||
- | *1st the system should check | + | *1st the system should check CT record against the [[#PP_conditions]] |
+ | ** If record meets the [[#PP_conditions]] | ||
- | + | The system should: | |
+ | * Split the CT record into 2 parts and send to the TM | ||
+ | ** One from the orgin address to the pool point | ||
+ | ** Another from the PP to the delivery location | ||
+ | * Give some sort of Pool Point note on the TDS | ||
+ | * Give some sort of an option for Jag operators to override the systems Pool Point decision. | ||
- | + | 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. | |
- | + | ||
- | + | ||
- | + | ||
- | Note: It is possible that CT | + | |
*One reason could be that the shipment is very urgent. | *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. | *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 === | === Exceptions === |
Revision as of 17:52, 8 December 2010
Contents |
Info
Mantis: 2597
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 go through a pool point.
- 1st the system should check CT record against the #PP_conditions
- If record meets the #PP_conditions
The system should:
- Split the CT record into 2 parts and send to the TM
- One from the orgin address to the pool point
- Another from the PP to the delivery location
- Give some sort of Pool Point note on the TDS
- Give some sort of an option for Jag operators to override the systems Pool Point decision.
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 Exceptions of the #PP_conditions.
In this case, the system should:
- Not send to the TM
- Give some sort of an alert on the TDS
- Give option to users to send 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, then the shipment should route the CT through a pool point.
If CT record, CT_bo#Shipper_State = NY, NJ, or CT And CT_bo#Consignee_State = VA OR ME And Commodity#Plts > 60 And Commodity#Stackable = Y And Commodity#Gross_Lb is > 44,000 lbs
OR
If CT record, CT_bo#Shipper_State = TN, GA, NC, SC, or VA And CT_bo#Consignee_Address = NY, NY (Manhattan, aka NYC) And Commodity#Plts > 60 And Commodity#Stackable = Y And Commodity#Gross_Lb is > 44,000
OR
If CT record, CT_bo#Shipper_State = NY, NJ, or CT And CT_bo#Consignee_State = VA or ME And Commodity#Plts > 28 And Commodity#Stackable = N And Commodity#Gross_Lb is > 44,000
OR
If CT record, CT_bo#Shipper_State = TN, GA, NC, SC, or VA And CT_bo#Consignee_Address = NY, NY (Manhattan, aka NYC) And Commodity#Plts > 28 And Commodity#Stackable = N And Commodity#Gross_Lb is > 44,000 lbs
Regular conditions
If CT record meets the below criteria, the system would not route through a pool point.
If CT record, CT_bo#Shipper_State = NY, NJ, or CT And CT_bo#Consignee_State = VA OR ME And Commodity#Plts = 60 And Commodity#Stackable = Y And Commodity#Gross_Lb = 44,000 lbs
OR
If CT record, CT_bo#Shipper_State = TN, GA, NC, SC, or VA And CT_bo#Consignee_Address = NY, NY (Manhattan, aka NYC) And Commodity#Plts = 60 And Commodity#Stackable = Y And Commodity#Gross_Lb = 44,000
OR
If CT record, CT_bo#Shipper_State = NY, NJ, or CT And CT_bo#Consignee_State = VA or ME 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 And CT_bo#Consignee_Address = NY, NY (Manhattan, aka NYC) And Commodity#Plts = 28 And Commodity#Stackable = N And Commodity#Gross_Lb = 44,000 lbs
Design Ideas
To 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 criteria: have the system would then create 2 copies of that 1 record in the background - 1 from the pickup location to the pool point and 1 from the pool point to the deliver to location.
- IE CT 121245 has 8 pallets at 1500 lbs, coming from Edison, NJ - going to Roanoke, VA. The system creates 1 CT # 121245a at 8 pallets at 1500 lbs, coming from Edison, NJ - going to the Jewels Transportation in Newark, NJ (they are the pool point). Then the system creates the second 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. Then send these 2 records 121245a & 121245b to the TM, for the Jag ops to work with. Upon carriers tender acceptance in the TM & their updating of the pickup/delivery dates, the system would update the original CT # 121245 only, as received on the status update from the TM, because both a & b records are in the background.
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
- (do we need to add Exceptions criteria to admin panel or its must be hardcoded ?)
- 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.
- Answer 2: Recheck the changes to see if it makes any difference according to the pool point criteria.
- 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:
- CTs that must be routed automatically through PP (#PP algorithm), see #PP conditions
- CTs that must be routed as "regular CT" (#Regular algorithm), see #Regular conditions
- human intervention required (#Exception algorithm), see #Exception conditions
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 "current Arden project 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 and direct system to use #Regular algorithm or #PP algorithm
pick ups
As system d
Figure: PP
RFP
Proposal required before coding.