Remove the custom messages and replace with the default odoo tracking message that uses tracking_value_ids as parameters
Journal Items will log all changes of tracked fields in the chatter of the associated Entry - including one2many and many2many fields (by overriding _mail_track)
references original task 2061399
closes task 2469621
closesodoo/odoo#72023
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce the bug:
- Install Accounting and Expense app
- Go to accounting settings > enable cash basis option
- Go to accounting > configuration > accounting > taxes
- Create a new tax or choose an existing one e.g “Tax abc”:
Tax Computation = `”Percentage of Price”`
Tax Type = `”Purchases”`
Choose any value for amount
Select "Based on Payment" in tax due
choose an account with the "Allow Reconciliation" option activated in the Cash Basis Transition Account field
Save
- Go to expenses > Expense Reports > All reports > Create a new one :
- Add 2 expense and for both set up the taxes to "Tax abc" and unit price > 0
- Submit to manager
- Approve
- Post journal entries
- Register a payment
Problem:
A user error with the following message is triggered: “You are trying to reconcile some entries that are already reconciled”
In the use case we have two expenses and for each, an `" account.partial.reconcile "` will be created,
so we will loop twice and therefore add twice all the `”account.move.line”` linked to the taxes
in the dict `" to_reconcile_after "`: https://github.com/odoo/odoo/blob/beccf82e09d536255d9d9cb9bfe58ebae2559843/addons/account/models/account_partial_reconcile.py#L585
Then we loop to reconcile all the `" account.move.line "` which are in the dict `" to_reconcile_after "`,
but since we added them all twice, at each turn of the loop we give them all as a parameter
of the “reconcile” function without checking whether they are already reconciled or not.
opw-2565934
closesodoo/odoo#74432
X-original-commit: fb2b1482f5d3dec924b08e08dc915d6608c7d6b3
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
A tax line affecting the base of subsequent taxes is a line having some values in 'tax_ids' & 'tag_ids'.
When creating a refund, tags was wrongly computed in this case.
closesodoo/odoo#74307
Issue: 2596368
X-original-commit: 49d1dbbb74ea97e4337fe1af3b8074dc9146143c
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Explain the situation when a manual change has been done to the sequence
of `account.move`. This was needed because some user didn't realize that
they changed the sequence, and when they realized it, it had polluted
multiple numbers after that.
closesodoo/odoo#74326
X-original-commit: 56f7afb253da6560cddae121f5b6cdab3e3b1c6e
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
When sending the same invoice from Invoices > list view > select an invoice > action > Send and print, the email received by the client does not contain the header and the link to the invoice
This PR adds the custom_layout attribute to the context of "Send & Print" action
opw-2544654
closesodoo/odoo#74311
X-original-commit: 8bb27b88326d6298a03a5fa3978ac99b0e1ee7e0
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
action_invoice_sent() triggers two onchanges which normally don't happen at the same time. Added a check to one of them (onchange_is_email()), so that on action_invoice_sent(), only one of them calls the computationally expensive onchange_template_id_wrapper(), effectively halving the time taken.
Time for executing the action for one invoice dropped from over 3 seconds to a bit over 1.
closesodoo/odoo#74160
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this commit:
When there is too much records to post and it's take time more than 15 minutes then server was restarted.
So scheduler action will do the process with the same records again and again.
After this commit:
post record in batch of 1000
opw-2451446
closesodoo/odoo#70831
X-original-commit: 819321c3a129613890ce49e3efe9a903c3218070
Signed-off-by: rrt-odoo <rrt-odoo@users.noreply.github.com>
Currently, the payment method lines are only ordered
base on their sequences. This could lead an issue if
the sequences are all the same, where they would be
returned in a random order.
Add a second ordering on the id to avoid such random
issues.
closesodoo/odoo#73984
X-original-commit: ac700908a80f67e5fd15fa242cc111d57abd4aa9
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Nicolas Viseur <vin-odoo@users.noreply.github.com>
There is an issue when computing the suitable payment token ids making it impossible to
open a payment for a user without access to payment acquirers.
Also, the default computation of payment token was wrong and would never set it
correctly.
The compute for the method lines in payment would not filter unavailable acquirers
line and thus select them by default if they were first in line.
Also fix an issue with the ordering of payment method lines
X-original-commit: 73410a0fd76a70e1730883d35b79fc603741b59c
The journal needs to access the payment acquirers to determine with payment method is still available.
Since the acquirers can't be accessed only for admin users, an accountant doesn't any right to read them, and then, an access error was raised when opening the journal form view.
Also, the 'payment.acquirer' was accessed from the 'account' module instead of being overridden in 'payment'.
closesodoo/odoo#73761
X-original-commit: 7b4580c3756657c902eceb9840984dde76429dcd
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Change dependencies of a few computed fields in order
to avoid triggering them wrongly when migrating.
Also add a company check on the constrains blocking
deletion of payment method lines linked to an active
acquirer.
closesodoo/odoo#73731
X-original-commit: e94b4f09a4c5664360594bee6475cb2ef756be47
Related: odoo/enterprise#19663
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
In the first days of the month, many of the previous month's invoices
could still to be posted since the lock date is not yet set to the last
day of the previous month. To avoid the user having to modify the
default accounting date on each such bill, detect whether the conditions
allow the invoice to be posted on the very last day of the oldest
possible month, and then adapt the accounting date to the last day of
that month.
task-2575560
closesodoo/odoo#73701
X-original-commit: 2c5c1a4478505688f35e47ca20e7977b134d0fdb
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
On reconcile models, a rule can be set to map a partner to a bstline if
the bstline "Notes" matches a regex. This "Notes" field is actually
the "narration" field inherited from move. In commit 0f3c7f153e8bd20f83b7d1df031634996d36935b
this field is converted from Text to Html. This breaks the regex match.
The fix converts back the field value to text for the regex check.
closesodoo/odoo#73618
Task: 2427089
X-original-commit: 8e9616034678a627f92740487f20cf66e60c0f30
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: jbw-odoo <jbw-odoo@users.noreply.github.com>
To improve the payment method system, proceed to a few changes
such as changing the view a bit, making sure payment acquirers are not
linked to a journal by default and that only the manual payment method
type can be used multiple times in a single journal.
Task id #2573145closesodoo/odoo#73596
X-original-commit: 9122b367baea10e59b66e45bf7c458a6f1e82efb
Related: odoo/enterprise#19623
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit, the narration field was not filled with default terms and conditions when it was defined in the company settigns.
closesodoo/odoo#73501
Taskid: 2587051
X-original-commit: 49ca71337c8e0f00a5f200d5e97c1c246a6ccd03
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
Domains must be lists on calls to `_where_calc`.
```
Traceback (most recent call last):
File "/tmp/tmpjmcn3gby/migrations/base/tests/test_mock_crawl.py", line 162, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpjmcn3gby/migrations/base/tests/test_mock_crawl.py", line 253, in mock_action
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpjmcn3gby/migrations/base/tests/test_mock_crawl.py", line 366, in mock_view_tree
self.mock_web_read_group(model, view, domain, group_by, fields_list, limit_group=5)
File "/tmp/tmpjmcn3gby/migrations/base/tests/test_mock_crawl.py", line 442, in mock_web_read_group
self.mock_web_search_read(model, view, [group["__domain"]], fields_list)
File "/tmp/tmpjmcn3gby/migrations/base/tests/test_mock_crawl.py", line 402, in mock_web_search_read
data = model.search_read(domain=domain, fields=fields_list, limit=80)
File "/home/odoo/src/odoo/14.0/addons/account/models/account_move.py", line 3645, in search_read
return super(AccountMoveLine, self.with_context(domain_cumulated_balance=to_tuple(domain or []), order_cumulated_balance=order)).search_read(domain, fields, offset, limit, order)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4839, in search_read
result = records.read(fields)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 3020, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 3040, in _read_format
vals[name] = convert(record[name], record, use_name_get)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5666, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1019, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1175, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4061, in _compute_field_value
getattr(self, field.compute)()
File "/home/odoo/src/odoo/14.0/addons/account/models/account_move.py", line 3655, in _compute_cumulated_balance
query = self._where_calc(self.env.context.get('domain_cumulated_balance'))
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4247, in _where_calc
domain = [(self._active_name, '=', 1)] + domain
TypeError: can only concatenate list (not "tuple") to list
```
Observed on upgrade request 11722
Ref 9d28c71a71 since saas-13.2
closesodoo/odoo#73522
X-original-commit: e24295da8436b4d24cd03f6ac1f22e86465f950d
Signed-off-by: Christophe Simonis <chs@odoo.com>
PURPOSE
Align default sequence numbering on customer's expectation per journal.
Because of some feedbacks received, we acknowledge that most users will
want an annual sequence on sales documents and a monthly sequence for
the rest.
SPECIFICATION
By default, on customer invoices/credit notes (the default sequence
should be annual.)
We don't want an option and therefore, we make a decision ; user can
change it by resequencing if he doesn't like it.
task-2591145
closesodoo/odoo#73278
Related: odoo/enterprise#19565
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Steps to reproduce the bug:
- Go to Accounting > Vendors > Bills
- Create a new Bills
- Delete the contents of the 'Accounting Date' field.
- Click off that field.
Problem:
-An AttributeError is triggered because we try to recalculate a new name via the function `"_compute_name"`
and we base ourselves on the date field, but we do not check if it is null or not before accessing it.
This field is only used for purchase receipts, vendor bills, vendor credit notes, payments
and regular journal entries. Other move types are unaffected here.
opw-2511799
closesodoo/odoo#73490
X-original-commit: f830efa1af28de4a4cc3b861643ac9b6fb352c8d
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
Due to EU e-commerce 'One-Stop Shop' which becomes available on 1 July 2021, EU companies involved in distance sales are able to file their taxes using the new OSS process. Adopting OSS is now simplified in Odoo.
On installation of the module, all companies having a fiscal country in the EU will be processed.
For all existing domestic taxes in the company, an associated foreign tax (standard rate, reduced rate, etc) is found in the `EU_TAX_MAP`. This mapping will be created in a fiscal position that is automatically detected based on the customers' country.
All that is required from the user, is to review the tax mappings according to the products and services sold by the company.
A refresh button is also available in the odoo settings to redo/update the fiscal positions. This might be useful after adding a new tax.
Note: The tax mapping herein is not intended to cover all possible tax mappings between EU countries, but rather, the most commonly used ones. It is advised that users with special tax cases update the created Fiscal Positions according to their requirements.
Closes [Task 2579615]
closesodoo/odoo#73042
X-original-commit: 9c548c423614d1305542ebdffdbcd0da3cf09899
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Habib Ayob <h4818@users.noreply.github.com>
The purpose is to use config bar for real config steps rather than highlighting tour steps.
Mainly by:
- Removing "First Bill" step from the configuration bar and replacing it by "Company Data".
- Adding "Taxes Review" step in the configuration bar as the last step (after CoA). This step opens the Taxes list view.
- Adapting the Tour according to these changes.
closesodoo/odoo#70115
Related: odoo/enterprise#18125
Related: odoo/upgrade#2449
Signed-off-by: William André (wan) <wan@odoo.com>
When changing the journal of a payment that has already been saved by
one of another company, a traceback will occur because of writeoff lines.
This ensures that it will not happen.
closesodoo/odoo#72800
X-original-commit: b44a70284c52623061623d4793ffce29ea25487a
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Nicolas Viseur <vin-odoo@users.noreply.github.com>
To reproduce:
- Create a cash basis tax
- Make an invoice with two lines, a positive and a negative one (the positive having a higher value), both using this tax
- Post the invoice and register a payment for it
===> It crashes when registering the payment. The SQL constraint ensuring debit/credit consistency fails when creating the cash basis entry.
This is because we were not grouping debit and credit values together on the lines sharing the same taxes; we were summing them separately. The cash basis entry then received line values with both credit and debit set, which is forbidden by the SQL constraint. We now compute the balance first, and set either debit or credit depending on its sign.
closesodoo/odoo#72383
X-original-commit: 896496d84413e7bb5e5df582e2b67eae2583671b
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This commit fixes the case when the reconciliation never ends due to an infinite loop.
This happens when we attempt to reconcile two journal items having differents foreign currencies but an amount_residual = 0.0.
In that case, partials are created everytime with zero amount, zero debit_amount_currency and zero credit_amount_currency.
We don't need to handle such reconciliation because exchange difference journal items are always created using the same foreign currency as the originator line.
The way the reconciliation is made for reversal moves is also edited by this commit to avoid reconciling lines on the same moves but with different currencies.
closesodoo/odoo#72266
X-original-commit: 1231d54b8c2084db6ffb9551af7ed4ee9e31a95a
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When adding a section or a note on an invoice, default taxes are set on
the account move line, making the corresponding Tax Group to appear on
the invoice.
opw-2541722
closesodoo/odoo#72337
X-original-commit: a8d3f466dfffca08214acecf08ec298e3ace6272
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Passing an id directly to `search_view_id` is not working. It is silently
ignored.
The framework js code expects an id/name pair, as described in the ORM doc.
Most of the time, this will be unoticed as the specified search view being
ignored, the default one will be used instead, which is often the same one as
there is only one search view.
Only 3 occurences are real misbehavior.
Note that the `name` of the pair is useless, you can just pass the ID in an
array.
Working:
'search_view_id': [123, 'search'],
'search_view_id': [123],
Not working:
'search_view_id': 123,
closesodoo/odoo#72247
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Consider the following example:
1) Create tax ONE, 10%, include_base_amount=True
2) Create tax TWO, 20%, is_base_affected=False
Create an invoice with just one line of 100€, with taxes ONE and TWO (in this order).
The journal entry then contains:
- The payable/receivable line => 130
- The base line => 100
- The tax line for ONE => 10
- The tax line for TWO => 20
The bug this commit fixes concerns the tax_ids set on tax lines. In our example, none should be set, since tax TWO is not affected by ONE. But tax line for ONE actually had tax_ids=TWO, hence impacting TWO's base. This was wrong; the base for TWO is 100, not 110.
closesodoo/odoo#72063
X-original-commit: ff2d1728c835e7d43638502d69245291d0fa3c59
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Small fixup of recent commit 5800f20ccf63ef8482d1460f46c8c5fe30eac822.
It can happen that line_residual is equal to line_residual_after_reconciliation.
This should lead to a zero reconciled percentage instead of a ZeroDivisionError.
closesodoo/odoo#72064
X-original-commit: 9cc8ac4a86fff81af397c89fbbc197bec222622e
Signed-off-by: William André (wan) <wan@odoo.com>
The accounting date must be today by default and changing the bill date
must not affect that.
Kind of followup after this change of behavior fcaa54939e9a4f0dd5e47cd0ccffe7aa24bd451c
task-2550985
closesodoo/odoo#71977
X-original-commit: c63af09774414a004ef34644b4f38b4fdb1d12bd
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
In `_remove_tax_used_only_by_self`, as tags will be properly
removed in `_delete_tags_from_taxes`, we should only remove
them from the `self.tag_ids` set without unlinking them
(unlink them at this step, might lead to issues if these tags
are still linked to `account.move.line` for example).
As stated in https://github.com/odoo/odoo/blob/7444857b631e4c26ac1f13e6c29dfaa6b4c66359/odoo/models.py#L3549-L3555
we use the command `3` instead of `2` to achieve this.
upg-61375
closesodoo/odoo#71969
X-original-commit: 6a85debb540bf9281b10f8a95be1ff0b4491eabc
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Replace text fields to html fields as we have our own 'OdooEditor'.
Indeed, it gives more options to users in the way they format their
content without weighting too much on the UI
(tools appear on demand and not by default).
Models -> Fields
1) account.move -> narration
2) account.payment.term -> note
3) account.fiscal.position -> note
4) res.company -> invoice_terms
5) res.config.settings -> invoice_terms
Task Id: 2499504
X-original-commit: 0f3c7f153e8bd20f83b7d1df031634996d36935b
rounding_line_vals is invoked directly with a .create(), so the "currency_id" key's value should be an integer. See line 810.
This is hard to catch, i use Sentry on my servers and i found this bug. I cannot provide steps to reproduce, as i just see this bug report in Sentry.
closesodoo/odoo#71771
X-original-commit: 38de8fc52b4d6f6bdab4dd5e28eb9e3e5315145c
Signed-off-by: William André (wan) <wan@odoo.com>
Users may want to be able to have transactions coming from multiple
payment acquirers to be registered in the same journal.
This will allows that.
Task id #2414749closesodoo/odoo#67331
Related: odoo/upgrade#2500
Related: odoo/enterprise#17258
Signed-off-by: William André (wan) <wan@odoo.com>
- Enable cash basis (Accounting>Settings>Taxes)
- Enable analytic accounting (Accounting>Settings>Analytics)
- Have a sale tax:
- Based on payment (Account 10100 Current Assets)
- Included in Analytic Cost
- Create a [DEMO] product with such tax
- Create an invoice with 2 lines:
- One line with product DEMO and whatever analytic account
- One line with product DEMO but no analytic account
-Confirm and receive payment
CABA entry will consider only 1 tax line, because the
2 entries are equal beside the analytic account which is not considered
in the grouping keys
opw-2507417
closesodoo/odoo#71556
X-original-commit: 2a8f777c04bdbdce77dc44d92e099612f158cbef
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Tax groups configuration is now checked differently, and by country. Tax groups are considered properly configured if all the groups used by active taxes from that country have a tax receivable and tax payable accuont defined (by default or not) for the company.
To make the account.account form view usability better, we'll move around the fields,
add a new smart button to link the account to the taxes using it as well as
add a chatter to keep track of changes.
Task id #2481421closesodoo/odoo#69851
Related: odoo/enterprise#17943
Signed-off-by: William André (wan) <wan@odoo.com>
When using the "Send & Print" functionality, if the user adds an
attachment, the latter won't be linked to the record.
To reproduce the error:
1. Open a posted invoice
2. Send & Print
3. Attach a file > Select a file on your device
4. Send the email
Error: The invoice's PDF is added to record's attachments, but not the
other file (from step 3).
When the module selects the attachments that need to be linked to the
invoice, it only keeps the ones currently linked to `mail.compose.message`:
https://github.com/odoo/odoo/blob/6441ab71cb68648aa735057952bf757677a20ee3/addons/mail/models/mail_thread.py#L1719-L1725
This is correct when the user creates a message directly in the chatter.
However, when the mail is created thanks to `Send & Print` functionality,
the attachment is linked to `account.invoice.send`.
Another flow have a similar issue: from invoices list, select few ones,
Action > Send & Print: the generated PDF won't be attached to their
invoice. In such a situation, here is the source of the problem:
https://github.com/odoo/odoo/blob/05ad6c477f7da2a495e5baf5b4629323b9d11fa0/addons/mail/wizard/mail_compose_message.py#L363-L367
There isn't any information about the invoice, therefore it is not
possible to linked the attachment to it.
OPW-2438457
closesodoo/odoo#71495
X-original-commit: 98d3748aca724ef06db89294531d82679df45b74
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
A FEC file (Fichier des Ecritures Comptables) contains all the accounting data and entries recorded
in all the accounting journals for a financial year. In order to make the onboarding of new users
easier, Odoo Enterprise's French fiscal localization includes access to the ``l10n_fr_fec_import``
module, that enables the import of existing FEC files from older software to the Odoo database.
The imported data are:
* accounts
* journals
* partners
* journal entries
Every entity is imported with a generator that reads the values from each line, ready to be loaded.
The entity (only accounts for the moment) is then completed with data from the CoA's templates
and imported in the database. Journal entries are posted and reconciled.
The Odoo branch implements the install checkbox in the Settings > Accounting page for an easy install.
Task 2515785: https://www.odoo.com/web#id=2515785model=project.task
Documentation PR: odoo/documentation#979closesodoo/odoo#71290
Related: odoo/enterprise#16704
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
In order to not show unnecessary tax groups when configuring a tax,
we'll now filter them to only shows the tax groups that are either
linked to no country, or that are linked to the same country as the tax.
Task id #2206280
The display name of cancelled entries is "/"
This provides no information to the user - especially when the duplication message is logged.
This aims to improve the display_name of account.move so draft and cancelled entries display the id as a reference
closesodoo/odoo#70764
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Original issue:
Create a payment like follow:
Payment type: receive money
Partner type: customer
Destination account: whatever receivable
Amount: define an amount (i.e. 90.00)
On Save, open the draft jounral entry created.
Lower the liquidity or counterpart amount and add a writeoff
Go back to the payment, change the amount and save.
The journal entry writeoff will swap from debit to credit at every
change made to the amount. This occur also when changing currency on the
payment
opw-2475223
Otherwise, this fix is not covering all cases:
inbound with write-off in debit
inbound with write-off in credit
outbound with write-off in debit
outbound with write-off in credit
closesodoo/odoo#70903
X-original-commit: 01b9bff35e85fafb1a50bb0819123d186acf4925
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The value taken into account in the SQL for the calculation were wrong:
- Not based on the state of the invoices (cancelled and draft
were taken into account)
- Had the tax included
opw-2464004
feedback-2478356
closesodoo/odoo#71088
X-original-commit: 8b0e438af24883f979cb54eb046564e4e2a3f64c
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: bve-odoo <Abridbus@users.noreply.github.com>
Habib (ayh)