ASN 20 Solution
From UG
About
This wiki defines both Requirements and Solution for ASN 20 project.
Primary audience - Development Team (leads, developers) and Product Team (prod manager, business analysts).
Author: alex@jaguarfreight.com
Preliminary Remarks
Core Needs
Copied from #ASN 20 BR wiki.
ASN 20 will extend ASN 1.X to provide the following functionality - see below.
- extend Shipper / ASN / Planner / Jaguar Ops functionality to:
- other MOTs (Air, Ocean, etc)
- any Client Company
- add some additional features (such as Additional MOT Air approval)
- introduce some changes (such as FTL/LTL logic)
- some not directly related to ASN functionality (such as merging Com and EQuery)
ASN 2.0 vs ASN 1.X
ASN 2.0 is an extension of ASN 1.X functionality.
This wiki maintains focus on explaining what to add and change without repeating in details what to carry over from previous version (ASN 1.X). At the same time I do briefly mention some of the major functionality that needs to be preserved.
ASN 2.0 vs International Portal
Originally this scope was kept under larger International Portal project. Most recently it was decided to extract ASN related functionality and implement it as soon as possible. This project is to be called ASN 2.0.
Some features that were developed or half-developed under I-Portal such as Flexible CT editor, merging of Client and Internal App were put on hold and are out of scope for this project.
Some features such as new User Roles Manager will be used for this module. But some adjustment is required (example: some Roles will be defined as Flexible and some as Built In).
Also we need to clearly define in the system option for Truck Domestic mode: TMS vs non-TMS.
Rapid development for ASN 2.0
We should try to take such development approach that allows for rapid first version that could change after we get additional understanding soon after (if we sell this solution). Ideally code that we write should not affect existing code that already supports ASN 1.X and CT2. Same would be true for database structure that supports existing data.
Demo version first
It is requested to produce demo version first (limited set of features, no need for production quality) within first 4-5 weeks of development.
Misc Set 1
These are Non Core (Peripheral) tasks.
Add Clone User feature
BR: ASN_20_BR#Add_Clone_User_feature
On UI level there would be "Clone" button on Admin > Users Admin panel.
Selecting one user and pressing "Clone" would open up Add New User panel with all info pre-populated from selected user except (these fields should be empty):
- username
- First / Last name
- password
- SkypeId
- birthday
- phone
Note to Developer ----------------- We used to have this feature. After we merged Jag and Non-Jag profiles it disappeared. Search for this code and re-use if possible.
Post Impl Notes.
Implemented as defined in spec.
Add Create GRP action to Virtual Group
BR: ASN_20_BR#Add_Create_GRP_action_to_Virtual_Group
See mock up below.
On "Create GRP" load "Add shipment group" window:
- List all CT numbers there.
- if all CTs have same E0 and MOT then pre-fill these fields
- if these CTs can't be grouped together provide Error message (try to re-use existing logic/code)
Create and consolidate TMS and ASN Admins
Create and consolidate TMS Admin
1) Create Admin > TMS menu item
2) Move Admin > Client Application > Admin > TMS to Admin > TMS
3) Associate Trailer payload Admin with TMS:
Move Admin > Transportation > Trailer Payload panel to Admin > TMS
Create and consolidate ASN Admin
1) Create Admin > ASN menu item
2) Move Admin > Client Application > Admin > Shipper Portal to Admin > ASN
Re-design SKU Map
SKU Map.
"SKU Map" aka "SKU to Planner mapping" as defined in ASN 1X is a table (uploaded in the form of xls) that links unique SKU# to SKU description and to planners name.
It provides auto-suggest for SKU description on ASN form and planner filter for List CTs under Planners login.
It was required only for CTs that are associated with one particular PO Issued By value.
Link to ASN 1X spec: ASN_1.X#SKU_to_Planner_Mapping_Feature.
SKU Map browser.
We need to add one simple important table: history of uploaded files with ability to View files and with these attributes per File entity:
- file-name
- file size
- time-stamp when uploaded
- who uploaded (username)
Currently, it is not possible to see even currently uploaded xls.
Figure below suggests possible UI design to satisfy stated functionality.
- Upload button - to upload new files.
- View button - to view existing.
Option with No:
Option with Yes:
Flag CT feature
BR/ISA: ASN 20 BR#Flag CT feature
Merge Com and EQuery
BR/ISA: ASN 20 BR#Merge Com and EQuery .
Flexible Shipments List
BR/ISA: ASN 20 BR#Flexible Shipments List.
Misc Set 2
Add TMS E0 attribute
Currently "TMS solution" supports only one Client Company (E0) at a time - we can not send shipments to TMS that are identified by more than one E0 - this case is not defined - no code or business process exists to handle this case properly. This restriction will remain in ASN 2.0.
We need to add parameter to the system that defines clearly what E0 "is linked to" Descartes TMS currently. This will help in :
- reporting
- for example for DR/KPI reporting we will know in this case what CTs are linked to cost that we receive from TMS vs costs entered by operators. It is important because we keep these costs in different database tables for these two cases.
- validation
- to make sure we do not send CTs from more than one E0 to TMS
See mock up below.
Tune Role Admin
Add Role Type attribute: Built In vs User Defined User Roles.
We have to distinguish between Built In and User Defined User Roles.
Also this should be obvious for the user - what role is of what type.
This is a new attribute of User Role Entity.
User Defined Role is a role that can be created and fully defined by user through Admin > Security > User Roles panel.
See UI changes on the Figure below:
1 - change button label
2 - add "Role Type" column
Add Generic Shipper and Generic Planner Built In User Roles.
Currently the only Shipper and related Planner roles defined in the system are "EA Shipper" and "EA Planner". These are built in roles.
They currently support only Elizabeth Arden (EA) Domestic Trucking workflow.
Since it is intention to increment/change EA workflow and also to add support for any Client Company without distracting existing operations we need to create two new built in roles "Generic Shipper" and "Generic Planner" that would fully satisfy ASN 2.0 requirements.
See #3 and #4 on the Figure above.
Deploy this into production. After release we should:
- EA Shipper
- EA Planner
- Generic Shipper
- Generic Planner
At that point In production we could:
- start creating new Generic Shippers/Planners for any E0
- transfer all users from EA Shipper to Generic Shipper
- transfer all users from EA Planner to Generic Planner
- remove EA Planner, EA Shipper (in the following Rel to Prod)
Important Note to Developer ------------------------ Code should be re-used by both EA and Generic Shipper/Planners. Obviously we should not create separate similar code for EA vs Generic roles.
Misc set 3
ASN transmit
BR/ISA: ASN_20_BRBA#ASN transmit
ASN transmit: Admin
Admin user should be able to add ASN Transmit Option.
Each ASN Transmit Option has the following attributes:
- Name
- defined by user text; examples: Jaguar(CT2), Panalpina(3PL)
- Type
- possible values: {System, User Defined}
- System - hard coded option; for now it is only one: Jaguar(CT2)
- User Defined - user can add and define options in this admin
- possible values: {System, User Defined}
- Method
- for "Jaguar(CT2)" it should say "native/internal". In this case CT2 will internally open access to CT record to Jag Ops
- for all user defined it should provide drop down with one option: "email"
UI mock up: TBD.
Components using this:
ASN transmit: email option
option 1) One e-mail will have two attachments:
- commodity info
- utilize existing "Download to xls format" but remove totals info
- non-commodity info
- create similar format to above but list attribute/value vertically
option 2) One e-mail will have one attachment
Portal
ASN Portal is created for particular Company and its Supply Chain. Example: EA.
Therefore we need to create such entity in the system so we can define all properties associated with it.
We could have used Client Company E0 for that purpose but unfortunately we sometimes create multiple E0s for the same Company/Supply Chain. For example for EA we have:
- "EA DOM PORTAL" E0 for USA Trucking Domestic shipments
- "Elizabeth Arden" E0 for Air and Ocean shipments
So in the case above we will create Portal named "EA" and associate it with all relevant E0s: in this case "Elizabeth Arden" and "EA DOM PORTAL".
List of Portals and Portal Profile
List of Portals
Add this to Admin > ASN .
This is a panel that lists all existing Portals in the system.
Each portal listed with some additional information:
- number of linked E0s
- number of linked users that are just Shippers
- number of linked users that are just Planners
- number of linked users that are both Shippers and Planners
On "Add" or "Edit" system shows #Portal Profile.
See mock up below.
Portal Profile
Portal Profile has several sections - see below.
Note to developer ----------------- I suggest that we implement UI similarly to Client Companies: a) Add/Edit results in a pop-up window. b) We utilize a mix of <tabbox/> and <groupbox/> with <caption/> to present various sections.
Portal Profile: General Settings Section
In this section the following 3 parameters have to be defined:
- Portal Name:
- user will name it here
- Portal Note:
- some useful memos could be posted here to preserve knowledge for other admin users
- Related E0s:
- list of E0s that would be used "under this Portal"
See UI mock up below.
Portal Profile: MOT Settings Section
In this section we define all desirable configurations under specific portal that relates to the following parameters:
- MOT:
- - "native" to CT2 MOTs
- Synonym (mode) and Synonym (sub-mode)
- - this combination is just a synonym for MOT
- - two values define two dropdowns on ASN form
- From:
- - options:
- - Regions (multi with any)
- - Countries (multi with any)
- - Shippers (multi with any)
- - see also #ASN transmit
- To:
- - options:
- - Regions (multi with any)
- - Countries (multi with any)
- - Consignees (multi with any)
- - see also #ASN transmit
- Transmit To:
- - see also #ASN transmit
- Link to E0:
- - see explanation here: #Portal
Developers Note -------------- Per Kostya's suggestion: * def: let's call each line a "rule" * all "rules" defined in the table are ordered * rules at the top have higher precedence that those at the bottom * default "rule" would be added to cover cases that are not defined
See UI mock up below.
List:
Edit:
Portal Profile: Approval Settings Section
Specific portal could have option to transmit all ASNs to 3PLs for transportation as they get submitted by Shippers or could provide separate layer for approval workflow:
- option 1) All ASNs will be transmitted to 3PLs for transportation automatically
- option 2) At least some ASNs needs to go through approval process
If option 2 is selected then additional information needs to be defined such as:
- PO Issued By list
- approval mode for every PO Issued By/MOT combination
- - possible values: {Auto, Single, Double}
- Air Approval and Cargo Due date settings
UI mock-up:
Note to developer ----------------- Feel free to implement another UI equivalent to above.
Edit or Delete Portal
Select portal from #List of Portals and apply action.
Make PO Issued By List Portal specific
This feature is already in the system.
Since every Supply Chain/Company has its own PO Issued By List it has to be defined in Portal profile - see #Portal Profile.
Since approval type will be Portal specific we have to move related parameters there as well - - see #Portal Profile.
Existing list is located under Admin > Transportation > PO Issued By.
It needs to be again defined for Portal once we migrate from EA Shipper to Generic Shipper.
SKU Map should be PO Issued By specific and Portal specific
This feature is already in the system.
Now SKU Map should become Portal specific - see #Portal Profile: Approval Section.
Y vs N indicate if SKU Map is used for selected PO Issued By or not.
SKU Map is not required feature therefore default is N.
On "Add" the following pop-up will be produced - see #Re-design SKU Map.
Shipper Related Functionality
New Shipper Profile
Shipper Profile: General section
We have the following fields:
- Portal:
- change: used to be linked to (create ASNs for) one E0
- Shipper (T1):
- remains the same
- Shipments weight in:
- remains the same
See mock up below.
Shipper Profile: Portal specific section
For every Portal defined in General section we can define the following:
- Approval mode for every PO Issued By/MOT combination
- By default these settings are taken from Portal profile
- Air Approval and Cargo Due date settings
- By default these settings are taken from Portal profile
- Available MOT setting
- we define can Shipper select mode at all or not
- if Yes then we define what mode (out of defined in Portal modes) he can select
See mock up below.
New ASN Form
ASN form and logic: list of changes.
Here is a brief list of changes for ASN form and on submit logic:
- Add mode/sub-mode fields
- Show truck table for FTL
- Show container table for FCL
- on submit create CT records based on new special algorithm
- new dims and CBM management
ASN form mock up.
See below mock up for Ocean FCL case.
Add mode and submode
Add (Transport) "Mode" + "Sub-Mode" as defined through "MOT synonym" - see #Portal Profile: MOT Settings Section.
Truck and container tables on ASN form
Add FTL vs LTL flag
BR:
- FTL - full truck load. Paid per track regardless of weight/volume. For very large shipments.
- LTL - less than truck load. Paid based on weight/volume. For small and medium shipments.
In ASN 2.0 we would like to request shipper to indicate what kind of shipment he is requesting: FTL vs LTL.
Also this should be a sub-mode offered to Shipper/Planner.
ISA:
(Per Kostya) the best way to implement is to add extra entity "Sub-mode" with values: {LTL, FTL}
Add Truck table for FTL
BR:
We want to request the following info from Shippers when they submit ASN for FTL shipments:
- how many trucks of what size are required to move commodities defined on ASN
PIN:
The following design has been implemented:
NOTE: see also #CRW 8 Re-design Truck Info (pendng)
Add Container table for FCL
BR:
Provide same container related capability to Shippers as ops have on internal:
- create containers with size/type/seal/number
- assign commodities
Above will be optional. In many cases shippers will just indicate how many containers and of what size.
ISA:
I suppose we could just re-use back-end (non-zul) code that we have
On submit algorithm
If ASN is associated with E0 that is associated with TMS (see #Add TMS E0 attribute)
Then keep existing ASN 1.X logic (create separate CT for each commodity table)
Else create one CT with multiple lines in commodity table (as defined on ASN form).
This CT will have status new and appear under radar of appropriate planners.
Preview and Confirmation Screen
Preserve such logic defined in ASN 1.X.
Show these screens on submit:
- Preview Screen
- Confirmation Screen
See it defined here: ASN 1.X#Create_CT_record. (NOTE: This wiki might not be completely up to date, functionality in production is more relevant).
Email Notifications on ASN submit
Send Notification email to Shipper who created record on ASN submit (as defined in ASN 1.X).
ASN info access after submit
To remind once ASN is submitted the following could happen in terms of ASN info access:
- if no approval process defined then:
- CT record created based on ASN will show up on #ANA report or be transmitted to other 3PLs
- if approval process is defined then:
- CT record created based on ASN will become available to Jag Ops or other 3PLs
- It will become available for planners for approval process
In both cases above shipper user can edit CT record until "ASN locked for edit condition":
- Actual pick up date is set.
New dims and CBM management
BR:
We need to add choice to enter cbm or dims per line item vs per table.
To do that:
- add selector "Define volume/dims for each commodity line (Y/N)?"
- if N then functionality is the same as on internal (see Table B and Dims/Non-Dims selector)
- if Y then see below
- each commodity line is incremented with fields W,H,L,Unit(for L,W,H),total(in cbm),total(in cft)
- calculate / display total for entire com table (in both cbm and cft)
- provide Non-Dims option (to enter volume, not calculate) per commodity line
- use same functionality for both internal and Client Apps (= it must behave same way on both Client and Internal)
Shipments List for a Shipper user
Add mode and sub-mode columns and filters.
Preserve existing logic. See ASN_1.X#View_list_of_CT_records_as_a_shipper.
But need to add mode and sub-mode columns.
See (1) and (2) on mock up below.
Add Display one line per CT option.
If un-selected then show all commodity items.
If selected then fields that have different values across commodity items should show "var" (for various) and ideally on mouse over show all values.
See (4) on a mock up below.
Shippers UI in case of multiple Portals.
In this case Shipper need to choose from the list of Portals to see shipments for particular Portal.
See (3) on a mock up below.
This is due to business requirement to not mix CTs within different Portals.
Edit, Clone, Delete CT records as a Shipper
Preserve existing logic. See ASN_1.X#Core Shipper Functionality.
Shipments List mock up.
See mock up below.
Planner Related Functionality
New Planner Profile
Each Planner is associated with multiple Portals.
Under each Portal we need to define his role separately for each PO Issued By.
See mock up below.
Planners that handle #Air Approval Type defined as Air Planners.
Shipments List for a Planner user
Preserve existing functionality: ASN_1.X#View_list_of_CT_records_as_a_planner
Planners UI in case of multiple Portals.
Please apply same approach to UI as for Shipper in this case.
Add type of planner to UI.
Add type of planner to Planner UI.
It should be a simple label. Examples:
- You are a Super Planner
- You are a Regular and Air Planner
Shipments List for a Planner mock up.
See below.
Additional features (1),(2),(3),(4) are defined in #Shipments List for a Shipper user
Approval related logic
Preserve existing functionality: ASN_1.X#Authorize_CT_records.
See also ASN_1.X#Double Approval Process Feature.
Also introduce some additional functionality and changes as defined below.
Approval algorithm
"Under one ASN" (decision will be made for one ASN at a time) planner might set different status for every commodity line. Every time Planner process multiple lines:
- create one CT for all rejected records
- create one CT for all on hold records
- create one CT per MOT for all approved records
NOTE: all commodities that are combined in one CT must have same "header" info (origin, destination, etc).
Notes to developer. ------------------- 1) CT# that was created from ASN originally will not be re-used in above process or not.
PIN 1 ------- Per Sasha: * planner will take action through Shipment List interface, "Display one line per CT" option = off * shipper will be able to change mode on individual line items/groups of line items
IMPORTANT: If ASN is not approved completely first time by planner (all items) then clear Truck Info and Container Info since it is relevant only if all commodities are moved together.
Approval types summary
- single - defined in ASN 1.X
- double - defined in ASN 1.X
- no approval - new type - see below
- air approval - new type - below
Air Approval Type
This is an additional layer of approval for Air shipments that is required before CTs become visible to Jag Ops.
CTs created by Shipper Users that have this approval type selected would require Planner User who's is "Air Planner" to approve these shipments.
No Approval Type
This is a.k.a. Auto Approval.
CTs created by Shipper Users that have this approval type selected would be automatically available for Jag Ops bypassing any approval layer (unless Air Approval is required).
After Approval logic
Reminder that once CT is approved one of these two things would happen:
- it becomes available on dashboard for Jaguar Ops
- it is transmitted to other 3PLs
Notifications by Planner
Preserve ASN 1X notification:
- on any approval related status assignment/change (by Planner) - email to Shipper
Jaguar Operator Related Functionality
There are number of changes required on internal for ASN 20 version. See below.
ANA report
As in ASN 1X shipments that are approved (or not require approval) are ready for Transportation and need to come under radar of operators so that they can be handled.
This is achieved by Approved But Not Actioned shipments Dashboard Report (aka ANA Report).
It is similar in spirit and functionality to TDS Dashboard in ASN 1X for TMS (Truck Dom Stats) shipments for EA.
Newly approved shipments should appear on DR and stay there until they are noticed and acted on by an operator.
NOTE(!): TMS CTs should not be a part of this report as they are part of TDS.
ANA report level 1
Information is structured by Client and by #Transport Mode.
See mock up below.
For every such group of shipments two counters provided in the form of X/Y.
ANA status
ANA - approved (but not yet actioned);
CT has AR status if both conditions below are met:
- approved: CT "passed approval process" - approved by all planners involved or no approval was required
- not actioned: PU Trucker not assigned AND CTs not grouped AND Master not created AND none of Ref Num is assigned
ANA report level 2
Display (as on TDS):
- shipments with details (selected attributes)
- filters
Note that the following columns have been added in ASN 20:
- MOT
- Orig country
- Dest country
- CBM
- Haz, Y/N
Add to table below and filters.
Please note that in comparison with TDS there are no tabs here.
Instead there is a label identifying Client E0 and ANA status.
See mock up below:
ANA report on Reports Scheduler
Should be managed through Reports Scheduler (with dashboard option).
Filters:
- E0 multiselect - limits list of client companies available on DR
- MOT multiselect - limits list of MOTs available on DR - see below
E-mail option was not requested so please disable that option.
Jaguar Misc functionality
Add some fields on Internal to Gen Tab
All new fields defined for AS 20 needs to be shown/managed on internal (at the bottom of Gen Tab for all MOTs):
- cargo available
- cargo due
- planner (uname/fname/lname)
- shipper (uname/fname/lname)
- PO Issued By
- Approval type
Notifications by Jag Ops.
The following ASN 1X notification should remain:
- on Trucker assign (by Jag Ops) - email to Shipper
Final Tasks
Add Standard Archiving and Logs
- For all new entity admins Standard Archiving functionality needs to be implemented
- All user actions needs to be logged using Standard Logs
Add E0 specific Pick Up and Delivery Addresses
On ASN Form it would make most sense to display only Pick Up (Origin Door) and Delivery (Destination Door) Locations that are relevant to specific Supply Chain (E0).
These two lists could be defined in a Client Company profile.
One Shipper normally has many Pick Up and many Delivery Locations of course so wee need multiselect on UI.
Add these controls to a separate tab.
We also have to provide alternative to use addresses defined here or any address from Address book.
To achieve that:
- create 2 radio buttons separately for Pick Up and Delivery
- option 1: "Use addresses defined here"
- option 2: "Use Pick Up (T4 list) and Delivery Locations (T7 list) from CT2 Address Book"
Default is option 2 and therefore shippers will choose from any address available in the system.
[Mock Up TBD]
VG number feature (Optional task)
Add possibility to generate unique number associated with current VG.
Benefits:
- it works like "saved filter": by entering this number operator can quickly re-create CT list and continue working with this group
- helps in communication between operators
- helps in communication between operators and non jaguar users
- can be used in the future:
- to generate docs, in accounting docs
- each shipment leg can be associated with separate VG and hold specific to that leg values
Notes:
- see mock up below
- button "Generate" - see 1
- VG Note (hint on what type of CTs are in this group) - see 2
- Display list of generated VG numbers:
- show it under Main menu > Virtual Group > History
- display a table
- columns:
- date/time
- VG #
- who generated
- VG Note
- most recent records first
- checkbox filter: show my VG only
Statements Of Work
SOW 1 Create new branch for this project from trunk; create envir for QA/SIT/UAT
mantis: 0003680
Call it "ASN 20".
SOW 2 Add Clone User feature
mantis: 0003753
spec: ASN_20_Solution#Add Clone User feature
SOW 3 Misc: Add Create GRP action to Virtual Group
mantis: 0003754
spec: ASN_20_Solution#Add Create GRP action to Virtual Group
SOW 4 Create and consolidate TMS and ASN Admins
mantis: 0003755
spec: ASN_20_Solution#Create and consolidate TMS and ASN Admins
SOW 8 Re-design SKU Map
mantis: 0003756
spec: ASN_20_Solution#Re-design SKU Map
SOW 7 Flag CT feature
mantis: 0003757
spec: ASN_20_Solution#Flag CT feature
SOW 5 Merge Com and EQuery
mantis: 0003758
spec: ASN_20_Solution#Merge Com and EQuery
SOW 6 Flexible Shipments List
mantis: 0003768
spec: ASN_20_Solution#Flexible Shipments List
SOW 9 Add TMS E0 attribute
mantis:
spec: #Add TMS E0 attribute
Non critical bugs:
1) When entering filter it shows finded E0 and clear entered info in filter box
2) If change E0 in admin settings, then system will send all early approved CTs for this Client company to TMS. Also it should corectly works for CTs editing.(after editing send to TMS or not)
functional should be tested after all other changes on ASN portal
5) In log records "Old Value" is always "null"
SOW 10 Tune Role Admin
mantis:
spec: #Tune Role Admin
Non critical bugs/QA Notes:
1) "Also this should be obvious for the user - what role is of what type." regular user can't see what type of role is "build in" what is "User defined" in "users admin" is no mentioned.
2) In cpecification is no information about is "build in" roles are editable or not ? I think if somebody will edit "build in" role and would like to save it, system should propose to save it with another name.
SOW 11 New Planner Profile
mantis:
spec: #New Planner Profile
Non critical bugs:
"1) Is ""Super planner"" should not be set and read only in case of ""single approval procces"". What is should be ""by default"" for auto approval PO issues ?(should it be by default ""super planner"")"
2)Align "Authorize CT with PO Issued By:" dropdown(selector with whole element)
3)Align "Portals" and "Properties" or add some separator between them.
QA notes:
третья стадия апрува:
"air approval" нет описания, у него тоже будут супер планер и бейсик планер или общие с другим МОТ (бесик, супер) ???
"каким образом planner будет связан с порталами ? (у шипмента будет маркер каким порталом он создан ?)"
SOW 12 Shipments List for a Planner user
mantis:
spec: #Shipments List for a Planner user
SOW 13 Approval related logic
mantis:
spec: #Approval related logic
SOW 14 Add FTL vs LTL flag and add Truck table for FTL
mantis:
spec: #Add FTL vs LTL flag and add Truck table for FTL
SOW 15 ASN transmit
mantis:
spec: #ASN transmit
SOW 16 ANA report
mantis:
spec: #ANA report
SOW 17 Jaguar Misc functionality
mantis:
spec: #Jaguar Misc functionality
SOW 18 List of Portals and Portal Profile
mantis:
spec: #List of Portals and Portal Profile
Non Critical bugs:
"Transmit To:" is always "Jaguar CT2" hard coded but should be list from SOW 14 (critical)
1)When "All ASNs will be transmitted to 3PLs for transportation automatically" option is enabled then better to show options "Approvals" for "PO issue by" like "Auto"
2) No LOG records for this admin
3) It's possible to create few identical "transport modes" with the different "Transmit To:", how system will behave itself in this case ?
4) Mouse click on "Rules" for "transport modes" should select not only this particular rules but a common MOT also, so when user will try to edit it he get an admin panel for correct record.
Questions:
Зачем три столбца с МОТ ??? Почему описано "- Regions (multi with any) - Countries (multi with any) - Shippers (multi with any)" а на макете только страна ?
SOW 19 New Shipper Profile
mantis:
spec: #New Shipper Profile
SOW 20 New ASN Form
mantis:
spec: #New ASN Form
SOW 21 Shipments List for a Shipper user
mantis:
spec: #Shipments List for a Shipper user
SOW 22 New dims and CBM management
mantis:
spec: #New dims and CBM management
Dependencies for SOWs
- Column A: <y/n: Can coding be STARTED before all tasks in set B completed?>
- Column B: <set B:list of tasks (SOW#s) that must be completed before task A can be COMPLETED>
- Column C: <task A>
column A // column B // Column C ------------------------------ y // none // SOW 1 Create new branch for this project from trunk; create envir for QA/SIT/UAT y // none // SOW 2 Add Clone User feature y // none // SOW 3 Misc: Add Create GRP action to Virtual Group y // none // SOW 4 Create and consolidate TMS and ASN Admins y // 18 // SOW 8 Re-design SKU Map y // 12, 21 // SOW 7 Flag CT feature y // 12, 21 // SOW 5 Merge Com and EQuery y // 12, 21 // * SOW 6 Flexible Shipments List y // none // SOW 9 Add TMS E0 attribute y // none // SOW 10 Tune Role Admin y // 10, 18 // SOW 11 New Planner Profile n // 20 // * SOW 12 Shipments List for a Planner user ? // 20 // * SOW 13 Approval related logic y // 21 // * SOW 14 Add FTL vs LTL flag and add Truck table for FTL y // 20 // * SOW 15 ASN transmit y // 13 // SOW 16 ANA report y // 20 // SOW 17 Jaguar Misc functionality y // none // * SOW 18 List of Portals and Portal Profile n // 10, 18 // * SOW 19 New Shipper Profile n // 18, 19 // * SOW 20 New ASN Form ? // 20 // * SOW 21 Shipments List for a Shipper user
NOTE: coding for some tasks can start and even be nearly complete in some cases before set B is completed. But not QA.
CRWs
These are Change Request Work.
CRW 1 Introduce View Only Planner
mantis: 3808
spec: see below
BR: Add "view only" planner role.
Currently each planner can be Super and/or Air planner (see planners profile). This is PO Issued By specific.
To achieve that I suggest adding "Basic Planner" and "View Only" options.
If "Basic" is selected then this planner has basic planning functionality.
If "View Only" is selected then this planner has view only functionality. See below.
View only planner.
Such planners can only review CTs and post comments. Subject to PO Issued By visibility rules.
CRW 2 Add Client role to Portal
mantis: 3809
spec: see below
BR:
1) Add ability to configure Client (view only) role users for Portals. 2) Add "PO Issued By" as a condition to visibility rules.
CRW 3 Changes to Com component
mantis:
spec: see below
BR:
- 1) To field logic:
- on Client:
- default to operator of last change
- provide choice to email to nobody or anybody from the oper/client lists
- on Internal:
- default to "no email"; on submit warning: "Comment will not be e-mailed to anybody(OK, Cancel)"
- provide choice to email to nobody or anybody from the oper/client lists
- on Client:
- 2) Add Com tab to Edit CT form
CRW 4 Move Admin > ASN > Admin options to
mantis:
spec: see below
BR: These options must be Portal specific
UAT 2
CRW 5 Enable quick user creation through Portal
mantis:
spec: see below (TBD)
CRW 6 Re-design interface for Flexible Shipments List
mantis: TBD
spec: see below
"Mouse over header of the list and right click to show column management panel" is fine.
But pop up that manages visible columns and order of columns needs to be re-designed:
- should have 2 panels
- left panel has a list of all available fields in alphabetical order
- right panel contains all visible columns (top to bottom order indicates left to right order on a Sh.List)
- fields/order of fields are to be selected through "drag and drop": drag from left to right and immediately insert on the right in appropriate position
- see mock up below - picture shows two types of mouse drag and drop movements:
- one is to make column visible and position where user wants to (in the same movement)
- another is to re-order existing visible columns
List of fields available needs to be changed. This is the correct list:
- For all tabs:
- CT#
- Mode
- Sub-Mode
- Pick Up Location
- Delivery Location
- PO
- SKU
- Qty
- Piece Price
- Total Value
- Item Descr.
- New, Delivered, Archived:
- Created On
- Approved:
- Approved On
- Hold:
- Approved For
- Rejected:
- Rejected On
CRW 7 Change filters logic on Shipment List
mantis: TBD
spec: see below
- No need for "Apply filter" (except then for search) - change in filter should result in immediate re-draw
- "Display one line per CT" should be a checkbox on the very left
- Add "Display one line per CT" (on/off) functionality for specific CT (not all)
- When "Display one line per CT"=off highlight in one color all commod lines of specific CT. Alternate line highlight as in standard ZK design but not per line but per CT. See example below:
CT# PO <color> 123 1 gray 123 2 gray 555 7 white 765 9 gray
CRW 8 Re-design Truck Info
mantis: TBD
spec: see below
BR (Marc/Simon):
We want to request the following info from Shippers when they submit ASN for FTL shipments:
- how many trucks of what size are required to move commodities defined on ASN
- what size, seal, trailer number each truck has
- assign commodities to each truck (as for containers)
Typical truck size values: 48 ft, 53 ft.
ISA (Alex/Kostya):
Truck Info should be managed similarly to containers:
- lines with truck size / seal# / trailer id
- assign to commod line function
- note: num of trucks should be a drop down
- validation: all fields are optional
Also:
- manage truck sizes in Admin - add this as a tab to Admin > Transportation
- associate this info with both Pick Up Trucker and Delivery Trucker
- "summary" line should be added to indicate what is the total of trucks for each size in the table -this eliminates the need to have a separate option to just indicate how many of what size (in case user does not provide additional info such as seal/trailer id/link to commodity item)
- PT / DT fields (trailer ids designed for TMS) must be refactored
- Data should be migrated
- Reports that have trailer id must be re-factored:
- In transit
- Delivert Trailer
- Impending Del/Col
- Main
- Pend Appr Rep
- Previous Day
- if ASN is not approved completely first time by planner (all items) then clear Truck Info since it is relevant only if all commodities are moved together.
Solution (Alex/Kostya):
See ISA above.
See mock up below:
Alternative Solution (Marc):
- for FTL add 2 fields to each commodity line: truck#, size
- preserve existing limitation of one Truck Dom shipment (FTL or LTL) cant have more commodities than one truck.
- in ASN allow to enter more commodities than one truck; require map commodities into trucks
- on submit create one CT per truck
- if Planner approves CT partially (just some items) then
CRW 9 Re-design Container size and type admin
mantis: TBD
spec: see below
Add flag to each item: include or exclude item when this list shows through portal.
(This is to exclude "LCL" value from portal - they use it for internal)
Misc
https://docs.google.com/spreadsheet/ccc?key=0Am72_c2KUoQjdFc2NTNTcjhyZEFrVVdSSkdFTFVxZXc#gid=9
