FFM: Comments on: Status code explanations - IB 17-Aug-11.docx uploaded

[Johannes Lehtinen <johannes.lehtinen@rossum.fi>]

Hi! Thank you for the explanations, this helped me to understand how you were envisioning to use the different status codes.

I have couple of comments and questions regarding these status codes. These are probably due to slightly different visions on how the FFMII interface would be used in practice so I am bringing them up so that we can eventually form a unified view on these aspects.


First of all, I see that the described status codes have been derived mostly from ERMS perspective. While I am sure that they are all applicable to the ERMS side work handling process, I am not sure how some of the status codes would be applied in the scope of FFMII. So, to clarify the potential use cases for these status codes...

Status code "Open": Per the explanation this indicates that a Work Request or Activity exists but has not yet been assigned to anyone. However, my understanding is that from FFMII perspective there is no Work Request before the associated Task has been assigned to some Assignee in ERMS after which ERMS creates a Work Request and sends it over FFMII to FFMS. Of course, the customer order and Task description exists in ERMS in some form before the assignment but is this stage relevant to FFMII interface?

Status code "Scheduled": Per the explanation the WR is assigned but not yet necessarily communicated to the Assignee. Does not sending a Work Request over FFMII equal to communicating the Task to the Assignee already? The Assignee is not necessarily actively notified about the new Work Request (depends on the Implementation) but WR is made available to the Assignee anyway. So, is this stage relevant to FFMII interface (or does it really differ from "Tentative")?

Also, in the case a Task is unassigned from one Assignee and then assigned to another Assignee, I was thinking that this would involve canceling the original Work Request and creating a new one for the new Assignee (although the logical Task in ERMS side might be the same). Based on status code explanations, it seems that you were planning that the same Work Request would be moved between Assignees? Would it first become unassigned and linger in that state (also in FFMS) until it is later assigned again?

In some cases there can not be 1:1 mapping between ERMS side work description and a Work Request. For example, when the work is split to multiple Tasks assigned to different Assignees, then a separate Work Request must be created for each of them.


Finally, regarding status transition diagram at the end...

Would this be just an explanatory diagram on how these status codes are typically used (while the actual state model could still be dynamically specified without limitations) or is the idea that this would statically define the possible transitions between status codes? For example, in simple scenarios the acknowledgement/rejection phase might be unnecessary. Also, it is a bit unclear to me what transitions would be initiated by Assignee actions and what transitions by Manager (or both?).

BR, Johannes

2011/8/17 <israel.beniaminy@clicksoftware.com>

The document named Status code explanations - IB 17-Aug-11.docx has been
submitted by Israel Beniaminy to the OASIS Field Force Management (FFM) TC
document repository.

Document Description:
Definition of proposed status codes for WRs and Activities

View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=43242

Download Document:
http://www.oasis-open.org/committees/download.php/43242/Status%20code%20explanations%20-%20IB%2017-Aug-11.docx


PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.

-OASIS Open Administration

-- 
Johannes Lehtinen
gsm +358 40 734 7049
Rossum Oy