Discussion of State vs. Status and settings involved.

Document ID : KB000105775
Last Modified Date : 09/07/2018
Show Technical Document Details
Introduction:
This is a discussions about "State" vs "Status" and how this relates to a number of settings such as "Allow Discrete Request Life Cycle After".
Instructions:
First,
I will try and elaborate on some settings which are already described in our documentation and how they relate.

"Allow Discrete Request Life Cycle After" ::: determines whether a request which contains different services can move these services ahead to a different state without the other services in that request being in the same state. If you were to set this to "Complete" then there would be NO discrete life cycle processing and all services for that request would be in the same state. 
What is important to realize is that this refers to Catalog states (such as Approval, Processing and Complete) which are not the same as a status and cannot be customized.
There may be many different statuses in each state and the services can all have a different status. For example one could be in the approved state and one could be waiting for approval but these would both be in the "Approval" state and if discrete life cycle processing was not in effect then they would not move on to the "Processing" state until they were all approved.

"Allow Cancellation Through" :::: Refers to status and the maximum value you can set is "fulfilled".

So, to provide a brief walkthrough and explain a real world situation which caused some questions in the past:

Basically, the short answer is that cancelled is a unique case and can be both a status and a state. 
But in general the cancelled status is considered part of the "complete" state as far as things like lifecycle go. 
So all the services are considered to be in some type of "complete" state. The state of the request just picks the lowest one in the DB. 
So it sounds like (with the patch) everything is working as designed. 
Here is a more detailed example: 
1.Since the customer set "Allow Discrete Request Life Cycle After" to "Completed" there is no discreate life cycle here in this scenario. 

2.Let us consider the request has two services, first is moved to fulfillment and second one is in pending-fulfillment state. 

3.Customer set the "Allow Cancellation Through" to "fulfilled", that is maximum value user can set. 
What "Allow Cancellation Through" says is: 
"you can cancel a request only if the status of the request has not exceeded the status specified by the Allow Cancellation Through setting in the Catalog, Configuration, Options, Request Management Configuration." 

4.Here the status of the service (fulfilled) is same as the status specified by the "Allow Cancellation Through", in this case also cancellation is not allowed (this may require update of documentation something like this: 
you can cancel a request only if the status of the request has not equal to or exceeded the status specified by the Allow Cancellation Through setting in the Catalog, Configuration, Options, Request Management Configuration) 

5.Whatever the service with status same or greater than the "Allow Cancellation Through" will mark it as complete 
Whatever the service with status less than the "Allow Cancellation Through" will mark it as cancel. 
Overall status of the request is marked as complete. 

6.What if customer want to set the status to cancel in this case? 
Set "Cancel Completed Requests" to Yes and cancel the completed request again. This resolves the issue. 

7.On the usm_subscription_detail table, the first item_id has a status of Completed = 2. 
However, all the status, are set to Cancelled = 4: 
This is an issue need to be addressed. This seems to be fixed in 17.1 RU1 in our testing.