It is not possible to take money out or put money in for a PoS since it
leads to a traceback.
The decorator `@api.one` returns a list, which is something we don't
want when the method returns a dictionary.
opw-681417
Context:
Source document on invoice created through a credit note with the modify option
Current issue:
create an invoice from a sale order,
validate it,
Create a refund with the modify option
The first invoice is reconciled with the refund
The new draft invoice doesn't have a source document and can't be reached from the SO
Expect result:
The new draft invoice should have the sale order as the source document
Symptoms: running a full reconciliation manually with that wizard was resulting in not fully reconciled aml altough the total in company currency and in secondary currency were perfectly matched. Full use case described in added test test_manual_reconcile_wizard_opw678153.
Problems:
- The system was processing by pair of aml and creating exchange rate entry/full reconciliation as soon as possible whereas in that case it needs to be postponed at the end of the manual reconciliation otherwise some entries would be excluded from processing.
- Another problem was that because of this batch processing, we ended with unconsistent amount_residual_currency values for some entries that were fully reconciled in company currency but not in foreign currency (also negative amount_residual_currency for a debit line which should never happens)... To solve that, we now process the manual full reconciliation in two steps: only in company currency first, then in secondary currency if needed. A small adaptation in the payment widget of invoices was needed for that too.
When several accounts are selected to print their GL, the GL of only one
is printed. This is due to two issues:
- 'active_id' is retrieved instead of 'active_ids'
- the method `get_action` is called with the wrong records. `self`
refers to the wizard, not to the accounts selected.
opw-676061
When a user validates an invoice linked to a SO, he might want to modify
it afterwards thanks to the 'Modify' option in the refund wizard. This
will create a refund, reconcile and create a draft invoice.
The issue is that the draft invoice is not linked with the SO.
The fix is to link, in this specific case only, the draft invoice to the
SO. At the same time, we have to make sure to:
- unlink the first invoice (to prevent counting the quantity as invoiced
in the SO)
- keep track of the first invoice/refund in the invoice list of the SO
opw-673446
When a a refund is created from an open invoice and a different
date than today is selected as refund date, the invoice date of
this refund must be the selected date.
opw:673369
Currently there is a selection field 'account_type' on the
account.analytic.account model with 2 values : Active or Archived
Let's use an active field instead and add a Archive stat button on the
form. That way, we can remove all the domain ('account_type','=','normal')
which are implicit with the generic active field behavior
It is using an already existing field that wasn't used anymore ('account_type') but as a lot of domains on analytic accounts were
- wrong (still using old fields state and type that have been removed as well in the same commit),
- or defined directly in the views
so, an update of some modules may be needed in order to avoid further problems.
The domain for the analytic account in the `reconcile with writeoff` wizard
should be based on the `type` field, which must be `view`,
not on the `parent_id` field, as it's done everywhere else
(e.g. in the supplier invoice form).
`[('parent_id', '!=', False)]`
and
`[('type', '!=', 'view')]`
is almost the same, but the second domain is more appropriate.
Closes#4562
In Accounting > Bank and Cash > Cash Registers, when clicking in "More" button
on 'Put Money In' or 'Take Money out', the date used for the bank statement line
created must be the date of the bank stattement(same behaviour then when clicking
on "Add item" in edit mode). It's forbidden to put/take money in/out for a bank
statement which is not open.
opw:647631
Christophe Simonis