This blog is intended to describe the functionality and the use-case for the consistency check in C4C transactions.
For example lead & opportunity are error tolerant objects i.e. in most cases if inconsistent data is maintained even though an error message is thrown , we allow the user to continue to save the data . However in such cases , we set the consistency status to ‘inconsistent’ . This will prevent follow-up object creation e.g. lead cannot be converted to an opportunity or a follow-on quote cannot be created for an opportunity.
The consistency check is internally run in the BO when any changes are made and saved. It just re-runs all the important validations of the object to determine consistency status.
User needs to trigger it manually ONLY in some cases (see below).
In the past we had seen following issue within implementation projects:
Imagine there were mandatory checks maintained in party fine-tuning due to which the objects get inconsistent, if this mandatory data isn’t maintained. Now the fine-tuning is changed to remove the checks/the mandatory settings. But the already existing inconsistent objects remain inconsistent, thereby preventing follow-ups. This inconsistent status can be removed only by making any change and saving the object. Since this was not obvious to the user , we exposed the ‘check consistency’ action .
This action can be used in following cases :
- User should use this in conjunction with the consistency status in the header (field can be added via KUT). In case an object is inconsistent , this action can be triggered at any time to re-check the instance and display relevant error message
- If user tries a follow-up and gets a message ‘Source document is inconsistent’ , this action can be triggered to check the issues.
If action is triggered and re-check is successful, the consistency status will be updated.