- payment.acquirer have many fields with 'required_if_provider'
attribute and while saving form it gave an error like "Required
fields not filled", so it was confusing to know which required fields were empty.
- after this commit, it is displayed like "Required fields not filled (field name)"
opw:1881054
- We extract some code logic to methods to allow to override them.
This is needed for the subscription module where a payment token need
to be copied from a transaction to a subscription.
The subscriptions is created from a sale order and before the
payment.transaction holding the payment.token id is validated.
Since the payment.transaction is not validated, the subscription
module doesn't find the correct transaction.
By extracting this code logic, we can override exactly when it should
be.
- The method to compute the reference of a payment.transaction and avoid
duplicate was missing some edge cases (for example if there was a '-'
in the reference).
- The creation of transactions in the route /website_payment/pay was not
checking for duplicate payment.transaction.
Like invoices, a reference is now computed on sales orders.
The configuration of such reference is done through the Wire Transfer acquirer.
The usability of the communication feature (on invoices/SO) has been a bit improved to be more clear.
Was task: 1870121
Was PR #26152
Add an onboarding panel for invoicing, it appears above the invoice
list.
After going through the steps the system should be all set to send real invoices.
In the payment module, add a payment acquirer step and add it to the invoice onboarding panel.
task: 60668
- When clicking on the invoices stat button on payment transactions via
the form view a traceback is displayed.
This is due to the fact that the code is trying to access to a
member/field named "id" on an integer.
"invoice" is an integer, not a record/object.
Purpose
=======
The Contact form is one of the most used/important view. It is quite
important to find the piece of information easily and to navigate in
a few clicks to the related views.
Specification
=============
Stat buttons
------------
- Restructure stat buttons with the following order:
Opportunities -> sales user
Meetings -> sales users
Sales -> Sales users
POS Sales -> pos users
Subscriptions -> Subscription users
Events -> event user
Tasks -> project user
TIckets -> helpdesk user
Purchases -> purchase user
Due -> billing: user
Invoiced -> billing: user
Vendor Bills -> billing: user
Customer/Vendor Partner Ledger -> accounting: billing
Analytic Accounts -> accounting: billing
Credit Cards -> sales user
Direct Debit Mandates -> accounting: billing user
Publish
- Use better/more relevant icons
- Check that the proper access rights are set
- Remove the bank accounts stat buttons and replace it by a one2many
tree on the Invoicing page.
Fields
------
Move some res.partner fields from the "Accouting" page to the
"sale & Purchase" page:
- Fiscal positions
- Payment terms
Miscellaneous
-------------
- Remove dead code.
- Display nothing instead "Please complete customer's informations and email"
on the popup when sending an email to a contact without email address.
.. & hide transaction list + page numbers on HTML report.
1. Before this commit:
Portal Invoices were displaying the total amount instead of the residual
amount. The pay button would also trigger a payment for the total amount
Now:
If part of the invoice is already paid, we show the residual amount and
payment transaction amount are set to residual amount so the client is asked
to pay what he really needs to pay.
2. Processed transaction results in a bootstrap alert message displayed at the
top of the page, showing warning, success or alert depending of the result.
This alert is supposed to show thank message `post_msg` only if it set.
Before this commit:
Since `post_msg` is an html field and editable through summernote, it will
never be empty. Indeed, empty field with summernote are replaced by a `br` tag
inside a `p` tag.
The condition would never be false, resulting in an empty `p` with a `br`
inside being displayed at the bottom of the alert, making it looks like it is
bugged.
Now:
The condition also consider summernote's empty string as such.
3. Remove the transaction list from the invoice portal template since it is not
an important information to the client.
Some client would not even understand what it is.
4. Hide page numbers on HTML report since they are not split in pages and page
number remains empty, resulting in `Page: /` (Or empty square with the
'clean layout.)
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
The field `transactionReference` of Sips must contain only
alphanumerical characters. Previous commit 31dc6b888e solved
the special case of several attempts to pay, but a much simpler case may
appear in v11. Paying an invoice is likely to fail since the reference
contains by default `/`.
In the previous commit, we could simply modify the common `payment`
module code. In this specific case, however, we only change the
reference if the acquirer is Sips.
opw-1841483
This commit adds the auto-creation journal for installed acquirers.
This is not easy because:
- The acquirers are created on the 'payment' module but are enabled only when the specific module
is installed. E.g. Paypal is enabled with 'payment_paypal'.
- To create a journal, a chart of accounts is required. However, the post_init_hook on the
'account' module makes the installation order harder. E.g install payment_paypal directly:
The module are installed in the order: account -> payment -> payment_paypal -> l10n_generic_coa.
To fix the problem, the journals are created at two moments:
- During the installation of the chart of accounts.
- At the installation of an acquirer module. E.g. payment_paypal.
Was PR #23904
Was task: 1831620
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 was already the intended behavior, but in Python a return inside
of a try...finally does not behave this way. From the Python
documentation [1]:
When a return, break or continue statement is executed in the try
suite of a try...finally statement, the finally clause is also
executed ‘on the way out.’
This can cause issues because some payment acquirers will return an
error when refunding a pending transaction. This puts the transaction
in the 'error' state which means it won't be refunded anymore.
Additionally, putting s2s_do_transaction in a try...except like this
hides any traceback that occurs which makes troubleshooting harder.
[1] https://docs.python.org/3/reference/compound_stmts.html#finally
Steps to reproduce the bug:
-Just purchase a simple product using Authorize.net
-Click on "Pay Now" to be redirected to Authorize.net gateway
Bug: The company field added during checkout page was not filled.
opw:1817597
Purpose
=======
It looks a little to restrictive to only allow bank journals on payment acquirers.
For example on could want to define a manual payment acquirer linked with a journal of type "cash".
Allow both journal types instead of only bank.
Code to thumbnail payment icon image had an error for python3 because
from RPC the image would be a text string instead of an expected
bytestring.
This change accepts both and made another small fix in the view since
image_medium doesn't exist (and image is already thumbnailed).
A third fix was that removing an image caused an error.
opw-803722
closes#22088
When installing a payment acquirer from the kanban view, this would by
luck display the form view correctly.
But if we go back to the listing then forward to the form view, things
go awry.
This is because the listing action views have not been updated after the
module installed, this worked at install because we loaded a new action.
This commit change the action so when installing a payment acquirer from
the kanban view, the view is simply reloaded.
opw-786454
closes#21757
- Go in Accounting > Sales > Payment
- Fill the mandatory info, and create a "Payment Transaction"
- On the form view, change the Partner
- The Customer Details are empty, and saving is not possible since the
country (mandatory) is not filled in
Closes#15708
opw-771753
* add a method computing available acquirers and payment tokens for a
given partner and company. Those data will be used notably in customer
portal when displaying the payment form;
* raise if no partner_id set in s2s process. Indeed this field is
required but values come from a dict. Current code raises an error
about None being converted to Int instead of giving the real error;
Christophe Simonis