Hi Nhomar,
Thank you very much for your bug link and opw conclusion. every information
I need is clearly explained there.
My point is BOTH the comments of 9510 and 9265 should including "for more
information, see bug 1154270 "
I like your word like " this things happend even in the best families :-) "
Great thanks again
------------------
Jeff Wang | [email protected] | 18016291663 | 02158980787
@OpenERP_Jeff "As simple as possible, As complex as needed"
Maintainer of Open ERP china community
http://www.openerp-china.org
------------------ Original ------------------
From: "Nhomar Hern??nde";<[email protected]>;
Date: Thu, Oct 10, 2013 00:26 AM
To: "jeff.wang"<[email protected]>;
Cc: "[email protected]"<[email protected]>;
Subject: Re: [Openerp-community] Community, Please pay more attention to
thechanges of OpenERP core
Hello Jeff.
We as community don't have inherence over the work done by OpenERP.
In this specific bug we are the protagonist of the commit (bad one) and the
revert (because leak of communication.
THe bug report is:
https://bugs.launchpad.net/openobject-addons/+bug/1190103
Duplicated from
https://bugs.launchpad.net/openobject-addons/+bug/1154270
The revert is due to a backguard compatibility with some belgium concepts
solved with this 0 lines.
Let share with you the answer we receive from the OPW:
***********************
Hi there,
i'd like to explain this. But first let me concede that fact that we (read
"I") have to explain this again and again is probably the normal consequence of
a poor design or something like this. If we get time to refactore the
accounting, this point will more than probably be addressed, but anyway... it's
not the subject.
These 0 lines are useful AND needed. They are really important and removing
them would lead to errors in the tax report. Indeed, in the account.move.line
object, there are 2 important concepts that are mashed up:
1) accounting stuff: debit, credit, journal and account.account..
2) tax stuff: tax amount and tax code
Both concepts are independent, and a line with debit = credit = 0 is meaningful
if the tax amount and tax code aren't empty.
Let me take a real example of a belgian tax VAT-IN-V81-21:
for a refund of 100?? using this tax, the information to consider in the tax
report are (legally, you have to provide and show these information):
*tax code 81: -100
*tax code 85: 100
*tax code 63: +21
Where the accounting stuff is:
*product account: 100
*tax account: 21
Now read me carefully: 2 lines of accounting stuff to consider, and 3 lines of
tax stuff: how can we put all this together in the same object
(account.move.line) knowing that we have on the account.move.line only a single
field for the tax code and another for the tax amount. So for a single
account.move.line, you can only record one of the three lines of my tax stuff.
Do you see my point?
That's the reason why it exists lines with debit = credit = 0, and why it is
legal in OpenERP. And if you look carefully on the video given in the bug
report, it appears that the "0-line" pointed is clearly having tax information
on it (tax code and tax amount columns are filled). In our example, OpenERP
will more likely create something looking like this:
*product account: 0, tax code 81: -100
*product account: 100, tax code 85: 100
*tax account: 21, tax code 63: +21
But as i said, the 2 concepts are independent and you'd have the same results
in your tax report with
*product account: 0, tax code 85: 100
*product account: 100, tax code 63: 21
*tax account: 21, tax code 81: -100
So i hope, i made it clear. I'm gonna ask to update the status of the bug
reports into the proper state (invalid) with a proper explanation, + the revert
of patch 9265 that was by mistake accepted on stable version (although it was
only hiding 0-lines, not preventing their appearance i do not see any good
reason to accept this hack anyway).
Thanks for your comprehension
Quentin
*************************
We decide internally take the Quentin's answer as valid and we will improve
our localizations until this behavior can be refactored.
FYI:
We report the bug in June, and we exchange a lot of discusions with OpenERP
support team, sometimes is not humanly possible mantain everything updated.
II ask apologize because i think you are right, but it is better manage with
bzr pull instead update qith nightly it give you more control.
Just as experience, You are right, but this kind of bugs will continue
happening I think the request should be re-directed to OpenERP SA if they share
the "conclusion" of the OPW report it can help a lot.
BUT BTW it is a known issue and we need to be prepared, as you saw it was not a
light decision it was so discussed __before__ and after the merge, I think this
things happend even in the best families :-)
IMHO it brings "more" problems NOT MERGE As soon as the problem is solved,
because everyone of us can not see all the solutions, but the improvement
should be just copy and pasting the "conclusion" of the solution in the commit
message for now.
We have several examples where we don't ask for the merge until we test
internally very well, but it is far from 15 minutes my friend.
Regards, I hope it helps you understand this specific case.
2013/10/9 jeff.wang <[email protected]>
Hi All,
I am very glad to see that may community projects cover great modules become
more active, but I really worry about the core package now.
We know, the package openerp.com build every night is the first sight our
potential customers know what OpenERP looks like. the quanlity of this part
shouldn't be technically "not dump in runbot", it should be functionally "every
changes are reasonable". So every community user should pay more attentions to
the changes of openerp addons/server/web everyday, "more eyeballs, less bugs",
correct me if I am wrong. it costs about 10-15 minutes for a quick code review,
but openerp community's future need this time funding from each member.
I write this mail because I begin to review the changes everyday from 2
months ago, I do found a problem:
" Not all merged commit bind to a specific bug report, especial the opw
ones."
When I see that change, I have to guess what happened without this change.
50% times I can know that by some 10 minutes research, 50% times I don't know
why this change is introduced. by the way, I have to say Oliver Dony always
show best practice in the commit comments: 5W1H, and also the commits bind to
specific bug, I can see who report it, what is the result he want, what is the
result he got, how to reproduce at other's side... after all, I have to say,
review the code changes in this 2 months cost me more time than I think it
should.
give you a sample, yesterday we have this change
http://bazaar.launchpad.net/~openerp/openobject-addons/7.0/revision/9510
[FIX] account: revert commit 9265, show every invoice line in the list
view and do not force domain on it to remove 0 debit/credit lines
so I go to
http://bazaar.launchpad.net/~openerp/openobject-addons/7.0/revision/9265
[MERGE] [FIX] OPW 590066 account: remove accounting information lines from
Journal items
You know my English is very poor, I really cannot understand if "remove
accounting information lines" equal to "remove 0 debit/credit lines"
I just want to know the reason why this domain need this ['|',['debit',
'!=', 0], ['credit', '!=', 0]] value from 2013-06-24 and never need it from
2013-10-08. actually I want to know what opw 590066 says 3 months ago and why
it's wrong yesterday.
Furthermore, we ALL are building solution to end users base on openerp core
function, keep every merge to this repo touch everybody's eyeball, IMPO this is
the open soure way. for developers, I suggest every merge request should link
a bug, if there is none, create one. so that at least somebody can discuss
this change later, or ask for an explain about why this change is needed.
------------------
Jeff Wang | [email protected] | 18016291663 | 02158980787
@OpenERP_Jeff "As simple as possible, As complex as needed"
Maintainer of Open ERP china community
http://www.openerp-china.org
_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openerp-community
More help : https://help.launchpad.net/ListHelp
--
--------------------
Saludos Cordiales
Nhomar G. Hernandez M.
+58-414-4110269
Skype: nhomar00
Web-Blog: http://geronimo.com.ve
Servicios IT: http://vauxoo.com
Linux-Counter: 467724
Correos:
[email protected]
[email protected]
twitter @nhomar_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openerp-community
More help : https://help.launchpad.net/ListHelp
