you account.invoice object really has "foo (compX)" in its partner_id.
Yes, but only if you don’t link the lead to a Customer and have OpenERP create one for you. partner_id of *contact* stored in database for invoice. [account_invoice] as well as for opportunity. [crm_lead]; quote/sale. [sale_order] and [sale_order_line]; delivery. [stock_picking]; stock move. [stock_move]; if you group or analyse invoices by partner. foo and bar two contacts of compX won't be grouped together. Yes - this is what I observe also. If OpenERP would not let you sell to Contacts at companies, this problem would go away also I think. Strictly B2B or B2C, not a combination of selling to a contact at a business – which causes the problem. they indeed changed the accounting move generation to relate them to compX instead of foo Yes - this is what I observe also. partner_id of *company* stored in database for journal items. [account_move_line] partner_id of *company* stored in database for journal entry. [account_move] That is at least confirmed receivable from foo and compX are correct. Yes - this is what I observe also. the partner balance of the *company* is for the invoice amount. the partner balance of the *contact* is 0. If you want to create an arbitrary payment from compX and then relate it so some of the opened invoices it will be harder. I didn’t have a problem with a payment from the Invoice (*company* makes the payment, not the contact) or with an arbitrary payment (including when I created other open invoices for the *company* – all open invoices were shown). when the *company* partner_id is entered to make a payment, the open invoice from the contact is listed. when the *contact *partner_id is entered to make a payment, no invoices are shown. If you have report that try to plan you cash management not only based on the existing moves but also based on draft invoices or even confirmed purchase or sale orders. Then you won't be able to analyse this by customer or supplier properly. Yes - this is what I observe also. Get around this by not selling to contacts. So what do you think? I need to do some more research. If I stop Invoices from being created for Contacts in the first place, the problems won’t be problems. I read that Fabien thinks this is incorrect, but it would be easier to add an ‘ATTENTION: CONTACT NAME’ line on the PDF than to refactor the searching and grouping. Ray. *From:* Raphael Valyi [mailto:[email protected]] *Sent:* Friday, April 05, 2013 1:01 PM *To:* Ray Carnes *Cc:* Gustavo Adrian Marino; openerp-community *Subject:* Re: [Openerp-community] IMPORTANT: OpenERP v7 and company contacts management On Fri, Apr 5, 2013 at 4:51 PM, Ray Carnes <[email protected]> wrote: Invoices for Contacts will cause problems for my customers. If that is happening I want it fixed and can get them to all log the same bug. I can’t get OpenERP to Invoice a contact? How can I reproduce this so I can ask them to report it? Ray. Ray, it's exactly what I meant by "they started changing the code to at least associate the accounting moves to the company and not to the contact" you account.invoice object really has "foo (compX)" in its partner_id. That is if you group or analyse invoices by partner. foo and bar two contacts of compX won't be grouped together. If you want to create an arbitrary payment from compX and then relate it so some of the opened invoices it ill be harder. Now, yes, in order the bug to be less manifest, they indeed changed the accounting move generation to relate them to compX instead of foo. That is at least confirmed receivable from foo and compX are correct. Now, if you read carefully what I'v written they fixed only a little part of the problem. Further Nhomar stated: https://www.evernote.com/shard/s158/sh/40828d76-d94a-4f44-bdb5-9c0336f55a52/fe43fe77c401e9f3bdf95982a4b0a878 "6.A.- Inconsistency, and bad approach, the partner_id in the invoice MUST be the same of the account move line." which is what we have here. If you have report that try to plan you cash management not only based on the existing moves but also based on draft invoices or even confirmed purchase or sale orders. Then you won't be able to analyse this by customer or supplier properly. This is what I call a terrible shot in the feet for reporting for no usability benefit compared to the solution I proposed instead. Is there more doubt? What about you tax collection in the USA given this is really "foo" the contact on your invoice? Are you able to apply the proper account matching? For intrastat invoices in Europe or invoices in a Brazil this doesn't work today if you invoice a contact as the system let's you do or even does for you such as in this case. So what do you think? -- Raphaël Valyi Founder and consultant http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi> +55 21 2516 2954 www.akretion.com
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
