- Activate Invoice Online Payments
- Create an invoice for 2000, make a partial payment of 500.
- Send the portal link to the client
- Open the portal link => the amount due is 1500
- Pay the invoice
The amount to pay is 2000 instead of 1500.
opw-1909118
closesodoo/odoo#29284
This commit aims to improve the user experience when using payment acquirers. There currently are no error feedback with some acquirers, which leaves the user wondering what is going on and what is the real status of its payment.
In some cases, the user is currently being redirected to the home page even though the payment has failed. We want to make it more obvious to the user that something unexpected has happened by redirecting to an intermediate page that will provide good feedback on payments status.
Another goal of this commit is to order acquirers by sequence instead of by flow and to select the first acquirer by default. This feature was already implmented in commit fe294fd43e521bd2d339e962f43acf46c3d4cb97, some UI adaptations were needed though.
Related to task #36680Closes#26958
It was very confusing for the user to distinct account.payment and payment.transaction. From now on, the transactions are
technical objects and, in the backend, we only refer to it in log messages (Front end will be adapted in the same fashion
later on). They are hidden in debug mode in accounting\configuration\payments as their purpose is now purely technical/log
This commit also aims to reduce the gap between the accounting app and the transactions: account.payment objects are
created/validated upon completion of transaction.
To ease the capture/voiding of pending transactions, the related buttons are now displayed directly on the SO/invoice
instead of the transactions.
Was task: https://www.odoo.com/web#id=35857&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
Was PR #24043
[FIX] add domain based on journal to payment tokens
Was opw: https://www.odoo.com/web?debug#id=1828206&view_type=form&model=project.task&menu_id=5200
Until now invoice_id is filled on the transaction only when we make
payments through invoice. However if we make payments through sale order
then invoice_id is not filled.
This commit fixes that issue. As there is no common point between
sale_payment and account_payment except payment, a void method is added
in payment and an override done in account_payment. That was when both
modules are installed code is correctly triggered.
This commit is related to task ID 1813602. Closes#22746 .
This commit adds support of payment in the account customer portal. This
is done in the account_payment module. This way customers can now pay
invoices directly on the customer portal and have access to the status
of their invoices. It replaces the old website payment mechanism that
was only allowing to pay without generating payments and reconciliating
them.
Two routes are defined in this commit, one for form-based payments and
one for server2server-based payment. Please refer to commit 1fdb10f0ac
for more details about the new payment form.
Tools methods are added to handle transaction / invoice matching, the
check of invoice and the automatic payment and reconciliation.
Purpose of this commit is to add a link between invoices and transactions
to store payment data like what is already done for sale orders.
* add payment_tx_id on account.invoice model that stores the last
transaction; also add the acquirer related on the tx;
* add a stat button on invoice with links to all transactions linked
to that invoice;
* add account_invoice_id on payment.transaction model that stores the
link to the invoice;
* add the inverse one2many from invoice to all its transactions so
that we can browse them if necessary;
Nicolas Martinelli