closes odoo/odoo#97569

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

Steps to reproduce:
- Create a quotation
- Add a product that is invoiced on "ordered quantities" and set the
  quantity to a negative number.
- Leave 'delivered' to 0
- Confirm the quotation
- Create the Invoice and validate it.
- Go to the SO list view (Orders > Orders)

You should see that the Invoice Status of the order you just created is
'Upselling Opportunity', which is not correct.

Why this is happening:

Here's an explanation on the 'Upselling Opportunity' state (found in
the code):
" upselling: this is possible only for a product invoiced on ordered
quantities for which *we delivered more than expected.* "

In our case, the invoice line's state is set to 'upselling'
because we have a negative ordered quantity and a zero delivered
quantity (i.e. we delivered more than expected)

opw-2895218

closes odoo/odoo#97555

X-original-commit: 8480ce07
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>

In order to perform reverse charge self-invoicing, a company must have
its codice destinario (pa index) defined. This commit adds a valid
pa_index (from the sdicoop test channel) to the demo company.

closes odoo/odoo#97572

Signed-off-by: Josse Colpaert <jco@odoo.com>

To reproduce
============

Enable "Qr Codes" under Accounting Settinsgs > Create Invoice > set "Payment QR-code" method (tab "More Info")
> issue Credit Note > try to "Send and Print" credit note > Error:

` The chosen QR-code type is not eligible for this invoice. `

Specification
=============

Generating QR code on Credit Note doesn't make sense, so the field `qr_code_method` is set to `False`
when creating a Credit Note.

opw-2900112

closes odoo/odoo#97018

Signed-off-by: Josse Colpaert <jco@odoo.com>

According to
www.agenziaentrate.gov.it/portale/web/guest/schede/istanze/richiesta-ts_cf/informazioni-codificazione-pf

The tax identification number of natural persons
consists of an alphanumeric expression of sixteen characters.

The first fifteen characters are indicative of the master data
of each individual in the following order:

- 3 alphabetic characters for the surname;
- 3 alphabetic characters for the first name;
- 2 numeric characters for the year of birth;
- 1 alphabetic character for the month of birth;
- 2 numeric characters for the day of birth and sex;
- 4 characters, 1 alphabetic and 3 numeric for the Italian municipality
  or foreign state of birth.
The sixteenth character, alphabetic, serves as a control.

The main fix is about this part:

When two or more individuals have master data generating
the same tax code (homocodes), the tax code is differentiated
for each of them. For this purpose, systematic substitutions
of one or more digits starting from the right one are made
within the seven numeric characters contained in the code
with corresponding alphabetic characters according to the
following table:

0 = L 4 = Q 8 = U
1 = M 5 = R 9 = V
2 = N 6 = S
3 = P 7 = T

Also the check for iva number format was incomplete.
Indeed, The three penultimate digits correspond to the region of the
VAT office and must be between 001 and 100 inclusive,
or equal to 120, 121, 888 or 999.

We use the stdnum library's methods for the validation of fiscal code
and iva number format.

opw-2797408

closes odoo/odoo#95594

Signed-off-by: Josse Colpaert <jco@odoo.com>

When issuing a refund for a reverse charge bill, the document type
should be the same as the parent bill type (either TD16, TD17 or TD18,
rather than TD04), and the values of the lines and totals should be
negative.

To fix this the values are made negative dependent upon whether the
invoice is a 'rc_refund' as in a "reverse charge refund". The way that
the document type is ascertained is also changed in order to include the
'in_refund' (for the case of the reverse charge refund).

The way document_total (ImportoTotaleDocumento) has been made
conditionally negative in the case when the invoice is a reverse charge
refund.

A test has been added for the reverse charge refund case, and the test
taxes have been adapted so that the correct tags are being used (and so
that tags are used on the refund lines).

closes odoo/odoo#97263

Ticket-id: 2936967
Signed-off-by: Josse Colpaert <jco@odoo.com>

closes odoo/odoo#97503

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Steps to reproduce:

  - Switch odoo language to french
  - Create a client bill for Azure Interior of $1 000 000
  - Confirm it
  - Go to the accounting dashboard
  - On the bank, click on reconcile
  - Select Azure interior
  - Click on the correct bill
  - Switch to Manual operations
  -> $1 000 000 is not a correct monetary field

Cause of the issue:

  Recently in https://github.com/odoo/odoo/pull/94126

 , `formatMonetary`
  switched from joining the currency and symbol from ` ` to a non
  breaking space, NBSP.
  To parse monetary values, the behavior was to split around NBSP to
  get the symbol on one side and the value on the other which is then
  passed to `parseFloat`.

  For the following examples, NBSP is replaced with an underscore.
  So `$_1000` becomes `$, 1000`
  But some languages such as french uses the same char as thousands
  separator.

  In that case, `$_1_000` becomes `$, 1, 000` and then the parse fails.

opw-2937403

closes odoo/odoo#97462

X-original-commit: 9d367227
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>

Prior this fix, creating an action with (e.g.)
additional_context : {create: 0} wouldn't have any effect
on calendar view.

Now, if this context key is added, the user won't be able to create.
Also true for delete and write.

closes odoo/odoo#97022

Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>

This old file is indented with tabs instead of spaces.
This is a problem because the file is using as template to
write new localization.

closes odoo/odoo#97452

X-original-commit: 56f9e90d
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>

This commit fixes a glitch on iOS (both iPhone & iPad landscape) where,
when the user attempts to open the datepicker of a custom filter's
field, it pops up and immediately close.

This is due to the desktop behavior which hides datepickers on scroll to
avoid hidding fields behind it.

In our case, a scroll is triggered once the focus is set in the date's
input and the virtual keyboard opens up... which then hides the
datepicker!

Sadly, this behavior's purpose being still useful in desktop, we don't
have much other solution than "just" disabling it on affected platforms
(ie. iOS) as it affects both small screens (ie. iPhones) and
dekstop-like ones (ie. iPad).

Hopefully, a better solution will be found at some point in a future
version, avoiding this kind of "trick"...

Note: replacing the "scroll" event with the "wheel" event seems to fix
the issue at first glance... but actually has side-effects for devices
using both touchscreens and a mouse (ie. 2-in-1 laptops).

Steps to reproduce:
- Open any collection view (list, kanban...)
- Open "Filter" dropdown and add a custom filter
- Choose a date/datetime field (ie. created_on)
- Tap the input
=> datepicker opens up and close immediately

opw-2671618
opw-28192998

closes odoo/odoo#97467

Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>

Before this commit, the lang entries in the language switcher's dropdown
would overflow the dropdown (which was way too small).

There were no issue in 13.0 as the issue seems to have appeared since
commit [1] which was merged in 14.0 (13.5 at the time).
That commit added a `min-width: 0;` on the `.dropdown-menu` making the
dropdown visually broken in rtl languages.

There is no issue in saas-15.5 (current master) as it was converted to
BS5 where the issue do not appear.

There is probably a cleaner solution to be found to have a full
understanding of the real issue and probably make a generic solution
instead of only fixing footer language selector, but this would need to
spend more time investigating the issue.
As the error seems gone with BS5 anyway, and only this dropdown seems to
be impacted, this is a reasonable fix.

[1]: https://github.com/odoo/odoo/commit/745ef9de97544d5c1a97e03be67e903feca40c2a



Fixes #64774, fixes #63764
opw-2904798

closes odoo/odoo#96455

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

Purpose
======
When creating a specific Operation Type of type 'Manufacture' the default
operation type is not the correct one on object creation.

So in this commit, we set default `Operation Type` in picking when Type of
Operation is `Manufacture`.

taskID - 2939078

closes odoo/odoo#97299

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

As a stable fix, to not touch XML templates and break existing
translations, the ⌙ character is automatically replaced by └ which makes
more sense for the usecase and should work properly in all browsers. The
⌙ character is actually rendered mirrored on Windows 11 Chrome (and
others) as the font used for those unicode characters is left to the
browser. We could force a font of our own but it's probably not worth it.

A better solution with a SVG or CSS solution has to be done in master.
That would unify the look of the symbol across all browsers and
also prevent special characters to be placed in translations.

closes odoo/odoo#97338

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

The button to select a template when using the editor was hidden on
a012019c because it was deemed useless. However, the way to determine
what button to hide relies on the button text, which doesn't work when
we're on a different language.

To solve the above, button is now identified by other attributes
(tabindex and accesskey).

closes odoo/odoo#93768

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

Before this commit, If "Show public price & discount to the customer"
discount display policy is selected, taxed prices in the pricelist with
discounts are compared with untaxed prices in the public pricelist,
which leads to not showing the discounted values when the pricelist
value is less than untaxed list price, but the taxed value is more than
untaxed list price.

Steps to reproduce:

1. Create a product, add it to a pricelist with a lower price in a way
 that if the tax is added the price is more than its sale price, add a
 tax option to the product
2. Set the pricelist discount display policy as `Show public price &
discount to the customer`
3. Set the PoS to use tax-included prices, and to use the discounted
pricelist
4. start the PoS session, add the product, you will see that the
public price isn't shown (with a strike-through)

To fix, we can use a different function that computes the taxed public
price, so it could be compared with the pricelist price.

opw-2919734

closes odoo/odoo#96749

Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>

Sometimes, no picking type match the domain, but picking_type_id is a required field.

closes odoo/odoo#97250

X-original-commit: afcad067
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

backport of  #85323

closes odoo/odoo#97242

X-original-commit: 01feeb84
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Co-authored-by: auon-odoo <auon@odoo.com>

Install Documents
Open Settings > Documents, enable 'Accounting' files centralization
Configure 'Journals' with a single line
- Journal -> Vendor Bills
- Workspace -> Finance / Supplier Invoices
Now in go to Accounting>Vendor>Bills
Upload an xml representing a vendor bill, including an attachment
encoded in the <Allegati> tag
Open created bill

Traceback. The error is caused by the attachment included in the xml
registered without res_id/res_model.
In the document flow the attachment will receive a res_id, but not the
res_model, causing the traceback when retrieving the attachment

opw-2919610

closes odoo/odoo#97061

Signed-off-by: Josse Colpaert <jco@odoo.com>

It is currently impossible to modify the _cart_update behavoiur from website_sale_stock

The sale.order method _cart_update() updates the lines on the e-commerce shop
cart, some modules override the method adding new features, the module
website_sale_stock is one of them.

The specific behavior of _cart_update() in the module website_sale_stock allows
to delete from the sale order the products whose demand is greater than the stock.

If the specific behavior of the module website_sale_stock is needed to be
expanded or totally changed, that is not possible because the method _cart_update()
should be always super called, even if the website_sale_stock code for
_cart_update will be totally changed.

To allow inheriting just the specific behavior of website_sale_stock without
affecting other modules. This commit creates a new method _cart_lines_stock_update()
which have the important behavior for this module and will allow to be
easier to inherit it.

Based on: https://github.com/odoo/enterprise/commit/f5d92e70aaa472324cc1f0374ddb108d100bec59



OPW#2500355

closes odoo/odoo#97195

X-original-commit: 1e3adbf6
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

The below line raises a KeyError when `warehouse` refers to an archived
warehouse.
https://github.com/odoo/odoo/blob/01cc43b0578ecc9d1fed37a12b2468ffc9d4aedd/addons/stock/models/stock_orderpoint.py#L396

The reason is that the SQL view created on
https://github.com/odoo/odoo/blob/01cc43b0578ecc9d1fed37a12b2468ffc9d4aedd/addons/stock/report/report_stock_quantity.py#L28-L37


doesn't take into account whether the warehouses are archived or not.

The solution proposed here is to fetch all warehouses to ensure the
lookup doesn't fail. Alternatively the view could be updated but that
will be a bigger change.

This issue was detected during the upgrade 226754

closes odoo/odoo#88204

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

When getting the on hand quantity of a product in a specific location,
the result may be incorrect.

To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create a storable product P
3. Update its quantity:
    - 5 x P at WH/Stock/Shelf 1
4. Inventory > Reporting > Inventory Report
5. Apply the following filters:
    - Product: P
    - Location: WH/Stock/Shelf 1
    - => There is a line with 5 x P at WH/Stock/Shelf 1, which is
correct
6. Click on Inventory at Date, set <Today>, confirm
7. Apply the following filters:
    - Product: P
    - Location: WH/Stock/Shelf 1

Error: There is a line for P but its on hand quantity is 0, which is
incorrect (should be 5)

In the first search, we let the ORM handle the domain conversion. When
searching for `('location_id', 'ilike', 'WH/Stock/Shelf 1')`, it will
use the `_rec_name` of the model to find the record. In case of a stock
location, its `_rec_name` is the field `complete_name`:
https://github.com/odoo/odoo/blob/94a8ad3fae914b046064bb7ce17572be8280f6e0/addons/stock/models/stock_location.py#L19



However, for the second search, when getting the on-hand quantity of the
product, we force the use of the field `name` to find the location.
Because the `name` of the searched location is "Shelf 1", using
"WH/Stock/Shelf 1" as key search will not work.

OPW-2920904

closes odoo/odoo#97091

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

Original PR: #96572

closes odoo/odoo#97168

X-original-commit: 5a53d0d6
Signed-off-by: Kevin Baptiste <kba@odoo.com>

Open Accounting>Journal Items
Select 1+ items with 0 credit/debit
Hit Actions>Automatic Entries
In the wizard choose 'Change Period', select an Accrued Account with
'reconcile' flag and confirm

Error will raise 'You are trying to reconcile some entries that are
already reconciled.'
This occurs because new entries, with 0 balance, will be created to match
the selected one. The flow include a reconciliation step in which the 0
balance will raise the error.

With this patch the problematic lines will be created but not reconciled

opw-2909058

closes odoo/odoo#96733

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

Step to reproduce:
	- install sale, accounting and l10n_de
	- activate proforma in sale settings
	- set the template to external_layout_din5008 in the settings (use developer mod)
	- create sales order or quotation
	- print it as a proforma

Current behavior:
	- the proforma is missing from the title in the document

Behaviour after PR:
	- the proforma is in the document title

The l10n_de_sale module was missing the case scenario of a proforma sales report and the sale module only
gives the information of a proforma report in the xml context. Then we add the case scenario and propagate
the proforma info from the sale module also in the python context using the proforma variable.

opw-2796603

backport of bb9db7e2c95a161b240977baf4e526c5b03c5842

closes odoo/odoo#97039

Signed-off-by: Josse Colpaert <jco@odoo.com>

Check whether the product ID of the first item exists inside product_data
before trying to access it. Although it means the first item still does not
appear, both products will be present in the user's cookies.
When the user refreshes the page or navigates away, both products will be
visible in the comparison panel.

closes odoo/odoo#97124

X-original-commit: 5c6a92d0
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

When the payment reference on an invoice is empty an error occurs when
trying to generate the edi xml. The error comes from trying to retrieve
a slice on a bool.

To solve this, a t-if has been added in this commit, such that the
function is not called when the field is empty.

closes odoo/odoo#97089

Signed-off-by: Josse Colpaert <jco@odoo.com>

In the XML, on the field holds the untaxed amount but it should have the taxed amount.
The field inside the xml correctly takes the total amount of the
invoice, but on the invoice in Odoo when using a RC tax, the tax amount
is 0 in Odoo, so the total amount will be as it is untaxed on the XML.
That's because the repartition lines are +100%/-100% distributed, but in
the self-invoice they must be exported as +100%, so we re-add them to
the total.

Task link: https://www.odoo.com/web#id=2936967&model=project.task


opw-2936967

closes odoo/odoo#96686

Signed-off-by: Josse Colpaert <jco@odoo.com>

closes odoo/odoo#96611

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

- Add translations for fr, de
task-2928312

closes odoo/odoo#96286

Related: odoo/enterprise#29625
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>

Steps to reproduce:

  Create a new DB with `-i l10n_ar_website_sale` and `--test-enable`

Issue:

  Multiple test fails.

Cause:

  By installing only a l10n module, main company will be altered
  (espcialy the fiscal country and currency among other things).
  By doing so, it will raise at least 2 issue:
  - Previous pricelists linked to main company got the previous currency
  - Some fields can be required (depending company fiscal country)

Solution:

  - Alter company's website pricelist currency to match company currency
  - Reset country and fiscal country, so that fields added by
    localizations are hidden and non-required.
    Also remove default taxes from the company and its accounts,
    to avoid inconsistencies with empty fiscal country.

opw-2767684

closes odoo/odoo#96887

Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>

When redirected to the payment acquirer PayuLatam, if the amount is more than 2
decimals we can have two errors (invalid sign and unique reference).
Even with the decimal accuracy set to 2, we still can have a rounding issue and get
an amount like 1661.340000001

fixes opw-2900105

closes odoo/odoo#96974

X-original-commit: deaf27a7
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

As we allow editing balances in processing state, we do not want
to check balances before the validation of the bank statement
(only in case of a bank journal).
Commit about editing balances: 03f83eb8
This fix split the _check_balance_end_real_same_as_computed into
2 functions. One to check "bank" bank statement and one to check
"cash" bank statement. It allows to keep the same behavior for
a "cash" bank statement when we post the bank statement, and
having the right behavior for a "bank" bank statement.

opw-2835728

closes odoo/odoo#96829

Signed-off-by: Laurent Smet <las@odoo.com>

Because the sanitized fields can be made form-tolerant since [1], [2]
was not forwarded from 13.0 to 14.0, it made the newsletter snippets
rebuild their input in case they were saved in a sanitized field.
However there might be non-form tolerant sanitized fields, but in [3]
the newsletter snippets were not marked as `t-forbid-sanitize="form"`.

This commit marks the three newsletter snippets as forbidden in
sanitized fields that are not form-tolerant.

In 15.0, the donation snippets will need to be updated in the same way.

[1]: https://github.com/odoo/odoo/commit/388c222c6c4bb7e2fe3e67009b248359ae0fd3db
[2]: https://github.com/odoo/odoo/commit/b8d6a124b95bc37da489cbd07c5e1be8a3a5817b
[3]: https://github.com/odoo/odoo/commit/4c011256a1c799132012f01defd6f2c458889516



task-2829961

closes odoo/odoo#96841

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

This is a backport of [1].

Since [2] whenever the image of a `product.template` is updated, the
write date of all its related `product.product` is updated.  This was
done to force a change of the unique parameter on image fields, which is
based on the last update field.

After this commit the `product.product`'s last update is instead
computed by also taking the `product.template`'s last update into
account.  This avoids the need for updating the write date when the
image is changed, but on the other hand it also forces product images to
be reloaded whenever any other field of the `product.template` is
changed.

[1]: https://github.com/odoo/odoo/commit/620b0222506a91e73eac6e08f5d17d20e3a23230
[2]: https://github.com/odoo/odoo/pull/71139

Related to https://github.com/odoo/odoo/pull/76309



task-2477438

closes odoo/odoo#96774

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

When using the decrease quantity popup, there could be a traceback when clicking on the cancel button.
Step to reproduce:
  1) Add an orderline
  2) Change the quantity
  3) When the popup is triggered, press cancel

Now we only set values if the popup is confirmed.

closes odoo/odoo#96583

Related: odoo/enterprise#29788
Signed-off-by: Masereel Pierre <pim@odoo.com>

Following this commit: f864daa141cd2ab07c31c825aaee1b39be41cda4
There was an issue when clicking on a table and going back to the floor screen. An empty order was created.

In the case of a certification, order cannot be deleted.
We figured out that only one part of the previous commit was neccesary to avoid the double order in the back end.
We also add a check about order with payments lines.

Part-of: odoo/odoo#96583

This commit aims to handle the belgian blackbox error properly just as the sweden blackbox do.
Add an error code of 701 to handle the error messages.

Part-of: odoo/odoo#96583