Backport of 48156efcd9 + 44f6409731 that fixed the problem in next versions
Revert of da563bcf5c that hid warning for users in backend
One day, we will have to refactor website_sale_delivery. But today, we are the dung beetles.
With a UPS delivery type carrier,
`ups_get_shipping_price_from_so` can return a `ValidationError`,
making the carrier unavailable for this order.
Nevertheless, the iteration checking the availability of the remaining
carriers must be ensured.
opw-657161
Since a2b94b0b6d, we already push the cost
of deliveries on the DO (it may be a grid or a carrier).
So we simply harmonize the behavior: when a DO is transferred,
_add_delivery_cost_to_so() is always called (it will check whether the
delivery costs are to be added to the SO or not)
If the delivery method chosen is NOT an external provider (such as
Fedex, UPS...), the shipping cost is not set on the delivery order.
This fix will search for any shipping cost on the associated sale order
and will update the shipping cost accordingly on the delivery order.
opw-653328
Since commit 78cc0b95f4, there was no more
way to invoice the actual price of a shipping (after the transfer).
In order to make that available again, we introduce a new field on the
sale order. This field automatically detects whether a sale order
contains a "delivery" line or not, at sale order confirmation
(action_confirm).
When the delivery order is processed, the actual shipping cost is thus
repercuted on the sale order if and only if the shipping price was not
"forced" at the sale order confirmation.
(and a few refactoring to avoid copy-pasting code lines)
As the transporter interfaces will put a label on every package,
it is in handy to have a field with the list of the final packages
(and their weights) treated in the picking.
We give a weight for the products that are not in a package also(bulk).
We only put the weight on the package in the views.
The weights in the product form views should appear entirely or not in
product / product templates (only when only 1 variant)
(attrs was only on the field, not label, ...)
The digits= for the weights are not needed as there is a decimal precision
on these fields.
* migration to new API
* removed delivery.grid object, has been merged with delivery.carrier
* change view of delivery.carrier (price rules, etc.)
* tests from yml to py
* website : restrict the list of countries for delivery address in the shop
- Added reverse for purchase_ids/purchase_line_ids/invoice_ids/invoice_line_ids
- Put first everything in a dictionary by invoice to create and
then create invoice by invoice
Add a `delivery_type` selection field on delivery.carrier.
The default is `grid` i.e. a static pricing grid with rules
to compute the delivery costs.
Future module will however be able to extend the `delivery_type`
selection to add new keys, such as `fedex` or `ups` and provide
custom implementations for the various API methods, as described
below.
In order to add your own external provider, follow these steps:
1. Create your model MyProvider that _inherits `delivery.carrier`
2. Extend the selection field `delivery_type` with a pair
('<my_provider' , 'My Provider')
3. Implement API methods as required:
<my_provider>_get_shipping_price_from_so
<my_provider>_send_shipping
<my_provider>_open_tracking_page
<my_provider>_cancel_shipment
Martin Trigaux