Community mailing list archives

community@mail.odoo.com

Re: Purchase Requisition Process

by
Eficent Business and IT Consulting Services, S.L.
- 05/11/2015 21:01:30

Eric is right. Quite a change... but much needed! I will look into the problem that you point out and give you further feedback.

My initial assumption was that the materials fro different PR's would always require to be sent to the same Warehouse.

In SAP the destination address has been at item level.. since I was a toddler.

In fact with purchase_amendement also you are starting the path to move the purchase business process to the item level, which is the right thing to do.

Regards,
Jordi.

El dia 12/05/2015 2:28, "Caudal Eric" <caudaleric@gmail.com> va escriure:
You will have to push the warehouse/destination location to the POL which is quite a change in the standard PO logic.

2015-05-12 0:34 GMT+08:00 Joël Grand-Guillaume <joel.grandguillaume@camptocamp.com>:
Hi Jordi,


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.

Looking forward to hear from you !

Regards,

Joël



On Fri, May 8, 2015 at 4:33 PM, Jordi Ballester Alomar <jordi.ballester@eficent.com> wrote:
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".
4b. - When PR "C" changes to status "PO created", the related PR's also change to "PO created".

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!!

Regards,
Jordi.

On Fri, May 8, 2015 at 2:26 PM, Joël Grand-Guillaume <joel.grandguillaume@camptocamp.com> wrote:
Dear Jodri,


There is I think something that may interest you, but that's a whole lot of module made for NGO's (the big project I'm working on for 2 years now).

You can find them here : https://github.com/OCA/vertical-ngo

Also another interesting module is for better CBA process (which I'm not sure it is what oyu want, but still interesting) : https://github.com/OCA/purchase-workflow/tree/8.0/purchase_requisition_bid_selection

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.

Best regards,

Joël











On Fri, May 8, 2015 at 9:47 AM, Jordi Ballester Alomar <jordi.ballester@eficent.com> wrote:
Hello Community,

I'm in need of Purchase Requisition process as Wikipedia defines it (http://en.wikipedia.org/wiki/Purchase_requisition). 

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.


Regards,
Jordi.

--

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe




--


camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Joël Grand-Guillaume
Division Manager
Business Solutions

+41 21 619 10 28


_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe




--

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe




--


camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Joël Grand-Guillaume
Division Manager
Business Solutions

+41 21 619 10 28


_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe




--
Eric CAUDAL
+86 186 21 36 16 70

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe