openerp-community team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

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 <rcarnes@xxxxxxxxxxxxxxxxxxx>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:rvalyi@xxxxxxxxx]
> *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 <rcarnes@xxxxxxxxxxxxxxxxxxx>
> 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=
> ursainfosystems.com@xxxxxxxxxxxxxxxxxxx [mailto:
> openerp-community-bounces+rcarnes=ursainfosystems.com@xxxxxxxxxxxxxxxxxxx]
> *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 <rvalyi@xxxxxxxxx>
>
> 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     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>
>
>
>
>
> --
>
> Gustavo Adrian Marino
>
> Mobile: +54 911 5498 2515
>
> Email: gamarino@xxxxxxxxx
>
> Skype: gustavo.adrian.marino
>
>
>
>
>
>
>