c2c-oerpscenario team mailing list archive

[OpenERP Romania <308813@xxxxxxxxxxxxxxxxxx>]

For version 6.0.1

Search for # Diginesis fix ... # end fix

Please feedback


** Attachment added: "# Diginesis fix ... # end fix - contains the fix"
   https://bugs.launchpad.net/openobject-addons/+bug/308813/+attachment/1934137/+files/invoice.py

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

Title:
  critical bug: 'unit price' doesn't mean the same thing in sale order
  and in invoice!

Status in OpenERP Modules (addons):
  Won't Fix

Bug description:
  In sale order, in a sale_order line, the unit price is the price after
  taking into account the pricelists. For instance, If I offer 20% of
  promo for all products, with demo data, PC1 has a unit price of 360
  euros in a sale order line, this fine.

  Now, if I create an invoice from this order or from it's packing, the
  unit price an total price will be correctly propagated, fine again.

  
  BUT, if in the created invoice, I add an other line with a PC1, now the 'unit price' is 450 euros: that is the listed price. Pricelist are not taken into account, this means what the same 'unit price field means is not homogeneous from an order line to an invoice line. Also, it's hardcoded in the invoice to take the listed price. Meaning that if you base your price on an other field (like if you want a 'constant' dollar price as well for the product, then it won't use that field here while it would use it (part of the pricelist) in the sale order. See attached capture where you can compare the two lines. Also notice that the product description is not homogeneous either which is confusing too.

  I think you'll have to byte the bullet and correct that. You'd better
  do it before v5 I think because else people will be angry if you
  change something that important and central later on.

  A simple fix would be the invoice line take the pricelists into
  account too or call that field something else, but then customers will
  find it strange you present an invoice where they don't find the sale
  order terms.


  
  By the way, we think there is a more profound flaw here, we mean a business flaw in lots of situation:
  Indeed: suppose I'm offering 20% discount in the pricelist to my 'gold customers' and then may be the salesman might offer some 3% extra discount exceptionally (using the discount field in sale_order_line. With the current OpenERP, natively, you'll only print a 3% discount in the sale order (and invoice if made from the order, avoiding that bug we describe). 

  But commercially speaking, lot's of us think that: since you agree a
  20% discount, then you should be given the opportunity to make some
  benefit out of that sacrifice: meaning in term of image it's often
  good to state clearly that you are doing a 20% discount (plus may be
  3% extra) both on the sale order and invoice. But since currently you
  are not copying the product listed price on the sale_order line: it's
  just very difficult (but we did it) to compute those 20% while
  mainaining the current line amount computation system, including the
  native discount field and our ability to change the overall discount
  exceptionally (but still without writing in the product listed price
  or pricelists).

  -> Your sale line amount computation could include one more
  abstraction around the listed price that might be copied into the
  sale_order_line/invoice_line (so we might change how much it looks
  exceptionally) and one or two discounts that will take into account
  the pricelist discount. Basic usage would look the same, but you could
  easily and cleanly activate an editable discount taking the pricelist
  discount into account.

  We made a system for us based solely on computed fields (without
  altering the native datamodel) and using the native discount field but
  making it a computed field with function + inverse function (as
  introducing a second editable discount pricelist aware would have
  changed the line amount computation with unknown risky consequences)
  but it was hard to design, especially workarounds with delivery costs
  for instance where 'unit price' should keep its ability to be set
  manually while offering the explained system... I mean lot's of users
  might be interested in having a strong native system here.

  
  Hope you can fix the bug and may be think about the discount pricelist idea, making what is possible to help here for the v5 time window (so you probably can't have that full blown system unfortunately).

  Raphaël Valyi