Pool Point
From UG
(→Summary) |
(→TMS Load Viewer) |
||
(151 intermediate revisions not shown) | |||
Line 2: | Line 2: | ||
= Info = | = 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 = | ||
+ | '''This section was commented out.''' | ||
+ | |||
+ | <!-- | ||
Mantis: [http://mantis.jaguarfreight.com/mantis/view.php?id=2597 2597] | Mantis: [http://mantis.jaguarfreight.com/mantis/view.php?id=2597 2597] | ||
+ | '''This has been put on Hold = Status X as MO wants for Descartes to provide this feature.''' | ||
== Business Requirements == | == Business Requirements == | ||
Line 16: | Line 28: | ||
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). | 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 | + | There is a multi level process on how the system should check to see if a shipment should route through a pool point. |
- | 1st | + | * 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 [http://mantis.jaguarfreight.com/wiki/Cybertrax_2.1_Client_(requirements)#Truck_Domestic_Stats_TDS_feature 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 | |
+ | *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 | ||
+ | |||
+ | '''Exception Criteria''': | ||
+ | |||
+ | CT record meets [[#PP_conditions]] but has: | ||
+ | *[[Commodity#Plts]] > 28 but < 20 | ||
+ | *And [[Commodity#Stackable]] = N | ||
+ | *And [[Commodity#Gross_Lb]] is > 44,000 lbs | ||
+ | |||
+ | OR | ||
+ | |||
+ | CT record meets [[#PP_conditions]] but has: | ||
+ | *[[Commodity#Plts]] > 60 but < 35 | ||
+ | *And [[Commodity#Stackable]] = y | ||
+ | *And [[Commodity#Gross_Lb]] is > 44,000 lbs | ||
+ | |||
+ | === Regular conditions === | ||
+ | |||
+ | 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 | ||
+ | |||
+ | |||
+ | == 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 == | == 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 == | == SA Notes == | ||
Line 67: | Line 190: | ||
: 2) what should we to do if CT was edited (total GW and other) ? | : 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. | :* 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. | :***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'. | : 3) Can TMS work with CT# that contains characters? by example, '111111a'. | ||
Line 93: | Line 216: | ||
==== Shipments ==== | ==== Shipments ==== | ||
- | * New CT fields ( | + | * New CT fields (GenTab ?): |
** Pool Point | ** Pool Point | ||
- | ** Actual Pool | + | ** Actual Pool Point Delivery Date |
- | ** Actual Pool | + | ** Actual Pool Point PickUp Date |
==== TDS dashboard ==== | ==== TDS dashboard ==== | ||
* add collumn "Pool Point" with number of approved CTs whose need operator's attention to create Pool Point. | * 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 "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 == | == RFP == | ||
- | Proposal required before coding. | + | 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. --[[User:Denise|Denise]] 12:01, 9 December 2010 (EST) | ||
+ | |||
+ | - | ||
+ | --> | ||
+ | |||
+ | = Ver 2 = | ||
+ | |||
+ | Parent mantis: '''4168''' | ||
+ | |||
+ | == Definitions == | ||
+ | |||
+ | === Client Company === | ||
+ | |||
+ | Company that contacted Jaguar to ask to assist in shipping some goods. | ||
+ | |||
+ | It will be billed by Jaguar. | ||
+ | |||
+ | === CT === | ||
+ | |||
+ | In CT2 system it is a certain amount of goods (aka commodities) combined together and associated with one shipment order made by a [[#Client Company]]. | ||
+ | |||
+ | It has a unique id# called CT# and properties such as weight, volume, Origin, Destination, etc. | ||
+ | |||
+ | Properties of commodities are defined in Commodity Table associated with CT. They are defined on one hand by packaging (pallets, loose count, etc) and on another hand by PO, SKU, Quantities. | ||
+ | |||
+ | === MOT === | ||
+ | |||
+ | MOT - Mode Of Transport. | ||
+ | |||
+ | In CT2 system it is a property of CT that classify it by several main categories. | ||
+ | |||
+ | For example: | ||
+ | |||
+ | * MOT= Air if it is a multimodal move "truck -> Air -> truck" | ||
+ | |||
+ | * MOT=Truck Air if it is an LDP Air move | ||
+ | |||
+ | === CT Group === | ||
+ | |||
+ | In CT2 system it is a number of CTs associated together. It is assigned a unique number (GRP#). | ||
+ | |||
+ | All CTs in the same group have same [[#MOT]]. | ||
+ | |||
+ | === Shipment === | ||
+ | |||
+ | See [[Sh#Shipment]] | ||
+ | |||
+ | === Vehicle === | ||
+ | |||
+ | It is a mobile machine that transports [[#CT]]s such as trucks, trains, ships, boats and aircraft. | ||
+ | |||
+ | === Carrier === | ||
+ | |||
+ | Company that operates [[#Vehicle]]. | ||
+ | |||
+ | === Location === | ||
+ | |||
+ | Location is a recorded in a CT2 system geographical position of [[#CT]]. | ||
+ | |||
+ | Not all locations are recorded in the system. | ||
+ | |||
+ | ==== Location attributes ==== | ||
+ | |||
+ | * Address | ||
+ | * Date of arrival of CT to this location | ||
+ | * Date of departure from this location | ||
+ | |||
+ | ==== Location type ==== | ||
+ | |||
+ | There are 3 types of locations: | ||
+ | |||
+ | * [[#Origin Door]] (required) | ||
+ | * [[#Stop]] (some type of stops are required for some [[#MOT]]) | ||
+ | * [[#Destination Door]] (required) | ||
+ | |||
+ | ==== Origin Door ==== | ||
+ | |||
+ | aka Pick Up Location | ||
+ | |||
+ | Location where CT is originally picked up. | ||
+ | |||
+ | Mapped to 5. Export Pick-up (T4) | ||
+ | |||
+ | ==== Destination Door ==== | ||
+ | |||
+ | aka Delivery Location | ||
+ | |||
+ | Location that is a final delivery destination for CT. | ||
+ | |||
+ | Mapped to 6. Export Delivery To (T5) | ||
+ | |||
+ | ==== Stop ==== | ||
+ | |||
+ | For given CT '''Stop''' is a temporary location to which [[#Carrier]] delivers it. | ||
+ | |||
+ | Later same carrier or another carrier picks CT up from there to move to another Stop or Destination Door. | ||
+ | |||
+ | Not all stops need to be recorded in the system. But some of them are mandatory (example: Port of Origin). | ||
+ | |||
+ | One special type of stop is a [[#Pool Point]]. | ||
+ | |||
+ | ===== Pool Point ===== | ||
+ | |||
+ | Pool Point is a special [[#Stop]] that is used for transferring and consolidation of CTs. | ||
+ | |||
+ | See example below. | ||
+ | |||
+ | [[File:Pool point.jpg| 500px]] | ||
+ | |||
+ | ===== Other important stops ===== | ||
+ | |||
+ | * Air: | ||
+ | ** Origin Airport | ||
+ | ** Destination Airport | ||
+ | ** Transshipment Airport | ||
+ | |||
+ | * Ocean: | ||
+ | ** Origin Port | ||
+ | ** Destination Port | ||
+ | |||
+ | * Misc: | ||
+ | ** Terminal | ||
+ | ** Warehouse | ||
+ | |||
+ | === Leg === | ||
+ | |||
+ | For given CT '''Leg''' is a one non-stop trip between Stops or between Origin Door and Stop or between Stop and Destination Door. It is done on the same [[#Vehicle]] with the same [[#Carrier]]. | ||
+ | |||
+ | Leg as entity has the following attributes: | ||
+ | |||
+ | * Origin | ||
+ | * Destination | ||
+ | * transport mode (air vs LTL vs ... ), this is different from [[#MOT]] ! | ||
+ | * Carrier | ||
+ | * Vehicle id (such as trailer id for MOT= Truck Dom) | ||
+ | |||
+ | === Path === | ||
+ | |||
+ | Full ordered sequence of [[#Leg]]s that CT has. | ||
+ | |||
+ | Path could be: | ||
+ | |||
+ | * [[#Non Stop Path]] | ||
+ | * [[#Muli Stop Path]] | ||
+ | |||
+ | === Non Stop Path === | ||
+ | |||
+ | CT is moving '''Non stop''' if it moves from [[#Origin Door]] to [[#Destination Door]] with one [[#Carrier]] without a [[#Stop]]. | ||
+ | |||
+ | In this case trip has one [[#Leg]]. | ||
+ | |||
+ | === Multi Stop Path === | ||
+ | |||
+ | In this case CT has at least one [[#Stop]]. | ||
+ | |||
+ | 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" | ||
+ | |||
+ | == 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 CT travels through [[#Pool Point]] | ||
+ | ** tag CT as "delivered" / send "delivered" message to client users only if delivered to Delivery Location (not a Pool Point) | ||
+ | |||
+ | Above is possible due to recent fixes in TMS. | ||
+ | |||
+ | Above will eliminate workarounds operators have used so far to accommodate Pool Point moves. | ||
+ | |||
+ | == Ver 2 Systems Analysis and Solution == | ||
+ | |||
+ | === Impact on ER Model === | ||
+ | |||
+ | Decision is made to Implement [[#Multi Stop Path]]. | ||
+ | |||
+ | Now Truck - Domestic CT could be only part of one or two loads. | ||
+ | |||
+ | In case of two loads we are able to accomodate "Pick Up Trucker" (to Pool Point) and "Delivery Trucker" (from Pool Point) info: | ||
+ | |||
+ | * carrier name | ||
+ | * trailer id | ||
+ | |||
+ | It was suggested to increment ER structure to be able to collect info about [[#Multi Stop Path]] / multi leg trips. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | === Impact on CT Editor === | ||
+ | |||
+ | '''Idea''': | ||
+ | |||
+ | * Re-factor table on Dates tab to include all relevant info | ||
+ | * This table will be somewhat different for these 3 cases below. | ||
+ | |||
+ | ==== CT Editor in case of Descartes TMS Dom Trucking ==== | ||
+ | |||
+ | * '''! only this case to be implemented in this release !''' | ||
+ | |||
+ | * This is for our particular implementation of Descartes TMS | ||
+ | |||
+ | * Add "Dates/Locations" tab. On this tab display info defined below in a table like form | ||
+ | |||
+ | * '''Row''' in this table represents [[#Location]] with associated info for it and for each [[#Leg]] that initiates in that Location. Exception is the last row that represents only "final" Location (destination door) | ||
+ | |||
+ | * '''Columns''': | ||
+ | ** Location // [[#Location type]] - see below | ||
+ | ** Address // Location address | ||
+ | ** Status // If associated "Actual date" is defined then CT has reached (and possibly passed) this point and status is "actual". Else it is "estimated" | ||
+ | ** Arrived // editable // date of arrival to this Location; use Actual date if defined, else use estimated | ||
+ | ** Departed // editable // date of departure from this Location; use Actual date if defined, else use estimated | ||
+ | ** Transp Mode // comes from TMS | ||
+ | ** Carrier // editable // trucker name, comes from TMS | ||
+ | ** Vehicle id // editable // trailer id, comes from TMS | ||
+ | ** Load# // comes from TMS | ||
+ | ** Pro number // editable // comes from TMS | ||
+ | |||
+ | * Mock up: | ||
+ | |||
+ | [[File:Pp truck dom with full addr.png | 700px]] | ||
+ | |||
+ | ==== CT Editor in case of non TMS Dom Trucking ==== | ||
+ | |||
+ | Same as above but: | ||
+ | |||
+ | * operator adds rows in the table identifying Location types and associated info | ||
+ | * additional location types such as Warehouse and Stop | ||
+ | |||
+ | ==== CT Editor in case of non Dom Trucking ==== | ||
+ | |||
+ | * operator adds rows in the table identifying Location types and associated info | ||
+ | * more types of locations and legs that are associated with different MOTs such as Air and ocean (Examples: Ports/Airports, Terminals, etc) | ||
+ | |||
+ | ==== CT Editor Open Questions ==== | ||
+ | |||
+ | * Should we also edit through this table? | ||
+ | |||
+ | * Should we only edit through this table? (removing say Pick Up/Deliv Trucker from Gen Tab) | ||
+ | |||
+ | * In non-TMS case and other MOTs case this table is created by oper: | ||
+ | ** adding locations/identifying what type of location | ||
+ | ** need some validations such as delivery location must always be last, etc | ||
+ | |||
+ | === Impact on Reports === | ||
+ | |||
+ | Interface will not change. | ||
+ | |||
+ | Known reports affected: | ||
+ | |||
+ | * Main | ||
+ | * DR/KPIs | ||
+ | |||
+ | === Impact on DRs === | ||
+ | |||
+ | TBD | ||
+ | |||
+ | === Impact on pdfs === | ||
+ | |||
+ | None. | ||
+ | |||
+ | === Impact on Accounting === | ||
+ | |||
+ | TBD | ||
+ | |||
+ | === Impact on EDI interface === | ||
+ | |||
+ | Change code to capture moves through Pool Point. | ||
+ | |||
+ | Use '''AddressTypeDesc'''="Pool Point" attribute/value pair of '''ShipToInformation'''. | ||
+ | |||
+ | Update DB: | ||
+ | * load numbers | ||
+ | * carriers | ||
+ | * dates | ||
+ | |||
+ | Above comes from: | ||
+ | * load plans | ||
+ | * status messages | ||
+ | |||
+ | Consider most generic test case: "Consolidate with Pooling"number of CTs from different pick up locations to different delivery locations. | ||
+ | |||
+ | Update above should update both Gen Tab and Locations Tab. | ||
+ | |||
+ | ==== Pool Point Address ==== | ||
+ | |||
+ | Add Pool Point Addresses to Addressbook > Transportation under new category "T14: Pool Points" | ||
+ | |||
+ | When Pool Point info comes from TMS compare with above by full address or by id. | ||
+ | |||
+ | === Impact on Notifications === | ||
+ | |||
+ | Edit current notifications on: | ||
+ | * actual pick up updates from trucker | ||
+ | * actual delivery updates from trucker | ||
+ | |||
+ | Notify users only if: | ||
+ | * picked up from Origin Door | ||
+ | * delivered to Final Delivery Location (Destination Door). | ||
+ | |||
+ | Do not notify when delivered to Pool Point or any other intermediate stop. | ||
+ | |||
+ | === Impact on Est Module === | ||
+ | |||
+ | For every new load two lines will be added into Est Table (for freight and other charges). | ||
+ | |||
+ | So in case CT has path: Origin > Pool Point > Destination we should have 4 lines on Est Tab (two per load). | ||
+ | |||
+ | === TMS Load Viewer === | ||
+ | |||
+ | ==== View Loads Through Quicklink ==== | ||
+ | |||
+ | Roma/Alex suggest simple TMS Load Viewer. | ||
+ | |||
+ | By entering LD# into quick link user is served page with the following info: | ||
+ | |||
+ | * ld# | ||
+ | * Carrier | ||
+ | * List of CT# under this load | ||
+ | |||
+ | ==== View Loads Through Where Is ==== | ||
+ | |||
+ | * Add one more filter to Where Is Report: | ||
+ | ** label: "TMS LD# equals" | ||
+ | ** control: enter into "text box" to create a list | ||
+ | ** logic: for LD#(s) that user enters find all CTs that are associated with entered numbers and produce standard report for these CTs | ||
+ | ** if there are multiple loads that participate in the report result then in els view add column "LD#" | ||
+ | |||
+ | ==== View Loads in Load Window ==== | ||
+ | |||
+ | * Add "Load Window" in an ASN Portal so that could be opened from "ASN View" window. | ||
+ | * In Internal ''(please note, Leg means a Load)'': | ||
+ | ** Show a Load#-related info clicking a "View" button (or use Load# as a link to open pop-up window). | ||
+ | ** Clicking on GRP# (link) -> see a GRP in pop-up window. | ||
+ | * Provide an ability to print for both above (Load/GRP). | ||
+ | |||
+ | * Load Window mockup: | ||
+ | [[File:Load-Window-mockup.png]] | ||
+ | |||
+ | === Impact on Logs === | ||
+ | |||
+ | Make sure that all events are properly logged. | ||
+ | |||
+ | = SOWs = | ||
+ | |||
+ | === SOW 1 Create architecture for Pool Point project === | ||
+ | |||
+ | mantis: 0004228 | ||
+ | |||
+ | spec: see [[#Ver 2]] | ||
+ | |||
+ | |||
+ | === SOW 2 === | ||
+ | |||
+ | ==== Impact on EDI interface ==== | ||
+ | |||
+ | mantis: 0004229 | ||
+ | |||
+ | spec: see [[#Impact on EDI interface]] | ||
+ | |||
+ | |||
+ | === SOW 3 === | ||
+ | |||
+ | ==== Impact on CT Editor ==== | ||
+ | |||
+ | mantis: 0004236 | ||
+ | |||
+ | spec: see [[#CT Editor in case of Descartes TMS Dom Trucking]] | ||
+ | |||
+ | |||
+ | === SOW 4 === | ||
+ | |||
+ | ==== TMS Load Viewer ==== | ||
+ | |||
+ | mantis: 4237 | ||
+ | |||
+ | spec: | ||
+ | * part 1: see [[#View Loads Through Where Is]] ''(released in 2013, see mantis)'' | ||
+ | * part 2: see [[#View Loads in Load Window]] | ||
+ | |||
+ | === SOW 5 === | ||
+ | |||
+ | ==== Logging for TMS ==== | ||
+ | |||
+ | mantis: 4238 | ||
+ | |||
+ | spec: see [[#Impact on Logs]] | ||
+ | |||
+ | |||
+ | === SOW 6 === | ||
+ | |||
+ | ==== Impact on Notifications ==== | ||
+ | |||
+ | mantis: 4240 | ||
+ | |||
+ | spec: | ||
+ | |||
+ | [[#Impact on Notifications]] | ||
+ | |||
+ | |||
+ | === SOW 7 === | ||
+ | |||
+ | ==== Impact on Est Module ==== | ||
+ | |||
+ | mantis: 4241 | ||
+ | |||
+ | spec: | ||
+ | [[#Impact on Est Module]] | ||
+ | |||
+ | |||
+ | === Misc === | ||
+ | |||
+ | 1) old field (Gen Tab) // new field (Leg Tab) // updated by // TMS specific? | ||
+ | |||
+ | * 5. Export Pick-up (T4) // PU, leg1 // oper // N | ||
+ | |||
+ | * 6. Export Delivery To (T5) // Delivery, leg 2 // oper // N | ||
+ | |||
+ | * 8. Export Pick-up Trucker (V3) // // N | ||
+ | |||
+ | * Delivery Trucker (V3) // // N | ||
+ | |||
+ | 2) old field (Gen Tab) // new field (Leg Tab) // updated by |
Current revision as of 14:13, 30 March 2015
Contents
|
[edit] 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.
[edit] Ver 1
This section was commented out.
[edit] Ver 2
Parent mantis: 4168
[edit] Definitions
[edit] Client Company
Company that contacted Jaguar to ask to assist in shipping some goods.
It will be billed by Jaguar.
[edit] CT
In CT2 system it is a certain amount of goods (aka commodities) combined together and associated with one shipment order made by a #Client Company.
It has a unique id# called CT# and properties such as weight, volume, Origin, Destination, etc.
Properties of commodities are defined in Commodity Table associated with CT. They are defined on one hand by packaging (pallets, loose count, etc) and on another hand by PO, SKU, Quantities.
[edit] MOT
MOT - Mode Of Transport.
In CT2 system it is a property of CT that classify it by several main categories.
For example:
- MOT= Air if it is a multimodal move "truck -> Air -> truck"
- MOT=Truck Air if it is an LDP Air move
[edit] CT Group
In CT2 system it is a number of CTs associated together. It is assigned a unique number (GRP#).
All CTs in the same group have same #MOT.
[edit] Shipment
See Sh#Shipment
[edit] Vehicle
It is a mobile machine that transports #CTs such as trucks, trains, ships, boats and aircraft.
[edit] Carrier
Company that operates #Vehicle.
[edit] Location
Location is a recorded in a CT2 system geographical position of #CT.
Not all locations are recorded in the system.
[edit] Location attributes
- Address
- Date of arrival of CT to this location
- Date of departure from this location
[edit] Location type
There are 3 types of locations:
- #Origin Door (required)
- #Stop (some type of stops are required for some #MOT)
- #Destination Door (required)
[edit] Origin Door
aka Pick Up Location
Location where CT is originally picked up.
Mapped to 5. Export Pick-up (T4)
[edit] Destination Door
aka Delivery Location
Location that is a final delivery destination for CT.
Mapped to 6. Export Delivery To (T5)
[edit] Stop
For given CT Stop is a temporary location to which #Carrier delivers it.
Later same carrier or another carrier picks CT up from there to move to another Stop or Destination Door.
Not all stops need to be recorded in the system. But some of them are mandatory (example: Port of Origin).
One special type of stop is a #Pool Point.
[edit] Pool Point
Pool Point is a special #Stop that is used for transferring and consolidation of CTs.
See example below.
[edit] Other important stops
- Air:
- Origin Airport
- Destination Airport
- Transshipment Airport
- Ocean:
- Origin Port
- Destination Port
- Misc:
- Terminal
- Warehouse
[edit] Leg
For given CT Leg is a one non-stop trip between Stops or between Origin Door and Stop or between Stop and Destination Door. It is done on the same #Vehicle with the same #Carrier.
Leg as entity has the following attributes:
- Origin
- Destination
- transport mode (air vs LTL vs ... ), this is different from #MOT !
- Carrier
- Vehicle id (such as trailer id for MOT= Truck Dom)
[edit] Path
Full ordered sequence of #Legs that CT has.
Path could be:
[edit] Non Stop Path
CT is moving Non stop if it moves from #Origin Door to #Destination Door with one #Carrier without a #Stop.
In this case trip has one #Leg.
[edit] Multi Stop Path
In this case CT has at least one #Stop.
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"
[edit] 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 CT travels through #Pool Point
- tag CT as "delivered" / send "delivered" message to client users only if delivered to Delivery Location (not a Pool Point)
Above is possible due to recent fixes in TMS.
Above will eliminate workarounds operators have used so far to accommodate Pool Point moves.
[edit] Ver 2 Systems Analysis and Solution
[edit] Impact on ER Model
Decision is made to Implement #Multi Stop Path.
Now Truck - Domestic CT could be only part of one or two loads.
In case of two loads we are able to accomodate "Pick Up Trucker" (to Pool Point) and "Delivery Trucker" (from Pool Point) info:
- carrier name
- trailer id
It was suggested to increment ER structure to be able to collect info about #Multi Stop Path / multi leg trips.
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.
[edit] Impact on CT Editor
Idea:
- Re-factor table on Dates tab to include all relevant info
- This table will be somewhat different for these 3 cases below.
[edit] CT Editor in case of Descartes TMS Dom Trucking
- ! only this case to be implemented in this release !
- This is for our particular implementation of Descartes TMS
- Add "Dates/Locations" tab. On this tab display info defined below in a table like form
- Row in this table represents #Location with associated info for it and for each #Leg that initiates in that Location. Exception is the last row that represents only "final" Location (destination door)
- Columns:
- Location // #Location type - see below
- Address // Location address
- Status // If associated "Actual date" is defined then CT has reached (and possibly passed) this point and status is "actual". Else it is "estimated"
- Arrived // editable // date of arrival to this Location; use Actual date if defined, else use estimated
- Departed // editable // date of departure from this Location; use Actual date if defined, else use estimated
- Transp Mode // comes from TMS
- Carrier // editable // trucker name, comes from TMS
- Vehicle id // editable // trailer id, comes from TMS
- Load# // comes from TMS
- Pro number // editable // comes from TMS
- Mock up:
[edit] CT Editor in case of non TMS Dom Trucking
Same as above but:
- operator adds rows in the table identifying Location types and associated info
- additional location types such as Warehouse and Stop
[edit] CT Editor in case of non Dom Trucking
- operator adds rows in the table identifying Location types and associated info
- more types of locations and legs that are associated with different MOTs such as Air and ocean (Examples: Ports/Airports, Terminals, etc)
[edit] CT Editor Open Questions
- Should we also edit through this table?
- Should we only edit through this table? (removing say Pick Up/Deliv Trucker from Gen Tab)
- In non-TMS case and other MOTs case this table is created by oper:
- adding locations/identifying what type of location
- need some validations such as delivery location must always be last, etc
[edit] Impact on Reports
Interface will not change.
Known reports affected:
- Main
- DR/KPIs
[edit] Impact on DRs
TBD
[edit] Impact on pdfs
None.
[edit] Impact on Accounting
TBD
[edit] Impact on EDI interface
Change code to capture moves through Pool Point.
Use AddressTypeDesc="Pool Point" attribute/value pair of ShipToInformation.
Update DB:
- load numbers
- carriers
- dates
Above comes from:
- load plans
- status messages
Consider most generic test case: "Consolidate with Pooling"number of CTs from different pick up locations to different delivery locations.
Update above should update both Gen Tab and Locations Tab.
[edit] Pool Point Address
Add Pool Point Addresses to Addressbook > Transportation under new category "T14: Pool Points"
When Pool Point info comes from TMS compare with above by full address or by id.
[edit] Impact on Notifications
Edit current notifications on:
- actual pick up updates from trucker
- actual delivery updates from trucker
Notify users only if:
- picked up from Origin Door
- delivered to Final Delivery Location (Destination Door).
Do not notify when delivered to Pool Point or any other intermediate stop.
[edit] Impact on Est Module
For every new load two lines will be added into Est Table (for freight and other charges).
So in case CT has path: Origin > Pool Point > Destination we should have 4 lines on Est Tab (two per load).
[edit] TMS Load Viewer
[edit] View Loads Through Quicklink
Roma/Alex suggest simple TMS Load Viewer.
By entering LD# into quick link user is served page with the following info:
- ld#
- Carrier
- List of CT# under this load
[edit] View Loads Through Where Is
- Add one more filter to Where Is Report:
- label: "TMS LD# equals"
- control: enter into "text box" to create a list
- logic: for LD#(s) that user enters find all CTs that are associated with entered numbers and produce standard report for these CTs
- if there are multiple loads that participate in the report result then in els view add column "LD#"
[edit] View Loads in Load Window
- Add "Load Window" in an ASN Portal so that could be opened from "ASN View" window.
- In Internal (please note, Leg means a Load):
- Show a Load#-related info clicking a "View" button (or use Load# as a link to open pop-up window).
- Clicking on GRP# (link) -> see a GRP in pop-up window.
- Provide an ability to print for both above (Load/GRP).
- Load Window mockup:
[edit] Impact on Logs
Make sure that all events are properly logged.
[edit] SOWs
[edit] SOW 1 Create architecture for Pool Point project
mantis: 0004228
spec: see #Ver 2
[edit] SOW 2
[edit] Impact on EDI interface
mantis: 0004229
spec: see #Impact on EDI interface
[edit] SOW 3
[edit] Impact on CT Editor
mantis: 0004236
spec: see #CT Editor in case of Descartes TMS Dom Trucking
[edit] SOW 4
[edit] TMS Load Viewer
mantis: 4237
spec:
- part 1: see #View Loads Through Where Is (released in 2013, see mantis)
- part 2: see #View Loads in Load Window
[edit] SOW 5
[edit] Logging for TMS
mantis: 4238
spec: see #Impact on Logs
[edit] SOW 6
[edit] Impact on Notifications
mantis: 4240
spec:
[edit] SOW 7
[edit] Impact on Est Module
mantis: 4241
spec: #Impact on Est Module
[edit] Misc
1) old field (Gen Tab) // new field (Leg Tab) // updated by // TMS specific?
- 5. Export Pick-up (T4) // PU, leg1 // oper // N
- 6. Export Delivery To (T5) // Delivery, leg 2 // oper // N
- 8. Export Pick-up Trucker (V3) // // N
- Delivery Trucker (V3) // // N
2) old field (Gen Tab) // new field (Leg Tab) // updated by