Same reason as: 4ba4d61903
Some messages from payment are displayed on the frontend (eg. when the
transaction is being done on the ecommerce), but only translations of
module matching a given domain (computed with the method of ir.http
model: _get_translation_frontend_modules_domain) are made available on
the frontend.
With this changeset, payment is added in the domain (which can be done
since payment depends on account, account on portal, and portal in
http_routing that declares the method).
opw-2033528
closes#34712
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In case the partner has no language (not a required field), the fallback on the
payment transaction was 'en_US'
en_US may however be an invalid choice for partner_lang field as it is
a selection field that only has the activated languages (result of the call to
self.env['res.lang'].get_installed())
A database created in a different language does not have en_US activated
Fallback on user language instead of False as the partner_lang is expected by
some payment providers and may produce an error is empty
Fixesodoo/odoo#33750closesodoo/odoo#33870
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit will correctly check for a custom payment.transaction create method
on 'self' instead of the acquirer's provider before calling it.
closesodoo/odoo#33033
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Render from payment//payment_acquirer.py promises:
All templates will receive:
'feedback_url', 'return_url', 'cancel_url', 'error_url'
However they are all in -> FIXME.
After 6 years in FIXME, this promise is still a lie.
It is unfortunate since the Adyen payment provider requires 'return_url' to work.
Before, this function was called by _get_shop_payment_values,
which provided a value for it.
We copy the value that was given there directly as a default in render,
so that it doesn't crash no matter what method calls it.
opw 1928918
opw 1944142
closesodoo/odoo#31814
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Suppose that a payment transaction cannot be reconciled for any reason.
Then _cron_post_process_after_done will try to process it every 10 minutes until
the end of time.
Moreover, if the user takes some manual action before
_cron_post_process_after_done,
even if in principle it would have been able to go through,
then it is likely to fail, e.g. on invoice_open.
Meaning that a transaction that could have been processed will become
an undead transaction.
To avoid that situation we set an arbitrary retry_limit_date set to 2 days,
which seems a reasonnable compromise.
It gives some time for the transaction to go through, but not exaggeratedly so.
opw 1945953
closesodoo/odoo#31791
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- The method `_get_available_payment_input` that returns the available
payments acquirers and the payments tokens for a specific user never
returns the payments tokens linked to a non s2s payment acquirers.
This is wrong, the payments tokens should always appears no matter
what are the acquirers' payment flow.
The payment flow is used only to specify where the customer should
input his credit cards details, either on Odoo or on the payment
acquirer's website (or popup).
Once a token is created, it is safe to process it since no credits cards
details are stored on the Odoo database.
closesodoo/odoo#30258
The field partner id is not a required field in payment transaction, and
we try to read its value in the dictionnary given to the create
function, so if a transaction is created without the partner_id, it will
raise a KeyError.
So to fix it, we only complete the pratner values on the payment
transaction if a partner_id is given.
- The payment transaction processing cron retrieves all the transactions
that need to be processed.
In some cases, it can causes issues when trying to process payments
that are being process by the payment polling page after returning
from the payment acquirer.
To avoid this concurrency issues, the cron will only process payments
that have been validated for at least 10 minutes.
closesodoo/odoo#29317
- When a payment is done through a `payment.transaction` the
communication should be the transaction's reference instead of its
invoices reference.
closesodoo/odoo#29187
- Before this commit when a transaction failed, the code doesn't
rollback and continue to process the other transaction, thus creating
record that should be rollbacked.
closesodoo/odoo#28748
Transfer accounts created for payment acquirers was ignoring the prefix of the main transfer accounts and was always creating accounts with code 000001, 000002, etc.
The reason is because the method was called on an empty recordset
closesodoo/odoo#28789
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
Purpose
=======
- Add the SwissQR Code on the invoice in aim to replace the actual ISR
- Improve the settings of the SEPA QR Code to make it more user friendly
Specifications
==============
- ln_ch:
- Add a SwissQR Code on the invoice to fit the Switzerland QR-Bill Format
- Use the "partner_bank_id" field to generate the QR Code
- Add function to get the address number out of the field "street" and "street2"
- account:
- Remove the SEPA QR Code's journal settings from the general setting
- Display the "partner_bank_id" field on the invoice "Other info" page
- Use the "partner_bank_id" field to generate the QR Code
- website_sale:
- Add a check box on the payment acquirers to use the SEPA QR Code on the e-commerce
- Use the payment acquirer "journal_id" field to generate the SEPA QR Code
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
- 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
Nicolas Lempereur