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
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.
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.
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
Previous tests did several risk operations on tests, like performing an unbound search
on payment orders, what can lead to errors if there are some data on DB (or for example
we add in the future some payment orders in demo.
This commit also split the tests for inbound payment in a base inheritable class that
can be reused in other dependant modules, and the test of this module.
Finally, we use SavepointCase for improving performance in tests.
context of payment orders, she should ocus on the amount that
is due to be paid. In this method we are forcing to display both
the amount due in company and in the invoice currency.
We then hide the fields debit and credit, because they add no value.