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>
When loading a module, the code in the tests directories should not be
loaded.
One does not need freezegun on a server without running the tests.
closesodoo/odoo#113536
X-original-commit: 705c5d5dd9b76850638bd5d36b8395314ba78248
Related: odoo/enterprise#37481
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Harmonize currency conversion of unit prices:
* Make sure no rounding is applied during the conversion
(it'll be managed by the price_unit decimal precision
and the currency rounding will only be applied by the
monetary fields later in the computations).
* consistent parameters for the conversion (date,
company, currency).
* code simplification
* consistent behavior when the SO has no currency specified
...
Part-of: odoo/odoo#110833
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>
Purpose: When re-invoicing the expense on the SO, the cost (purchase_price)
is not correctly set. For expenses with zero product it is set to zero,
and for the expenses with price on it, it is set to unit_price of the product.
As a result, the margin is calculated incorrectly on SO.
It should be set to the untaxed_amount of the expense in case of zero
product, or untaxed_amount of the product in case of a product with
price defined on it.
task - 2867723
closesodoo/odoo#96981
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Martin Trigaux