The group_lines method didn't make the sum of the quantity field, hence resulting in incorrect results when making product based statistics from the account.move.line records.
Courtesy of Luc De Meyer. Was PR #10551
The test `test_balanced_exchanges_gain_loss`
failed on Jun 6, because it created a specific rate
for today's date at midnight
(e.g. on Jun 6, 201x-06-06 00:00:00) for the test purpose,
but a rate is created in the demo data for Jun 6 midnight exactly:
`base.rateUSDbis`, making the test confused about which rate
to use.
We solve this by making the test use the rate `base.rateUSDbis`,
modifying the rate for its own need, instead of creating a new
rate.
By default, when reading a m2m field, entries that are
deactivated in the destination table are not included.
This behavior is desirable in some cases (e.g. for
"tags" or "categories", but not for entries that
significantly impact other field values in the parent
record, such as taxes.
The problem is rather obvious: when displaying a
paid invoice that used taxes that are now deactivated,
the taxes are hidden while they still affect the
computed amount. And after cancelling + resetting
to draft, the tax is not taken into account anymore,
while still being linked.
Forcing the field-level (python) domain to include
both active and inactive entries solves the problem:
- when reading, displaying and recomputing values,
deactivated taxes will be included.
- when trying to pick a tax, deactivated entries
will still be ignored, as expected.
This commit applies the technique to all m2m
fields that refer to taxes.
Fixes#12066
opw-677751
'foo %s bar' % 'alice' if False else 'bob' returns 'bob', not 'foo bob bar'
The previous strings returns '>=' when the direction is future while it should
be 'COALESCE(l.date_maturity,l.date) >= %s'
Fixes#10654Closes#10695
Used case:
-Create several customer invoices and validate them
-Register a payment without any partner_id and in a bank statement for an amount
a bit lower than the total of the invoice (the difference is the paypal fees)
-Reconcile the invoices with the payment and create a write-off for the paypal fees
-When you close the bank statement, check the journal items, the paypal fees are
automatically assigned with a partner.
Fix:
-When creating the account move line for the fee, if all the account move lines
linked to the move are for different partners then you cannot determine the partner
of the fee.
opw:674822
- Only invalidate cache for fields and records we modify
- Rewrite query to be more efficient
- Avoid o2m commands to be more efficient; write directly on reverse m2o
When "Filter by Periods" is choosen in the wizard, the right periods
must be set in ctx to filter the account moves according to the right periods
opw:674593
The user performing reconciliations may not always
have the right to update the corresponding partners,
for example if a partner is also a system user.
Doing it as super-user after verifying that the
user is indeed allowed to reconcile journal items
works around the problem.
Fixes#11931
Commits 7b7f3fa and d6c88b8 filter out special periods from the account
balances. However, this filtering is not necessary anymore for a closed
fiscal year. The result is that the opening balance becomes wrong as
soon as the previous fiscal year is closed.
This commit fix this by computing the balance over all fiscal years.
Closes#11515
This revision is related to 99d8cd6
Avoid to check the journal centralization
mutliple times, for each move lines.
Checking the journal centralization
for each journal for each period just
before the call to `super` is enough.
Before this revision,
if a large number of move lines
was passed in the `ids` parameter
of the `write` method, with all
the same journal / period, this
could lead to huge performances issues,
the `_check_moves` being called
a large number of times for the same
journal and period couple, uselessly.
opw-672797
When adding new lines to an existing statement,
the order of the lines was not kept,
due to the re-sequencing operation done in the
override of `write` in `account.bank.statement`:
```
for statement in self.browse(cr, uid, ids, context):
for idx, line in enumerate(statement.line_ids):
account_bank_statement_line_obj.write(cr, uid, [line.id], {'sequence': idx + 1}, context=context)
```
as the lines order was based on `statement_id desc, sequence`,
which is the same for all lines added,
(except if the order is forced in the web client,
using the handle widget)
and, therefore, the order
of the lines returned by `statement.line_ids` was
not determinist.
Adding the `id` to the lines order
(as it's done in `sale.order`, for instance),
solves the issue, as the lines will then be fetched
in the order they were created.
opw-667541
Commit 7b7f3fa filters out the special periods. However, the filtering
should be done only for the display in the form view, nto for the
reporting which is actually correct.
opw-672531
When using sequences per fiscal year,
the sequence used to build the bank
statement name must be the according fiscal
year sequence.
opw-671937
Closes#11185
When computing the balance, debit and/or credit, the opening period must
be filtered out. Otherwise, the invoices which are still opened at the
time of the period closing will be counted twice.
opw-670584
when using a journal with 'Group Invoice Lines'
and issuing an invoice with foreign currency with more than 1 line
(of the same product, or no product),
the amount currency in the journal item
associated to the merged invoice lines was wrong.
It took into account the `amount_currency` of the first line only,
ignoring the `amount_currency` of the remaining merged lines.
opw-670972
Closes#10375
Properties depends on with which companies the records
are browsed.
When retrieving the fiscal position as sudo,
the company must therefore be enforced within the context,
to make sure to get the properties from the right
company.
This method can totally be accessed as sudo,
within the crons for instance.
Before this revision, the recurring invoices cron
could retrieve properties from the wrong company,
and therefore retrieve the fiscal position of another
company.
Closes#11039
Specifically, when one API implementation calls the other one, it has to call
the method *from the same class*. Otherwise, overriding the method may result
in an infinite recursion. Consider:
class A(Model):
_name = 'stuff'
@api.v8
def foo(self):
return 42
@api.v7
def foo(self, cr, uid, context=None):
return self.browse(cr, uid, [], context).foo()
class B(Model):
_inherit = 'stuff'
def foo(self, cr, uid, context=None):
return super(B, self).foo(cr, uid, context=context) + 1
and now call: `env['stuff'].foo()`. This invokes `B.foo` (new-API), which
calls `B.foo` (old-API), which calls `A.foo` (old-API), which calls `B.foo`
(new-API) instead of `A.foo`!
This issue would not be present if old-API `A.foo` was defined as:
@api.v7
def foo(self, cr, uid, context=None):
return A.foo(self.browse(cr, uid, [], context))
Odoo Translation Bot
qdp-odoo
luc-demeyer
Denis Ledoux
Olivier Dony
Kinner Vachhani
Goffin Simon
Nicolas Seinlet
Adrien Peiffer (ACSONE)
Manuel Vázquez Acosta
Nicolas Martinelli
eLBati
Stéphane Bidoul
Raphael Collet