Cashbook Bank Reconcilation issue - getting message 'Values have Changed'

Hi all,

Just wanted to make you aware I have had 3 different customers in the week report an issue when trying to complete their Bank Reconcilation it does not print and then they get a message 'Values have Changed' and it just keeps going around in a loop.

I do believe this is a defect and it is related to the rectification process in someway (not sure if both PL and SL) but on 2 of the sites I have been able to identify where two very separate transactions from the purchase ledger which have been part of the rectification process have got assumed with the same at_entry and ae_entry numbers - i'm still trying to find what the culprit is on this 3rd site which is getting exactly the same issue. I have been able to fix 2 of the customers so far by giving one of the entries on atran and aentry its own ae_entry number.

I have an incident open with Pegasus but not had any communication back from them as yet and it was reported on 10th June.

Regards

Claire

Find more posts tagged with

Pegasus - Partner General Discussions

Comments

unknown

Hi Claire,

What release of Opera 3 does this pertain to ? i.e. What release of O3 do your 3 customers have ?

Thank you for sharing with the community.

claire-craig

Two of them are on 2.81.02 and one on 2.81.03

unknown

hi calire, havent come across thie en masse like that. We use a select statement that identifies the culprits if this helps:

select ae_acnt+ae_cntr+ae_entry as aekey from aentry into cursor ae

select count(aekey), aekey from ae into cursor counts group by aekey

select count(aekey) as cnt1, aekey from ae into cursor counts group by aekey having cnt1<>1

The do a set filter to, on the entries it finds………

Usually you may find the duplicate entries, amend the second duplicated number by putting a letter at the end instead of a numeric so the entry can not be duplicated in future.

alex

We have seen this happen on several sites. The rectification process reverses a receipt/payment and lumps it in with another batch on the cashbook, one which may be part of an ongoing bank rec, which results in this message.

It's not something we've managed to replicate offsite yet.

There was an issue whereby if the first refund name in the list (Sales/Purchase > Utilities > Refund Names) was linked to a batched cashbook type then this would cause issues but I thought that had been fixed.

Cheers,

Alex

claire-craig

Thanks James, I was able to find the culprit and fix it :-)

claire-craig

Hi Alex, Pegasus are now onto it and I've got two customer datasets with the issue in it so hopefully they will be able to get to the bottom of it :-)

melissa

I don't know about you guys but I am getting so fed up with defects - I've never seen so many.

Regards

Melissa

fzw

This has been going on since they introduced the rectification process. I spoke to Pegasus a long time ago but because I couldn't replicate they were not interested. I have always advised customers to make sure the delete transactions is not ticked and to manually reverse them if necessary, and if a foreign currency account don't bother as you can't untick delete transactions.

I've not found any pattern as to why sometimes it works and sometimes it doesn't. My two recent customers are as follows:

1) 1st rectification went in under P9000201 (not batched) fine, 2nd rectification used P9000202 - however atype not updated so the subsequent payment used the same unique reference

2) both sales and purchase with this customer however in purchase the 1st rectification appears to have not updated atype (P900001128), so the second uses the same reference this one updates atype so the subsequent payment is OK. The sales is really fun though as the first rectification went wrong the next two rectifications also use the same number it wasn't until a receipt went in did the number update in atype (so four separate transaction with the same unique reference )

I have tried replicating over the years but not succeeded as yet.....

claire-craig

Hi, thanks so much for you update.
Talking it out loud with Pegasus this morning for each scenario this has happened with my customers over the last week, there has been a saved Bank Reconciliation and I'm thinking could it be that a transaction marked for reconciliation is then rectified? and/or it is something to do with when there is a payment and a refund being removed as part of the rectification - so trying this morning to recreate. Pegasus are also working on it, thankfully got their interest back into looking at it. The rectification process is a great tool, such a shame not to use it to its full potential.

conleth-overton

[quote userid="11032" url="~/pegasus-product-support-group/f/pegasus-product-support-group---discussion/25543/cashbook-bank-reconcilation-issue---getting-message-values-have-changed/68652"]Usually you may find the duplicate entries, amend the second duplicated number by putting a letter at the end instead of a numeric so the entry can not be duplicated in future.

Thank you James. This is a great way of ensuring no future duplication.

Copyright © 2025 Infor. All rights reserved.