Before this commit, when trying to access website_public_price from the backend (when adding this field to a view for example), a traceback saying that the website attribute on the request object was non existent was raised.
After this commit, we control for this and the field displays correctly
OPW 778586
closes#20536
In some cases, vendor reference for payment may already exists.
For instance in Belgium, some suppliers provide recurring invoices which
contain the same communication for the payment. From the version 9.0,
the field Vendor refrence is used for payment communication and the
maching on bank statement.
So, in this case, we have to put the communication from the payment in
this field and, as explained just above, maybe the same as on another
invoice.
Therefore, this commit provides a hook to modify/disable this behavior.
Closes#20343
opw-777608
The access to the state of sale.order.line (related field) seems very slow for big sale order. Bypassing the related field and using the real field instead, improves performance.
Before this commit, you was able to double click on the button when
are in registration flow. In this case, you subscribe 2 times and so
take 2x more seats, what can be annoying when you have a limited room.
In the same time, we fix the form in the form that generate
strange behaviour like some events not bubbled correctly.
The attendee form (into the modal) was inside the registration form.
$'attendee_form).on('submit') obviously failed due to this bad dom.
This commit closes opw-778191
Since Odoo 8.0,
the default stock input account for product categories
in the Canadian localization is set to
`214100 CANADA REVENUE AGENCY`
This is the case since this commit:
https://github.com/odoo/odoo/commit/13dacd11c10dac853def763432829b8976604a7d#diff-2e65e26a4efc4ab95e72dbe2033141ecL294
In which the account with the XML ID 2141_en
214100 Stock Received But Not Billed
has been renamed
214100 CANADA REVENUE AGENCY
In this very same commit, the account "Stock Received But Not Billed" has been moved to the account 217100,
under the XML ID chart2171_en:
https://github.com/odoo/odoo/commit/13dacd11c10dac853def763432829b8976604a7d#diff-2e65e26a4efc4ab95e72dbe2033141ecR447
While the default value for the products categories stock input account remained the same, the account with as code 2141:
https://github.com/odoo/odoo/blob/8.0/addons/l10n_ca/account_chart_template_en.xml#L8
This is an oversight. It was not meant that way. The default stock input account for products
should well be "Stock Received But Not Billed".
In addition, a stock account is supposed to be of type assets, and not of type liabilities.
I contacted @max3903, who was a contributor of the l10n_ca localization,
and who is therefore a better expert than me regarding the Canadian localization.
He confirmed me all the above findings.
opw-775413
When having a product with included taxes that are changed/removed with
a fiscal position, the price changes depending on if the pricelist's
discount_policy is with_discount or without_discount.
This commit aligns the without_discount behavior to the with_discount
behavior.
Note: the behaviour isn't 100% correct. The applied discount will be
computed on the list_price, instead of the tax excluded
list_price. If a price_surcharge is set, it will be wrong.
Supplements https://github.com/odoo/odoo/commit/0d56dca
When basing a pricelist on another pricelist in different currency
conversion was not being made correctly, since commit https://github.com/odoo/odoo/commit/6b3a808
that changes the pricelist_item on which the currency_id is set in
_get_real_price_currency.
Also align the _get_display_price's base_price to the
_onchange_discount's new_list_price in the case where the pricelist
depends on other pricelists that are in without_discount mode as well.
On rereservation of an mo, it will remove the existing stock.move.lots
if no quantity was done on them. We wanted to avoid however that it
would remove the temporary stock.move.lots on the workorder. On the normal
ones however, there is also a workorder_id. That way it would
not unlink stock.move.lots when you had workorders. By checking the temporary or
not flag (done_wo) instead of workorder_id, we solve the issue.
Courtesy of blaggacao fixes#19422
Fixes 27280fefa9:
* `partner_id` is an `int` not a recordset
* qweb Response is lazy (the template is only looked up and rendered
when we actually need to send the content over the wire) => the error
would occur outside of the try..except block. Force rendering
(`Response.flatten`) so we can handle the issue here
* Uses the HttpCase interface to contact the server over a new socket
(same as tours & al) because using `werkzeug.test.Client` would not
use the correct cursor (?) and so the test data would not be visible
Create an accout.voucher with "Pay Directly" as payment.
You get something like:
D | C
--------------------
Expenses: x |
Cash: | x
However, the expense line doesn't appear in the reconciliation widget
because the payment_id is missing in the account.move.line and then, doesn't match
the search domain for the reconciliation.
To solve it, a payment_id is created for this line in case of "Pay Directly" payment.
-opw: 775167
Between v9.0 and v10.0 a pricelist refactoring made it so negative
discounts no longer worked correctly. They should always be
included in the unit price of the product (not to be displayed as a
negative discount even if the option to display the discount is
enabled).
This commit also corrects currency conversion issues when basing the
price on another pricelist with a differnt currency, and when making
the sales order in a company with a different currency than the
pricelists currency.
Use case to reproduce
- Set a product to be expensed
- set the expense_policy to something else than no
- Do a delivery order with a picking
- Validate the picking
-> Delivered quantity to 0 and impossible to create an invoice
if the invoice_policy is delivered_quantity
It happens due to this commit 48ea59d46e
What does it do:
- The move could be generated by an expense.
- If the move has 'no' as expense policy thus we won't add it in the invoice
Problem we can't guess if the move come from an expense or not (limitation).
This commit increments the delivered quanity if the product can
not be expense anymore
opw-777139
Before this commit, creating a base_action_rule with model X from module
A and then uninstalling module A would make the database crash because
the algorithm would look for an uninstalled model during the Registry
reinitialization.
i.e. Install project and base_action_rule, create a base_action_rule
depending on model project.task, try to uninstall Project -> BOOM!
This is fixed by checking if the model obtained is None, in which case
we log a warning (for cleanup) and skip to the next iteration (continue)
opw-777301
When following these steps on Firefox:
- Select all text in a bold link (triple click)
- Type some text
The typed text did not replace the selected text but was instead put
at the front of it.
5afb5ecd04 rewrote the tax computation
in both account and point_of_sale to fix complex tax computations but
it no longer allowed negative prices in the point of sale.
opw-778013
Set the round_globally method on the company.
Have an invoice with several lines and some of them having two (or more) taxes.
See the OPW 775501 for exact numbers.
It is a practical example case where
round(0.003 + 0.004) = 0.007 ~ 0.01
BUT
round(0.003) + round(0.004) ~ 0.00 + 0.00 = 0.00
Before this commit there could be a difference between amount_residual and amount_total on invoices.
This was because the two amounts are based on something different:
AMOUNT RESIDUAL
It computed in function of account_move_lines of the invoice.
For such an invoice the structure of those lines would be 1 line per tax + 1 line in the receivable account
Here the amount tax of each line is rounded before the addition.
In summary, the total amount of each tax are rounded and then added to each other
AMOUNT TOTAL
It is computed in function of the on-the-fly computation of the taxes with two cases:
- round per line: obviously each invoice_line gets its taxes rounded before addition, which isn't problematic as regards to the previous paragraph
- round globally: Here lied the problem. the rounding of the tax_line_ids was made **after** each tax amount was added to each other, which contradicts the above argument
After this commit, we round tax_line_ids before their addition, it is rather logical and matches the expectation one can have reading the tooltip of the rounding method field
>> If you select 'Round per Line' : for each tax, the tax amount will first be computed and rounded for each PO/SO/invoice line and then these rounded amounts will be summed, leading to the total amount for that tax.
If you select 'Round Globally': for *****each tax*****, the tax amount will be computed for each PO/SO/invoice line, then these amounts will be summed and eventually ***this total tax amount*** will be rounded <<
OPW 775501
After this commit, it is expected that the behavior of sale.order and purchase.order won't be the same as the invoice in the same conditions.
See PR #20349 for an explanation
Here is what could (sometimes) happen in community:
- the point of sale tour is started by the runbot
- it loads the '/web' url
- this instantiate the mail client action (init)
- the tour sees that the POS link is in the dom and clicks on it
- the action manager destroys the discuss client action (before its
start method is called)
- the destroy method from the client action is called, this.$buttons
is not set, the destroy method causes a traceback
You start with an MO with a quantity of 2 with routing and we
produce just 1. At least one of the components is tracked by lots.
When we update the MO to a quantity of 1 again, the temporary
stock.move.lots continued to exist which led to processing a the consume
d move of e.g. 1 piece with 2 pieces of the quants processed when
posting inventory.
A test is added in order to avoid this case
opw-767526 and opw-772786
We try to avoid to take the inactive move lots. While they are normally
already filtered through the split, we had a case when you update the
quantity of the mo, that the split would not separate them.
Before this commit, a portal user would land on /web after login in with oauth.
He would then just see the "Website" app.
He should then click on it to land on website instead of landing directly on it
after login in, which is not convenient, especially since theses users doesn't
know Odoo (in case of sale customers manually created for instance).
Now, if users has no 'base.group_user' right, it will be redirected to the
website directly instead of /web.
- Create a tax included of 21 %
- Create a product sold 7.00, set the 21 % tax
- Add the product in a SO
Amount w/o tax: 5.79
Amount tax: 1.22
Total: 7.01
We defer the base rounding to the end of the method so that the rounding
doesn't impact the tax computation of included taxes.
Complement of 6e46ba7b46
opw-777221
- Create a product attribute, e.g. 'Recommanded Age'
- Create several values for this attribute
- Try to associate more than attribute value to the same variant =>
contraint which prevents to do it
We should allow this use case as long as the product attribute doesn't
create a variant.
opw-776344
- Activate multi-company, create companies A and B
- Set 2 companies on a user
When a message is sent (for example, thanks to the chatter), the
notification email always contains the logo of the same company,
whatever the company of the user or the company of the object.
This is a complement of commit 7a03f9ce93, applied to notifications.
Closes#20088
opw-772405
Lucas Perais (lpe)