In 9.0 the argument pay_journal in function pay_and_reconcile must be an id
but in 10.0, pay_journal must be a recordset with one element. So it was
not possible to call this method by rpc in 10.0
opw:725737
When a partner has a lot of contacts, the computation of the issue total
takes a lot of time. Indeed, it performs the computation for the
partner, but also for all the children, despite the fact that the amount
is not displayed.
opw-726355
Currently the amounts of all invoices (linked to sale or purchase
journals) is summed regardless of these invoices being bills or
refunds, this means e.g. if you create an invoice for 1000 then a
refund for 500 on this invoice, the dashboard will display an
"awaiting payment" total of 1500 which while technically correct is
not really logical or helpful from a user's POV.
Fix summation to take in account the invoice type (invoice or refund)
and remove refund amount from the total amount.
Intent validated by @lap-odoo, also not ignoring or removing refunds
from count to avoid situations like "0 Awaiting Payments [for] $-1200"
which would be really strange.
OPW-728860
SQL that retrieves data for the "Due Payments" report doesn't include
any filter for excluding AR/AP move lines already reconciled, which
shouldn't be presented in this report.
Courtesy of Pedro Baeza. Was PR #16440
Different method use self._context.get('lang', 'en_US') to get the lang
value but, the lang in the context can be set to None (eg: copy method).
When the context is used with a lang=None, the method can have a
unexpected behavior or crashed (eg: if you try to format a datetime with a
locale=None)
When reconciliating manually, it may be possible to filter between
`All`, `Customers`, `Suppliers`, `Others`.
When changing this mode, we could end up in a situation such as:
1)
- reconciliation widget X is available
- reconciliation widget line XB is being loaded
- mode is changed -> reconciliation widget X is removed
- reconciliation widget line XB loading finishes
-> error because the parent reconciliation widget exists no more.
2)
having no (or less than the expected) or too few results because
removing reconciliation items (when for example we switch from supplier
to customer mode) can be done asynchronically. But the code expected it
to be done synchronically. Also all elements displayed were removed
instead of only the ones of other types.
thus instead of displaying the expected number of reconciliation items:
MIN({num of record to display}, 10)
the records displayed were:
MIN({num of record to display}, 10 - {num records displayed before})
which could amount to 0 event if there was thousands available ones.
This commit solves these two issues:
1) by not adding line to a reconciliation item without error,
2) by counting and removing displayed items correctly
opw-725796
opw-728309
Step to reproduce the bug:
1.Create a product with a customer tax(15%) for a price=100
2.Create a customer invoice with this product
3.Change the amount of the tax to 10(instead of 15)
4.Validate the invoice
5.Click on "Refund invoice"
6.Select the refund method "Modify: create refund, reconcile
and create a new draft invoice"
Bug the new draft invoice has 15 as amount of tax
Now all the taxes from the invoice when preparing the refund in function
_prepare_refund, in this it keeps all the modified taxes.
opw:726491
To deduct the fiscal position, we should use the shipping partner.
The field `partner_shipping_id` is defined in the sale module.
Thus, we should choose this partner if the module sale is installed and if this field is set, or fallback to the original partner instead
Tribute to Ray Carnes
PURPOSE
=======
Since the fields shipping_partner_id has been added on the invoice model, the onchange triggered by the partner_id hasn't been modified.
SPECIFICATION
=============
The shipping_partner_id will be picked by default to select the fiscal position. If there's no shipping partner, it will check if a 'shipping' partner is a child on the partner_id.
Both tree and form view have the same sequence, which haas, at best no effect,
at worst, shows the form before the tree view.
In the second case, making that clicking on the bank journal name drives you to
a new bank statement instead of the list of existing ones.
Closes#16187
With multiple companies defined, ensure consistency in demo data in case a localization reusing the ones defined in account module is installed. Before that, the demo data used several hardcoded values to reference the company, but some models relied on the default company, which lead to crash when the active company was not the one hardcoded in demo data and such a new localization got installed.
This revert commits 51882ea70c and d94c449547 that were introduced to solve OPW-693955.
The usability before those fixes was good, but the bug was appearing when we first create the journal without the boolean 'dedicated refund sequence' set, then we try to modify that va$
This time, the fix consist to create automatically the sequence on the write of the boolean if it's not existing yet, in the same fashion than on the create().
With multiple companies defined, ensure consistency in demo data in case a localization reusing the ones defined in account module is installed. Before that, the demo data used several hardcoded values to reference the company, but some models relied on the default company, which lead to crash when the active company was not the one hardcoded in demo data and such a new localization got installed.
OPW: 716163
This is needed to fix the following problem: adding a partner to res_partner.child_ids will mark all element of child_ids as 'todo'
and trigger a write on res_parner.commercial_partner_id for all element of the child_ids and then on the related field
account_invoice.commercial_partner_id. This can cause problem if partner in child_ids belong to different company and have invoices. This will throw a
read access error when doing the _write method of account_invoice. Adding the compute_related=True to account_invoice.commercial_partner_id
ensure that the _write on that field is done in sudo.
Steps to reproduce:
-Create a new journal called VISA of type=bank
-Allow the reconciliation on debit and credit account
-Create two expenses (700$ each one)paid by company with the VISA journal
-Submit to manager, validate and post the entries
-Create a bank statement of -1400$ on Bank journal
-Click on reconcile button
Bug: the two account move lines linked to the expenses are not available
to be reconciled with the statement.
In 9.0, it was possible but due to this commit: 9188d01934
the two aml were not available because
this two aml had a payment_id, no statement_id and were with an account_id different of the bank journal
(not in reconciliation_aml_accounts) because they had been paid with VISA journal. So they were rejected
with the domain_reconciliation due to the account_id on VISA journal and they were rejected with the
domain_matching due to the payment_id not False and statement_id False.
In 9.0, they were accepted with the domain_matching so the same behavior has been done in saas-11.
opw:709861
Odoo Translation Bot