- Create a TAX A and TAX B
- Create a fiscal position, and TAX A in scr and TAX B in dest, and add other tax map
- Use this fiscal position in POS
- A month latter unactive TAX B (because the law have change).
--> You have an issue during opening the pos

closes odoo/odoo#80739

Signed-off-by: Masereel Pierre <pim@odoo.com>

Current behavior :
Quantity displayed on 'Detailed operations' block for a product lot isn't correctly displayed on the invoice sometimes.

Steps to reproduce : 
- Install Sales and Stock
- Enable 'Units of Measure' in Settings
- Enable debug mode then go to Users and enable 'Display Serial & Lot Number on Invoices' for current user (i.e. Mitchell Admin)
- Create a new product
  - Tracking set to 'By Lots'
  - UoM set to 'g'
- Create a quotation with the previously created product and set the quantity to 3.07
- Confirm the quotation, go to the Delivery and confirm it too
- Go back to the SO and create the invoice, then go to the invoice and confirm it
- Print the invoice

OPW-2704307

closes odoo/odoo#81313

Signed-off-by: Arnold Moyaux <arm@odoo.com>

If you create an individual contact that has a company contact as the
parent, it will inherit certain fields from that parent, which are
defined by `_address_fields` in `res.partner`.

`base_address_city` allows enforcing picking a city from a pre-defined
list, which gets stored in `city_id` instead of the standard free-text
`city` field on `res.partner`. If you change `city_id`, an `onchange`
will update `city`.

`city_id` was not being inherited from the parent, which means the
contact ends up in an inconsistent state: `city` will be set, but
`city_id` will not.

In the Colombian accounting localization, which uses the enforced city
feature, a municipality code which is part of the record behind
`city_id` is mandatory in certain electronic invoice XML fields that get
sent to Carvajal. This value will incorrectly be 0 if `city_id` is not
set on the contact due to the above issue, causing the invoice to be
rejected.

This fix lets a contact inherit the `city_id` from its parent if
`base_address_city` is installed.

opw-2638687

closes odoo/odoo#81239

X-original-commit: e4345c81
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Raf Geens <raf@odoo.com>

It should be allowed to pay amount that are not rounded if the value is less than the rounding value.
Ex:
Rounding value: 0.05
Amount to pay: 0.04
The amount to pay should remain 0.04 and not be rounded to 0.05.

This fix allows the user to pay for values under the rounding value without applying the rounding.

closes odoo/odoo#81330

X-original-commit: 76ccaaf0
Signed-off-by: Masereel Pierre <pim@odoo.com>

Expected behaviour

When having multiple promotions with, for example, a promotion of X% for the
first order and a promotion of Y% (Y<X), we should apply the first promotion
on the first order and then don't get this promotion into account to choose
the best promotion for a future order, so that we have:
1. A promotion of X% on the first order
2. A promotion of Y% on every other order

Observed behaviour

When trying to apply promotion on other order, nothing seems to happen, as
Odoo take the already-used X% promotion into account, being the most
interesting promotion, select it as the best promotion to apply and then
apply it to finally get a result of a 0% discount as the promotion has
already been used.

Problem Root Cause

As it can be seen in the commit, the error comes from the fact we filtered
the available promotion with a non-strict inequality.

Validation

A test has been added in test_program_numbers.py to validate our fix

Related issue

- opw-2674681

closes odoo/odoo#81308

X-original-commit: d2c58a9d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Hendrickx Anthony (anhe) <anhe@odoo.com>

When an event is created from an external calendar account such as
Google or Outlook, attendee info such as email and state may be given,
and should be taken into account.

For example, if the current user who is syncing his calendar is not
the organizer of the event, his attendee state should be set to
'needsAction' and not automatically set to 'accepted'.

opw-2489815

closes odoo/odoo#79313

Signed-off-by: Arnaud Joset <arj@odoo.com>

As explained at https://github.com/odoo/odoo/blob/171e42e380a46463b4359166955dc4c5f6ccf42e/addons/google_calendar/models/calendar.py#L206

,
When there is no Odoo user who is the owner of the updated event,
modification are limited to some fields only.

In this case, that means we must use the `PATCH` method instead of the `PUT`
one to avoid erasing all not modified fields such the event name.

opw-2694739

closes odoo/odoo#80074

Signed-off-by: Arnaud Joset <arj@odoo.com>

The requirement of having real_time valuation in product categories to use LC is not needed
at all, as the information is taken from stock.valuation.layer, but it was previously
enforced due to the leftovers of the previous algorithm.

We remove such requirement in this commit, and also not creating the LC journal entry in
such cases.

TT32954

closes odoo/odoo#80975

X-original-commit: 81ad4d6a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@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

closes odoo/odoo#81240

Related: odoo/enterprise#22827
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>

This solution is not perfect. In order to be, we would need to have a
sanitized function that is used to store the number in the database, and
to use the same function to search in it. This will most likely be done
in master with a refactoring of `base_vat`, on which `account` will
depend one way or another.

In the meantime, we need to support cases that were working before these
fixes:
https://github.com/odoo/odoo/commit/bfb2436b9d99bf9eea29ee44000e18197efa88b6
https://github.com/odoo/odoo/commit/e24c5ba4efef466919735ec4304cfd46be5f0d3f



Since these, it was indeed impossible to detect a partner based on his
VAT for Swiss partners if `base_vat` was installed, which is the
default.

closes odoo/odoo#81227

Signed-off-by: Olivier Colson <oco@odoo.com>

How to reproduce the bug:

- install l10n_de
- in Settings/General Settings/Business Documents, configure document
  layout to DIN 5008
- try to print one of several:
   => timesheet entries
   => direct debit mandates
   => follow-up reports

Bug:

When you use the DIN 5008 report defined in l10n_de, the o variable is
defined which generates an error.

closes odoo/odoo#79848

Opw: 2659703,2699563,2649221
Signed-off-by: William André (wan) <wan@odoo.com>

closes odoo/odoo#81200

X-original-commit: ad12b854
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

In Argentinean localization, we are making inactive some document types in a
no-updatable xml view to keep the user configuration when the module is
updated. This fix is to avoid the possibility of inactivating doc types
from other localizations with the same code.

closes odoo/odoo#80577

X-original-commit: b7531c4e
Signed-off-by: Josse Colpaert <jco@odoo.com>

This fixes inconsistencies when dealing with fields that are computed
and inversed by the same methods.

Consider two fields F1, F2 with the same compute and inverse methods.
Consider a record where we wrote on a dependency of the common compute
method.  At this point, both fields F1 and F2 are marked to be computed.

Now let us write on F1 only.  Here is what happens:
 - the write discards the computation of F1, but not F2
 - the inverse method of F1 is called:
    - the method accesses F2
       -> this calls the compute method, which assigns both F1 and F2
    - the method accesses F1
       -> the value of F1 has been replaced by the computation above

The issue comes from a combination of factors:
 - the value of F2 must be determined by the computation;
 - the computation assigns both F1 and F2;
 - the computation is done while inversing F1 (and F2).

The solution is to force the computation before actually writing on the
fields and calling their inverse methods.  Note that this is necessary
only when part of the fields computed by a common method are updated.
When all fields computed by a common method are updated, the computation
will automatically be cancelled.

closes odoo/odoo#81152

X-original-commit: fb4d6ee4
Signed-off-by: Raphael Collet <rco@odoo.com>

The message displayed to the user was not translated

closes odoo/odoo#81065

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Part-of: odoo/odoo#81065

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
odoo/odoo#69377
odoo/odoo#66347
odoo/odoo#61758
odoo/odoo#54355
odoo/odoo#43180
odoo/odoo#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to odoo/odoo#62139

closes odoo/odoo#81127

X-original-commit: d99e173b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>

The commit ca7d5701 fixes issue with
backorder being to quickly canceled but as it call `action_cancel`
before the condition who's looking on the SO state, the condition can
never be matched as the SO state will always be `cancel`.
So, the exception about the SO being cancelled will not be logged on
following documents.

How to reproduce:
  - Create a product and enable route MTO + Manufacture on it and create
    a BoM for this product;
  - Create a SO for this product and confirm it;
  - Cancel the SO and check the generated MO => There is no exception
    about the cancellation of the SO.

This commit fixes this issue and doesn't impact the previous fix.

task-2657799

closes odoo/odoo#79215

Related: odoo/enterprise#22008
Signed-off-by: Arnold Moyaux <arm@odoo.com>

Before this commit when covers were edited from their list view (e.g.
changing their background color from the blog posts list or from the
events list), the resize class was lost.

After this commit the resize class is kept from its previously saved
value if it is not a parameter during edition.

Related to task-2359250 and task-2678100

closes odoo/odoo#77018

Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>

How to reproduce:
1: create two employees (A B)  and two departments (C D)
2: Assign A as manager of C and B as manager of D
3: Assign C as A's department and A as A's manager
4: Change A's department to D -> A is deleted

This is due to `parent_id` being both a computed field and the source
field for a One2many. By changing the `department_id` the `parent_id`
also changed which results in it being report in the `onchange` method.
For some reason however the command sent by the orm is not `UNLINK` but
`DELETE` which results in the `active_id` being deleted.

TaskId-2711428

closes odoo/odoo#81135

X-original-commit: 3ec9dcc5
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

when we crop illustrations using the editor crop tool,
the resulted image will disappear as soon as we save the update.

we have this issue because we cannot get the right svg string using
toDataURL on the new cropped canvas with mimetype = 'image/svg+xml'
(see 'web_editor.image_processing' > 'applyModifications')

To solve this issue we set svg illustrations as uncroppable (for now).

task-2312878

closes odoo/odoo#59536

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Steps to reproduce:
- Install and launch sales
- In settings: activate price lists and discount; price list based on advanced rules
- Create a new price list; based on percentage (54%)*; applicable on all products; show discount
- Make sure the Public Price List has show discount activated
- Create a new quotation
- Select the Test pricelist
- Select a product (price 0.03 eur/$/other)*
- Change the price list to Public price list
- update the prices
- change the price list to Test price list
- update the prices
-> The Discount shown is not the one defined in the price list (66.67%)*
*(values for my example)

Solution:
Use the real price and not the a posteriori-rounded price for the computation of the discount  in the `update_prices` method.

opw-2677884

closes odoo/odoo#80706

Signed-off-by: yosa-odoo <yosa@odoo.com>

Current behavior:
Invoices report had a wrong average price when invoice had credit note

Steps to reproduce:
Create a db with accounting
Create a customer C and a Product P
Create an Invoice for C for 10 pieces of P
Create a Credit note for C for 1 P
Go to Reporting > Invoice Analysis
Open the pivot view, in the Measures, display the Average Price, the Product quantity and the Untaxed Total
The Total multiplied by the quantity is not equals to the average.

opw-2557420

closes odoo/odoo#79609

Signed-off-by: William André (wan) <wan@odoo.com>

- allow to match a partner having 'BE0477472701' as vat but '477472701' inside the xml.
- code cleanup as suggested in the original PR

Introduced by https://github.com/odoo/odoo/pull/80266



closes odoo/odoo#81120

Signed-off-by: Olivier Colson <oco@odoo.com>

Due to floating point representation, some floats may have some
insignificant decimals. Therefore, `float_compare` should be used when
comparing such numbers

OPW-2699576

closes odoo/odoo#81118

X-original-commit: 7f30ef42
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

When editing the billing address of an existing portal partner P,
the salesperson of P was changed by the default website salesperson

BACKPORT of 52442484

opw:2649732

closes odoo/odoo#81073

X-original-commit: f7b8a07a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Simon Goffin <sig@odoo.com>

Creating employee from applicant was not providing the default
home_address_id

closes odoo/odoo#80939

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Part-of: odoo/odoo#80939

Improve matching on vat: 'BE0639876138' should match '0639876138' or '639876138'
Retrieve first partners having the same company as the invoice.
Match partners on vat first, then contact info (email, phone), then on name.

closes odoo/odoo#80266

Issue: 2694097
Signed-off-by: Olivier Colson <oco@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/79737



closes odoo/odoo#80418

Related: odoo/enterprise#22767
Signed-off-by: Olivier Colson <oco@odoo.com>

This is a backport of [1] which for some reason was merged in 14.3
instead of 14.0 directly. It is now important to have it there as the
theme tours will be run during tests.

Useful when debugging: launching the themes tours automatically will
build the page with the snippets in the right order.

[1]: https://github.com/odoo/odoo/commit/2ee9d4009fa62124dad5410d5bfdca572237dc65



closes odoo/odoo#80936

Related: odoo/design-themes#532
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

A wrong field is used to control propagation of questions from event template
to child events. Currently an event template must use automated emails to
propagate its questions, instead of correctly checking the question enabled
field ``use_questions``.

As most templates use automated email this was not seen before.

Task-2703285 (event performance)
Task-2703289 (event testing)

closes odoo/odoo#81044

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

When consulting the Purchase Analysis, the measure "Days to Confirm" may
not be easily understandable

To reproduce the issue:
1. Create a purchase order PO:
    - Order Deadline: <today + 10 days>
    - Add 2 products
2. Confirm PO
3. Purchase > Reporting:
    - Measures: Days to Confirm
    - Group By: Order

Error: For PO, the value of "Days to Confirm" is -20, it should be -10

The report computes the sum of the delay (i.e., "Days to Confirm") of
each purchase order line. Computing an average seems more relevant

A similar flow could be reproduce with the measure "Days to Receive"
(i.e., the difference between the Order Deadline and the Receipt Date)

OPW-2678673

closes odoo/odoo#80985

X-original-commit: 80e71545
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

When you need to add certain details to the data in order to make a
maintenance request. I can't do it using the old code.
As a result, I've included a hook method to be more flexible with
customers.

closes odoo/odoo#80819

Signed-off-by: Arnold Moyaux <arm@odoo.com>

[FIX] account: Add missing sudo for https://github.com/odoo/odoo/commit/0cb9d03cb7c7d6261f57e932e553caf179499827



closes odoo/odoo#81022

Signed-off-by: Florian Gilbert <flg@odoo.com>

When selling a storable kits, the consumable components should be
ignored in account lines

To reproduce the issue:
(Need account_accountant,sale_management,mrp)
1. Create a product category PC:
    - Costing Method: FIFO
    - Inventory Valuation: Automated
2. Create 3 products P_kit, P_compo01, P_compo02
    - P_kit:
        - Type: Storable
        - Category: PC
    - P_compo01
        - Type: Storable
        - Category: PC
        - Cost: 5
    - P_compo02:
        - Type: Consumable
        - Category: PC
        - Cost: 6
3. Update P_compo02's on hand qty: 1
4. Create a bill of materials:
    - Product: P_kit
    - Type: Kit
    - Components:
        - 1 x P_compo01
        - 1 x P_compo02
5. Create & Confirm a sale order SO with 1 x P_kit
6. Process the related delivery
7. Create & Post the related invoice

Error: The journal items of the invoice are incorrect, the value of
Expenses and Stock Interim (Delivered) are $11 instead of $5. The
consumable components should be excluded from this value

OPW-2604084

closes odoo/odoo#81002

X-original-commit: 5de45100
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

Have a [TEST] product tracked by serial number
Create a SO with [TEST], quantity N (at least 2)
Add FEDEX int. delivery to the order
Validate and confirm delivery

On the shipping invoice the product is reported on N lines, one for each
serial number, but the price is not splitted accordingly so the total of
the invoice will be the original price multiplied by N

This commit revert f3488749
not needed anymore after
e13f048a

opw-2703581

closes odoo/odoo#80930

Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

closes odoo/odoo#80990

X-original-commit: 567a8380
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Release notes: https://github.com/odoo/owl/releases/tag/v1.4.10



closes odoo/odoo#80981

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>