The `account.voucher` field `date` was twice in the view
`view_purchase_receipt_form`
Besides the fact the field was twice in the view,
this prevented to set a date in the past
for the resulting journal entries,
as the second field `date` input of the view
contained the date of today, while
only the first one was visible and editable
by the user, and it was the second field
value which was took into account when
passing the form values to the server,
most-likely because this second field was set
further in the view.
opw-674712
The method `create_exchange_rate_entry` is called
either if one of the two parameter
`amount_diff` or `diff_in_currency` is not equal to 0.0
(or, near to zero, `float_is_zero`):
```
if currency and aml_to_balance \
and (float_is_zero(total_amount_currency, precision_rounding=currency.rounding) \
or float_compare(total_debit, total_credit, precision_rounding=currency.rounding) == 0):
```
Nevertheless, the method is called with the amounts not rounded,
and, therefore, one could be considered to 0.0 (if
closed to 0.0) but not be exactly equal to 0.00,
and it should therefore be rounded before the entries
creation.
opw-673854
In non grouped mode, a recent fix (fixing race condition in do_search)
introduced a new bug, the dataset size is not correctly set.
This is a quick and dirty fix, I believe that changing the dataset
internals like this commit (and other) do is really not correct.
However, the correct fix (working on the dataset API) is more dangerous
in a stable release.
Rounding the unit price at that moment is a bad idea. Here is the use
case:
- Set the product 'Costing Method' to 'Real Price'
- Set the product 'Inventory Valuation' to 'Perpetual'
- Receive through a PO 9 products for a unit price of 115.80
- Receive through a PO 35 products for a unit price of 116.80
- Sell these 44 products thanks to a SO, generate and validate the
invoice
On the Stock Output Account, the following entries will be generated:
- First PO --> 1042.20 = 9 * 115.80
- Second PO --> 4088.00 = 35 * 116.80
- Invoice --> 5130.22 = 44 * 116.596
116.596 is the average price of the two POs, but rounded. The issue is
that there are 2 cents of difference... Nice ;-)
The fix is to avoid the rounding of the unit price, since we don't even
store it on the account move line anyway.
opw-673976
Following commit 8276fb585, the data exported should match the data
displayed on the list view. Therefore, we need to make sure that the
context used match the context of the list view.
When a filter is applied in the list view, the context is evaluated
thanks to pyeval (see the call to `/web/dataset/search_read`). The fix
is to evaluate the context in a similar way.
opw-674473
- Fix for status widget (b25c054c93) moved
to appropriate file: addons/web/static/src/js/views/form_widgets.js
even though the problem is less severe in 9.0 (no crash but triggers
form save, which is unnecessary)
- Fix for website_event_sale ignored (880e951f34)
because the problem does not exist anymore in 9.0, probably due to
refactoring 66871ee65b
When deleting the analytic account of an account move line(aml),
the analytic lines linked to this aml must be unlinked even if
the aml is not linked to another account analytic.
Used case:
Once a analytic account is removed from a journal line, the analytic line
created for this journal line has to be removed from this analytic account.
Inspired from 8.0
opw:673803
When the warning on form view is closed by cancel or OK button, all is
well. But if the modal is closed by any other way the def will stay pending
blocking next operations.
This commit set the deferred as dejected if not resolved when the modale
is closed.
closes#11688
opw-671371
When processing a payment transaction, double-check the
match between the amount of the transaction and the
amount of the SO, to be sure that we won't be validating
a SO that has been modified since the payment.
Such cases have to be double-checked manually.
Also add a bit of extra logging to make auditing ecommerce
transactions easier.
In addition to being mostly useless because Paypal's API
changes are supposed to be backwards-compatible, this
warning was using inconsistent version numbers.
Switched to a simple INFO line with IPN version.
/!\ This commit must not be forward-ported on saas-10 (the file that
is modified here does not exist anymore anyway).
Since the website/web_editor split, the mt/mb definitions were not
included in reports anymore. Those were not the only rules that
were forgotten.
As it would be tricky to add the whole files where those rules are
defined now in the assets of stables branches, this commit only
restores the missing css rules by adding them in the report.css file.
Note: after the assets refactoring that has been done in saas-10, this
problem will no longer appear.
The introduction of the new pos.config dashboard at
48ab50ed0d does not filter non-active
pos.configs. There are no constraints against opening sessions on
inactive or deprecated pos.configs so after deprecating/inactivating
users could still open new sessions through the dashboard.
opw-673020
When a lead is set to 'Won', the date_closed is defined. However, the
user might have clicked by mistake, and he might want to change the
state back. We need to take this into account, otherwise the lead is
considered as closed although it is not.
opw-674226
The POS generates journal entries for both the amount of money the
customer pays and the amount of money the POS user returns to the
customer (the 'change'). Whether or not this is the correct thing to do
is up for debate, but we can't change that in stable anyway.
One of the main issues is that in 9.0 accounting will propose
unreconciled payments belonging to the customer on open, unpaid
invoices. This does not work well with the account entries generated by
the POS. Accounting will propose the amount the customer paid, without
taking into account the change.
Example: a customer buys $7 worth of products and pays with a $10
bill. The customer gets $3 change. The invoice will propose the $10
payment.
When you add that payment to the invoice a residual amount ($3 in the
example) will remain on the paymentline, complicating everything even
more.
Although we cannot change how the POS does accounting in a stable
release, we at least want people to be able to easily handle invoices
generated through the POS. To achieve that this patch will make the
backend match the payment to the total amount of the invoice removing
any potential change.
opw-671486
From 94ed4ce8c8
The original issue is the following:
- Go to the journal item creation
- Choose a partner
- Add a line => the partner on the journal item is removed
This is because `partner_id` on the account move is a related to
`partner_id` on the account move lines. This is likely to cause errors
during the manual encoding of a journal item, since the relation will
link the partner of the account move to the partner of the first account
move line only.
opw:672354
For some reason this made it into a stable release. Although you can set
a background image on a floor this image never actually got displayed on
the floor in the POS. Only the background_color field is respected.
Something like this is always a bit tricky, because you would either
have to scale the image to fit on the floor (ugly if the user uploads a
low-res image or an image with the wrong aspect ratio), or you would
have to tile the image (also ugly in most cases).
Because of the above and because this has never worked and because I
don't consider it a particularly useful feature we will remove it
completely in master.
opw-674031
Current behavior before PR: if you create a new record within a one2many
field and the model's form has a clickable status bar defined, clicking
this status bar will raise an exception because the virtual id
(one2many_v_XXXX) will be passed to the model's write method
Desired behavior after PR is merged: clicking just changes the cached
value
Related and function manual fields may not be loadable during initial
setup (partial=True) due to dependencies being not loaded. Ignore
theses fields during partial loading.
Users may sometimes need to edit their own partner records directly,
although indirect access by writing on `res.users` directly works
fine in most cases.
The SQL view `crm_partner_report_assign`
makes a join on `account_invoice_report`
A column is added to
`account_invoice_report` in the module
`sale` (`section_id` is added to the view),
making the SQL view `account_invoice_report`
replaced automatically at the install/update
of the `sale` module, which leads
to the automatic deletion of the SQL
view `crm_partner_report_assign`,
because the SQL view `account_invoice_report` is
altered.
Therefore, after the install/update of the `sale`
module, the view `crm_partner_report_assign` was
deleted, and the "partnership anaylsis" unusable.
This revision makes sure to init the
`crm.partner.report.assign` report after
every init of the `account.invoice.report`.
opw-674177
For some reason, it was lost. Probably in the graph view/pivot view split.
This commit simply accepts the attribute, but default to true, so nothing
changes unless you have explicitely set it to false.
Also, fixes en error introduced by a forward port (the use of
openerp.web.format_value)
Denis Ledoux