[New Feature] Blanket Sales Order and Blanket Purchase Order

Currently ERPNext doesn’t support blanket orders for sales or purchasing. If you don’t know what a blanket order is please check this wikipedia article. This can not be done in the system currently! The newmatik team would like to develop and contribute this.

The basic requirement for a blanket order would be:

  • Due Date: the date by which the blanket order has to be served, meaning that the whole quantity has been bought by you (purchase order) or by the customer (sales order)
  • Open Blanket Order Quantity: whenever a sales order or purchase order is created from a blanket order or if it is referencing it, it needs to reduce the open quantity
  • Pull price from blanket order: generally when you create a purchase order or sales order and you are referencing a blanket order (make button or referencing it in the order line) you should pull the price from the order rather than from the price list
  • Referencing in print format: sales order lines or purchase order lines should reference the blanket order in the print format
  • Batch Size: example would be that the customer orders 10,000 pieces in batch sizes of 1,000 pieces which would be 10 deliveries.
  • Production Order: you should be able to create a production order based on a blanket sales order to build stock so you can serve customer’s purchase orders with no or low lead time
  • Pending Report: create two reports, one for the blanket purchase order and one for the blanket sales order to quickly give an overview what is still pending (open to be sold or purchased to fulfill the contract). Maybe combine this with a release report which shows what has been delivered and when.

Now I consider this a clear open source contribution rather than something we customize for ourselves. I would like to start this discussion to implement this right and to meet the demands from the community.


  1. Are Blanket Purchase Order and Blanket Sales Order their own DocType or should this be a change in Sales Order and Purchase Order in which case they will reference themselves? I think it makes much more sense to have this be it’s own thing. This is also how it is done in SAP, Navision, etc.
  2. How do we create a Blanket Order from a Quotation and how do we indicate in a quotation that it is a quotation for the blanket order? The batch size should also be in the quotation.

MS Dynamics has a blanket order just as a type Finance and operations application documentation - Finance & Operations | Dynamics 365 | Microsoft Learn

If it has to be its own type, IMO we should call it “Purchase Agreement”, seems like a more mainstream name than blanket order (which seems like a ERPish term)

It would be very similar to how Subscription is setup in the v9 (merged in develop)

I didn’t check how Dynamics do it, I was thinking Dynamics NAV 2009. For me it doesn’t matter if we make it a type or a new doctype as long as it works.

The Wikipedia article calls it “Blanket Order”, that is the only way I have ever heard it referred to in the business world. I think brits sometimes call it “Frame Order” which seems weird. It would have to be called “Purchase Agreement” and “Sales Agreement” which would be ERPNext specific naming. I would call it “Blanket Order”.

Funnily I never came across Blanket Order. I guess another option is “Standing Order”

Standing Order is a banking term Standing order (banking) - Wikipedia. I don’t undersand why we spend time for the the name @dominik privided (with wikipedia link and clear business term) and don’t comment on the core of the issue itself

1 Like

I agree on naming is hard thing in some cases, but in this case wikipedia is the naming source …so no to much to think of …imho

1 Like

There are some terms that are a left-over from old ERPs that are not familiar with people not using ERP systems. “Purchase Receipt” used to be called “Goods Receipt Note” (GRN) but Purchase Receipt sounds more modern and I am happy we made that switch. I would also like to rename “Delivery Note” → “Fulfilment” but then it would be trouble for a lot of customisations. So its best to debate naming before we jump into any commitment.

I would go with “Purchase Agreement” but then we also need a “Sales Agreement” which would be the same thing.

I am ok with Blanket Order too, its just that before we make such a call, we should debate all the options. Personally I have never heard the term Blanket Order before. To someone new, it might sound like someone needs to order some blankets! Lets not directly jump on this and sleep over this for a day or so. I am okay with what is best.


In SAP terminology, it is called Scheduling Agreement. Scheduling agreement can have multiple items. Scheduling agreement is used for Bulk Qty commitment to supplier and delivery is controlled using schedule Lines for the items (Daily, weekly, monthly etc). It is used mainly for Direct materials (which goes with finished product).


For Example - Scheduling agreement is similar to Purchase order but we can give item delivery schedule in SA which is not the case in PO. This functionality is used for controlling delivery of items to avoid inventory cost or for “Just in time” Inventory management.


It seems like a scheduling agreement would be something else again like you said it would determine an actual schedule of when things get delivered while a blanket order generally, at least how I have seen it, doesn’t determine a schedule only total quantity, batch size and total runtime.

I don’t think that a scheduling agr event would be helpful to most ERPNext customers. You could just create sales or purchase orders for it within a blanket oder.

We will do the implementation based on what we have described in the original post and we will call it “Blanket Sales Order” and “Blanket Purchase Order”. These will be copies of Sales Order and Purchase Order that we change around to meet our requirements and allow them to reference each other.

We will keep you posted, meanwhile if there are any suggestions about this please share.

I’ll recommend re-use and extend SO and PO and add types instead of two more doctypes.

If controllers erpnext/erpnext/controllers at develop · frappe/erpnext · GitHub are used, most of the fields will repeat in both orders.


OK, a decision has to be made here that is crucial:

  1. Copy DocTypes and change them to our requirement
  2. Add type to existing DocTypes and trigger different fields based on type

Assuming most of the fields are the same, in my opinion, option two makes more sense.

If there is significant divergence in fields, then option one makes more sense.


The goal of the blanket order is to have a fixed price order over a period of time or upto a certain quantity

A quick way of doing this would be to extend Item Price to have an expiry and also link it to a customer. This way we don’t have to update anything.

For each blanket order, just create a price list with expiry and party linked, then use it in your purchase order / sales order.

All other options will require either duplicating functionality or hacking deep into the core features and reports to make sure it works smooth.

Edit: In the Bengaluru meetup, we hacked up a Restaurant management system. There is a concept called a “Restaurant Menu” which is very similar to a blanket order. The way I implemented it was to create Item Price in the background and the rest of the functionality worked very well. Will be sending in a pull soon on this. We can use the same features for blanket order.


Some thoughts:

I think the functionality required is more like Contract that governs dispatch of goods (either from a Supplier via multiple POs or to a Customer via multiple SOs) based on pre-defined Contract that includes variants of price & quantity. The contract governs & controls the quantity & price both for a certain period of time.

Item price is an option, but may miss controlling quantity till which the price applies & may also not be adequate to capture any legal terms that a contract may have.

Those are features we need to add.

All “Price List” needs is a link to the terms master. I think it makes sense to have prices linked to specific terms.


I can tell , how we have solved this:
we call it a ‘Frame order’ (an order for a complete year) and then accordingly ‘Call-off Orders’ (partial orders based on the Frame order).
We have just introduced several different Naming series, like ‘FRAPO-’ and ‘CLFPO-’ it makes it easy to distinguish and filter from regular POs.
The only missing thing is that you need to track manually and each time calculate, how many peaces you still need to order and when your Frame Order is finished. But otherwise, it works just fine.

1 Like

@Evaldas_Pabreza you have customized a solution that partially works. It mostly works in the legal sense that you can confirm your customer the legal agreement. It does however as you have pointed out miss a lot of critical functions:

  • No notification when blanket order is overdue
  • No tracking of open and purchased quantities
  • No setting of delivery address, payment terms etc. for the “call-off orders”
  • No determination of the price for the “call-off orders”
  • No formal 1-1 relationship between blanket and order
  • No tracking of what blanket orders exist for an item in the dashboard

Regarding naming:

“Frame Order” seems to be another word used (Google has 189k hits) for “Blanket Order” (Google has 174k hits). The more commonly term that I have come across is blanket order.

Using price list is not solving the requirement. A blanket order is a legal agreement that determines much more than a price and requires tracking. While the price list should definitely include functionality to set the price for a blanket order item it does not replace creating the functionality of the blanket order.