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 ?)
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.
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?
You could use a Function field.
In case of cancelling a purchase order linked to a purchase request and a RFQ, what about the RFQ state ? Keep unchanged ?
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.
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?)
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.
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
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 ?
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.
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 ?
I think so. But I still think the wizard should warn about such situation.
Ok. So a warning when calling wizard on purchase_request with ‘quotation’ state, or it should be when we process the wizard and we had to search for existing lines with same request and supplier after the cartesian product?
What would be the warning message? 'Be careful, you already made a quotation with one of the selected requests !"?
I think we can simply rely on the state.
Yes with the rec_name of the request (and probably without the “Be careful” because there will already have the warning icon).
With this module, purchase_request module needs to get data from the best quotation (first line with state answered) to create a purchase (wizard). So i’m redefining _group_purchase_line_key and _group_purchase_key to get data from the quotation.
For each method _group, i need to search for existing quotations with state answered and getting data from the first result (sequence ordered).
So, is it better to define a new function field on the request that would be “best_quotation” or this kind of field is unnecessary and i keep checking for best quotation each time wizard create_purchase is launched ?
I do not think it is needed to have a Function field, the cache will not be so much useful.
But you could use a property that do not make a search but just a loop on the quotations and return the first valid.
This topic was automatically closed after 14 days. New replies are no longer allowed.
