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.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related.
Learn more.
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.
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".
> 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.
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.