hello Ray, well not sure how you did, I just reproduced it on runbot: http://7-0-6450.runbot.openerp.com/?db=7-0-6450-all&ts=1365189983709#id=39&view_type=form&model=crm.lead&menu_id=446&action=511 admin/admin See opportunity "l1", where partner is "foo" contact of company "compX". (I could post a video, I can just not do it now). I also transformed the opportunity to a quotation again related to the contact.
In any case, this is of very little importance if there such bug or not in the CRM? As I said, this isn't the debate at all. I already fixed that bug for our customer. What happen if a user picking a contact manually in an invoice anyway? In a purchase order? We just have the same fundamental issue I described in details. Saying it's user fault is no solution because if the systems allows it they will do it. And we also need a way to manage contacts of such documents because they are important. Regards. -- 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 4:23 PM, Ray Carnes <[email protected]>wrote: > 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
