@odony

> We have considered all possible options, and came to the following 
> conclusions:
> 
>  - OpenERP accounting is specific and does not need 'rounding moves' to be 
> able to validate a multi-currency invoices with everything balanced (as 
> opposed to other accounting systems that perhaps need it).

I hope that OpenERP's accounting is not so special, or we are in big trouble. 
There is nothing to invent, unless we are reinventing the wheel. All accounting 
entries are to be balanced. I hope that any accountant even with basic 
knowledge will agree with me.


>  - Accounting is a very sensitive and complex topic, but our goal is to try 
> keeping the main process as simple as possible, and avoid bloating it with 
> all kinds of exceptions and specific behaviors.

Agree in that it is sensitive, but completely disagree that generic things, 
like with this bug should be implemented in localization modules. Ask any 
analyst or accountant who have been working with major ERP/financial packages 
and they will say you that there is no other way to solve the problem described 
in the bug report! If you do not see this, I am sorry for you.


>  - Specifically, we know that in many countries the law lets you handle these 
> situations as you see fit. For example some "legally defined" charts of 
> accounts do not even include dedicated accounts for "rounding adjustments" or 
> "penny difference" as they were named here.

There is nothing specific about it, the cause for the problem is in pure 
arithmetic, the scope acounting (not the business process, like you want to 
deal with it by reconciliation), the solution is like it has been done many 
times before us, because there is no other option to solve it.


>    This is why OpenERP will only implement the basic logic that is common to 
> everyone in multi-currency.


Sorry this is basic logic, if we want creating accounting moves automatically.


>  - I repeat: we want to be very clear for community and customers, OpenERP 
> does not make errors in computing multi-currency invoices, and all moves are 
> balanced.


No they are not unfortunately.


>  - Now for countries or companies that absolutely insist that the "penny 
> difference" or "rounding adjustment" must be processed by the invoice itself 
> and not to be handled by the normal reconciliation process (as for exchange 
> rates write-offs), we will offer the same sort of solution as usual: this 
> must be done in a separate module.


This is not about reconciliation, because reconciliation has nothing to do with 
accounting itself. Reconciliation is a business process, not the accounting 
process. It could not solve the unbalanced accounting move, because it just 
connects several accounting entry lines from several different moves. Some 
companies even not implement reconciliation as such (often they are the 
companies who use ERP systems, not the small ones), (again) because it has 
nothing to do with accounting. And when we are creating invoice, most likely, 
there is no other accounting entry present yet to make reconciliation against.

@ael

> I hope that the migration from version 5 to version 6 will not be like that 
> of version 4 where the integrator and the customer will be held hostage to 
> either pay to move or keep the old version 


There is nothing painfull if you use our data migration module. Many things in 
OpenERP has been done crippled not by lack of knowledge, but by intention to 
beat the money from community.

These are (not comprehensive list):
* inability to add new report from UI, you have to pay for proprietary piece of 
software to solve it;
* migration process - long ago it has been promised to release the migration 
scripts, nothing has been released;
* shared funding projects, which, BTW, have long ago been refunded to editor, 
anyway stay unreleased.

OpenERP SA, just keep up with the policy, raise mistrust!




-------------------- m2f --------------------

--
http://www.openobject.com/forum/viewtopic.php?p=59564#59564

-------------------- m2f --------------------


_______________________________________________
Tinyerp-users mailing list
http://tiny.be/mailman2/listinfo/tinyerp-users

Reply via email to