Community mailing list archives
Re: Sale and purchase workflowby
Yes and also eating too much chocolate makes you fat.
Now user in company A creates product.
User in company B uses product.
On an invoice tax is applied, via the account.
On a sale order tax is not, EVEN IF the tax was set as a default due to those very record rules.
Merci, Antony.Where is this documented. please?This and other nuances as far as configuration is concerned.Thank you in advanceOn 19 September 2015 at 12:13, Antony Lesuisse <firstname.lastname@example.org> wrote:If records rules are set correctly you should only see the taxes from the company you are currently in. To setup the product P1, as a regular user switch to company A and set P1.taxes_id = [TA1, TA2] The switch to company B and set P1.taxes_id = [TB1, TB2] If you are loggued as administrator you see P1.taxes_id = [TA1, TA2, TB1, TB2] but it's forbidden to work as administrator in a multi company environement. As a regular user everything work perfectly because of the record rules. On 09/19/2015 09:04 AM, Graeme Gellatly wrote: > 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 stock.py 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 > http://www.camptocamp.com