Purchase module : UoS not set properly when move is created

[Blqt]

Hi,

Using latest stable 5.0 release.

When a purchase order is confirmed, the created moves do not take the product UoS into account:
404 'product_qty': order_line.product_qty,
405 'product_uos_qty': order_line.product_qty,
406 'product_uom': order_line.product_uom.id,
407 'product_uos': order_line.product_uom.id,

Benoit

[Numérigraphe (numerigraphe)]

Would you care to write a XML test file to demonstrate this problem?
Lionel

[Jay Vora (Serpent Consulting Services) (jayvora)]

Hello Benoit,

Functionally, UoS is a unit of sale, and it is used only for Outgoing moves(products).
Have a look at Products and check that it has Purchase UoM.

UOS is for the meaning for : You buy/purchase in UoM and sale them in UoS.

Thanks.

[Blqt (benoit-luquet)]

Hello Jay,

OK. The documentation expressly explain that "For example, in food industries, you will manage a stock of ham but invoice in Kg. Keep empty to use the default UOM"

... But what if I am the customer of this company selling ham. Can't I use OpenERP?
I buy ham by the KGM (I can't know the number of pieces and it is invoiced to me in KGM) and then move them to the production unit in pieces. Then the production unit manages it by KGM

... or should I describe the products I buy differently?

Thanks for your help

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hello,

yes, we also noticed you can't use OpenERP to buy ham in a different unit
(the book example), and we had a few doubts you could even sale it properly
(may be a few things have been fixed). Of course we wish it's fixed in
OpenERP. However, we feared it would take resource that would better be
allocated to things even more important such as accounting and had some fear
trying to fix that would introduce wildcat API changes or regressions.

That's why we fixed the issue by developing a brand new module for that:
https://code.launchpad.net/~akretion-team/+junk/product_second_uom
You'll also find the third party specification here:
https://blueprints.launchpad.net/openobject-addons/+spec/stock-movements-in-2-measure-units

Hopefully it helps OpenERP S.A. to fill the gap in the core ERP to be able
to use the second UOM properly has suggested by the examples, at least for
5.2.

Hope this helps

Raphaël Valyi
http://www.akretion.com

On Wed, Mar 17, 2010 at 10:51 AM, Blqt <email address hidden> wrote:

> Hello Jay,
>
> OK. The documentation expressly explain that "For example, in food
> industries, you will manage a stock of ham but invoice in Kg. Keep empty
> to use the default UOM"
>
> ... But what if I am the customer of this company selling ham. Can't I use
> OpenERP?
> I buy ham by the KGM (I can't know the number of pieces and it is invoiced
> to me in KGM) and then move them to the production unit in pieces. Then the
> production unit manages it by KGM
>
> ... or should I describe the products I buy differently?
>
> Thanks for your help
>
> --
> Purchase module : UoS not set properly when move is created
> https://bugs.launchpad.net/bugs/538502
> You received this bug notification because you are subscribed to
> OpenObject Addons.
>
> Status in OpenObject Addons Modules: Invalid
>
> Bug description:
> Hi,
>
> Using latest stable 5.0 release.
>
> When a purchase order is confirmed, the created moves do not take the
> product UoS into account:
> 404 'product_qty': order_line.product_qty,
> 405 'product_uos_qty': order_line.product_qty,
> 406 'product_uom': order_line.product_uom.id,
> 407 'product_uos': order_line.product_uom.id,
>
> Benoit
>
>
>
>
>

[Blqt (benoit-luquet)]

Hello Raphael,

I had already seen your post about that module and had a look at it (I try not to post bugs/questions before looking at everything already posted).
However, using your module would make it impractical to merge with standard OpenERP later.

Benoit