Community mailing list archives

Re: Sale and purchase workflow

Open For Small Business Ltd, Graeme Gellatly
- 09/19/2015 02:57:44
Hi Fabien,

You miss my point re taxes.

On invoices it takes it from the account, itself a property field of product.template
On sale orders it takes it from taxes_id - not a property.

The inconsistency is hugely annoying (well requires a custom module at least).  Consider the most common use case, VAT.  With very few exceptions this is generally charged.  Now a user creates a product and doesn't have access to one company.  The company is losing money or breaking the law or both.

If you look at partners, products or any static data model that is generally shared, the multicompany fields are property fields which means defaults work.  These taxes are the only exception meaning that essentially the act of creating a product can only be performed by an administrator EVEN IF defaults have been set.

If you either a: make this field a property field or b: make sale orders behave the same way as invoices then personally I think you create a huge usability improvement for very little effort.

Also re GTK, I'm sure it wasn't 6.1.  Maybe it was but it worked fine for years.

On Sat, Sep 19, 2015 at 1:18 AM, Alexandre Fayolle <> wrote:
On 16/09/2015 13:17, Fabien Pinckaers wrote:
> There are several approaches to hook in the code. Use the one that fits
> your use case:
> - extend on the action, not the event (easy if you want to change the
> behaviour of an action, just a method to overwrite)
> - extend on the recompute of the computed field (easy if you want to
> trigger something new on a change: e.g. if the invoice_status changed,
> just a method to overwrite)
> - extend on write/create (not super clean, but basically the same than
> what the workflow was doing)
> - extend the trigger of the change of the computed field (extend @depends)

Hello Fabien,

We can certainly make such approach work (even if I think this is not
moving in the best direction).

However, I'm begging you to consider porting at least the computed
fields of in v9 to the new API. The fact that the state of
stock.pickings is declared using the old API has very nasty consequences:

* overriding the field is harder than required, and cannot be done in
the new API afaik
* it is not possible to call other pieces of code from within the
overridden function and expect these calls to see the updated state of
the picking. It sure is possible to work around this but readability and
maintainability are badly harmed in the process

If we are to extend the recompute of computed fields, please pretty
please help us by having all these computed fields in v9 be declared
with the new API.

Thanks for your work on Odoo, and for considering this request.

Alexandre Fayolle
Chef de Projet
Tel : +33 4 58 48 20 30

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac Cedex

Post to: