Current behavior:
When using a product kit that have a product kit in his BoM some move line where merging when they shouldn't.
Because of this the delivered count wasn't correctly updated in any sale order using this product

Steps to reproduce:
- Create product B to manufacture with a BoM (type Kit) using component A and component B
- Create product A to manufacture with a BoM (type Kit) using product B and component A
- Create a sale order with product A
- Confirm the sale order and validate the delivery
- The delivered count of product A on the sale order stays at 0

opw-2777810

closes odoo/odoo#86545

X-original-commit: 7d1af314
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>

SHA1 is going to be deprecated by ogone.
This change try to keep current behaviour while adding
the possibility to use SHA256 and SHA512

As this change as to be done in stable version,
We use the length of the key to know which version of SHA
we should use.

The goal is to switch add an selection to master to ensure
better code modularity.

The change was requested by PDE/ANV.

opw-2766648

closes odoo/odoo#86642

X-original-commit: 759411fa
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>

Steps to reproduce the issue:

- Let's consider a company C in $ and the rate conversion from $ to € is 0.5
- Let's consider a product P
- Let's consider a pricelist PL1 in € such as P is set to 100€
- Let's consider a pricelist PL2 in $ such as P id set to 100$
- Create a sale order SO with PL1
- Create a line with P

Bug:

The unit price of P was 200€ instead of 100€ because field currency_id was not set on the line
when trying to pass it to function _get_tax_included_unit_price

opw:2789324

closes odoo/odoo#86483

Signed-off-by: Simon Goffin <sig@odoo.com>

When using price included taxes, the xml contained data that failed to
meet the constraints of the edi. This is due to the local rounding on
the lines of the invoice.
For example:

	A product costing 321€, on two lines of the invoice, with
	a price included tax of 22%
	Rounded per line:
	float_round(
		321 - (321/122 * 100),
		2 # To two decimal places
	)
	evaluates to 57.89, the total tax will be 2 * 57.89 = 115.78

	In the case of global rounding
	float_round(
		321 + 321 - (321/122*100) - (321/122*100),
		2 # To two decimal places
	)
	evaluates to 115.77,

	so we have a difference of one cent.

This can be exacerbated by more lines.

The constraints on the EDI that this conflicts with are on the tax
summary section for each tax.
The constraints (roughly reworded):
00422:  The base taxable amount for the tax must be equal to the sum of
	the base product prices (for which we have already used the
	rounded computed values, calcuated in the invoice) +
	<Arrotondamento> (rounding).

00421:  The value provided for the <importo> that is the value of the
	vat is equal to the taxable base multiplied by the tax rate.

The problem is that because of our local roundings, the taxable base
is equal to our products, but the tax rate * taxable base is not equal
to the tax amount (as present in the invoice).

This commit adds to the rounding field and subtracts from the
taxable base of the tax summary a value rounding value that
should make tax rate * taxable base equal to the value of the vat.

closes odoo/odoo#86052

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

Description of the issue/feature this PR addresses:
Fixes an error raised by #84827

Current behavior before PR:
The following error was found

Add the option Print invoices on customer requeston a Pos Config.
Open a session
Create 2 orders for the same customer and invoice them
Return one of the orders and invoice it
Two account moves will have amount_residual != 0 (the credit note and one of the orders) (tested on runbot)

Desired behavior after PR is merged:

The result is that all moves are reconciled.

In order to not loose it, I added tests for this issue and the issue fixed on #84827

closes odoo/odoo#86656

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

Currently, the shape controller uses =like when looking for an
attachment with a matching URL, but what is compared against is the
request's path. While this is not a security issue as we know the path
starts with the controller's route and only look for public attachments,
it's still undesirable as the end of the url may contain underscores or
percent and we do not want those to be interpreted as a pattern.

closes odoo/odoo#86623

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

When confirming a sale order, if a purchase order is generated, the
descriptions of the PO's lines won't be adapted to the vendor

To reproduce the issue:
1. Create a vendor V
2. Create a product P:
    - Type: Service
    - In Purchase, add a line L01:
        - Vendor: V
        - Vendor Product Name: Name01
        - Vendor Product Code: C01
    - Purchase Automatically: True
3. Create and Confirm a SO with 1 x P
4. Open the generated PO

Error: The description is incorrect (it's the standard name of P instead
of "[C01] Name01")

OPW-2777702

closes odoo/odoo#86256

closes odoo/odoo#86547

Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

This fixes erroneous matching of product when the product code in an invoice is ambiguous and fixes a missuse of the label from a product rather than the one on the invoice

Previously, a product would be set on an invoice line even if several products share the product code and when a product is set the label is the one of the matched product
Now, a product is set if the code matches one and only one product and the label used is always the one from the invoice

closes odoo/odoo#86590

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

When codice fiscale is not the same as the partita IVA, the template was
utilising the wrong value for IdCodice in <IdTrasmittente>. It should
use the value of codice fiscale, and if it's not found, then use the vat
value (e.g. when it's not an Italian company).

closes odoo/odoo#86441

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

PrezzoUnitario causes an error when the discount is 100% as it tries to
divide by zero. Fix this by just using the unit price when the discount
is 100%.

closes odoo/odoo#86569

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

The EDI rejects the xml if the <IdDocumento/> is longer than 20
characters long.

Part-of: odoo/odoo#86569

Before this change, we have the errors that documents generated on
pre-printed sales journals mark as unified book were wrongly
named using the wrong doc prefix code.

This was visible thanks to the demo data were we notices that the credit
notes were having FA- doc prefix instead of NC-

This was because we are reusing the shared sequence directly, now we
check and fix the doc prefix for those cases and all documents generated
on shared sequences are properly named.

closes odoo/odoo#85170

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

The issue is that the config param is data, which means that when the
module is updated, the config parameter will be updated (i.e. reset to
the 'demo' state), which will cause havoc on client databases. Even if
we set the record to 'noupdate=1', the existing clients will have the
record updated.

The solution is to remove the config param from the data entirely, thus
preventing it from being updated when updating the module, and instead
have a 'post_init_hook' that sets the parameter to 'demo' (this will
only happen when the module is installed, and never again).

closes odoo/odoo#86535

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

As sale does not know about special lines it will always update
the price based on product and price list instead of applying the correct
shipping rate, so we do skip those lines by using a newly introduced hook method

closes odoo/odoo#85884

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

Since https://github.com/odoo/odoo/commit/cb6c6224be4eaa80091f51f957059de889332e68


we are now raising possible errors when uploading an invoice.
In 14.0+ we are allowing via a redirect warning to change the status of
the currency without changing the page but the upload only starts when
you change the uploaded file.
So the following flow does not work:
    - Try to upload a bill with MXN currency
    - With MXN being inactive, it raises an error. Using the redirect warning action
      we activate the currency, clos the modale window and try to upload
      again.
    - The upload won't work until we refresh the page, because the value
      of the input file does not change (or we need to select another
      one, then the first one again)
This change reset the file input if there is an error raised during the
upload allowing to select the same file more than once without reloading.

closes odoo/odoo#86504

X-original-commit: 4bfc7507
Signed-off-by: William André (wan) <wan@odoo.com>

Current behavior:
All batch transfers are shown in the tree view. But only the one for the allowed companies should be in the list

Steps to reproduce:
- Be in a multicompany environnement
- Activate batch picking
- Go in Inventory/Batch transfers

opw-2752617

closes odoo/odoo#86498

X-original-commit: 8415b48c
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>

Cash rounding value were not added with negative amount.
For example if you made an order:
  - amount of the order: 1.98
  - rounding value: 0.05
  - amount to pay: 2.00
The refund of this order should be:
  - amount of the order: - 1.98
  - amount to pay: - 2.00
  - amount to pay before the fix: - 1.98

Because when we added the latest fix that allowed payment lower than the cash rounding value (for example an order amount of 0.03 with a cash rounding for 0.05), the negative amount were not taken into account.
Whenever a negative amount had to be paid, the condition was triggered and return a 0 as rounding to apply (-1.98 < 0.05 => true).
Now we check the absolute value of the total amount to consider if we need to apply a rounding.

closes odoo/odoo#85280

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

When delivering an additional product with a specific UoM, the generated
line on the sale order should have that same UoM

To reproduce the issue:
1. In Settings, enable "Units of Measure"
2. Create two products PA and PB (UoM of PB is the meter)
3. Create and confirm a SO with 1 x PA
4. On the picking, add 1 km(!) x PB
5. Validate the picking
6. Go back on the SO

Error: the line for PB is incorrect, its UoM is 'm', it should be 'km'

OPW-2761913

closes odoo/odoo#86281

Signed-off-by: Steve Van Essche <svs@odoo.com>

Prior to this commit, the multi company rules were bypassed due implicit
sudos (compute_sudo and self.env.user).
The function computing the number of days will now make sure to include
the right domain.

TaskId-2791030

closes odoo/odoo#86359

X-original-commit: 26ff56d9
Related: odoo/enterprise#25254
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

PR #85474 introduced a bug where in users are not able to create purchase
requisition in a multi company setup.

closes odoo/odoo#86386

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

opw-2793379

closes odoo/odoo#86398

X-original-commit: 0dd7c78b

Currently while sending a digest, if a company does not have an email
address set, the "From" field for the mail is blank and so trying to
send digest fails.

With this commit, if a company does not have an email address set, it
will fallback to logged in user's email address as a "From" value.
In most cases, it will be the Odoobot email address (if the digest is
sent with the CRON) but if the admin send manually the digest, we will
use the admin email address.

TaskID-2729780

closes odoo/odoo#83808

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

When a PO is in the "To Approve" state, it disappears from the
forecasted report

To reproduce the issue:
1. In Settings, enable "Purchase Order Approval" with a minimum amount
equal to 0
2. Create a storable product P
3. With Marc Demo:
    - Create a PO with 50 x P
    - Consult the forecasted report of P: there are 50 x P "Forecasted +
Pending"
    - Confirm the PO (its state becomes "To Approve")
    - Consult the forecasted report of P

Error: The 50 x P disappeared: 0 On Hand, 0 Forecasted, 0 Forecasted +
Pending. We should still see 50 Forecasted + Pending

OPW-2774586

closes odoo/odoo#86161

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

Expected Behaviour

When updating the cost of a product with a negative quantity and then
making an inventory adjustment, the final value should be corrected according
to the current cost of the product

Observed Behaviour

In the case we had a negative quantity when changing the cost, the compensation
layer will be ignored when doing an inventory adjustment afterward, leading to
an incorrect total value in the inventory valuation

Reproducibility

This bug can be reproduced following these steps:
- Create Storable product with costing method = AVCO Automated, Update cost to 100$
- Sell 10 units of this product (Inventory valuation at -1000 $ for -10 units)
- Update cost of the product to 10 $ (Inventory valuation at -100 $ for -10 units)
- Create an inventory adjustment to set the quantity of the product to 0.
==> Inventory valuation is a 900 $ for 0 unit of our product

Related Issues/PR

- opw-2635692

closes odoo/odoo#86328

X-original-commit: 2e4fdcb8
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Hendrickx Anthony (anhe) <anhe@odoo.com>

Step to reproduce:
- Create a Quotation Template QT and set in in the sale settings
- In the confirmation Tab of QT add a confirmation email
- As a portal user, purchase an item in ecommerce
 The payment must be confirmed. (tested using payment_test module)

Current Behaviour:
- Traceback on confirmation email rendering, portal user do not
 have access to the full data.

Behaviour after PR:
- Email is rendered as superuser to ensure data is correctly
 fetched

opw-2749804

closes odoo/odoo#85186

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Fixes odoo/odoo#86216
When printing qweb report use the current company.
For example, the company logo printed was always from user company
default instead of the current company.

closes odoo/odoo#86220

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

Part-of: odoo/odoo#86220

THe price shown on the order line was not taking into account the
quantities ordered.

closes odoo/odoo#85846

Taskid: 2678064
X-original-commit: f9243560
Signed-off-by: Kevin Baptiste <kba@odoo.com>

This commit aims to allow assigning tags to the taxes
created by the OSS feature by providing the xml_id of their
report.line in the eu_tag_map.py file.

Before this commit:
In l10n_be, the taxes created by OSS (l10n_eu_services) didn't set
the tag +47 on invoice_repartition_lines nor +49 on
refund_repartition_lines.
This make the VAT report for Belgium wrong.

After this commit:
Taxes created by OSS for a company using the belgian CoA will get
their tags set properly and thus will the taxes impact the
belgian tax report correctly.

task: 2770182
ticket: 2768622

Community-PR: https://github.com/odoo/odoo/pull/85607



Design choices:
This fix is currently solving the issue for l10n_be but we have
no doubt that it will be raised for other EU countries too.

In order to provide the tags, we decided to be consistent with
what as been done regarding the tax mapping. Thus we decided to
create and maintain a simple mapping file and to test it.

several other methods were explored:
- create a global variable and update it from all localization
modules. This method would work but is ugly and error prone.

- create a templating method and override it from localization
modules.
The problem is where to set the root of the template method?
The naïve solution would be to create a bridge module between
l10n_eu_services and l10n_be but that would lead to an explosion
in the number of bridge modules which we don't want.

In order to keep things simple and generic, we could put the
template method directly into the account module. But it is kind
of ugly because account shouldn't know anything about the oss
feature and it would encourage such a leaky design to happen
again in the future.

closes odoo/odoo#86295

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

Improves l10n_eu_services code readability

Part-of: odoo/odoo#86295

The smartbutton for the number of hours in the attendance smart button
on employees and user did not use the right widget and could display
invalid data like '1.8 hours last month'.

TaskId-

closes odoo/odoo#86247

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

Description of the issue/feature this PR addresses:

In odoo payment the cc_expiry.maxlength is limited to 7 characters

https://github.com/odoo/odoo/blob/75785db4c8d0c0be9fb7b8dfc2cd7b8209181c21/addons/payment_test/views/payment_test_templates.xml#L19 https://github.com/odoo/odoo/blob/75785db4c8d0c0be9fb7b8dfc2cd7b8209181c21/addons/payment_ingenico/views/payment_ingenico_templates.xml#L54

Current behavior before PR:

But your [$.payment.formatExpiry](https://github.com/odoo/odoo/blob/14.0/addons/payment/static/lib/jquery.payment/jquery.payment.js#L629) can return 9 characters
![Screenshot(20)](https://user-images.githubusercontent.com/35231827/157748056-c4fa8e4a-1504-41a9-afbc-99743e5491fe.png)

We can see in when the user use autofill

https://user-images.githubusercontent.com/35231827/157748925-1778e71d-28a6-4ed5-82ac-989d4e503a24.mp4

Desired behavior after PR is merged:

https://user-images.githubusercontent.com/35231827/157748644-fd530ded-a13f-473d-8410-09eca4c8c961.mp4



--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

closes odoo/odoo#86226

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

The issue is simply creating a related stored many2many field, which is
pretty easy to do with Studio.  When creating the field, Odoo crashes
with a traceback caused by ondelete being None on the field.

The source of the bug is the fact that the attribute field.ondelete is
set to a sensible default ('cascade') on non-related fields only.  The
fix consists in setting the default value on the attribute itself, so
that the setup of the field never falls on a case where field.ondelete
is unset.

closes odoo/odoo#86255

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

When having a bank statement line in foreign currency, the writeoff line is display with the right sign but with the amount in company currency.

This is happening in two scenarios :

1 - With a bank journal in foreign currency, and a reconciliation model
with 'rule_type' 'invoice_matching' and 'match_total_amount' at 90 for example.
Create an invoice in the foreign currency for price 100, and create a bank
statement on the journal with a line amount of 90 (payment_ref set with the
invoice name). Then confirm and reconcile -> the writeoff amount is display with
the right currency sign, but in company currency

2 - With a bank journal in company currency, and a reconciliation model
with 'rule_type' 'writeoff_suggestion'. Create a bank statement with a line
with amount X, amount_currency Y, foreign_currency set. Confirm and reconcile
-> writeoff amount is the amount with the foreign currency sign, instead of the amount_currency.

opw-2695846
opw-2731737

closes odoo/odoo#85475

Related: odoo/enterprise#24739
Signed-off-by: Laurent Smet <las@odoo.com>

If applied, this PR will enable button_access for all users and portal_customers, letting them
access the documents directly. The button "View Journal Entries" will appear on the notification
email, and by clicking this the user will be directed to the portal page of the invoice/refund.
All users and portal_customers subscribed to the thread should be able to see this button.

A following refactor by TDE (#82167) has addressed this problem in master (for 15.2).
For stable versions, in this PR, we agreed to keep changes limited to the accounting scope.

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



opw-2645653

closes odoo/odoo#86214

X-original-commit: de8d1632
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>

closes odoo/odoo#86227

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

Finetuning of #85774
Fixes #86174

closes odoo/odoo#86198

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Current behavior :
SIPS urls aren't available anymore and lead to a 410 error page

Reason :
URLs have been updated and should be replaced
i.e. previous URL : https://payment-webinit.simu.sips-atos.com/paymentInit
should be replaced by https://payment-webinit.simu.sips-services.com/paymentInit
according to SIPS docs [1]

[1] : https://documentation.sips.worldline.com/en/WLSIPS.317-UG-Sips-Paypage-POST.html#Step-3-Doing-tests-in-the-simulation-environment_



OPW-2780969

closes odoo/odoo#86193

X-original-commit: d2149231
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Claude Thibault (thcl) <thcl@odoo.com>