c2c-oerpscenario team mailing list archive

[Graeme Gellatly <814446@xxxxxxxxxxxxxxxxxx>]

Hi Eric,

I wrote that doc a fair while ago.  Never got any feedback and tbh my
thoughts have probably changed a little since then.

How often do you print or send supplier invoices? So maybe only sale matters
in the rare case that purchase and sale do not match, provided the totals
are still correct.

The price_unit accuracy is synonymous with product price accuracy.  In fact
once you start thinking it through, the case for anything but storing
maximum precision at the unit level on any document looks less and less
sound.  My gut feel now is values should be stored at maximum precision
here, to best allow for uom, pricelist and currency conversions to be as
accurate as possible, and just a display accuracy.  Don't know haven't
really thought it through fully.  In which case it is minor to adjust the
display digits individually on purchase and so (and accompanying invoices),
in fact we have customised so that display digits varies not just by
document but by value, so if an item on a purchase is less than 1 we display
5 digits, 1 or more we display 2, but we are lucky, all of our 5 digit
suppliers cost less than 1, and all of our 2 digit suppliers are much more
than 1.

But now I am talking precision by partner, and I suppose precision by
currency is also desirable, so it all makes hardcoding decimal precision
definitions in to fields look decidedly inflexible.

I have not looked at 6.1 at all.  However it was Odony who triaged the
original bug and who I sent paper to.


On Mon, Aug 1, 2011 at 3:17 PM, Eric Caudal - www.elico-corp.com <
eric.caudal@xxxxxxxxxxxxxx> wrote:

> Hi Graeme,
> Thanks for the doc. On my side I see 2 main issues:
> - Invoice lines is one database object receiving the result of 2
> objects: PO and SO (and maybe more) lines. SO has 'sales price' decimal
> accuracy and PO 'Purchase price' decimal accuracy which cannot be
> compatible with one accounting decimal accuracy in invoice lines.
> - invoice lines information (eg prices) have different needs from
> accounting totals. Nevertheless today we only use accounting decimal
> accuracy for all information in invoice and invoice lines.
> Here is how I see it:
> - Account decimal accuracy should be use in accounting, in invoicing
> total, SO totals and PO totals.
> - Sales price decimal accuracy should be used in SO and CI lines.
> Purchase price decimal accuracy should be used in SO and SI lines.
>
> Which brings a question and a problem:
> - question is should we use sales price accuracy for price only or for
> line total as well (I would say only prices, line total should follow
> accounting accuracy)
> - problem is there should be 2 separate fields for prices (depending on
> customer or supplier invoice) in the invoices lines to be able to
> separate 2 ways of accounting sales prices and purchase prices.
>
> Do we know how this will be handled in 6.1?
>
>
> Eric CAUDAL
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Addons.
> https://bugs.launchpad.net/bugs/814446
>
> Title:
>  Unit price in invoice should follow sales/purchase price accuracy
>
> Status in OpenERP Modules (addons):
>  Opinion
>
> Bug description:
>  unit price in invoice follow accounting decimal accuracy.
>  If I create an order (VAT included) of 7.0551 x25 = 176.38 RMB. When I
> create the invoice based on this order, I get the following: 7.06 x25 =
> 176.5 which is incorrect.
>  Unit price in customer invoice/refund should follow sales price accuracy
> and in suppliers invoice/refund should follow purchase price decimal
> accuracy.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-addons/+bug/814446/+subscriptions
>

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/814446

Title:
  Unit price in invoice should follow sales/purchase price accuracy

Status in OpenERP Modules (addons):
  Opinion

Bug description:
  unit price in invoice follow accounting decimal accuracy. 
  If I create an order (VAT included) of 7.0551 x25 = 176.38 RMB. When I create the invoice based on this order, I get the following: 7.06 x25 = 176.5 which is incorrect.
  Unit price in customer invoice/refund should follow sales price accuracy and in suppliers invoice/refund should follow purchase price decimal accuracy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-addons/+bug/814446/+subscriptions