The error will occur when a user try to print POS inalterability check report
for pos orders when accounting is not unalterable for that company.
steps to produce:

1. install l10n_fr_pos_cert the  module
2. switch to company other than FR company
3. pos > reporting > POS inalterability check .

when the company's country is not in unalterable country :
https://github.com/odoo/odoo/blob/3b88958f5a07edf86d2fc9c8080ee46d16b872ef/addons/l10n_fr/models/res_company.py#L14-L24

1. so,`_check_pos_hash_integrity()` gets Nonetype which will lead to above
traceback, when trying to update the data dictionary.
2. Also, `_check_hash_pos_integrity()` is not defined in our standard code so ,
this commit optimize the `_get_report_values` method.
see : https://github.com/odoo/odoo/blob/3b88958f5a07edf86d2fc9c8080ee46d16b872ef/addons/l10n_fr_pos_cert/report/pos_hash_integrity.py#LL11C1-L22



sentry-4243853702

closes odoo/odoo#124664

Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>

The content of the override of `can_be_merged_with` should only be executed when we're
in France.
The previous implementation resulted in breaking the `test_05_tip_screen` when this module
was installed with pos_restaurant.

closes odoo/odoo#117942

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

Before this commit: if the user wanted to generate a
POS Inalterability Check statement, an IndexError was raised.
This commit raises a more understandable error.

opw-3237383

closes odoo/odoo#116386

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

Before this commit: if one of the orders is corrupted, it will print an empty report.

The solution is to print corrupted orders in the report.

opw-2867770

closes odoo/odoo#95455

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

When installing 'l10n_fr_pos_cert', some fields become always editables on the bank statement form even the state is not in 'open'.
This allows the user to introduce a lot of unconsistencies regarding the bank statement balances.

closes odoo/odoo#83314

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

Fixes odoo/odoo#78932
Closes odoo/odoo#79273

Part-of: odoo/odoo#79360

Before this fix, if the country is not set on the company
the loading of the session may stall at some point.

A check is added and will prevent to start a session if the country
is not set.

opw-2557989

closes odoo/odoo#79212

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

closes odoo/odoo#76674

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

closes odoo/odoo#74842

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

When using several certification together, there was an issue
when we tried to modify the quantity of an orderline.
The "this" context was lost and we were unable to call the function
anymore.

In order to fix that, we bind the context when calling the function.

closes odoo/odoo#74162

Related: odoo/enterprise#19811
Signed-off-by: William André (wan) <wan@odoo.com>

The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.

closes odoo/odoo#74231

Related: odoo/enterprise#19850
Related: odoo/design-themes#43
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

- Create a pos order, pay and valide
- Close Pos
- reopen pos
- search this order
- click print ticket

--> Issue the hash doesn't appear on the ticket

closes odoo/odoo#71172

Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

When resuming a POS session, if the latter has been opened in the past
and if its state is 'Opening Control', a incorrect UserError is raised
and prevents the session to be started.

To reproduce the error:
1. Use a French company
2. Create a POS
    - Enable "Advanced Cash Control"
3. Start a new session
4. Close it
5. Set the computer's date in the future
5. Open the POS session > Continue Selling

Error: A UserError is raised ("This session has been opened another day.
To comply with the French law, [...]"), but the user does not have the
possibility to close the session. Moreover, since its state is "Opening
Control", no sales have been made yet.

This fix suggests to reset the start date in such a situation.

OPW-2488952

closes odoo/odoo#69253

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

Task 2309613

We have a new hierarchy:
* Accounting
  * [Generic, not changed]
  * Localization
    * Account Chart
    * Check
    * EDI
    * Point of Sale
    * Purchase
    * Reporting
    * Sale

This helps in displaying only the chart of accounts when clicking on
"Install more Packages" from the accounting settings in the Fiscal
Localization section.
We can also refine the search in the _auto_install_l10n post init hook
of account.

closes odoo/odoo#55384

Related: odoo/enterprise#12179
Related: odoo/upgrade#1568
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>

This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
  _("Foo %s", bar)

to progressively migrate the code to the new syntax.

A few calls were not technically incorrect but still detected by the
linter.

  _("Foo" +
    "Bar")

has been converted to

  _("Foo"
    "Bar")

as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).

closes odoo/odoo#53683

Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

Convert deprecated tags through the codebase.

Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))

Old syntax is still compatible but starts the migration to the new
syntax that catches error.

For most localizations, decreasing quantity of an orderline is
prohibited. This commit generalizes this behavior and is now available
in core point_of_sale.

- Install PoS and "l10n_fr_pos_cert";
- Erase the country in the current company;
- Open a PoS session;
- Click on any product.

Before this commit, a JavaScript traceback was raised: TypeError: Cannot read property
'code' of null.

Now, an error message is raise, that informs the user that the company don't have country
setted.

opw-2241993

closes odoo/odoo#50320

X-original-commit: 5ed4b0cb
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>

ir.rule are default values but can be customized based on the
company's policy and needs.
This is typically a record that is in noupdate as should be
customization-friendly.

In a French configuration, the decimal separator is a comma.
Unfortunately, `parseFloat` doesn't handle this case and incorrectly
parses the string.

Similar issue and correction than
https://github.com/odoo/enterprise/commit/af8177612e569907bcb8fe4b9ce2d845de5ab2a0



opw-2207795

closes odoo/odoo#46945

X-original-commit: 3d87d79e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Task 2092079
Accounting firms that want to give access to their customers avoiding
mistakes and risks will love this profile that can't do anything
wrong... Maybe as well as companies auditors..?

closes odoo/odoo#39860

Related: odoo/enterprise#6576
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

When the french certification is installed for the pos, there is an error when we use it in a company that is not french.
The format of the values sent was not identical to the format of the values expected.
Now the order and the server_id are sent separetly to match the parent function.

closes odoo/odoo#43476

X-original-commit: 657133a2
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

The report sale closing that was working on journal and takes the sales
total and cumulative total on periods of 'day', 'month' and 'years'. Is
now based on the pos orders and moved to the pos certification module.

closes odoo/odoo#36967

Task-id: 47990
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

We've added a repport that guarantee that the blockchain of hash has not
been altered. It recompute the hash and check that they are the same as
the one stored.

TASK-ID: 47990

Once an order is created in the french certification, we cannot modify
it wihout traces, so we've disabled the edtition of the order lines in
the frontend, disable the price changing, and the deletion of orders.

So when we want to decrease the quantity, a line with negative quantity
should be done.

TASK-ID: 47990

We now display the pos order hash, on the order form view when we are in
debug mode.

TASK-ID: 47990

When an order is sent to the server from the point of sale, a unique
hash is generated by the server. This hash must be printed on the
receipt to allow the comparison between the receipt and the data on the
server and guarantee the unalterability of the data on the server.

TASK-ID: 47990

closes odoo/odoo#35754

Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>

Task ID: 2039160

This commit deletes account_cancel module and squash it into account.
The 'update_posted' field is changed by 'restrict_mode_hash_table' field.

If 'restrict_mode_hash_table' is true, you have a hash chain on your account journal.
These hash chains prove the inalterability of your accounting.

l10n_fr_certification module is deleted and all hashing method are moved in account module.
Now, you can download a PDF report about your inalterability in the company settings.

If you have l10n_fr or l10n_post_cert installed you have more information on this report
like the inalterability of pos orders, etc.

Task ID: 2039160

When the hash is generated for a pos order, it is computed based on some
fields, there was the field statement_ids that doesn't exist anymore,
and so we replaced it by payment_ids which is the new field.

closes odoo/odoo#36912

Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

Main goal of this task is to create single accounting entry
(AE) when closing a pos.session instead of individual AE for
each order in the session.

This significantly minimizes the number of created journal
entries by point_of_sale which also results to faster closing
of session when there is large numbers (order of thousands)
of orders. It also eases the reconciliation of payments because
on one hand, cash payments are automatically reconciled and on
the other, other payments are combine in a receivable line
based on the payment method.

**Important points to note**

1. Two new models (pos.payment.method and pos.payment) are
introduced replacing the functionalities of account.journal
(and account.bank.statement) and
account.bank.statement.line, which served before as payment
methods and payments.

2. The creation of single AE relies on the receivable_account_id
defined in each pos.payment.method. This receivable_account_id
is supposed to be different from the account module's receivable
account, thus, a new receivable account for pos is introduced
in each localization.

3. A simple example below can illustrate this change.

Given the following orders:

    +---------+----------+----------+-----+-------+-------+
    | order   | payments | product  | qty | price | total |
    +---------+----------+----------+-----+-------+-------+
    | order 1 | cash     | product1 |  10 |    10 |   100 |
    |         |          | product2 |   5 |    20 |   100 |
    +---------+----------+----------+-----+-------+-------+
    | order 2 | bank     | product2 |   7 |    20 |   140 |
    |         |          | product3 |   1 |    30 |    30 |
    +---------+----------+----------+-----+-------+-------+
    | order 3 | bank     | product1 |   1 |    10 |    10 |
    |         |          | product2 |   3 |    20 |    60 |
    |         |          | product3 |   5 |    30 |   150 |
    +---------+----------+----------+-----+-------+-------+

Instead of generating 3 accounting entries, a single
accounting entry (linked to the pos.session) will be created.
This accounting entry will have the following lines:

    +---------------------+---------+------------+
    | account             | balance | reconciled |
    +---------------------+---------+------------+
    | sale                |    -590 |    -       |
    | pos receivable cash |     200 |    yes     |
    | pos receivable bank |     390 |    no      |
    +---------------------+---------+------------+
    | Total balance       |     0.0 |            |
    +---------------------+---------+------------+

Note that the cash receivable line is already reconciled
because it can assumed that the payment is already received.
The unreconciled receivable line can be reconciled manually
using the reconciliation widget.

More examples can be seen in the tests.

TASK-ID: 1862388

get_installed and _lang_get_id are both ormcached and correctly check
the context

Retrieving a res.lang from a code is a frequent action that can be
achieved with _lang_get (cf previous commit).
Using _lang_get ensure the active_test in the context is correct and
is not poluted with another context propagation issue.
odoo/odoo#35490 discussion is an example of bad context propagation

closes odoo/odoo#35504

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

The goal is to be coherent with the user property.

Actually, company_id and company_ids on the environment are no fields.

Calling env.company_id returns a browse record, not an id.

No need for selection fields
If in global variable, the _lt should be used instead

closes odoo/odoo#31211

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

Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.

Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`

Purpose
=======

Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.

It is confusing for users to see the records from the company he is connected to
and the records of the children companies.

Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.

/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.

Specifications
==============

1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.

2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.

3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.

4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.

5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.

6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.

7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids

8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.

9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.

10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.

11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624



12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.

13/ Introduce a res.group to enable/disable the multi company per tab
feature.

14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.

15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.

16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.

17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.

TaskID: 1960971

closes odoo/odoo#32341

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