"Depreciation Account" must be renamed in "Depreciation Expense Account"
Reason: This is the account that will be shown in the Profit and Loss, the original
label "Depreciation Account" is confusing because it could mean a depreciation asset
account.
"Asset Account" must be renamed in "Depreciation Asset Account"
Reason: This makes it clear that this is an asset account that will receive
depreciation entries, without this wording it could mean that we are simply
informing the Asset module which account is the asset account, but that depreciation
entries go elsewhere.
opw:672852
When dealing with issues related to 'rescue' sessions we are very
limited in what we can do because the actual orders sent to the backend
exist only in localStorage in the browser on the device of the
user. Because of this it is important that we log some data about the
orders we receive in the backend to have an idea of what's going on.
opw-676497
When several accounts are selected to print their GL, the GL of only one
is printed. This is due to two issues:
- 'active_id' is retrieved instead of 'active_ids'
- the method `get_action` is called with the wrong records. `self`
refers to the wizard, not to the accounts selected.
opw-676061
When "Filter by Periods" is choosen in the wizard, the right periods
must be set in ctx to filter the account moves according to the right periods
opw:674593
Backport of 8423a0df34
Clear the cache/environment in addition to rolling back
the cursor, in order to retry the transaction with fresh
data, not partially stale data.
If a user syncs his calendar with Google,
and a second user is created in the database by copying this first
user, the Google information of the first user was copied
(The Google account to sync, the token to use, the last
syncrhonization date, ...), which is obviously wrong.
On calendar syncrhonization, which can be done
manually or automatically with the according cron, all
events of the first user were created a second time,
as a second user synchronized the same Google Calendar.
opw-674141
A non-breaking space is used between the amount and the currency.
However, if a space is used as a separator, there is a possibility that
the amount will be split into several lines.
opw-674535
When a payment is registered on an invoice, the payment difference must
be considered differently if we receive the payment or pay a bill. This
is necessary at the creation of the 'Counterpart' entry. For example,
an invoice of 100 is considered as paid with a payment of 90. The
difference of 10 should be booked as a debit in case of a customer
invoice, but it should be booked as a credit in case of a vendor bill.
opw-675641
In event not during all day, it looks like
`start_date` could be defined, but `stop_date` not.
Despite the fact this is not such a normal state, this should
not prevent the save of the event with the
`_check_closing_date` constraint, checking that the ending
date is after the starting date
(in the case of an event not during the whole day,
this is ensured with the `start_datetime` and the
`stop_datetime`
opw-676245
On smaller screens some buttons will be hidden. An example of this is
the 'Validate' button in the stock.picking form view. It is not :visible
but it should still be possible to trigger through scanning a
'O-BTN.validate' barcode.
opw-676741
The comments field was ignored (because reasons) when exporting terms in CSV.
This was an issue when using the wizard 'Synchronize Terms' as it first export
the terms of every module in CSV.
opw-673853
- As of 9.0 there is a discrepancy between the smart button showing
the "total timesheet" entries at the top of a Sales Order, and the
actual timesheet lines used to computed the "delivered quantity"
of the lines of that SO.
Fix this by simply counting all the timesheet lines assigned to
the SO lines.
- Also replace the sum of "timesheets" mixing different UoMs with a
simple count of the lines, on the smart button.
It's not going to match the sum of the "delivered qty" on the
lines anyway (due to diff. UoMs), so let's show something that makes
sense all the time.
- Finally, use a more logical plural form in the smart button label
When the user searches for date (or a datetime) in the search bar, the
suggested date can become completely wrong. For example, in the French
localization where the date format is DD/MM/YYYY, the system will search
for the date MM/DD/YYYY. This is even worse when the date is not fully
written: DD/MM could be converted to MM/DD/0000, which doesn't make any
sense. This is related to the moment issue
https://github.com/moment/moment/issues/1407.
The fix is to make sure that the input date has a correct format thanks
to `parse_value`. The latter converts the date into a fixed format.
Fixes#11876
opw-676604
When creating an customer invoice with a product linked to a deferred revenue
category, the account used in the invoice line must be the account_asset_id.
When creating an vendor bill with a product linked to an asset
category, the account used in the invoice line must be the account_depreciation_id.
Inspired from 0287c1e1b3
opw:677098
When creating an invoice from a SO or PO with a line containing a product with a
deferred revenue type or an asset type, this information is not copied in the
related invoice line.
Inspired from 564fda4
opw:677098
Thomas Groutars