Problem with Aged Accounts Receivable report

Mindie

One of our clients is having a problem with the Aged Accounts Receivable that I can't figure out.

After they closed 2009 they printed all of their reports. The Aged Accounts Receivable report tied into the A/R accounts perfectly. Now when they print the Aged Accounts Receivable as of the year end date it has a different number. I have verified that no new transactions have posted to the G/L before the year end date.

They are on ver 5 sp1. Is the report wrong or is there something other way for this to happen that I haven't thought of yet?

They are saying that the same has happened for A/P and Inventory but I haven't looked at those yet.

gjvk70

Is it possible entries have been applied in the subledger with an incorrect date? (Applied at a date before the most recent document date of the selected documents).

rsaritzky

The Aged A/R report's logic is a bit complex - it evaluates each A/R (Customer Ledger) transaction. As each invoice is evaluated, it looks at the posting and application dates of the payments and credits to that invoice and determines the balance as of the aging date.

One thing to try is to run the report as of a week before the end of the year and see if it balances then. I've had customers where year-end adjustments are the culprits. Then you can narrow down the transactions you need to look at.

Ron

Mindie

"Is it possible entries have been applied in the subledger with an incorrect date? (Applied at a date before the most recent document date of the selected documents)."

NAV won't allow an application to be posted that is before either of the document dates.


"One thing to try is to run the report as of a week before the end of the year and see if it balances then. I've had customers where year-end adjustments are the culprits. Then you can narrow down the transactions you need to look at."

No, that didn't work. It still wasn't the correct amount.


Any other ideas?

Savatage

Mindie wrote:

I have verified that no new transactions have posted to the G/L before the year end date.

How did you do that?
Did you match up trial balances based on the date in question for each g/l account and saw no differences?

Did you double check that they running the report today exactly the same way (meaning filters & options) as they did on the last day of the year?

rsaritzky

Mindie wrote:

"One thing to try is to run the report as of a week before the end of the year and see if it balances then. I've had customers where year-end adjustments are the culprits. Then you can narrow down the transactions you need to look at."

No, that didn't work. It still wasn't the correct amount.

Then the next thing to do is to run the for an earlier date, say, the previous month (November), and see if it it balances then. Keep going back until you find when the problem started. I once had a customer who did not have any locks on posting dates set and in 2009, posted an entry to 2003 by mistake. It threw off the aging/reconcilation all the way back.

I think you said you did this already, but find the entry number of your GL closing transactions and check any G/L Entry records after that entry No. for dates prior to the close date.

Ron

Savatage

rsaritzky wrote:

find the entry number of your GL closing transactions and check any G/L Entry records after that entry No. for dates prior to the close date.
Ron

Nice! :thumbsup:

themave

This has been a know problem with the AR report since we first started using Navision in 1999 with version 2.0, it was still there when we upgraded to 4.0. I assumed it would be fixed at some point, but appearantly not.

Here is what I did earlier to help us

to fix our version of the report, 4.0 no service pack

on the Data Item Cust.Ledger entry
open the properties and select

DataItemTableView and remove the table filter

Open=Const(Yes)

the problem with running the report with any date other then today, is it filters out items that are closed after that date with a application entry.

If you remove the filter listed above, the report will look at all the entries and then correctly identify which ones were open at the date you listed and the report will be accurate.

I am not a developer, but this is the best I could figure out, without actually going through it all. this does fix the report for 4.0.

It runs slowers, but it is correct

Mindie

"I think you said you did this already, but find the entry number of your GL closing transactions and check any G/L Entry records after that entry No. for dates prior to the close date."

Yes. I ran the GL Entry table, filtered by posting date, and sorted by Entry No. The closing entries where the last thing to post to the G/L up to that date. I did something similar in the customer ledger entries. I then compared the date on the register date of the last entry no of the cust. ledger to the register date of the closing entries in G/L. There was no entries posted to the cust. ledger after that time either.

Mindie

themave wrote:

This has been a know problem with the AR report since we first started using Navision in 1999 with version 2.0, it was still there when we upgraded to 4.0. I assumed it would be fixed at some point, but appearantly not.

Here is what I did earlier to help us

to fix our version of the report, 4.0 no service pack

on the Data Item Cust.Ledger entry
open the properties and select

DataItemTableView and remove the table filter

Open=Const(Yes)

the problem with running the report with any date other then today, is it filters out items that are closed after that date with a application entry.

If you remove the filter listed above, the report will look at all the entries and then correctly identify which ones were open at the date you listed and the report will be accurate.

I am not a developer, but this is the best I could figure out, without actually going through it all. this does fix the report for 4.0.

It runs slowers, but it is correct

I read that problem was corrected in ver 4 sp2. I will still check it out though.

themave

Mindie wrote:

I read that problem was corrected in ver 4 sp2. I will still check it out though.

Microsoft has been know to re-intruduce bugs, I have no idea if that is the case, all I know, is I complained about the problem in the beginning of 2000, and 9 years later it still wasn't fixed. I heard of the mythical fix in 4.0 sp2, but I also have read a lot of forum post since then, all describing the same problem. so, maybe they fixed the one bug, but introduced a new different bug that causes the same problem.