AR out of balance mas90/200 3.71

Ar aging and trial balance do not always balance. This is not in error.
Aged invoice os based on the invoice date. Trial balance is based on the transaction date.

Ie invoice with the date of 9/30 posted on 10/2 to the gl will show on the aged invoice with the date of 9/30. Tb will have 10/3

Here is the knowledgebase article on it.

Resolution Details
TITLE :
The A/R Aged Invoice Report does not match A/R Trial Balance Report in Sage MAS 90 and 200

DETAILS :

The A/R Aged Invoice Report does not match A/R Trial Balance Report
Entry Type: Informational

Product: Sage MAS 90 ERP, Sage MAS 200 ERP, Sage MAS 200 ERP - SQL Server Edition

Application: Accounts Receivable

Version Reported: 3.71

Subject:
The A/R Aged Invoice Report does not match A/R Trial Balance Report.

Possible Workaround:
The two reports are not generally expected to match.  The Aged Invoice Report selects invoices to print based on the Invoice Date whereas, the Trial Balance Report prints invoices based on the Transaction Date (the date the invoices are posted to the General Ledger).

For example:
An invoice with the Invoice Date of  09/30/2009, posted to G/L on 10/02/2009, will display on the Aged Invoice Report as of 09/30/2009.   The Trial Balance Report will not display the invoice until it is printed as of 10/02/2009.

In research, there are four (4) sales order journals dated 01/18/2011 one 01/19/2011 that were closed on the correct date; however, the invoices on these journals closed with $ amounts to the general ledger; the invoices are not in the customer aging totals; they are in the invoice history on tab 3.

You need to run/print statements. This should update the aging in MAS.

While this exposed some of the errors im unsure of how to correct it.
1 of the sales orders shows 2 items in the sales order but only 1 item in the sales order history file.

the other again is a dropped item off the sales order.

in the attached jpg there is a "invoice#  0166749" that shows a payment of (-610.00) BUT no item. And again "S163409" has no item.
somehow the Items did not get pulled correctly into the history.
maslinemissing.JPG

That helps a bit.

I am a little curious as to why you have invoice 166749 with a negative payment. This looks like a duplicate of the check number of the same name. Basically, it looks like the payment was not applied correctly.

Besides this though, have you run statements and when it asks to update aging, did you click yes?

I think they were not pulled into history properly because the "Invoice" has a PMT type. Notice all o fhte other "invoices" are either prepayments or invoices.

It is correctly showing 2 payments as it is 2 separate purchases of the same product.

I take that back..... The screen shot shows 1 purchase of an item(610.00) invoice # S163409 the next line shows the PMT and Check #.. against invoice # 0166749...

the "Invoice number 0166749" is supposed to be a "INV" NOT  a PMT....
this is showing up as 2 X payments of (610.00)

snurker thank you for your help.
1 question
in AR - Statement Printing i do not get the option to "Update Aging". is this the right "Statement Printing?

Besides this though, have you run statements and when it asks to update aging, did you click yes?

Yes. In newer versions, you can have it calculate aging without running statements. Older versions it was easier. It may not prompt.

Yes. In newer versions, you can have it calculate aging without running statements. Older versions it was easier. It may not prompt.

I did not want to send you into DFDM without trying to print statements. Yes that will fix it, but you do not know if there is something that is causing the issue. Remember that changes in DFDM DO NOT update other tables nor do these changes post to the GL. If everything else panned out and this was the only error than that solution is fine.

I am honestly a little surprised that they sent you to DFDM so quickly.

For some reason certain SO's got dropped on 18,19 Jan. They made it into the history and dropped from ar6. Whats really strange is the payments were in there against the S.O. but no info on the S.O.
Im thinking data corruption of a file(ar6***.soa) not to uncommon in the flat file system of Mas.  

I have a number of MAS clients an data corruption is not common unless other programming has been done to augment how MAS functions or if you have factors outside of MAS causing the issues. You may want to check your activity logs and look for errors stating network disconnects. This could cause data corruption and I have seen it in the past.

BTW, it was good that you did contact someone. I would not recommend taking DFDM advice from a forum unless there is an exact knowledgebase article on it. Again as mentioned, you can do some serious damage.

the support was provided by blytheco. it costed a lot of $$$