Peter Langenberg (Agaplan Belgium) 2012/9/11 James Jesudason <[email protected]>
> 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 > <[email protected]> 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. > I think for legal reasons it's absolutely necessary that you cannot change an account code when journal entries have been posted. It's possible that there are already printed journals - balances and so on and then you just change the account code. For accounting you just have to create a new account and put the old one to zero by miscellaneous journal. > > > > * 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 > Peter Langenberg (Belgium) : Agree. > > > > * 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 > Peter Langenberg (Belgium) : Agree 100 % > > > * 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. > Peter Langenberg (Belgium) : Agree > > > - 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 > Peter Langenberg (Belgium) : Agree d > 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 > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-expert-accounting > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openerp-expert-accounting > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-accounting Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-accounting More help : https://help.launchpad.net/ListHelp
