© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
> @raphael
>
> [...]
> Note that your proposition B is not good; it's important to be able to
> invoice to physical persons who have no company.
@Fabien, please read carefully. My proposition B is not about preventing to
invoice a final customer at all.
It it about to put a domain like you already did for bank statements for
instance to be able to selection only a commercial entity that is:
a company OR a final customer BUT NOT a contact company.
Look at the party model carefully (at least the top of the page):
http://
Now in v7 you made companies, contacts and final customers all subclasses
of a "party" (res.partner now) which seems good to me so far. (provided you
do the address object extraction via _inherits to be able to share
addresses then).
BUT because they are subclass of Party, it doesn't mean they can be
exchanged anywhere!
It is like if you have a python function requiring a number, you can pass
it a floats or an integer, no problem. Like may be you can have a pinking
in OpenERP pointing to any kind of party (and may be not, that
generalization should be allowed case by case very carefully), fine.
BUT you may have a python function requiring an integer and not a float.
And I claim the way it is your account module requires that partner_id can
only be a commercial entity (that is a company OR a final customer I mean)
BUT NOT a company contact!
So my recommendation is not to change all the code of the account module
(and all community related modules, and at least the same for the purchase
module) but instead to make that "subtype" restriction explicit via a
domain, just like you did already for the bank statements. AND you also
need to introduce some sort of contact_id to manage the invoicing contact.
Additionally, going solution A) instead (that is change all the code of
account and other modules to accommodate to partner_id now being a company
contact eventually) you would screw all the reporting tools about your
invoices in a very bad way. No more simple groud_by partner_id to find your
sales to per companies (or final customers), you would now at least join
with the res_partner table and eventually join again over the res_partner
table on the parent_id... Much more cumbersome and many existing reports
totally broken!
As for localizations. Well our localization in Brazil won't work if
partner_id can be a contact company instead of the company. That is as a
workaround we already assumed that for our v7 projects (that is I applied
my patch even if better can still be made).
But it's worse than that, if OpenERP SA view is to allow company contacts
everywhere for partner_id, well I'm not sure we would follow OpenERP next
versions because it sounds extremely wrong and dangerous to us.
So I hope we see solution B) assumed and implemented.
I'm not the only one thinking that. See also
https:/
Regards.