The Purchase Requisition is an internal document to request to purchasing to procure some products.
It is composed of the employee requesting, a delivery date, an internal code and of course a list of products with quantity and description (we could also add an estimation price for information).
It needs to have a work-flow with those states: draft, waiting, processing, purchased and cancelled.
There will be a special group for approbation right that will allow to create via a button an approbation record. A configuration will define when the waiting requisition can go to the state processing.
At the processing state, the requisition will create “Purchase Request” for each line.
We need more functionalities on the purchase requisition document :
- Employee requesting can specify a Party or not
- Preferential if the requester know the supplier that meet the needs.
- If the requester has a reference supplier (quote or project) the party is mandatory. Example : an engineer is negotiating the creation of a new machine and request an offer with service and equipment (inseparable). This request is made directly (without purchase department) because very technical.
- Currency is on the document (not only on the line) because the purchase order is not multi-currency. Only mandatory if the requester provide price on product lines.
- Description mandatory on purchase requisition document to provide a way to retrieve easily the requisition because the party is not mandatory (only requester and date on the header)
After the workflow transition “approval” the purchase requisition lines create purchase request lines with an origin.
The state of purchase requisition lines will be a function fields on the state of purchase requisition until processing and purchased state depending on the creation of purchase order (by module purchase request).
Some fields from purchase requisition (currency, supplier reference) will introduce some constraints for the selection of lines in purchase request module.
- purchase request lines are not ‘splittable’ : we cannot select purchase request with different currency for a Purchase order.
- purchase request lines should stay together : when there is a reference supplier → all the lines of purchase requisition must be computed together.
In this case, I don’t see the point to use “Purchase Requisition” is the purchase department is skipped. The user could directly create a purchase order (maybe without validation right).
I don’t agree. The requested product could be from different suppliers with different currencies.
So limiting on the document is a big drawback in the design.
We don’t put required on field in base if it is not strictly needed to work.
I don’t think it is needed because we will have a link between the line and the “Purchase Request” so user could follow the state of the “Purchase Request”. Also I think the link could be later extended to create more than one “Purchase Request” (for example: composed product), so a unique state will be difficult to compute.
We modified the documents incorporating the remarks of talking. We are now on a more generic model.
remove : supplier reference -> party mandatory.
remove : inseparable purchase requisition line
move the currency on the purcahse requision line
remove : mandatory on description
remove : state and workflow on purchase requision line
For the state int the workflow, what do you think of this :
Draft (first step)
Waiting (send the purchase requisition to approval - waiting response)
Rejected (purchase requisition rejected)
Approved (purchase requision approved -> create purchase request line for each purchase requisition line)
Cancelled (purcahse requistion cancelled)
Done (purchase requisistion is terminated -> done)
Do you think I must add a Processing state beteween approved and done ?
The done state is set manually by the requester to archive the purchase requisition.
I guess it is better to name the field “supplier”.
I think they are good.
No I don’t think it is needed because it is for internal usage.
I don’t think it is needed as far as we sort by date.
About the work-flow, I think there is a mistake “cancelled” should only be available from “draft”.
New issue for a proposal: Issue 5657: Proposal of a new module : Purchase Requisition - Tryton issue tracker
After a video call, we agreed that approved should not be a state. But instead the approbation should be done using a button that will create a record on a list of approbations of the requisition.
There will be a configuration using MatchMixin that will define when the requisition can be processed by defining the number of approbation per group of user.
After IRC chat, we agreed to remove purchase_request state according a purchase_requisition could be linked to more than one purchase_request (in case of quantity are modified, another purchase_request is created with the remaining quantity) and there’s a relate to purchase_request so it’s easy to track state of each request rather than defining an new state in case of multiple purchase_requests with differents states.