Add contact and invoice party on orders

Feature
,
1

Rational

Currently on sale and purchase, we can define a party (who takes the order and is invoic ed–ing) and the shipment party.
But the complete picture of an order may have more parties involved: who place, who take, who is invoic ed–ing and who receive/send. So we are missing some of them (or they are merged into the party).

Proposal

We add on sale and purchase a new optional field contact which is a link to a contact mechanism with no restriction on the party attached to (and we change its record name to display the name or the party in addition to the value, e.g.: +1-202-555-0191, John Doe). This idea is to store who placed the order and how by email, phone etc. But for searching this contact if the party is already filled, by using the search_order we show first the mechanism of the party, then those with the minimal relationship distance. Also when creating a new contact mechanism from the order, it should fill the party field by default with the value of party order.

We also add on sale and purchase a new field invoice_party which behaves like the shipment_party.

For the opportunity, we add also the fields contact with the same behavior and it is copied onto the sales created.

Implementation

https://bugs.tryton.org/issue8992

2

I’m not sure if this is really required. Is not the party placing the order most of the cases who is invoiced?

3

Yes in most of the case but not all.

4

Then I’m not sure if it’s worth to add this field as part of base and have a more complex UI

5

I’m not sure it will make the UI more complex. Indeed I think it will bring better symmetry if we design it like:

Party: _______________ Contact: _______________
Invoice Party: _______ Invoice Address: _______
Shipment Party: ______ Shipment Address: ______
6

Do I understand correctly that in field contact there should be stored a party, that orders on behalf of the invoiced party? Besides legal questions (who is allowed to order in the name of another party?) shouldn’t the field be better named then ‘placing_party’ and I agree with pokoli, that its usage seems to be a quite special use case and doesn’t qualify for inclusion in base.

7

Not a party but a contact mechanism.

Common case is an employee of a company who place the order for his company.

It is not a party.

The contact is not special that happens for most of the B2B orders.

8

Should invoice_party create a delegated invoice? (Invoice delegation TL;DR:
A invoice in the name of the sale/purchase party, but the payment is delegated to the invoice_party)

9

I do not think so. Here it is an information that we have prior to validate the order and the party want to have this information on the invoice.

10

This is contradictory. An employee is a party following our data model in Tryton. Otherwise you also wouldn’t have to say
“We add on sale and purchase a new optional field contact which is a link to a contact mechanism with no restriction on the party attached to”

But I see what you intend to do. I am still thinking that placing_party would be a better match for the purpose.

11

Yes but we store his contact mechanism because the goal is to be able to contact him.

12

But why you would like to restrict the contact possibilities to one single contact mechanism, when we could have all contact mechanisms of the order placing party?

Here it looks like the Contact is a contact mechanism of the Party of the left side. But with your conception it could be a contact mechanism of a different party. Where is the symmetry to Invoice (Shipment) Party and Address, where the Address is an address of the Invoice (Shipment) Party?

13

This is not a restriction but an information.

Nowhere.

14

I also don’t understand why one would want to have a single contact mechanism. If I want to contact a party, I open its form and use the contact mechanism I need at that moment.

15

If you store only the party, you are losing the information about how the order was placed. By storing the contact, you have both information.

16

I don’t see how that it is relevant. I may be interested to know if it was placed by phone, e-mail, or another means (say EDI-like interface) but not which exact phone or e-mail was used.

A party can have several phone numbers for the same contact (at least the company one and the mobile one are going to be quite frequent) and I don’t think anyone cares if the order was placed from one phone or the other.

17

For me, it is more flexible to use contact mechanism there because it supports both usages: using party with party relationship and using contact mechanism to store few contact (we have name now on contact).

18

Ok, so for me it makes sense to store the contact mechanism but why storing the party? As the mechanism is directly related to the party I’m not sure it make sense to also store the party by default on sale. I’m wondering if it won’t be better to make it a functional field.

19

The party is not linked to the contact (just preferred with order and default value).
The party represents the entity that will own the goods or services sold.

20

Here is the implementation: Issue 8992: Add contact and invoice party - Tryton issue tracker