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>
The dashboard is using a domain `[('move_id.state', '=', self.id)]`
This impacts the performances because we are not joining explicitely on
`move_id`. We can't use the field `state` because it is re-declared on
`account.bank.statement.line`.
X-original-commit: 8b19f0f981fefc6df7c8298b57619c6b9b0a0890
Part-of: odoo/odoo#82807
Steps to reproduce:
- install accounting (account_accountant)
- go to invoice
- click on "send and print"
-> template is not loaded directly
Solution:
- revert changes of commit #fc5812c327daab4 since the onchange is now called only once
OPW-2732687
closesodoo/odoo#82805
X-original-commit: fa25a3b2b7cdafbce70e39a8a896924f015185a9
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
We have our own html2plaintext, already used in lot of use cases instead of
just a few for the html2txt library.
Notably for emails: most emails going through Odoo stack use our simple
html2plaintext to format the body alternative. When no body alternative
is given to ``build_email`` an alternative is built using the library to
remove. Using our own parser allows to have the same results compared to
using ``MailMail.send()``. Difference lies in spaces and new lines as well
as markdown. Our html2plaintext is a bit simple and does not try to generate
Markdown but generates a simple plaintext version.
This also helps solving some issues with depending on that library.
Task-2702034
closesodoo/odoo#82486
X-original-commit: b3b9627b655cd7cb928925affed6cc8d92661e8d
Related: odoo/enterprise#23364
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce :
- Create an invoice for a customer (ex $100)
- Create a payment for the invoice (ex $100)
- create a bank statement with a line item for $200
- In reconciliation, add either another journal entry or a manual operation without partner to reconcile the remaining $100
Issue:
All lines receive the partner from the invoice
opw-2691196
closesodoo/odoo#82517
X-original-commit: 6cda0780fdccf666f5a3fb0f39db59fcb0bd45c8
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>
By searching on account.move.line parent_state instead
of move_id.state, we avoid a join in many circumstances
and allow the database to benefit on an index on
company_id+parent_state to optimize several
queries, such as the default filter on the Journal Items
menu which shows posted items.
closesodoo/odoo#82504
X-original-commit: ef61db1cf8ebf1ab11e5dfdd439256d0607edba8
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Florian Gilbert <flg@odoo.com>
The aim of this commit is to allow EDIs to create and save account move
even if a supplier reference is duplicated.
This is achieved by delaying the moment to which the constrains is
triggered.
Before this commit:
A user can only upload a bill once. (xml ubl format for instance)
If he needs to upload it a second time, he will be forced to find a
workaround.
After this commit:
User will be able to upload as many bill as he wants but will receive a
ValidationError when trying to post the invoice if the reference is
duplicated.
The user will be able to post the bill very easily by changing the
reference a bit if he wants to pursue.
closesodoo/odoo#82303
Community-pr: https://github.com/odoo/odoo/pull/81748
Enterprise-pr: https://github.com/odoo/enterprise/pull/23255
Task: 2612299
X-original-commit: 200614876e62192e1a5ce2f30ec7aa8a1de77672
Related: odoo/enterprise#23281
Signed-off-by: William André (wan) <wan@odoo.com>
As the query results are set in a list of dicts relying on the
position of the dicts inside the list, the SQL query must ensure
the results returned by postgres are ordered properly so that it
will match the order in which the dicts are defined inside the list.
closesodoo/odoo#81978
X-original-commit: bac93bf56ff67a89f9381137b0c67642a302e6bb
Signed-off-by: Laurent Smet <las@odoo.com>
When reversing the CABA entry, the CABA tax account was replaced by the transition tax account if not set on the repartition line.
To reproduce:
Set up a CABA tax with ACC1 as transition tax account and ACC2 as tax account.
When creating the CABA entry, there is a line on ACC1 and another on ACC2.
When reversing the CABA entry, both lines are now on ACC1.
Introduced by https://github.com/odoo/odoo/pull/79556closesodoo/odoo#82004
Issue: 2718413
X-original-commit: 2f6a35eb73978ce0638765fd0981c7e95d9df696
Signed-off-by: Laurent Smet <las@odoo.com>
Steps to reproduce:
- Create an account group for a range for example from 100000 to 200000
- Now edit the group to have a range from 100000 to 150000
Issue:
The accounts with code > 150000 are still in the account group
Solution
Adding an other intermediary table to the query in order to take into
account the accounts which have no group_id
opw-2695533
closesodoo/odoo#82023
X-original-commit: 05c3cb8dbb7a9bf0f438d5ee687b92e8d934f26b
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>
It's possible to confirm an invoice with an archived bank account of
the recipient. But it's not making any sense, since the bank account
is archived.
It's why we need to raise an error if the user want to confirm an
invoice with an archived bank account.
opw-2704605
closesodoo/odoo#81939
X-original-commit: 8b9ff034cb67b132cdb6736a5f18d70beb63c253
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Bruno-brsy <brsy@odoo.com>
Steps to reproduce:
- Create two bank journals Bank-1 and Bank-2
- Create one Oustanding Payments and one Outstanding Receipts account for each bank journal
- Create and confirm an internal tranfer from Bank-1 to Bank-2 for 100$
- A second payment is created
Issue:
The account on the line in the second payment is the Outstanding Payments account of Bank-1,
it should be the Outstanding Receipts account of Bank-2.
After this commit, the second payment will take into account the account set on bank journal,
and if not set, the one set on company. Otherwise, an error is raised.
opw-2711252
closesodoo/odoo#81938
X-original-commit: 51b5a9d4e56d8d2300cf1ee91f8030c57a41a856
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>
Consider this example:
- Create a 42% tax, price-included, with two tax repartition lines doing +100 -100
- Create an invoice of 100€ using this tax, and look at the move lines generated
==> Only a base line of 100 and a receivable/payable line of 100 have been created; no tax line.
This is wrong, as we'd expect to see:
- 100 in payable/receivable
- 100 for the base line
- 42 for the +100 tax repartition line
- -42 for the -100 tax repartition line
The two tax lines are missing because the compute_all considers the tax as a 0% one, because of the +100 -100 stuff.
OPW 2716083
closesodoo/odoo#81771
X-original-commit: 9d24e3cf002bacb09d6e955b26124dda09c15f18
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>
When no partner is set on a statement line, the reconciliation models try to find candidates using the payment reference or the partner name.
This was not working well when using reconciliation models configured to match on notes and/or reference. Only the default match on label was working.
As an example, consider the following case:
1) setup an invoice-matcing reconciliation model as such:
- Partner Is Set and Matches = False
- Match Invoice/bill with = Reference
2) Create an invoice with payment reference 123, for 100€
3) Create a statement line of 100€, with reference ('ref' field, inherited from account.move) = 123, label='test', and no partner set.
4) Try to reconcile the statement line
=> not match is found
OPW 2701729
X-original-commit: 74894b0da82f5f71cd22a3c9bb405696f908ef5c
Part-of: odoo/odoo#81730
Renamed the 'Other' account type into 'Non Trade' to enhance clarity and coherence
Changed the filtering system in the accounting search view to improve coherence with the filtering system available in the reports.
It is now possible to filter the trade/non trade accounts in the accounting views.
This change may be overriden by default selections already in place.
Renaming Receivable/Payable to Trade Receivable/Trade Payable could have turned out to be confusing for accustomed users.
They are now renamed Receivable/Payable, though the Non-Trade option is still present.
task-2669128
closesodoo/odoo#79752
Related: odoo/enterprise#21773
Related: odoo/upgrade#3004
Signed-off-by: Laurent Smet <las@odoo.com>
Have an MX database set up
Activate multicurrency (MXN and USD)
Have several rate for USD
- yesterday 0.047939098170
- today 0.048486729180
Make an invoice, dated yesterday for USD 116, tax 16% (cash basis)
Create a received payment dated today, for USD 116
Reconcile invoice and payment
Jounal items will be created for the invoice, for the exchange
difference and for the cash basis entries, but there are redundant
entries addressing the tax.
This occur because when reconciling the payment with the invoice the
system create the cash basis moves and reconcile them. During this inner
reconciliation exchange difference move are created (1) just for the tax
line.
Then the outer reconciliation flow continue and compute the exchange
difference moves, considering all cash basis items created before. A new
couple of journal items will be created to account for the difference in
tax, but this is redundant since it was already covered before (1)
opw-2685570
closesodoo/odoo#81624
X-original-commit: 03bf311bfde98f28a9b8e73953869a42b828c5e3
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Currently Bank Suspense Account has "Current Liabilities" type, while it should be "Current Assets"
Task ID: 2702804
closesodoo/odoo#81491
X-original-commit: c6d2a50499744a9ddbb09a9974d6ab52116ef542
Signed-off-by: Laurent Smet <las@odoo.com>
When the Reconciliation Model had a tax on the writeoff,
the journal_id wasn't populated by widget.get_reconciliation_dict_from_model(),
preventing the reconciliation from happening.
opw-2689002
closesodoo/odoo#81396
X-original-commit: 17a1c960cc3cce1850a6009ebf9641174e0304fb
Related: odoo/enterprise#22891
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
This commit:
1) fixes the customer invoice/vendor bill outstanding debit/credit warning anchor link
2) improves the customer invoice/vendor bill outstanding section
3) fixes the customer invoice/vendor bill outstanding debit/credit warning messages when viewing an account move reversal
4) modifies the order of the 'invoice lines' tab for mobile view
1) The anchor link did not work when pointing to a field (the id of a field is not propagated into the DOM).
Hence,the target field is put inside a div with the correct id.
2) The outstanding section is placed to the right, below the amount due and next to the description for clarity purpose.
The 'Add' button is turned into a secondary button (s.t. it is more noticeable). Each entry name is now a link to to the corresponding account move.
3) The warning messages are modified because they were not consistent and confusing when viewing an account move reversal.
4) Previously, the order on the 'invoice lines' tab was: narration>total>widget, now it is: total>widget>narration
task-2669132
closesodoo/odoo#78550
Signed-off-by: Laurent Smet <las@odoo.com>
When paying an expense, we should take the bank accounts from partner instead of the ones set on the company.
Also, the computation of the partner bank account is different on the wizard and the payment.
To unify both models, the 'available_partner_bank_ids' should also be put on account.payment.
see https://github.com/odoo/odoo/pull/79737closesodoo/odoo#81236
X-original-commit: 89d8c0a1ea03919e9f3085ea0d05aa80ad443ff7
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
By searching on account.move.line parent_state instead
of move_id.state, we avoid a join in many circumstances
and allow the database to benefit on an index on
company_id+parent_state to optimize several
queries, such as the default filter on the Journal Items
menu which shows posted items.
closesodoo/odoo#80815
X-original-commit: c2a72c268e6a28d7448b6dbf96fed4e36d24b3fe
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
When using account control on a journal, line_section and line_note do not
block the process even though they are not in the allowed accounts (they
don't have an account at all).
But when adding new accounts in the account_control_ids field, the
constraint is triggered by those lines.
This PR makes the constraint ignore those lines when assessing if
there's an issue.
opw-2677597
closesodoo/odoo#80313
X-original-commit: 9a42ebf1d9d482b031bc5bb7839cc9a8a09090ea
Signed-off-by: Florian Gilbert <flg@odoo.com>
Yannick Tivisse