Decimal Places passed in on EXTDCOST does not match setup

(0) Share

Report

Posted on by Community Member

I am integrating PO Receipts using the eConnect nodes (these PO receipts are not associated with a PO and all the items are flagged as non-inventoried). I noticed that when I integrate a PO receipt with a unit cost that extends out to two decimal places the extended cost gets rounded, either up or down. If I manually enter, into the GP interface, the same PO Receipt line the extended cost does not get rounded. So I decided to add the extended cost parameter to my SQL Stored Procedure so that Extended Cost is passed in, instead of getting calculated for me. Once I made that change I started getting the error "Decimal Places passed in on EXTDCOST does not match setup". The company does not use multi-currency. I have verified that in Purchase Order Setup non-inventoried items are two decimal places for quantity and cost. I am not really sure where else to look for the setup on the number of decimal places. Once strange piece of information, when I manually added the PO Receipt line, that did not round the extended cost, I did it on the same PO Receipt that was integrated via eConnect. When I compared the two lines in SQL they were identical with the exception of the extended cost. I was expecting to see some differences between the two lines, especially when it concerned the number of decimal places. Any help would be greatly appreciated.

*This post is locked for comments

I have the same question (0)

All responses (9)

Answers (0)

Suggested answer

Redbeard 12,931 on at

Like (1)

Report

Michael,

Interestingly, there is a post online with a very similar set of circumstances. It appears as though the solution was to update the Currency ID for the Checkbook to nothing, but only when Multi-currency is not enable, which sounds like the case with your setup.

Update CM00100 set CURNCYID = '' where CHEKBKID = 'XXXXX'

Here is a link to the post:

support.panatrack.com/.../202420676-Decimal-Places-passed-in-on-UNITCOST-does-not-match-setup

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

All the CURNCYID fields on the checkbook records were already set to blank. Just for giggles I ran the update statement anyway and tried to integrate the PO receipts again. I am still getting the error. Any other thoughts?

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

How about looking at this from a different angle. What do you think is causing my extended price to round to zero decimal places when I am passing in a unit price that is at a two decimal place precision. For Example, I have a quantity of 2 at $25.26 and the extended price on the PO Receipt line is $51.00 and not $50.52.

Thank you

Was this reply helpful? Yes No
Suggested answer

Redbeard 12,931 on at

Like (0)

Report

Michael,

Please check your settings in Purchasing > Setup > Purchase Order Processing

Check the Blue Arrow to the right of currency to see what the settings are for the various currencies in your system.

Was this reply helpful? Yes No
Jothi Krishnan N 1,895 on at

Like (0)

Report

Add conditions as needed and run these queries and look for the value 1 in decplcur. ( for 2 decimals it should be 3)

select decplcur,* from POP40100

select decplcur,* from POP40600

Or try hard coding ( just to test) decplcur=3 on the eConnect POPreceiptline node and see if that works.

Was this reply helpful? Yes No
Suggested answer

Redbeard 12,931 on at

Like (0)

Report

Jothikrishnan makes a good point, for those unfamiliar with decimal places in Dynamics GP, the number in SQL tables, which represents decimal places is one off (greater) from what you would expect.

support.microsoft.com/.../930346

Was this reply helpful? Yes No
ImAPilot 70 on at

Like (0)

Report

I'm having the same issue here and found the workaround to only be partially helpful. We are not using multi-currency, but have the functional currency set, which sets the currency value on the CM00100 table. When I clear the checkbook currency, I am able to insert the transaction, however, the distribution records are created without a currency. If you attempt to post the transaction in a batch, the distribution is then cleared and the transaction does not post. When creating the receipt, I'm using autocost and not passing any cost values, but getting the error that the unitcost decimal places does not match the setup. I do have the decimal places setup correctly for both currencies and quantities.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

I am having a similar issue using Autocost set to 1. I am getting the same error on unit cost when using any amount with 2 decimal places. whole value costs work fine. Did you get a resolution on this?

Was this reply helpful? Yes No
Community member 2 on at

Like (0)

Report

I am experiencing the same issue when I perform an integration of Receiving Transactions. The system is rounding the extended cost without decimals, but when entering the transaction manually, it takes all the decimals. Have you found any solution for the integration to calculate all the decimals?

Was this reply helpful? Yes No