button will only be visible if the move_line are not reconciled yet
This button will allow user to register a payment and then reconcile it with multiple invoices in the payment matching view.
Was PR #15157
Demoted to library in Python 3, see if uses can be replaced by more
specific construct, just import functools.reduce otherwise.
Futurize fixers:
* lib2to3.fixes.fix_reduce
With our new views, we broke almost all JS code, including the
reconciliation widget, which was (and still is) dependant on the field
widget. With this commit, we rewrite and simplify the reconciliation
code. We also add some tests, to help with the maintenance.
Work done by CHM
* `<>` was removed and should be replaced by
`!=` (lib2to3.fixes.fix_ne)
* `\`` was removed and should be replaced by either `repr()` or the
`%r` format string modifier (lib2to3.fixes.fix_repr followed by
hand-rolled edition to replace concatenation)
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
Aged receivable/payable was using create_date of account_partial_reconcile to decide if a partner needs to be shown at a given date or not.
While it was not wrong, our decision to use the create_date was based on the fact that we wanted to be able to render the exact same report we had at a past date, so a the date of the reconciliation would be important... but since the unreconciliation was not forbidden it wasn't really the case.
Moreover, in some case where reconciliation is not at the same time the payment is recorded, this choice
- was confusing people about results given by the aged receivable/payable report.
- was confusing people about the 'Paid on...' line in the payment widget on the invoice, as they would see there a date unused by the system (although they would have liked too)
This was discussed in opw 31844. Was PR #16016
Allow to configure the bank statement import mode from kanban
When doing a manual journal entry, don't show the maturity date
Removing Issued total, using credit instead (less code, more
useful to have due amounts, instead of overdue)
Creating a bank, set a name 'BofA Current' and an
account number (that way, the account.account is based
on name)
Settings Wizard & menus: better sentences
Statement CSV Import: installed by default (it
does not add any menu)
remove use_in_payment: complex field, only
used for a default value
Small code cleanup
[IMP] sale: moving order date to secondary tab (strange on a quotation)
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.
This is needed in order to clear the 'unreconciled payments' in the bank statement reconciliation report when you wrongly encoded a bank statement and reversed it.
This patch goes along with the modification of the bank reconciliation report in enterprise to exclude such 'reconciled' lines.
Since ee2c76a431, a new field 'statement_line_id' has been added on account.move.line object and the field 'statement_id' became a related... but this statement_line_id on the bank account aml was, by mistake, not set. That created aml that were wrongly appearing in blue in the reconciliation widget.
If this error occured in a DB, the following SQL query can fix it:
$ UPDATE account_move_line l SET statement_line_id = s.id FROM account_bank_statement_line s
WHERE l.statement_line_id IS NULL
AND l.statement_id = s.statement_id
AND l.name = s.name
AND coalesce(s.partner_id, 0) = coalesce(l.partner_id, 0);
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().
A warning was raised when an invoice line had a negative amount that may cause some
trouble when dealing with discount (negative amount). Now, the warning is raised
when the amount total of the invoice falls bellow 0.
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.
Having more than one supplier invoice with the same reference is sometimes
possible. For instance, in Switzerland, the use of BVR/ESR numbers as a type of
reference permits this. Generally, this number is unique and used only for one
invoice. However, some suppliers do use the same BVR reference for several
invoices (e.g. recurring invoices).
This commit allows to disable this check if required, which is only possible
if it is extracted from 'invoice_validate'.
Closes#15891
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
Christophe Simonis