Odoo is the world's easiest all-in-one management software. It includes hundreds of business apps:
CRM | e-Commerce | Accounting | Inventory | PoS | Project management | MRP | etc.
On v6.1 one partner could have several addresses (invoicing, delivery). Is this still possible in v7?
On version 6.1 one partner could have several addresses (invoicing, delivery). Is this feature still possible in version ? It does not seems possible so it looks like a big regression.
In terms of features related to partners, nothing has been lost between v6.1 and v7. Not only the new model in version 7 allows to manage more business situations (B2C) but everything you could do with
res.partner.address in version 6.1 is still possible in version 7 with the unified table:
- You can still have several addresses per companies
- You still have the "address type" field on the address/contact (invoice, shipping, ...)
- You can still have several contacts per company or address
- You still have a tree hyerarchy between partners (subsidiaries)
- You still have the exact same information on the Sale Order (ordering contact, delivery address, invoice address)
- You still have the exact same information on the PO
- You still have the exact same information on the invoice but with one field less 
You may have missed it because these features are not visible by default. To activate this feature, you have to activate the multi-address option:
- Go to
Settings / Configuration / Sales
- Check the option: "Allow a different address for delivery and invoicing".
This will add more fields on documents (e.g. invoice and delivery address on sale oder) and some fields on a contact/address of a company (e.g. the address type)
The only regression introduced in version 7 is about the base_contact module that has been deprecated for different reasons:
- this module did not worked correctly with the others modules of OpenERP which made it unuseable in a lot of apps
- 80% of the companies who installed base_contact did not needed it. They installed it because they installed a module that depended on it (like event) or because they needed to manage contacts (people).
- Only 20% of the companies who installed base_contact needed it's main feature: being able to manage one person that work for several companies.
For companies that used base_contact in production (including ourself), we noticed that even when we had the same people working for different companies, the users created several contacts mainly because they did not understood how to use base_contact efficiently. --> it was way to complex to work in the real life, with lambda users.
As usual, as part of our OpenERP Enterprise service, when there is a big regression, we try to find an alternative. So, for our customers that migrate from a v6.1 using base_contact to v7, we developed a base_contact adapted to v7. (with the same pros and cons that the one in v6.1)
In terms of business flows, it works more or less like in version 6.1:
I do a quotation for a contact, working for a company (B2B) or not (B2C)
- OpenERP proposes an invoice address (another contact on this company)
- OpenERP proposes a delivery address (another contact on this company)
The invoice is labelled at the name of the invoicing contact that could be the company itself or a specific contact working for this company, some example:
- Accounting Dept, Company XYZ or
- John Doe, Company XYZ
The journal entries are created at the name of the company, not the contact
We just noticed a bug in the journal items generated automatically from delivery orders that are labelled at the name of the delivery contact, not the related company. This should be fixed soon.
But there are a few drawbacks that we have to fix
- It's not possible to create a company with different address directly from the company it self. The one2many_kanban only allows to create contacts having the same address than the company. So, you have to create several record to create one company with several address. We already started the task to improve this in version 8.
- The search view is not simple for companies having a lot of addresses or contacts. If you search the name of a company, it shows you all companies matching your query as well as all contacts related to this company which gives too many records. We will change so that if you search for a company, it returns only this company and not all it's contacts (but there is an option in the search to get all contacts)
After a gool deal of searching Q&A, this post seems to be the right place to have an answer.
Let's say you have a "big customer" (nike, amazon...but let's call it OpenErp) but different companies because you don't want the many contacts from OpenErp France or Spain to be messing around with the many contacts from OpenErp England or Italy. And you also want to be able to do sales stats and reports on each company/country separately.
Furthermore, let's say Invoicing for all companies is handled by OpenErp Germany.
If you create a "fictitious" contact for dealing with the invoice address, as it can only be attached to one company, you have to create as many contacts for all invoicing address ?!?!
Am I missing something ? How do you do handle this quite common B2B situation ?
Beacuse I'm a little confused here while reading possibilities ("tree hyerarchy between partners / subsidiaries") and drawbacks ("you have to create several record to create one company with several address").
Looks to me like a case of violoation of Enstein's principle : Make it as simple as possible, but not more...
I think OpenERP got carried away in the effort of making the system foolproof and now it's lost some of its more powerful functionnality.
Maybe V8 will bring things back together.
About This Community
This platform is for beginners and experts willing to share their Odoo knowledge. It's not a forum to discuss ideas, but a knowledge base of questions and their answers.Register
Odoo Training Center
Access to our E-learning platform and experience all Odoo Apps through learning videos, exercises and Quizz.Test it now
|Asked: 3/4/13, 3:55 PM|
|Seen: 4731 times|
|Last updated: 5/20/15, 6:06 AM|