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.
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
Previously, when an update operation was performed, the list of
ids in the x2many field was emptied beforehand.
It kinda worked in lots of cases where one would expect it to
fail because in thoses cases the widgets send link_to commands
along with the update one, thus re-adding the removed line.
Now the behavior is more consistent accross the board. We start
with the current list of ids and apply the requested changes.
When the user zooms with the browser, the bottom left pads are
misaligned for some zoom levels.
By slightly reducing the width of the action pad, this can be solved for
all acceptable zoom levels.
opw-745074
Use the field `time_cycle` for cost computation, which takes into
account the routing configuration (fixed time of computed based on
previous operations).
- Create a work center with a capacity of 1, an efficiency factor of
100% and a cost per hour of 40$
- Create a routing with two operations: one with a fixed duration of
30:00 minutes (OP1) and another with a duration computed on real time
but with a default of 30:00 minutes (OP2)
- Create a component with UOM "m" and a cost of 10$
- Create a finished product with an associated BoM
- The BoM has a first line with 0.8m of component in the OP1 and a
second line with 0.4m of component in the OP2
- Activate the Compute from BoM option on the finished product
- The proposed cost is 32$
Expected cost: 52$
(30 minutes @40$/hour + 30 minutes @40$/hour + 1,2m @10$/m)
We divide the WC cost by the number of operations, which does not make
sense.
opw-741032
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 ... "
An archived forum could still be posted in, something better should be
done in the next version (eg. website published present on a lot of
record type) but as of 10.0 just this improvement is done.
opw-745510
closes#17365
Otherwise some changes can create rpc errors that are silently caught
and never seen as long as, out of (un)luck, the end result is the same.
Tests which need to create a server error can just simulate it using
the mockRPC mechanism.
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).
When the user writes something in a Many2One input, after a short
delay, a name_search RPC is done with the value written in the
input, and results are displayed in a dropdown. Then, if the user
clicks on the input, the dropdown closes. If he clicks again, it
should do again a name_search RPC with the value of the input.
Before this rev., it was doing it with the empty string.
Suppose that we have a many2one which is set (has a value) in
a form view. Before this rev., if the user unset the value (by
erasing the input content in edit mode), and then reset the same
value, the input remained empty, and the old value wasn't actually
reset.
Problem occured with checkboxes in editable lists: when pressing
up, down, right or left with the focus on a checkbox, in addition
to navigating in the requested direction in the list, the page
scrolled (if there was a scrollbar of course). This was because the
event wasn't 'preventDefaulted'.
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.
Fixed some issues with parralax image updates:
- Background updated without clicking
- Default wallpaper not coming back
- Background disappearring sometimes
In carousel snippet, the target element for background snippet option is
being changed manually. So for the new target, we have to rebind the
associated events that were bound in `start` function of the snippet
option. For that, some code is extracted from the `start` function and
is used to rebind necessary events for new targets.
In particular, this was preventing the carousel slides' backgrounds to
be automatically removed when a background-color was selected.
The context is not in the kwargs when the integrity error is raised from
a rpc request. So the user lang was lost and the sql error message was not
translated.
The part treating the callable message in sql error is depracated.
opw:743259
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.
Olivier Dony