1. Mailing Lists
  2. Accounting
  3. Re: Feedback Accounting Blog

Accounting mailing list archives

accounting@odoo-community.org

Browse archives

Re: Feedback Accounting Blog

Avatar

Re: Feedback Accounting Blog

by Ferdinand Gassauer <ferdinand.gassauer@camptocamp.com> - 13/11/2015 11:59:08
On 2015-11-13 11:23, Fabien Pinckaers wrote:
<blockquote cite="mid:CANRftauJ+Oc_GhjWqm61qGonHmos51iw-1JxsnjHLc_JRD8Jqw@mail.gmail.com" type="cite">
Feedback on this blog: https://odoo-community.org/blog/oca-news-1/post/odoo-9-accounting-oca-28

1/ Removal of fiscal year

Removal of fiscal years has a lot of advantages: no more painful opening of fiscal years (I would say that 30% of our customers call us in the beginning of a fiscal year because they could not invoice), easier comparison mechanism, performance improvement, better lock-in system, efficient multi-company settings. 

There is only one little drawback (*) in the current implementation: the user has to select date ranges when doing a report for complex fiscal year (>12 months). It's a rare use case and it takes just 30 seconds to set custom dates on a report.

Trying to put back fiscal year would be a HUGE mistake. It may complexify the code and the user experience.

If you want to solve the drawback, the small improvement I would suggest it to just save the current report date selection so that if you launch the report again, it uses the same selection.

(*) or is there other drawbacks?
  • closing periods ? - not allowing to post items
    BTW  closing should be on journal level to allow partial closing
  • it's much faster (and safe) to select periods / fiscal years for reports/lists. New users may not be aware of irregular fy's.
    IMO it would be sufficient to have this period/fy as structure to select dates omitting period_ids in journals.
    camp to camp reports automatically select the correct previous fiscal year if the user wants a fy comparison report
  • we have attached monthly VAT-declaration and other period / fy related documents to period records.
  • planning is mostly done on a monthly basis.
  • printing meaningful commonly used report titles (although this could be probably derived from selected dates) 
    like "fiscal year 2015/16", "balance 2015"
  • see also comment below

<blockquote cite="mid:CANRftauJ+Oc_GhjWqm61qGonHmos51iw-1JxsnjHLc_JRD8Jqw@mail.gmail.com" type="cite">

2/ Limited access to journal items

We will not add this as we think it's too technical for the majority of the users who should use Journal Entries which is cleaner as you can work in it, and they reflect a real accounting document. Journal items view can only be readonly, which makes them useful.

But we understand that some "advanced" users may want to have it. 

Note that we have added (not sure it's merged yet, but it will be soon) the link from the general ledger report to open journal items related to the account. (currently the link is showed if there are more than 80 records, but we will make it appears even on low number of entries)
in my organisations the access to journal items (account_move_lines, account_analytic_line, stock_moves etc) is essential - especially if something went wrong.
accountants select account, fiscalyear and / or period to see all postings of the account.
For this reason we added period_id, fiscalyear_id to many of the journals.
if access to detailed information of the records can be achieved with the new reporting engine - it's fine.

<blockquote cite="mid:CANRftauJ+Oc_GhjWqm61qGonHmos51iw-1JxsnjHLc_JRD8Jqw@mail.gmail.com" type="cite">

3/ Removal of hierarchy

That's just a technical point of view. If you have a look at the accountant needs: they need hierarchy in P&L, Balance Sheet, Chart of Accounts...

All reports in Odoo have a hierarchy (P&L, BS, Chart of Accounts), but this way of managing the hierarchy is cleaner than a simple parent_id approach. In v8, we only had a hierarchy for Chart of Accounts --> how do you manage the hierarchy of P&L, ...? In v9, every report can have its own hierarchy.

4/ Basic reports

Yes, some reports can be improved.

5/ What's the use case?

Since v9, you don't need to use the reconciliation mechanism anymore (réconciliation comptable). The system is designed around the bank reconciliation. (rapprochement banquaire). Or, only for very specific use case. 99% of the reconciliation will be on the bank statement or the invoice directly, and this is a good thing, just a different way to work. (BTW the reconciliation wizard is still there)
unfortunately (or luckily for you) you missed complex business cases.
the other day I had to reconcile 500+ items. (which in v 6.1 didn't work because the balance was -0.00  and the system wanted to post the difference which was 0 and hence not allowed - will the new Monetary fields provide BCD ? )
<blockquote cite="mid:CANRftauJ+Oc_GhjWqm61qGonHmos51iw-1JxsnjHLc_JRD8Jqw@mail.gmail.com" type="cite">

For visualization, I do agree we should add some information on the journal entry to zoom to reconciled documents (invoices, other payments, ...)

6/ Payments

What is the nightmare with payments in currencies?

But I do agree that we should add a multi-suppliers payment feature. (If I am not wrong, technically, the feature is there but not activated as I have seen it working before the release; but it does not seems to work anymore)



Thanks for the feedback and effort to improve Odoo,

-- 
Fabien

_______________________________________________
Mailing-List: http://odoo-community.org/groups/accounting-28
Post to: mailto:accounting@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe


Reference