c2c-oerpscenario team mailing list archive

["Eric Caudal - www.elico-corp.com" <eric.caudal@xxxxxxxxxxxxxx>]

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