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
When a account.bank.statement.line is created by clicking on "Put Money In"
(Accounting(Menu)>Bank and Cash(Menu)>Cash Registers(Menu)>More(Button)>"Put Money In"),
the account.bank.statement linked to this line must be updated(by passing in the write of
this model) to compute the real closing balance. This fix allow to have the same
behaviour than when a line is manually added (with "Add Item) in an account.bank.statement.
opw:647631
Removed a code that allows to write a message, using a subtype that
does not exist. This is probably critical for some business, but
as I don't know which ones, let's remove it.
Chatter is sufficient.
- [REM] account_budget: removal of field 'validating _user_id' on account.crossovered.budget, which is now replaced by inheritance with mail.thread
- [REM] account_budget: removal of field 'code' of account.crossovered.budget, which was not used and redondant with its name
- [REM] account_asset: removal of field 'note' of account.asset.category, which was not used and redondant with its name
- [REM] account: removal of field 'to_check' of account.move, which was redondant with state == 'draft'
- [REM] account_voucher: removal of field 'audit' of account.voucher, which was a fields.related on move_id.to_check
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
qdp-odoo