Skip to main content

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :
Microsoft Dynamics GP (Archived)

PO Processing - Override Extended Price - Strange Behavior

(0) ShareShare
ReportReport
Posted on by 7,365
GP 10 SP 1 I found some strange behavior that I have not seen before.  Suppose I am making a PO for some items in high quantity/low cost.  My quote is for 20,000 units at .05678 = $1135.60 total price.  But my item only has 2 decimal places in for the currency.   So I enter the line on the PO like this:  20,000 at .06 and the extended cost calculates at 1,200.00 Then I go in and just override the "Extended Cost" field of the PO that says $1,200.00 with the price of $1,135.60.  My unit price stays at .06 cents.  My line takes at $1,135.60.  The PO Total says $1,135.60. Then when I print the PO, it comes out to screen (and paper) at $1,200 on the line and in the $1,200 for the PO Subtotal.  If I go back to the PO, it still says $1,135.60 on my PO line and Total but my PO Remaining Subtotal says $1,200.00 Is this expected behavior?  I remember specifically when I was a user of GP 8, I did this all the time and it worked.

 

*This post is locked for comments

  • Community Member Profile Picture
    Community Member Microsoft Employee on at
    Re: Re: Re: PO Processing - Override Extended Price - Strange Behavior

    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!)

    end
  • K Day Profile Picture
    K Day 7,365 on at
    Re: Re: PO Processing - Override Extended Price - Strange Behavior

    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. 

     

  • Community Member Profile Picture
    Community Member Microsoft Employee on at
    Re: PO Processing - Override Extended Price - Strange Behavior

    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.

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.

Helpful resources

Quick Links

Announcing Our 2025 Season 1 Super Users!

A new season of Super Users has arrived, and we are so grateful for the daily…

Vahid Ghafarpour – Community Spotlight

We are excited to recognize Vahid Ghafarpour as our February 2025 Community…

Tip: Become a User Group leader!

Join the ranks of valued community UG leaders

Leaderboard

#1
André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 292,494 Super User 2025 Season 1

#2
Martin Dráb Profile Picture

Martin Dráb 231,307 Most Valuable Professional

#3
nmaenpaa Profile Picture

nmaenpaa 101,156

Leaderboard

Featured topics

Product updates

Dynamics 365 release plans