Previous patch by Alexis created a co-dependency between
account_payment_order and account_banking_sepa_direct_debit, which is
not correct.
This patch avoids such problem and fix properly the test, although
the utility of some of them is debatible.
The previous approach creates manually the journal entries and does all
the hard work, plus not being 100% compatible with the bank statement
reconciliation widget (requiring a patch on OCB to see blue lines).
That decision made sense on the moment it was done (v9), where the
native payment model (account.payment) was very limited, and wasn't able
to store all the needed information for the bank transaction.
Now that the limitations are gone, we can get rid off this extra model,
and generate instead `account.payment` records, using both the native
model + methods to perform the same operations.
This serves also to workaround the problem found in #966.
All the code, views and tests of main module have been adapted to this
new approach in this commit. Later commits will adapt the rest of the
modules of the suite, and add migration scripts to transit from the
previous approach to this new one.
TT39832
- Add a hook method to retrieve communication type and communication
- Improve normal communication if there is a credit note
If there is a credit note that partially cancel an invoice, the payment communication
should be the combination of the invoice reference and the credit note one.
- Remove not needed assert as parameter is required
- Use the 'payment_reference' field if filled in
- Add existing payment references to communication
If some movements have been reconciled with the original invoice,
their references should be added in communication too.
e.g.: Manual credit notes
- Don't duplicate communication reference
The test introduced in 7bdb286aa1 is not
valid, as its indentation made it to not be executed. Anyways, the
content and the tested things are also not correct.
This commit split the tests for outbound payment in a base inheritable class that
can be reused in other dependant modules, and the test of this module.
similar to 86bd1a2525
Add partner_bank_id column to avoid MemoryError on an existing Odoo
instance with lots of data.
partner_bank_id on account.move.line requires payment_order_ok to be True
which it won't be as it's newly introduced - again nothing to compute.
(see AccountMoveLine._compute_partner_bank_id() in models/account_move_line.py)
create_account_payment_line() is supposed to returned a form view for a
single payment order and a tree view for multiple payment orders. Before
this fix, it would return a tree view if you were payment more than 1
invoices while generating a single payment order, because the list
result_payorder_ids would contain several time the same ID.
Some tests need to be run on post-install
The bank_journal.inbound_payment_order_only field is true only if all inbound_payment_method_ids are payment_order_only True. For this we must include the "SEPA Direct Debit for customers" in test
When the test hour is around midnight, and demo data using CET/CEST
timezones, current code fails due to some asserts not having this into
consideration. This fix avoids such problem, and irons the execution
no matter the hour.
- Improve computation of sepa on account.payment.order: check IBAN is in SEPA zone
Update move line generation to get transfer account from bank journal
Update payment mode configuration accordingly (3 fields removed)
Several improvements in payment order tree and form view
- Remove done state (migration script provided)
- Don't set reference_type field on account.move required=True, because it
causes a lot of problems in other modules that don't depend on this one.
Setting it as required in the view is enough.
- add optional="hide" on payment mode in invoice tree view
- FIX crash when communication=null on payment line
- payment_mode_id readonly when state != draft
- Change security group category
Before this change, the group was creating a new section in each user's settings called "Other" with a field called "Other Extra Rights" that could select "Accounting / Payments" as an option
This places it in the correct location
TT29182
- Make post move field invisible in payment modes
When the generate_moves option is not selected, the post_move option should not be available
TT29182
- fix account move views
Current spec was causing weird display in account move view, both for customer invoices and vendor bills
Changing the placement and adding back the label fixes the issue
TT29027
- fix set partner_bank_id in account move lines
Case: The bank account isn't set properly in the payment order lines, because the bank account is only got from account.move.line or the first bank account in the partner_id, but never from the invoice (account.move).
Solution: With this fix, the bank account will be get from account.move when matching the criteria.
- fix payment orders from invoice tree view
Case: User can't add invoices to payment/debit orders from the tree view but it's still possible to add them one by one from the form view.
Solution: Remove binding_views="form": by default are "tree & form". With this fix, users can add payment/debit orders from the invoice tree view
- fix the attachment file name & dowload.
Case: After the configuration of a debit order and generating the .xml file, user can't download it from the next step screen using the download link.
Solution: This fix makes the .xml file downloadable from the .xml file name as it was in older versions
When you haven't still generated the file, `generated_user_id` is not filled, and
so, you can't control the language in which the payment order is going to be printed.
Adding a condition for using the user language in that case makes this more
comfortable.
