Managing Blanket Orders Sales and Purchase

[tbruyere (Thierry Bruyere)]

@ced

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 agree with this remark, I had not thought of the concept of access rights by model.

[tbruyere (Thierry Bruyere)]

@ced

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

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.

[tbruyere (Thierry Bruyere)]

@ced

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

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?

[pokoli (Sergi Almacellas Abellana)]

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

@tbruyere

• Quotation
• Opened
• Closed

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

@tbruyere

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.

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

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.

[ced (Cédric Krier)]

@tbruyere

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.

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

@tbruyere

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?

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.

@pokoli

Quotation → Negotiating

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

@pokoli

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.

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

[lars_wuerfel]

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.

[ced (Cédric Krier)]

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.

[lars_wuerfel]

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.

[ced (Cédric Krier)]

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.

[tbruyere (Thierry Bruyere)]

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?

[ced (Cédric Krier)]

@tbruyere

Create an “origin” reference field on the Sale / Purchase line to extend the concept of the origin of a line?

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.

[tbruyere (Thierry Bruyere)]

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?

[ced (Cédric Krier)]

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.

[coogor]

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

[vincent (Vincent Bastos)]

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

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

[lars_wuerfel]

@ced

I’m still in favor of a simple module first. […]

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

[lars_wuerfel]

@tbruyere

A “Blanket Orders” Sale or Purchase must have :

• Company
• Blanket Order Number : A unique number with a sequence
• Party […]

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.

[ced (Cédric Krier)]

@lars_wuerfel

For Sale, the Blanket Order Number comes from the customer. So it must be editable, and - if uniqe - then unique per customer.

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.

[lars_wuerfel]

@ced

@lars_wuerfel

For Sale, the Blanket Order Number comes from the customer. So it must be editable, and - if uniqe - then unique per customer.

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

Ah, then this is the (Trytoin internal) ID.
Then we need an additional field “customer’s Blanket Order Number” which contains the number (or string) the customer gives for this Blanket Order, and which has to be printed on the documents, resp. transmitted in the EDI message.

[ced (Cédric Krier)]

It is not the ID, I’m talking about number.
Anyway this is very minor detail that has no point to be discussed here as long as nobody is actually implementing it and have proposed a review.

In general when discussion on blueprint starts to talk about such detail, I just leave it (like Association blueprint). The blueprint is about discussing the general idea.