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!