Cybertrax 2.1 Client (Q and A)

From UG

(Difference between revisions)
Jump to: navigation, search
(→Any requirement for release date?)
 
(14 intermediate revisions not shown)
Line 1: Line 1:
[[Category:Cybertrax 2.1 Client]]
[[Category:Cybertrax 2.1 Client]]
-
== [[User:Alex|Alex]] 20:09, 19 June 2010 (EDT) ==
+
== How to use this doc ==
-
I discovered number of new questions to be addressed.
+
Question could be posted here.
-
+
Add wiki signature, forward link to someone you think might answer.
-
Part A) new fields: visibility, Read/Write Access must be defined for each type of user, MOT, etc;
+
Discussion could be posted here.
-
+
If answer is final then spec must be updated and question marked as answered - move to [[#Answered Questions]].
-
We have significant number of new CT fields introduced: PO Issued by, Piece price, Approved For Date, etc
+
== New Unanswered Questions and Discussion ==
-
+
=== Some new fields seem to duplicate existing ===
-
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.
 
-
 
-
 
-
 
-
Next question is: If they are 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)
 
-
 
-
 
-
 
-
Part B) some new fields seem to duplicate existing
 
-
 
-
 
New fields  
New fields  
Line 82: Line 45:
   
   
-
 
We have to make a decision if we want to:
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 a) “discontinue” some of the old fields (then we must analyse where on pdfs/reports, etc we used them and delete or archive)
Line 93: Line 54:
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
-
+
'''Answer:'''
 +
???
-
Part C) existing Authorization process
+
== Answered Questions ==
-
+
=== How to avoid situation when planners ignore some new shipments for a long time? ===
-
We have authorization process for Client/internal now. Are we going to keep both it or replace it by new?
+
'''Answer:'''
 +
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? ===
-
Part D) Approval Report
+
'''Answer:'''
 +
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? ===
-
1)     it needs to be defined in details
+
'''Answer:'''
 +
:: '''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? ===
-
2)      We already have Approval report defined. Options:
+
'''Answer:'''
 +
:: '''A:'''No, not the same thing, but they are similar.  They play the same role in the approval process.
-
a)      Change existing
+
=== Any requirement for release date? ===
-
b)      Keep old  but then we need another name for new report
+
'''Answer:'''
 +
:: '''A:''' ASAP, ideally just several weeks
-
 
-
Part E) #One_user_with_multiple_roles requirement
+
=== 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;
-
Now I feel that it might be easier/faster to code (and of course maintain/grow code) with option 2 (see below).
+
We have significant number of new CT fields introduced: PO Issued by, Piece price, Approved For Date, etc
-
+
Important questions for each field:
-
Dev team will get a better feel for this next week.
+
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.
-
Quote from http://mantis.jaguarfreight.com/wiki/Cybertrax_2.1_Client_(requirements)#One_user_with_multiple_roles  :
+
* c] each Client Company? (show them for EA Arden Domestic only?)
-
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
* d] each Office? ? (show them for NY only?)
-
One user with multiple roles
+
* e] each Jag operator/group? ? (show them only for operators dealing with EA Arden Domestic?)
-
[a] It is possible for one person to have more than one "user role". Example: Shipper / Planner, Shipper / Client; Shipper / Planner / Client; etc.
+
'''Answer:'''
-
[b] There are two different approaches to interface in this case:
+
* a)
 +
** client - do not change functionality
 +
** shipper/planner/jaguar - may see all NEW fields
 +
* b,c,d,e – visible for any value for now
-
§  option 1) show separate shipments lists depending on role
+
=== Need read or write defined per user type, different phases in the lifetime of the shipment ===
-
§  option 2) show one shipments list and provide additional filters that would allow user to show:
+
Next question is: If new field is visible then are they open for read or also write? Must be defined separately for:
-
§  all shipments
+
* a] each of 4 types of users: jaguar/internal, shipper, planner, client
-
§  only shipments user would see in "shipper role"
+
* b] different phases in the lifetime of the shipment (example: commodity info may not be changed after Ct is approved)
-
§  only shipments user would see in "planner role"
+
Some of this already defined, but not all – it is a matrix: (option a) X (option b)
-
§  only shipments user would see in "client role"
+
'''Answer:'''
-
+
* 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
-
== [[User:Alex|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?
+
=== Existing Authorization process seems to overlap with new ===
-
== Original ==
+
We have authorization process for Client/internal now. Are we going to keep both it or replace it by new?
-
* '''Q''': <!--Alex--> ''How to avoid situation when planners ignore some new shipments for a long time? ''  
+
'''Answer:'''
-
:: '''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.
+
Keep both
-
* '''Q''': <!--Alex--> ''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
 
-
* '''Q''': <!--Alex--> ''What additional read-only fields edited by Jag oper Shipper will see?''
+
=== Approval Report ===
-
:: '''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)
+
-
* '''Q''': <!--Andrei--> "EM" and "Planner" - same thing?
 
-
:: '''A:'''No, not the same thing, but they are similar.  They play the same role in the approval process.
 
-
* '''Q''': <!--Andrei--> Why 10? Why not make it flexible?
+
1)      it needs to be defined in details
-
:: '''A:'''This was not a phase 1 requirement.  It will be further discussed for phase 2.
+
 
 +
2)      We already have Approval report defined. Options:
 +
 
 +
a)      Change existing
 +
 
 +
b)      Keep old  but then we need another name for new report
 +
 
 +
 
 +
This functionality is replaced with TDS dashboard
 +
 
 +
=== Do we need to limit # of lines on internal to 1 line? (blocking adding lines) ===
 +
 
 +
'''Answer:'''
 +
Yes
 +
 
 +
=== Should jag users be able to edit commod table created by shipper at all? ===
-
* '''Q''': <!--Alex--> Any requirement for release date?
+
'''Answer:'''
-
:: '''A:''' ASAP
+
Yes

Current revision as of 22:46, 16 July 2010


Contents

[edit] How to use this doc

Question could be posted here.

Add wiki signature, forward link to someone you think might answer.

Discussion could be posted here.

If answer is final then spec must be updated and question marked as answered - move to #Answered Questions.

[edit] New Unanswered Questions and Discussion

[edit] 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

Answer: ???

[edit] Answered Questions

[edit] How to avoid situation when planners ignore some new shipments for a long time?

Answer: 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.

[edit] When Jag operator may see or "start to move" CT?

Answer: 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

[edit] What additional read-only fields edited by Jag oper Shipper will see?

Answer:

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)

[edit] EM and Planner - same thing?

Answer:

A:No, not the same thing, but they are similar. They play the same role in the approval process.

[edit] Any requirement for release date?

Answer:

A: ASAP, ideally just several weeks


[edit] 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?)

Answer:

  • a)
    • client - do not change functionality
    • shipper/planner/jaguar - may see all NEW fields
  • b,c,d,e – visible for any value for now

[edit] 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)

Answer:

  • 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


[edit] 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?

Answer: Keep both


[edit] 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


This functionality is replaced with TDS dashboard

[edit] Do we need to limit # of lines on internal to 1 line? (blocking adding lines)

Answer: Yes

[edit] Should jag users be able to edit commod table created by shipper at all?

Answer: Yes

Retrieved from "https://wiki.jaguarfreight.com/Cybertrax_2.1_Client_(Q_and_A)"
Personal tools