- Create an expense sheet
- Line 1 is 500
- Line 2 is -200
- The total is 300 => a payment of 300 is made
When the payment is validated, the expense is not set as paid.
In v10, one expense line = one account move. In order to know if the
expense is paid we check that each account move is completely
reconciled. The account move of 500 is never completely reconciled by
the payment of 300, so the expense stays opened.
This simply cannot be supported in v10, since each expense line is
handled in a separate account move.
opw-740492
When posting journal entries for an hr.expense.sheet with several expense lines
(by clicking on the button "Post journal entries"), all the account move lines
created for the same sheet must be linked to the same account move because
the model hr.expense.sheet has just a field "account_move_id" to access all the entries
(by clicking on button "Accounting Entries")
This commit reverts f97eb0ac2b
opw:715523,709930,725798,716239
When posting journal entries for an hr.expense.sheet with several expense lines
(by clicking on the button "Post journal entries"), all the account move lines
created for the same sheet must be linked to the same account move because
the model hr.expense.sheet has just a field "account_move_id" to access all the entries
(by clicking on button "Accounting Entries")
opw:715523,709930,725798,716239
- Create an expense with a tax
- Validate and post entries
3 AML are created, one on the expense account, one on the account
payable, one for the tax. However, the AML of the expense account is not
linked to the tax, and therefore does not appear in the reports.
opw-715488
- Create a partner who is a contact of a company
- Associate this partner to an employee
- Create an expense for the employee, validate and post entries
The AML created are linked to the company, not the partner.
Since the bank account account is registered on the partner, and not the
company, this is more logical to link the AML with the partner.
opw-724550
- Create an expense of 0.00, validate
- The expense can never be set as paid since it's not possible to create
a payment of 0.00.
An expense of 0.00 still makes sense in the following use case.
An expense is paid by salary before the expense is actually made, i.e.
I get 1000 EUR to redecorate my homeoffice, I get the money beginning of
the year. After that I want to book expenses against the initial payment
until the 1000 EUR is gone and I would like to make use of the expense
workflow to approve the costs.
opw-710695
* ccd6fc6 already fixed the bug of the account move for expenses with more than 1 taxes but the taxes were not used.
Adding in `_prepare_move_line` to be included in the created move line.
* added Contributor License Agreement
Closes#12849
Steps to reproduce:
- Create one (or several) expense lines
- Submit them to the manager (create the expense sheet)
- Approve the sheet and post the entries
- Delete the created and posted sheet
Bug:
- The expense is deleted but the accounting entries are still in the database
- The expense lines are in "To submit" and you can submit to manager again and
generate a new report and therefore new accounting entries...
Fix:
It is not allowed to delete posted expense.
opw:692323
Since commit dabf82870a, the expense sheet now creates one account.move per expense, so there is no point in grouping per journal. Moreover, the account_move_id m2o is not relevant anymore for expense sheet having more than one line. That's why it is now replaced by a button
This grouping was causing problem at the time of bank statement reconciliation, if the expenses were set as already paid by the company, since we had only one account.move related to several bank statement lines although the DB structure wasn't allowing such a case (the link was made as a m2o from account.move to account.bank.statement.line where a m2m would have been needed).
This is required in order to have those bank journal items appearing afterwards in the bank statement reconciliation widget (blue line) for reconciliation.
Force the name to the default value '/', to avoid an eventual 'default_name' in the context to set it to '' which cause no number to be given to the account.move when posted (which is totally wrong).
Nicolas Martinelli