Community mailing list archives

community@mail.odoo.com

Re: Sale and purchase workflow

by
Eric Caudal
- 09/20/2015 09:26:25
Hi Graeme,
In multi-company you need to setup first your default parameters in each company so that when new products or partners are created taxes and accounts are automatically assigned.
- Taxes in settings/configuration/accounting
- Accounts (and other properties) in settings/technical/parameters.
When a user will create a product in company A and the user in company B will access the product, he will automatically get the default taxes/accounts.
Of course if the taxes is not the default one, a user in company B will have to force it in the product.
AFAIK taxes/accounts will apply the same way in SO and invoices.

Let me know if I understood properly your question

On Sat, Sep 19, 2015 at 11:46 PM Graeme Gellatly <gdgellatly@gmail.com> wrote:

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.


On Sun, 20 Sep 2015 2:03 AM Luis Panozzo <luis.panozzo@elmatica.com> wrote:
Merci, Antony.
Where is this documented. please?
This and other nuances as far as configuration is concerned.
Thank you in advance


Luis Panozzo (Lp)
Technology Manager
Elmatica AS
luis.panozzo@elmatica.com
Skype: luispanozzo

On 19 September 2015 at 12:13, Antony Lesuisse <al@openerp.com> 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
>
>     _______________________________________________
>     Mailing-List: https://www.odoo.com/groups/community-59
>     Post to: mailto:community@mail.odoo.com <mailto:community@mail.odoo.com>
>     Unsubscribe: https://www.odoo.com/groups?unsubscribe

>
>
> _______________________________________________
> Mailing-List: https://www.odoo.com/groups/community-59
> Post to: mailto:community@mail.odoo.com
> Unsubscribe: https://www.odoo.com/groups?unsubscribe
>

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe

--

Eric  Caudal (from my mobile)