In the payslip name, the month name was set
within the server locale, rather than the
user language.
Therefore, if you had your server default locale
in English but your user in French, the
month name was displayed in English anyway.
opw-692590
When editing the website, adding a gallery, choosing the grid mode
and then adding images, an extra, empty, image was
added to the grid, in the first position, making it looking weird
or at least not aligned.
This was due to the `start` method of the widget, which
is trying to focus the image in the images browser when
you double click on an image (in the big image building block
for instance) and set an image without url in the case
where `o.url` was undefined, and the url of one of the records
was also undefined.
opw-692205
For example l10n_ch has default included purchase tax on products. This
would impact the valuation of the product and fail the tests.
This commit removes these taxes in the purchase test (they are tested
elsewhere anyway) and also use python to change the company currency
(since the current way didn't seem to work).
opw-691996
It has been done outside of the previous commit
to give the possibility to point the comment
to the according revision, as this is a really tricky
case.
opw-687201
On an invoice, when registering a payment in a foreign currency
for which the payment pays entirely the invoice,
and even more thanks to the change gain(write off),
but for which the foreign currency rate to the company currency is higher than 100,
(higher than the currency decimal precision of 2 digts),
e.g. Invoice in CDF, Payment in USD (1 USD = 948 CDF),
and choosing the option "Mark invoice as fully paid" for the difference handling,
the invoice could not be marked as paid, according to the result
of the currency rate rounding.
This is because the debit or credit of the writeoff was computed
from the payment difference, in the foreign currency,
to the company currency, which lead to two currency rate computation,
one in each way,
company currency to foreign currency,
then foreign currency to company currency,
and some precision was lost in the process.
Instead of computing the debit or credit of the writeoff from
the payment difference, we now compute it from the
payment amount in the company currency minus the
invoice residual amount in the company currency,
to avoid the double currency computation rate,
so the precision is not lost in the process,
and the invoice move is finally fully reconciled
e.g.:
Invoice of 247590.40 FC
Payment of 267 USD (1 USD = 948 FC)
Payment difference: (247590,40 / 948) - 267 = -5.83 (Gain of 5.83 USD)
Before the revision, the credit of the writeoff was computed as:
`((247590,40 FC / 948) - 267 USD) * 948 = 5526,84`
After the revision, the credit of the writeoff is computed:
`247590.40 - (267 * 948) = 5525.6`
Notice in the first formula that the rate computation is performed two
times, once in each way (`/948` then `*948`), while only once
in the second, and this avoid the loss of 1.24 FC in the process.
Without this precise debit/credit of the writeoff, the invoice
could not be marked as fully paid, as the move was not fully
reconciled.
opw-687201
Due to the following revision:
bdf630f9b8
When creating an invoice from a purchase order with an
analytic account set, the analytic account was no longer
copied on the invoice, as the analytic account that was added
thanks to
https://github.com/odoo/odoo/blob/9.0/addons/purchase/invoice.py#L53
was overwritten with `False` as `rec` was False
or if `rec` was True, it was overwritten with the analytic account
of `rec`.
opw-697702
The pos loading crashes in the following scenario.
1. start selling a product (order line the localstorage)
2. archive or delete the product in backend
3. reload the pos session
The POS is interrupted with not much information.
Give an error a bit more meaningful.
When sending an email via the mail.compose wizard, the selected partners are
stored in the context (`active_ids`).
If the composed message is saved (button "save template"), the context is lost
in the _reopen action.
The active_ids content of the new context is the id of the newly created mail
template and is used as the id of a res.partner (sending the email to a
different contact).
Keep the context during the reopen to avoid losing active_ids.
Closes#11947
Version 9.0 comes with a revamped accounting system, and the
cashbox system for cash control on bank statements was changed in the
process.
The POS App was updated to use the new system, but failed to
reuse the existing cashbox control if one already existed.
This worked as expected on bank statements directly, but not
on POS sessions where a new cash control had to be input every time.
This fix requires an update of the views, but works in a
backwards compatible manner. Users who do not sync their view
definitions will still be able to work (but will still experience
the bug).
Rev 87a3fe92de revamped the
rescue session system in an attempt to simplify it, but
created new problems.
The rescue system is designed for accepting POS orders
that belong to a POS session that is already closed.
After 87a3fe92de:
- The system tried to automatically reuse an existing session
that matches the properties of the closed one. This will often
come as a surprise to the POS users, with orders appearing
from nowhere in a live session, possibly invalidating the cash
control steps, etc. Using a separate new session with an obvious
"RESCUE" name is much better for users. They will be able to
review the rescued order separately as well.
- When no open session was available, the system tried to create
a new one (without the rescue flag). This could often fail
because existing sessions could conflict with the new one, completely
breaking the recovery. (E.g. a session from the same POS but
with a different user) The rescue flag was designed to avoid this
pitfall, allowing multiple extra rescue sessions to coexist with
live ones.
This patch restores the use of the RESCUE flag for recovery
sessions, and forces the creation of a new session for every
recovered session. Recovery sessions will also be labelled as
"RESCUE" now, making it things more obvious for end users.
There seems to be no need to reset to the root category
on the product list every time we switch back to
the list from another screen. Unless a full refresh
was requested (e.g after closing an order).
This avoids losing the currently selected category
after each screen switch. It can be quite convenient
to stay in the same category while the cashier is
processing items that need to be weighed, for example.
This commit allows POS screen widgets to distinguish
when the user is expecting a full reset of the
target screen, vs. simply re-displaying it.
When switching back from the scale screen to the
product screen, the order summary was re-drawn
and always scrolled at the top.
This happens because the redraw takes place in the
background while the scale screen is still displayed,
so the new area does not know its size yet and
cannot be scrolled properly.
Swapping these operations around fixes the issue
and it happens fast enough to be invisible to the
user.
The order of variants(product.product) is (re)defined each time the attributes
of a product.template are modified. The order of these variants is computed according
to the order defined on "product.product" which is ordered by 'default_code,name_template'
and also the sequence of the product.attribute.value.
But when a new product.attribute is created, the default sequence is the order of creation of your new values.
So if the sequence of the attributes is changed after modifying the product.template, the new sequence will not
have any impact on the order of the variants. The sequence of the attributes must be defined first
before modifying the attributes on a product.template to have an impact on it.
opw:693135
The feature "set all date to all order line" on a purchase order allow
user to update the schedulded date of all order lines.
It was backported in 9.0 with 401a3cfa but in 9.0 date_planned was not
stored, the button would wrongly set the scheduled dates of the lines to
the minimum date.
With this commit the functionality should work as expected, unless
someone use an out-of-date template in which case the functionnality is
disabled.
opw-697680
note: PO date_planned is stored after 9.0 so this commit must not be
forward-ported.
When renaming a warehouse, the sequence are renamed.
Previous sequences uses slashes while the new one backslashes.
Keep consistency between sequence from origin and new one.
Closes#13774
* ccd6fc6 already fixed the bug of the account move for expenses with more than 1 taxes but the taxes were not used.
Adding in `_prepare_move_line` to be included in the created move line.
* added Contributor License Agreement
Closes#12849
The account move line created for a tax must have the right account_analytic_id
according CONDITION.
CONDITION(inspired from function compute defined on model "account.invoice.tax")
if the tax is for an "in_invoice" or an "out_invoice" => tax_code = 'tax_code_id'
=> the account_analytic_id of the tax must be set to 'account_analytic_collected_id'
if the tax is for an "out_refund" or an "in_refund" => tax_code = 'ref_tax_code_id'
=> the account_analytic_id of the tax must be set to 'account_analytic_paid_id'
note:forward-port upto saas-6
opw:694821
The account move line created for a tax(with analytic = True) must have
the same account_analytic_id than the account move line created for the
taxed amount.
opw:694821
Declaring the keyword argument `context` in an API v7 `orm.browse_record` can
lead to mixed API v7/v8 inheritance bugs (`context` will be treated as a
function parameter instead of being injected in `self.env.context`). As the
context is already propagated in line 953, we can safely remove it from line
971.
Closes#13115
When the user name entered hasn't an email specified the error message wasn't
displayed in the reset view.
The error message was in e.name, not e.message
César Castillo