Notifications
Announcements
No record found.
*This post is locked for comments
Hi K Day, I had a long response typed in, clicked post...and it didn't!
Anyway the short answer is that the problem is that your decimal places currency for this item is set to 2. If they were set to 5, when you typed in the new estended cost, the unit cost would calculate and display .05678. As it is, when you overwrite the extended cost, GP back calculates a unit cost, correcly gets .5678, and then rounds it up to .06, because you have set the decimal places to 2.
The 'proper' solution is to change the decimal places to 5. Might be difficult if you have PO's already entered for this item. Check out GP >> Tools >> Utilities >> Inventory >> Change decimal places.
The other solution is to modify the PO layout, using the 'Extended Cost' field from the Purchase Order Line Work table instead of the calculated field (called cyExtCost?) which the report uses. You will also have to amend the subtotal field in the footer. You may need to play around with this especially if you are using multicurrency. Don't delete and ofthe fields on the report, just make them invisible.
Thanks Ian,
That is the probelm that I wanted to change the currency decimals but there are a bunch of these items on PO's and I don't see any time in the near future where they will have them all closed or completed so we can run that utility. I suggested to create a new item to use (these are misc items just coded against an expense account anyway).
What do you think would be the effect of changing this decimal place using SQL while there are open PO's with this item? I could see it messing up the system if we went from 5 decimals to 3 and there was a PO using 5 decimals open. But this would be going from 2 decimals to 3.
I couldn't recommend changing it through SQL, simply because I don't know what the effects would be. It would probably look OK, but you never know. Even doing it in a test company first wouldn't be fool proof...it could have effects later on with say, a reconcile or something.
FYI...To use the change decimal places functionality, The PO's would need to be transferred to history (the remove PO utility)...and for this they would need to be completed / cancelled.
Perhaps if you could postpone entering PO's into GP?...maybe manually create the next few PO's in MS Word and send them out so that you can still order product...and hold them back for later entering in GP when the decimal places are changed?
Other than that creating a new item as you suggest might be the best option.
Best regards, (If you do change it through SQL...let me know how you get on!)
Under review
Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.
As AI tools become more common, we’re introducing a Responsible AI Use…
We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…
These are the community rock stars!
Stay up to date on forum activity by subscribing.
mtabor 1
