openerp-community team mailing list archive

[Ray Carnes <rcarnes@xxxxxxxxxxxxxxxxxxx>]

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:rvalyi@xxxxxxxxx]
*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 <rcarnes@xxxxxxxxxxxxxxxxxxx>
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