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>
Before this commit, the domain applied to the field
employee_id on hr_expense was wrong, so a simple officer (no other rights)
could not see the relevant people
After this commit, the domain is correct and matches the one on the
officer group's record rule
OPW 2058512
closesodoo/odoo#36292
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This commit provides hard constraints (SQL level) for expense to work in multi company
environement. This is related to a R&D task, the rest of the code need to be adapt, but
freeze is coming.
As expense implies accounting entries, it is required to generate them in the right
company, the company field should then be required.
Task-1999686
closesodoo/odoo#35953
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
For better user experience, there should be a 'UPLOAD' button on'hr.expense'
through which user can directly upload a single or multiple documents and
according to the number of documents, blank expense record with attached
document should be generated. These records should be in 'draft' state.
TaskID: 2040887
closesodoo/odoo#35400
Signed-off-by: Yannick Tivisse (yti) <yti@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>
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
The states for the expense are:
- draft
- reported
- approved
- done
- refused
So in the definition of the `payment_mode` field, these states must be used.
Before this fix, wrong states were used in the definition of the field
`payment_mode`.
opw:2038715
closesodoo/odoo#35051
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this commit: 15fa0c23d9
It was possible to encode negative amount for an hr.expense.
Before the fix, it raised a Error saying:
"Cannot create unbalanced journal entry."
opw:2036620
closesodoo/odoo#34953
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
This commit merges the following models
* account.invoice and account.move
* account.invoice.line and account.move.line
* account.voucher and account.move
* account.voucher.line and account.move.line
It was the opportunity for a big cleanup of the code, so it also restructures the whole account module, its different models/fields, the tests etc. for a better world and a better code readability.
==== Rationale ====
The rationale of this huge change is that we want journal entries / invoices to be easily edited, and changes reflected in the other model. It's a HUGE feature and very strategic for the fiduciary companies. For example, changing the account of a journal entry needs to be automatically reflected on the related invoice.
The same reasoning applies to sale/purchase vouchers.
==== Changes made in features =====
When creating an invoice, you are now creating a journal entry directly.
--> The object account.invoice no longer exists.
In the same fashion when creating an invoice line, you're now adding journal items directly in the journal entry representing the invoice. If this invoice line has some tax, it may create additional journal items as well.
--> The models account.invoice.line & account.invoice.tax no longer exist
Identically, when creating a sale/purchase receipt with its lines, you are now creating a journal entry directly and there's no more usability difference between encoding a receipt or an invoice.
--> The object account.voucher no longer exists.
--> The object account.voucher.line no longer exists.
--> The whole account_voucher module no longer exists.
Positive side-effects coming from these changes are
* draft invoices/bills/sale or purchase receipts now create a draft accounting entry. Validate these objects now simply post its journal entry. That means that draft invoices/bills/sale or purchase receipt can straightforwardly be included in reporting or budgets.
* opening a journal entry in form view will now always open the correct view: if it's a sale/purchase journal entry we will have a customer invoice/vendor bill view or a sale/purchase receipt view, whatever the menu we're coming from.
* code & business logic simplification. It is also condensed in a single place instead of being partially duplicated on invoices, vouchers and journal entries.
There should be no feature loss, except the one allowing to group multiple journal items together based on the same product during the invoice validation.
==== Changes made in models =====
* account.invoice: model removed. Instead, now use account.move with following mapping
field (account.invoice) field (account.move)
----------------------- --------------------
name invoice_payment_ref
number name
reference ref
comment narration
user_id invoice_user_id
amount_ total_company_signed amount_total_signed
residual amount_residual
state state + invoice_payment_state /!\ selection changed
date_invoice invoice_date
date_due invoice_date_due
sent invoice_sent
origin invoice_origin
payment_term_id invoice_payment_term_id
partner_bank_id invoice_partner_bank_id
incoterm_id invoice_incoterm_id
vendor_bill_id invoice_vendor_bill_id
source_email invoice_source_email
vendor_display_name invoice_vendor_display_name
invoice_icon invoice_vendor_icon
cash_rounding_id invoice_cash_rounding_id
sequence_number_next invoice_sequence_number_next
sequence_number_next_prefix invoice_sequence_number_next_prefix
'invoices' subset of account.move can be accessed by using the selection field 'type' or one of the many helpers like is_invoice()
* account.move: now has a valid state 'cancel' that has to be excluded from all business logic
* account.move: field 'amount' renamed into 'amount_total'
* account.move: field 'reverse_entry_id' renamed into 'reversed_entry_id'
* account.move.line: now has a field 'display_type' that has to be excluded from all business logic, in order to support invoice layouting
* account.invoice.line: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.line) field (account.move.line)
---------------------------- -------------------------
invoice_id move_id
uom_id product_uom_id
invoice_line_tax_ids tax_ids
account_analytic_id analytic_account_id
'invoice lines' subset of all account.move.line from a journal entry can be accessed by using the boolean field 'exclude_from_invoice_tab'
* account.invoice.tax: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.tax) field (account.move.line)
--------------------------- -------------------------
invoice_id move_id
account_analytic_id analytic_account_id
amount price_unit
base tax_base_amount
'tax lines' subset of all account.move.line from a journal entry can be accessed by using the relational field 'tax_line_id'
* account.invoice.confirm: model removed. Instead, now use the 'post()' function of account.move
* account.invoice.refund: model removed. Instead, now use account.move.reversal to reverse the entries with the same options as we had for invoices
* account.voucher: model removed. Instead, now use account.move of type in ['out_receipt', 'in_receipt]
* account.voucher.line: model removed. Instead, now use account.move.line
==== Changes made in functions ====
* on account.move, method _run_post_draft_to_post() renamed into _autopost_draft_entries()
* on account.move, method action_account_invoice_payment() renamed into action_invoice_register_payment()
* on account.move, method action_invoice_reconcile_to_check() renamed into action_open_matching_suspense_moves()
* on account.move, method _get_domain_edition_mode_available() renamed into _get_domain_matching_supsense_moves()
* on account.move, method _get_intrastat_country_id() renamed into _get_invoice_intrastat_country_id()
* on account.move.line, method _get_domain_for_edition_mode() renamed into _get_suspense_moves_domain()
* in account.bank.statement, contextual key 'edition_mode' renamed into 'suspense_moves_mode'
Was task 1917430
Select 2 hr.expense then go to action > submit report
Before this commit, the company currency amount of the first expense line of the report
was equal to zero, always
This is because, when evaluating onchanges, a tree is constructed in the order of the model._fields
which is an orderedDict, filled up when the class is the read
So in python and in the Odoo ORM, the order of field declaration does matter
i.e. a @api.depend fields must come *after* the fields it depends on
After this commit, everything computes as expected
OPW 2008868
closesodoo/odoo#34110
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Purpose is to make field use more obvious by correctly stating in the
name it should contain an xml id to a qweb layout used for email
notifications. This renaming is propagated through various calls and
addons.
Related to task 1943901
Linked to PR #32404
- Activate multi-company
- Create a company B
- Switch to company B
- Create an allocation request
An access error is raised.
Commit 7f775f0677 added a `sudo` call in order to prevent an access
error. However, it implies that the fallback value `self.env.user`
refers to the SUPERUSER, not the current user anymore. If the current
user is not in the same company than the SUPERUSER, the multi-company
record rules will be triggered.
The fallback is changed to an empty recordset, and selecting the current
user is done out of the method called with `sudo`.
opw-2003137
closesodoo/odoo#33804
Signed-off-by: Nicolas Martinelli (nim) <nim@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.
In case a User is defined as Expense Responsible for another
user, and if he has Officer Expenses Rights, he cannot validate
an expense while it should be the case.
opw-2043985
closesodoo/odoo#35711
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
There was no way to inherit properly action_move_create method.
opw:1974069
closesodoo/odoo#33488
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
* account, hr_contract, hr_expense, point_of_sale, sale_margin,
website_sale_delivery, website_sale_wishlist
digits only works on Float fields, on Monetary fields it has no
effect:
- The column_type of a monetary field is always numeric
- It is not applied in `convert_to_column()` or `convert_to_cache()`
- It is not part of `description_attrs`, so it will not be included in
the output of `fields_get()`
closesodoo/odoo#35336
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Enforce the domain of the UOM not by an onchange but by a domain.
Example of an issue if the domain is enforced by an onchange:
- create a order
- add an order line
- select the product
- select an uom
> the uom presented are the one from the product category.
-Save
- edit
- select an uom
> all UOM are presented even the ones of other categories
This commit enforce this new logic at most places.
task - 2003959
closesodoo/odoo#33741
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
1/ web: adapt formatDate to handle NaN values
DashboardRenderer might return NaN for `Date` or `DateTime` fields if
their original value is null or incorrect.
2/ hr: add job_title in demo data
3/ hr_recruitment: link employee in the chatter for new recruits
4/ hr: remove employee documents in the model
5/ hr_attendance: improve resiliency of relative_time
6/ hr: display manager on res_users
7/ hr: change Address Book to Employee Directory
TaskID: 2009111
closesodoo/odoo#34180
Signed-off-by: Yannick Tivisse (yti) <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'`
Since previous commit moved decimal_precision module's feature into base,
use the new syntax for fields declaration
Remove the imports to the removed module
Remove the module from dependency in manifest
sed -i "s|digits=dp.get_precision('\([A-Z a-z]*\)')|digits='\1'|" **.py
sed -i "/from odoo.tools import decimal_precision as dp/d" **py
oe_view_nocontent_smiling_face does not exists in css
when using this classname, the smiling face does not appear
closesodoo/odoo#33519
Signed-off-by: Christophe Simonis <chs@odoo.com>
Consider the following use case:
- Two taxes:
-A: price included, affect base of subsequent taxes, 10%
-B: 15%, regular
- Create an invoice with a line applying A, then B, for 110€. Post it
- The following move lines are generated:
- base: 100€
- tax A: 10€
- tax B: 16.5€
Before this fix, line "tax A" only had the tax tags of tax A. It should also receive the base tags from tax B, in order to affect its grid total correctly in the tax report.
Also, tax_base_amount field used to be computed, but its computation was too simple, and most of the time wrong when doing advanced use of taxes like the one we defined above. It is now not computed anymore, and directly takes its value from the compute_all's result.
closesodoo/odoo#33420
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- Add repartition lines on taxes
- Link account tags directly to account.move.line; remove the tag_ids field from account.tag
- Add a new report engine dedicated to tax reports, directly generating account tags. It is called as an alternate mode of generic tax report, with a dedicated "Use tax grids" toggle.
>> The biggest change lies in the way the new tax report computes its values.
Everything is now aggregated directly using the tags set on the account move lines. Thanks to that,
modifying the configuration of a tax today will not impact the report for the previous periods anymore.
This is a big improvement, as it means the report will keep on reflecting the values that were submitted
to the state before, whatever the configuration change.
- Add an audit char field to account.move.line telling with tax grids are impacted by the line, with the corresponding amount
- Modify the behavior of cash basis taxes: the cash basis account is now used as the transition account, while the regular account given in tax declaration is used to store the final entry (it was the opposite before)
- Modify every l10n_* module in order to keep them consistent with these changes
closesodoo/odoo#32833
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Christophe Simonis