Commit 8911be11d1 moved code from website_portal_sale to
a new sale_payment module, in order to move code down and ease its use in
variou addons. However a called method was forgotten in the process leading
to some issues when using sale_payment. This commit fixes that.
PURPOSE
=======
It's confusing as it's not used. We had a customer with two exact same rules; he complained to the
support today because Odoo decided to use the other rule. (he was confused because he thought
priorities were based on sequences as there is a sequence field that allow drag & drop)
Order is based on "applied_on, min_quantity desc, categ_id desc", not on sequences. (since v9
and it's better that way; but we forgot to remove the sequence field)
SPECIFICATION
=============
Remove field
For now, these tests do not work with another CoA than the generic one.
Depending on your testing infrastructure, they may or may not pass.
We skip then invalid CoA's and plan to make them work in master.
On the 6 June, the rate from EUR to USD change
in demo data. This cause problem in test, when
comparing amount.
We choose to not used currency rate defined in
demo data and that are time-dependent.
The import_module() method does not need to be public,
so let's mark it private. It's not called by anyone
except import_zipfile().
After 76cd8d2558 it would
fail anyway because addons_path would not be prepared by
import_zipfile().
Before this fix, if the start field is readonly, the user could not create
an event. With this commit, it is also ensured that the context sends the
right default values to the view
In case of a MemoryError, there is no error message, the user gets a
"Database restore error: "
without any details.
Instead fallback to the repr.
This way, a wrong password is
"Database restore error: Access denied"
and a memoryerror
"Database restore error: MemoryError()"
Closes#17393
On a pricelist, if multiple rules were set with the same
set of rules condition, the choice of which rule/item
is used was random, according to the postgres database
state.
Adding the `id` in the order force to always use the same
rule/item (the first that was created).
opw-744865
with the new views, we removed the many2many_kanban widget on many2manys, since it is the default behaviour anyway, but we also removed it for a few one2manys. And this is a mistake, some one2manys have to behave like many2manys.
(PR #17190)
This commit separate code from website_portal_sale, website_sale and
website_quote in order to extract common code, separate payment code
from sale model and controller code and ease reusing of payment code
in various addons.
Main features are
* move account-related code from website_portal_sale to a new
website_account module
* move payment related to sale in a new sale_payment module
* factorize JS code to handle payment through form and tokens
* use generic sale payment code in website_sale and website_quote
Refer to individual commits for more details on the branch content.
This commit Closes#16956.
Indeed payment module already adds a website_published button to ease
acquirer management directly in payment without link to website. The
mixin added in website_payment adds a website_url field that has no use
for payment acquirers and is not used at all in the current codebase.
As there is no website url the website publish button method is not
different than the one already implemented in payment. There is
therefore no need for this override, lessening model code in
website payment.
Online quote now uses JS code from payment module in order to make online
payments. Front-end template is updated to use o_payment_acquirer_button
generic class for payments and data is added to be managed by payment.js.
This allows to remove some strange code parsing the url to find the order
ID and token instead of using rendered values.
A payment controller is removed because it was only a shortcut to another
one. In transaction controller token parameter is renamed to access_token
to avoid confusion with payment token and match the payment and website
sale naming.
Online Quote controller now uses tools method from sale_payment module
like website_sale. This way it is now standardized and moved out of
controllers that should not perform so much model-level computation.
This commit adds tools method in sale_payment related to sale order
confirmation, token and transaction management. Purpose is to be able
to use them in frontend sale module like eCommerce and Online Quote and
have it standardized at model-level instead of done custom in controllers.
JS code managing transaction creation through acquirer 'Pay Now' form
button is improved in order to be less website-sale dependant. It now
takes parameters for access token and URL to call in Json. Class used
to bind JS is now o_payment_acquirer_button in order to be more generic.
eCommerce module is updated accordingly. Future commits will probably
make Online Quote (website_quote) use it.
Indeed this code is difficult to understand and uses unnecessary
variables. Both confirm_so and generate_and_pay_invoice methods now work
on payment.transaction records as they belong to that model. Finally
less code is put in the try/except of confirm_so to avoid hiding real
errors and issues.
One interesting thing would be to correctly manage so confirmation errors
and mail sending errors. This is currently not done and will maybe be
done in future commits.
Access token field is moved directly in sale module. Indeed future commits
will improve customer portal and access tokens will be used in other module
than website_quote. This commit already moves the field.
Moreover some strange code in website_sale already uses access_token even
if it does not exist in that module. Moving the field solves that issue.
Finally so_token defined in stripe is renamed to access_token to have the
same naming through all addons.
- Create an excluded tax of 20 %
- Create a customer invoice of 1000
- Create a payment of 900
- Make the matching between the invoice and the payment:
Write-off of 83.33, with the 20 % tax
Error: 'Cannot create unbalanced journal entry'
After commit 89cbef8540, the tax are by default not created
automatically anymore. We should make sure to pass the context key
`apply_taxes`.
opw-744266
When disabling the customer portal
in the general settings
(or uninstalling the `portal_sale` module directly),
the model `sale.order` no longer has a method
`get_signup_url`, and it therefore leads
to the fail of the email template rendering which is
still referencing this method.
Besides, the `access_url` is actually used only if
`is_online` is True,
(see the `% if is_online:` few lines later)
and in this case `get_signup_url`
was not used at all.
Therefore, we can assume `None` is a good alternative,
as the resul of `get_signup_url` was actually no longer
used.
opw-710481
If you have two invoices with a same product,
- one having 1 unit of a product,
- the other -1 unit of a product,
The sum of these quantities will be 0, and it will lead
to a division by zero in the former sql request.
The nullif should be applied on the sum, not on the line quantity.
opw-745073
This try except block was added in another era, where the piece of code
in the block was far less ambitious (and not for good reason since
adding a try except block because of a malformed mail template seems
overkill).
Even worse, this block actually prevented errors from bubbling, which
could have adverse effects.
Example: a long transaction confirmation (several seconds since it
implies S2S communication, invoice creating/validation, etc.) is
rollbacked because a mail message is recorded on the quote during
the processing time. The quote confirmation then crashes because of a
concurrent update error in postgres. This try except block does not
re-raise the error, which means that instead of retrying the operation
like the ORM would normally do, we have an incomplete traceback in the
system (since the error message crashes itself) and the transaction is
not validated (as far fetched as it may seem, this is in fact how this
bug was discovered).
This try-except block offers no gain in error logging (on the contrary,
since we have lost the initial error-causing statement) and prevent the
orm from correctly managing errors.
This commit removes it and let the orm handle the errors like a grown up
man; either crash for real (because it should crash to know if there's a
problem) or retry the transaction if it's a serialization issue.
opw-744629
Move sale and payment bridge code into its own module. This commit mainly
moves (and reorganizes without changes) code from website_sale related
to payment and SO confirmation.
Only change is that payment_acquirer_id field on sale order is now a
related on transaction.acquirer_id . Indeed in website_sale and
website_quote both values were written but only managing transactions
and getting its acquirer is more efficient and ensure values are coherent.
JS part controlling payment form management is moved directly into
payment to reuse later on in future commits. Probably.
Purpose: separate and locate website code for main addons in their
correct module. This commit targets accounting related customer portal.
This commit adds a new bridge module between website and account. It
contains code related to website portal of invoices. It was located
in website_portal_sale but this one should only be the quotation and
sales portal.
A dependency from website_sale to website_account is added to ensure the
behavior and available features of eCommerce are not impacted by this
commit.
No code modification is performed in this commit except one unnecessary
less rule. It contains only code move.
Instead of checking that the day short name is effectively Sat or Sun
it now checks that it is the saturday or sunday based on weekday. It is
located in a method to ease inheritance or implementation of specific
behavior based on some calendar if necessary.
Closes#17294 .
The attribute filters based on all products matching current domain was limited
to the first page of result only.
If all the products of the current page had no variant, no filter was displayed.
Closes#17361
Purpose
=======
Ease payment setup & flow of ecommerce
- In Odoo, we have 3 ways to sell:
- sales -> invoice is needed when you issue quotations
- eCommerce -> invoice is mostly for B2B but is part of the flow in any case
- PoS -> invoice is mostly for B2B. It's an option
-> make invoicing an option in ecommerce (still working but invisible)
- Config of payment acquirers is tough to understand: remove order confirmation
- the invoicing process depends on the company, not on the payment acquirer -> simple invoicing option in ecommerce settings
- capture manually: only for authorize.net! Somehow it shouldn't be visible for other acquirers
- terms are confusing
- payment method: payment method is something else in accounting payments. -> rename to payment acquirers
- transaction: the difference with payments is not obvious -> rename to payment request
Specification
=============
- New module to add invoicing fields, buttons and menus: account_invoicing -> hide invoicing stuff when starting with eCommerce (not Sales app)
- new setting in website:
- keep behavior of current setting
- if automatic generation of invoice is checked (default value), an invoice must be generated, validated and reconciled when the order is confirmed
- If "Invoice what is delivered (manual)", users will create the invoice manually from the order.
- tooltip: Choose the automatic mode if you use to issue an invoice whenever an order is placed. The manual mode allows you to invoice based on what is really delivered. That way you can invoice in several steps, etc. The mode selected here applies to any new product created but not to products already existing. If you want to invoice delivered quantities, you must update the invoicing policy of those products.
- New primary button "Mark as Paid" on SO if status = quotation sent and payment acquirer provider = wire transfer or manual config
- when you press "Mark as Paid" -> mark payment.transaction as done.
- easy way to cancel payment -> when clicking Cancel Order button: reset the transaction to Pending, break the reconciliation receivable (=invoice) / payment, cancel the payment with an opposite entry. That way everthing comes back to initial state.
- when a payment.transaction is 'authorized' or 'done' -> confirm the SO
- when the transaction is 'done' -> register also a payment in the payment journal set on the payment acquirer (mandatory field, see next item).
- must work for any payment acquirer, even if provider = wire transfer or manual configuration
- restructure options of payment acquirers:
- replace Order Confirmation by:
- Payment Journal
- existing m2o (journal_id), make mandatory, only show account.journal whose type = bank + context when you create a journal from the field, default value = Bank, display only if account_invoicing is installed
- tooltip: Payments will be registered into this journal. If you get paid straight on your bank account, select your bank account. If you get paid in batch for several transactions, create a specific payment journal for this payment acquirer to easily manage the bank reconciliation. You hold the amount in a temporary transfer account of your books (created automatically when you create the payment journal). Then when you get paid on your bank account by the payment acquirer, you reconcile the bank statement line with this temporary transfer account. Use reconciliation templates to do it in one-click.
- Capture Amount Manually [ ]
- only visible if acquirer type = Authorize.net
- tooltip: Capture the amount from Odoo, when the delivery is completed.
- must be compatible with "Create Invoice Automatically". -> The invoice must be created when the payment transaction is "done"
- Specific Countries [ ]
- if checked show the country field just below
- tooltip checkbox: Make this payment acquirer available for customers of specific countries.
- tooltip Countries: If you leave it empty, the payment acquirer will be available for all the countries.
- Add Extra Fees [ ] move up the fees fields
- Relabelling:
- Payment Methods -> rename to Payment Acquirers (menu items, views, etc.)
- real payment methods already show up in the Register Payment modal of invoices.
- Transactions -> Payment Requests
- "Transaction" is too close to "Payment". People think it's the same. With payment request, it makes think about a process: payment request -> payment
- Add a "Payment Requests" stat button to SO form to see all the payment attempts + show the status in this list view.
- if only one payment request, display it in form view
- + remove payment method + transaction fields below the SO total
Additional remarks:
- mark as paid button only when you can do it
- mark as paid should confirm the order (+ hide Confirm button)
- invoicing settings: faut un peu changer le truc pour séparer la génération automatique de la facture du mode de facturation des produits
- hide radio options when Invoicing option is not checked
- to hide if account_invoicing is not installed:
- invoicing options in product form
- SO invoicing status in list view
- invoicing status in SO form
- invoice link once order paid + invoice notification in the SO chatter + hide mark as paid button if already done
- create invoice button in SO
- orders to invoice in website dashboard
- in automatic invoicing > mark order as paid > cancel order > reset to quotation -> no way to record the payment again
show MARK AS PAID in draft quotation status IF payment transaction is set ?
Purpose
=======
The field journal_id on a payment.acquired is required on the view. The only issue is that the journals cannot be created before having installed a localization. When the payment acquire module is installed before the localization, the journal id is not set on the payment acquire and it's impossible to make a call to `write` (For example publish the acquire)
Specification
=============
When making a write or a create on a payment acquire, udpate the journal_id with a default value if not set.
Thibault Delavallée