c2c-oerpscenario team mailing list archive

[Graeme Gellatly <814446@xxxxxxxxxxxxxxxxxx>]

Eric,

We currently run 2 systems that behave precisely as I wrote.  5 digits on
unit and line total, and 2 digits on general total.  But they always display
2.  And these are the 2 most popular accounting systems in Australia and NZ
and very popular worldwide so I think it is OK.  Your argument against
supplier doesn't hold anyway.  Because it is their system that determines
the invoice total, not yours.  And each system is different.  So therefore
to accommodate that you would need precision by partner - which you don't
want or max/greater precision on unit.  Also you must allow for pricelist,
uom, currency conversions as well as discount.  You simply cannot do any of
that with the same precision as you display and not expect large rounding
errors.

Regards what you send your partners is what is in your database - we are
only talking about unit precision here, not accounting totals.  The
precision we use to calculate the totals, NOT the total itself.  Personally
I see no issue, further borne out by the above that it hasn't been a problem
for us or the literally millions of other users of the other systems we use.
 So all we did was make OpenERP match that.

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

> Hi Graeme,
>
> On 01/08/2011 12:56, Graeme Gellatly wrote:
> > 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.
> Even if I do not send supplier invoices, they generate stats and
> accounting so they should be accurate. How can the accountant check
> incoming invoices if every supplier's invoice is incorrect?
> You do not want to be correcting every invoice you make before you
> validate, not even mentioning that accounting people most of the time do
> not have the information.
> > 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.
> What you send to your partners should be the same as in your database.
> If not you will deal with write-off, reconciliation and delays in
> getting payed. This is the reason why I am not so sure about having a
> display and internal accuracy: to be analyzed though.
> > 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.
> Precision at partner level seems complex and unpractical to maintain.
> > I have not looked at 6.1 at all.  However it was Odony who triaged the
> > original bug and who I sent paper to.
> I hope we can get some feedback soon from experts' list!
> >
> > 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 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