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 and 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 [1]

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.

In terms of useability, the model introduced in version 7 is a strong improvement. In all the tests we did, lambda users and customers in production feel much more confortable with the version 7.

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)

[1] In v6.1 you had res.partner and res.partner.address, in v7 you just have the equivalent of res.partner.address which is not a reduction of information as the res.partner was directly related to the res.partner.adress, so we removed something redundant which is good technically and in terms of useability)