Tryton - Issues

 

Issue7450

Title Remove default accounts from journals
Priority feature Status testing
Superseder Nosy List Timitos, ced, pokoli, reviewbot
Type feature request Components account, account_invoice, account_statement
Assigned To pokoli Keywords review
Reviews 50391002, 45551002, 45561002
View: 50391002, 45551002, 45561002

Created on 2018-05-21.16:29:29 by pokoli, last changed by reviewbot.

Messages
review45561002 updated at https://codereview.tryton.org/45561002/#ps140001
review45551002 updated at https://codereview.tryton.org/45551002/#ps220001
review45561002 updated at https://codereview.tryton.org/45561002/#ps120001
review45551002 updated at https://codereview.tryton.org/45551002/#ps200001
review45561002 updated at https://codereview.tryton.org/45561002/#ps100001
review45551002 updated at https://codereview.tryton.org/45551002/#ps160001
review45561002 updated at https://codereview.tryton.org/45561002/#ps80001
review45551002 updated at https://codereview.tryton.org/45551002/#ps140001
review45561002 updated at https://codereview.tryton.org/45561002/#ps60001
review45551002 updated at https://codereview.tryton.org/45551002/#ps120001
review45551002 updated at https://codereview.tryton.org/45551002/#ps100001
msg41317 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2018-06-08.09:10:33
I'm wondering if we should not have only a 'account.reconcile.write_off' model in account module and an 'account.invoice.payment.method' model in account_invoice module. The 'cash' is not used in account module.
I think this will make more sense to the user as we could precisely define where they are used.
review45561002 updated at https://codereview.tryton.org/45561002/#ps40001
review45551002 updated at https://codereview.tryton.org/45551002/#ps80001
review45551002 updated at https://codereview.tryton.org/45551002/#ps40001
review50391002 updated at https://codereview.tryton.org/50391002/#ps40002
review50391002 updated at https://codereview.tryton.org/50391002/#ps40001
review45561002 updated at https://codereview.tryton.org/45561002/#ps20001
review45551002 updated at https://codereview.tryton.org/45551002/#ps20001
New review45561002 at https://codereview.tryton.org/45561002/#ps1
New review45551002 at https://codereview.tryton.org/45551002/#ps1
msg40954 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2018-05-23.10:27:54
> I think we should go further and remove the accounts from the journal.

That makes sense for me. 

> For me, they are only used for cash and write-off which indeed should probably by replaced by a similar design to statement journal (but probably with a less confusing name which does not include "Journal").

Agree about creating a new model for the Cash Journal. About the name I think we should use something like "Payment method" as I see that cash journal is only used for paying invoices. 

For write-off journals I'm wondering if won't be better to completly remove the write-off type and allow any kind of journal on the write-off wizards (like we do for example on payment clearing). On the wizard we should also ask for the account that should be used for the write-off. Indeed the writeoff API already accepts an account and fallbacks to the journal one if not set.
review50391002 updated at https://codereview.tryton.org/50391002/#ps20001
New review50391002 at https://codereview.tryton.org/50391002/#ps1
msg40808 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2018-05-21.16:55:49
I think we should go further and remove the accounts from the journal.
For me, they are only used for cash and write-off which indeed should probably by replaced by a similar design to statement journal (but probably with a less confusing name which does not include "Journal").
For the migration, I think there is no choice than requesting to manually create/set the new "journals".
msg40807 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2018-05-21.16:40:15
Here is review50391002.

I decided to not make fields optional and fall-back to current journals accounts if not defined. I'm wondering if it will be great to make the fields required and migrate the current values from the journal default accounts. The main problem with this approach is I'm not sure if we can do a migration as this is a multivalue field and the migration will probably not work if extra criteria has been added to the MultiValue pattern. We can also warn the user to manually migrate the data so they can clean the extra journals if they wan't.

Any comments will be much appreciated.
msg40806 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2018-05-21.16:29:28
Currently the statement move lines are created using the accounting journal default credit/debit account. This forces the user to create an accounting journal for each account which adds unneeded complexity.

In a database with multiple companies, this is more complex to manage as the accounting journals are shared between all the companies but the statement journals are company specific. So you end up with a lot of accounting journals created only for statement usages that are not needed on all companies.
History
Date User Action Args
2018-08-08 12:38:57reviewbotsetmessages: + msg42799
2018-08-08 12:36:11reviewbotsetmessages: + msg42797
2018-08-02 15:41:22reviewbotsetmessages: + msg42603
2018-08-02 14:33:21reviewbotsetmessages: + msg42601
2018-07-06 17:50:53reviewbotsetmessages: + msg42092
2018-07-06 17:50:43reviewbotsetmessages: + msg42091
2018-07-04 10:50:26pokolisetstatus: in-progress -> testing
2018-06-22 15:05:52reviewbotsetmessages: + msg41594
2018-06-22 15:05:44reviewbotsetmessages: + msg41593
2018-06-14 12:27:02reviewbotsetmessages: + msg41407

Showing 10 items. Show all history (warning: this could be VERY long)