Old A/P accounts (invoices) generated in PMO (Property Manager for DOS) won?t clear in ADAGIO ? all transactions appears with ?C? which means transaction completely settled by postdated transaction.

We note that a patch to Adagio Ledger made before version 8.00 and think that maybe, the problem relates to the data that may have been imported before the patch for PMO was put in place.

When the same report is run in ACCPAC payables (DOS) everything is cleared we don?t have this 60 page problem.

Thanks!

OK - I'm lost...

A "patch to Adagio Ledger" will not impact how Adagio Payables behaves - and it's in this module that you appear to have a problem - right?

Are you talking about clearing fully paid invoices in Adagio Payables? What report are you printing in ACCPAC Plus Accounts Payables where "everything is cleared"?

Is the data integrity check clean in Adagio Payables? Would you send me a backup of the data so that I can take a look? (Use File | Backup | Payables data and e-mail me the resulting ZIP.)

In Adagio Payables, the 'Open Payables' report will label an invoice with a 'C' for 'Completely settled by post-dated transactions' if there is one or more matching transactions applied to the invoice - with a date later than the report date - that sets the current amount of the invoice to zero.

And when you indicate that these invoices will not clear, do you mean to move these completed invoices from Current to History in Payables?

Firstly, do an inquiry to the vendor transaction and look at the applied details (ie payment, credit note, etc). Are there any and what is the transaction date? If you printed the Open Payables report with a date later than these applied detail dates, how do the invoices look on the report?

When you run period date to purge completed transactions to history, all transactions must be earlier than the purge date. If the payment date is later than the purge date, then not only will the payment not be purged, but neither will the invoices that it paid. This likely is why Adagio Payables is not clearing these invoices - if there are post-dated payments or credit notes on file, applied to these invoices.

Thank you for your reply!

-> A "patch to Adagio Ledger" will not impact how Adagio Payables behaves - and it's in this module that you appear to have a problem - right? <-

1) the module where the problem is surfacing is indeed Adagio payables. I was just trying to make some kind of guess here, so, my apologies for the red herring!

-> Are you talking about clearing fully paid invoices in Adagio Payables? What report are you printing in ACCPAC Plus Accounts Payables where "everything is cleared"? <-

2) Yes, the fully paid invoices as printed in the "Open Payables" in the Adagio payables module. Both detail and summary are incorrect. The entries that have the problem were all imported from the DOS version of property manager as they carry "PMO" somewhere inthe document number column. In regards to the report that we are comparing it against in ACCPAC, the report is the "Open Payables Report", again, either detail or summary. The point is that the transactions come up as "C" in the Adagio Reports (and everywhere else of course). The report date being given for the Adagio report is Oct 26,2006 and all the transactions are paid before that date.

-> Is the data integrity check clean in Adagio Payables? <-

3) the Accpac integrity check was error free while the Adagio one had more than 4,800 errors - probably the culprit.

-> Would you send me a backup of the data so that I can take a look? <-

4) We have a backup and will gladly send it to you. Contact me by email and I can attach it.

Again, thank you for your help and,

Cheers, JK!

Hey, I have posted my replies to each question asked and have not heard a word back after almost a week.

Could someone help us please?

Thanks, JK!

Hi ITBGEEK,

You responded to Andrew's questions, but not to ours. Here are these again:
===
And when you indicate that these invoices will not clear, do you mean to move these completed invoices from Current to History in Payables?

Firstly, do an inquiry to the vendor transaction and look at the applied details (ie payment, credit note, etc). Are there any and what is the transaction date? If you printed the Open Payables report with a date later than these applied detail dates, how do the invoices look on the report?
===

Please give an example of an invoice that is appearing with a "C" on your Open Payables report, and indicate in your reply the invoice date and the dates for all applied transactions against the invoice. If none of the applied transactions have dates later than Oct 26, 2006 then there is more to be investigated, but if you find later dates, then this is the answer.

Also, you mentioned finding 4800 integrity errors - please indicate the message (ie invalid vendor, calculated amount not correct, etc).

Hi!

Sorry, about that, I figured that my responces to Andrew's questions covered off your points. My apologies.

>> And when you indicate that these invoices will not clear, do you mean to move these completed invoices from Current to History in Payables?

Yes, this our longer term goal but at the moment we are looking at the two reports and finding divergence.

>> Firstly, do an inquiry to the vendor transaction and look at the applied details (ie payment, credit note, etc). Are there any and what is the transaction date?

yes there are details in the vendor transaction and the dates are correct and appear in the range of 1999 to 2003 etc... all well before the report date of Oct 26,2006

>>If you printed the Open Payables report with a date later than these applied detail dates, how do the invoices look on the report?

we did print the open payables report with a date later than those noted in the payment particulars (OCt 26,2006) and the items are showing up unpaid but completely reconciled by post dated transaction even those that show up in the vendor inquiry dated in 1999, 2000, 2001 etc.. etc... (ie: with a "C").

>> Please give an example of an invoice that is appearing with a "C" on your Open Payables report, and indicate in your reply the invoice date and the dates for all applied transactions against the invoice. If none of the applied transactions have dates later than Oct 26, 2006 then there is more to be investigated, but if you find later dates, then this is the answer.

Item appearing with "C" on the open payables report is:

Peter Bradly vendor number BRA01
document date: 05/15/2002
document amount: 535.00
marked as "C" right next to the current amount column

Same item in vendor inquiry report:
Peter Bradly vendor number BRA01
document date: 05/15/2002
orginal amount: 535.00
type PA:
document number: 6443
document date: 05/16/2002
reference: 6443
org amount: -535.00

Conclusion: dates are in order. Data is present in the vendor inquiry and appearing as completely settled by post dated trandsaction in the Open Payables Report.

>> Also, you mentioned finding 4800 integrity errors - please indicate the message (ie invalid vendor, calculated amount not correct, etc).

I have posted an image of the error here: http://xecinc.com/files/rf_errors.jpg

Again, thank you for your help!

Cheers, JK!

Hi JK,

Thanks for the information thus far.

Are the 'current amounts' of these invoices and payments 0.00 or the same as the original amounts? If invoices and payments are equal and non-zero, then can we assume that the payments have not been applied to the invoices? And they should have been.

To rectify that situation, you need to create 'zero-dollar' entries in a manual check batch that apply to both the invoice and pre-payment (that net to zero).

If you have Payment transactions with a current amount equal to a non-zero value, this is indicative of corrupt data.
---
As for the almost 6000 integrity errors, having to do with home equivalent balances for customers and invoices, where the data has a stored value of zero but expecting non-zero (the calculated values), this relates to whether the current amount of the invoices are zero or not.

A 'PA' payment transaction typically comes from the system check processing function and will pay existing invoices and have a current amount of zero.

I wonder if your transaction matching file is missing information. If you print the Open Payables report for just that single vendor BRA01 and make sure the 'Applied Detail' checkbox is selected, do you see the payment listed underneath the invoice? If not, then the matching file is corrupt.

At some point, you may want to make a copy of your AP data and attempt the Rebuild on the copy. This will help identify if all those integrity errors is the cause of the report scenario, which I wouldn't doubt.

Hi!

>> I wonder if your transaction matching file is missing information. If you print the Open Payables report for just that single vendor BRA01 and make sure the 'Applied Detail' checkbox is selected, do you see the payment listed underneath the invoice? If not, then the matching file is corrupt.

This is exactly the case. The payment information does not show up in this eact instance.

>> At some point, you may want to make a copy of your AP data and attempt the Rebuild on the copy. This will help identify if all those integrity errors is the cause of the report scenario, which I wouldn't doubt.

Ok, we have indeed targetted the exact location of the problem now. Can you advise as to how to perform the Rebuild on the copy...?

I'll venture a guess at making a backup first, and the opening the back up. Then from there somewhere, we run a utility called rebuild. Correct?


Thank you and,

Cheers, JK!

The Rebuild function is found on the same screen as the Data Integrity Check. If an Integrity Check is performed and errors are found, the Rebuild button becomes enabled. Choosing this will make repairs to the database. After this, you would want to re-run the Integrity Check because in some cases, data corrections will require a second round of re-calculations and another Rebuild.

I would strongly suggestion making a backup of the data (very easy to do - File/Backup/Payables Data within Adagio Payables). You can run the DIC and Rebuild on your live data or the backup copy as you wish.

Hi JK,

Just to clarify the nabove post:

The File | Backup choice makes a standard ZIP file that you would extract onto your local disk. You'd then open the local copy and run the DIC doing the rebuild (perhaps several times) until the DIC is "clean". Hopefully that will solve the problems.

PS. Sorry I "disappeared" - I'm on the road pretty continuously at the moment and have only sporadic access to the web.

Thank you, we will give this a wirl first thing in the morning tomorrow and will post up the results.

As usual,

Thank you for your efforts and,

Cheers, JK!

Hi, good day and thanks for your help!

We have:

a) created a backup,
b) ran the integrity check,
c) ran the rebuild,
d) compared the open payables report to the vendor inquiry report.

The open payables report no longer sports "C" all over the place but does not show the items as paid at all whereas the vendor inquiry clearly shows the item and it's corresponding payment.

The dates are in order and we are embarking on another data integrity check and rebuild.

Any ideas?

Thank and,

Cheers, JK!

Hi again,

We have run through the integrity check - rebuild procedure until everything came up clean.

We still have the vendor inquiry report coming up with both the invoice and the payment and the open payables report with just the invoice.

The only difference now is that the open payables report knows nothing at all about the payments!

Help!!!!

That's part of the problem with corrupted data (in this case, missing Transaction Matching records) and why we suggested doing this on a copy of the data.

The rebuild process will not re-match existing payments to invoices and create records - that could potentially mess things up really bad. Instead it found that an invoice did not have a matching payment and set the current amount back to the original amount.

My guess is that if you were to do a new manual check batch and entry for the vendor BRA01 mentioned in an earlier posting, you will see the invoice but not the PA payment. If you do see the payment in the grid then this is great! Apply to both the payment and invoice (net to zero) and post - this will set the current amount of both to zero - and will allow purging to history later on. If you don't see the previous payment then this indicates that you have records that cannot be purged (and the data is still corrupted).

So in seeing this, you might decide that the Rebuild will not put the data in a place where you can move forward from here.

From the copy of the data you have (prior to running the Data Integrity Check and Rebuilding), are the Current Amounts for both the Invoice and Payment equal zero? If so, you may be able to run Period End in order to clear these out of current transactions. If you try Period End on the data copy and this works, then great! If they are not purged, then your data is corrupted too badly for an automatic process like Rebuild to fix it, and it will need the attention of a Database Repair expert.

Hi and thank you for your reply.

>> That's part of the problem with corrupted data (in this case, missing Transaction Matching records) and why we suggested doing this on a copy of the data.

Indeed and that is why we followed the suggestion!

>> The rebuild process will not re-match existing payments to invoices and create records - that could potentially mess things up really bad. Instead it found that an invoice did not have a matching payment and set the current amount back to the original amount.

I understand.

>> My guess is that if you were to do a new manual check batch and entry for the vendor BRA01 mentioned in an earlier posting, you will see the invoice but not the PA payment. If you do see the payment in the grid then this is great! Apply to both the payment and invoice (net to zero) and post - this will set the current amount of both to zero - and will allow purging to history later on. If you don't see the previous payment then this indicates that you have records that cannot be purged (and the data is still corrupted).

Well, thank you for the suggestion but this is an enormous amount of work (more than 5000 transactions).

I am very familiar with ISAM databases and the Advantage database engine (of which I assume you are using the local server). I beleive that the data is indeed in the original data set (the one looked at by the open payables report) but that some flushing of an index key somehow caused all the date fields to be pushed to an emptry state. The repair process would probably involve setting a relation into the other table where the original payment date information could be found and updating the value.

Can you refer me?

Thanks for all your help and,

Cheers, JK

Hi John,

I wouldn't want you to have to do 5000 entries - that indeed would be enormous! I was only suggesting looking at this for a single vendor (BRA01) to indicate whether this was even possible. This helps identify the state of the data.

If you have the Adagio GridView program, you could take a look at the Payables Vendor Transaction Matching file. This is where the list of invoices and applied payments are kept. This wouldn't be a solution for fixing the data, but rather if the matching records exist at all, or if they do but are missing vital information. In GridView, filter the list the records for a single vendor (BRA01) and look for the invoice number. This would be the extent of my 'repair process' knowledge.

**Is the overall intention to purge these invoices and payments, as they are already paid? I assume that the period end function is not doing this for you.

Andrew mentioned in an earlier posting to send a copy of the AP data - indeed it is surprising that Plus shows the integrity as clean.

Hi!

Thank you for your reply!

>> I wouldn't want you to have to do 5000 entries - that indeed would be enormous! I was only suggesting looking at this for a single vendor (BRA01) to indicate whether this was even possible. This helps identify the state of the data.

Thank you, we were not looking forward to 5k entries!!! Continuing on this thread, we started a manual check batch for BRA01 and found no payment in the dialog window. This check was performed on the rebuilt / rebuilt & rebuilt data however it is my gut feeling that it may have been there in the original data set but that matters not!!!

>> Is the overall intention to purge these invoices and payments, as they are already paid? I assume that the period end function is not doing this for you.

Correct!

>> Andrew mentioned in an earlier posting to send a copy of the AP data - indeed it is surprising that Plus shows the integrity as clean.

I have not posted the data as I know not where to post it to!

Thanks for your replies, they are appreciated as this issue is becoming more and more pressing.

Cheers, JK!