Request for Quotation to Many Suppliers

Feature
1

Continuing the discussion from Pending State on Purchase Requests:

The idea is to be able to create a new document “Request for Quotation” per product from a list of “Purchase Requests”.

This RFQ will have a One2Many which will store the request to each supplier. Those lines will contains the “Unit Price” per UOM to fill when the supplier answer and an optional “Lead Time”.

The “Purchase Request” will have a link to the RFQ which will prevent it to be deleted by the re-computation. This link will change the state of the request to “Quotation”.
Also this link will allow to put the selected “Supplier” to the linked “Purchase Requests”. The “Unit Price” and the “Lead Time” could also be re-used as default value for the “Purchase”.

I think also that we could have a view of all the lines that could be filtered by supplier to ease the encoding of the answers and to generate the request to send to the supplier.
A similar design as the payment group will be applied to group the lines requested to the same supplier inside one document (Report).

One way to select the supplier out of the RFQ could be simply by using the first line which will be ordered by the user (using DnD).

To create the lines for a selection of supplier, I think we could use the Cartesian product attribute on the One2Many.

2

Here, at Saluc SA, we are very interested in such development.

First of all, we are beginners with this new way to develop with a community. And then, it’s not so easy to write down our ideas and explain them in english but we’ll try to do our best.

We suggest a more general proposal.

We thought a 'Multi-Vendor RFQ “ document that would generate multiple RFQ document in order to group several RFQ with a common reference to the Multi-Vendor RFQ id.
Multi-Vendor RFQ, is an entity where you select one or more suppliers (Multi-Vendor RFQ Party), select one or more products (price, quantity, uom, description), payment conditions, shipping instructions, currency …

  • RFQ should not only be created by the module “Purchase Requests”. Purchase department should be able to create “Multi Vendor RFQ” manually (not only lines from purchase request). Also we can select one or more lines in Purchase Request module to generate a “Multi-Vendor RFQ” in state draft.
  • RFQ should be for multiple products (especially if we are working with a Purchase Requisition module who generate Purchase requests): we could ask in a purchase requisition for products that must be ordered together, so each RFQ sent to suppliers should have multiple lines of products. (considering the original Purchase Requisition created by user is conceivable : you don’t order printer toner with toilet paper, but you can ask for two hard drives and one keyboard…
  • The RFQ must include the conditions of payment and shipping because it is very important for the quotation and choice of supplier.
  • The purchase order is not multi-currency, so we don’t use multi product line with different currency in the same ‘Mutli vendor RFQ’.
  • We need to track the state of “Multi Vendor RFQ” (processing of the request) but also the state of each RFQ generated by this “Multi Vendor RFQ” (track all response of suppliers)
  • We need to keep the answer of all RFQ supplier. A supplier could submit another quantity, unity or price.

RFQ’s are generated by this “Multi-Vendor RFQ” module: an RFQ document
by supplier with a Many2Many field between the ‘Multi Vendor RFQ’ lines
and the RFQ lines.

Each RFQ is sent to supplier (printing, email,…) then we are waiting for the answer. When we received an answer, we write reception date, price, quantity, uom in the RFQ
Then we choose which RFQ is/are the best and we generate a purchase order('s) with informations provided by the supplier. Others RFQ are cancelled (manually).

Workflow Multi-Vendor RFQ: Draft, Processing, Done, Cancelled

With the transition ‘processed’ between state Draft and Processingn we thought create a RFQ by supplier (cartesian product of MultiVendor RFQ lines and party selected on MultiVendor RFQ).

Workflow RFQ: Draft, Send, Received, Ordered, Cancelled.

workflow_multi-vendor-request-for-quotation-v1.jpg843×1199 61.5 KB

multivendor_request_for_quotation_v1.jpg1245×1629 158 KB

3

I don’t think this is needed. At best, we could group the “RFQ lines” of the same supplier with a reference group (like the payment group). I don’t think it is really needed to get a unique reference for “RFQ lines” of different supplier because the important information is to be able to link the supplier answer to the right line.

I don’t think it is right because what will be done of the result if there is no “Purchase Request” to store the selected supplier. For me the “Purchase Request” is the place where everything should go.

I don’t think it provides a real advantage and I think working per line gives more flexibility. But of course it would be possible to create wizard to create the RFQ lines for a list of RFQ instead of going RFQ per RFQ.

I agree for “lead time”. But others, I think this is special case because Tryton doesn’t manage supplier payment term per product by default.

I don’t think it should be a state but with a reference group, we will know if it was requested and once there is a price set, we know it was answered. I would not go for a workflow with state because many will never get answers and so they will not reach the ending state.

I guess user will keep the lowest and in case one could activate the history on it if he wants. But I think it is a little bit bloated for the standard.

4

Here’s a new schema based on previous remarks for RFQ:

RFQ-DATA-MODEL.jpeg1024×782 77 KB

5

I propose to use the state “Answered” instead of “Done” for RFQ (and “sent”).
RFQLines could be simply RFQ.
I think the “Selected Function” fields should select the first RFQ in the state “Answered”. Maybe this fields are not required if we show the RFQ in a One2Many (we could use Python property for developers).
The RFQ Group should have a workflow and it should have the state instead of the RFQ.

6

We suggest those states on RFQ Group : DRAFT (initial), SENT(prevent to forget to send an RFQ (could be triggered when printing RFQ ?)), ANSWERED (Manual action , the lines with price from this RFQ could be selected to generate the purchase_order from the purchase_request), DONE (process will switch state when all the purchase_requests linked to the products in the RFQ have a purchase_order in state “Confirmed”, this state will permit to limit the number of “active” RFQ) and CANCEL (error when selecting supplier or another reason).
Can we apply a sequence on a One2Many ? (to sort the best line following our criteria (best price is not always a choice, we sometimes prefer to order all the products to the same supplier (even if the price is not the best for one product) ?

workflow_multi-vendor-request-for-quotation-v2.png1630×1392 82.4 KB

7

I do not think it is needed to have such state. ‘answered’ is a good enough ending state. Because once a RFQ is answered the user has nothing to do any more with it.

Yes it should be ordered by sequence because the criteria can be complex like the delivery delay, the general condition etc.

8

but some RFQ will never reach the “Answered” state (some suppliers will not reply to RFQ, or purchase department will not spend time to encode some RFQ answers because they think it’s not a valuable offer and a waste of time to encode ?) So the Done state would “clean” those pending RFQ.

“General condition” (and other conditions maybe ?) are usually applied on the whole RFQ, how will it be copied on the line for the one2many selection (function field ?)

9

You have the cancelled state for that which is more accurate because it will not be taken as the user did not fill the answers.

I do not think “Genral condition” should be encoded or simply with a free text field.
I do not think it needs to be copied and so on. I use it as an example of why the best RFQ is not necessary the cheapest.

10

My question is: Let’s imagine that we have a field ‘Payment Conditions’ on the RFQ Group. (it could be specific development). When the user will choose the best product line, he needs to know this information to do the best choice, so how will it be displayed on the lines of the one2many?

11

You could use a Function field.

12

In case of cancelling a purchase order linked to a purchase request and a RFQ, what about the RFQ state ? Keep unchanged ?

13

I think once the RFQ has been used by the purchase request, we can just forget about it.
But there is one case where the user will want to manage the exception at the request level and maybe he will want to change the priority of the RFQ’s but this is already supported by the design except that he should be allowed to change an answered RFQ into cancelled and vis-versa.

14

So Cancel state can go back to any other state (draft, sent, answered) with erasing previous values ?

Another question, RFQ will always be generated through Purchase Requests ? (or we should plan a “manual” RFQ ?)

And what about Quotation in the purchase order ? (purchase department will pass this step in case of RFQ?)

15

After more thoughts, I think we should have a state “Rejected” so the transitions will be:

draft → sent
draft → cancelled
sent → answered
sent → rejected
answered → rejected
rejected → answered

The fields should always be editable (it is not really sensitive data) for any state.

For me, yes it should. The request is the central point.

As they want because the answers from the RFQ could be different than the real quotation. For example because time has passed, the quantities are different or the sets of products is different etc.

16

New Workflow:

workflow_multi-vendor-request-for-quotation-v3.png1228×1050 53.3 KB

17

After discussion on IRC:

How naming this new module? RFQ or request_for_quotation ?
CEDK: I said purchase_request_for_quotation
And the name of .py file ?
CEDK: purchase.py

CEDK: we could forget the “for” so module name could be “purchase_request_quotation”
CEDK: model name: purchase.request.quotation
CEDK: class name: PurchaseRequestQuotation

18

Purchase Request will have a new state “Quotation” : if purchase_request is in “draft” state and has quotations then state will be “Quotation”.
Can we call again the wizard to generate quotations when the purchase_request is in the state “Quotation” ?
In this case, what if we select a supplier and there’s already a quotation with this supplier ?

19

I think in this case, the user can just create manually the missing request for quotation.

I think the wizard should not care but by default it should raise a warning if it is run on a quoted request.

20

What do you mean ?

Previously you said :

So after reflexion, i allowed to create another quotation even if there’s already quotation because it could be associated with another purchase_request and this is a new RFQ group:

Purchase Request 1, Purchase Request 2 with suppliers A and B will generate 4 lines of quotation (cartesian product):
PR1-A
PR1-B
PR2-A
PR2-B

Those four lines will be grouped by supplier to become RFQ : RFQ 1 (PR1-A,PR2-A) and RFQ 2 (PR1-B,PR2-B)
My purchase requests PR1 and PR2 are now in state ‘Quotation’

Let’s imagine another Purchase Request PR3 and we select also PR1 (which is already in state ‘quotation’) , we choose supplier A and C, so we’ll get also 4 lines:

PR1-A
PR3-A
PR1-C
PR1-C

PR1-A : could be considered as a duplicate line but it will be grouped with another line to generate 2 new RFQ : RFQ 3 (PR1-A, PR3-A) and RFQ 4 (PR1-C, PR3-C).

So for me, selecting twice the same purchase_request with the same supplier is not a problem…
Is my reasoning correct ?