Hi Chris,

This is quite strange and seems to indicate that other contracts/lines are linked somehow to this contract or were at one time (perhaps a canceled contract or canceled lines?).

To correct this, I would try in a DB copy on a UAT system if possible to recalculate the revenue recognition using the contract revenue recognition module to see if this clears up the situation.

Other than that, I would suggest raising a support ticket as it seems you have a data issue which I don’t think we can fix over a Community post.

Hi Phil,

Thank you for the suggestion.  I tried it in one of our pilots, I just entered the contract ID and hit RUN, but it did not change anything.  One thing that seemed strange was that the “Recognize Until” field shows 012021...

Anyway, I guess I need to open a support ticket.

Thanks

Chris

Recognize until reflects the current fiscal period defined in the financial settings for the profile.  This is not modifiable in contract revenue recognition screen as it is picked up automatically.  That naming indicates it looks like the current active fiscal period is Jan 2021.

What you can do is review the contract revenue data table rows and see if there is a clue where the ccontl that is involved might be coming from with the high numbers?

select * from ccont_rec_rev with(nolock) where cconth_id = 'UJ65385_7'

Hi Phil,

Thanks.  The only thing I can spot is that those high value lines have the ccont_version set to -1, where it is zero for everything else.  I did a search for just lines that had ccont_version set to -1 and found only 2 contracts from the last 11 years, so it certainly seems to be significant… but I have no idea why or how this might have happened.  I’ll discuss it with someone here that is more familiar.  Thanks again.

Hi Phil,

We managed to resolve this issue, thank you

Hi Chris,

May I ask how you resolve the issue and what was exactly the problem that caused this situation?

Hi Phil,

After some testing in Pilots, we decided to remove the lines where ccont_version was set to -1

Might be better if the code that pulls in the recognition ignored those lines perhaps?

Hi Chris,

What you suggest by ignoring the rows when retrieved will not really resolve the underlying issue.

I would think it would be better to find out how this happened and prevent it in the first place.  Otherwise you are only cleaning up the display by removing it from the DAL but any reporting which is looking at the rows might still pick it up, etc.

It is a very rare occurrence which suggests to me that perhaps it was something environmental while executing some process that left these rows there.  I don’t know what the purpose of the ccont_version but because it was set to -1, this also suggests that this was a temporary row that should have been removed by the process and it could not for whatever reason.