Thursday, August 27, 2020
4 changes · master
Enhancements to existing features
Restaurant cashiers can now continue adding items to an order until the payment is formally validated, even if a card payment has already been completed. For payment providers that support it, such as Adyen, the authorized payment amount can be adjusted to match the updated bill, reducing the need to cancel and restart payments.
Original PR description
As long as the payment is not validated, the cashier can add products to the order, even if the payment has been completed. The amount authorized can be adjusted if the payment interface implements the canBeAdjusted method. TaskID: 2117032 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sales order lines now show clearer availability statuses and expected dates, helping teams understand whether products can be delivered on time. Forecast reports were simplified with clearer quantity signs and labels, and a costly sales order quantity calculation was replaced with a direct report button for better performance.
Original PR description
[FIX] sale_stock: fix json_forcast attrs in SO line
[FIX] (sale_)stock: SO line delivered refactor
In SO line, refactor json_forecast ('Delivered') computation:
"Available" if related stock move is assigned, (already available).
"Exp ", if the product will be available at "date". in Red if
the deadline of SO exceeded, else orange.
"No Available", if the product won't be available in the current
situation.
Change the computation of json_forcast of stock move to add a info
about expected date on partially available moves.
[IMP] (sale_)stock,mrp: improve forcasted report.
Add a minus before quanity if it describes a output move.
Remove intermediate section "Pending Incoming Documents" and
"Pending Outgoing Documents".
task-2324039This pull request modernizes the graph view renderer, improving how chart-based information is displayed and maintained. It matters because users should get a more reliable and consistent reporting experience, while the product team benefits from a cleaner foundation for future updates.
Resolved issues and error corrections
Reordering quantities now update correctly when related purchase orders or RFQs are edited or cancelled. This helps ensure replenishment reports show products that still need ordering, reducing the risk of missed purchases or stock shortages.
Original PR description
Before this commit, `stock.warehouse.orderpoint` `_compute_qty` didn't depend on `purchase.order.line` (POL). This means when a relevant POL was edited/cancelled, then the `qty_forecast` wouldn't…
Before this commit, `stock.warehouse.orderpoint` `_compute_qty` didn't depend on `purchase.order.line` (POL). This means when a relevant POL was edited/cancelled, then the `qty_forecast` wouldn't correctly update. To reproduce: - Create a product w/ a vendor and buy route active, - Go to replenishment report, create a reordering rule, and hit order for product (RFQ should be created) - Cancel the RFQ and go back to replenishment report The product should reappear in the list view, but does not because it's `qty_forecast` has not updated and therefore has not updated corresponding `qty_to_order` value. Note string rename of `purchase_line_warn` 'Purchase Order Line' => 'Purchase Order Line Warning' is due to repeat label use issue. It is better to rename the poorly labeled `purchase_line_warn` than to give a hacky label for new One2many field. Task: 2285912 Manual forward port of: odoo/odoo#56580 due to migration test error Closes: odoo/odoo#56625 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr