openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

Hey Olivier, you are right, looks like it has been fixed indeed. Sorry, I
didn't pay attention to that.
Something that lead me to confusion is that you can still select a different
company_id from the one determined by the shop_id on an order. But then when
you save the order, the company_id get switched back to the one determined
by the company_id (didn't pay attention to that detail and that's why I
believed they weren't related fields).
So except that detail we don't need to bother too much, everything looks
perfect now regarding to the order company_id field and its usage.

Thank you for your time.


Raphaël Valyi
Founder and ERP Consultant
+55 21 3010 9965
http://www.akretion.com

<http://www.akretion.com.br/>


2010/9/21 Olivier Dony <odo@xxxxxxxxxxx>

> Le 21/09/10 16:52, Raphaël Valyi a écrit :
>
>  As part of the native multi-companies support, in OpenERP v6, the
>> sale.order object now has a company_id field.
>> The trouble is that this is somewhat redundant with the existing
>> mandatory shop_id field which also determine a company_id field (a shop
>> belongs to a company).
>>
>
> As far as I can see [revno 4958] the company_id on the sale.order *is* a
> related field (in this case a /stored/ read-only copy of the shop's
> company).
>
>
>
>  I'm asking that while I try to provide a proper patch for
>> https://bugs.launchpad.net/bugs/626861 (even worse: the company for the
>> subsequent picking/invoice is taken
>> from the currently logged user in context no matter what the two other
>> company_id fields are; similar issues may exist at other places)
>> as I'm testing the v6 multi-companies features for a customer.
>>
>
> Again, as far as I can see [revno 4958] the line you refer to (in your bug
> description) is only used to determine the security lead time to consider
> when scheduling the new picking. Using the sale.order's company would make
> sense too.
> The picking's company is correctly taken from the order. We could even
> argue that it should be taken from the source stock location instead (since
> this is a outgoing shipment), but this will be the same as the order's
> company due to the way the source location is determined.
>
> In any case we are in the process of reviewing this kind of business rules
> during the preparation of v6, so any testing of multi-company features is
> always welcome!
>
> I hope this helps (but I hope we're reading the same code base)...
>