[FIX] l10n_fr_certification: main module
Main resource document to be found at https://www.economie.gouv.fr/files/files/directions_services/dgfip/controle_fiscal/actualites_reponses/logiciels_de_caisse.pdf
This document states that only business operations with partners not being subject to VAT should be inalterable and secure.
We adpat the module by differentiating between b2c and b2b journals and apply hashing on the former's moves
Protection against account_cancel is not necessary anymore
By default, this module considers a sales journal being a b2c, thus activating hashing on its move.
Since we can't afford to lose information, when a b2c journal contains hashed moves, its b2c characteristic cannot be changed
[ADD] l10n_fr_pos_cert: module to adapt the POS to the recent French regulation CGI art. 286, I. 3° bis.
The module adds following features:
- Inalterability: deactivation of all the ways to cancel or modify key data of POS orders, invoices and journal entries
- Security: chaining algorithm to verify the inalterability
- Access to download the mandatory Certificate of Conformity delivered by Odoo SA (only for Odoo Enterprise users)
[ADD] l10n_fr_sale_closing: module to store automatically the total of daily/monthly/annualy sales.
(both of the period and cumulative).
This fulfills another requirement brought by the recent French regulation CGI art. 286, I. 3° bis related to the storage of data
Adaptation of #20581 for version 11.0.
The order of production was first based on "priority DESC" and then
"date_planned ASC".
So for production with the same priority/date_planned the order is not
deterministic.
This commit make the order deterministic as it seems preferred.
opw-784243
closes#21644
Main resource document to be found at https://www.economie.gouv.fr/files/files/directions_services/dgfip/controle_fiscal/actualites_reponses/logiciels_de_caisse.pdf
This document states that only business operations with partners not being subject to VAT should be inalterable and secure.
We adpat the module by differentiating between b2c and b2b journals and apply hashing on the former's moves
Protection against account_cancel is not necessary anymore
By default, this module considers a sales journal being a b2c, thus activating hashing on its move.
Since we can't afford to lose information, when a b2c journal contains hashed moves, its b2c characteristic cannot be changed
[ADD] l10n_fr_pos_cert: module to adapt the POS to the recent French regulation CGI art. 286, I. 3° bis.
The module adds following features:
- Inalterability: deactivation of all the ways to cancel or modify key data of POS orders, invoices and journal entries
- Security: chaining algorithm to verify the inalterability
- Access to download the mandatory Certificate of Conformity delivered by Odoo SA (only for Odoo Enterprise users)
[ADD] l10n_fr_sale_closing: module to store automatically the total of daily/monthly/annualy sales.
(both of the period and cumulative).
This fulfills another requirement brought by the recent French regulation CGI art. 286, I. 3° bis related to the storage of data
Was PR #20581. Was task 29922
The bug is also present in enterprise but the required style of
enterprise makes the bug invisible. The bug has also been naturally
fixed in 11.0 thanks to the views and design refactoring.
Thanks @auyeung112002 for the original fix.
Bugs introduced with commit https://github.com/odoo/odoo/commit/08e92204b661086b27a2d435d3ca06436540c0e0
- The new `rainbowMan` option was always `true`
- When checking the option, it was looked in the wrong object so it was
always considered false (so no more rainbowMan at all...)
Also deactivate the rainbowMan for the automatic tours.
Also refactor the method's documentation.
The checksum computed to verify the version of the assets includes a list of
files as JSON. This JSON is generated from a list of dictionaries.
When using Python <3.6, the ordering of the dictionaries is not guaranteed which
lead to unnecessary rebuild of assets. Particularly when starting Odoo on more
than one host, the current implementation hits this issue:
* server 1 computes the checksum with an ordering and generates the assets
* server 2 computes the checksum with a different ordering and generates the assets
* server 1 computes the checksum with a different ordering and generates the assets
* And so on...
Which obviously lead to disastrous performances.
Without proper group restrictions many computed/related fields will
crash because they depend on other group-restricted fields, such as
the `children` field.
When you have e.g. an SO with a product MTO generating a manufacturing
order, and you put the delivery order to done, before the MO is done,
you can not cancel the MO anymore, because the cancel method checks if
the move is not done (and raises an error).
As the user stays blocked in this case, it is better to just not try to
cancel the destination move by not propagating the cancel when the destination
move is done.
opw-786571
When you have e.g. an SO with a product MTO generating a manufacturing
order, and you put the delivery order to done, before the MO is done,
you can not cancel the MO anymore, because the cancel method checks if
the move is not done.
As the user stays blocked in this case, it is better to just not try to
cancel the destination move by not propagating the cancel when the
destination move is done.
opw-786571
Once installed, a standard employee cannot open a employee form view since this
field was computed and that field children is not allowed without group hr_user
Before this commit, editing a website.menu (linked to a website.page (m2o))
would not save the URL on the website.page record but only on the
website.menu.
But since the URL retrieved to display the website navbar is:
1. The website.page url if the menu has a page_id
2. The website.menu url otherwise
It would never get the edited URL stored on website.menu
Clean method _add_dispatch_parameters
Remove unused code for caching
Call super before to have the correct lang when we browse website.
Without it, menu was not loaded in correct language.
Steps to reproduce the bug:
POS -> Settings -> Enable Price Control.
Login with user with POS -> Manager rights
Open POS Session.
Bug: Price Option was disable.
opw:784422
In some cases the MRP scheduler can remain blocked on an infinite loop
consuming a lot of CPU. The reason comes from the loop 'Check done
procurements'
If a new procument is created from another process (such like MTO
orders) during this loop, the process never ends.
The only way to reproduce is in debug mode:
1. Put a breakpoint on line 'Check done procurements'
2. Launch the MRP scheduler manually and stay paused on the breakpoint
3. In parrallel, create and confirm a sale order with a MTO route, this
will trigger the creation of a new procurement order in state
'Running'
4. Continue debugging step by step the scheduler and you will notice
that the loop never ends.
Closes#21565
opw-787651
Use case to reproduce:
- Go for a delivery order and use show detailed operations mode
- Have something reserved on a picking
- Manually delete the stock.move.line
-> The move state is not adapted to the new state of the stock move lines
It happens because the move state is not computed not
update on the move line unlink method.
This commit use the existing move function in order
to compute the state and add a test.
A part of test_stock_flow_74 is updated. Since procurement
refactoring make a move mto and confirm it will not work
since purchase or mrp are not install (Usererror). Also do an unreserve
on a draft move is not a real use case and should not pass
it in waiting since moves orig are never created.
The package weight is computed by summing all move lines related to it,
which is wrong, because if you have a package that is in two pickings,
its weight will two times bigger than the real weight.
To fix this, we will compute the weight based on the quants in the
package, except if we are opening the package from a pickin, it's weight
will be the sum of move lines of the package that are in the current
picking. This allow user to see the weight of a package after a put in
pack when there are not yet any quants in the package
- delivery slip: remove mention of packages
- package: fix the report's traceback
- picking: moved the packages references to a table at the bottom of the report
Have the following location structure: Loc A -> Loc B -> Loc C
The `complete_name` fields are:
- Loc A
- Loc A/Loc B
- Loc A/Loc B/Loc C
When changing Loc A to Loc D, the `complete_name` are:
- Loc D
- Loc D/Loc B
- Loc A/Loc B/Loc C
Compute `complete_name` of stock location using `complete_name` of
parent instead of parsing the full bunch of ancestors. This improves
the computation speed, and moreover solves the recursivity problem.
Closes#21585
We have problems when trying to validate our EU VAT report because some vat number are wrongly encoded in Odoo.
There are 2 problems:
1) We use vatnumber library to check the validity of the VAT number entered by the user on website.
That library removes the following characters '.' and '-' in order to perform the check and
thus can return True for a number like 123.123.123.13 or -123-3454-34
And those VAT number are then saved in our database but are rejected by the state
as VAT number should only contains alphanumeric character
-> Solution: prevent entering vat number with other characters than alphanumeric for users that are located in EUROPE!
2) Usually VAT is prefixed by country code, however some people in europe managed to bypass the system
by prefixing their VAT number with CC instead of their country code, CC is consider valid in odoo
(it means Country Code) but is not a valid European country code in general, which means that those
people that should have pay some tax have not. Which is a huge problem.
-> Solution: prevent the use of CC as country code by the user when entering a vatnumber only if the user country is in EUROPE!
source: https://en.wikipedia.org/wiki/VAT_identification_number
opw:785443
costs_hour field no longer exists
Some modules in a different repository (let say enterprise), may be still using
it but it is not its place here.
For stability reasons, we keep the computation if an external module adds the
missing field anyway
Fixes#16269Closes#20899
Improve performance (* 2.5) on _compute_reserved_availability
`mapped` makes use of orm prefetch, which is inefficient in this use
case when facing high volume.
Closes#21198
Two fiels are set readonly according to the status of the purchase
order: product_id and product_uom_id. They become readonly once the
purchase order is confirmed, but according to the options a user is
still able to add purchase order line. Make sure to always send the
required fields to the server.
Fixes#21519
On MS Windows, the mimetypes module relies on the Windows Registry to
guess mimetypes. As a consequence, when generating assets bundle for
javascript files, the mime type of js files may be wrong. In that
particular case, the Odoo user is facing an empty web page.
This commit enforce 'application/javascript' for js assets when they are
saved as ir_attachment in the database.
This commit is a backport of 77ca51f
When a stage on crm leads is removed, the leads appear in an
"Undefined" column in a kanban view, but this was not handled when
getting the "graph data" (eg. in version 11.0 for sales team graphs
when grouping by stage in CRM > Reporting > Sales Channels).
opw-784455
closes#21507
Christophe Simonis