Comment 18 for bug 1155679
Revision history for this message
| Raphaël Valyi - http://www.akretion.com (rvalyi) wrote | #18 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0f7b58d
(Get the code!)
Hello Bojan,
all the OpenERP partners I talked with don't caution invoicing a company contact instead of a company. A contact company is never expected to carry the legal fiscal, accounting and financial data of the company it belongs to. And today the code in the account module will mostly try to read these information on the contact only if partner_id happens to be a contact like with this bug.
Apparently OpenERP SA tried to work a bit around it by at least finding back the right company accounts for the journal entries. But this is broken for almost every other field that the account module will now try to read on the contact instead of the company partner, like: payment term, payment condition, credit limit, fiscal position, pricelist...
So IMHO the two options are:
A)
try to make it possible to invoice a company contact by fixing everything else (but there is A LOT OF WORK) and I don't think it's a work in the right direction at all. There are several other very severe functional regressions with the new address design which fails to normalize data. So I'm really not sure we should change a lot of functional code to meet that new suspect data model. May be it's more constructive to change the partner data model again quickly for a v7.1 or v8 version instead.
OR
B)
Forbid to invoice a company contact, with a domain on partner_id for instance. In this case this big should be dealt with and work should be done to have an invoicing contact again on the invoice object.
From our quick investigation we have at least the same problem with purchase orders. As for sale orders, as there is already an independent invoicing address, it can more easily be worked around (still if we fix that kind of bug here).
I should say I believe many OpenERP profesionnals and may be OpenERP SA themselves didn't understand yet the gravity of this regression. I'm extremely disappointed to see such regressions, still totally minimized today while IMHO this should be addressed among the very to priorities before saying the version is stable.