Well if you follow the default process as described, it will end up invoicing the contact of the company it will have created (here "Joe" see exact scenario un bug report).
*I did, and I reported at https://bugs.launchpad.net/openobject-addons/+bug/1155679 that the Invoice was created for the Company. I checked this in the database and compared the partner_id of the contact and the company.*** * *The contact name is printed on the Invoice above the name of the company, but the Invoice is for the company. It shows up on the aging for the company, and needs to be paid for by the company. Ray. *From:* Raphael Valyi [mailto:[email protected]] *Sent:* Friday, April 05, 2013 12:18 PM *To:* Ray Carnes *Cc:* Gustavo Adrian Marino; openerp-community *Subject:* Re: [Openerp-community] IMPORTANT: OpenERP v7 and company contacts management Hello Ray (and others) thanks for investigating. Well that one from the CRM is just the top of the iceberg really. Well if you follow the default process as described, it will end up invoicing the contact of the company it will have created (here "Joe" see exact scenario un bug report). But in many situations (if not all), you cannot invoice a contact, because a contact doesn't carry any of the fiscal, accounting or financial data of the company it belongs to, trivial examples are a contact isn't expected to carry the fiscal position, neither is it supposed to carry payment conditions or credit limit. More tricky scenario would be: for instance I believe in the USA you should collect taxes according to where you sell. Well what probably matters here is where the company you are selling is located not where the contact you had on phone is. But this happens also with intrastat sales across Europe. In countries such as Brazil, missing the fiscal parameters in a sale order will even lead you to pick the wrong VAT's and show wrong amounts. Furthermore, invoicing a company contact can even be illegal in some countries (basically you can put nothing from a contact on an invoice, it's the case at least in Spain (after Ana Juaristi or Brazil where we have electronic invoicing and everything specified from the company, not a contact). This is a quick patch, but SA saying it's expected to invoice a contact in v7 is what I really call the top of the iceberg. As a consequence, they started changing the code to at least associate the accounting moves to the company and not to the contact. Well, as a consequences, invoices and there moves and payments don't belong to the same partner_id (and have no other key in common either). So it required customization of the reconciliation process too, with some missing issues: https://bugs.launchpad.net/openobject-addons/+bug/1151900 But chances are this will mess with overdue payments and cash management prevision. Here https://www.evernote.com/shard/s158/sh/40828d76-d94a-4f44-bdb5-9c0336f55a52/fe43fe77c401e9f3bdf95982a4b0a878 Nhomar is analysing "6.A.- Inconsistency, and bad approach, the partner_id in the invoice MUST be the same of the account move line." Which is just a consequence of letting picking a contact in invoices and then changing partner_id in the accounting. So after I reported that, in https://bugs.launchpad.net/openobject-addons/+bug/1160365 OpenERP started to propose us the following fix: copy data such as fiscal position from a company to all its child contacts. Notice that Olivier Dony proposed that solution one week after telling Ana Juaristi base_contact module was to be ported to v7. I would be be very happy to understand how you can have a contact belonging to two companies (base_contact) but still copy fiscal data from its parent company to it (so which one and what you do in the other cases?). When I read such plans, sorry, it raises suspicion if they even know what they are doing... And the proposed solution goes as far as duplicating accounting properties from the properties table to the contact. Hum data duplication, record duplications, what a nice solution... But mostly, the proposed fix they planned totally fails to address many issues that are minimized instead: 1) Once your business documents like invoices can have partner_id pointing to any contact of a company, how accurate are your financial report grouped by supplier or by customer? Same things with sale an purchase previsions. Which B2B company isn't interested knowing purchases by supplier? in comparing prices between supplier (and not facing contact ids artifacts inside)? 2) *The problem isn't just in invoices. It's everywhere!* In many place in OpenERP, a document has a partner_i field (which can now be a contact) and propose to select a many2one record which belongs to the same partner_id. Consider that obvious case: you deal with Return Material Authorization such as with modules like that one: https://launchpad.net/openerp-rma you create some picking related to some customer. Later you want to relate that picking to a CRM claim. by default the domain will be taking the partner_id found in the picking form and filtering crm.case based on it. What about all the other claims from the same partner but where partner_id has been set to a contact instead of it? Well you will just miss them as if there were none. What if you put a contact on the picking instead of the company instead? Even harder to relate the right business documents despite they belong to the same company. What if the code automatically creates a crm.claim if it finds none for the provided partner_id ? There are such cases such may be more subtle all over the place in the in the official addons... And no, these pointers, you cannot duplicate them the contacts... A record that is linked as: partner one2many recods such as a CRM claim cannot point to the other contact ids of that partner because it should do that with only one foreign key (a many2one). This is no paranoia, for instance a partner can also have many banks. Well currently they will be matched only against the company. What happens when partner_id is a contact now? So basically OpenERP SA is telling us "fear not". If such cases are identified (they exist right today), we will fix them by changing the code. from my 5 years of OpenERP experience, a regression takes on average 3 months to be fixed and is fixed in the common branch only 50% of the times. So even if that's only 50 hidden functional regressions on the core related to that choice to allow contacts everywhere in partner_id, *yes I do fear, and not just a little*. But it's not just about the core, it's also about all the hundreds of community module that have never been designed so that partner_id can randomly be a company or any of its contact. An other case we identified just yesterday is access rules. Imagine you say a salesman can only see and write the documents related partners of its portfolio (so hard to imagine really?). Well, are you sure you will properly define what is the portfolio for every companies and all these contacts, even these added later? Will you not forget to give access rights to the contact parents now that data will be supposed to be duplicated between a company and its children? Are we really making things simpler by doing that??? Now consider instead (what I called option B): Why the hell can we not say: everywhere we have a partner_id field. The OpenERP ORM adds a contact_id field automatically. In any form were there is a partner_id field, the fields_view_get method automatically hides partner_id an show contact_id with all the same labels and view modifiers taken from partner_id. The user cannot see any difference. Now when contact_id is changed, an onchange event automatically sets partner_id with the related company or the same id in case of a physical person partner. Then partner_id is exactly what the code as always been expecting. Then records of same and different nature that belong to the same company all have the same partner_id again. Reporting just works again exactly as expected. And if we want to say "sorry SAP, we are social and flashy now", you still have that contact_id you can send the mail to or search with. Isn't that a much less risky, much less invasive solution than the "fear not" from the ostrich policy? An early prototype of such a thing is available for tests here: https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/27 of course, that would have been cleaner if OpenERP SA did it in the core instead of a monkey patch. And if my concerns had met more understanding, probably even the naming choices would have been more tolerant. Now if you paid attention to the reasoning: you will probably agree that an ERP cannot live with business document having no key pointing to their related commercial/legal entities (because no grouping, no matching). Then we need that key. And yes, we ALSO need a key to the contact that is something much more random. *It means we need two keys, not just one.* *So do we really want changing all the semantic of partner_id and fixing all the code everywhere to make sure it continues to work when partner_id is suddenly a contact? And in the future what? to avoid dying OpenERP would then add a new "commercial_entity_id" key pointing again to the commercial/legal entity deterministically?* *isn't it smarter to add that contact_id key right now just for contact (anything) and leave partner_id untouched with a code that is battle tested to just work like that?* Also, forbidding contacts just on some documents instead of systematically wouldn't seem a really good idea. Because every time two business documents belonging to the same company don't have the same partner_id, then we are making the code and reporting brittle for nothing. Instead it's just better to ensure they all have the same partner_id always, and that most of documents can have an additional contact_id, even if it's not used. At least the user still see only one field to field, so no usability difference with today. Sorry, but the direction taken by OpenERP SA on that is beyond any logic for me and quite a few folks. And yes, that's an important topic, a critical one even. -- Raphaël Valyi Founder and consultant http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi> +55 21 2516 2954 www.akretion.com On Fri, Apr 5, 2013 at 2:28 PM, Ray Carnes <[email protected]> wrote: Hello Gustavo and Raphael, I just spent some time looking at this – clearly there is something I don’t understand. I have posted my experience at https://bugs.launchpad.net/openobject-addons/+bug/1155679 I get the right partner_id associated with the sale and invoice and no accounting problems. What am I missing? Can I impose on you to outline a reproducible case that I can follow? We have many customers on OPW and could have each of them log the same bug if I could understand it and reproduce it. Ray. *From:* openerp-community-bounces+rcarnes= [email protected] [mailto: openerp-community-bounces+rcarnes=ursainfosystems....@lists.launchpad.net] *On Behalf Of *Gustavo Adrian Marino *Sent:* Tuesday, March 26, 2013 11:35 AM *To:* Raphael Valyi *Cc:* openerp-community *Subject:* Re: [Openerp-community] IMPORTANT: OpenERP v7 and company contacts management Raphael: I totally agree with your position. The position of OpenERP will lead us to uncountable problems without any benefit. Let me add that there are many countries that do not allow a contact as reference of a commercial document. In all cases a legal entity is required (a company or a documented person, someone with a legal ID). In that sense, a contact is not a party. It is no secondary issue, it is in fact the main an only difference between partners and contacts! I strongly believe the proposal of Olivier is no more than whishfull thinking. He is underestimating the consequences of the faulty proposed strategy and trying to hide the foresable problems just not to accept that OpenERP should fix the problem in the current version. It is clear that this is more a dogmatic issue than an attempt to look for the best for the comunity. I totally agree with you in the fact that the faulty process in testing before v7.0 release and the lack of discusing about philosophy of res.partner's changes early enough is probably the root of the problem. Nevertheless, now it is time to solve the issue, even if we have to change some rules in order not to damage the commercial success of OpenERP. It is not a minor issue. That's the way rules evolve, when you change them once you realize they are no longer valid! I encourage you not to abandon your effort to convince OpenERP which is the right thing to do. My 2 cents. Gustavo Marino 2013/3/26 Raphael Valyi <[email protected]> Hello community, I think this threads totally deserves your attention: https://bugs.launchpad.net/openobject-addons/+bug/1160365 Basically in OpenERP v7, business documents such as invoices can now have their partner_id field pointing to a company contact res.partner record while in previous versions of OpenERP it had to point to company partner or to a physical person partner. Note that this is note about debating moving the res.partner.address into the same res.partner table which I find a good move that is making us closer to the Party industry standard pattern. This is more about how we are allowed to use these records in OpenERP v7. I claim the current codebase doesn't handle the case where partner_id is a company contact and many bug are related to that (many not reported one by one yet). This has just been partially acknowledged by OpenERP SA in the bug tracker, but IMHO the problem is deeper than what is acknowledged (I explained why in the tracker). Basically there are two ways of fixing this: A) making everything required to have contacts suddenly a be "first class business documents citizen". Me and several people claim that this "everything required" actually involves many many things that may take years to get right again if you accept to look deeply at the issue and that it's not reasonable to go this way withing the v7 "stable" release. But this is this way that OpenERP SA planed to go and is apparently still planing to go... B) there would be an other way that would be adding contact_id fields on business documents (sale/purchase orders, invoices...) and putting an on_change to set the existing partner_id field with the same id in case of a physical person or the related parent company in case of a company contact. That would preserve the existing partner_id semantic within the core and community codebase which took nearly a decade to consolidate the way it was on 6.1, avoid taking useless risks, allow fine grained by contact analysis while not breaking the by company reporting. I think this is about a 50 lines patch at most. No risk taken... Why on earth try to go with A)? So I suggest experts carefully read this thread and give their thoughts when they understand the problem: https://bugs.launchpad.net/openobject-addons/+bug/1160365 Thank you for your attention. Meanwhile, if you are using v7, it works quite well for B2C and can work for B2B provided you don't put company contacts in partner_id fields of business documents if you are interested in accounting, fiscal or financial correctness. In my opinion, the problem isn't that much the 50 lines of patch of solution B) that everyone could put in place right now, the problem is instead the hundreds of lines of code I forsee if we keep trying to do A) that may lead to slower and more complex code with no functional benefit IMHO and making people not applying the B) patch facing regressions possibly for years. So let's say that's diverging way of fixing the problem, quite diverging ways and we need this to keep working as contact management is an important feature that was supposed to work in the core. Please comment on the bug tracker (not here) if you want to comment the proposed solutions. Best regards. -- Raphaël Valyi Founder and consultant http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi> +55 21 2516 2954 www.akretion.com _______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp -- Gustavo Adrian Marino Mobile: +54 911 5498 2515 Email: [email protected] Skype: gustavo.adrian.marino
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
