Core Financial Modules

[SAGEMAS90CONSULT]

MAS 200 V.4.2.0.15

Occasionally a customer invoice created in Sales Order Invoice Date Entry will post in duplicate or triplicate to both A/R and G/L. If it has posted in duplicate, when you look up the invoice on the Customer Maintenance Invoices tab, the same invoice number is listed twice. In the “Trans Type” column, the first invoice is listed as “Invoice” but the duplicate is listed as “Adjustment,” and the “Trans Amount” is the same for both invoices. By standard procedure, if a SO Invoice needs to be adjusted, it is done by entering a Credit Memo or Debit Memo in SO Invoice Data Entry. So there is never any “Adjustment” done to the invoices, so the system is assigning this “Adjustment” title to the duplicate invoice.

The invoices post to G/L in double or triple the amount of the invoice posted. An A/R Invoice History Report shows the invoice listed twice or three times and the line items are listed two or three times, as well as the increased posting to Inventory, Accts Rec, Sales, COGS, etc. - all doubled or tripled. At least the postings are consistent in GL and other modules/accounts.

I searched the Sage KB and found nothing there. The Sales Orders and following Sale Order Invoices have been entered manually and not from a VI import or other Auto generation task such as SO from PO, nor is there an extended solution used.

A review of the DSOSJ when the SO Invoices are posted does not show anything unusual. Sometimes the duplicate invoices are not discovered until the customer’s payment is applied in Cash Receipts, and the AR Clerk finds the duplicate invoices and the Customer Balance is incorrect. It is corrected with a credit memo.

A shout out to anyone who may know what may be the suspect. Thanks in advance.

[DFeller]

I have a customer that struggled with that and they had to upgrade to 4.30.0.17 to resolve.

Dawn

[SAGEMAS90CONSULT]

Thank you for the post, Dawn. I figured as much but it was good to have my fears confirmed: :-) The client has some custom programming so they will have to remain on 4.2 for awhile.

[TomTarget]

Actually once a sales invoice is posted, by design you can go in and re-enter the same invoice number a second time and "adjust" the invoice without doing a credit or debit memo.

You get a warning that the invoice already exists and it then asks you if wish to adjust.

I have one client that does a huge number of invoices each year and the invoice numbers wrap around and occasionally the combination of invoice number and customer number  (which is what makes an invoice unique)  matches up and you get this effect.   All of their invoices are imported using VI, so they don't get a warning about the "adjustment:.   They see exactly what you are describing when it happens.

Your client doesn't by chance import with VI and occassionally get a duplication from their external data source?

[mattk]

I was wondering if you ever found a solution to this.  I am experiencing the same problem.  It occurs very very rarely (only 3 times I know of so far), but it happens exactly as you describe.  The adjustment date is the same date as the invoice, we do no import any invoices, and we are on 4.3.18.  If anyone knows has any further information on this issue, please advise.

Thanks,

Matthew Kaney

Biopac Systems, Inc.

[SAGEMAS90CONSULT]

Thomas: I did mention in the original post that they don't use VI. Your post did prompt me to check into other reasons they may be reusing an invoice number and I didn't find any. The history shows a smooth progression of the use of invoice numbers with no duplicates.

Matthew: No I have never resolved this. The customer is getting a quote for the custom programming and considering upgrading in hopes of resolving this together with the other benefits of upgrading. It will be a wait-and-see situation and I'll post again if I have any more info that may be helpful. 

Sorry for the delay in replying and thank you all for the posts.

[SPyle]

Interesting, I just discovered three transactions that have been posted in duplicate.  All three were credit card, but they were all different payment types (one each, MC, Disc, Amex), so it's not the payment type.

The Sales Journal looks correct, the gross profit journal is correct, but the GL is doubled up.  I guess I'm finding these since I'm reconciling the credit card suspense accounts.  I suspect there may be more in the AR, but I don't know that I want to go looking for them.  Since I adjust inventory out-of-balance back to a COGS offset, the total profit for the company won't be affected.

These are happening on 4.5, update 1.  One was at the end of October, then two in November.  On the Journal entry, the duplicate is listed twice to the suspense account, but all the other values are rolled up into the individual lines:  e.g., One sales entry, one cogs entry, ...

This could be a big problem if I allowed MAS to book commissions, but fortunately I do that manually.

P.S.  I'm on MAS90, 4.5.

I'd report this by I don't have any cases and there isn't a way to report without giving them my credit card and hoping for a refund later.

[jnelsonut]

I reported this in mid December (see my post in the distribution and manufacturing section).

Sage said there were a few customers with the same problem, and a fix should come out on the next PU.  It probably wouldn't make the one that came out in December, but it sould be on the next one.

The amount on the Daily Sales Order Sales Journal is doubling some invoices on the Daily Sales Recap By Product Line, and on the Daily Transaction Register.

What I found is, if you don't update after printing the Sales Journals - Go out - Then reprint the Sales Journals the totals now match.

Joe

[TomTarget]

I've got a client this morning reporting the exact same thing.

Will have them try the reprint suggestion for now and anxiously await product update #3.

[SPyle]

Joe,

I was just reviewing this with my accounting clerk, and realized you don't know if it doubles up until you run the daily transaction register.  So, are you running the entire sales order day-end twice, or just the daily transaction register twice?

If it is the former, there isn't a way to know if there is a problem until it is too late, so we'll just have to routinely run it twice from now on.