Making a bank account reconcilable is a very common mistake, and leads to confusing and useless data (the move lines made on this account) to be displayed in the reconciliation widget. With this commit, we make sure the user cannot make this mistake anymore.
- Set up a 10 % tax with a 'Tax Due' as 'Based on Payment'
- Create a bank statement of 110, Reconcile
- Create a new AML for the reconciliation using the mentioned tax for an
amount of 100
- Validate
The tax amount does not appear in the Generic Tax Report.
This is a specific case where the reconciliation process creates the
payment itself. Therefore, the tax amount should appear in the report.
To do so, we explicitly send the `tax_exigible` value on the AML, and
propagate it to the tax line.
opw-1858492
Since revision 4acec418ce
it was no longer possible for an accounting adviser
to create taxes.
This is because when creating a taxes,
as the related field `hide_tax_exigibility` wasn't readonly,
it attempted to write on the field
`tax_exigibility` of the model `res.company`,
and the adviser do not has that access right.
There is no reason for this field not to be readonly,
as it is used only to compute an invisible attrs
for the tax form view.
opw-1846265
* In account.journal model, the domain of bank_account_id field was incorrectly comparing the partner_id with a res.company object
* When modifying the company of a bank journal, the company of the related res.partner.bank was changed without checking if it had a company and also its partner (account holder) was not changed.
Was PR #23480. Courtesy of Miquel Raich (Eficent)
Changing the next sequence number on a journal requires having Administration/Settings access
rights. However, this feature should be available for advisors.
- github issue: 23352
Before this commit, when reconciling with a tax included line,
the journal entries were wrong as the amount taken into account was the one that was **already** computed with tax
e.g:
TAX: 20%
amount of the line (tax included): 1
tax amount: 0.17
base amount: 0.83
what was sent to the server was the basea amount, and since python re-computes the taxes
it reapplied tax included 20% on 0.83 instead of 1
After this commit, we send the right amount to the server,
at the small price of semantics change in the meaning of "amount"
OPW 783933
closes#21189
Suppose some taxes with the same sequence:
The tax are not computed in the same order in POS and SO/INV.
This is wrong in case of multiple taxes affecting the base.
-opw: 779498
- Create a tax:
Fixed amount: 10
Price included
- Add it by default to a product costing 100
- In a SO/PO/Invoice, add 2 units of the product
The total price is 210 instead of 200.
opw-779696
Suppose a bank statement of 11$ and a tax 10% price_included.
The result shown by the reconciliation widget is
D | C
11 |
| 10
| 1
that is correct. However, after clicking on validate, the result is
D | C
10 |
| 9.09
| 0.91
because the taxes are recomputed python-side and the values of the account.move.line are
amount = 10, tax_id = 10% incl. Then, the tax is recomputed on 10 instead of 11$.
-opw: 776644
Christophe Simonis