The desired flow of currency rate in expense is as followed:
- (default) Use Odoo currency rate
- Allow the user to set a custom rate (to include fees) when changing
the total amount in company currency
- Revert to the default behaviour when the currency is changed
or the amount in foreign currency is changed
This aims to fix how currency rate is computed and overridden
- Reorganize all currency rate computation, so it doesn't revert to Odoo rate
at every compute call
- Deals with a bug where a "total_amount_currency", when changed
just before calling "action_submit_expenses" would not trigger
the computation of unit_amount
- Force save when changing currency on expense form view to prevent a bug
where the first modification of "total_amount_company" would be canceled
(due to the new behaviour of currency rate computation)
- Removes unit_amount_display from views as it should be removed
in later versions and is deprecated since 16.0
task-3476569
closesodoo/odoo#137598
Signed-off-by: Laurent Smet (las) <las@odoo.com>
As from the 16.2, when splitting an expense, the wizard first opens so you
can modify the result of the splitting and when clicking the split expense
button, you are redirected to a new and blank expense. Inside of the
splitting wizard, if you click on a total and modify it without pressing
"Enter" or "Esc", the currency symbol stays to the extreme left of the
column. These two behaviors are not desired.
This PR changes the redirection after splitting an expense so the user is
brought back to the tree view of the expenses and the total field of the
lines inside the splitting wizard is modified so the symbol stays to the
right of the column.
For the redirection, a different return on the splitting action is added
and is triggered when the action is called from inside the wizard.
For the symbol, an adjustment to the field size is made so it stays
shorter until a bigger value is entered.
After this PR, the expense flow is improved with a better redirection of
the user after he split an expense and the display of the total amount
column is clarified
task-3443396
closesodoo/odoo#131638
X-original-commit: 3b64971045741e5dbea93a8961a86a73cdeeb891
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Thomas Becquevort (thbe) <thbe@odoo.com>
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
This commit makes hotkey uses more coherent throughout the entire
codebase by setting alt+q as main shortcurt for confirm and default
actions and alt+x for cancel actions.
task-3370463
closesodoo/odoo#127469
Related: odoo/enterprise#43694
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
When an expense sheet move is created, there is only one
outstanding line, but it is usual to pay separately.
That makes the reconciliation step harder.
This makes sure one move is created per expense
Task-3328877
closesodoo/odoo#126805
Related: odoo/upgrade#4873
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Rework of the hr.expense workflow so that:
- expenses paid by employee generate purchase.order
- expenses paid by company generate entry that look like payments
Main reason being that purchase.receipt are not active by default.
That makes the entry hard to find, holes in sequences, inconsitency
with payment states.
It also remove the refusal of expenses as this was dead / inaccessible code, only reports can be refused.
task-id: 3126550
[community](https://github.com/odoo/odoo/pull/110518)
[enterprise](https://github.com/odoo/enterprise/pull/36090)
closesodoo/odoo#110518
Related: odoo/upgrade#4266
Related: odoo/enterprise#36090
Signed-off-by: Laurent Smet <las@odoo.com>
This method is not used by rpc calls and wrongly allowed users to read the standard_price
field by calling the method through rpc.
Make it private to reduce its uses and avoid this potential leak of information.
closesodoo/odoo#113234
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, the user had to go over each expenses to
register a payment.
He now has the possibility to do so from the expense report
tree view via the "register payment" button.
task-id: 3116195
[community](https://github.com/odoo/odoo/pull/109671)
closesodoo/odoo#109671
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
currently in the expense refuse form view the reason field is too compact to enter a reason in the field.
Expenses -> My Expenses -> My Reports , open any submitted expenses and click Refuse button.
closesodoo/odoo#109157
X-original-commit: 5fda586cc9f738471c6b34fd982bb80e5dd259d3
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The - Split Expense - feature was introduced in odoo/odoo#90770
In this commit we fix the following bug, related to it:
Steps to reproduce:
- Create expense with tax_ids.
- Click on - Split expense on the expense form. From the first
hr.expense.split line remove the tax_ids. Rename it as '1',
so that it is easier to find it back for checking later on.
- Click on - Expense split on the wizard.
Check the resulting expenses. Specifically, the one with the name '1'.
Current behavior - The tax_ids field for the first expense
(with the name '1') is still populated.
Expected - The tax_ids field for the first expense should be empty.
On top of that, we introduce the tests that check Split Expense flow.
task - 2831024
closesodoo/odoo#108049
X-original-commit: 3aaf4f1ee2967793c9a4c29766cec63d2c6e3cf4
Related: odoo/enterprise#35005
Signed-off-by: Kevin Baptiste <kba@odoo.com>
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
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>
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>
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>
- A user has accounting permission but no employee permission, when that user creates a 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 creating a payment
closesodoo/odoo#96607
X-original-commit: 8045780cbf2dc36d533dbfd3315bab31a229351d
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Task 2850882 modified the behaviour of expenses to support working
with all purchase taxes, regardless of their 'price included'
configuration.
We missed a domain on the split lines though, so it was impossible
to use 'all taxes' when splitting an expense.
This commit resolves that limitation/oversight.
closesodoo/odoo#95627
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Task: 2856281
- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed
closesodoo/odoo#93212
Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
In expense flow the taxes are calculated as included in price.
Prior, to guarantee it, we had domain - ('price_include', '=', True) on taxes.
That could be inconvenient from user's point of view, as they first needed to
define taxes with price_include = True. That led to users duplicating taxes
between included/excluded just so that they could use taxes in expense.
Now we force taxes to act like price_include = True. This way, user does not
need to define taxes just for expense's purposes and still taxes will be calculated
as it supposed to be - included in price.
task - 2850882
closesodoo/odoo#94392
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose: Sometimes, taxes are distinct on parts of the expense
(for example alcohol and food).
Therefore the expense should be split in two.
In order to split the expense, we added an wizard.
When creating a new expense from the split, we also
copy the attachments.
'hr.expense.split' has to have the similar logic and dependencies between
the fields as 'hr.expense' does. For example, in case we change the
product_id to the product that has cost defined on it, it should have
the same behavior as expense has. In particular, the 'total_price'
will be set and the user should not be able to modify the amount.
Similarly, if we change the product_id to the one that has no tax defined
on it, then split tax_ids should be cleared out and be set to readonly.
Similar logic goes to sale_order_id (Customer to Reinvoice'),
we should not be able to set it, in case the product can not be re-invoiced.
All of the above constraints leads to the amount of similar code to to the 'hr.expense.split' side.
But it could not have been avoided, if we want the smooth flow.
task - 2831024
closesodoo/odoo#90770
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Current behavior:
When cancelling an expense payment, the expense state was not modified and was still 'paid' when it should be 'refused'.
Steps to reproduce:
- Create an expense and post the expense and register a payment for the expense.
- Then go the vendor payments and cancel the associated vendor payment.
- The expense still shows as paid in the expenses page.
opw-2711383
closesodoo/odoo#82496
X-original-commit: 16459957d23f4bdfddfe96d72ef96cbdc6fec539
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Steps to reproduce:
1. Install the Expenses and Contacts Apps
2. Go to the Contacts App
3. Add a bank account to the private address linked to a specific employee
4. Go to the Expenses App
5. Create an expense for the employee and try to register the payment
6. The bank account will not show up
Solution:
If the employee doesn't have a bank account selected in the Employee form, we select the first bank account of his private address
OPW-2655450
closesodoo/odoo#80774
X-original-commit: cb998c804a0e7b14393637f372f1f32051fd548d
Signed-off-by: Olivier Colson <oco@odoo.com>
Define `data-hotkey` on most used action buttons.
For the modals, the following keys are dedicated for "special"
actions:
- Alt+G: add
- Alt+V: save
- Alt+Z: cancel
closesodoo/odoo#73275
Taskid: 2588233
Related: odoo/enterprise#19464
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When registering a payment on an expense, we are currently using the first
bank account set on the partner if no account is set on the account move.
We should use the bank account defined on the employee instead, and
fallback on the partner only if it is not set.
closesodoo/odoo#72077
X-original-commit: e0335a71afbeb34c5fad9a71bd1b53d5d88d6fa6
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Display a confirmation dialog when a user creates duplicate expenses.
Two expenses (or more) are considered duplicates when they share the same
date, amount, product, employee, company and currency.
closesodoo/odoo#64190
Taskid: 2368636
Related: odoo/upgrade#2061
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Use the one defined in the account module allowing paying multiple journal entries
and group payments together.
- Remove the hr_expense_check module that contains only duplicated features regarding the
register payment wizard.
--task: 2273528
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
Impacted modules:
hr, hr_contract, hr_recruitment, hr_payroll, fleet, hr_skills, hr_appraisal, ....
Several onchanges have been converted to computed fields in the following modules :
Community :
- hr
- hr_contract
- hr_recruitment
- hr_work_entry
- hr_maintenance
- hr_expense
- hr_expense_check
- hr_holidays
- sale_expense
- account_analytic_default_hr_expense
Enterprise:
- hr_contract_salary
- hr_referral
- hr_payroll
- hr_payroll_expense
- test_l10n_be_hr_payroll_account
There are still 2 onchanges with complex behavior that couldn't be converted easily:
- an onchange that updates "tz" (timezone) that is defined as a related field
to "resource_id.tz". Apparently it is useless except to initialize the default
value of "tz".
- an onchange that updates "name" that is defined as a related field to
"resource_id.name".
the applicant.
closesodoo/odoo#45414
Taskid: 2169099
Related: odoo/enterprise#8572
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Create journal entries as soon as bank/cash statement lines are created, temporary booked on a suspense account set on the journal.
- Simplify the management of "blue" lines in the reconciliation widget. A "blue" line is now a journal item using a temporary liquidity account (outstanding payment/receipt accounts, set on the journal).
- Adapt and simplify the bank reconciliation report.
- Remove the bank reconciliation threshold date. The reconciliation report will show the not already reconciled journal entries using a liquidity account and the not already reconciled journal entries using a temporary liquidity account. Without accounting, an account.payment will involve directly the liquidity account and then, will be considered as a statement line directly.
- Remove the post_at bank reconciliation feature. The "paid" state will be set on the invoices only if reconciled with a journal entry involving the journal's liquidity account.
With invoicing, the payment will do that so the "in_payment" state should never be shown up.
With accounting, only the statement lines have the power to move an invoice to the "paid" state.
- Fix various corner cases about the management of multi-currency in bank statement lines.
- Fix the conversion dates in multi-currency: Since the bank/cash is always used on the statement lines, it will use always the real "bank" date instead of the fictive payment one.
- Ensure the 'reconcile' method will raise an error if the involved moves are not posted.
related enterprise PR odoo/enterprise#7019closesodoo/odoo#41301
--task: 2092096
Related: odoo/upgrade#1018
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Incorrect forward-port of e09798098679f made in 51d49517a8b5af2d1c85d9c6.
closesodoo/odoo#45775
X-original-commit: 099d0d6785b85dd67ef091fdaef084713fafb3c0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When making a payment for multiple vendor bills at once, it is possible that payments will be generated without any recipient bank account for payment methods normally requiring one. In such cases, the user needs to be able to correct the payments by cancelling them. It was not possible.
closesodoo/odoo#45082
X-original-commit: 9aec95dccef48a9ec89691f5721619ffc0e4da56
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
In 0.15 accessing werkzeug.urls functions directly through werkzeug
is deprecated, the shortcut will be removed in the eventual werkzeug
1.0.
Fix existing uses of these shortcuts. Also cleanup some imports when
they're not far from a werkzeug* import being altered.
Purpose
Fix multi-company access issues following the big changes that happened
(the 13.0). Make the usability better in order to avoid potential
multi-company issues for the user.
Specification
Check the related commits to see the different fixes that have been
made. For more information about the technical/functional considerations,
check the related task.
Taskid: 2088891
X-original-commit: 5c8df3a5e5f7960e5eab6439e0a32a06224ba826
This commit tries to fix multi company problem in Expense application. Indeed, no check
were done to ensure this business flow. Some technical decisions were made:
- journal company: the journal define the company in which the accounting entries will be
created. We know ensure with 'domains' and constraints that the journal have the same
company as the expense sheet.
- journal conditionnally required: the journal is only required when posting the expense. It
is set by defaut on creation, but can be modify by accountant users. This is why the expense
company determine the journal and not the opposite.
- company fields required: As we need to use the company from the expense / expense sheet to
determine the journal field and since expense models are business models, we needed to put
company fields required.
Business Flow
When an employee creates an expense, the expense should be in its current company. A
product from any allowed company can be chosen. Only the taxes of the expense company are
applied to compute amounts. Then a report (sheet) can be created. We ensure that the expense
lines of a report belongs to the same company as the report and to the same employee. Once
submitted and approved by manager, the account journal can be set: it is forced to be in
the same company as the expense report. The accounting entries are created in the journal
(and expense report) company. As the analytic account can be shared (company is not set)
the analytic entries will be in the expense company (handle by the accounting module).
The payment is now registered in the expense company.
Migration
As company fields are now required, fill the company fields with the company of the related
employee, or fallback on the one from the journal.
Task-1999686
closesodoo/odoo#36447
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
Create two expense and put them into one sheet
Post the sheet
Make One partial payment with the wizard (Register Payment)
Do it again for the residual amount
Before this commit, it crashed because the second payment tried to reconcile
itself with an already reconciled line
After this commit, all the lines that need to be reconciled
actually are without crash
OPW 2065501
closesodoo/odoo#36454
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When the many2xxx field relates to a model where company_id is required, set
this domain [('company_id','=',company_id.id)]
When the company_id field of the related model is not required, set this domain
['|',('company_id','=',company_id.id),('company_id','=',False)]
When setting the domain on a field which is in the treeview of a xxx2many field
evaluate against the company_id of the 'parent'.
Some constraints have been added on sereval models. Take a look at the complete
specification for more details.
TaskID: 2024446
Closes: #35266
Signed-off-by: Yannick Tivisse (yti) <yti@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.
Purpose
=======
Fields `customer` and `supplier` on `res.partner`
are mostly used in domains of many2x fields.
Those domains can confuse end users because they don't
see the partner they are looking for; and it's not obvious why.
Some identified problems:
1. It can lead to duplicated partners: the user does not find
the partner, so he creates a new one.
2. The user imports supplier contacts in the Contacts app, so they
don't get the `supplier` flag. Then the user wants to make a purchase order,
and cannot find the new suppliers in the list
3. A user removes the customer flag on a prospect, because they don't think
it's a customer yet - except now they can't make a quote for that customer...
Specification
=============
Remove the two mentioned fields.
Since fields `customer` and `supplier` have been removed, all partners
are now shown in many2one dropdowns.
But in some cases, not all partners are relevant or some are more likely
to be relevant than others. e.g. when creating a PO, top suppliers have a
higher priority than other partners.
So, adapt the places where those fields were used with the new mechanism to
display the searched the partners, according to the number purchase/sales
orders they made.
TaskID: 2031147
Co-authored-by: Yannick Tivisse <yti@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'`
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closesodoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Julien Alardot (jual)