Receivings Transactions Entry Rounding issue
I am importing a large list of items (Shipment/Invoice) to Receivings Transactions Entry from SmartConnect into GP 2010.
Getting these errors on the Receivings Edit List for the batches. Some, not all.
**The PURCH distribution(s) don't equal the actual amount (And/Or)
**The Contra distribution(s) don't equal the actual amount
The whole import list uses 2 decimal place values and I don't see a problem here, but once imported some values of ORCRDAMT & ORDBTAMT in the distributions are off by some small fraction like .8425, .36500, .20750, etc. (in POP10390). I have been assuming that is causing the errors above.
Anyone know of GP settings that might cause the ORCRDAMT & ORDBTAMT values to be off? CRDTAMNT & DEBITAMT values appear fine and rounded to two decimal places.
——————————————-
David Morinello
Information Systems Developer
ProEnergy Services
Sedalia MO
Getting these errors on the Receivings Edit List for the batches. Some, not all.
**The PURCH distribution(s) don't equal the actual amount (And/Or)
**The Contra distribution(s) don't equal the actual amount
The whole import list uses 2 decimal place values and I don't see a problem here, but once imported some values of ORCRDAMT & ORDBTAMT in the distributions are off by some small fraction like .8425, .36500, .20750, etc. (in POP10390). I have been assuming that is causing the errors above.
Anyone know of GP settings that might cause the ORCRDAMT & ORDBTAMT values to be off? CRDTAMNT & DEBITAMT values appear fine and rounded to two decimal places.
——————————————-
David Morinello
Information Systems Developer
ProEnergy Services
Sedalia MO
Answers
Best Answer
Just as an update to this discussion, I opened a case with Microsoft and it's apparently a known bug. They have sent me a new version of the Stored procedure taPopCreateDistributions, which I will be testing this week.
I was wondering how the new stored procedure worked for you. I’m having the same issue using SC/eConnect and GP 2010
We are having a similar issue in GP 2015. Were you able to resolve the issue you reported here, and if so, how please?
I am still seeing this rounding issue. It seems to be specific to some Projects and their assigned GL distribution accounts. I tried explicitly setting the currency at the line and header levels, and threw in rounding for every imported amount. And I am still getting the "…distribution(s) don't equal the actual amount" errors
SmartConnect Map Group:Purchase Order Processing -> Node Type: Receiving > Add Line item -> Unit Cost field >- this calculation
if _PAORIGAPPRBILLRATE = 0 then
return Math.Round(_PAORIGAPPRBILLAMT / _PAQTYQ, 2, MidpointRounding.AwayFromZero)
else
return Math.Round(_PAORIGAPPRBILLRATE, 2, MidpointRounding.AwayFromZero)
end if
Still seeing rounding issues in the POP10390 table in the imported data. I assume these are causing the
"…distribution(s) don't equal the actual amount" errors
POPRCTNM
CRDTAMNT
ORCRDAMT
DEBITAMT
ORDBTAMT
Distribution_Type
VENDORID
PSTNGTYP
RCT159064
$ –
$ –
$ 29,577.08000
$ 29,577.08000
Unbilled Account
PROCRAFTS001
0
RCT159064
$ –
$ –
$ 5,923.72000
$ 5,923.71500
Cost of Goods Sold
PROCRAFTS001
1
RCT159064
$ –
$ –
$ 5,225.86000
$ 5,225.85500
Cost of Goods Sold
PROCRAFTS001
1
RCT159064
$ –
$ –
$ 16,065.00000
$ 16,065.00000
Cost of Goods Sold
PROCRAFTS001
1
RCT159064
$ –
$ –
$ 393.75000
$ 393.75000
Cost of Goods Sold
PROCRAFTS001
1
RCT159064
$ –
$ –
$ 1,968.75000
$ 1,968.75000
Cost of Goods Sold
PROCRAFTS001
1
RCT159064
$ 29,577.08000
$ 29,577.07000
$ –
$ –
Contra Account
PROCRAFTS001
0
RCT159064
$ 5,923.72000
$ 5,923.72000
$ –
$ –
Unbilled Project Re
PROCRAFTS001
1
RCT159064
$ 5,225.86000
$ 5,225.86000
$ –
$ –
Unbilled Project Re
PROCRAFTS001
1
RCT159064
$ 16,065.00000
$ 16,065.00000
$ –
$ –
Unbilled Project Re
PROCRAFTS001
1
RCT159064
$ 393.75000
$ 393.75000
$ –
$ –
Unbilled Project Re
PROCRAFTS001
1
RCT159064
$ 1,968.75000
$ 1,968.75000
$ –
$ –
Unbilled Project Re
PROCRAFTS001
Dave,
If you change the destination to Microsoft Dynamics GP-File, do the distribution amounts come out correct there?
If they do then there is something in the Dynamics GP eConnect logic that is not setting those Originating amounts correctly. It may require Microsoft's involvement at that point.
Lorren
Yes, they appear to be coming out correct in the XML. The calculation issue appears to be within PRO(company) after the transfer.
I have opened a case with Microsoft and we are troubleshooting now. It appears to happen only with certain Project/Cost Category combinations. It's like somewhere at the Project level there is a decimal place setting that allows it to calcuate qty times unit cost out to 3 decimal places.