Community mailing list archives
Re: Purchase Requisition Processby
On 12 May 2015, at 21:22, Ana Juaristi <email@example.com> wrote:Hi Everybody:I'm going to try to sumarize the problems using standard Odoo procurement tools that are working right on basis but user completly looses control about them.On the other side I will try to explain what we did in OdooMRP after several "plan" versions and attempts. Pedro and me expended a lot of hours with our OdooMRP customers in order to try to fix standar functionality and try to extend it a little bit giving much more control to user about what he/she want to do.1. One of the biggest standar modules issue is that even if you don't install just in time, most of processes are executing the procurement so fordward objects are created without any control. Let's say rutes MTO, minimum stock calculate proccess, automaticatically generated MO confirming and so on. Once the object is created or procurement need included in Po or Mo control and visibility is lost for user.So.. first of all we cutted the execution of procurements that now are always created "confirmed" status, so user can have real vision of what is needed before creating or executing anythingtry procurement_orderpoint_no_confirm and procurement_mrp_no confirmEvidently this modules are not compatible with jit module2. Procurements have got a "complex" workflow where they can be confirmed, exception, running and done wich is rightConfirming one procurement if something is wrong will go to exception. Let's say supplier not found or BOM not found. At this point you can go to procurement, solve the problem and try to execute again but...other procurements having same problem will not be re-executed. There is no way to launch this execution for all procurements together but just doing one by one. Nosense for user point of view.Same issue happens when you need to cancel or to confirm several procurements once.To solve this issue we made procurement_managerWe added some actions on procurement object where you can select several of them and execute the action you need for all together.3. As said by Eva, "running" estatus is "hidden" status. Noone know if a PO or MO has been created or what happened. Very complex to explain to user.We improved a little bit procurements tree view to show directly the PO or MO created from procurement, we also show the "rule" on tree since we can see in one single view if it's to buy or manufacture and maybe we could also show PO/MO status to see directly on procurement one step fordward what is happening there.4. At the end... we have built our procurement_plan_mrp (recently name changed) https://github.com/odoomrp/odoomrp-wip/pull/799If you are interested I can make an small video showing how it works and I will upload to our youtube channel when we make the merge to wip branch. But...meantime here it is:Plan is a new object where we could "group" procurements and act with them making whatever we need.Plan includes one2many procurements and show on header all "actions" that can be executed for individual procurements.Plan header includes start date- end date, serial number and name to be identified.Header also includes a button "import procurements". Pushing the button will import all procurements wich data is between header start-end date.We also included a shorcut to navigate to procurementes included in one plan just to be able to group by product/location/rule or whatever you need to control or see.Plan is shown on standar procurements tree view in order to see if it's been treated by now into a plan or it is not.5. Standar Manufacturing material procurement is a nighmare since it's needed confirming any manufacturing order to create material stock moves that create procurements. If someone cancels a production order... there is no automated way of cancelling all needed structure at once. Orders, moves, procurements... and so on.On the other side if Technical office needs to change something on defined BOMs for longtime manufacturing with several levels... nighmare becames double so... we decided using our plan module Version 24.334 (Joke) to solve part of this problems...First of all we included a concept "level" on procurements. By default all procurements will be created by system on level 0We included a button "generate procurements" that explodes all procurements included on plan in all BOM levels. Evidently procurements level zero, having manufacturing "rule" and existing BOM. Errors will be saved on plan chatter so it should be solved by user.When user decides to execute each procurement MO and PO will be created standar way but... we can choose creating POs BEFORE MOs, just selecting the ones with rule "to_buy" and pushing execute so we are avoiding cancelling MOs, stock moves and so on.We can choose to launch/confirm the MO in precise moment when manufacturing is going to start. If procurement of materials went right, they will be in house by now so for materials under stock, no problem.For materials MTO, we have got a TO-DO here because we would need MTO-MTS rule here. Just to supply that we could mark all materials MTS with 0-0 rule, so... no very big problem here by the moment (we will see on future)About exploding bom on plan, we can explode a single level or full treeWe could also erase a branch of procurements since they will have parent_id (procurement level 1 is child of procurement level 0)6. At the end we will merge plan module with our MPS module where we are able to create procurements importing old sales or purchases from one period. We will include both buttons directly on procurement plan, integrating both in a single one.I think with our aproach where maybe Version 24.335 or further ones will be still needed but step by step we are solving most of control problems about procurementsOne BIG TO DO is controlling procurement datas and make minimum stock rules by period. With those both things I thing we could have a really strong automatic procurement and stock planning system.As always, any comment is wellcome and for sure an sprint code on odooexperience (formerly opendays) would be very interesting.Pedro and me will arrive tuesday at midday (11-12 more or less)Thank you!!!Ana2015-05-12 18:40 GMT+02:00 Jordi Ballester Alomar <firstname.lastname@example.org>:@Joël, We got interesting ideas to improve the Procurement to Tender process.And I agree with Eva, that internal purchase requests made by internal users deserve it's own separate process, connected with Call for Bids and/or Purchase. Making the Procurement Orders used by end users can be tricky and requires a specific material to be entered.Regards,Jordi.Regards,Jordi.On Tue, May 12, 2015 at 4:20 PM, Joël Grand-Guillaume <email@example.com> wrote:I think both work are complementary, I am wrong ?b) Have a was to group various needs in a same purchase requisition (or Tender) so the procurement team in the company can find the best suited supplier for the required material or services.a) Plan the procurement as your module probably do@Jordi: Great ! The system can even provide a method "_find_pr" that will try to find the proper PR to include the new need in (instead of letting the user choose?).@Perdo: That looks promising to planify the procurement in term of volumes. May be I don't understand it well, but it seems to me we have to different needs here:On Tue, May 12, 2015 at 2:02 PM, Jordi Ballester Alomar <firstname.lastname@example.org> wrote:Hmm.. agreed this is the way to go!In order to prevent the system creating 1 Call for Bids for each Procurement Order, the user could indicate an existing Call for Bids in the Procurement Order, and when the scheduler is run it would add an extra line or +1 to quantity of that Call for Bid, as you suggested. That will be a good improvement to the existing solution already.Additionally, security rules should also prevent users from listing / executing Procurement Orders that belong to others, but Purchasing department should have access to all the Procurement Orders.I will put together a Google Docs then.Thanks for the good feedback!Jordi.JoëlRegards,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 ?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."At least this is how SAP handles the Purchase Requisition process. And makes sense to me:http://help.sap.com/saphelp_erp60_sp/helpdata/en/5e/7eb65334e6b54ce10000000a174cb4/content.htm?frameset=/en/52/7eb65334e6b54ce10000000a174cb4/frameset.htm¤t_toc=/en/32/81b65334e6b54ce10000000a174cb4/plain.htm&node_id=41&show_children=falseRegards,Jordi._______________________________________________Hi Joël,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.Regards,Jordi.JoëlRegards,That would be a first stone.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.2) If no PR exists, create one1) 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)This new route will :What about the person wanting to make a PR create in fact a procurement in Odoo for the concerned warehouse, and put new create Route "Grouped PR" (like I suggested to do for this module : https://github.com/OCA/stock-logistics-warehouse/pull/47).Hi jordi,Just an idea, but may be interesting:
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.
Would you be you are interested to fulfill this same requirement?
Looking at the community threads, I can see that internal stock requests can also be fulfilled with this module:
I have not evaulated stock_indent yet.
This feature is something I am seeking as well. I am willing to contribute funding to help the development.
I was thinking on using the stock management module to request the move and based on availability a draft would be generated.JoëlRegards,Looking forward to hear from you !In any case, your approach sounds goods because then it is generic enough to be used also with the logistic_requisition module.Any idea how to handle that ? Did you already think about it ?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 !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.JoëlBest regards,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.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.* 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,..)* Once source, you create a draft SO (cost estimate) to submit to the requester for approval* Source them with various way : On Stock, On framework agreement, On Tender* Record request from requester called "Logistic Requisition" (for need of services, product or whatever).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: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_selectionYou can find them here : https://github.com/OCA/vertical-ngoDear 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).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.--
Post to: mailto:email@example.com
----CEO Avanzosc, S.L : Office phone / Tfono oficina: (+34) 943 02 69 02
Ana Juaristi Olalde : Personal phone: 677 93 42 59. User/usuario skype: Avanzosc
El contenido de esta comunicación y de toda su documentación anexa es confidencial y se dirige exclusivamente a su destinatario. El uso no autorizado de esta información está prohibido por la legislación vigente. Si usted no es el destinatario le rogamos nos lo indique, no comunique su contenido a terceros y proceda a su destrucción. Disculpe las molestias que le haya ocasionado la recepción indebida de este e-mail. Sus datos figuran en un fichero cuyo titular es Avanzosc, S.L., a quien usted puede dirigirse para ejercer sus derechos de acceso, rectificación, cancelación y oposición en Klara Donea 13, 20720, Azkoitia (Gipuzkoa), Tef. 943 02 69 02 - firstname.lastname@example.org
Komunikazio honen edukia eta dokumentazio erantsia konfidentziala da eta hartzaileak bakarrik jaso beharko luke. Indarrean dagoen legeriak debekatu egiten du bertan eskainitako informazioa baimenik gabe erabiltzea. Komunikazioa zuri iritsi bazaizu, baina zu ez bazara hartzailea, mesedez, guri jakinarazi, eta jasotako informazioa ez inori jakinarazi eta suntsitu. Barkatu okerreko email hau jasotzeak eragindako eragozpenak. Zure datuak Avanzosc, S.L. enpresaren fitxategietan sartuta daude. Zure datuak atzitzea eska dezakezu, bai eta, datuak zuzentzea, ezereztea eta tratamenduari aurka egitea ere. Horretarako, enpresara jo dezakezu, helbide honetan: Klara Donea 13 20720, Azkoitia (Gipuzkoa), telefonoa: 943 02 69 02 - email@example.com
This message and all documents attached to it are confidential and intended only for the person or entity to which it is addressed. Any use of this information by unauthorised persons is prohibited under current legislation. If you received this message by error, please advise us, destroy it and refrain from communicating its contents to third parties. We apologise for any inconvenience receiving this email improperly may cause to you. Your personal data are included in a file owned by Avanzosc, S.L. If you want to exercise your rights of access, correction, erasure and objection you can contact the Controller at Klara Donea 13 20720, Azkoitia (Gipuzkoa), T: 943 02 69 02 – firstname.lastname@example.org