Cybertrax 2.1 Client (Q and A)
From UG
(→Answered Questions) |
(→New Questions) |
||
Line 4: | Line 4: | ||
- | === | + | === Need visibility defined per user type, MOT, client, office, internal user group, etc === |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
Part A) new fields: visibility, Read/Write Access must be defined for each type of user, MOT, etc; | Part A) new fields: visibility, Read/Write Access must be defined for each type of user, MOT, etc; | ||
- | |||
- | |||
We have significant number of new CT fields introduced: PO Issued by, Piece price, Approved For Date, etc | We have significant number of new CT fields introduced: PO Issued by, Piece price, Approved For Date, etc | ||
- | |||
- | |||
Important questions for each field: | Important questions for each field: | ||
- | |||
- | |||
Are they visible? This must be defined separately for: | Are they visible? This must be defined separately for: | ||
Line 38: | Line 28: | ||
Of course simplest answer: b,c,d,e – visible for all. If we want to differentiate then I suggest not to hard code and define this through admin. | Of course simplest answer: b,c,d,e – visible for all. If we want to differentiate then I suggest not to hard code and define this through admin. | ||
- | + | === Need read or write defined per user type, different phases in the lifetime of the shipment === | |
- | Next question is: If | + | Next question is: If new field is visible then are they open for read or also write? Must be defined separately for: |
* a] each of 4 types of users: jaguar/internal, shipper, planner, client | * a] each of 4 types of users: jaguar/internal, shipper, planner, client | ||
Line 50: | Line 40: | ||
Some of this already defined, but not all – it is a matrix: (option a) X (option b) | Some of this already defined, but not all – it is a matrix: (option a) X (option b) | ||
- | |||
- | + | === Some new fields seem to duplicate existing === | |
- | |||
New fields | New fields | ||
Line 98: | Line 86: | ||
- | + | === Existing Authorization process seems to overlap with new === | |
- | + | ||
- | + | ||
We have authorization process for Client/internal now. Are we going to keep both it or replace it by new? | We have authorization process for Client/internal now. Are we going to keep both it or replace it by new? | ||
- | |||
- | |||
Part D) Approval Report | Part D) Approval Report | ||
- | |||
1) it needs to be defined in details | 1) it needs to be defined in details | ||
- | |||
- | |||
2) We already have Approval report defined. Options: | 2) We already have Approval report defined. Options: | ||
Line 119: | Line 100: | ||
b) Keep old but then we need another name for new report | b) Keep old but then we need another name for new report | ||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
== [[User:Alex|Alex]] 19:31, 19 June 2010 (EDT) == | == [[User:Alex|Alex]] 19:31, 19 June 2010 (EDT) == |
Revision as of 00:34, 20 June 2010
Contents |
New Questions
Need visibility defined per user type, MOT, client, office, internal user group, etc
Part A) new fields: visibility, Read/Write Access must be defined for each type of user, MOT, etc;
We have significant number of new CT fields introduced: PO Issued by, Piece price, Approved For Date, etc
Important questions for each field:
Are they visible? This must be defined separately for:
- a] each of 4 types of users: jaguar/internal, shipper, planner, client
- b] each MOT: air, ocean, etc.
- c] each Client Company? (show them for EA Arden Domestic only?)
- d] each Office? ? (show them for NY only?)
- e] each Jag operator/group? ? (show them only for operators dealing with EA Arden Domestic?)
Of course simplest answer: b,c,d,e – visible for all. If we want to differentiate then I suggest not to hard code and define this through admin.
Need read or write defined per user type, different phases in the lifetime of the shipment
Next question is: If new field is visible then are they open for read or also write? Must be defined separately for:
- a] each of 4 types of users: jaguar/internal, shipper, planner, client
- b] different phases in the lifetime of the shipment (example: commodity info may not be changed after Ct is approved)
Some of this already defined, but not all – it is a matrix: (option a) X (option b)
Some new fields seem to duplicate existing
New fields
- Authorization status,
- Approved For Date,
- Approved By
- “Approved On
- etc
seem to serve same purpose as existing:
- Authorized By,
- Authorized MOT (could be hold),
- Authorization Method,
- On Customer Hold
- Pending Approval
We have to make a decision if we want to:
Option a) “discontinue” some of the old fields (then we must analyse where on pdfs/reports, etc we used them and delete or archive)
Option b) re-use some of the old fields (and potentially rename)
Option c) keep all as is but define better the difference and purpose
Existing Authorization process seems to overlap with new
We have authorization process for Client/internal now. Are we going to keep both it or replace it by new?
Part D) Approval Report
1) it needs to be defined in details
2) We already have Approval report defined. Options:
a) Change existing
b) Keep old but then we need another name for new report
Alex 19:31, 19 June 2010 (EDT)
1] Do we need to limit # of lines on internal to 1 line? (blocking adding lines)
2] Should jag users be able to edit commod table created by shipper at all?
Answered Questions
How to avoid situation when planners ignore some new shipments for a long time?
- A: Currently this is not required for phase 1 and will be addressed for possibly phase 2. Although, suggestion was given such as auto approve or auto reject, based upon a certain amount of time. Yet this is something that would need to be further discussed and defined by Elizabeth Arden.
When Jag operator may see or "start to move" CT?
- A: Once a record is approved by a planner or an E.M, that shipment will then show on the live tab for both the internal & client applications
What additional read-only fields edited by Jag oper Shipper will see?
- A: Trucker, Estimated Pick up date, Actual Pick up date, Estimated Delivery date, Actual Delivery date, Approved (with name of person who approved, including the date & time), Hold (with name of person who placed on hold, including the date & time), Rejected (with name of person who rejected it, including the date & time)
EM and Planner - same thing?
- A:No, not the same thing, but they are similar. They play the same role in the approval process.
Any requirement for release date?
- A: ASAP, ideally just several weeks