Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ADD] [sale_partner_contact] #253

Closed
wants to merge 5 commits into from

Conversation

JordiBForgeFlow
Copy link
Sponsor Member

This module allows to add to a quotation or sales order the contact person.

@rafaelbn
Copy link
Member

rafaelbn commented Mar 3, 2016

Thanks! Hi @jbeficent could you check travis please?
Cc @antespi @pedrobaeza

@pedrobaeza
Copy link
Member

This module has no sense for me, as you can put directly a contact in the partner_id field. Then, you only have to customize the report if you want to distinguish between partner_id and partner_id.commercial_partner_id.

@JordiBForgeFlow
Copy link
Sponsor Member Author

If this person leaves company A and goes to company B, you'd have to duplicate the contact to ensure that the sales is attributed to company A. Not nice, because the contractual agreement(aka sales order) is with a company, not with a person.

@rafaelbn
Copy link
Member

rafaelbn commented Mar 3, 2016

@jbeficent you have to duplicate contact always. This is not only for sales, is for emails, event register, tasks as follower. In Odoo you cannot never reuser contact for diferent companies, you have to use diferent one. Because if not you will have to create partner contact for every model.

In the other hand, @pedrobaeza this is the situation to solve in my opinion:

  • Partner of the sale: person who requiest that sale (contact)
  • Partner for the invoice: person o place where you have to send invoice (invoice)
  • Partner for the shipping: where you will deliver products (shipping)

Other need (which must be linked) is in invoicing. When there are a lot of people in a company (>20 fox exemple) in diferent you and you must separate in the same way of sale:

  • Invoice partner (partner for the invoice in sale order)
  • Invoice Shipping partner (partner for the shipping in sale order)
  • Invoice Contact partner (partner_id field in sale order)

OK, then is more logic to add a new field in invoices invoice_partner contact and take the field from partner_id in sale order.

@jbeficent you have to take care also because all this fields are related with portal modules, who access who not.

@rafaelbn rafaelbn added this to the 8.0 milestone Mar 3, 2016
@JordiBForgeFlow
Copy link
Sponsor Member Author

@rafaelbn Relating to contacts moving to a separate company, you'd need to then add a restriction to prevent a partner from being moved to a different company, if he's been involved in transactions with the previous company. What you describe is a recommendation based on your experience. Not preventing anyone from doing this simple change means that people could completely screw the sales orders, invoices, etc.. just because they moved the contact person to another company.

It seems to me a better practice that you should be able to remove that contact person as follower from whatever he's been involved in the past, and then assign him to the new company, as a company procedure. I recall a module that would allow you to view what a partner was being follower of, so that you could quickly remove him the privileges related to his previous company.

A company holds commercials transactions with other companies, or with individuals acting as the direct receiver of that transaction. Not keeping the partner directly associated to the transaction is IMHO incorrect.

As for the proposed partners in the sales order or invoice, I do not really understand.

In my previous experience in SAP, you had the following partners in a sales order:

  • Sales To (the partner with whom you sign the contract and have an obligation. In a sales order the main partner is the "Sales To".)
  • Bill To (that's the physical address that will receive the invoice)
  • Payer (that is the partner that will be responsible for payment. The journal entry for Accounts Payable is associated to the payer)
  • Ship To
  • Contact person (optional)

Then, in the invoice:

  • Payer (In an invoice the main partner is the "Payer". Is the partner that has an obligation to pay the invoice, and is the one reflected in the accounts payable journal item)
  • Bill To
  • Contact person (optional)

Generally it's not a good practive to maintain the Ship To in the invoice header. The reason for this is - you can combine multiple deliveries (with different Ship-tp-Party) in a single Invoice. Thus in case like this one, Ship-to Party would be different for some line items in Invoice.

So Ship-to-Party should be best available only at Line Item Level in Invoice.

@rafaelbn
Copy link
Member

rafaelbn commented Mar 3, 2016

Well of course you can try it, but it's not my experience only, it's how Odoo implement Odoo and what Odoo says. Contact is not a contact, is a contact of a company and if this person move to another company it's a new contact of a company. Check what Odoo says:

2016-03-03_22-08-14

This is not enough:

I recall a module that would allow you to view what a partner was being follower of, so that you could quickly remove him the privileges related to his previous company

What about mailing list, event registry, surveys, opportunities, meetings, calls, ... ?

If you try to change this it doesn't look to be a general approach in my opinion but specific one.

@pedrobaeza
Copy link
Member

You mustn't change the company of the contact. You create another contact with the proper data (for sure this person will have a new email, and maybe a new phone number), and deactivate the old one.

@pedrobaeza
Copy link
Member

Closing this one following the discussion.

@pedrobaeza pedrobaeza closed this Nov 13, 2016
BT-dherreros pushed a commit to BT-dherreros/sale-workflow that referenced this pull request Apr 29, 2019
Syncing from upstream OCA/sale-workflow (12.0)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants