openerp-india team mailing list archive

["Olivier Dony \(OpenERP\)" <1151947@xxxxxxxxxxxxxxxxxx>]

On 03/08/2013 11:05 AM, Guewen Baconnier @ Camptocamp wrote:
> Just a point, how will you determine who is the 'accounting partner'? Use
> the direct parent_id if such exists and the current partner has no
> children? It could maybe be a problem if one want to create a hierarchy of
> 'simple' partners, they would be mislead with a 'complex' partner with
> addresses. That's maybe a use case to forbid though.

The current _find_accounting_partner() method uses the direct parent if the 
current one is not a company, and it needs to be improved.

To keep things simple, it could probably go all the way up to the root ancestor 
in all cases (ignoring the `is_company` flag). That would work for companies 
and for individuals. It would not allow complex hierarchies where different 
children can be customers/suppliers and have their own receivable/payable 
entries, so making separate partners for these special cases would still be 
required. However it seems it would still cover most B2C and B2B cases, while 
keeping the logic very simple to understand and use.

Then perhaps in trunk we could refine this behavior by relying more on the 
`customer`/`supplier` flags: depending on the kind of journal entries being 
generated the system could take the first `customer` or `supplier` parent in 
the hierarchy, which would allow making multi-customer/supplier hierarchies.
However to make this robust we should make sure that contacts/addresses are 
never flagged as customer/supplier implicitly, and help avoid mistakes by 
raising an error when the partner flags aren't properly set at the moment of 
generating the journal entries.
It sounds a bit complicated to understand and use properly though, so we need 
to make sure it's really useful first.

What do you think?

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Server.
https://bugs.launchpad.net/bugs/1151947

Title:
  Link several addresses on individual partners (not companies)

Status in OpenERP Server:
  Confirmed

Bug description:
  Hello,

  Thanks to the Fabien's Q&A on help.openerp.com regarding how to have
  several addresses on partners, I think the situation is clear enough and well
  explained for companies [0].

  However, I still can't find a good way to link several addresses on
  individual customers, not companies, in a B2C context. I posted a
  question and got no response [1].

  Here is a use case, I'll use it in my hypothesis below.

  Mr Foo lives at Bar Street 1.
  He works at Baz Avenue 150 and usually he wants to receive goods at
  work.

  I see 4 hypothesis for that in OpenERP 7:

  1. I create 2 distinct partners:

  * Mr Leo Foo at Bar Street 1
  * Mr Leo Foo at Baz Avenue 150

  They haven't any links between them.

  Problems:

  * From a usability point of view, this would be a mess, especially if I have
    homonyms. I would never be sure what is the main address of Mr Foo and
    would have difficulties to find his good addresses (even if I set Baz
    Avenue 150 as 'delivery' address, I would also the 'delivery'
    addresses of  his homonym Mr Foo in the searches).
  * I would have wrong accounting entries, sometimes on Mr Foo at Bar
    Street, sometimes on Mr Foo at Baz Avenue

  Conclusion:
  It seems to me that this solution is not applicable due to accounting
  issues.

  2. I put the main address of Mr Foo as `is_company`:

  * Mr Leo Foo at Bar Street 1 is the main record, considered as
    `is_company`.
  * Mr Leo Foo at Baz Avenue 150 is a contact of type 'delivery' linked
    to the Mr Foo company record.

  We would not have accounting issues, because this is already handled for
  companies. The searches and usability would be improved over solution 1.

  Problems:

  * Mr Foo is not a company!
  * This would be totally misleading
  * If any existing or future addons use the field `is_company` to apply
    some logic which should only be applied for companies, we would be
    bloody damned with individuals considered as companies

  Conclusion:
  It seems to me that this would be a good solution, but with a renaming
  of the field `is_company` to something more general (and eventually keep
  a field `is_company` to only keep this information). => too late for v7?

  3. This use case is not supported by OpenERP 7 and has to be coded in a
  community addon.

  Problems:

  * We have to be very sure that this problem will be handled
    in only one way. If a part of the community manages it in one way and an
    other part in another way, we'll start to see incompatibility between
    addons (and OpenERP risks issues for migrations too).

  Conclusion:
  It would be very surprising because this use case is very basic for B2C.
  I think that a so 'low level' part of the datamodel should be defined by
  OpenERP to avoid to compromise higher level addons. A change on theses
  base models can have an impact on all the other addons (see
  base_contact).  But let's admit this hypothesis is the good one.

  I'm alright to create a community addon to handle this use case (by the
  way, this is a prerequisite to synchronize openerp with magento). But I
  expect a strong guidance from OpenERP, I need to know how this link
  should be done (add an `is_individual` field like the `is_company`
  field? Just add the `parent_id` field accessible everytime?) to ensure
  that the community addon's solution won't go against the current with
  OpenERP devs.

  4. I just missed the way to do that

  Conclusion:
  The usability on this point should be improved because no one has ever
  answered to my question :-)

  
  What is the solution advocated by OpenERP and why?
  Thanks

  
  Guewen

  
  [0] http://help.openerp.com/question/4341/on-v61-one-partner-could-have-several-addresses-invoicing-delivery-is-this-still-possible-in-v7/
  [1] http://help.openerp.com/question/135/how-do-i-attach-different-addresses-on-a-individual-customer/

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-server/+bug/1151947/+subscriptions