Comment 120 for bug 1160365

Ana,

My reply to your scenario bellow.

> John Doe works for ACME, SA.
> John Doe buys a good for ACME, SA.
> Our company makes a sale order for John Doe working for ACME, SA.
> We are sending goods after one month Jon Doe asked for those goods so we
> will expend almost 1 month to send the invoice to John Doe. Curiously, John
> Doe left ACME, SA and was contracted by CAEM, SA who casually is also our
> customer.
> How do we handle with this aproach on 7.0?
> 1. We have got to create John Doe for CAEM, or worst, change John Doe
> company asigning now CAEM, instead of ACME. So.. if user does that... What
> will be the company related to invoice? CAEM? ACME?
> 2. If we create both different John Doe contact... sameway first invoice is
> going to an incorrect contact because John Doe is not working more for
> ACME.
> 3. If we just move company... I don't know what happens. I'm lost,
> because... How this will affect to sale order? or pickings? Or statistics?
>
> Now.. let me handle same aproach with 6.1
> 1. Sale order is in the name of ACME. Additionally (if we need) could set
> John Doe as related contact for Acme.
> 2. If John Doe leaves... what happens? NOTHING at all. User does not need
> being worried about correct contacts because nothing change.
> 3. Sale order will be always related to ACME, Pickings will be related to
> ACME and Invoices will be related to ACME. Additionally if we want
> correctly set John Doe is now working for CAEM... just change the contact
> company on contacts... it's done.

Please, Ana.

Please do test Olivier's branch and compare with v6.1 before judging.
You will notice that both versions produces the same result: documents
for external communications and forms for internal usage.

The behaviour is exactly the same in v6.1 and Olivier's branch when
sending documents to customers:
  - When printing the document, the sale order/invoice is sent to John
Doe's address (not to ACME's one) [*]
  - When sending by email, it uses John Doe's address, not acme's one.
And this is the correct behaviour!

If John Doe leaves and if you do the mistake to change John Doe's
company and address, the behaviour is exactly the same in v6.1 and in v7
--> wrong result. Whether it's by email or by post, documents are sent
to the new John Doe's address.

As an additional note, can you imagine sending your quote or invoices to
<email address hidden>?
It has no sense to send document to the generic address of a company.
Try to send a quote to <email address hidden> :) You have to send quotes to
<email address hidden> otherwise your email/letter will be lost in the company.

If someone leave the company, most companies redirect their emails and
letters to the responsible that replaces him, so this is not a problem.

If you change the company a person is working for (instead of creating a
new contact in the new company), you will create:
  - inconsistencies in v6.1, you get on printed addresses:
      Old Company
      Person
      New Company Address
  - in v7, you do not get an inconsistency as the model ensure it's
always correct (but it's may be not what the user expected):
      New Company
      Person
      New Company Address
The v7 behaviour is consitent (suppose you merge two identical partners
created by mistake) but I agree that it's not what the user may expect.

--> in this case the real solution is to add a Warning: "Are you sure,
this will...". Certainly not to reproduce the inconsistency of v6.1.
So, this is a very bad scenario. And the bug to fix is to ensure the
user do this only if he really intended to do this. It has nothing to do
with the quality of the solution/data model.

[*] You may have not noticed it as v6.1 does not print the name on the
invoice, which is a bug that has been fixed in v7. But it really uses
John Doe's postal or email address, not Acme's one.

> I feel really silly trying to explain this to someone. I can not realize
> how anybody can not see this approach...

Thanks for taking the time to provide your input. But, can you please
provide a real business case based on real tests you did on the branch
to avoid more confusions?

--
Fabien Pinckaers
CEO OpenERP
Chaussée de Namur 40
B-1367 Grand-Rosière
Belgium
Phone: +32.81.81.37.00
Fax: +32.81.73.35.01
Web: http://openerp.com