Purchase Order price calculation wrong

Bug #728092 reported by Kyle Waid
54
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Fix Released
Low
OpenERP R&D Addons Team 2
6.0
Fix Released
Low
OpenERP Publisher's Warranty Team

Bug Description

Something happened to the trunk around the 28th of February. In the commit, the Purchase order function now has wrong calculation.

When doing a purchase order it has wrong cost calculation. If the default UoM is different the the Purchase UoM then it double multiplies the price. cost x Purchase UoM x2 = price

Related branches

Revision history for this message
Kyle Waid (midwest) wrote :

I think, just guessing here it was revision 4462 because the purchase files were modified.

Revision history for this message
Kyle Waid (midwest) wrote :

Revision 4457 does not cause the error so something between now and then

Revision history for this message
Raphaël Valyi - http://www.akretion.com (rvalyi) wrote : Re: [Bug 728092] Re: Purchase Order price calculation wrong

Kyle
May be you better stick with 6.0 branches for production. That being said it
s cool to report thoses regressions
On Mar 2, 2011 7:41 PM, "Kyle Waid - http://www.midwestsupplies.com" <
<email address hidden>> wrote:
> Revision 4457 does not cause the error so something between now and then
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Addons.
> https://bugs.launchpad.net/bugs/728092
>
> Title:
> Purchase Order price calculation wrong
>
> Status in OpenERP Modules (addons):
> New
>
> Bug description:
> Something happened to the trunk around the 28th of February. In the
> commit, the Purchase order function now has wrong calculation.
>
> When doing a purchase order it has wrong cost calculation. If the
> default UoM is different the the Purchase UoM then it double
> multiplies the price. cost x Purchase UoM x2 = price

Revision history for this message
Kyle Waid (midwest) wrote :

Ive been on trunk the whole time, if I went back then I couldnt report bugs. Ill revert if I have to.

Revision history for this message
Raphaël Valyi - http://www.akretion.com (rvalyi) wrote :

Kyle, I advised to use trunk while approaching v6.0. But now that 6.0 has
been frozen, trunk has become unstable again (we don't know yet if OpenERP
SA is committed in making it converge to something stable again and for
when) and on the tracker you can see nasty regressions happening on it. This
is very cool to be a trunk early tester/adopter, but I just wanted to make
sure you know the risk of using that branch in production.

On Thu, Mar 3, 2011 at 2:52 AM, Kyle Waid - http://www.midwestsupplies.com <
<email address hidden>> wrote:

> Ive been on trunk the whole time, if I went back then I couldnt report
> bugs. Ill revert if I have to.
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Addons.
> https://bugs.launchpad.net/bugs/728092
>
> Title:
> Purchase Order price calculation wrong
>
> Status in OpenERP Modules (addons):
> New
>
> Bug description:
> Something happened to the trunk around the 28th of February. In the
> commit, the Purchase order function now has wrong calculation.
>
> When doing a purchase order it has wrong cost calculation. If the
> default UoM is different the the Purchase UoM then it double
> multiplies the price. cost x Purchase UoM x2 = price
>

Revision history for this message
Bogdan Stanciu (bstanciu) wrote :

On 03. 03. 11 12:40, Raphaël Valyi - http://www.akretion.com wrote:
> Kyle, I advised to use trunk while approaching v6.0. But now that 6.0 has
> been frozen, trunk has become unstable again (we don't know yet if OpenERP
> SA is committed in making it converge to something stable again and for
> when) and on the tracker you can see nasty regressions happening on it. This
> is very cool to be a trunk early tester/adopter, but I just wanted to make
> sure you know the risk of using that branch in production.
>
> On Thu, Mar 3, 2011 at 2:52 AM, Kyle Waid - http://www.midwestsupplies.com <
> <email address hidden>> wrote:
>
>> Ive been on trunk the whole time, if I went back then I couldnt report
>> bugs. Ill revert if I have to.
>>
>> --
>> You received this bug notification because you are subscribed to OpenERP
>> Addons.
>> https://bugs.launchpad.net/bugs/728092
>>
>> Title:
>> Purchase Order price calculation wrong
>>
>> Status in OpenERP Modules (addons):
>> New
>>
>> Bug description:
>> Something happened to the trunk around the 28th of February. In the
>> commit, the Purchase order function now has wrong calculation.
>>
>> When doing a purchase order it has wrong cost calculation. If the
>> default UoM is different the the Purchase UoM then it double
>> multiplies the price. cost x Purchase UoM x2 = price
>>
I feel it is very counterproductive to have an unstable trunk. Right now
I am not at all motivated to upgrade/test, as maybe tomorrow things get
reversed.

There are sufficient levels of testing/approval so the "official" trunk
could stay clean. of course, not "perfect" (what does that mean anyway
:-)) but as good as it could come.

what i saw lately is FAR from this.

just my opinion...
bogdan

Revision history for this message
Raphaël Valyi - http://www.akretion.com (rvalyi) wrote :

I should say, I was just warning Kyle against this fact. Of course I regret
this situation too. I know other projects where trunk is reasonably stable
enough so that motivated early adopter are rewarded of their testing efforts
rather than screwed with their installation. Cheers.

On Thu, Mar 3, 2011 at 8:59 AM, Bogdan Stanciu <
<email address hidden>> wrote:

> On 03. 03. 11 12:40, Raphaël Valyi - http://www.akretion.com wrote:
> > Kyle, I advised to use trunk while approaching v6.0. But now that 6.0 has
> > been frozen, trunk has become unstable again (we don't know yet if
> OpenERP
> > SA is committed in making it converge to something stable again and for
> > when) and on the tracker you can see nasty regressions happening on it.
> This
> > is very cool to be a trunk early tester/adopter, but I just wanted to
> make
> > sure you know the risk of using that branch in production.
> >
> > On Thu, Mar 3, 2011 at 2:52 AM, Kyle Waid -
> http://www.midwestsupplies.com <
> > <email address hidden>> wrote:
> >
> >> Ive been on trunk the whole time, if I went back then I couldnt report
> >> bugs. Ill revert if I have to.
> >>
> >> --
> >> You received this bug notification because you are subscribed to OpenERP
> >> Addons.
> >> https://bugs.launchpad.net/bugs/728092
> >>
> >> Title:
> >> Purchase Order price calculation wrong
> >>
> >> Status in OpenERP Modules (addons):
> >> New
> >>
> >> Bug description:
> >> Something happened to the trunk around the 28th of February. In the
> >> commit, the Purchase order function now has wrong calculation.
> >>
> >> When doing a purchase order it has wrong cost calculation. If the
> >> default UoM is different the the Purchase UoM then it double
> >> multiplies the price. cost x Purchase UoM x2 = price
> >>
> I feel it is very counterproductive to have an unstable trunk. Right now
> I am not at all motivated to upgrade/test, as maybe tomorrow things get
> reversed.
>
> There are sufficient levels of testing/approval so the "official" trunk
> could stay clean. of course, not "perfect" (what does that mean anyway
> :-)) but as good as it could come.
>
> what i saw lately is FAR from this.
>
> just my opinion...
> bogdan
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Addons.
> https://bugs.launchpad.net/bugs/728092
>
> Title:
> Purchase Order price calculation wrong
>
> Status in OpenERP Modules (addons):
> New
>
> Bug description:
> Something happened to the trunk around the 28th of February. In the
> commit, the Purchase order function now has wrong calculation.
>
> When doing a purchase order it has wrong cost calculation. If the
> default UoM is different the the Purchase UoM then it double
> multiplies the price. cost x Purchase UoM x2 = price
>

Revision history for this message
Kyle Waid (midwest) wrote :

Good discussion, not sure whats going on with trunk either, This was particularly a funny bug to me when people reported it to me. So if I revert my addons folder to the stable one it wont cause problems? I know it does not upgrade well. I think ill just stay where im at and report bugs as they surface. Thank you very much for your concern, I understand the risks. Our database is backed up every hour.

Currently the server trunk is busted, and now addons folder getting funny. I will continue to report bugs and try to provide as much detail as possible so you guys "experts" can fix them. So at least I have a minor, but contribution back.

Amit Parik (amit-parik)
Changed in openobject-addons:
assignee: nobody → OpenERP R&D Addons Team 2 (openerp-dev-addons2)
importance: Undecided → Low
status: New → Confirmed
Changed in openobject-addons:
status: Confirmed → In Progress
Revision history for this message
Rohan Nayani(Open ERP) (ron-tinyerp) wrote :

Hello,

Thanks for Reporting.
It has been fixed in lp:~openerp-dev/openobject-addons/trunk-bug-728092-ron
Revision ID: <email address hidden>
Revision num:4478.

It will be available in trunk soon,

Changed in openobject-addons:
status: In Progress → Fix Committed
Changed in openobject-addons:
status: Fix Committed → Fix Released
Revision history for this message
Kyle Waid (midwest) wrote :

Hi, I noticed that this bug also exists in the 6.0 stable branch. I changed the status back to new. Please confirm

Changed in openobject-addons:
status: Fix Released → New
Changed in openobject-addons:
status: New → Fix Released
Revision history for this message
Coco (coco-3-5) wrote :

Hi, I noticed that a similar bug affect journal entries in accounting when doing real-team inventory valuation.

Revision history for this message
snook (snook) wrote :

Hi, Kyle

Looks like this is related to bug: https://bugs.launchpad.net/openobject-addons/6.0/+bug/716289

And agree, [6.0.1 stable] has the bug.

Finding it impossible to progress with this bug.

Quantity and UOM should be tightly bound in OpenERP (or any where).

Revision history for this message
snook (snook) wrote :

Just another thought.

How does it work....

If bugs are reported on say 6.0.1 should they not have the fix applied there ?

Okay to apply to other branches but priority should go to the reported branch.

Revision history for this message
Jon Wilson (Willow IT) (openerp-willowit) wrote :

This bug still exists in the latest trunk revision as at 2011-04-19 - what's happening?

Revision history for this message
Kyle Waid (midwest) wrote :

I believe this issue is fixed, however it could have had a regression. There is a proposed patch here, just take the code and apply it to your server. I have not this issue, but I stopped updating to trunk, or even 6.0 because issues like this happen frequently

Revision history for this message
Jay Vora (Serpent Consulting Services) (jayvora) wrote :

Hello Kyle,

Thanks for reporting.

This has been fixed in stable 6.0.2 by revision <email address hidden>.

Kindly let me know if you faced regression with any case.

Thanks.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.