This field is used with the multilang module. As only one language is spoken in Dominican Republic, this definition is useless and furthermore it raises a warning in the logs.

When changing the 18 tax by the communication group, the 18 tax has
to remain

Description of the issue/feature this PR addresses:

The Chart of Accounts was missing accounts needed for correct
inventory valuation using perpertual method, and also a seggregation
for payroll accounts, to differ employee retentions from company
contributions.

Current behavior before PR:

Wrong accounts used for perpetual inventory valuation
Payroll accounts not showing difference between employee retentions and company contributions
Regulatory reports are hard to make without the right accounts tag
Desired behavior after PR is merged:
The correct accounts are now created and assigned for inventory valuation. And payroll accounts are correctly segregated for the payroll rules coming in the next PR.

The accounts will also have their corresponding tags for having regulatory reports based on the "control account" for hierarchy, which was removed in v8.

This changes are also needed for a WIP of a PR coming to the
Enterprise repository, for building legal reports based on account
and tax tags.

Closes #17237

Closes https://github.com/odoo/odoo/pull/17254/files

(was working in Odoo 9.0)

Courtesy of Yenthe

Closes #17257

https://github.com/odoo/odoo/pull/17251

Closes https://github.com/odoo/odoo/pull/17251

Closes #17255 

Closes #17256

Courtesy of cubells (Orbetix). Was PR #17219 

To help users to know why they can't close their pos sessions when
a Sales Journal is not set in the pos.config.

opw:744758

The "exp. closing" dashboard button takes into account the won
opportunities. It shouldn't.

opw-744940

Make sure the user has access to all sale orders linked to this procurement
group.

Fixes and closes #17232

Done at #17232

Recent changes in mail.templates not reflected

Was pretty outdated

Closes #17133
Closes #17137

Add a hook to allow the hardcoded domain in the method `make_po`, in
procurement order.

Base on work by @Cedric-Pigeon

opw-744606
Closes #17147

Done at #17211

When we are on a partner form view, we get the total invoiced containing
the child contact of the current partner. But when clicking the button
we only see the invoices of exactly the current partner.

In most locations of the code this has changed (since 347c784d) and
this part should also contain the descendants contacts.

opw-744929
closes #17188

In the case of a chatter on a calendar virtual event, there was a number
of issue because the record ID was of the type "[REAL ID]-[VIRTUAL ID]".

This caused issue when fetching and posting message with the composer.

opw-744405
closes #17179

Revert "[FIX] account: reset the move reference on bank statement"

This reverts commit 6de2990f.

The previous patch was removing the reference of the move.
However, the reference is useful to reuse the name if the line is reconciled
again.

Instead, remove the constrain. To delete the move, account_cancel is already
needed. It is useful to allow removing statement lines to match the statements
form the bank and the one on Odoo.
In the future, allowing to set the amounts to zero should be added as a way to
correct the lines.

opw-741205

- Set-up multi-currency with the following rates:
  MXN: 1.0
  USD (2017-04-10): 0.052632
  USD (2017-04-27): 0.051680

- Create an invoice of 1779.55 USD on 2017-04-10
- Register a payment of 1779.48 USD on 2017-04-27
- Set the invoice as fully paid

It is impossible to validate the payment because of the following error:
"The amount expressed in the secondary currency must be positive when
account is debited and negative when account is credited."

We make sure to align the writeoff amount sign with the writeoff amount
sign in the company currency.

opw-741520

The snippet options are attached to `closest`, `all` and `is` functions
to be able to find/check DOM they are associated to. Their behavior
depend on the snippet option type: the search in the DOM is either done
in the body, the editable parts, the editable children only, ....

The problem is that when searching from a given DOM element, jQuery
won't match the elements whose selector contains this given DOM element.
Or in code terms, jQuery find function behavior is:
`$('A').find('A B')` <=> `$('A A B')` (not `$('A B')`)

This was indeed a problem on the job position apply form pages where the
main editable element is the <form/> element itself. Indeed, the snippet
options' selectors which began by 'form' were not able to match. Worse,
the selector is used for a jQuery search for drag & drop and saving but
not for initialization (where it is used as a `is` check on clicked
elements). So, some DOM were able to be modified by options but not
properly (re)configured before saving.

opw-705902
opw-741305

The structure of the product.{product,template} form is the following:

product.product_template_form_view* (both)
|-- product.product_template_only_form_view* (template)
|   \-- stock.product_template_form_view_procurement_button
|
|-- product.product_normal_form_view* (product)
|   \-- stock.product_form_view_procurement_button
|
\-- stock.view_template_property_form (both)

Previous view was adding weight, volume fields on both view with a attrs that
applies only to the product.template (display only if no template).

This means that the weight was not displayed on product.product form if opened
from a Many2one (using the default product.product view) while the attrs should
not hide it.

Closes #16541
Fixes #16428

In a scenario with the following views:

Mod A, view 1*
|-- Mod B, view 2
\-- Mod B, view 3*

view 3 can not rely on the elements added by view 2 in xpath
If view 3 is a primary view, view 1 must be fully resolved first (apply view 2)
before resolving view 3.

Next commit describes a real use-case with product.

Linked to #16541 and #16428

When a membership is created, a redirection is done to the tree view of
the vendor bills. It should be the tree view of the customer invoices.

opw-743241

Was PR #15893

add gavymg

Done at #17148

The request language must be a fallback if the current website does not
have a default language

The prettifying of html when editing sources (user need to be in debug
mode to see the button) was removing too much spaces in some instances.

For example if someone got in a case such as:

  <span>hello<b> cruel </b>world!</span>

The spaces between text and tag would be removed (this would work fine
with the space outside of the tag).

This code add a special case so this doesn't happen anymore.

opw-743565
closes #17142

Introduced at c80a32f9

Before this commit data-precision='0' was ignored by qweb rendering.
Now we force the data-precision to be set even if 0. (cast in str)
And add a temporary fallback JS side to catch this case while people don't
update the qweb template.

This commit closes #17050 and closes #17046

Without this the error message will always be in English, no matter the language
of the end-user.

Closes #17141

With the settings:
- Anglo saxon accounting
- real price on product, perpetual accounting,
- multicurrency
- a product with a very small uom (like gram or kilograms and you want to sell many of them, like 500kg)

Flow: purchasing something in another currency

Before this commit, the rounding of the unit price took place right at the conversion level
which led the rounding errors to be amplified by the quantities when the total price was computed

After this commit, the conversion is done on the unit price but is not rounded yet
Only the prices are rounded, as late as possible

OPW 742293

Closes #17015