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
When an applicant is moved from a stage to another, an email is sent to the
applicant(s) if an email template is specified on the stage.
The active_ids is correctly set in the compose context to be used by the
send_mail method to send a message to all the applicants in the new stage.
However, a potential active_id may be propagated from a previous action.
This is the case when a user goes from a Job Position record to the list of
applications and change the stage using the kanban view (active_id & active_ids
is the id of the hr.job).
The default_get method of mail.compose.message will use the active_id as the
default value for the field res_id which is wrong as it is the id of another
record).
Forcing the value at False instead of ids[0] as it would not work in batch mode.
The list of records is correctly used in send_mail anyway.
Closes#12494
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
With the pricelist, it is possible to define a pricelist just for
a variant. But in the product.product.form, only the pricelist items
linked to the product template could be displayed.
The field item_ids has been created in product.product model to display
all the pricelist applied on a product.
opw:674700
Let's take the following case:
- Enable lot tracking on a product
- Costing Method is "Real Price", Inventory Valuation is "Perpetual"
- Create a picking with 2 stock moves, each stock move is linked to the
same product
When the picking is validated, 4 account moves are created instead of 2.
This occurs because the list of stock moves and the list of reserved
quants is sent to the method `_move_quants_by_lot`, but there is no
check to which stock move is related a given quant.
For most cases, the issue doesn't show up since there isn't usually 2
stock moves with the same product in a given picking. There is at least
one use case where this happens: selling a pack of two identical
products. In this specific case, 2 stock moves of the same product are
created, but one pack operation will merge the 2 stock moves.
opw-680308
_('foo '+bar) does not work as `bar` is a variable with undefinied content
during translation export (and variable content during evaluation) so a match
will not be found.
Also trailing spaces are stripped during synchronisation with transifex.
The proper syntax would be
_.str.sprintf(_t("foo %s"), bar)
but to avoid breaking existing translations (need to reexport .pot)
use the syntax
_("foo ") + " " + bar
that is more stable friendly.
The 'No value found for the field...' string is not possible to be fixed without
breaking the translations should be split at least twice.
Write it the propre way directly.
These accounts are created automatically on the journals creation
e.g. On the creation of a Bank Journal, a Bank account is automatically
created, linked to this journal.
Before this revision, when installing the generic chart of account
(or l10n_us), you had two Bank accounts (101400, 101401),
and two Cash accounts (101500, 101501),
by default,
which is not right.
opw-676950
Damien Bouvy