openerp-expert-accounting team mailing list archive

[James Jesudason <james.jesudason@xxxxxxxxxxxxx>]

I agree that this is necessary, and the lack of validation has led to
a lack of confidence in OpenERP as a reliable accounting system. I've
added some additional comments below:

On 11 September 2012 10:46, Frédéric Clementi
<frederic.clementi@xxxxxxxxxxxxxx> wrote:
>
> Our experience with accounting on OpenERP shown us that the system is,
> today, not trustable enough since it allows user to do many mistakes.

Agreed - this has been confirmed by our Finance team using OpenERP.

>
> * Account :
>...
> - Forbid to modify the code of an account if journal entries have been
> already posted on this account.

I don't understand this. Does that mean that you cannot restructure
the chart of accounts after journal entries has been posted to an
account? That doesn't make sense to me.

>
> * Reconcile
> ...
> - Force account with type 'recevable' or 'payable' to have a partner on
> journal entry
>
This is something that our Finance team has asked for as well


> * Date/Period
> - Forbid the possibility to post a journal entry on the wrong fiscal year in
> the core of the source code.
> - Forbid the possibility to get date outside the periode : this flexibility
> given generates too many problems (ie: filters or journal entry posted on
> the wrong month or worst  wrong year). This features already exists
> (checkbox in journal) -> we want to hide this option.
>
Agreed

> * Journal entries
> - Forbid the modification / deletion on a automatic journal entries (ie:
> generated by an invoice, bank statement, voucher, cash,... ?)

Agreed - we have seen user errors arise from people modifying journal entries.

> - Forbid to post any entries except on journals with type 'general' in order
> to force users to good practices (create invoices and use banks statement
> for ex.)

Agreed


Also, I'd like to see tighter validation on the use of the 'Currency'
and 'Currency Amount' fields as it is possible to enter one without
the other, which is incorrect. This then causes a problem with FX
revaluation, which is difficult to track down.

Also, it is possible to enter a Credit amount with a positive
'Currency Amount', or a Debit with a negative 'Currency Amount'. We've
had to add validation to catch this error, but it should be in the
core code.

Related to this, I think that the journal entry screen needs to be
improved. The fields are in the wrong order for data entry - users
should enter the date, Currency and Currency Amount which should
automatically calculate the Debit/Credit amounts using the exchange
rate for that day. The user can then override the Debit/Credit amount,
if necessary.

James