Improved the tooltip description of the 'Detect automatically' field for fiscal positions. The previous tooltip was "Apply automatically this fiscal position" while the new one is "Apply tax & account mappings on invoices automatically if the matching criterias (VAT/Country) are met."
task id : 3088331
PR number : #107092
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
// CASE 1: payment with different rate
1) Setup a company in USD, with EUR activated as well
2) Set a rate of 1 EUR = 2 USD for date A, and 1 EUR = 3 USD for date B
3) Setup a Cash basis tax of 1/3, with a non-reconcilable cash basis transition account
4) At date A, create an invoice with just one line with base amount=99.99 EUR ; and using the tax setup in point 3).
5) Register a full payment for this invoice at date B
===> The exchange move created by the full reconciliation consists of cash basis rounding lines for the CABA base received, transition account and tax account. 99.99 USD for the base, and 33.33 USD for the tax. Those are introduced to bring back the total amount in domestic currency to the domestic amounts computed for the invoice at date A.
Impacting the tax account and base received account is totally wrong. When doing cash basis, we want to use the rate of the payment in the amounts that get reported, as it corresponds to the money that actually came in. So, none of the lines impacting those accounts should be there.
Only the line impacting the cash basis transition account is useful, to bring its value back to 0. But it actually corresponds to an exchange difference, and we need to balance it with an exchange gain/loss account. This account can already be set as reconcilable, and if so, will be auto-reconciled. We now choose to only rely on that behavior. The account will not be brought to 0 in domestic currency if it's not reoncilable. If it is, it will create a regular exchange difference entry to handle this case properly.
// CASE 2: multiple payments in foreign currency, at different rates
1) Setup a company in USD, with EUR activated as well
2) Set a rate of 1 EUR = 3 USD for date A, and 1 EUR = 2 USD for date B and 5 EUR = 1 USD for date C
3) Setup a Cash basis tax of 1/3, with a non-reconcilable cash basis transition account
4) At date A, create an invoice with just one line with base amount=99.99 EUR ; and using the tax setup in point 3).
5) Pay 66.66 EUR at date B
6) Make a second payment of 66.66 EUR at date C
===> The problem in this case is that the tax and base amounts in foreign currency (33.33 and 99.99 EUR) will need to be divided by 2 (because we're making 2 payments, hence 2 cash basis entries), and the currency rounding will round these values to 50.0 for the base (instead of 49.995) and 16.67 (instead of 16,665) for the tax. Summing the cash basis moves will hence give a total base of 100, and tax of 33,34, which is wrong.
To handle this, a cash basis rounding of 0.01 EUR needs to be done in the exchange difference entry. The corresponding amount in domestic currency must be computed using the rate of the most recent payment, so it will be 0.05 USD here.
Before this commit, this case behaved as the first one, and brought back the reported amount to the rate of the invoice. Moreover, since it never adjusted the amount in foreign currency, the transition account could not be fully reconciled.
// FIX
To handle both those cases, we now split the behavior of the CABA adjustment:
- For rounding errors: we now check the foreign currency amount, and adjust it if necessary, reusing the rate of the most recent payment. If there is no foreign currency, the adjustement is still done for domestic currency, of course.
- Exchange rate difference of the transition account is not handled there anymore: to do this, the transition account must be reconcilable. In case of rounding error to compensate for, the adjustment line added in the exchange difference entry will be reconciled with the one on the CABA entries and on the invoice, to reach full reconciliation.
In case a transition account is not reconcilable, we only create rounding adjustments, no exchange difference.
closesodoo/odoo#107334
X-original-commit: 01cb7e960f912c4758d30c04653b599937785799
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
When filling a Sales Order applicability rule line, the financial
account prefix is useless, as it will not be used.
Thus we can make it invisible in the case of business_domain corresponding to sales and purchases.
task-3040927
closesodoo/odoo#105014
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
A move in draft created with an account that is later deprecated can
still be posted, while it shouldn't be allowed.
Thus, we add a new error blocking this wrong behaviour.
Task id #3087763closesodoo/odoo#107354
X-original-commit: d8c2ad469299349e5184bc8986183cb205beb16a
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Just change double the by single. This fixes various typos in error and
code comments.
closesodoo/odoo#107266
X-original-commit: 09dfedfc19c2bc34c2bb394dcc4bc609c5ac0107
Related: odoo/enterprise#34681
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the default value for `filter_hierarchy`
was set to `never`. So each report had to explicitly set the value
to `by_default` or `optional` in order to make it available.
Instead, we should use the `optional` value by default and let
reports that do not want it explicitly set it to `never`.
task-3041037
closesodoo/odoo#107263
X-original-commit: a1147d91729a5eb75565f04ec10b52ed28d93c42
Related: odoo/enterprise#34675
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Since BS5 integration in v16.0, the pdf of the invoices has changed. Borders would be present in the body of the invoice and the total detail.
Came back to v15 display by using the table-borderless class on those elements.
closesodoo/odoo#107257
X-original-commit: 1a46b6f9231c5d49d70bfa9eb8d434c1f092c1c7
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Camille Spiritus (casp) <casp@odoo.com>
This PR add a new page "Accounting Documents" with the journal entry, the list view asset_id and the statement_line_id. This make the first page more concise and allow the related asset to be more visible and simple to work with.
closesodoo/odoo#107205
Task-id: 3075466
Related: odoo/enterprise#34642
Signed-off-by: John Laterre (jol) <jol@odoo.com>
In order to make this modules to also match new module l10n_latam_check.
* refactory of some methods to make it more heritable
* check number now is showed only when is defined and is related to
check_printing payment method.
X-original-commit: 9394903813947cd4bfbad87f077cdf67233907d8
Part-of: odoo/odoo#107163
* = {account, sale, purchase, hr_expense}
When a plan is mandatory for SOL, POL or expenses, the flow should still be blocked when pressing the button, and not only when creating analytic lines.
We add the info in the context of the button, so automatic flows are still not blocked.
When the applicability rule requires a mandatory analytic distribution, raise an error upon :
- confirming PO,
- sending or confirming SO
- approving Expense Report by manager.
t-3040929
closesodoo/odoo#107166
X-original-commit: 8623a7850288828759db125b1054b0fed6b6b135
Signed-off-by: William André (wan) <wan@odoo.com>
If an aml has no product, it should not trigger a model that has a product.
So, we now define the fields that have to be checked on the model, instead of just being the ones given as parameters.
The way the field `company_id` impacts the model has also been changed.
The idea is that a model with a company specified should be better than a model without one.
But we also want that a model with 1 valid rule and no company is better than one with only a good selected company.
closesodoo/odoo#107165
X-original-commit: feff1a8a056f1fbbc852f7cf164e73abf83c4cc9
Signed-off-by: William André (wan) <wan@odoo.com>
This fixes the performance of the search panel of `account.move.line`
Menu > Accounting > Accounting > Journal Items
The control panel based on the accounts' roots was the issue (call to
`search_panel_select_range`)
Before this fix, the entire table was read through the use of a
`read_group`.
Since the data returned by the `read_group` is not interresting in our
case, we can simply do a lateral join on an indexed column with a limit
in order to improve the performances.
closesodoo/odoo#107164
X-original-commit: 26dd1d9627cdd04e12c3187f0f53c0e11892a345
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
This reverts 0e958ccd85
Using the id instead of the previous xpath makes it less natural.
It was also conflicting with `l10n_au` which was replacing that part
with something else, removing the id.
closesodoo/odoo#107186
Related: odoo/enterprise#34635
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Since mail.thread was removed from the account.bank.statement, the message_post code was causing a crash when attempting to import duplicate transactions.
This commit retrieves the messages from the returned action and displays them using the notification service
task-3044636
closesodoo/odoo#107167
X-original-commit: 6b5dd2399ccb2a7f533cdf7e2d00d0161a037c1a
Related: odoo/enterprise#34626
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
There's a demo vendor bill that is fixed on the 2018, while it
sure should be set at more than an year ago, but not in a fixed
point in time that keeps getting further away from the present moment.
Task link: https://www.odoo.com/web#id=2732449&model=project.taskclosesodoo/odoo#107112
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
Following some user brain tests analysis, the following small modifications have been implemented to improve the usability of the app.
* Delete the quick create option of the payment terms
* Change the name of the payment column in the invoice menu
* Removing the tags of the payment column when the state is different of posted
* When only one currency is activated the currency symbol wasn't displayed anymore cause of recent change on the js side with "group", by adding the field currency_id invisible in the arch the problem is solved
closesodoo/odoo#106903
Task-id: 3085423
Related: odoo/enterprise#34558
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Before this commit, the rendering context of kanban and form views
was the instance of the KanbanRecord and FormRenderer, respectively.
As a consequence, a lot of implementation details (e.g. "props",
"__owl__", any Class method...) were available. This wasn't what
we want.
The door being left open, people went through, and in 16.0, several
kanban and form archs contain(ed) such use of undesired "features".
With this commit, we restrict the rendering context of those two
views. In kanban views, it contains what has been historically
available (e.g. "record", "widget", "kanban_color"...). In form
views, nothing is available since the only dynamic part in those
archs is the attrs, which aren't evaluated by the rendering engine.
To do that, we use `t-call-context` owl directive. When using this
directive, the rendering context is the given one, + `this`. So the
component instance is still available, but through the `this`
keyword. We can thus use it in our compilers, to make them work as
before. Note that `this` can never be used in an arch directly.
Task 3085357
closesodoo/odoo#106045
Related: odoo/enterprise#34493
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
In Odoo 16, we redesigned the `Accounting > Miscellaneous` menu to
provide a convenient interface for inspecting any journal entry or
journal item.
As such, it no longer makes sense to call it 'Miscellaneous'.
This commit aligns the name with the new functionality.
We also remove the default filter of the 'Journal Entries' view, which
restricted it to miscellaneous entries, and replace it with a filter
on posted entries, consistent with the purpose of conveniently
inspecting the accounting journals.
closesodoo/odoo#106749
Task: 3083921
X-original-commit: ee551d74557b889a463bd7dff234ff5f12539e4a
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Purpose of this commit is to try to make code a bit easier to follow using
dicts, sets and tuples, as well as updating some variable names.
Also rename the method to be clearer. Tools methods may omit the namespacing
to avoid too much confusion in naming.
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#106658
PURPOSE
Purpose of this task is to cleanup attachment management done in generic mail
models overrides and move it in account as model overrides.
SPECIFICATIONS
Accounting holds code to handle attachments linked to their custom composer
(``account.invoice.send``) that uses through inheritance the mail composer
(``mail.compose.message``) that has a specific processing of attachments
to link pending composer attachments to the right records.
Indeed attachments linked to the composer are pending attachments, and are
linked to the record when posting the message. This allows to know which
attachments have been added by the user, have specific rules for access
rights, ...
However this code has been wrongly added directly at mixing level at
odoo/odoo@bdcc012004. Instead ``_message_post_process_attachments`` method
should always be called based on a record, allowing to locate the override
at model level.
Task-2792146 (Mail: Move model-dependent code from composer / template)
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#106658
When creating draft deferred entries in a reconcilable account,
we should not attempt to reconcile them, because only posted entries
can be reconciled.
closesodoo/odoo#106603
X-original-commit: edaf019eac9124cb64c0a1dce55291d40b542256
Signed-off-by: William André (wan) <wan@odoo.com>
To reproduce:
1) activate qr code on invoices
2) print an invoice with a qr code
3) print a followup letter, and attach the printed invoice
-> error due to missing 'qr_code_urls' variable in invoice template
This can happen with any report calling this template, thus we decided to set the qr_code_urls
inside the `report_invoice_document` template directly, so we never need to set it again in _get_report_values()
This allows to remove the following report classes (done in master due to stable policy)
- `ReportInvoiceWithoutPayment`
- `ReportInvoiceWithPayment`
- `PosInvoiceReport` (not even used anywhere)
closesodoo/odoo#106605
X-original-commit: a87460bdb82b7b2ab88f397f3506d0f380d86cfd
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
When the bank journal is set to automated online synchronization, we
also want to be able to configure it when no online bank is set.
task-3043449
closesodoo/odoo#106189
Related: odoo/enterprise#34208
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
1) forward-port of this PR: https://github.com/odoo/odoo/pull/97000
commit: c9209664ce3a4b10142bba4da6afb912afc983c2
2) use btree_not_null instead of simple btree for space optimisation
closesodoo/odoo#106484
X-original-commit: b743e736f764fd7d6e232d2c8eaf6b2e314c5f31
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Steps to reproduce:
-Go to Journals > Bank journal > Remove all Incoming Payments
-Try to pay for an invoice
-The Bank journal will still appear
Issue:
Bank journal should not be an option if it doesn't have Incoming
Payments.
Solution:
We need to add the proper filter for journals in the default_domain in
order to not get the bank journal when it is not available.
This bug affects all versions from 15.2 until 16.
opw-3027346
closesodoo/odoo#106471
X-original-commit: 119676029b929512179a337f0f3b70837a5c2b37
Signed-off-by: William André (wan) <wan@odoo.com>
If the method `_auto_install_l10n` is called programmatically on a DB
where the localization has already been installed, useless processing is
performed by `button_install`.
Do not call this method if no module need to be installed.
closesodoo/odoo#106419
X-original-commit: 11e9d3f1a9e8c85fa85a86f0a63935250552a19f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this PR, going to the coa in kanban view was broken with an infinite white screen. The error was that the template tried to display the account type and without the .value is resulted in an owl error.
It's now corrected, we can now access the kanban view of the COA.
I also changed a bit the size of column so that the name of the account stay a maximum in one line
closesodoo/odoo#106391
Signed-off-by: Josse Colpaert <jco@odoo.com>
Traceback when starting odoo server
ImportError: cannot import name 'errors' from 'psycopg2'
Exception management update in commit
4b430f8e30efb15f06982e4673cd73531a2119b3
would require psycopg2 version 2.8 minimum but version in
requirements is 2.7.7
closesodoo/odoo#106369
X-original-commit: b21fdf115e855d2383603e67343012bfe346cfd9
Signed-off-by: William André (wan) <wan@odoo.com>
We should always use `invoice_date` instead of the `date` of the move for currency exchange.
Re-adding some of the changes from odoo/odoo#87984
task-2807136
closesodoo/odoo#106367
X-original-commit: 76a640d05a350840bdde1c88bd052251aabd6b12
Signed-off-by: William André (wan) <wan@odoo.com>
Change the way the uniqueness of the sequence numbers is ensured.
Instead of using a `SELECT FOR UPDATE` approach inspired from the
`ir.sequence`, or even a true UPDATE, we can use a constraint approach.
SELECT FOR UPDATE
=================
By doing a FOR UPDATE NO WAIT, we are throwing an exception when another
transaction is creating a move using the same sequence as this one, by
locking the row that holds the current greatest sequence.
Since the row doesn't change, the lock is released and the following
UPDATE is allowed. Because of this, a "useless" UPDATE was always done
on the previous row to ensure a SerializationFailureError if two
concurrent transactions were trying to assign the same number.
This means that in a database with a lot of concurrent transactions
(typically with an online shop), many transactions were
aborted/rollbacked.
This approach also has the drawback of having the constraint implemented
python side, which is less robust.
UNIQUE CONSTRAINT
=================
Using a constraint on the database level means that the database knows
when some transactions will try to do something similar. It will
therefore make the concurrent transactions wait instead of aborting the
transaction.
It is however harder to have the constraint customized by different
modules/localization because it is now done directly in the database and
not in python. Changing the constraint means deleting/recreating the
index. For now, this only happens for Latin America l10n, so a simple
hardcoded approach is implemented.
In order to achieve this, the business code is trying to use the
sequence incrementally until it gets a number it can use for when
multiple transactions are concurrent.
closesodoo/odoo#106325
X-original-commit: 4b430f8e30efb15f06982e4673cd73531a2119b3
Related: odoo/enterprise#34297
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
2 fixes are made:
* We use a FOR NO KEY UPDATE instead of FOR UPDATE because we don't want
to prevent the insertion of lines referencing the partner as a foreign
key (i.e. new invoices).
The data is purely informative and the exact value isn't too important
anyways.
* We catch SerializationFailure on top of the previously catched
LockNotAvailable. It can happen in this use case
- T1 and T2 start
- T1 acquires the lock and updates
- T1 commits
- T2 acquires the lock: it gets it because T1 released it
- T2 updates: T1 did it as well so there is a serialization failure.
X-original-commit: b1491b7663e4c6c675e88a172e4b0a812e9b00a3
Part-of: odoo/odoo#106325
Graphs were not aligned depending on data. They will now stick to bottom of the card and fill consistently the space above.
closesodoo/odoo#106276
Task: 3071124
X-original-commit: f39904cbe8db3a4788b6771e2f4591d94dd38363
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Steps to reproduce
==================
- Use a mobile phone / mobile view in devtools
- Go to Accounting > Customer invoices
- Click on one item
-> A traceback occurs, the uom is missing
Cause of the issue
==================
The field is declared as
`<field name="product_uom" groups="uom.group_uom"/>`
The raw value is accessed with
`<t t-esc="record.product_uom.value"/>`
Solution
========
Add the missing group
opw-3070671
closesodoo/odoo#106066
X-original-commit: 6563e7b077ade8da333b710578a23ee8ac23a025
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Exporting a Binary field with a value of type dict from a record raises
an error
Steps to reproduce:
1. Install Accounting
2. Open Accounting and go to Vendors > Bills
3. Open any posted bill and register the payment
4. Go back to the list view and export the bill in payment
5. Add field Invoice Payments Widget to the exported fields and export
6. An error is thrown
Solution:
Make the field attribute `exportable` work (pass it in the field
description)
Make fields `invoice_outstanding_credits_debits_widget` and
`invoice_payments_widget` non-exportable as they contain computed
aggregated data for the client's benefit and it doesn't make sense to
export them
Problem:
xlsxwriter's `write` doesn't support type dict
opw-3054184
closesodoo/odoo#105972
X-original-commit: c925ecb2a22750524020f0d111888fd76eedb0cb
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
- When importing account move lines, accounts are created with `name_create`. If the `account_id` column only contains the code, like "12345", the `split_code_name`
would only return a value for the name and leave the code empty. This is because the first group in the regex expects a space in the end, so "12345 " would work correctly.
The code is a required field, hence the import fails.
Removing \s from the first group fixes the issue and the code is saved correctly.
- There should be a UserError raised in `name_create` instead of the ValueError. The message should be clearer as well.
- It should not be possible to quick create an account from product category views.
task-3056847
closesodoo/odoo#105815
X-original-commit: 24758778172595388c19fd0a83d93d35f2260261
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
The Accounting Journal Dashboard Kanban view contains direct owl components and directives. This should not be the case as it may cause problems with studio.
This commit replaces the direct owl with
1. a view widget for the file uploader buttons.
2. the kanban record template is extended to add the dropzone and file uploader with context
Task-3040946
closesodoo/odoo#105575
X-original-commit: 5de857d56c5f4cff318ed6b6c7dd15bf426e6a18
Related: odoo/enterprise#33877
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
Simplify the arch of the account_tour_upload_bill view.
Use the CSS grid from bootstrap instead of the mulitple cols and colspans.
Steps to reproduce: `-i account_accountant,l10n_fr --without-demo all`
Then, in the accounting dashboard, click on "Upload Vendor Bills".
closesodoo/odoo#105562
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
We made the field cumulated balance non exportable
in the GL.
Steps:
- Go to Accounting->Accounting->General Ledger
- Unfold and select one or several lines
- export lines
-> The cumulated balance is not computed
The reason is we don't pass in the compute as we don't
come from the search_read method when exporting, so we don't have a domain
to compute the cumulated balance.
As we can't force the domain, we override the fields_get method
to make the field non exportable.
opw-2800669
closesodoo/odoo#105538
X-original-commit: bd41d369342bfc97161a4190f03c98b718458aea
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Unused catch block arguments are now forbidden even when prefixed with an
underscore: if the argument on the catch block is not needed, the use of the
optional catch binding is enforced.
Part-of: odoo/odoo#105433
### Steps to reproduce
* go to Accounting > Settings and activate 'Cash Basis'
* got to Chart of Accounts and create a new account of type
`Current Assets`. We'll call it `A`.
* create a new tax, we'll call it `T`, with the following parameters:
* Tax type: Purchases
* Tax computation: Percentage of Price
* Amount: 22%
* Distribution of invoices:
* add a line with the following parameters:
% = 40, Based On = 'of tax' and Account = the tax paid account.
* add a second line with the following parameters:
%= 60, Based On = 'of tax'
* Distribution of Credit Notes: Add the same lines as
'Distribution of invoices'
* In the Advanced Options tab, set :
* Tax Eligibility = 'Based on Payment'
* Cash Basis Transition Account = `A`
* create a new vendor bill and add a product line to it and set
Taxes = `T` on that line
* confirm and register payment
Now go to Accounting > Journal Items, group by Journal. Look through the
'Cash Basis Taxes' group and find the entries related to the vendor bill
you just made. One of the debit lines on account `A` is not correct.
Here, the account should be the one specified on the invoice line.
opw-2796727
closesodoo/odoo#105445
X-original-commit: b69fc397aad019cc18bd00975d38dde9ffcc985b
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
The search bar had a trace back when searching on a name, and searching on the code prefix did not work.
This was not working because using str(self) does not work in v16, str is not defined in filter domain.
By removing the str and adapting the filter domain logic, it now works as it should. And the behavior of version 15 is restored
closesodoo/odoo#105381
Task-id: 3058778
X-original-commit: 9173e4da3912f8e46f163cc0d38a4a037b591c60
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
To Reproduce
============
- enable QR code on Accounting settings
- with a customer who has a bank account create a credit note for him/her
- in other info tab, make sure that the qr code method is empty
- send or print the credit note
The Problem
===========
the qr code method field will be filled with SEPA, and a QR code will be added to the PDF
Solution
========
Generating a QR code for a credit note doesn't make any sense, so the qr code method field must be hidden
and no QR code should be generated.
opw-3010649
closesodoo/odoo#105385
X-original-commit: 4b0c37833547ff45d2240e51272372a572a920d5
Signed-off-by: William André (wan) <wan@odoo.com>
hupo-odoo