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.
PURPOSE
=======
The field auto_confirm is complicated to understand for common users. Furthermore, on of its options is only useful for authorize module.
SPECIFICATION
=============
Remove the auto_confirm field. The destinies of its options are the following:
- none: Simply disappear.
- authorize: Become capture_manually. It has nothing to do with the auto_confirm field has it's related to the autorize module (And could be extended to other payment acquirers too).
- confirm_so: Remove it. Will be automatic, and we will always validate the sales order and generate the accounting entries on acquirer validation.
- generate_and_pay_invoice: Is linked to the journal_id. The field journal_id is always set and we will use it to validate the sales order and generate the accounting entries on acquirer validation.
Bonus: website_sale: Allow to create/validate invoice automatically on `Mark as Paid`
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 unvisible)
Specification
=============
Hide the menuitems of account, and add a module account_invoicing that will display them.
Hiding the Sales root menuitem isn't sufficient to hide all the menuitems from the sales module.
Example:
1/ Install Ecommerce, you don't have any menuitems from sale as sales_management isn't installed
2/ Install CRM, the root menuitem is activated by the sale_crm, and all the menuitems from sales are displayed
Specification:
Add the attribute active=False on all the menuitems from sales
Activate them on sale_management
This attribute will be used in the next commit to hide by default account menuitems in the account module to finally display them in the account_invoicing module.
Without this attribute, we should create the menuitems with the <menuitem> tag and after that make them inactive by using a <record> tag
PURPOSE
=======
Correct wrong placeholder
SPECIFICATION
=============
1. On SO, field "Note", replace the current placeholder by "Setup default terms and conditions in your sales settings ..."
2. On PO, field "Notes", replace the current placeholder by "Define your terms and conditions ... "
When cloning a snippet section thanks to the editor, the associated
snippet options' `on_clone` methods are called. Now these methods
receive a new argument `options`. The option this commit introduces
is the `isCurrent` one. It allows the method to know if the snippet
section it is associated to is the one that was cloned or if it is a
child of the one that was cloned.
This is useful to solve a known bug when cloning elements which have
bootstrap columns:
- When one column is cloned we want it to lose its col-*-offset-*
classes so that the offset is not duplicated (only the column).
- When a container with column children is cloned we do not want
these column' offsets to be removed (we want the whole cloned
container to be the same).
Some default website menu were not marked as active when landing on
their associated page, e.g. clicking on "Blog" loads the blog page
but the "Blog" menu is not marked as active.
This was because of slugified URL. Indeed, for the "Blog" menu for
example, the URL "/blog/1" redirects to the "/blog/my-super-blog-1"
URL.
Introduce a new snippet to show the company team.
This commit also introduces a new classe "s_no_resize_cols" to put
on a .row element to prevent the size and margins options to be used
on the .col-* children. This allows to build some complex layout without
having a deep hierarchy of snippet options.
Portal users do not have access on invoices or invoice lines. However when
viewing an online quotation in website_portal_sale some computation is
performed based on invoices and invoice lines. We therefore iterate on
invoice and invoice lines as superuser as we do not want to grant any
additional access on those models for portal users.
When choosing a payment acquirer or a delivery provider there is a link
allowing to directly jump in the backend to configure them. It has been
introduced at 6c2535b9b6.
However it is displayed for every user going through the checkout process.
This commit limits it to group_system. It seems a better idea to not show
it to everyone as they don't have access to it anyway.
Indeed, running the testsuite is not supported in multi-process (worker/pre-fork) mode, for multiple reasons: no multiple/concurrent execution of tests, necessity for in-memory cross-request statefulness (test cursor), etc.
We have no plan to work around these issues, as there seems to be no strong use case.
Our testsuite is mainly focused on the business/framework aspects, and not scalability/deployment aspects - which would require a much more complicated test infrastructure.
In this commit, we improve the behaviour of quick creation in grouped kanban views. The issue was that the quick create widget was removed when the user click somewhere else, even if the user added some text. For example, the problem could be seen in the kanban view for the tasks.
In this commit, we simply keep it around if there is a non empty text.
Clicking multiple times on 'Create' (in main list views) or 'Add an
item' (in o2m lists) might create invalid rows (i.e. rows with
required fields unset).
Creating a new record requires two sequential RPCs: a default_get
and an onchange (only if there is an onchange of one of the
record's field). When clicking twice to create a new record, that
sequence of RPCs is done twice in parallel, after unselecting the
current row (i.e. saving it if it is valid). However, in both
cases, there is no line to unselect yet (as both operations are
done basically simultaneously). When the first onchange returns,
a first new record is added to the list. When the second returns,
the second one is added and takes the edition, leaving the first
one, invalid, in the list.
This rev. ensures this doesn't happen by preventing concurrent
record creation.
... before saving a line.
Suppose that we have an editable list with one required field
(e.g. many2one) with an onchange. We add a record and select a value
for the many2one. Before the onchange returns, we click again on
'Add an item'. If we don't wait for the onchange to return before
unselecting the row (i.e. before saving it), a confirm dialog asking
if the changes can be discarded opens, because the line isn't valid
yet. This could easily be reproduced on the sale_order form view,
with some throttling.
This rev. ensures that we wait for the onchange to return before
saving the line, and thus before creating a new line.
In a slightly too naive way, we apparently tried to improve the
parse_float method while rewriting the new views. This was done by
using a regexp to match all occurences of a thousand separator.
The way the regexp was built was fine, until the thousand separator is a
'.', which, if used as a regexp, matches all characters. Also, sadly,
'.' is not so rare as a thousand separator...
When creating a vendor bill from a PO, the payment term configured in
the PO was lost due to function _onchange_partner_id.
When creating a vendor bill, the field payment term was invisibile if
there was no payment term set on the vendor.
opw:744714
When a ´default_order´ is set on an embedded view for a x2many field,
the sort was only applied server-side, after saving the record. After
adding a record in a x2many, the records were thus not correctly sorted.
We reintroduce here the client-side sort after the x2many modification.
With the new views, the attribute autocomplete on input was no
longer supported. We simply reintroduce its support in this commit.
The basic attribute values are 'on' and 'off' but one may want to use a
random string.
Note that an input with type='password' is a special case: the autocomplete
attribute should always be set to 'new-password' to remove autocompletion
(autocomplete='off' doesn't actually remove the autocompletion).
When clicking on 'Save & New' in the form view dialog, a new default record
is created. The parent was not correctly set in this record, which causes an
error if `parent` was used in context.
Only the validity of a date was enforced but the date could also be
wrong in other situation (required so must be filled, validation
attributes, ...).
opw-744273
closes#17329
Before this commit, error was giving on browser console when we open seo wizard which is due to the wrong (this) was passed when initializing Configurator
So in this commit, we passed correct this, to get rid of the error.
(PR #17260)
Yannick Tivisse