By adding an index the cost of the SQL's will be a lot lower.
See #86615 for info/sample
closesodoo/odoo#87287
X-original-commit: 44b445eba6287348211e002235e1d003b45f2d6e
Signed-off-by: William André (wan) <wan@odoo.com>
The journal in a cut-off has to be of type general. But there is an
issue at the moment where a default_journal_id would be provided in
the context (coming from the dashboard for example) and thus, fill
the journal in the cut-off wizard with a wrong value (vendor bill for
example).
This change make sure no default values are provided to the wizard.
closesodoo/odoo#87179
X-original-commit: 5b099bf6135b2ff517078d1839b513da7830f718
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
When creating the results of a writeoff button for the manual reconciliation widget, debit and credit are actually inverted with regards to what will actually get created (final inversion is then done here to bring them back to the right sign: https://github.com/odoo/enterprise/blob/15.0/account_accountant/models/reconciliation_widget.py#L986). Because of that, the conditions defining whether or not the compute_all should compute refund repartition need to be inverted as well.
Note that it wasn't the case for bank reconciliation widget, for which the sign was directly right.
Before that, compute_tax_tag_invert computed a different value for the tax_tag_invert field on base and tax line (as the tax line uses the repartition type of tax_repartition_line_id, and the base line depends on debit/credit and the tax type). Hence, the tax_tag_invert values between those two lines where inconsistent, and the tax report was wrong (since we did * -1 on one of them, but not the other).
OPW 2769586
closesodoo/odoo#86870
X-original-commit: fdf448ef226ecf27685675ea4a49a4501d4f9263
Signed-off-by: Laurent Smet <las@odoo.com>
In case an open balance needs to be created on a receivable or
payable account after reconciliation, but no partner was defined
on the statement line, we want to keep the partner from the
counterpart values that was identified through reference matching.
closesodoo/odoo#86752
X-original-commit: 8c4d6d362c096e9dc67562ecd7bad0ce08bc6697
Signed-off-by: Florian Gilbert <flg@odoo.com>
Create a 21% tax included in price
Create a 6% tax included in price
Create a fiscal position that will replace the 21% tax included by the
6% tax included
Create a customer and assign this fiscal position
Create a product :
Price = 121€
Tax = 21% tax included
Create a SO with this customer and this product
Create an invoice (from scratch) with this customer and this product
SO : the unit price is 100,00€
Invoice : the unit price is 106,00€
Fix by creating a common method to calculate the price_unit
opw-2699793
closesodoo/odoo#86514
X-original-commit: 8ab56af6827a640a3f41a87905778432b3786c00
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Consider the following case:
1) Create a 42% cash basis tax, impacting different grids on each repartition line
2) Create a misc entry using this tax, with the same lines as an invoice, with base amount of 100
3) Create a payment and reconcile it with the invoice-like move from step 2. This will create a cash basis move.
4) Cancel reconciliation
===> In the tax report, instead of seeing 0 in the base grid, we see 200. Amounts are doubled instead of being cancelled, they shouldn't. Tax grid is fine.
This is due to the fact tax_tag_invert is going to be computed, and will hence not have the same value as on the original move, since debit and credit on base and tax lines are inverted in the reverse move. Tax line is fine because it relies on tax_repartition_line_id, which is kept from the original move.
We now force keeping the same value for those moves as in the original one, to force full cancellation.
OPW 2769340closesodoo/odoo#86229
X-original-commit: 338c2e908bda73b8be81270e3ea721325452b73b
Related: odoo/enterprise#25182
Signed-off-by: Laurent Smet <las@odoo.com>
Improve the design of SO/PO/INV mails together with the other changes of the
release, i.e. fixes a few imprecisions introduced by odoo/odoo#82167.
In particular, these changes enforce
* a responsive, mobile friendly layout tested on many devices and OS
* more generally, a consistent styling. Note that some redundancy in directives
is required for compatibility across email clients.
Translation files are included.
Task-2751139
Follow-up of Task-2712450
See odoo/enterprise#25154closesodoo/odoo#86494
X-original-commit: 4914127b428802d2ff2e15351238a3ffef24b9cc
Related: odoo/enterprise#25306
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to cleanup some remaining notes in code to better know some cleaning
is long awaited, planned but still not in WIP. Brol is not a recognized word
in the whole world. Also add some query counters explanation as counters are
a bit different depending on accounting, community and enterprise runs.
Part-of: odoo/odoo#86254
The aim of this commit is to correct the compute_all calculation
when it is dealing with an article with 0.00 price and having a fixed
tax included in it.
In this situation, this means the tax is directly taken as an expense
by the company that offers it to its client.
This also solves the situation in which we have a 100% discount because
discount is applied before calling `compute_all` by changing the
unit_price.
Before this commit:
Creating an invoice with a line having a price at 0 or a 100% discount
and a fixed tax price_include resulted in a really weird behavior: the
company had to reimburse the customer for the amount of the tax.
(what a lucky customer :D )
After this commit:
Customer is sad, he only gets the product for free.
The base is calculated as negative, resulting in a debit amount on the base
income line.
The tax is then counterbalance by it.
The form is displaying a negative untaxed amount, a positive tax and the
total is 0.
closesodoo/odoo#86223
Ticket: 2660808, 2637512
Community-pr: https://github.com/odoo/odoo/pull/85747
X-original-commit: 727d19cb4e012e9a24d94640987ac5ea6f452a2e
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Brice Bartoletti <bib@odoo.com>
Steps to reproduce the bug:
- Let's define a sale python tax T where Python Code = product.list_price
- Let's consider a product template PT
- Try to set T on PT
Bug:
A traceback was raised because variable product was not defined when evaluting
the python code in function compute_all (defined in module account_tax_python)
opw:2787007
closesodoo/odoo#86145
X-original-commit: 718048e7d8e875b4a3be183acabc0e6ab67836b6
Signed-off-by: William André (wan) <wan@odoo.com>
Add a check to ensure that the repartition lines have at least one tax line.
Reason: the compute_all fonction skips the taxes with no tax lines
because it only loops over the tax repartition lines to fill taxes_vals
closesodoo/odoo#85943
X-original-commit: 783d604fd66f813b66b0bac769f22c1dc0ed761f
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
The goal is to add a digital stamp on the Invoice PDF
stating the name of its related Vendor Bill.
Auditors may request printed copies of all (original) Invoices
as well as the possibility to relate each document
to a posted entry (Vendor Bill).
task-2755372
closesodoo/odoo#86127
X-original-commit: f0ea39791c70cc63fe39665514e5344a56ed5b71
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: John Laterre <jol@odoo.com>
Just have some numbers before working on composer onchange removal and see
its impact.
Task-2789182 (Account: Invoice send performance test)
Prepares Task-2088884 (Mail: Composer onchange removal)
closesodoo/odoo#85902
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Journal groups name are used as an identifier in reports,
namely on financial reports when a company has different reporting requirements
- on company level
- on consolidated level
- according to IFRS standards
This will add a constraints to ensure that groups name are unique.
Task id #2759252closesodoo/odoo#85958
Signed-off-by: Laurent Smet <las@odoo.com>
Currently, if a liquidity journal has a currency set (e.g. Bank) the amount_currency shows lines according to the journal currency, which is correct. However, if the journal currency is the same as the company currency, the amount_currency shows the amount in the foreign currency that is not in fact held in the Bank.
Should be: follow the same logic for liquidity journals that have the same currency as the company (or set company currency by default) and show amount in journal/company currency.
closesodoo/odoo#85975
Task: 2779310
X-original-commit: 2e7a8e8200a4666baad74c9b596208841501c225
Signed-off-by: Laurent Smet <las@odoo.com>
As in 13.0, the default terms and conditions must be translated in the lang of the partner
PS: In the first computation, narration will be equal to the narration in the lang of the user.
So it was not changed when setting a partner.
The narration must be computed in the lang of the partner.
Writing on payment_ref triggers function _synchronize_to_moves and a write on partner_id was made.
In the write function, function modified was called
https://github.com/odoo/odoo/blob/15.0/odoo/models.py#L3850
And it lead to add the field narration in self.all.tocompute
https://github.com/odoo/odoo/blob/15.0/odoo/api.py#L758
Meaning that the next time it read the field narration, the function _compute_narration was called.
So it reset narration to False
opw:2726012
closesodoo/odoo#85775
X-original-commit: 6d9745e63fec20a7e967f00a428db9109c992bcf
Signed-off-by: Simon Goffin <sig@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
The accounting date and the related warnings were in some cases not
being set properly. This change aims to improve that by displaying
warnings in the view and updating the date on post instead of raising
user errors.
This will mostly affect sell documents.
Task id #2778958closesodoo/odoo#85744
X-original-commit: 51ddb870d346ff61a6ae36c8c3b545eaca9736cb
Signed-off-by: William André (wan) <wan@odoo.com>
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
Before this commit:
Suppose invl1 of 1000.0 with 10.0% and invl2 of -100.0 with the same tax. A tax line of 90.0 is created.
If invl1 is created before invl2, the tax details is computing the tax amounts as:
invl1 tax amount = 1000/900 * 90 = 100 (OK)
invl2 tax amount = 90 - 100 = -10 (OK)
total tax amount = 100 - 10 = 90 (OK)
If invl2 is created before invl2:
invl1 tax amount = 100/900 * 90 = 10 (NOT OK)
invl2 tax amount = 90 - 10 = 80 (NOT OK)
total tax amount = 10 + 80 = 90 (OK)
closesodoo/odoo#85406
X-original-commit: bada85c7621b45970c88548c4d09b88b77c08e8e
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
Steps to reproduce the bug:
- Go to settings and enable “External Email Servers” option
- Go to accounting > Configuration > journals
- Create a new journal, Choose "purchase" type
- save
- Go to advanced settings tab > click on email alias
- Note that default value = `in_invoice`
- Create another journal, choose "Miscellaneous" type > save
- Change the type to "purchase"
Problem:
the default value = "out_invoice", because it is not updated in the write function after changing the journal type
In the case of type == 'purchase', the default value should be 'in_invoice', and in any other case, it should be 'out_invoice'.
opw-2618357
closesodoo/odoo#85292
X-original-commit: c86b1e5a46b5923136fa920a8bb4fc1c8bd31c2d
Related: odoo/enterprise#24708
Signed-off-by: William André (wan) <wan@odoo.com>
The issue here is to be able to change the type of bank account
on the bank journal, e.g. changing from type "Current Assets" to "Bank and Cash".
Previously, a ValidationError would be raised :
"This account is configured in %(journal_names)s journal(s) (ids %(journal_ids)s)
as payment debit or credit account.
This means that this account's type should be reconcilable."
But in some cases, the client might decided not to reconcile.
And the error did not take into account the case when the bank account
and the outstanding accounts are the same.
opw-2738777
closesodoo/odoo#85370
X-original-commit: fe379bc22e649c623dfb6ed8aefb106b4846d02e
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: John Laterre <jol@odoo.com>
I create a method `_prepare_payment_display_name` for inherit.
When you want to set a new name for payment, you can extend this method.
Exp:
I create a new partner type is `employee` in payment for payment with
employee, but with your old code i can't add the key `outbound-employee`
or `inbound-employee`. So, the system will give an error message.
I think if you add this hook method, it will be good for customizers.
closesodoo/odoo#85251
X-original-commit: 6d129783b53115927f664499207c8c800d40bca2
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Step to reproduce:
- Install account_accountant
- Go to Accounting / Configuration / Accounting / Journals
- Create a Journals in Accounting
- Select a type as "Bank"
Issue:
Since this PR: https://github.com/odoo/odoo/pull/81071
The bank suspense account has been changed from "Current Liabilities"
type to "Current Assets", but isn't being correctly updated in
the journals view.
Solution:
In the domain of the "suspense_account_id", we should use
"data_account_type_current_assets" for the "user_type_id" instead of
"data_account_type_current_liabilities"
opw-2715621
closesodoo/odoo#85105
X-original-commit: c16bc3192fe8ea033144c9cb6ab5b8c6db21d735
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Bruno-brsy <brsy@odoo.com>
If partner is copied, it will copy customer_rank/supplier_rank and it
will be treated as such even though such partner has no references to
invoices for example.
closesodoo/odoo#85102
X-original-commit: c0161736db4f2415e6a44674d872bf8aa2972287
Signed-off-by: William André (wan) <wan@odoo.com>
The settings that determines the digitalization mode (disabled, manual
or automatic) used to be common for both vendor bills and customer
invoices.
As many users only want to use the service on vendor bills and not on
customer invoices, the settings has been split for both types of
invoices.
closesodoo/odoo#84184
Task: 2751408
Related: odoo/enterprise#24083
Related: odoo/upgrade#3240
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
To reproduce the issue:
- create a cash basis tax, with different account and tags for invoice and refund
- make an customer invoice using this tax, post it, and register a full payment for it
- unreconcile the payment
=> Two cash basis moves have been generated: one for the initial reconciliation, and another one reverting it when the reconciliation got cancelled.
=> Bug: the reverse move uses the refund repartition, while the original one is using the invoice's one, so they don't sum up to zero. It's wrong: since the reconciliation got cancelled, we want the impact of the invoice on our tax report to be 0 again, just as if it was brand new.
closesodoo/odoo#84727
X-original-commit: b9e94def7dd84a6a02ddb76959400b8d8fbc5025
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>
d22cd54 introduced the fact that when doing a full refund of an invoice, the same account was used as on the original invoice, instead of the one on the tax refund repartition lines, though the tags were still the refund ones. This is wrong.
Also, it restored an inconsistent data setup in a test, while the current version was actually correct.
X-original-commit: 031f017a5a696874065cb5873f2fecd5c4b177ed
Part-of: odoo/odoo#84727
Steps to reproduce:
- Set a language which use ',' (comma) as
decimal separator (eg French)
- Make a Vendor Bill for any product at any price.
If the partner's language use '.' (period) as
decimal separator (eg English), the field
amount_by_group is formated whit period, while others
are formated with comma. They should all be formated
with comma.
- Now print the Vendor Bill
The same issue is occuring.
With Customer Invoices, the issue is the same on
the form view, but not on the printing, where all
the fields are formated with period, as set in the
partner's language.
After this commit, we format all the fields
regarding the environment's language on the view form,
either in Vendor Bills and Customer Invoices,
and we formating the printed bill/invoice regarding
the partner's language
opw-2735698
closesodoo/odoo#84666
X-original-commit: bb029a476a04b7d41ea1f585274d24f581b4003d
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>
The function `_compute_amount` on `account.tax` returns None if the value of
`amount_type` is not a standard Odoo value. During normal use, this will never
be the case, and if the value is modified by a custom module the method is
overriden in its code to account for that case.
During an upgrade, however, custom modules are not available. During the tests,
if a field needs to be computed using that function, it will break with
`TypeError: unsupported operand type(s) for /: 'NoneType' and 'float'`
Adding a default return to the function in case the `amount_type` is not
recognisef will help prevent this.
closesodoo/odoo#84432
X-original-commit: 8489da59c7f30a978023c5c56824d9398b8590b4
Signed-off-by: Olivier Colson <oco@odoo.com>
Purpose
=======
Several actions are done even if nothing has changed on the configuration.
Example:
Writing on a cron the same value makes a dummy write-lock on the table
...
Part-of: odoo/odoo#82999
For this case is wrong use the company of the user, because you may in other company at this moment and the search is not
working properly.
The way to solve this is use the "env" company as use in the computed method.
closesodoo/odoo#84037
X-original-commit: ee264787841395a95162ae809928ee71fd1b7c84
Signed-off-by: William André (wan) <wan@odoo.com>
When creating a new invoice by giving it an invoice_line_ids list for
which the last line is a note, the tax line may be created wrongfully
without partner_id, which is totally wrong.
To reproduce :
Create a SO
Set a customer
Insert a product with tax
Insert a note
Deliver the product
Invoice the SO and confirm the invoice
The partner_id is not set on the created tax line
While the issue only arises in 15.0, it brings to light that the partner
is not in the grouping keys while it should, so it will be changed in 13.0+
opw-2750851
closesodoo/odoo#83999
X-original-commit: 2ce994d279126aa0356b86d3fa38b699e9035e54
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
Storno accounting is the term used to described the process of recording
a reverse action as a negative amount on the same site instead of a
positive amount on the opposite site of the credt/debit.
For instance, when one creates a credit note for an invoice, the values
of debit and credit will be kept in the same column with negative signs
instead of swapping columns like in non-Storno accounting.
It is a business practice commonly used in Eastern European countries.
Countries where Storno accounting is mandatory or considered as best
practice would be :
Czech Republic, Poland, Romania, Russia, Slovakia, Ukraine, Croatia,
Bosnia and Herzegovina, Serbia, Romania, China, Russia, Slovenia
It is available as an option in the settings and is automatically
activated for some countries which use this type of accounting.
otask-2064899
closesodoo/odoo#79581
Related: odoo/upgrade#3212
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: william-andre <wan@odoo.com>
Co-authored-by: qdp-odoo <qdp@odoo.com>
Currently: "register payment" wizard allows selecting different bank accounts or even creating one when registering a payment on customer invoice/vendor refund.
Should be: the field should be set to partner_bank_id and be set as readonly. When cash journal is selected, "Recipient Bank Account" field should be hidden
Task ID: 2710936closesodoo/odoo#81319
Signed-off-by: Olivier Colson <oco@odoo.com>
PURPOSE
Allow to somehow decorate notification emails headers with a subtitle holding
the record name and some main informations.
SPECIFICATIONS
Next to access button in "Pay Now" notification email, display a subtitle
for some of the main "Send by email" based email flows. It should be something
like 'Invoice REF/01 \n35€ due 11/2022' for account.move or equivalent for
sale.order models.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
Purpose is to better isolate MailThread related methods in those huge files
containing lot of code. Better have them located in a sub-section in order
to have all mail code at the same place.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
This commit accomplishes multiple objectives:
1. Loading of model data for the POS UI is now done in single
request (with some exemptions).
2. Backbone.js is removed and is replaced by reactivity.js
authored by the js framework team.
3. Better organization of assets in the `__manifest__.py`
Data Loading
------------
One request per model -- that's always been how the data is loaded
in POS UI. Now, we move the aggregation of data to the backend which
simplified the data loading. In the frontend, data loading is
initiated in `load_server_data` which makes the single rpc call
to the `load_pos_data` defined in `pos.session` model.
There remains some rpc calls during loading but the number is
greatly reduced.
This change result to faster loading of the POS UI. However,
there is no more progress bar during the loading.
Notable entry points:
- .js: `PosGlobalState.load_server_data`
- .py: `pos.session.load_pos_data`
It is possible to make customizations in the loading, but is done in
several steps:
1. Override `_pos_ui_models_to_load` to include the new model to load.
2. Define `_loader_params_<model_name>` to define the `search_params` and
optional `context`.
3. Define `_get_pos_ui_<model_name>` to return the data that will be
included in the full `loaded_data`. Perform the organization in this method
whenever necessary.
4. Override `_pos_data_process` for further post processing. The final
form of `loaded_data` in this method will be sent to the frontend.
Removal of Backbone.js
----------------------
POS is no longer dependent from `Backbone.js`, but it's replaced by a
new dependency -- `reactivity.js`. It's invented by the js framework
team which will be available in owl v2.
The consequences of this change are the following:
1. The old `PosModel` is renamed to `PosGlobalState`.
2. The name of the other models are kept (except Paymentline which
is renamed to Payment).
3. The name `PosModel` is now used as the base model of the data models.
This is symmetric to our use of `PosComponent`.
4. The instance of `PosGlobalState` is made reactive in `Chrome` (the
root component). As a result, whatever mutation made in that instance,
`Chrome` will rerender. But rendering is batched so multiple mutations
in a single sychronous function call will only result to a single
render call.
5. `PosModel`s can be extended in the `Registries` the same way as we
extend the `PosComponent`s.
```js
// E.g.
Registries.Component.extend(Chrome, PosResChrome);
Registries.Model.extend(Order, PosResOrder);
```
Reorganization of assets declaration
------------------------------------
This is a simple change that replaced the explicit enumeration
of loaded .js and .xml files. Also, we now have regions in the
manifest separating:
1. Augmentations of dependencies
2. Assets for `point_of_sale.index`
3. Assets for the qunit test (soon will be improved)
Other notable changes
---------------------
- Automatic call to `Order.save_to_db` is batched.
- Instances of `devices.DeviceProxy` (`proxy`), `devices.JobQueue`
(`proxy_queue`) and `BarcodeReader` (`barcode_reader`) are moved
to `point_of_sale.env`. Together with `posbus` and `posMutex`
(previously `flush_mutex`).
- `ActivePrograms` is now passed a props.
- `cashier` is no longer saved to `localStorage`.
- `pos_cache` is overhauled.
- `cache` is taken out from `PosDB` to prevent infinite rendering
loop whenever `cache` is mutated. It's now called `CACHE` in
the `db.js` file.
- reactive version of `posmodel` is exposed globally when in debug mode.
This means that calling when calling a mutator, the UI will react.
- Added control buttons in the `ProductScreen` is sorted during `Chrome`
setup. As a result, we don't need to worry on the loading order of the
control buttons components.
- Model can be simply instantiated using `BaseModel.create(obj)`. This
takes into account the extensions.
- `pos_coupon`: rewards are now updated whenever set_order is called.
- Component unit tests were removed. It wasn't useful and it just blocks
the development. We'll be introducing better unit testing later.
closesodoo/odoo#82461
Related: odoo/enterprise#23344
Signed-off-by: Masereel Pierre <pim@odoo.com>
Co-authored-by: Jacky (trj) <trj@odoo.com>
The paired payment generated when doing an internal transfer didn't have the correct date
Steps to reproduce:
1. Install Accounting
2. Go to Accounting -> Configuration -> Accounting -> Journals and duplicate the 'Bank' journal
3. Go to the Accounting Dashboard
4. Create a new internal transfer in Bank (go to the three dots on the top left corner of Bank and select New -> Internal Transfer)
5. Select 'Bank (copy)' as destination journal and select a date in the past
6. Save and confirm the internal transfer
7. Go to the paired internal transfer (link in the log notes)
8. The date of the transfer is the date of creation, it should be the same as the other transfer
Solution:
Use the date of the posted internal transfer to create the paired one
OPW-2710356
OPW-2730529
closesodoo/odoo#83316
X-original-commit: ce4b81e6abc49268623bad1fcb85e963eb8990c0
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Some use cases require the use of the same account number on multiple
partners. This will relax the constraints to allows such use cases, and
adapt to avoid setting the partner or bank when we cannot be sure of the
one we should take (on bank statement line, and during reconciliation)
Task id #2692025closesodoo/odoo#81362
Related: odoo/enterprise#22881
Signed-off-by: Laurent Smet <las@odoo.com>
If the liquidity account becomes reconcile (not possible from the UI but possible when setting the account on a payment.method.line), the account is visible from the bank reconciliation widget and then, the user is able to reconcile a statement line with itself that is wrong.
closesodoo/odoo#82997
Issue: 2713163
X-original-commit: b300e71076298fe622e36789fd849c5b1c83346a
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
The goal is to ensure that 2 conditions are met for a fiscal position to
be applied (within the EU):
- The customer must have a valid VAT number from another EU Member State
- The goods must leave the country of origin
Task: 2596204
X-original-commit: ca0fc6cda38fd1e4d3c8cd8953bea790a90001f5
Part-of: odoo/odoo#81832
To reproduce:
1- Configure a 0.05 cash rounding modifying the tax amount
2- Create an invoice using this rounding, for 3€, with a 21% tax (configured with some tags related on tax repartition; a Belgian one for example). => This will create a 0.02 tax rounding move line, for a total tax amount of 0.63 + 0.02 = 0.65
3- Check the tax report => Only 0.63 appears
This is wrong and leads to inconsistencies with the tax closing (which will consider 0.65 because of the tax account used), or the generic tax report (which only considers tax_line_id field, not tag_ids). The tags should be copied from the line we intend to modify the tax amounts of.
OPW 2714411
closesodoo/odoo#83091
X-original-commit: e8e4b0fe3913aadb0c8e1f958b65a24543e6fd9d
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Steps to reproduce:
Have a 0% Tax
Make an invoice with it
Open tax report
The 0% tax is not present in the report because there is no tax lines generated for them because the resulting balance is zero.
Since the tax details is making a mapping between tax lines and base lines and the tax report is using them to compute the report, the tax report is not able to compute the tax base amount for such taxes.
Explanation:
Until now, the tax line with a zero amount wasn't generated because considered as noisy journal items.
Now we must be able to groupby on the base tax account on the tax report, we are forced to use the tax details.
Injecting dynamically the 0% tax on the tax details sub-queries is really complicated and leads to a huge performance drop.
For that reason, we start to generate the tax lines for 0% tax even the balance is zero.
However, since there is nothing creating the missing lines in the past, it should be fixed case by case if needed.
opw-2711432
closesodoo/odoo#82971
X-original-commit: 65b5ec4ad65f798b1d647978b5b42a49e760139a
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
root