This Cash distribution amount is incorrect and will not be posted

[KTN]

I received this error message and have tried severl methods but nothing
works. I did go to the Distrubution and delete the records and set them to
the default, but the error still showing and will not post.

There are 3 lines in the Sales Distribution Entry: Line 1 for Sales with $0
for debit and $290 for Credit; Line 2 for Shipping of $0 (debit) & $10
(credit), Line 3 for Cash with $300 (debit) & $0 (credit). These numbers do
added up.

On the Sales Transaction Entry screen, fields [Amount Received] & [Terms
Discount Taken] are shown with $0. Even if I modified the values in the
back-end, it still not post. The Subtotal + Freight do add up to the total
value. The payment via credit card is authenticated and fund received. I
could not find anthing wrong with this transaction.

If you have similar issue or any suggestions, please help. Thanks!

GP 8.0 with latest SP.

[Victoria [MVP]]

If Amount Received on the Sales Transaction Entry screen is $0, then you
CANNOT have a GL distribution with a Type of CASH. If the On Account amount
on the Sales Transaction Entry screen is not $0, you must have a total debit
for the On Account amount showing in the distributions with a type of RECV.
If you (for whatever reason) need to book a debit of $300 to the Cash GL
account with this transaction, then you can leave the GL account as Cash,
but change the Type on that line to RECV.

Hope that helps.

--
Victoria Yudin
Dynamics GP MVP
Flexible Solutions, Inc.

"KTN" <K...@discussions.microsoft.com> wrote in message
news:0094651D-B26C-488A...@microsoft.com...

[KTN]

The value of On Account field is $300 which matched with the total. I took
your advice and changed the Type for debit in Sales Distribution Entry screen
from CASH to RECV for $300. There was no error message on saving the
transaction. But it still unable to post. I still keep other 2 credit lines
in the Sales Distribution Entry screen for type Sales ($290 credit) and type
FREIGHT ($10 credit). Should I remove them?

BTW, the values of On Account is originally at $300 which is correct with
your suggestion. Is there anything else I can do to get this transaction to
post? Thank you for your help Victoria!

[Mariano Gomez]

KTN,

Click on the default button in the Distribution Entry window. This should
register each amount to the appropriate account and distribution type.

Best regards,

--
MG.-
Mariano Gomez, MIS, MCP, PMP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com

[KTN]

I tried that first time I encoutered the isssue by deleting the record and
hit the Default button in Distribution Transaction screen, but it does not
solve the problem. Thanks for your suggestion. Please let me know if there
is other ways to solve the problem.

[Mariano Gomez]

Have you check for missing accounts at the line item level? Click on each
line item, then click on the Item expansion button to bring up the Sales Item
Detail Entry window. Once there click on the Distribution button.

If any account number is missing from the line item, your transaction will
not post even if the numbers are correct in the first window.

I would also print a Batch Edit list. This usually tells you why the
transaction will not post.

[KTN]

Victoria,

What happens if the values in fields [Amount Received] & [On Account] is
zeroes? Then do the values in Sales Distribution Entry still requires to
maintained the RECV type? Thanks!

[KTN]

Mariano,

I tried your method of printing out Batch Edit list and found 1 error
message [**ERROR: The payment distributions do not equal the amount
received.] After looking ath the report, the numbers are adding up correct
and not sure what else to look. Please let me know is there any other ways
to fix this issue. Greatly appreciated.

In the report:
Subtotal = $290, Freight = $10, Document Total = $300; other fields = $0

2 items in the sales transaction:
Item A Qty = 1, Markdown = 0, Unit Price = $180, Extended Price = $180
Item B Qty = 1, Markdown = 0, Unit Price = $110, Extended Price = $110
Total $290

Distribution: (3 lines)
Account Type = Sales, Debit Amt = $0, Credit Amt=$290
Account Type = Freight, Debit Amt = $0, Credit Amt=$10
Account Type = RECV, Debit Amt = $300, Credit Amt = $0
Total Debit Amt = $300, Total Credit Amt=$300

Cash Receipt/ Payment = Credit Card Payment for Amt=$300
Subtotal=$290, Freight=$10, Document Total =$300; other=$0

[Mariano Gomez]

KTN,

As you can see, I haven't given up on you, but this is my last resort and
ditch effort to help you solve this problem. Sometimes on the surface
(reports and screens) things appear to be ok, since these screens and reports
are limited by the number of decimals configured on the currency, but this is
only a formatting issue!

The following script will essentially compare at the SQL Level if there is
any variances between your physical values up to the 5 decimal places stored
in the table. If there is, that's your answer, since the SQL and Dex scripts
do compare the physical values and not the formatted ones on reports and
screens.

select a.sopnumbe, sum(a.amntpaid) as SOP10103_PYMT, sum(b.debitamt) as
SOP10102_DIST, sum(a.amntpaid) - sum(b.debitamt) as PYMT_DIST_Variance
from sop10103 a inner join sop10102 b on a.sopnumbe = b.sopnumbe and
a.soptype = b.soptype
where a.sopnumbe = 'TheProblemSOPNumber' and a.soptype = 3 and b.disttype = 21
group by a.sopnumbe

If this does not work, then I am out of the game and will concede to someone
else.

[KTN]

Mariano,

I thank you for you help on this issue. It is a dificult and strange issue.
When I ran your script, it came out empty. I noticed that the values for
field DISSTYPE only has 1, 7, and 3 which DISTTYPE = 1 & 7 has credit amount
and DISTTYPE = 3 has debit amount. There is not value 21. Could that be
that there is no record 21 and cause this issue? If that is the case, would
manaully insert the data into the table work?

Again, thank you very much for your help!

[Mariano Gomez]

Sorry, my bad! Change as follows:

select a.sopnumbe, sum(a.amntpaid) as SOP10103_PYMT, sum(b.debitamt) as
SOP10102_DIST, sum(a.amntpaid) - sum(b.debitamt) as PYMT_DIST_Variance
from sop10103 a inner join sop10102 b on a.sopnumbe = b.sopnumbe and
a.soptype = b.soptype
where a.sopnumbe = 'TheProblemSOPNumber' and a.soptype = 3 and b.disttype =

3 group by a.sopnumbe

Distribution type = 3 is a payment... please let me know how this works.

[KTN]

Mariano,

I ran your updated script and it returned 1 row and the info is correct.
This is not a good news for us. Again. thank you for your help.

sopnumbe SOP10103_PYMT SOP10102_PYMT
PYMT_DIST_Variance
INV10003 300.00000 300.00000 .00000

[Mariano Gomez]

KTN,

Can you provide me with remote access to check this issue? Please contact me
directly with the information below. At this point it sounds that it is
pretty much easier to void and re-enter this document.

[KTN]

Mariano,

Thank you for the offering to look at this issue via remote access, but
unfortunately it is not possible due to company policy. I am sorry that
could not be done and it is hard to turn away the offer like this.

If there is any other areas that you think I could check, that would be very
much appreciated. Again. thank you for your help and persistent in helping
me to solve the problem. It is still bad the issue remain unsolve. The
issue with voiding this transaction is the credit card transaction already
approved. With voiding the transaction, this might cause other issues with
voiding the CC transaction.

Again, thank you very much for your help.

[Mariano Gomez]

Just following up! Did you ever get this resolved?

[KTN]

I still have the same issue and trying different methods to solve the problem.

[Mariano Gomez]

Have you ran a DEXSQL.LOG? Open your DEX.INI file and change the following
entries to TRUE:

SQLLogSQLStmt=TRUE
SQLLogODBCMessages=TRUE
SQLLogAllODBCMessages=TRUE

BEFORE you get ready to post the invoice, open the file in NOTEPAD and clear
it completely, then Save and exit. Execute the posting, and copy/paste the
content of the file to thi thread.

[KTN]

The problem is fixed by going to backend and correct the info on SOP table.
Thanks again for your help!

[Michael]

I'm trying to resolve the same issue in a system I inherited. What tables
and fields did you update on the backend to correct the issue?

[Frankie D]

What tables/fields did you update from the backend to correct the issue? Tried:

update [USDM].[dbo].[SOP10100] set [ACCTAMNT] = 0, [ORACTAMT]=0 where
[SOPNUMBE] = 'n' and soptype = 3

but when we reinsert payment from the "Sales Payment Entry" window, "Amount
Received" is still 0 and "On Account" updates with the amount we overrode in
the backend. We've also reset the sales distribution for the invoice and
repeated the update statement, but... no luck

[Frankie D]

Solved it by running a reconcile on the affected document by going to
Microsoft
Dynamics GP > Tools > Utilities > Sales > Reconcile - Remove Sales Documents.

Selected the document and the output was:

INV000NNNNN Invoice
Payment Received was adjusted from $0.00 to $41.15.
Originating Account Amount was adjusted from $41.15 to $0.00.