[16.0][Add] sale_order_blanket_order

[lmignon]

requires:

• [16.0][ADD] sale_stock_prebook #3423
• [16.0][FIX] sale_order_product_picker: Fix addon installation when this addon is installed #3457

Context

When a company sells the same products to the same customers on a regular basis, it's a common business practice to create a sale framework that defines the terms and conditions of the sales.

If you need a way to define:

• the terms and conditions of the sales,
• the payment terms,
• the delivery terms,

and also secure the quantities of the products to be delivered, the sale framework module is the right choice.

This module introduces 2 new kinds of sale orders:

1. Sale Blanket Order: This is a sale order that defines the terms and conditions of the sales, the payment terms, the delivery terms, and secures the quantities of the products to be delivered. It is used to create sale orders that will be delivered in the future.

2. Call of order: This is a sale order that is created to consume the quantities of the products secured in the sale blanket order.

Others modules can be used to provide the same kind of features. For example, the module (sale_blanket_order)[https://pypi.org/project/odoo-addon-sale-blanket-order] also defines the concept of sale blanket order. The main difference between the two modules is that the sale framework module extends the sale order model to add the sale blanket order and the call of order. This allows to keep the benefits of all the extensions made on the sale order model by other modules without having to adapt them to the sale blanket order model (discount, invoicing; inventory process, ...).

This module extends the functionality of Sale Order to support Blanket Order and Call of Order.

Blanket Order

A Blanket Order is a standard sales order with the following specific features:

• Type: Classified as "Blanket Order".
• Defined Duration: Includes a validity period (end date).
• Payment Terms: Allows selection of preferred terms (e.g., 90 days end of month, upon delivery, etc.).
• Invoicing Policy: Can be based on product settings or the order itself.
• Stock Reservation: Allows advance reservation of sold quantities.
• Handling Unfulfilled Quantities: Provides options for dealing with undelivered quantities upon order expiration.
• Prices are calculated based on existing rules since it is a standard sales order type.

The blanket order serves as the central element triggering stock management and invoicing mechanisms.

Stock Management

Delivered quantities are tracked on the sales order lines as with regular sales orders.
The goods are not delivered upon confirmation of the blanket order, but stock can be reserved for the customer using OCA modules:

• sale_manual_delivery: Marks sales orders as "manual delivery," preventing stock reservation or delivery preparation.
• sale_stock_prebook: Marks sales orders as "to reserve," triggering stock reservation but blocking delivery preparation for such cases.

Invoicing

Standard invoicing policies apply (e.g., invoice on order or on delivery). Payment terms are configurable per order. Prepayment can be enforced by configuring the invoicing policy at the order level using the OCA module (sale_invoice_policy)[https://pypi.org/project/odoo-addon-sale-invoice-policy/].

Consumption Management

A wizard will be available on the blanket order to initiate a delivery. It allows users to select products and quantities for delivery. This action creates a Call-off Order linked to the blanket order.

Call-off Order

A Call-off Order is a standard sales order with these specific characteristics:

• Type: Classified as "Call-off Order".
• Linked to Blanket Order: Only includes products from the blanket order.
• Delivery Release: Enables the release of reserved stock for delivery.
• No Invoicing or Stock Management: These are handled via the linked blanket order.

Stock Management

No delivery is generated directly from the call-off order.

It triggers:

• Release of the reserved quantity in the blanket order.
• Adjustment of stock reservations for the remaining quantities.

Standard Sales Orders

To support existing workflows (e.g., e-commerce), call-off orders can be generated transparently from standard sales orders based on product and availability:

Entire orders may be converted into call-off orders if all products are linked to a blanket order.
Mixed orders split call-off items into a new call-off order, with both confirmed within the available quantities of the blanket order.

[pedrobaeza]

There's also sale_blanket_order in OCA.

[pedrobaeza]

These dependencies seem too much for a "framework".

[lmignon]

It's probably not the best name. I have no other idea as the name “sale_blanket_order” is already in use.

[pedrobaeza]

Yeah, but it's not only a question of the name, but to require such dependencies, that I think they should be extension modules: sale_framework_manual_delivery and sale_framework_stock_prebook. It also highlights that even using sale.order as base, it requires you some glue code for making it work. I would include also order on the name to be more specific. It's true that is not easy to name this. What about sale_order_multi_purpose?

[jbaudoux]

rename this module to sale_order_blanket_order as it allows to define the sale order type of an order as a blanket order.

[jbaudoux]

also remove the dependency to stock from this module and make another one for the glue with stock

[lmignon]

There's also sale_blanket_order in OCA.

see https://github.com/OCA/sale-workflow/pull/3436/files#diff-69478c720e8bc6a98546ecc5284bf2f95193e55918008899fe0160fc5e10972cR150

[rvalyi]

There's also sale_blanket_order in OCA.

..and even a "vault" module in server-auth I dare to say (désolé ; french only).

---->[]

[pedrobaeza]

In my experience in the past, extending a base model to behave different, requires more code to contain the undesired side effects than to add such features. Anyway, as said, having such heavy dependencies for the base module is too much IMO.

[lmignon]

In my experience in the past, extending a base model to behave different, requires more code to contain the undesired side effects than to add such features. Anyway, as said, having such heavy dependencies for the base module is too much IMO.

We analyzed the existing code and the Odoo code in depth with @jbaudoux and given the need to manage invoicing, stock reservation, etc. at the blanket order level, it seemed simpler to us to define new SO types. Otherwise, all the specific flows for price management, invoicing, etc. would have had to be duplicated for new models. I've tried to clearly present the constraints and objectives in the 'readme' files.

The module is not a base nor a simple module and may be split into several modules if possible. Work in progress

[pedrobaeza]

..and even a "vault" module in server-auth I dare to say (désolé ; french only).

I don't get the joke I'm afraid.

---

I don't insist more on the architecture, but a module with a generic name should be generic, not so specific of your project, including what prebook may be. And this repo is also very crowded to have even more deformations on standard objects. I wonder if this would be something to be on a vertical like wms.

[youring]

Hi @lmignon thanks for the huge work. Just a minor suggestion for naming.
IMHO, order_type is too common to be used here to just distinguish whether a sales order is a normal, blanket or call-off, and note that there's already a module sale_order_type which specializes in managing various order types.
From a functional user perspective, I think a more specific field name here would give the user a better idea of what it represents, thus less headaches.

[lmignon]

Hi @lmignon thanks for the huge work. Just a minor suggestion for naming. IMHO, order_type is too common to be used here to just distinguish whether a sales order is a normal, blanket or call-off, and note that there's already a module sale_order_type which specializes in managing various order types. From a functional user perspective, I think a more specific field name here would give the user a better idea of what it represents, thus less headaches.

Thank you the review. @youring I'll think about your comment about the naming even if I don't have a better idea at the moment. Once our functional tests are completed, I'll mark this PR as ready for review.

[nilshamerlinck]

you probably noticed it already as I see you isolated them, but fyi tests seem to get stuck there:

and because builds were triggered for each of the last commits, it created a bit of traffic jam in the ci queue for some moment 😅 (until Stéphane killed pending jobs)

[rousseldenis]

@lmignon The install of this addon does not work on large database.

See: #3476

[lmignon]

@rousseldenis
It worked on my very large database.... (even if it was not fast and should be improved)