Thanks for logging your question, Srini. Can you provide additional details on exactly what issues you are encountering? What is the unexpected action taking place and what are you seeing? This information may help the community to diagnose and chime in.
Essentially when one click on pricing terms associated with a contract, they get kicked out of with unhandled exception. This initially started on contracts that were amended but is now occuring on newer contracts too.
We have a SR and our solution right now is to reboot the application!
Wondering if others are facing similar issues.
I work with Srini. Below are a couple of examples of scenarios we have encountered with versioning control issues:
1) Amend a Contract Workspace. System should create a V3, but created a V2 again. So, we have 2 CRs CR-XXXX-V2 one in Processed and one in Composing state.
2) Amending Contract Workspace w/Terms not creating new version of CR. - The function of amending a workspace to change pricing terms is changing Pricing Term document status to Draft, however, linking to the last version 'Processed' instead of creating a new version of the last version ContractRequest.
3) Workspace amendment creating a new CR# instead of versioning - When customer amends a Contract Workspace , the system will create a new contract request number instead of creating the next version on the original CR.
We have experienced very similar behaviour a few times, although I can't provide an example of how it occured. We have had to start over a few times with some of our ACC terms (not fun for reporting, and continuity)
Otherwise our IT folks had found:
Two ContractRequests were linked to the same ExternalSourcingId.
On the ContractRequest with the following UniqueName: Inactive_PSL_15009_CR30-V8, the ExternalSourcingId has been set to PSL_15009_Doc141029 via inspector.
I don't think it has ever been determined how the CR's ended up being linked to the same ExternalSourcingId.