Steps to reproduce
- Install Accounting
- Create user and employee, "user_acc", with Accounting-Accounting and no Expense rights
- Take the expense in "To Submit" state for the employee different than user_acc and create report
- Save the report.
Bug - We get the error that required field 'name' is not set and expense lines disappear.
task - 3099142
closesodoo/odoo#107903
X-original-commit: c5765be58dcdb3f6d766e6ce409a6e0f8a82e45b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When filling a Sales Order applicability rule line, the financial
account prefix is useless, as it will not be used.
Thus we can make it invisible in the case of business_domain corresponding to sales and purchases.
task-3040927
closesodoo/odoo#105014
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
* = {account, sale, purchase, hr_expense}
When a plan is mandatory for SOL, POL or expenses, the flow should still be blocked when pressing the button, and not only when creating analytic lines.
We add the info in the context of the button, so automatic flows are still not blocked.
When the applicability rule requires a mandatory analytic distribution, raise an error upon :
- confirming PO,
- sending or confirming SO
- approving Expense Report by manager.
t-3040929
closesodoo/odoo#107166
X-original-commit: 8623a7850288828759db125b1054b0fed6b6b135
Signed-off-by: William André (wan) <wan@odoo.com>
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
It is not possible to post the journal entries related to an expense
paid by the company
Steps to reproduce:
1. Install Expense
2. Create an expense payable to company
3. Set an amount
4. Create report
5. Submit report
6. Approve report
7. Attempt to post
8. An error is thrown
Solution:
Relax the constraint on account.move.line linked to an expense paid by
the company
Problem:
The constraint `_check_payable_receivable` in the account module forbids
to post the journal entries even though they are correct
opw-3038648
closesodoo/odoo#106266
X-original-commit: 09274db12a25c178974dc20c4d669134e21cddbe
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Steps to reproduce:
- Install `Expenses` module
- Go to Settings > Technical > Email > Aliases
- Edit the `expense` alias
- Ensure the model is `Expense`
- Set `Alias Contact Security` to `Everyone`, then save
- Send an e-mail to the expense alias, using an e-mail address not
referenced on one of the employees.
Issue:
Error in logs related to `currency` variable.
Cause:
Trying to create an expense for a non-existing user, therefore,
no currency is set.
Solution:
If no user is found, no need to create the expense and let the orm
raise the error that a required field is not set (field employee on
expense).
opw-3027350
closesodoo/odoo#106057
X-original-commit: a339caa2faf8cde0ec1c85079b9d74f31b055f24
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Purpose of this commit is to cleanup alias usage in hr_expense. Indeed it
is currently used as a master data without being cleanly supported.
In this commit we
* globally avoid crashes if the alias data has been removed;
* recreate Xml ID record if it has been removed as it is considered as
being a master data;
* avoid issues when trying to configure the expense alias in settings if
alias has been manually removed. Setting a name now creates the alias
and an XmlID if it has been removed;
* rename a generic 'use_mail_gateway' field into 'expense_use_mail_gateway'
in order to avoid conflicts with future changes in generic settings linked
to email gateway and configuration
* fix empty list helper: it is now translated and correctly encode parameters
given to 'mailto';
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#105992
When printing a check that comes from an expense,
the check has no reference to the move from which
the payment has been created.
The reason is that we filter the move by taking
only outbounds to complete the check informations,
but moves from an expense are of type entry.
With this commit, we allow moves coming from
expense to be taken into account by adding a
check on move.move_type.
opw-3044141
closesodoo/odoo#105157
X-original-commit: b588329a45633f0dec89fe195cf24a8b3671dedd
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
During a refactoring [1], the behavior of having the taxes included in
the price for all expenses was broken/removed.
All the fields related to taxes are computed should be computed with the
correct context key when computing entries related to expenses. This is
preferred to adding the context key only when creating because it will
then keep the behavior even when editing the document.
task-3043252
[1]: https://github.com/odoo/odoo/commit/d8d47f9ff8554f4b39487fd2f13c153c7d6f958dclosesodoo/odoo#104746
X-original-commit: 6e944ac5fe108d5f2bc2d3f41ab547efd88a5ede
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
The fields were not correctly aligned.
task-3040395
closesodoo/odoo#104195
X-original-commit: f5cec113222db06f427f17a0170d45e2022b5b39
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Since odoo/odoo#95729
nodes with a `groups=` are completely removed from the views when
the user is not part of the group, instead of being made invisible.
In that PR, views have been adapted to add back fields, with invisible="1",
when they were required, for instance when they were used in a domain
of another field which was still there despite the user is not part
of the given group.
As `tree` views having `multi_edit="1"` where not considered
as editable views, the domain of fields in these views were not
validated:
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1460
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1321-L1322
while they are well required for the web client,
in `multi_edit="1"` this is possible to edit relational/many2one field,
and therefore it will do `name_search` calls using the domain of the
field, and therefore the fields used in these domains must always
be present in the views. Without it, a crash in the web client occurs
when attempting to edit the relational/many2one field.
This revision targets to consider the `multi_edit="1"` tree views
as editable, to make the field domains validated as they should be.
Hence, views are adapted to add back fields with `invisible="1"`
when they are required in domains of other fields.
Part-of: odoo/odoo#103790
The `analytic_distribution` field is a Json.
It was stored temporarily as a char.
Search is not available yet, so we do queries by hand when we need to search on keys.
Also added a constraint on account_analytic_distribution_model,
so we don't have models with accounts specific to a company when the model has no company or another company.
It would cause an issue when looking at the models from another company.
X-original-commit: 7064c95aa04e5138bb12ae97acfee04ebb67cc0e
Part-of: odoo/odoo#103097
Currently, when posting accounting entries from an expense report, the accounts set on the expense entries were not taken over in the account move lines. Also, the employee was not set as the vendor of the purchase receipt (account move).
This PR makes sure that both the accounts on the expenses, as well as the vendor (employee) is set on the account move created from an expense report.
Tests added as well.
closesodoo/odoo#103037
X-original-commit: 066c70e483b2f49ae48cb98ddc412014f4fe258a
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
The recent switch from tables to css grids for form views `group` nodes
has introduced several inconsistencies/issues with several views accross
modules - these will not be the last fixes.
closesodoo/odoo#102174
X-original-commit: 836568dfd59886a6d52f15e0e2109709903b6803
Related: odoo/enterprise#32295
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Add choices for the business domain on applicability rules, so rules are more precise
Also put 'general' as domain from the view when it's what should have been.
Make analytic field visible since owl migration (for sale and purchase)
closesodoo/odoo#102461
X-original-commit: c5867d5009a7fb448fff1be487b9e9c3e7945d4b
Related: odoo/enterprise#32421
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
This PR adapts the form views since the merge of #100570.
task-3002465
closesodoo/odoo#102750
X-original-commit: 03b7ed51d9bb1e0717d21cd6516f98e477a2c926
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps:
Create a expense with product having no cost and having the
total amount directly added from expense sheet.
then create an innvoice.
Issue:
While adding journal lines in hr expense the amount per unit
was calculated as the total amount of product such as quantity into the
price per unit inside the invoice.
Cause:
expense's total_amount was passed as price_unit instead of expense's unit_amount
and due to that total amount was multiply by qty so wrong value was passed.
Fix:
If unit_amount of product is non-zero then pass the unit amoun for invoice or
pass the total_amount if unit_amount does not exist.
task-3000758
X-original-commit: d47ca52a2cb8eb7146094e7d172f41f6aa3621a2
Part-of: odoo/odoo#102768
The following PR - odoo/odoo#98914 introduced changes in
accounting analytic.
The changes were applied to 'hr.expense' but they were not applied to 'hr.expense.split'.
Which lead to traceback.
task - 2997510
closesodoo/odoo#101997
X-original-commit: 4f5c531b854271284238b5a13f95d66eb2e12f93
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Slightly modify the view as well, including now showing the
'attach receipt' button before the first save (as it will trigger
a save a work properly since its migration to owl).
X-original-commit: 283779a8999b6ae93996bafb46b879dc6a3e0112
Part-of: odoo/odoo#101729
Make it possible to override both before and after execute actions on
all view controllers using `useViewButtons`.
This avoids having to change a value in the env to override the function
being called when clicking on a button.
closesodoo/odoo#101310
X-original-commit: 9f6c2b8e969635f35786d58ee89ca767ff57144d
Related: odoo/enterprise#31860
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
When creating an expense paid by the company, we want the expense
to be on a bank journal. This is currently incompatible with the
current constraint we have that force expense of type 'in_receip'
to be on a purchase journal. Since expense only behave like type
'in_receipt' we can ignore that constraint.
closesodoo/odoo#101307
X-original-commit: f95eb814166646ec3113d35b910a677b21737cd1
Signed-off-by: William André (wan) <wan@odoo.com>
Bank statements are now optional in accounting. The users add statements directly and can assign statements for control reasons.
The users can enter end date and end balance real for the statements and attach the bank statement scan.
The system checks if there is a gap (lines without statement) before current statement and warns the user
with decoration, also we check if the ending balance match the accumulated balance of the last line.
Bank statement lines now show an accumulated balance and can be sorted by drag and drop in the same date, if the user drags a line
to a position with lines of another date, it simply doesn't have any effect.
Rename accumulated balance to cumulative balance, a better name
closesodoo/odoo#99092
Task: 2879904
Related: odoo/upgrade#3906
Related: odoo/enterprise#30824
Signed-off-by: Laurent Smet <las@odoo.com>
The goal of this commit is to get rid of the analytic tags as they were confusing, serving tag purposes as well as distribution on analytic accounts.
Everywhere analytic tags were used as a distribution have been replaced with a new widget that will dispatch distribution on analytic accounts. If there was an analytic account field next to the tags, it has been included in the distribution.
Analytic tags that were used simply as information tags have been removed.
To fill the new widget, there are now 2 kind of rules that will help fill and prefill it.
The first are applicability: previous groups have been removed, and have by replaced by plans. Each account is required to have a plan. These plans define when they are available in the widget: a default applicability per plan and applicability lines that can specify rules following the context of the widget.
The second one are distribution models, that will replace previous default rules but follow the same principles. The accounts (and so the plans) that will be given by the distribution model can override the applicability rules from before.
closesodoo/odoo#98914
Related: odoo/upgrade#3885
Related: odoo/enterprise#30743
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Habib (ayh) <ayh@odoo.com>
The field is related towards the 'manager' field of the expense sheet,
which means that when the approver is suggested automatically based
on hr data, the expense records get written a value for this field
(which is not in the view) which gets logged as:
- None -> Mitchell Admin (Approved By)
which seems to suggest that:
- the expense has been approved (it has not, a report was created)
- Mitchell Admin has approved: it may not be him (as when approving,
the 'manager' field does not log who did the approval but who was
supposed to initially)
Disabling tracking for this field (which contained no actionable
information at best, and incorrect suggestions at worst) makes this
problem go away.
closesodoo/odoo#100241
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The context before click button cancel in expense sheet not cleaned yet.
closesodoo/odoo#100288
X-original-commit: 6f8d3d989cc024c8e5b3e9e1a6b2f4af636721d6
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Revision 26a5653f48 introduced
the possibility to set up a default journal for accounting
entries created by "employee-paid" expenses
This commit adds the same possibility for the "company-paid"
expenses (because why allow it for one and not the other?).
closesodoo/odoo#99993
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In the Employees app, when using the department kanban view and clicking on the
Time Off Requests or Allocation Requests, it leads to a tree view but the department
from which the user comes from is not part of the filters.
This commit adds the department in the filters of the tree view.
Due to the search panel being present in the tree view, the department filter is removed from the list of
filters to avoid a duplication of the filters in the search panel.
task-2939207
closesodoo/odoo#97773
Related: odoo/enterprise#30358
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Current outdated pictograms had to be replaced with better designed and
visually consistent pictograms.
PNG were replaced with SVG to gain in quality and lightness.
Unused category icons were removed.
task 2951089
closesodoo/odoo#99276
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Turns out having a <sheet> node is not well supported in layout
for dialogs, as it introduces unnecessary horizontall scrollbars.
closesodoo/odoo#99524
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
The goal of this revision is to get rid of the `groups_id` field of the model `ir.ui.view`.
- This feature wasn't really known or used by most developers,
and not straight-forward to understand.
Removing it allows one less complicated thing to learn for developers.
Besides, thanks to odoo/odoo#95729,
changing the behavior of the `groups=` attribute,
we can easily get rid of this `groups_id` feature
by simply adding `groups=` in the elements of the views
using the `groups_id` field, it will have the same effect:
adding the elements in the view only for the users part of the specified group.
- By getting rid of the groups_id many2many field on ir.ui.view,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the groups_id groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
Part-of: odoo/odoo#98551
Major changes:
- converted list view to owl
- merged menus
- added CREATE REPORT button on hr.expense that reports either
ticked draft expenses, or all the draft expenses for the user
- added dynamic buttons on expense.sheet list view
- added searchpanel on expense.sheet for team approvers and above
- moved (and changed) expense categories from demo to data
- added support on drag'n'drop while in list and kanban view of
expense for quick upload
task - 2831036
closesodoo/odoo#93802
Related: odoo/enterprise#28474
Related: odoo/upgrade#3778
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Just doing the summer file cleaning. Move mail data into files named based on
their model, easing maintenance and searching for those data.
Spotted during Task-2207626 (Rating: Delay rating notification to ease feedback)
Part-of: odoo/odoo#98661
This is an oversight of odoo/odoo#95729
In a database with multi-uom disabled,
when attempting to create an expense choosing a product
with a different unit of measure than the Unit(s)
a ValidationError was raised to the user
regarding an UOM incompatibility
e.g.
- Create an expense
- Set the product "[MIL] Mileage", using the uom "km"
- Save
-> ValidationError about UOMs
This is because the above mentioned PR makes the
`product_uom_id` completely removed from the view,
and the onchange no longer set the uom correctly within the form.
Solve this by setting `precompute=True` on the UOM field,
and the other fields using the same compute method.
In addition to solve the issue, it also allows to create
more easily expenses from the XMLRPC API:
Before, when creating an expense for the product "Mileage",
it was required you set yourself the uom correctly
in your API call,
even if multi UOMs was disabled in your database.
After, it's no longer mandatory to pass the UOM to use,
it is correctly computed from the product directly,
by default.
closesodoo/odoo#98662
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Before this commit, when a ListViewHeaderButton was clicked, the view
context wasn't sent to the server.
As ListViewHeaderButton shows, the onClickViewButton API is not correct.
It expects a record in params but this is not correct in the case of
ListViewHeaderButton. So we decided not to pass a record but a getParams
callback that allows us to calculate the params when we need them.
Part-of: odoo/odoo#97558
- A user has accounting permission but no employee permission, when that user register payment in spending it gives an error that does not have access to the bank_account_id field
- This commit allows the user to read the bank_account_id field when register payment
Original PR: odoo/odoo#98432closesodoo/odoo#98485
X-original-commit: 35e07de192dfeba0979170ba8421e4a61c5a483b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Steps to reproduce:
1. Install hr_expense,inventory
2. Enable unit of measure in the invetory setting
3. Create an expense product with a uom
4. Switch to mobile display and refresh
5. Try to create a new expense, the quantity field is not visible
Cause:
In 15.0 it was decided in PR #68387 to switch from the selection widget to options. This changed the css of the element.
Solution:
Checking the entire codebase with the following regex "<div.*class="o_row".*\n.*class="oe_inline".*\n.*class="oe_inline".*\n.*<\/div>"
in order to find an other usage of o_row with two inline element yielded no result other than hr_expense. In order to minimise the amount of changes,
a local fix of the styling is probably more appropriate.
opw-2924276
closesodoo/odoo#98336
X-original-commit: 0754f71b5e4760b1956f196f50bd6550e5fc41e0
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The mistake was made in odoo#81904
Instead of 'default_partner_bank_id' we have 'partner_bank_id' in the
context of action_register_payment.
In this commit, we undo that mistake and also backport the change to v15.
task - 2774594
closesodoo/odoo#97886
X-original-commit: 5c8b74bb3bddd67b5a76d37f7d97a1d5d77c00c4
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Only for terms containing Credit Note and expenses
closesodoo/odoo#97840
X-original-commit: 1754b094a66476a0bdb29fe60dc5583c03336c3f
Related: odoo/enterprise#30262
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The domain "id = False" for the visibility of the "Split Expense"
was set because I (wrongfully) thought it was necessary to save
the record before the wizard could use it.
That is not the case, as the button call will first save the record
anyway - it was weird not to have this button immediately and made
the feature hard to discover.
I also changed the "create report" button for the same reason - there
is no need to restrict its usage to "saved" records (unlike the
"attach receipt" button which is a specific widget that needs the record
to exist in database to work).
closesodoo/odoo#97634
Signed-off-by: Kevin Baptiste <kba@odoo.com>
TLDR:
* invoices are implemented using computed methods instead of onchange
* the synchronization only happens when switching tabs in the Form view
to improve perfs.
_______________________________________________________________________
The whole engine of the synchronization of Invoices to the Journal
Entries has been refactored
* by using computed fields instead of onchange functions
* by synchronizing only from invoice to journal entry in `create` and
`write`
* by saving when switching tabs on the Invoice form, to synchronize
before showing the values
This comes with numerous advantages:
* no need to call the onchange methods manually
* no need to use the Form emulator to build invoices (i.e. EDI, OCR,
intercompany, ...)
* the performance for invoices with many lines improves drastically, going
from 2 minutes to 4 seconds to create an invoice with 500 lines
* the model is more declarative, we can now see how the values are computed
instead of having the values being copied from various places.
* remove the hack in `onchange` that disabled the recursivity of it,
which was unexpected and needed to be managed manually in all the
onchange methods
This means that:
* Some fields need to be exclusively computed on journal entries values
or invoice values, more specifically the Tax Summary widget.
It is now
- computed from entry lines, when opening the view
- computed from invoice lines when changing those, because the tax lines
will need to be recomputed anyways, erasing previously set values
- set with an inverse function when saving; after the sync has been done
* Some possible operations previously possible have been dropped.
(i.e. look at the removed test test_in_invoice_line_onchange_accounting_fields_1)
This is because such a behavior was undefined (how is changing the balance going
to affect the unit price? How is the amount currency going to affect it?)
_______________________________________________________________________
Implementation Details
----------------------
The "dynamic lines", meaning the payment terms and the tax lines are now
only created in the `create` and `write` functions.
In order to reduce code duplication, it has been implemented using
context managers used in both `account.move` and `account.move.line`
These context managers help comparing the values before/after, acting
like a local `onchange`, but getting benefit from the dirty flags from
the `compute` dependences.
This is relying on computed fields on the move (`needed_terms`) and on
the lines (`compute_all_tax`) which contain the values needed for the
related move.
Depending on the needed values and the existing values (`term_key` and
`tax_key`, respectively) the context manager will determine what needs
to be created/updated/deleted.
Some related changes are to produce a `dict` instead of a `str` for the
`tax_totals` (previously `tax_totals_json`) fields, by simplicity to
reduce the complexity of IO, and simplicity of debugging, because the
logic of the field needed to change (cannot be computed at the same time
anymore since it needed the lines to be synced)
By simplicity, and also because it makes more sense, some boolean fields
have been merged into `display_type`:
* `is_rounding_line`
* `exclude_from_invoice_tab`
* `is_anglo_saxon_line`
The `price_unit`, `quantity` and other "invoice fields" are now not set
anymore on lines that are not product lines since it didn't make any
sense to have it.
Performances
------------
You have to keep in mind that a simple `create` didn't compute a lot of
fields, for instance not taxes were set, no payment terms,...
Now it does.
```python
import random
from timeit import timeit
from odoo import Command
domain = [('company_id', 'in', (False, self.env.company.id))]
products = self.env['product.product'].search(domain).ids
partners = self.env['res.partner'].search(domain).ids
taxes = self.env['account.tax'].search(domain).ids
def create(nmove, nline):
self.env['account.move'].create([
{
'move_type': 'out_invoice',
'partner_id': random.choice(partners),
'invoice_line_ids': [
Command.create({
'name': f'line{i}',
'product_id': random.choice(products),
'tax_ids': [Command.set([random.choice(taxes)])],
})
for i in range(nline)
]
}
for j in range(nmove)
])
# After | Before
print(timeit("create(1, 1)", globals=globals(), number=1)) # 0.11 | 0.09
print(timeit("create(100, 1)", globals=globals(), number=1)) # 2.76 | 2.50
print(timeit("create(500, 1)", globals=globals(), number=1)) # 14.56 | 12.34
print(timeit("create(1, 100)", globals=globals(), number=1)) # 1.03 | 5.52
print(timeit("create(1, 500)", globals=globals(), number=1)) # 3.99 | 125.02
print(timeit("create(50, 50)", globals=globals(), number=1)) # 19.44 | 79.55
```
Another metric that can be used is running the test suite with
`--test-tags=/account` (only `account` installed)
* before: 404s, 267127 queries (366 tests)
* after: 318s, 232125 queries (362 tests)
Why this commit title?
----------------------
Someone told me that this was the perfect way of naming your commits.
c04065abd8
task-2711317
closesodoo/odoo#96134
Related: odoo/upgrade#3715
Related: odoo/enterprise#29758
Signed-off-by: Laurent Smet <las@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
sofiagvaladze