Some view extension (in this case mainly counters on partners, like
small Sales Orders counter badges etc.) should not be visible if you
don't have the relevant rights.
Makes it easier to later reconcile payments with
bank statements. For eCommerce orders the payment
transaction happens before the creation of the invoice,
so the invoice number is not sufficient to quickly
find a match for reconciliation.
This allows to import acccount.move.line via csv and provide the field 'tax_ids' (which is needed for the tax statement).
This option is now a context's key, replace the key 'dont_apply_taxes' which was now useless
When doing a reconciliation, make sure that the tax amount is properly
rounded to the currency precision. Otherwise, if the rounding policy of
the company is "round globally", the amount recorded won't be rounded.
opw-688399
Closes#13452
An issue arises in the following use case:
- Company rounding policy in "round globally"
- Tax excluded of 20 %
- Create a statement of 3.80 EUR
- Reconcile the statement thanks to the reconciliation widget
- Click on "Choose counterpart" in order to manually create a line to
reconcile with the 3.80 EUR statement
- Add an amount of 3.17 EUR, and choose the 20 % tax
The widget creates an extra line of 0.00EUR . This is because the
remaining amount is 0.004.
The reason lies in the `monetaryIsZero` function. There is a hardcoded
decimal precision of 4, while it should be 2 for EUR.
We add an extra parameter to the function so it is possible to adjust
the decimal precision required. Only the problematic calls are modified
to avoid unnecessary intrusive modification.
Closes#13452
opw-688399
In some specific cases,it is necessary to call the `compute_all` method
and prevent any rounding to be done. This adds some flexibility in the
method to override rounding thanks to a 'round' context key.
Related to #13452 and commit 2e4777bb32
opw-688399
Commit 8ad0c0f3 introduces back the base amount taken into account for
tax calculation. However, the way it calculates the amount is wrong in
several cases:
- the tax amount is a percentage
- the tax is calculated thanks to Python code
opw-686846
We use summary instead of class as classes are often stripped by gmail or even odoo.
Summary is a commonly kept attribute so it is used in the mail gateway to hide
what is considered as internal content and should not be rendered in the chatter.
The action was never there but added by overwrite in sale_teams which (wrongly)
shared the same ID. After 11812b0 which splits the menus, this menus had no
longer an action added by sale_team module.
WHen checking `Dedicated Refund Sequence` in a
sale / purchase journal,
the field `Refund Entry Sequence` must be filled with a sequence.
Otherwise, later, when issuing a refund invoice, it won't be able
to generate the number of the refund invoice as it won't be able
to find the sequence to use.
opw-687839
Double tap
* fix wrong group xml_ids probably introduced when rebasing the branch
removing workflow after xml-id-pocalypse
* fix wrong group used for buttons, should be for Billing users
Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:
- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
translated
The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).
Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).
This commit correct all the external ids tagged as from base or other incorrect
modules.
=======
Purpose
=======
The company form should be heavily simplified. It's complex to have some settings on the company form, and others on the Settings menu of the related app. It would be much easier to have all settings in Settings menu (res.config) and nothing on the company, even if some of the Settings are multi company. (Stored on the company but set from the Settings menu).
The account.move has already self.date for the date field (cf the method
`_prepare_reconciliation_move`). As the field date on the account.move.line is
a related, it makes useless updates to write it here.
Same issue for journal_id field
Avoid setting a value for a related field as it will trigger onchange update.
This code was relevant when the date was different on the move and the line but
is no longer needed.
Remove all the `if vals.get(mandatory_field)` to simplify this method and remove
dead code or condition always true.
The field journal_id and date are both required on account.move and are stored
related on account.move.line.
Setting the required on the account.move.line allows to make it required in the
views or for the ORM but in practice it will be same as it's required on the
parent.
Making it required is a performance killer as it forces to specify a value for
the create which will retrigger an update on the parent move.
This means that adding a line with a date value on an account.move with already
10 lines will trigger 11 updates (date of the new line -> date of the move ->
date on the 10 existing lines), even if the value has not changed.
Christophe Simonis