All taxes change in Luxembourg, we added a script that will create or update taxes so the clients don't have to
manually update everything or ask the support to do it for them. We don't modify custom taxes.
closes odoo/odoo#108699
Task: 3098941
Related: #104833
X-original-commit: c44a33d67065e20c4ded2a229d0663191c91a0a0
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Claire Bretton <clbr@odoo.com>
To Reproduce
============
- enable QR code on Accounting settings
- with a vendor who has a bank account create an invoice from him/her
- print or preview the credit note
The Problem
===========
the qr code method field will not be filled with SEPA, and a QR code will not be added to the PDF or preview.
This qr reflects the vendor's bank account, so the user could scan it and send the money.
This feature was removed by PR #104496 because it was also printed in the refunds to the customers, which was odd, but as a side effect it is also removed from vendor bills.
Solution
========
The QR should not be hidden in vendor bills and purchase receipts, ( also in vendor refund it can be helpful for the vendor, but there isn't any complain about it now )
A better solution would be displaying the QR code in the form view if it is not the company's bank account (it is the partner's bank account), but it should be done in master, it is too much of change for stable versions.
Ticket No: 3071310
closesodoo/odoo#108612Closes: #108215
X-original-commit: 1b60e21c3636fffba55312525d86da5b1f14948f
Signed-off-by: Pouya Malekinejad (poma) <poma@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
With recent JS change on "group" the currency symbol was missing. By adding the currency_id field invisible in the arch the problem is solved.
Task-id:3089285
closesodoo/odoo#107106
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
An error is raised when trying to create sale order lines with tax on a
sale order without any customer (with debug mode enabled)
Steps to reproduce:
1. Install Sales
2. Create a new sale order without any customer
3. Add a new sale order line and a tax to this line
4. An error is raised `Invalid props for component 'TaxGroupComponent':
'currency' is undefined`
Solution:
Make prop `currency` optional (and format the total without any
currency)
Problem:
When trying to render the tax total of a sale order without any
pricelist, an error is raised as the `currency` prop is missing, which
depends on the pricelist
opw-3098020
closesodoo/odoo#108310
X-original-commit: c3acd369976f46e5c987d9d460908f99c6f05b0c
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Steps to reproduce:
1. Activate the hash mode on a journal
2. Create an account move
3. Choose a customer who is not a commercial partner (e.g. Brandon Freeman from Azure Interior)
4. Post the move
5. Error saying that we cannot modify the `partner_id` because the move has already been posted
This is because currently we first post the move and then we modify the `partner_id` of the lines whose `partner_id` is different from the account's `commercial_partner_id`. We can easily fix this by posting the move after the lines'`partner_id` have been modified.
closesodoo/odoo#108177
X-original-commit: 1036134a2f0d921fd6a659b4951e5fa63975b78d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
The default account was marked as required in the view (bold underline)
but the validation didn't happen. This made it possible to set up
journals without that required field.
Since owl, only the last `required` attribute is remembered, so we need
to define it at least correctly on the last field declaration.
Related:
48ef812a63bd6b98a65f
opw-3061073
closesodoo/odoo#108173
X-original-commit: 7628888d61843ed9e9b76039884572e923ba382f
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Issue:
- clicking on various account field gives traceback because
of invalid domain.
Cause:
- https://github.com/odoo/odoo/pull/105131 PR remove a leaf
from account domain but forgot to remove '&' operator.
Fix:
- removes '&' operator from account domain.
task-3099758
closesodoo/odoo#107914
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Removed annoying error raised onchange of the date/name if they don't match anymore. This was done during the update, which was dumb since it was popping in case you wanted to change both the date and the name. It now only relies on the constraint that is verified upon posting the invoice. Onchange warning is kept only for the format change.
Ensure the date constraint is always verified no matter if the invoice was already posted before, or if we're in quick edit mode: the date's info located in the name must always match the accounting date. This is ensured when posted.
task-2976499
closesodoo/odoo#108116
Forward-port-of: odoo/odoo#107867
Signed-off-by: William André (wan) <wan@odoo.com>
The currency field shows as a badly aligned "in USD".
This PR adds a proper handling of the combinations
of accounting and multi_currency groups.
Original PR in v15: https://github.com/odoo/odoo/pull/104013closesodoo/odoo#108101
X-original-commit: d2363794411bbc9147b8ff0d519d588a3814e582
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Steps to reproduce:
1. Create a new tax (TAX1) with a lower sequence than VAT(15%).
2. Check Affect Base of subsequent taxes.
3. Create an invoice, add a line with a product and both taxes.
4. Remove the invoice line.
5. Check Journal Items tab: a VAT line is still there with an amount
Bug:
When we create an invoice line with (affecting + affected) taxes,
4 Journal items are created, including the affecting tax line
having the affected tax as tax id.
When we remove the invoice line, the system sync the dynamic lines,
recomputing all the taxes to check what to create/write/delete
As one of the tax entries has a tax it will be left as a needed line
while it should be removed.
FIX:
avoid computing `_compute_all_tax` for tax lines
closesodoo/odoo#108048
X-original-commit: 4fbd639965107fc9363dddb553a70461cd596c0c
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
*: base, account, crm, hr, hr_attendance, test_access_rights
The various public methods of the ORM can be override in other models,
those overrides sometime don't implement the exact same signature as the
original method in the ORM. In this work we sanitize all the overrides
to ensure a better compatibility. The background objective is to make it
possible to call any public method using kwarg: `search(domain=[...])`.
* `search`, the first parameter was renamed from `args` to `domain` in
0e9adf7 but the overrides were not updated.
* `invalidate_models` and `invalidate_recordset`, a new `flush=True`
parameter was introduced in 9c3b9a4 but the overrides were not
updated.
* `update`, there is a clash between the `update` method responsible for
writing on a record and `update` in bus responsible to update the user
presence. The bus method has been renamed so it doesn't clash with the
ORM.
This sanitization comes with a new linter that verifies that all
overrides of BaseModel public methods share a compatible signature. The
linter has been disabled for `create`, `write` and `default_get` as too
many overrides don't respect the signature of BaseModel.
closesodoo/odoo#106999
Related: odoo/enterprise#34991
Signed-off-by: Julien Castiaux <juc@odoo.com>
The condition to visualize the payment status on the dashboard of account moves has been improved (this dashboard can be accessed by clicking on the Vendor Bill Journal and removing the filter for example). The reason for this change is that for a lot of different entries the payment status is indicated as "Not paid" even though no payment is expected for those entries. Moreover, this status will not change even though a payment is registered, which is counter intuitive (for payment line PBNK for example). This commit therefore improves the condition to visualize The payment status.
task-3091141
PR number-107329
closesodoo/odoo#107329
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
This commit aims at:
1. Fixing a bug where the invoice would be uploaded in the wrong journal
------------------------------------------------------------------------
To reproduce:
- Go to Customer invoices
- Upload an invoice (with an embedded FacturX)
- The journal is set to Vendor Bill
2. Letting the FacturX move type override the user-chosen move type
-------------------------------------------------------------------
Currently, if the user uploads a credit note in a customer invoice journal,
the document is not created and set to the OCR. This is due to a restrictive check
which has been removed. Therefore, when the move type is defined in the FacturX XML,
we will use it to override the user choice so that the document is always created
within the right journal.
3. Harmonizing the invoice upload between the Accounting and the Documents apps and avoid code duplication
----------------------------------------------------------------------------------------------------------
Currently, the flow of uploading an invoice from the Accounting app and the Documents app is different.
Indeed, if one uploads an invoice in the Document app and click on the "Create invoice",
the document is sent directly to the OCR. Now, instead, we will pass this document to the same upload method
of the Accounting (which will try to create the invoice from the FacturX XML if present).
Therefore, the flow will now be the same from the two apps for better harmonization.
4. Adding a 4th button in the Documents app to create a Vendor refund
---------------------------------------------------------------------
Currently, there are 3 buttons to create a customer invoice, a credit note, a vendor bill, but no vendor refund.
This is due to a duplicate xmlid which has now been fixed allowing the 4th button to be seen in the UI.
5. Adding a button "Switch into customer invoice/vendor bill" button in the account.move's form view
----------------------------------------------------------------------------------------------------
Currently, the user has access to a "Switch into credit note/refund" but not the reverse button to
go from a credit note/refund to an invoice/bill. This is now the case.
Task id 2961932
closesodoo/odoo#103427
Related: odoo/enterprise#32890
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit the canceled lines would not filter out from checks for completeness
of the statements and also the corrections in split wizard consider canceled lines as
real values. One of the results of this is when the user import statements with some
duplicate lines, the duplicates are canceled but the statement stays complete regardless
of the missing lines.
Also fixes the line date is not auto-filled when creating lines in the list view if they don't have a state
Closes PR #105708closesodoo/odoo#107894
X-original-commit: 2422b2c619209c1ff4171902dd2f90824194366d
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Pouya Malekinejad (poma) <poma@odoo.com>
in account and hr module's manifest file non existing image path is specified in images key. removing this images key from manifest and remove empty images key from l10n_latam_check module
closesodoo/odoo#107346
Related: odoo/enterprise#34711
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Journal Items menu was not visible out of debug mode, now it is visible
Closes PR #105704closesodoo/odoo#107668
X-original-commit: fbedc97a5479bace8b23122fc423abdeb2c1757a
Related: odoo/enterprise#34876
Signed-off-by: Laurent Smet <las@odoo.com>
The kanban cards did not take the class
oe_kanban_color.
This is because it was set on the child div
instead of the parent one.
opw-3069024
closesodoo/odoo#107778
X-original-commit: 9078761d10289446cfd3881e9df9061075441440
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Currently, the style for the link 'Browse available countries' you have on the accounting dashboard when no chart of accounts is installed for your company has no link style. This means it has the same styling as any other text, and makes it hard to actually know it's a link.
This commit adds a class to this link to give it a distinct style.
Task id=3094593
closesodoo/odoo#107653
X-original-commit: cc431997944ba90f61e543c73caaac5aeeb6f5c1
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Many country-specific fields were displayed while a company with another country was selected (in case of a multi-company environment).
These country-specific fields are now visible only if one of the selected companies with said country is selected.
closesodoo/odoo#106221
Related: odoo/enterprise#34226
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Changing the bank account on the bank journal led
to a traceback (expected singleton on currency_id)
when trying to open the reconciliation widget.
This is because we are trying to open a blank line
as the origin line was linked to the origin Bank account,
therefore there is no currency_id.
It has been decided to filter the statement line that
match the bank account and to adapt the action button.
Steps to reproduce:
- Create a bank statement line
- In Bank journal, change the Bank Account
- From Accounting Dashboard, click on "Reconcile X items" or
just open the Bank Journal
-> Traceback (expected singleton)
opw-3085670
closesodoo/odoo#107441
X-original-commit: c566a48c5bc528a140e6f29399ca1fbcede60490
Related: odoo/enterprise#34762
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
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>
Claire Bretton (clbr)