Re: Purchase Requisition Process

by

Camptocamp SA, Joël Grand-Guillaume

- 05/12/2015 07:45:50

Thanks for sharing !

In my understanding, the PR in SAP is kind of "Need record", a date when it's needed and where. That is the procurement in Odo. The type of PR is in fact the route and the procurement rule linked to it. As they define it :

"

You use this component if you wish to give
notification of requirements of materials and/or external services and
keep track of such requirements.

Requisitions can be created either directly or indirectly.

“Directly” means that someone from the
requesting department enters a purchase requisition manually. The person
creating the requisition determines what and how much to order, and the
delivery date.

“Indirectly” means that the purchase requisition is initiated via another SAP component.

"

It clearly correspond to the procurement object in Odoo. I think we should start thinking with that in mind IMO. Would we start a draft google docs for this ? May be we can also talk about that during the OCA code sprint in June ?

But IMHO a Call for Bids is a purely purchasing function that responds to a strategic decision made by the purchasing department to group a certain number of requests for material and/or services, in a package that they send out to suppliers requesting for a quote. This package or Bid is result of a decision made by the Purchasing user.

IMHO the process of Call for Bids is being used incorrectly in Odoo. Think of the way the MRP now creates Calls for Bids from Procurement Orders. 1 Call for Bid for each Procurement Order. If you have 10 manufacturing orders, it creates 10 Bids for the exact same product. Nonsense, because the purchasing department may want to group these 10 requests for the product into a single Bid that they send out.

Now, perhaps the correct thing to do would be to use your logistic requisition, that can be initiated by an individual, or by the MRP scheduler, if the product has an attribute "Create Logistic Requisition" = True (same as with the currently used in Call for Bids, but this time is correctly used).

Then using your Logistic Requisition, Purchasing department can group lines of Logistic Requisitions into a Call for Bids, a Purchase Order or even Stock Transfers. So it is the function of Purchasing to determine how to fulfill each individual item requested in a Logistic Requisition.

I can see that the requirement that you now have for 1 Logistic Requisition : 1 Call for Bids is just a specific scenario for a particular business case, for example, in NGO's.

What do you think? Perhaps starting with isolating the Logistic Requisition into its minimal expression (minimum dependencies) could start to define a very strong process, that can later be used in different business contexts.

1) Look if an existing PR exists for the given WH, if yes, it'll add the quantity there (the same than your module you backported in v7)

2) If no PR exists, create one

That way, using this route will automatically grouped PR that make sense together. We can put some hooks in the proper place so everyone will be free to define their own business rules to know how to grouped and so on. This first module will provide a new procurement rules and method to add needs in an existing PR ar create one.

The modules that Joël is working on would capture a material request by an employee, irrespective of how will it be fulfuilled afterwards. The solution looks to me more oriented towards the sale, organizing the procurement flow before the sale one is triggered.

What I was looking for was to extend Purchase Requisitions to manage internal purchase request made by various people within the company, which is a more simple scenario.

My use cases are:

- Direct procurement: project managers that need material to complete their project. This material has not been explicitly identified in any sales order.
- Indirect procurement: employees asking for office supplies.

I'll need this feature too, that's why I'm seeing how we can work together here. Currently, the blocking point I'm facing is that a PO can only have one delivery address and may be your PR A and PR B have different !

Any idea how to handle that ? Did you already think about it ?

In any case, your approach sounds goods because then it is generic enough to be used also with the logistic_requisition module.

Thanks Joël for the feedback. But I have the feeling that "logistic_requisition" is prepared to fulfill a much more complex scenario. But I'm looking more closely at it now.

In my scenario the basic assumption is that users raise requisitions, and a centralized purchasing department can then decide to raise a PO to fulfill multiple requisitions. I am looking at your project, and it looks like a call for bids cannot be linked to likes of different logistics requisitions. This, in my opinion, would break my essential requirement.

My proposal would be as follows. In my opinion is simple, and would not break anything that exists now. (Note: instead of "Call for Bid" i will refer to a Purchase Requisition or "PR")

Basic workflow:

1. - User "1" creates a PR "A" and confirms it,

2. - User "2" creates a PR "B" and confirms it.

3. - Purchasing department reviews the requisitions and decides to create a new PR "C", and import the lines from PR's "A" and "B". Then confirms the PR.

* From PR "A" and "B" you can see, for each line, that is going to be sourced by "C".

* PR "A" and "B" change to state "Waiting for another Requisition". Nothing can be done in this state in "A" or "B".

4a. - If PR "C" is cancelled, PR "A" and "B" change to the previous state "Confirmed".

In order to handle more complex scenarios where some of the lines could not be procured, a status of the purchase requisition line would be needed, so that the requisitioner can get to know for which lines was the PO created.

This would allow, for example, that the purchasing department can create Bids that group individual requirements created by users or the MRP scheduler.

Look, for instance, at the MRP process creating automatically 50 bids for the same product, out of 50 different manufacturing orders. But the purchasing department just wants to issue 1 PO to the supplier!!

In the vertical NGO addons, you'll need to install the logistic_requisition and his dependencies. It's a set of module where you can:

* Record request from requester called "Logistic Requisition" (for need of services, product or whatever).

* Source them with various way : On Stock, On framework agreement, On Tender

* Once source, you create a draft SO (cost estimate) to submit to the requester for approval

* If accepted, the sourcing done above will be trigged and the required document will be generated (PO based on FA, PO based on Framework agreement, Warehouse dispatch,..)

It's a very short summary of what we've done (as it's a huge project), but I think it really cover the use case you described.

Let me know, but I think I may have to show you those modules to have a better explanation. I don't know if they can fit your needs, but I have the feeling that it may work perfectly. If not, I'm really interested in developing a module compatible with "purchase_requisition_bid_selection" in any case, so I can even imagine contributing financially in order to achieve that. Please let me know.

What I'm finding is that the current "purchase_requisition" module is more oriented towards organizing a bid for a predefined set of products. 1 Bid translate to 1:N PO's.

But what I'm looking for is a model where users can request the procurement of materials or services to the purchasing department, and this department can then decide to group various Requisitions to initiate a single purchase (or even a bid that would complete a number of user requisitions).

That is, a model where N Purchase Requisitions can translate to 1:M Purchase Orders.

Before we start the work to develop the modules to fulfill this need, I'd like to double check with others to see if there's consensus about the Purchase Requsition process.