CT Groups Ops Component
From UG
Requirements
Several CT could be "groupped". Motivation behind that:
- to be able to apply "same operation" to every CT with one click. For example you could change value of one CT field on multiple CT's
- generate pdf documents that "desribe" combined "values" from multiple CTs
- post comments into multiple CTs with one click
- see P/L report for combined CTs
- etc
Design Ver 3.0
B.1 "Group update" for fields on Gen, Exp, Imp CT tabs
B.1.1) If CT is a part of a group then on a Gen, Imp, Exp tabs "Group Save" button would appear B.1.2) "Group Save" button on click produces pop-up where you can select all or just some CTs from a group B.1.3a) on "OK" System would update selected CTs in addition to current CT B.1.3b) Only SOME fields can be updated for multiple CTs: B.1.3gen) "Group fields" for Gen tab: A. B. C. D. EO, E1, E2, E3 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 B.1.3exp) "Group fields" for Export Tab: AIR: 1. & 18. -> Note: All the remaining fields (except 19) are "master" fields OCN: 1, 2, 3, 11a, 15a (11a and 15a: include both calendars for each field as well) 18. -> Note: All the remaining fields (except 19) are "master" fields B.1.3imp) "Group fields" for Imp Tab: all fields
B.2 "Group update" for Internal Cooments, Comments, EQuery CT, File Upload tabs
B.2.1) If CT is a part of a group then on a Gen, Imp, Exp tabs "Group Operation" button would appear B.2.2) "Group Operation" button on click produces pop-up (see http://mantis.jaguarfreight.com/svn/ct2/SS/ops/groups/UI/UI_apply_to_selected_CTs.JPG) B.2.3) on "OK" (see above) System would update selected CTs in addition to current one. "Operation" would be applied to ALL selected CTs B.2.3icom) "Operation" for Internal Cooments is "insert/email comment" B.2.3com) "Operation" for Cooments is "insert/email comment" B.2.3ieq) "Operation" for EQuery CT is "insert/email query" B.2.3ifu) "Operation" for File Upload is "upload file"
c) "Group update" for pdfDocs
In general for each pdf there would be a way to generate one doc for all CTs in a group (or a subset). Some Info on pdf (like HUs) would be combined info from all selected CTs. See specific pdf design doc for specific specs.
UIs
- see related UI <A HREF="../UI/">here</A>
[Create/Edit/Del group. Add/Remove CT from group.]
A1) To create a group, system must require at least 2 CT's. A2) A group for which less than 2 CT's are attached to is "void" (no longer a group) (Related to nimber 1) A3) Given CT can only be a part of ONE group A4) When group is created "Transport Mode" and "Client Company" must be specified. new ====> A4b) (may 26 2009) Groups have only ONE "truck mode", not 3 truck modes like CT have A5) If a CT is added to a group then CT's Mode, client (E0), will be updated to client (E0) and Mode that the group is set to. new ====> A5b) (may 26 2009) If group's MOT ="truck" then only CT's with MOT = truck-dom OR, truck-air OR truck-ocean can be added new ====> A5c) if group X has MOT="truck" can we change it to another MOT, say "air"??? yes. A7) Group's "Client Company" parameter could be changed at any time. Then all groups member CT's Client are "force-changed" to new value. A8) Group's "MOT(mode)" parameter could be changed. Then all groups member CT's Client are "force-changed" to new value. A9) [MOT lock] After CT becomes part of the group MOT on general tab must become read-only A10) If user deletes CT from a system it should disappear from the group A11) Max number of CTs in group = 40 A12) If CT1 is a part of GR1 and user is trying to add CT1 to GR2 system will complain: "CT is already a part of another group". To MOVE CT from one group to another user must do 2 steps: delete CT from its group and then add to another group.
[Master related]
Am1) System should prevent changing MOT of the group if group is a part of a Master. Am2) If we add/remove ANY groupped together CTs to/from a Master then automatically ALL of them are added/removed to/from the master (! update Master's M/CT Maping tab immediately) Am3) If CT1, CT2, ... are part of same group and user executes "create M base on this CT" operation for one of the CTs then ALL remaining CTs become part of that master Am4) If user removes CT out of G that is a part of a Master then CT should: a) be removed from M b) be set in a "CT initial state" (MOT=undefined, containers=none) Am5) If user adds a CT to a G that is a part of a Master then CT should be added to M Am6) Master can contain a mix of multiple groups and "stand alone" CTs Am7) Assume: CT belongs to M group G doesnt belong to M User is trying to move this CT to this G system must prohibit this action
Notes
[NOTES] --------- N1) [test case] If CT X is a part of a group G1 and G1 ia a part of a Master M1 and user is trying to add X to a group G2 that IS NOT a part of master M1 then system should prohibit and complain (because of A12 requirement above). N2) [test case] If CT X is a part of a group G1 and G1 ia a part of a Master M1 and user is trying to add X to a group G2 that IS a part of master M1 then system should prohibit and complain (because of A12 requirement above). =======all below is from Mantis - do we already have that? === * if CT X is a part of a Master Y then X can be added only to group that is a part of master Y (or if added to group that is a part of master Z simply move X to Z?) * after CT (not part of the group) removed from M then we keep CT mode, should we also set it to "undef" mode/remove containers?
Ver 3.1
Ver 3.2
- add more "group fields" (should have a check box for group updates):
- Export Tab: All fields that are not M fields
- Import Tab: All fields
v3.3
System should allow to group shipments that are already part of one master. Now it gives error.
History
0003178: [Ops.Groups] Optimize ungrouping shipments functionality
Ungrouping Shipments is taking too long and causing processing errors
