I am getting confusing results when a user tries to update the User Status of an Opportunity in the WebUI of CRM 7.0.
The values for User Status has gone through multiple iteration. The current values are:
- In Process
However, for some Opportunities, the old values are appearing when I click on the drop down.
Another example is even stranger. This Opportunity shows a Status of “Open” in the Search results (see below).
However, when I click to see the details of the Opportunity, the Status shows “BTStatus not bound” (see below).
When I press “Edit”, the Status blanks out (see below).
When I click on the drop down for Status for this Opportunity, there are no available values (again see below). The available values from the drop down overlays the “Reason” field. As you can see, there are no available values for Status and I cannot enter anything.
If I go to a different Opportunity, the Status in the Search Results shows “In Process” and the Opportunity Details also shows “In Process”. The values available in the drop down are the current ones configured (see below).
Hopefully someone can explain what is going on and more importantly, how to fix the problem. Thanks.
Under old values do you mean values from old status profile? Do you use same or different status profile for 'old' and 'new' statuses?
Or there is the same status profile and are you confused with the sequence of available statuses? Please clarify your question.
The easiest answer for all your questions would be that you're checking different transaction types of opportunities.
For instance, first document has document type which in turn has status profile that you're showing with 'Won', 'Lost', 'Stopped by customer' etc.
Second document's transaction type does not have status profile at all. And in search results you see system status Open, in details view you see BTStatus not bound because you are in view mode and there is no user status set. And when you switch to change mode you see empty dropdown list. It's normal behavior for dropdown lists.
And the last one is just different transaction type with status profile different from the first one.
So clarification is needed.
Thanks for responding. From the behavior of the application, it seemed that the Status Framework has a "memory". I wasn't able to browse CRMD_JEST using SE16. I get the error that the table is not active in the dictionary.
Do you know how we can make the application use only the current set of values for Status? Also, any ideas on the other results I mentioned?
It's been a long while but the table you are looking for is CRM_JEST. You should not be getting the not-bound issue in a normal system. Now the problem is that if you removed statuses from the profile then the system might not be able to calculate what the available statuses should be based on the current status for an existing document. This is of course based on sequence number in your profile for the statuses how far it can go. You never want to remove a status that is in use from a profile without changing to the new status code in all the corresponding documents or otherwise things will become very very messy.
Hi Stephen and Andrei,
Are you saying that the configuration needs to have all of the previous values for User Status in addition to the new ones? If so, i would
1. Add the previous values back in,
2. Move that through the system; DEV -> QA -> PRD
3. Update the User Status for all Opportunities to the "new ones"
4. Change the configuration so that only the new ones are in the configuration
5. Move the "new User Statuses" through the system; DEV -> QA -> PRD
Yes If you have existing transactions then you need do it that way, or otherwise it will lead to inconsistent results/documents in your system.
The only issue is I can't remember as you add or remove the statuses from the profile, whether the technical code underneath for each value will change. Might want to verify this back in your Dev/QA because it could really lead to worse problems.
Thanks for the feedback. I'll check the results back in DEV/QA.
That also means that all of the User Statuses, old and new, will apprear for existing Opportunities. So until all the existing Opportunities go to completion, the user could update an existing opportunitiy with an incorrect User Status.
Do you know of any way that the functionality could be "forced" to show only the new User Statuses? Sounds like a bug to me.
In looking at the Statuses for the three versions of the configuration, I find that the same Status Number means different things depending on the version. For example, Status Number 1 means “Open” for the first version of the configuration; Status Number 1 means “Identify Opportunity” for the second version of the configuration and Status Number 1 means “In Process” for the third (current) version of the configuration. There are other Status Numbers with multiple meanings depending on the version of the configuration.
This means that the it isn’t possible to include all of the old and new Statuses in an updated configuration.
What would you suggest?
I think that Stephen ment not Status Number but technical code (e.g. E0001, E0002, E0012 etc.) of each of the status.
One thought how you can resctrict the list of statuses. You can enter authentication key in status profile for old statuses and do not give authorization for this key for users. So users won't be able to change current status to one of 'old' statuses. Also it's better to somehow translate old statuses to new ones in still open opportunities.
And seeing old statuses it's not a bug. There are no old or new statuses for the system. They are all equal. In my opinion it's not a good practise to change status profiles frequently.
Didn't you try to change assignments of status profiles to transaction type? I mean you can try to leave old statuses, let's say, in old status profile, create new one with new statuses and assign new status profile to the same transaction type.
We have the same issue with Status (E0001, E0002, etc) as with Status Number. The same Status means different things depending on the version of the configuration. For example, Status E0001 means “Open” for the first version of the configuration; Status E0001 means “Identify Opportunity” for the second version of the configuration and Status E0001 means “In Process” for the third (current) version of the configuration. There are also other Statuses with multiple meanings depending on the version of the configuration.
Good idea on the restricting of Statuses. Also I would agree with you that it is not a good practice to change Status Profiles. Between the users changing their minds and the business requirements changing, we went through three versions of the configuration; all with the same Status Profile name and the same Transaction Type. Obviously I did not know the problems it would cause when the meaning of the Status for a particular Status Code (E0001, E0002, etc) was changed.
Thanks for your help.
I tried adding the old Statuses back in but the User Status as assigned by the system did not match the User Status that was in the Opportunity. For example, in an existing Opportunity with an old Status, the User Status was E0003, which was the ID of the User Status that was deleted. When that User Status was added back in, the system simply assigns the next number for the User Status, e.g. E0010. Obviously E0003 does not match E0010. It was easy to confuse User Status with Status. Table TJ30 shows the User Statuses in the Status Profile being used.
The problem was solved by deleting the Status Profile and recreating it. Since the Status Profile we were using started with a copy of Status Profile CRMOPPOR, I copied it to the the same Status Profile name that I had just deleted. I then added the new User Statuses. That way E0003 (as well as any other User Statuses that had been deleted) was back in the Status Profile. Then I was able to change the User Statuses of existing Opportunities to the new User Statuses specified by the business using the mass change capability. The next step that will be done wil be to delete the old User Statuses since they will no longer be wanted and will not have any Opportunities with those User Statuses..
Thanks for all your help Stephen and Andrei. I really appreciate it.