To have the right sign, amount = debit - credit
Before the fix:
-Create an invoice in another currency than the currency of your company
-Link the invoice lines to an analytic account.
-Validate the invoice.
Bug:
The analytic lines have a negative amount in the amount currency field
which was a bit stange as it is the opposite sign than the amount in the company currency.
opw:692557
When an asset is set as Prorata Temporis, with a one month period, the
first depreciation amount is computed on the basis of the remaining days
in the purchase year. This doesn't make sense for a monthly
depreciation.
This commit makes the distinction between a monthly and a yearly
depreciation. In the case of a monthly depreciation, the remaining days
in the purchase month are taken into account.
opw-690034
Backport of 0a3899b72c
The fiscal year start date should be taken into account when calculating
the depreciation amount in case of prorata temporis.
opw-678072
Backport of e69d9b8b7d
Steps to reproduce:
- Create a Sales Order with 2 product qty
- Keep Delivery Method as DHL International
- Confirm
- Open Delivery Order
- Edit Qty of the Delivery Order
- Change Carrier (any integrated)
- Validate the transfer
- Process the backorder
- Edit and change the Carrier to normal or free delivery charges
- Validate
Bug:
The price of the free delivery charges was not recomputed and kept
the carrier price set on the SO.
Fix:
When the price of the carrier is "fixed" or "base_on_rule", the price must
be reconsidered in case of change.
opw:691224
Since 1ba91042d monetary fields values could be represented by a
float_precision which is aimed as an improvment for digit precision when
saving a monetary field value to the database.
xmlrpclib (we are using to serialze the response) is handling some
common datatypes, but for custom one we would need to register it with
how it needs to be serialized.
This commit add a convert_to_read method to the Monetary field so when
reading monetary fields value we get the float numbers and not the
float_precision ones.
The float_precision is needed when saving, so it is alright to have float
when reading.
fixes#13857closes#14125
opw-692373
It can happen that the account moves generated during reconciliation
from a bank statement with several lines have the same number.
This is a complement of commit 9365482df0. The order of statement lines
is not derterministic since it is based on `statement_id desc,
sequence`. Therefore, at each call of `process_reconciliation`, the
array `self.statement_id.line_ids.ids` can be different.
opw-690853
Since this commit d025251c7e, a lead
does not use stage anymore. A lead is either alive or archived.
Then the field stage_id is useless in the crm_case_tree_view_leads view
opw:691838
The function open_entries doesn't have to propagate the context
because it propagated group_by from other models.
Example:
- Click on Accounting > Adviser > Assets
- Click on Group by > Category
- Click on an asset
- Click Entries
The group by "category_id" was propagated on the model "account.move"
and it led to a traceback.
opw:692888
The company currency is USD, the invoice currency is EUR.
- Create an invoice in EUR, set an invoice date
- Compute the taxes (click on "update" button)
- Change the exchange rate between EUR and USD
- Validate the invoice
At validation, the tax lines are not recomputed. Therefore, the tax
amounts, are still converted in the company currency using the old
rates. On the other hands, the other account move lines will have the
appropriate new rate.
Closes#14024
opw-692430
The company currency is USD, the invoice currency is EUR.
- Create an invoice in EUR, set an invoice date
- Compute the taxes (click on "update" button)
- Change the exchange rate between EUR and USD
- Validate the invoice
At validation, the tax amounts are not recomputed. Therefore, they are
still converted in the company currency using the old rate.
Closes#14024
opw-692430
The widget html is used for plain text and html content.
Need to check if the content is a valid html code, if is not wrap with p tag every lines.
opw-692158
When confirming a SO as the admin, for example through the website_quote
module, browse the product with the correct company to get the right
project (this is a company_dependent field).
In a multi-currency environment, company currency is USD
- Create an invoice of 100 EUR, corresponding to 65 USD
- Register a payment directly from the invoice (button "Register
Payment") of 60 USD. Choose "Mark invoice as fully paid".
- The write-off line contains the amount in the invoice currency (field
`amount_currency` filled in.
This was introduced in commit 003f2ee9b.
On the other hand:
- Create an invoice of 100 EUR, corresponding to 65 USD
- Create a bank statement of 60 USD.
- Proceed to reconciliation, and create a write-off line of 5 USD.
- In this case, the write-off line does not contain the amount in the
invoice currency.
The user expects the same behavior in both cases, so we introduce the
amount currency in the second case.
opw-690784
Certain localities (eg. Colombia, but South America in general) legally
require somewhat complex behavior when validating a POS order.
It was difficult to implement this behavior in the POS. The
validate_order function did way too much and was way too large. If a
user wanted to add an additional check that an order has to pass before
allowing validation the user would probably have to copy all the
validate_order code.
To solve these issues we split the functionality of validate_order into
two functions:
order_is_valid: returns true or false depending on the validity of the
order
finalize_validation: finalizes the order by sending it to the backend
etc.
Fixes#13142Closes#13994
When we put a pack in a pack and try to validate the picking, we get
an error saying we are trying to create a pack operation without a
location id.
This is caused by the 'quant.package' location computation, when we
validate a picking, odoo will create the pack operations in the next
picking if there are any. And when it tries to create a pack operation
of a pack in pack, it cannot get the location id of the top level
package quant because in the compution of the location_id, it only looks
at quants having a package_id correspeding to the package. And there are
not any when the it's a package of package.
To solve this issue, we fixed the function '_compute_children_quant_ids'
that doesn't work either because of the same reasons. And then we use it
in function '_compute_package_info' to get the quants if there are any.
This bug has been introduced in rev: https://github.com/odoo/odoo/commit/fe9b31c0e703cf4f3f4f4001ab199f7a4353f9b9
Up to this commit, the JS module system only notified failed modules as
an 'information' instead of an 'error'. This was annoying, since the
runbot takes the result into account, and might be green even though a
module failed to load.
In v9, when in the context of the many2one field in the XML of the view
you did not put default_ before the field (context={'product_id': product_id}
instead of context={'default_product_id': product_id}, this would work.
The problem is that in saas-11, this is not the case anymore and so,
when you created new lots upon receipt (or another operation), the product_id was not set,
so you needed to set it for each lot you create and can even put a different product than foreseen.
So, we changed those for the packages and the lots.
opw-692679
* Tip are never destroyed when change view mode
* unbind methods
* mail: memory leak with unbind methods
* web: memory leak because 'ui-autocomplete' is never destroyed
* web_editor: memory leak for wrong unbind on destroy
* web: memory leak: must remove fileupload handler
* bus: memory leak: correctly debind handlers on window in bus.Bus
* remove handlers on switch buttons and views $buttons
* remove handlers on breadcrumbs
* web: memory leak: correctly debind handlers
* im_odoo_support: memory leak: remove fileupload handler odoo_support
Note: part of this commit was actually authored by aab
Before, the quantities on the pack operations were set also for the
pack operations that should have lots and had not, which is an inconsistency.
As at the end of the PoS, errors are not shown and not rollbacked, this
created really nasty situations. With this code, it was never meant to
use lots in the PoS, but as the picking was not validated (but existed, because
not rollbacked) some people thought it as a wanted feature.
In the mean time, we had commit fafc048d02, but it will give
problems as it will not automatically create a backorder. It is
better not to do anything when lots are involved somewhere in the picking
as then the user will see the open pickings in the PoS Orders picking type.
It is also important to not do anything when it is a move without a picking.
Needs to be forward ported to saas-11, where the file structure changed.
opw: 692045
The tax has to be only on the second line because otherwise the accounting entry is not correct. Note that I'm not sure it is a usefull use case, but at least the accounting entry of the w/o is now logical and corresponds to what you expect (and what you see on screen). OPW 689806
Previous commit b6cbc36f9 hides volume, weight and standard price in the
product view if a product has variants. The use case was the following:
- Create a product (template)
- Give a value to these fields
- Add attributes to the product (this creates variants)
The values were reset to zero. This is a normal behavior since the
relevant values are now on the product (product).
This reverts commit b6cbc36f9a.
opw-692833
The POS attempts to auto-validate pickings and so it sets qty_done of
the pack operations to equal product_qty. In the case of a pack
operation about a tracked product this doesn't make much sense, as in
that case auto-validation will fail and serial/lot numbers have to be
manually specified by the user. Without this patch you end up with pack
operations that look like they're done, but still need to have
serial/lot numbers set.
opw-690516
! This is a backport from 10.0 (9010ed0a) !
opw-693017
Original commit message:
A side effect of commit b9d1239eff if that the method `sale_get_order`,
which is used to retrieve the SO, will also update information on this
SO (change partner, change pricelist...). We therefore need another way
to retrieve the SO.
opw-692919
! This is a backport from 10.0 (815f085) !
opw-693017
Original commit message:
When a user tries to pay a website quote thanks to Stripe, the button
spins and nothing happens.
In the case of a quote, the jQuery selector is not correct.
opw-692341
! This is a back-port from 10.0 (fb010a1) !
opw-693017
Original commit message:
When a user uses Strip and clicks on "Pay & Confirm", a "Bad Request"
error can pop-up. This is because it tries to reload the page, while it
should only display the Strip pop-up.
This is simply due to a `preventDefault` done after the event is
performed, and not before.
opw-692341
This effectively reverts the patch 7bdd4de that was made on 8.0 then reverted by 001610e (in 8.0 too) but each of them manually forward ported to 9.0, except that the forward port of the last one forgot to remove the faulty commit.
If a snippet contains a .oe_structure element inside of it, it allows
the user to drop other snippets in that location. The web_editor
contains code which removes all empty parent of an element being
deleted. This is done so that, for example, when the last col of a
3-col snippet is removed, the whole snippet is removed.
However, there was an exception to this rule which was not considered,
if one of these empty parent is an .oe_structure, it should not be
removed.
Note: the only snippet which does this is the parallax snippet.
Steps to reproduce:
- Create one (or several) expense lines
- Submit them to the manager (create the expense sheet)
- Approve the sheet and post the entries
- Delete the created and posted sheet
Bug:
- The expense is deleted but the accounting entries are still in the database
- The expense lines are in "To submit" and you can submit to manager again and
generate a new report and therefore new accounting entries...
Fix:
It is not allowed to delete posted expense.
opw:692323
The favorites menu is always added in search views. Then the
menu "add to dashboard" is always added even if it is triggered from
a form view in a modal. In this case, the action_id is not available
in the object FavoriteMenu.
If the action_id is not available, the menu "add to dashboard" is
hidden.
opw:692023
When an asset is set as Prorata Temporis, with a one month period, the
first depreciation amount is computed on the basis of the remaining days
in the purchase year. This doesn't make sense for a monthly
depreciation.
This commit makes the distinction between a monthly and a yearly
depreciation. In the case of a monthly depreciation, the remaining days
in the purchase month are taken into account.
opw-690034
When an asset is set as Prorata Temporis, with a one month period, the
first depreciation amount is computed on the basis of the remaining days
in the purchase year. This doesn't make sense for a monthly
depreciation.
This commit makes the distinction between a monthly and a yearly
depreciation. In the case of a monthly depreciation, the remaining days
in the purchase month are taken into account.
opw-690034
The javascript tour (test) will verify the total amount based on sale
price of the product without taking taxes into account.
However, if any l10n_* module is installed and defined a default value
for product taxes, the test will fail this check.
As of f814dd9908, debug
mode causes an extra X-Debug-Mode header to be sent
by the rpc() JS method.
This custom header was not whitelisted in the accepted
CORS headers, therefore any cross-origin call to a route with
`cors=True` would fail in debug mode, with a console error
along those lines:
"Request header field X-Debug-Mode is not allowed by
Access-Control-Allow-Headers in preflight response"
This would prevent loading the POS GUI in debug mode,
for example.
This commit is necessary in the 8.0 branch because
the POSBox is currently based on a 8.0 server and may
be accessed by a 9.0 POS or later, thus with the extra header.
Martin Geubelle