Comment 2 for bug 603100

Thanks for the comments Nhomar.

*** About the technical / framework problem ***

The root of the problem is the framework not dealing gracefully with function fields being overwritten:

  - It does not allow to easily extend the method used by the function field. So the developers must overwrite the full function field definition to use their method implementation. (That's why the 'amount_tax' needs to be redefined on purchase_tax_include). It would be interesting to have a way to redefine some attributes of the field alone. Like changing the methods used on function fields, or changing the caption, without having to overwrite the full field.

  - When redefining a function field, if the store attribute is not specified, the ORM seems to 'remove' the field from the table, but still tries to store it, so it raises those nasty "column X of relation Y does not exist".

*** About the purchase_tax_include module itself ***

The truth is that is *severely* broken :(

After fixing the previous bug (the "column 'amount_tax' of relation 'purchase_order' does not exist" / "no store" problem), I could use the module a bit, and discovered that:

  - The module shows incorrect 'amount_untaxed' and 'amount_total' on the purchase order (though the lines values are the expected), cause only 'amount_tax' is overwritten.
    (* I already corrected this on my branch).

  - The "price_subtotal_incl" is not getting added to the purchase order lines of the order form view (so the user can not see the total value with taxes).

  - When the order is invoiced, the created invoice does not use the "tax_included" price type, so the values don't match the order.

So, I'm starting to think that this module never worked at all... :(

Anybody using it and willing to exchange experiences?