Steps to reproduce:
-Set your company in USD
-Create a SaleOrder with a pricelist in EUR
-Create an expense in USD, with the analytic account of the SO
-Confirm the expense and post journal entries.
Bug:
The unit price of the new SO line was wrong: it was stil in USD as in
the expense.
Expected behavior:
The price unit must be converted in EUR
opw:682378
When the lead step is activated (`group_use_lead` is true), 2 dinstinct
tree views can be selected to display the opportunities.
Indeed, when the action "Your Pipeline" is selected, the tree view
`crm_case_tree_view_oppor` is displayed thanks to the method
`action_your_pipeline`. However, when the page is reloaded or the tree
view is saved in the custom dashboard, the tree view
`crm_case_tree_view_leads` is selected instead.
The fix is to specify explicitly in the action which view should be
chosen, accordingly to what is done in method `action_your_pipeline`.
opw-681488
opw-681734
In v8, we had a BoM price report in xsl format which was removed in v9.
As it is still needed, we added a report in the new qweb format, but this
time it is on the BoM instead of the product variant.
It also makes sense to have a similar report for v10 as the cost structure report
on the mo is for the real cost and not the standard cost.
Removed assertion statement that was making a useless browse on account.move. This single patch is enough to divide by 4 the time of preprocessing a bank statement when opening its reconciliation widget.
That removed assertion is now a supposed prerequisite when calling the function and should be tested first (on batch of records).
When using the abbreviated month in the language
date format (`%b`),
e.g. `%d %b %Y`
in some languages, the parsing of the date
from this format to the database format (YYYY-mm-dd)
failed because of a dot `.` added from time to time
to the end of the abbreviated name
e.g., in French, `5 juil. 2016`
This is a bug of `moment.js` < 2.13.0,
handling badly this dot.
This is solved from `moment.js` 2.13.0,
thanks to the below revision
moment/moment@41fdb58572moment/moment#3078
Unfortunately, we cannot update this library to its latest
release in stable release of Odoo (e.g. 9.0),
as this is seen as an unstable change
(if some API changes occured in the given library)
Instead, if the parsing of the date fails with the
strict mode (meaning the date must respect the format
exactly), we perform a second pass without the strict mode,
so this dot will be ignored,
and the date can be correctly parsed.
The issue can be reproduced by loading the French language,
and setting `%d %b %Y` as date format, and then performing
an advanced search on a date field. The value of the date
in the advanced search will be empty without this revision
(for the months having more than 4 chars,
other than `mars`, `mai`, `juin`, `aout`).
Fixes#11854
opw-682534
It is possible (in very rare cases) on rereservation that the new reservation will trigger other stock moves
than the first reservation. In order to be sure to send the correct stock moves involved to done, it is better
to do the rereservation before the splitting of the moves on the total picking.
Also rereserve is optimized as it should only reserve for what is given by the pack operations,
as the backorder will be reserved later on anyways.
If you are in a view whose action defines a default team (for
example in a pipeline view), the default should take the context
into account instead of simply forcing the team of the current
user.
opw-682577
Tax Paid(Hacienda Pública. IVA soportado) and Tax Received(Hacienda Pública, deudora por IVA)
must be respectively under Current Asset and Current Liabilities in BS report.
opw:681998,681252
The compute method of the `counterpart` field only keeps a maximum of 2
account codes. However, it attempts to do [0:2] on a set, which is not
syntactically correct in Python.
opw-682373
The "else" has to be removed because if a tax group named "X" is
the group of tax "A" and "B", the journal item corresponding to the invoice line
has the taxes "A", "B", and "X" set.
Introduced by 5a5ac1d7a5
in details:
[FIX] added analytic account in grouping key of because we need to create different journal items for each of the lines having a different analytic account.
[REF] added a function on account.tax that returns the grouping key and that could be inherited in another (community) module
When an account move line(aml) is created for an include base amount tax,
all the other taxes are impacted with this tax then the field tax_ids of
the created aml must contain the other taxes.
Example:
Considering an invoice line with:
-A price=90
-A fixed include base amount tax=10(incl_tax)
-A 21% tax(called tax)
The base amount for the 21% tax is equal to:
100 = 90 + 10(incl_tax)
When the invoice is validated, three amls are created:
One for the product with:
-Debit=90
-Credit=0
-Tax_ids=(incl_tax, tax)
-Tax_line_id=()
One for the incl_tax with:
-Debit=10
-Credit=0
-Tax_ids=(tax)
-Tax_line_id=(incl_tax)
One for the tax with:
-Debit=21
-Credit=0
-Tax_ids=()
-Tax_line_id=(tax)
In this way, the base amount of 21% in the "Declaration periodique TVA"
report is the sum of all the amls balance(credit-debit) linked to tax with
the field Tax_ids.
opw:681102
In the below revision:
c0db6aec56
The dialog close `reason` was introduced
to not reload the current form if the dialog
has been closed for a reason
(e.g. a window action was returned by the server).
This is to prevent the record reload, which:
- Is useless, as another action has been launched
and the user therefore redirected elsewhere
- Can fail, in the case the initial action deleted
the current record
(e.g. when merging a lead in an opportunity, the
lead is removed, and therefore this is not possible to reload
it).
opw-680180
When a product is received in the lot reception view, a new lot is
created. If the user receives at least one lot, closes the lot selection
window, then reopens the window, he will not be able to create a lot
anymore, but only choose existing lot.
The fix is to make sure that the lot selection is available only in the
case of a returned product.
opw-681925
Before this commit, the return of a delivered product with a lot number
is problematic because the user cannot select the lot from the list of
delivered lot numbers. Therefore, the user needs to create a new lot
number for the returned product since the combination product/lot must
be unique.
opw-681925
The FEC control check does not like rows
with debit = credit = 0
```
º Structure fichier incorrecte, débit/crédit ...
renseignés sur une même ligne ... , ou débit=crédit=0
```
opw-682365
Using a frozendict as context breaks the `t-lang` mechanism, as
the `loader` is not aware of the changes of a copied frozendict
and thus is still using the values from the original context,
including the lang one.
This reverts commit e1deae7eab.
When a kit is sold, the unit price of the COGS recorded is the sum of
the unit prices of each component multiplies by the quantity sold.
Obviously, this is not correct since the unit price should not take into
account the quantity sold.
opw-681403
The previous wording was inaccurate and made users think it
was impossible to setup "Net EOM" payment terms.
Updated POT file accordingly, but not PO files because this
requires a proper new translation.
The field bom_count appeared twice in product.template form view and
then the smart button for "Bill of Materials" always displayed 0 as
number of BoMs.
opw:681830
To be displayed correctly on odoo app (In a given category and not only in all or hidden)
the module category in the __openerp__.py file should be one of these:
"Accounting",
"Discuss",
"Document Management",
"eCommerce",
"Human Resources",
"Industries",
"Localization",
"Manufacturing",
"Marketing",
"Point of Sale",
"Productivity",
"Project",
"Purchases",
"Sales",
"Warehouse",
"Website",
"Extra Tools",
'Accounting & Finance' will not work, as 'Project Management', ...
On the website,
when registering for an event with ticket,
the placeholder `Attendee #` could not be translated,
as `t-att` attributes are not translated.
An alternative is to put the string to translate
in a `t-set` node, which can be translated, and
to use the variable assigned in this `t-set`
in the `t-att` attribute.
opw-678758
It might happen that a transaction produces more than one message in the
chatter. In this case, the messages are created with the exact same
date, and they might appear in the wrong order in the chatter.
We therefore sort the messages by id, and not by date. Note that the
messages are already sorted when received from the server, but the web
client has its own management of the messages' order. Relying on the
server order might imply to change other parts of the code on client
side, which is something we want to avoid on a stable version.
opw-681049
Commit d349584 solved the state change tracking of pickings, and
moreover prevents unnecessary state changes to be recorded. However,
this also prevents the state "Done" to be recorded in the chatter.
Saving properly the state change for the picking might be quite tricky,
since the stock processes sometimes imply unreservation/rereservation of
quants, and therefore lead to several state changes inside the same
process.
opw-680343
fields ref, journal_id and date on account.move.line are all related fields on
the account.move.
Setting a value here is then useless and triggers write on the account.move
after the creation of the account.move.line (inverse values in write)
Function fields, old-api style, that are not stored do not have cache
invalidation mechanisms. This means that they are recomputed every time the
field is accessed.
Due to the way the cache behaves, the records that are present in the cache will
be included when the prefetching is done.
In the scenario of the a POS session being closed, this implies that the cache
will contains more and more account.move.line records and try to prefetch all
(hopefully max 1000) without ever relying on the computed result for the next
access. This makes the computation of fields `amount_total` and `price_subtotal`
very slow, even for orders with a very low number of lines.
Backport the new API migration of these computed field to benefit from depends
mechanism and keep the computed value into cache when needed.
In master these fields should be stored.
On the other routes (e.g. /my/, /my/contract/) payment information on the parent
contact are displayed but can not be access in the my payment route.
You get in a unconsistant situation where you can access the contract of the
company and its payment information but can not use this payment information.
opw-681491, opw-681502
An access error occurs when a the delivery address of a SO is set to a
different partner than the SO partner. In this case, the picking
created is associated to the partner of the delivery address. This is an
issue when the SO partner tries to view the picking from the front-end
("My Account"), since he is not allowed to access it.
opw-681341
The computation of the total_invoiced field did not work in batch mode.
When displaying a company in a form view (field invoice_total comptued), the
children of this company are present in the cache and the value of the field
invoice_total will be prefetched for these children as well (at least in 9.0).
Most of the time this is redudant information and the same value is computed
for each child while most of the invoices are on the parent.
Batching the computation per partner allows to make one global query for all
partners.
Add test to make sure the total increase correctly after a test invoice
confirmation.
When browsing a form with a one2many / many2many field
with several pages, the one2many pager page was not reset
when going to the previous/next record, while the next/previous
record could not have multiple pages on its one2many/many2many,
and the page on which the user was on the former record could
not exist in the newly displayed record.
Besides, even if the page does exist, there is no reason
to display this new record X2many value from its first page.
It's the case anyway when you edit/save, it comes back to the first page.
opw-679092
Goffin Simon