Managing Blanket Orders Sales and Purchase

Feature
1

Rationale

Link to : Best practice to manage delivery contracts

A blanket order is a long-term agreement between a company and its customer or supplier.

You can also name this: Frame contracts

A “Blanket Sales Orders” is a contract with a customer who agrees to purchase a large quantity of product and requests partial delivery over a period. The customer can have regular delivery or via calls for delivery.

The price of the products is negotiated during the contract but it is possible to revise the price during the calls according to the agreements concluded with the customer (exchange value of the currency greater than x%, increase in transport costs by x% …)

With a “Blanket Sales Orders” it is possible to track the quantities remaining to be delivered without impacting the available stock. The impact in inventory will only be visible when lauching a sale after customer call.

A “Blanket Purchases Orders” is a contract with a supplier with whom we have an agreement to order a large quantity of product and request partial delivery over a given period. We may request regular delivery or via delivery calls.

The Price is fixed during the contract but can be modified as in the case of “Blanket Sales Orders”

With a “Blanket Purchases Orders” it is possible to follow the quantity to be taken from our supplier without having any impact in the planning of stocks. The impact in inventory will only be visible when lauching a purchase after your call to the supplier.

The purchase or sale created from a “Blanket Orders” must have information indicating to the customer or the supplier that it is not a new order but a call on the contract.

Proposal

10/15/2021 - update following discussion

Two different model : sale and purchase.
This is mainly because they will be managed by two different kind of users so the access right must be different.

A “Blanket Orders” Sale or Purchase must have :

  • Company
  • Blanket Order Number : A unique number with a sequence
  • Party
  • Contact
  • From Date
  • To Date
  • Type : Selling or Purchasing
  • Currency
  • Description : Internal information to describe the “Blanket Orders”
  • Terms and Conditions Notes : To allow the addition of clauses to the contract with the customer / supplier.

Lines :

  • Product
  • Description
  • Quantity
  • Unit
  • Unit Price

The possible states:

  • Draft
  • Quotation
  • Opened Running
  • Closed Done
  • Cancelled

The “blanked number id” is created on draft state.

Via the “Blanket Orders”, it must be possible to create a purchase or a sale using part of the quantity remaining to be delivered / ordered.
During this creation, it must be possible to select the products that will be included in the sale / purchase.

A “Wizard” is used to launch the creation of a sale or a purchase with all the product lines with a remaining quantity> 0. The lines will be created with the totality of the remaining quantity. The user will be able to delete lines or adapt the quantity directly in the sale or purchase.

It should be possible to create a sales or purchase document normally and link the line with a blanket order line. During this connection, the unit price should be adjusted.

The purchase or sale lines created must have a link with the original “Blanket Orders” lines (origin)

For the monitoring of quantities, we must be able to identify this information on the product’s line:

  • The contract quantity
  • The quantity processed : already delivered / received *
  • The quantity remaining : to be delivered / received = Contract Quantity - Quantity processed.
  • The list of Sales Lines / Purchase line related to this Blanket Orders product’s line.

*) the processed quantity must be recalculated during the processing of the linked sale / purchase to calculate with the modified quantity, but also during shipping or receiving to use the quantity actually shipped / received. Blanket Orders "

The relate on “Blanket Orders” :

  • Invoice relating to the “Blanket Orders”
  • Sales / Purchases relating to the “Blanket Orders”
  • Shipment int/Shipment Out relating to the “Blanket Orders”

This module must be generic and provide a first part of the response to the management of “blanket orders”. The notion of automatic launch based on a calendar should be part of a second phase with an optional addition.

Implementation

Future Improvements and Ideas

  • Check for the credit limit.
  • Check when closing the “Blanket Orders” if it was not fully consume.
  • Delivery Schedule
2 Likes
2

I think it will be better to have two different model for sale and purchase.
This is mainly because they will be managed by two different kind of users so the access right must be different.

I’m wondering if it should not be links to payment term.

I think it will be simpler to create the order with all remaining products and the user will edit the order directly.

I think we should allow to create an order as usual and allow the user to link a line to the contract. In this case the unit price must be updated.

3

I agree with this remark, I had not thought of the concept of access rights by model.

4

The idea is to have the possibility to define condition information at the contract level.
For example: price revision clause, delivery clause, payment terms clause.
But indeed the notion of “Payments Term” should be added to the model to be retrieved in the order when it is created.

5

Effectively creating the order with the remaining quantity simplifies the procedure.

Do you think that the order should be created automatically with all the product lines of the “Blanket Orders” (with remaining quantity) and the user removes the lines in the order of sales / purchases?

6

I’m wondering if states should be better named as:

  • Quotation → Negotiating
  • Opened → Running
  • Closed → Done (or Finished)

For me it is not clear how to create an order from the Blanket Order. It should be a manual process or we should have a wizrd to ask the user the requested quantities and create a order from it. Probably it will be easier from the User Point of view to just have a wizard which asks the quantities for each line and creates the orders.

7

Then I would simply add a note text field without any particular mean.

I think because it is the same amount of work than having a popup that ask to select/deselect lines and update quantities to them.

Maybe we could even skip this step and have only Draft.

See my proposal to create an order with the remaining and let user edit it.

8

Blanket Orders could have a “Delivery Schedule”.
A Delivery Schedule could consist of

  • Blanket Order id
  • date (today or in the future, no past dates)
  • quantity to deliver

When a Delivery Schedule is not applicable, it could be empty.

The Delivery Schedule for a Sale could be entered by hand, or
entered with help of a wizard (for example constant weekly/monthly delivery, see idea from @maxx Best practice to manage delivery contracts - #4 by maxx)

It also could come in from

  • a VDA4905 / VDA4984 / etc. delivery call
  • other defined formatted file or interface

The import / replacement of the Delivery Schedule should be handled by specific
modules, which give the user the possibility to

  • see which delivery calls were coming in
  • see the difference between the previous and the new Delivery Schedule
  • accept (or withdraw) the new schedule

When a new Delivery Schedule is accepted, it should replace the previous Schedule completely.
This functionality would not be part of the “Blanket Orders” module, Blanket Orders takes a Delivery Schedule as given, no matter where it comes from.

The Delivery Schedule for a Purchase could also be entered by hand or wizard,
but could later possibly come from other modules like “purchase_request”.

When creating a Sale and choosing a Position from a Blanket Order, the quantity
of the next delivery point in time could be proposed as quantity. It must be
possible to overwrite it by hand.
When there is no delivery schedule, the remaining quantity could be proposed.

It might be comfortable to be able to view the complete delivery schedule of the
Product while adding it to the Sale.

There could be a wizard to create a Sale draft from Blanket Orders for a specific customer,
containing all positions that should be delivered on or until a specific date. The Sale draft
could then be manually changed.

It might be convenient to have

  • a comparison between Delivery Schedule quantities for a given date, and the corresponding Sales (= planned deliveries) for this date

and / or

  • a warning mechanism, when there is no Sale position for a Delivery Schedule for a given date

It might be super convenient, but not necessary, to have this overview in a calendar style view.

9

For me the management of a scheduler should not be part of the initial implementation. It will be easier to extend the base module later.

10

I think the basics of a Delivery Schedule should already be part of the Blanket Order module, and should be well chosen, for the following reason:
There may come various modules which access / work with Blanket Order and Delivery Schedule. Simple ones, like the “cron” for weekly delivery; and more extensive ones like a VDA49xx module changing Delivery Plans on a daily basis. As long as they have a common basic structure, they will all be compatible with each other.
With “basics” I mean that the fields are available and can be seen and edited by hand. Nothing more. Everything else should be done by other modules, but the Schedule is the common ground for these modules which should be defined in the Blanket Orders module.

In fact I think that the Blanket Orders module should not modify the Delivery Plan in any way.

Sorry that this was unclearly worded in my previous post, I just wanted to give some examples for the use of a Delivery Plan.

11

I’m still in favor of a simple module first. I understand that you want to have this feature but it is not a strict requirement to implement an initial module and it can be implemented later.

1 Like
12

How to manage the relationship between a Sale / purchase line and the “blanket order line” for the implementation?

Create an “origin” reference field on the Sale / Purchase line to extend the concept of the origin of a line? This requires the modification of an existing module

Create a One2Many field “blanket_order_line” on the Sale / Purchase Line model via the new modules?

13

I’m not sure it should be an origin-like field but it could be a simple Many2One.
I think it should not be an origin because the line could be created by something else than the blanked order but still be linked to it.

14

I continue my questions on the implementation …

Regarding the calculation of the quantity processed.
You have to choose between a function field or a float field on the blanked order line.

I wonder if the function field will not consume too much perfomance because we should recalculate the quantity processed for all the lines of a blanket order at each opening. The quantity only changes when processing SALE LINE / PURCHASE LINE and processing IN / OUT shipments. Then the value should not change anymore.

In the case of a FLOAT field, it will be necessary to launch the computation of the field on SALE / PURCHASE and SHIPMENT IN / OUT events.

Which is better: function field or float field?

15

I think it is too soon to think about optimization. So the first design should avoid data duplication so what can be computed must be computed. Later if we see there are performance issue, it will be time to think about improving this.

16

Small sidenote: In the industry the term ‘Outline agreement’ is quite common for a blanket order, and the delivieries are called ‘call-off’s’. With or without delivery schedule

17

This is a great module - I also support the simple module approach first.

Feel free to contact me for any contribution to this module.

18

Okay, let’s focus on the module without schedule first.

19

For Sale, the Blanket Order Number comes from the customer. So it must be editable, and - if uniqe - then unique per customer.
There can be a unique internal number with a sequence, but the Blanket Order Number of the customer must be editable, because

  • user must be able to search for it → it is the key that is given on the delivery call off
  • it must be printed on the Delivery Note and Invoice

For Purchase, the number comes from the Company, so here it may be okay to use an automatic number with a sequence.

20

I do not agree. This is not the standard in Tryton. Number are always generated by the system. We store external reference in reference.

Any way in general I do not think it is useful to discuss implementation detail on blueprint especially those that will come from standard practice and usage of Tryton.