The previous version of this verification was buggy and inadequate. It was for example impossible to post an account.move before the tax lock date, even if it did not impact the tax report in any way.
closesodoo/odoo#36289
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before that, when removing a tax previously set on an account.move.line in tax_ids, the onchange event did not remove the corresponding tags from the base line, causing possible errors in tax report.
closesodoo/odoo#36283
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- create an invoice with only one line with a price of 91.56
- assign a tax of 15% using two 50% repartition lines to this invoice line
==> The total tax amount computed was 13.74; it should be 13.73.
closesodoo/odoo#35412
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
[IMP] l10n_*: don't define accounts or tags on tax repartition line templates anymore for 0% taxes
[FIX] account: remove old function used to migrate the former tax model, incompatible with the new one
There was an error in this tax's repartition. A tag was wrongly added to its base.
closesodoo/odoo#34245
Signed-off-by: Josse Colpaert <jco@openerp.com>
Before that, groups of taxes defined in l10n_es only defined tags on child taxes. This is wrong: base tags of a group of taxes should always be set on the group itself; children should only contain tax tags (at least, if their type_tax_use is 'none'). Indeed, the tax_ids field of aml generated for these taxes will point to the group, while tax_line_id points to its children.
closesodoo/odoo#34557
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When creating a new tax, before saving, the default-computed repartition lines had no country_id associated. It only 'appeared' when saving the record.
closesodoo/odoo#34359
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Such move lines can be created by POS, when closing a session. Because of commit https://github.com/odoo/odoo/commit/d3453f7d152d486cb5df01b4e40dbde57f59b49e , the cash basis entries are now created *after* reconciling everything (and not during reconciliation anymore). This causes multiple lines of the move created for the sessions to be reconciled together in case a refund was made (partial or not).
Solves ticket 2008085
closesodoo/odoo#34237
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Some taxes were declared as groups with some children having 'type_tax_use' different from 'none'. While this is totally correct from a technical point of view, this meant that the group actually had to stay a group in the new model introduced in 12.3. However, functionally speaking, it was not what was intended. We change that here for consistency with 12.3, and to ease the migration. Databases having installed l10n_ae's chart template before this commit will not be affected, and their groups will stay groups in the future (which makes no problem, they simply will be less easy to configure).
closesodoo/odoo#34189
Signed-off-by: Josse Colpaert <jco@openerp.com>
We now force tax repartition lines to use the same percentages for invoices and credit notes. Thanks to that, we are able to simplify the way manual modifications made on vendor bills' account.invoice.tax entries must affect the ones of the refunds created for them. This also prepares the code for the incoming big accounting revamping.
closesodoo/odoo#33577
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Before this fix, in 12.3, with taxes affecting subsequent taxes' base, tax_ids was used to store the taxes whose tax lines impacted current tax line's base. Before 12.3, this field was used to store the taxes whose base line has to be impacted by the current tax line.
This old behavior was changed by mistake. We restore it for consistency.
closesodoo/odoo#33471
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Before that, creating a tax without any repartition line with a company_id set in create() failed to create the default ones, because they did not receive the company they had to be created for (as 'company_id' was not passed to the default_get).
closesodoo/odoo#33617
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Consider the following use case:
- Two taxes:
-A: price included, affect base of subsequent taxes, 10%
-B: 15%, regular
- Create an invoice with a line applying A, then B, for 110€. Post it
- The following move lines are generated:
- base: 100€
- tax A: 10€
- tax B: 16.5€
Before this fix, line "tax A" only had the tax tags of tax A. It should also receive the base tags from tax B, in order to affect its grid total correctly in the tax report.
Also, tax_base_amount field used to be computed, but its computation was too simple, and most of the time wrong when doing advanced use of taxes like the one we defined above. It is now not computed anymore, and directly takes its value from the compute_all's result.
closesodoo/odoo#33420
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- Add repartition lines on taxes
- Link account tags directly to account.move.line; remove the tag_ids field from account.tag
- Add a new report engine dedicated to tax reports, directly generating account tags. It is called as an alternate mode of generic tax report, with a dedicated "Use tax grids" toggle.
>> The biggest change lies in the way the new tax report computes its values.
Everything is now aggregated directly using the tags set on the account move lines. Thanks to that,
modifying the configuration of a tax today will not impact the report for the previous periods anymore.
This is a big improvement, as it means the report will keep on reflecting the values that were submitted
to the state before, whatever the configuration change.
- Add an audit char field to account.move.line telling with tax grids are impacted by the line, with the corresponding amount
- Modify the behavior of cash basis taxes: the cash basis account is now used as the transition account, while the regular account given in tax declaration is used to store the final entry (it was the opposite before)
- Modify every l10n_* module in order to keep them consistent with these changes
closesodoo/odoo#32833
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Have a PO with a product in automated valorization, and average as method of valorization
Validate and receive *partially* (create backorder)
invoice with a different price than the PO
Receive the backorder
Invoice the rest, also with a different price than the PO
Before this commit, wrong amounts were written in the account.move corresponding to the invoice.
In particular, the payable account's amount was erroneous because it is computed to balance the move
As a result, the bill showed an amount due different from its total, even though nothing was reconciled with it.
After this commit, the payable entry and hence the amount due on the invoice are correct
OPW 1967289
closesodoo/odoo#32920
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before that, the tag set on this tag for its base amount was wrong; it caused it to be reported in the wrong section in l10n_fr_reports.
closesodoo/odoo#32103
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Forbid locking the fiscal year or period in case there is an open POS session into it. Without that, it will be impossible to close these sessions, as the lock date will not allow posting accounting entries for them.
Also forbid to create a session before lock date, as it would be impossible to close.
closesodoo/odoo#28257
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Before that, having a payment with amount_residual=0, but amount_residual_currency!=0 did not display it.
Also, 'outstanding credits/debits' label was displayed in case amount_residual was != 0 with an amount_currency=0 (and of course, a currency_id value was set on the aml). This could for example happen in case of partial reconciliation, were the amount_residual field is used to keep track of what will have to be written in the exchange rate difference entry when the reconciliation becomes full.
closesodoo/odoo#30362
Before that, with "post at bank reconciliation option" activated on bank journal, the following scenarii did not work as expected:
1. When creating an invoice, making two payments for it, and then matching only one of them with a bank statement
=> the invoice was marked as 'paid' while it should have staid 'in payment' until the second payment gets a bank statement.
2. When directly reconciling a bank statement with an invoice for its full amount
=> the invoice staid in "in payment" state, while it should have been "paid"
[IMP] account: add tests for the aforementioned cases
closesodoo/odoo#28428
Before that, when reversing an account.move, if two lines of the move shared the same account, we tried reconciling them once for each line: it worked the first time but triggered an error message the second, since the lines had already been reconciled.
Before that, taxes were only applied with the most recent currency rate, which caused problems in multi currencies, when reconciling statement lines made in the past with invoices, causing the amount currencies in the payment account.move to be wrong.
//Scenario to reproduce the issue (from customer ticket 1903497):
(for a company with USD as base currency)
1. Create a new bank journal for EUR payments
2. Create a new customer invoice for 90€
3. Create a new tax for the reconciliation model, price-included and amounting to 15%
4. Create a new reconciliation model using this tax
5. Use the currency rates from the demo data, add one that is closer to current date than the most recent one.
6. Create a new bank statement for the created EUR bank journal. Make sure that the transaction is less than the actual amount due on the invoice so that we can apply the reconciliation model. Also make sure to set a date on the transaction that lies in the past at some point when the currency rate was (significantly) different.
7. Hit the reconcile button, select the amount due from the invoice and apply the discount reconciliation model(take note of the amount on the created tax move line). Now reconcile.
What is the current behavior that you observe?
Now go back to the bank statement and check the created journal entries. You will see a difference in the amount currency values of the payment and the tax account move line. This difference should not exist.
This shorten form is aa-bbb-x. The a characters are the first two digits of the number, x is the mod10r verification digit, and b characters consist of all the intermediate digits, without the leading 0s. The chain of b characters' length can range between 1 and 6 characters.
Before that, the body of the message was never displayed if the message had tracking values. This was annoying for account_asset module, were we prompt the user for some justification when she modifies the depreciation data of an asset, and then call message_post with this text as body, and tracking values reflecting the change that was made.
Before that, when receiving, then invoicing with price diff, the value in interim account corresponded to the price on the invoice instead of the original valuation one.
Scenario to reproduce the issue:
* create PO with 1 product, FIFO valuation, price=10
* receive PO: the entry in stock interim account has debit=credit=10
* create invoice, with price=15 instead of 10
* the invoice entry should be: payable: C=15 ; price diff: D=5 ; interim account: D=10
==> Instead, we had payable: C=20 ; price diff: D=5 ; interim account: D=15 => this was wrong
Also added a test case for the same scenario, verifying the amounts written in the different accounts (and refactored a bit ValuationReconciliationTestCase for easiness)
Closes#27394
Until v12, doing this is wrong. The currency_id field of account.journal should only be used if the journal is in a different currency. Otherwise, this field should stay empty.
//NOTE FOR FORWARD-PORT: this commit should not be ported to 12.0 and further.
Two account had the same account code. Because of that, one of them always failed to be created and logged a psql error. To fix that, we totally remove this account, as it never got created anyway.
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.
Before that, the administrator could use accounting features by default. This is not what we want, the group only gets assigned by default when installing account_accountant, on enterprise.
Before that, the administrator could use accounting features by default. This is not what we want, the group only gets assigned by default when installing account_accountant, on enterprise.
This will be used to add the 'Upload' button on the tree view of vendor bills, by extending the regular view.
Was part of PR #26740
Was part of task #1880089
This is done by adding a new field on mail.thread objects and setting it when posting a message with attachments on a model inheriting from mail.thread.
Was part of PR #26740
Was part of task #1880089
get the product_name thanks to a function, so that we can reuse it somewhere else (account_predictive_account)
Part of PR #26876.
Part of task #1882329
[IMP] account: partner form view: add a small link under the bank accounts list, allowing to open the tree view of the linked res.partner.bank, so that they can be fully edited
Before that, as the bank_ids field of res.partner is displayed as an editable tree view with only two columns, it was impossible to edit more specific fields of the bank accounts through the partner form view, such as acc_holder_name.
In some countries, it might be preferable not to recon the payments journal entries at the time they are registered in the system, but to do so at the date of the bank statement line they will be reconciled with.
Thus, to manage this we've added an option on bank journals to have payments generating draft account.move when they are validated, and posting them only after bank reconciliation (+overwriting their date)
Was task 1870892
Was PR #26349
This is done by displaying this field on top of the vendor bills form view and using it as a default value when registering the payment. The use of a sequence on res.partner.bank also allows giving priorities to partner bank accounts directly from the tree view that is contained in res.partner form. In case payments are generated for multiple invoices at once, their account is set as the partner's most prioritary account.
[IMP] account: payment for multiple invoices: option to group + also group on account + hide memo
Add an option in the multiple invoices payment wizard to choose whether or not to group the generated payments. This is useful in case we want to keep one payment by invoice (even if they share the same partner, etc) so that each of them corresponds to a single communication.
The memo field of this wizard is now also hidden in some cases, when displaying it would allow entering wrong communication values (for example, when paying invoices from different partners ; it makes no sense that all the generated payments share the same memo).
[IMP] account: option to sanize invoice communications
Payments older than the chosen date won't be proposed in the widget allowing to match payments with bank statements. This is useful if the db used invoicing for years and then installed accounting : users don't want to have to match all the old payments that were generated by invoicing with bank statements.
Was task 1829536
Was PR https://github.com/odoo/odoo/pull/24728
This field is used by the multiple payment wizard; the payments it generates are always individual and should never have multi=True. Before this commit, they did, because of the values given in context when calling the payment wizard.
This field is used by the multiple payment wizard; the payments it generates are always individual and should never have multi=True. Before this commit, they did, because of the values given in context when calling the payment wizard.
This field is somewhat generic, as anyone could want to specify it and as it is used by several batch payment methods. It is thus now factorized in the core module.
Enterprise module 'hr_expense_sepa' is thus not needed anymore as its code can be put in hr_expense
Was part of task 33323
Was PR #25562
The code was actually alreadt made in this spirit, there was just as wrong call to the date_invoice field of the model instead of the local variable with the same name, which contained the right value.
[IMP] account_bank_statement_import: bank account manual configuration wizard: when linking to an existing journal, change its statements source if the journal had an 'undefined' source.
With this change,
* some modules are now set to be automatically installed by default
* the setup bar of accounting has been changed in order to allow more easiliy the configuration of bank accounts/journals (and the step to oversee the opening entry has been removed)
* the kanban view in the dashboard has been enhanced (mostly for bank journals, but not only)
Was task: 32668
Was PR #23049
It is sometimes useful to be able to customize slightly the color of a
field depending on some conditions on the current record.
For example, imagine that we want to show a VAT number field in green/red, if
it was validated or not. To do that, we can add a field with an
onchange, and simply add decoration-danger and decoration-success
attributes to the field.
This is mandatory to ensure consistency of the data generated by the test, as stock pickings created from a PO are by design always created for the current date (there is no way forcing this), meaning that they always use today's exchange rate for their valuation.
Despite the fact we rewrite the date of the valuation moves artificially, we cannot correct the debit and credit values, since the anglosaxon entries get automatically reconciled (and you cannot modify a reconciled entry).
So, we have to make sure that "today"'s rate will always be the last rate we created in order to ensure complete control of the test. This deletion will have no further impact, as the transaction will be rollbacked at the end of the test.
The date of the invoice is used for currency conversion in anglosaxon stock valuation. Before this fix, the tests crashed between june 6th and december 31th, as the demo data define a currency rate for USD on june 6th. Using the proper date on the credit note ensures the good rate (the one in application when making the credit) is always applied.
The use of id and model reference was inconsistent for this variable, depending on the content of the context. Doing this caused a failure when trying to load some financial reports (> Balance Sheet, Spanish reports, ...) of accounting in multi company, if both companies had not the same currency.
See https://github.com/odoo/odoo/issues/20804
We don't turn invoice_ids into a computed field, because we need it erverywhere for technical reasons. Instead, we use a new computed field only there to ensure consistency of the displayed data.
Was task: 1819501
Was PR #24290
Before that, the following scenario (tested in purchase/tests/test_anglosaxon_valuation_reconciliation.py) failed:
- create a PO
- change of currency rate
- create and validate vendor bill in foreign currency
- receive goods
- change of currency rate
- return the goods
- change of currency rate
- refund the bill
At the end of it, both invoices (bill and refund) were not in 'paid' state, but they should have been! The anglosaxon stock valuation code had some issues in the way it managed currency rates. The main one was that we converted the computed valuation_price_unit variable in company currency using the date of the invoice as a reference, which was wrong in case the invoice was a refund, as it should then use the date of the valuation for this. This problem caused the code to detect an exchange rate difference between refund and valuation as a price difference, hence generating a line in the price difference account, which caused the debtor account line of the associated account.move to be wrong, and hence impacted the residual field of the invoice ("amount due", in GUI). Finally, as this field contained an inconsistent value, the refund invoice was not marked as paid after reconciling it with the original one.
Solving this needed to refactor the code quite a bit, so that we don't convert everything in invoice currency in the end, but rather do it directly everytime we compute a part of valuation_price_unit. The test had also to be partly re-written as it was too naive in the way it used currency rates, we needed something closer to a real utilisation of the program.
Olivier Colson