Cybertrax 2.1 Client (Q and A)
From UG
(→Answered Questions) |
(→New Questions) |
||
Line 24: | Line 24: | ||
* e] each Jag operator/group? ? (show them only for operators dealing with EA Arden Domestic?) | * e] each Jag operator/group? ? (show them only for operators dealing with EA Arden Domestic?) | ||
- | + | ==== A ==== | |
- | + | * a) | |
- | + | ** client - do not change functionality | |
+ | ** shipper/planner/jaguar - may see all NEW fields | ||
+ | * b,c,d,e – visible for any value for now | ||
=== Need read or write defined per user type, different phases in the lifetime of the shipment === | === Need read or write defined per user type, different phases in the lifetime of the shipment === | ||
Line 36: | Line 38: | ||
* b] different phases in the lifetime of the shipment (example: commodity info may not be changed after Ct is approved) | * 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) | |
- | + | ==== A ==== | |
+ | * a) | ||
+ | ** client - do not change functionality | ||
+ | ** jaguar - can edit all fields (for now) | ||
+ | ** planner - can only edit its own fields as defined in Requirements | ||
+ | ** shipper - can only edit its own fields | ||
Line 84: | Line 91: | ||
Option c) keep all as is but define better the difference and purpose | Option c) keep all as is but define better the difference and purpose | ||
- | + | ==== A ==== | |
+ | |||
+ | see "(data dictionary)" | ||
=== Existing Authorization process seems to overlap with new === | === Existing Authorization process seems to overlap with new === | ||
Line 90: | Line 99: | ||
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? | ||
- | + | ==== A ==== | |
+ | Keep both | ||
+ | |||
+ | |||
+ | === Approval Report === | ||
Line 100: | Line 113: | ||
b) Keep old but then we need another name for new report | b) Keep old but then we need another name for new report | ||
+ | |||
+ | |||
+ | |||
=== Do we need to limit # of lines on internal to 1 line? (blocking adding lines) === | === Do we need to limit # of lines on internal to 1 line? (blocking adding lines) === | ||
+ | |||
+ | ==== A ==== | ||
+ | Yes | ||
=== Should jag users be able to edit commod table created by shipper at all? === | === Should jag users be able to edit commod table created by shipper at all? === | ||
+ | ==== A ==== | ||
+ | Yes | ||
== Answered Questions == | == Answered Questions == |
Revision as of 18:41, 22 June 2010
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?)
A
- a)
- client - do not change functionality
- shipper/planner/jaguar - may see all NEW fields
- b,c,d,e – visible for any value for now
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)
A
- a)
- client - do not change functionality
- jaguar - can edit all fields (for now)
- planner - can only edit its own fields as defined in Requirements
- shipper - can only edit its own fields
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
A
see "(data dictionary)"
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?
A
Keep both
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
Do we need to limit # of lines on internal to 1 line? (blocking adding lines)
A
Yes
Should jag users be able to edit commod table created by shipper at all?
A
Yes
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
- 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
- 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
- A: ASAP, ideally just several weeks