[OFBiz] Users - Automatic Purchasing
Locked
12
12
[OFBiz] Users - Automatic Purchasing
 
|
For various reasons, I do not want to use the OFBiz Order Requirements to
automate purchasing for my business. I would rather duplicate the functionality of my existing purchasing system. This will also be my first attempt to create an OFBiz application, so I'm hoping somebody will tell me if I'm re-inventing the wheel here. My application will automatically generate purchase orders based upon the ProductFacility entity's minimumStock and reorderQuantity. There will be a screen for the user to select: [] Facility - which facility are you ordering for? [] Supplier, or "All Suppliers" [] Product, or "All Products" [] ATP/QOH Preference: Should we use the ATP or QOH numbers to generate the purchase order? [] Order Quantity Preference: if the suggested order quantity is less than the supplier's minumum order quantity, then does the user want to omit the item, or increase the quantity to match the vendor's minimum order quantity? Clicking a "Generate" button will examine the inventory at that facility. Each item that has a ATP/QOH less than the minimumStock will be ordered up to the reoderQuantity. Purchase orders will be automatically created, and the user can approve them or cancel them. MAJOR ISSUE: o "Primary Suppliers" need to be defined. Because each product can and often does have multiple suppliers, there needs to be a notion of a Primary Supplier. This would ideally be part of the ProductFacility entity, but I could create a new entity called, say, ProductFacilityPrimarySuppliers to avoid messing with the native ofbiz entities. I currently use a system like this, and I don't think I can live without it. Does this seem like a reasonably non-complicated OFBiz cusomization project? Would anybody else find this valuable, or does this somehow violate some sort of 'best practices' with regard to OFBiz purchasing management? -- Christopher Farley www.northernbrewer.com _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
It would be nice to have some automated purchase order creation.
But, how is "Purchase orders will be automatically created, and the user can approve them or cancel them" going to be really different than "Requirements are automatically created, and the user can create purchase orders from them or cancel them"? Might you be writing a lot of code to support essentially the same business process. Primary supplier sounds like a good idea. Maybe we should have that. Anybody else? Si Christopher Farley wrote: >For various reasons, I do not want to use the OFBiz Order Requirements to >automate purchasing for my business. I would rather duplicate the >functionality of my existing purchasing system. This will also be my first >attempt to create an OFBiz application, so I'm hoping somebody will tell >me if I'm re-inventing the wheel here. > >My application will automatically generate purchase orders based upon the >ProductFacility entity's minimumStock and reorderQuantity. There will be >a screen for the user to select: > [] Facility - which facility are you ordering for? > [] Supplier, or "All Suppliers" > [] Product, or "All Products" > [] ATP/QOH Preference: Should we use the ATP or QOH numbers to generate > the purchase order? > [] Order Quantity Preference: if the suggested order quantity is less > than the supplier's minumum order quantity, then does the user want > to omit the item, or increase the quantity to match the vendor's > minimum order quantity? > >Clicking a "Generate" button will examine the inventory at that facility. >Each item that has a ATP/QOH less than the minimumStock will be ordered >up to the reoderQuantity. Purchase orders will be automatically created, >and the user can approve them or cancel them. > >MAJOR ISSUE: > o "Primary Suppliers" need to be defined. Because each product can and > often does have multiple suppliers, there needs to be a notion of > a Primary Supplier. This would ideally be part of the ProductFacility > entity, but I could create a new entity called, say, > ProductFacilityPrimarySuppliers to avoid messing with the native > ofbiz entities. > > >I currently use a system like this, and I don't think I can live without >it. Does this seem like a reasonably non-complicated OFBiz cusomization >project? Would anybody else find this valuable, or does this somehow >violate some sort of 'best practices' with regard to OFBiz purchasing >management? > > > _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: [OFBiz] Users - Automatic Purchasing
|
|
Si Chen ([hidden email]) wrote:
> It would be nice to have some automated purchase order creation. > > But, how is "Purchase orders will be automatically created, and the user > can approve them or cancel them" going to be really different than > "Requirements are automatically created, and the user can create > purchase orders from them or cancel them"? Might you be writing a lot of > code to support essentially the same business process. I could use requirements, but I would need to make the following enhancements to OFBiz: 1. Create a screen to automatically generate requirements from current inventory values: for each item with an ATP less than the minumumQuantity, create a new requirement. The quantity of this requirement is reorderQuantity - ATP. This screen should allow the user to limit automatic requirement generation by supplier, product SKU range, product category, etc. 2. Improve the Approve Requirements process. A lot of businesses have thousands, or even tens of thousands of SKUs, and there needs to be a way to approve and reject requirements en masse. My idea would be to list all requirements on a single screen so they can be selected with a check box. Include buttons to Select All/Deselect All. Finally, you need a way to either approve or reject the selected requirements. 3. For adding requirements to purchase orders: the Requirement List should only show requirements that contain products that are valid for the current Supplier. You would need to "SELECT * FROM requirement WHERE product_id IN (SELECT product_id FROM supplier_product WHERE party_id = ?)" 4. Currently, when you try and put a requirement on a purchase order, and the quantity is less than the supplier's minimum order qty, you get an error: "SupplierProduct not found". This needs to be fixed. Idea: Next to the "Submit Button" on the Requirement List, include a checkbox that says "Increase Quantities to Match Supplier's Minimum Order Quantities". This would not necessarily require a "Primary Supplier" to be defined. Maybe this would be easier than what I proposed earlier. My other solution could have been a stand-alone application, whereas enhancing the requirements involves mucking with existing OFBiz code/applications. I'm somewhat comfortable creating a stand-alone app, but moderately fearful of enhancing existing OFBiz code. -- Christopher Farley www.northernbrewer.com _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: [OFBiz] Users - Automatic Purchasing
|
|
In reply to this post by Si Chen-2
We have primary suppliers too. Each supplier will have their own price and
ordering requirements. Coincidently, we're currently working on porting our inventory module to OFBiz. So, this is a very timely thread. Our current non-Ofbiz software does exactly what Christopher described. We don't use that feature here - because we manufacture to order, and inventory is ordered as work orders are released to production. Si Chen wrote: > It would be nice to have some automated purchase order creation. > > But, how is "Purchase orders will be automatically created, and the user > can approve them or cancel them" going to be really different than > "Requirements are automatically created, and the user can create > purchase orders from them or cancel them"? Might you be writing a lot of > code to support essentially the same business process. > > Primary supplier sounds like a good idea. Maybe we should have that. > Anybody else? > > Si > > Christopher Farley wrote: > >> For various reasons, I do not want to use the OFBiz Order Requirements >> to automate purchasing for my business. I would rather duplicate the >> functionality of my existing purchasing system. This will also be my >> first >> attempt to create an OFBiz application, so I'm hoping somebody will tell >> me if I'm re-inventing the wheel here. >> >> My application will automatically generate purchase orders based upon the >> ProductFacility entity's minimumStock and reorderQuantity. There will be >> a screen for the user to select: >> [] Facility - which facility are you ordering for? >> [] Supplier, or "All Suppliers" >> [] Product, or "All Products" >> [] ATP/QOH Preference: Should we use the ATP or QOH numbers to generate >> the purchase order? >> [] Order Quantity Preference: if the suggested order quantity is >> less than the supplier's minumum order quantity, then does the >> user want to omit the item, or increase the quantity to match the >> vendor's minimum order quantity? >> >> Clicking a "Generate" button will examine the inventory at that >> facility. Each item that has a ATP/QOH less than the minimumStock will >> be ordered up to the reoderQuantity. Purchase orders will be >> automatically created, and the user can approve them or cancel them. >> >> MAJOR ISSUE: >> o "Primary Suppliers" need to be defined. Because each product can and >> often does have multiple suppliers, there needs to be a notion of >> a Primary Supplier. This would ideally be part of the ProductFacility >> entity, but I could create a new entity called, say, >> ProductFacilityPrimarySuppliers to avoid messing with the native >> ofbiz entities. >> >> >> I currently use a system like this, and I don't think I can live without >> it. Does this seem like a reasonably non-complicated OFBiz >> cusomization project? Would anybody else find this valuable, or does >> this somehow violate some sort of 'best practices' with regard to >> OFBiz purchasing management? >> >> >> > > _______________________________________________ > Users mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/users > _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
In reply to this post by Christopher Farley
Chris,
Christopher Farley wrote: >Si Chen ([hidden email]) wrote: > > > >>It would be nice to have some automated purchase order creation. >> >>But, how is "Purchase orders will be automatically created, and the user >>can approve them or cancel them" going to be really different than >>"Requirements are automatically created, and the user can create >>purchase orders from them or cancel them"? Might you be writing a lot of >>code to support essentially the same business process. >> >> > >I could use requirements, but I would need to make the following >enhancements to OFBiz: > > 1. Create a screen to automatically generate requirements from > current inventory values: for each item with an ATP less than the > minumumQuantity, create a new requirement. The quantity of this > requirement is reorderQuantity - ATP. This screen should allow > the user to limit automatic requirement generation by > supplier, product SKU range, product category, etc. > > > your products, so you can re-use those services on your screen. This shouldn't be too hard. > 2. Improve the Approve Requirements process. A lot of businesses have > thousands, or even tens of thousands of SKUs, and there needs to be > a way to approve and reject requirements en masse. My idea would > be to list all requirements on a single screen so they can be > selected with a check box. Include buttons to Select All/Deselect > All. Finally, you need a way to either approve or reject the selected > requirements. > > > "service-multi" and multi forms. > 3. For adding requirements to purchase orders: the Requirement List > should only show requirements that contain products that are valid > for the current Supplier. You would need to "SELECT * FROM requirement > WHERE product_id IN (SELECT product_id FROM supplier_product WHERE > party_id = ?)" > > > Good idea again. It would require adding some code to the screen for purchase orders. > 4. Currently, when you try and put a requirement on a purchase order, > and the quantity is less than the supplier's minimum order qty, you > get an error: "SupplierProduct not found". This needs to be fixed. > Idea: Next to the "Submit Button" on the Requirement List, include > a checkbox that says "Increase Quantities to Match Supplier's > Minimum Order Quantities". > > > Maybe it's better to figure out what the minimum quantity is and put it in there or at least show the user what that is? >This would not necessarily require a "Primary Supplier" to be defined. > > > You're right. >Maybe this would be easier than what I proposed earlier. My other >solution could have been a stand-alone application, whereas enhancing the >requirements involves mucking with existing OFBiz code/applications. >I'm somewhat comfortable creating a stand-alone app, but moderately >fearful of enhancing existing OFBiz code. > > > Yes, most people feel that way at first. But longer term it's better for you to enhance the existing application because - 1. You can upgrade more easily over time. Having stranded orphan features that are incompatible with new versions of OFBiz is no fun--believe me, I know from first hand experience. 2. You'll get more familiar with OFBiz and be more able to customize it in the future. 3. If you contribute stuff back, others can help you develop, debug, and maintain your work. Anyway, sounds like you have some great ideas. Let me know if you need any help with them. Si _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: [OFBiz] Users - Automatic Purchasing
|
|
In reply to this post by Christopher Farley
Hi Christopher,
I agree with Si when he says that you should consider extending the existing requirement stuff. The enhancements you are suggesting are very good stuff (I can see you have a good understanding of the existing data model and processes related to requirements) and, as Si already said, some of them are partially implemented. 1 and 2 are partially implemented (see the Manufacturing-->Approve requirement screen) 3 and 4 are planned features that it would be great to see implemented: if you need help, please let me know. About the primary supplier concept: given a product, the primary supplier could be the one with higher priority in the SupplierProduct entity; and, when creating a requirement for a product, you could link the 'primary' supplier to the requirement thru the RequirementPartyAssign (or something similar, I don't remember the name of the entity) giving it a role like PRIMARY_SUPPLIER. Regards, Jacopo Christopher Farley wrote: > Si Chen ([hidden email]) wrote: > > >>It would be nice to have some automated purchase order creation. >> >>But, how is "Purchase orders will be automatically created, and the user >>can approve them or cancel them" going to be really different than >>"Requirements are automatically created, and the user can create >>purchase orders from them or cancel them"? Might you be writing a lot of >>code to support essentially the same business process. > > > I could use requirements, but I would need to make the following > enhancements to OFBiz: > > 1. Create a screen to automatically generate requirements from > current inventory values: for each item with an ATP less than the > minumumQuantity, create a new requirement. The quantity of this > requirement is reorderQuantity - ATP. This screen should allow > the user to limit automatic requirement generation by > supplier, product SKU range, product category, etc. > > 2. Improve the Approve Requirements process. A lot of businesses have > thousands, or even tens of thousands of SKUs, and there needs to be > a way to approve and reject requirements en masse. My idea would > be to list all requirements on a single screen so they can be > selected with a check box. Include buttons to Select All/Deselect > All. Finally, you need a way to either approve or reject the selected > requirements. > > 3. For adding requirements to purchase orders: the Requirement List > should only show requirements that contain products that are valid > for the current Supplier. You would need to "SELECT * FROM requirement > WHERE product_id IN (SELECT product_id FROM supplier_product WHERE > party_id = ?)" > > 4. Currently, when you try and put a requirement on a purchase order, > and the quantity is less than the supplier's minimum order qty, you > get an error: "SupplierProduct not found". This needs to be fixed. > Idea: Next to the "Submit Button" on the Requirement List, include > a checkbox that says "Increase Quantities to Match Supplier's > Minimum Order Quantities". > > This would not necessarily require a "Primary Supplier" to be defined. > > Maybe this would be easier than what I proposed earlier. My other > solution could have been a stand-alone application, whereas enhancing the > requirements involves mucking with existing OFBiz code/applications. > I'm somewhat comfortable creating a stand-alone app, but moderately > fearful of enhancing existing OFBiz code. > _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: [OFBiz] Users - Automatic Purchasing
|
|
In reply to this post by Si Chen-2
Si Chen ([hidden email]) wrote:
> >I could use requirements, but I would need to make the following > >enhancements to OFBiz: > > > >1. Create a screen to automatically generate requirements from > > current inventory values: for each item with an ATP less than the > > minumumQuantity, create a new requirement. The quantity of this > > requirement is reorderQuantity - ATP. This screen should allow > > the user to limit automatic requirement generation by > > supplier, product SKU range, product category, etc. > > > > > > > This is already done automatically when you set the requirement enum for > your products, so you can re-use those services on your screen. This > shouldn't be too hard. I have implemented the above, with the exception of a few cosmetic finishing touches. The user selects a facility from a drop down menu, clicks a button labelled "Generate Requirements", and a minilang script creates a requirement for each item at the facility. In the future I would like the option to limit generated requirements by a supplier. I have a few questions/issues: 1. Should the Requirement Type Id for the generated requirements be PRODUCT_REQUIREMENT, or should I create a new Requirement Type Id called, say, AUTO_REQUIREMENT? Creating a new Requirement Type Id will allow the user to more easily sort through the automatically generated requirements as opposed to product requirements created via sales orders, etc. 2. Where should this screen go? Right now I added a button labelled "Generate Requirements" on the ordermgr's FindRequirements screen (to the right of the "New Requirement" button. 3. If you have a lot of products at a facility, the script can take a few minutes to run. The default transaction timeout causes an error. I am still working on a suitable resolution to this... 4. Just to confirm terminology: my script calcs requirement quantity like this: requirementQuantity = reorderQuantity - availableToPromiseQuantity Am I interpreting "reorderQuantity" properly? Or is "reorderQuantity" meant to be a fixed quantity that is ordered each time you order? 5. Once I'm ready to submit a patch for review, would I open an account on Jira and submit it there? -- Christopher Farley www.northernbrewer.com _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: [OFBiz] Users - Automatic Purchasing
|
|
Hi Christopher
I'm very glad that you are working on this, and working to share this back with the community... I'm no expert with all of this inventory stuff, but one thing you said didn't quite make sense... Perhaps some of the gurus here can set us both straight... You said: 4. Just to confirm terminology: my script calcs requirement quantity like this: requirementQuantity = reorderQuantity - availableToPromiseQuantity Am I interpreting "reorderQuantity" properly? Or is "reorderQuantity" meant to be a fixed quantity that is ordered each time you order? I think reorderQuantity is something that is different for each supplier, and is based on minimumQuantity and OrderQuantityIncrements. Would it make more sense to do something like... requirementQuantity = minimumStock - incomingShipments - availableToPromiseQuantity At some point, to make OFBiz truly generic, we might want to think about upgrading the inventory system to one that can track future inventory requirements at multiple points in time. In the electronics industry lead times can exceed 6 months... with numerous future purchases/deliveries planned... It can get tricky to know if you can sell X today, and still meet all of your promised deliveries. Thanks On Wed, 2005-11-16 at 00:47 -0600, Christopher Farley wrote: > 4. Just to confirm terminology: my script calcs requirement quantity > like > this: > requirementQuantity = reorderQuantity - availableToPromiseQuantity > Am I interpreting "reorderQuantity" properly? Or is > "reorderQuantity" > meant to be a fixed quantity that is ordered each time you order? _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: [OFBiz] Users - Automatic Purchasing
|
|
Daniel Kunkel ([hidden email]) wrote:
> 4. Just to confirm terminology: my script calcs requirement quantity > like > this: > requirementQuantity = reorderQuantity - availableToPromiseQuantity > Am I interpreting "reorderQuantity" properly? Or is > "reorderQuantity" > meant to be a fixed quantity that is ordered each time you order? > > I think reorderQuantity is something that is different for each > supplier, and is based on minimumQuantity and OrderQuantityIncrements. > > Would it make more sense to do something like... > > requirementQuantity = minimumStock - incomingShipments - > availableToPromiseQuantity My current system has a concept of minimumStock and maximumStock levels. We order all items that have fallen below the minimum stock levels, and we replentish these items up to the maximum stock levels. I was guessing that "reorder quantity" was analagous to "maximum stock". My only justification for this was that, in the seed data, reorderQuantity was always greater than minimumStock. OFBiz does have a separate field for a supplier minimum order quantity, in the supplier_product relation. But auto-generating requirements shouldn't consider this -- it is just a service to generate requirements based on what your facility needs. Later, you can adjust the purchase order to take into account the supplier's minimum order quantity and order quantity increments... As for taking into account incoming shipments, yes this should be done. Does anybody know if there is an existing service to query the incoming shipments? I'll have a look... > At some point, to make OFBiz truly generic, we might want to think about > upgrading the inventory system to one that can track future inventory > requirements at multiple points in time. In the electronics industry > lead times can exceed 6 months... with numerous future > purchases/deliveries planned... It can get tricky to know if you can > sell X today, and still meet all of your promised deliveries. -- Christopher Farley www.northernbrewer.com _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
In reply to this post by Christopher Farley
Christopher Farley wrote: >Si Chen ([hidden email]) wrote: > > > >>>I could use requirements, but I would need to make the following >>>enhancements to OFBiz: >>> >>>1. Create a screen to automatically generate requirements from >>> current inventory values: for each item with an ATP less than the >>> minumumQuantity, create a new requirement. The quantity of this >>> requirement is reorderQuantity - ATP. This screen should allow >>> the user to limit automatic requirement generation by >>> supplier, product SKU range, product category, etc. >>> >>> >>> >>> >>> >>This is already done automatically when you set the requirement enum for >>your products, so you can re-use those services on your screen. This >>shouldn't be too hard. >> >> > >I have implemented the above, with the exception of a few cosmetic >finishing touches. The user selects a facility from a drop down menu, >clicks a button labelled "Generate Requirements", and a minilang script >creates a requirement for each item at the facility. In the future I would >like the option to limit generated requirements by a supplier. > >I have a few questions/issues: > >1. Should the Requirement Type Id for the generated requirements be > PRODUCT_REQUIREMENT, or should I create a new Requirement Type > Id called, say, AUTO_REQUIREMENT? Creating a new Requirement > Type Id will allow the user to more easily sort through the > automatically generated requirements as opposed to product > > requirements created via sales orders, etc. > > Yes, but creating an existing type would allow you to reuse existing services that handle it, which is what I personally think would be better? But I'm open to an alternative - what does everybody else think? There is already a service called "createRequirementFromItemATP" Did you see this? >2. Where should this screen go? Right now I added a button labelled "Generate > Requirements" on the ordermgr's FindRequirements screen (to the right > of the "New Requirement" button. > > > That sounds like a good idea. >3. If you have a lot of products at a facility, the script can take a few > minutes to run. The default transaction timeout causes an error. I am > still working on a suitable resolution to this... > > > Set the transaction-timout (yes, that's how it's spelled) in your services xml definition to something longer (the default is 60 for 60 seconds.) >4. Just to confirm terminology: my script calcs requirement quantity like > this: > requirementQuantity = reorderQuantity - availableToPromiseQuantity > Am I interpreting "reorderQuantity" properly? Or is "reorderQuantity" > meant to be a fixed quantity that is ordered each time you order? > > > If you're using createRequirementFromItemATP, it should already have a formula for doing that. reorderQuantity means the fixed quantity to be ordered each time. >5. Once I'm ready to submit a patch for review, would I open an account > on Jira and submit it there? > > Yes. That would be the best way. _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
In reply to this post by Christopher Farley
Christopher Farley wrote: >Daniel Kunkel ([hidden email]) wrote: > > > >>4. Just to confirm terminology: my script calcs requirement quantity >>like >> this: >> requirementQuantity = reorderQuantity - availableToPromiseQuantity >> Am I interpreting "reorderQuantity" properly? Or is >>"reorderQuantity" >> meant to be a fixed quantity that is ordered each time you order? >> >>I think reorderQuantity is something that is different for each >>supplier, and is based on minimumQuantity and OrderQuantityIncrements. >> >>Would it make more sense to do something like... >> >> requirementQuantity = minimumStock - incomingShipments - >>availableToPromiseQuantity >> >> > >My current system has a concept of minimumStock and maximumStock levels. >We order all items that have fallen below the minimum stock levels, and >we replentish these items up to the maximum stock levels. > >I was guessing that "reorder quantity" was analagous to "maximum stock". >My only justification for this was that, in the seed data, reorderQuantity >was always greater than minimumStock. > > > >OFBiz does have a separate field for a supplier minimum order quantity, >in the supplier_product relation. But auto-generating requirements >shouldn't consider this -- it is just a service to generate requirements >based on what your facility needs. Later, you can adjust the purchase >order to take into account the supplier's minimum order quantity and >order quantity increments... > > > I agree. The only problem is maybe if you add five requirements of 10 each, the purchase order entry system might not know that that's equal to ordering 50 and meets the 50 breakpoint, but that should be fixed. >As for taking into account incoming shipments, yes this should be done. >Does anybody know if there is an existing service to query the incoming >shipments? I'll have a look... > > > Not too sure. Take a look in the service reference in webtools or see how this page is done: http://localhost:8080/catalog/control/EditProductInventoryItems?productId=GZ-1000 It displays a list of incoming shipments. >>At some point, to make OFBiz truly generic, we might want to think about >>upgrading the inventory system to one that can track future inventory >>requirements at multiple points in time. In the electronics industry >>lead times can exceed 6 months... with numerous future >>purchases/deliveries planned... It can get tricky to know if you can >>sell X today, and still meet all of your promised deliveries. >> >> > > > _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: [OFBiz] Users - Automatic Purchasing
|
|
In reply to this post by Si Chen-2
Si Chen ([hidden email]) wrote:
> There is already a service called "createRequirementFromItemATP" Did > you see this? I didn't use this because it: - requires a seqGroupSeqId and an orderItemSeqId (none required for my autoGenerate method) - requires that the product is configured with a requirementMethodId of PRODRQM_STOCK_ATP. I don't want to configure my products that way, because I don't want requirements being generated after each sales order. (If this seems strange, I could tell you my reasons...) I would prefer that requirements are generated for all products (regardless of requirementMethodId) at the moment my purchasing manager clicks on the "Generate Requirements" button. This, I think, adds some justfication for adding a new requirementTypeId. These requirements are not linked to specific orders, and you might want to keep them separate from ordinary PRODUCT_REQUIREMENTs so you can approve, reject or delete them en masse. -- Christopher Farley www.northernbrewer.com _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: [OFBiz] Users - Automatic Purchasing
|
|
In reply to this post by Si Chen-2
Si Chen ([hidden email]) wrote:
> I agree. The only problem is maybe if you add five requirements of 10 > each, the purchase order entry system might not know that that's equal > to ordering 50 and meets the 50 breakpoint, but that should be fixed. That's half of the reason I want to autoGenerate requirements, so that I never have five requirements of 10 each... In my business, I would probably end up with hundreds or even thousands of requirements for 1 or 2 each, and the resulting purchase order would have hundreds or thousands of line items, all for the same supplier product. This would be unacceptably inefficent for check-in, etc. Plus, my suppliers would go berserk when they saw my 2000 page purchase orders coming through on their fax machine! I originally thought that the way to solve the problem is to have ofbiz group products together when adding requirement items to a purchase order. For example, if you have five requirements of 10 each, and select them to be added to a PO, only one line item is added to the PO, and the quantity is 50. Then, of course, you could not link purchase order lines to a specific sales order line, which is desirable for some businesses. -- Christopher Farley www.northernbrewer.com _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
In reply to this post by Christopher Farley
Christopher,
It's great what you're doing, but I think it might be better to try to modify or extend createRequirementFromItemATP rather than add another service that does something so similar. The reason is because OFBiz is already huge (1300+ services), and it would be nice to keep it as manageable as possible by reusing the existing logic. I'm looking at your issues with the existing service, and I think the requirement for seqGroupSeqId and orderItemSeqId are related to it needing to link the requirement to orders. We can probably change the code to make it so that if these are not available, it just won't link them to orders, so they become optional. You maybe right about needing a separate requirement type, then. I see what you want: bulk generate rather than one at a time when each sale is created. Still there should be a lot of code in that existing service which you can reuse, either by isolating it or by modifying the original? Si Christopher Farley wrote: >Si Chen ([hidden email]) wrote: > > > >>There is already a service called "createRequirementFromItemATP" Did >>you see this? >> >> > >I didn't use this because it: > - requires a seqGroupSeqId and an orderItemSeqId (none required for my > autoGenerate method) > > - requires that the product is configured with a requirementMethodId of > PRODRQM_STOCK_ATP. I don't want to configure my products that way, > because I don't want requirements being generated after each sales > order. (If this seems strange, I could tell you my reasons...) > I would prefer that requirements are generated for all products > (regardless of requirementMethodId) at the moment my purchasing > manager clicks on the "Generate Requirements" button. > >This, I think, adds some justfication for adding a new requirementTypeId. >These requirements are not linked to specific orders, and you might want >to keep them separate from ordinary PRODUCT_REQUIREMENTs so you can >approve, reject or delete them en masse. > > > _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: [OFBiz] Users - Automatic Purchasing
|
|
Si Chen ([hidden email]) wrote:
> Christopher, > > It's great what you're doing, but I think it might be better to try to > modify or extend createRequirementFromItemATP rather than add another > service that does something so similar. The reason is because OFBiz is > already huge (1300+ services), and it would be nice to keep it as > manageable as possible by reusing the existing logic. > > I'm looking at your issues with the existing service, and I think the > requirement for seqGroupSeqId and orderItemSeqId are related to it > needing to link the requirement to orders. We can probably change the > code to make it so that if these are not available, it just won't link > them to orders, so they become optional. > > You maybe right about needing a separate requirement type, then. I see > what you want: bulk generate rather than one at a time when each sale is > created. Still there should be a lot of code in that existing service > which you can reuse, either by isolating it or by modifying the original? Maybe I could isolate some code and re-use it in both services. Maybe. See, as I investigate createRequirementFromItemATP, I see that it is quite specialized for its purpose. For example, if you have a product with the following properties: minimumStock: 10 reorderQuantity: 20 availableToPromiseTotal: 5 order line Quantity: 1 The createRequirementFromItemATP service creates a requirement for... only 1. It chooses the lesser of the quantityShortfall (based only on minimumStock, it doesn't even consider reorderQuantity) or the order line quantity. My service would take into account minimumStock and reorderQuantity, and create a requirement for 25. Now maybe there is some code that can be shared with respect to querying for the actual quantity shortfall. It would be maybe 5 lines of code at present, but it could be more than that if we start querying for incoming shipments, etc. I'll think a little bit more about it.... -- Christopher Farley www.northernbrewer.com _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
Christopher Farley wrote: >Si Chen ([hidden email]) wrote: > > > >>Christopher, >> >>It's great what you're doing, but I think it might be better to try to >>modify or extend createRequirementFromItemATP rather than add another >>service that does something so similar. The reason is because OFBiz is >>already huge (1300+ services), and it would be nice to keep it as >>manageable as possible by reusing the existing logic. >> >>I'm looking at your issues with the existing service, and I think the >>requirement for seqGroupSeqId and orderItemSeqId are related to it >>needing to link the requirement to orders. We can probably change the >>code to make it so that if these are not available, it just won't link >>them to orders, so they become optional. >> >>You maybe right about needing a separate requirement type, then. I see >>what you want: bulk generate rather than one at a time when each sale is >>created. Still there should be a lot of code in that existing service >>which you can reuse, either by isolating it or by modifying the original? >> >> > >Maybe I could isolate some code and re-use it in both services. Maybe. > >See, as I investigate createRequirementFromItemATP, I see that it is >quite specialized for its purpose. > >For example, if you have a product with the following properties: > >minimumStock: 10 >reorderQuantity: 20 >availableToPromiseTotal: 5 >order line Quantity: 1 > >The createRequirementFromItemATP service creates a requirement for... >only 1. It chooses the lesser of the quantityShortfall (based only >on minimumStock, it doesn't even consider reorderQuantity) or the >order line quantity. My service would take into account minimumStock >and reorderQuantity, and create a requirement for 25. > > > >Now maybe there is some code that can be shared with respect to querying >for the actual quantity shortfall. It would be maybe 5 lines of code >at present, but it could be more than that if we start querying for >incoming shipments, etc. > > > It seems to my novice eyes that the two services do similar things. Basically, what you need can be written as createRequirementFromItemATP for all products, but I could be wrong. By the way, how are you getting a list of all products? From a warehouse? From a store? From a catalog? What if, for example, I had none of something in stock, so there's no InventoryItem for it. Will it create a Requirement? >I'll think a little bit more about it.... > > > _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: [OFBiz] Users - Automatic Purchasing
|
|
Si Chen ([hidden email]) wrote:
> >For example, if you have a product with the following properties: > > > >minimumStock: 10 > >reorderQuantity: 20 > >availableToPromiseTotal: 5 > >order line Quantity: 1 > > > >The createRequirementFromItemATP service creates a requirement for... > >only 1. It chooses the lesser of the quantityShortfall (based only > >on minimumStock, it doesn't even consider reorderQuantity) or the > >order line quantity. My service would take into account minimumStock > >and reorderQuantity, and create a requirement for 25. > > > > > > > Yes, that's a bug. Can you fix it? Fixing the problem properly could require some substantial re-architecting. The major problem, IMO, is that in order to do the calculations properly, you need to consider the existing automatically generated requirements for that product/facility. If you do not consider them, then each time you do a requirement quantity calculation, you will be ignoring the quantities the system previously required, and you will keep requiring more and more and more... Now this seems weird to me, because you are now calculating the required quantity on the basis of requirements that are in the database, but not even approved. Also, I'm not 100% sure about this, but I don't think you want to consider all requirements in your calculation. If there's an internal requirement, or if manufacturing enters a requirement, you should *not* use those in the calculation. (True??) So given that, here's how I think you could fix the bug: - Create a new requirementTypeId that is used by the automatic requirement generation system, say AUTO_REQUIREMENT - When it is time to generate a requirement by ATP, you will: a. Search for all existing AUTO_REQUIREMENTs for the product/facility with a status of REQ_CREATED or REQ_APPROVED b. If there is not an existing AUTO_REQUIREMENT with a status of REQ_CREATED, create one c. Take the first requirement with a status of REQ_CREATED and update its quantity according to this formula: requirementQuantity = minimumStock + reorderQuantity - (availableToPromisQuantity + incomingShipmentQuantity + sumOfExistingRequirementQuantities) d. You also need to add an orderRequirementCommitment to the updated requirement for the new sales order line item. This solves a couple problems. Namely, the quantity calculation. But it also fixes another ugly problem, where incoming sales orders could generate hundreds of new requirements for the same exact item at the facility. (Imagine if you were a supplier and you received a 90 page purchase order for only three distinct items. Ick.) There will only be one AUTO_REQUIREMENT for each product/facility. I think it is possible to have many orderReqirementCommitments for a single order line. And, on the purchase order, it should also be possible to link multiple orderItemAssociations to a single order line. I'm not 100% sure about the details. Maybe it is fine to use the existing PRODUCT_REQUIREMENT as the requirementTypeId. I'm not sure what else creates PRODUCT_REQUIREMENTS, and if it would be sensible to consider them. But all of this complexity is really unique to continuously generated requirements (requirements generated after each sales order). Periodicly generated requirements (aka "batch" or "bulk" requirements) are much easier to handle. You don't really care about existing requirements, especially if you segregate the periodic requirements with their own requirementTypeId. You don't even link them to specific sales orders, so its a lot easier to deal with overall... > By the way, how are you getting a list of all products? From a > warehouse? From a store? From a catalog? What if, for example, I had > none of something in stock, so there's no InventoryItem for it. Will it > create a Requirement? I'm using ProductFacility to get a list of all products. Generally a purchase order must come to a specific facility, and that's where minimumStock and reorderQuantity are, so I figured it was sensible. -- Christopher Farley www.northernbrewer.com _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: [OFBiz] Users - Automatic Purchasing
|
|
Hi Christopher,
this thread is very interesting. I'd like to have more time to jump into it... Have you ever considered to use the MRP algorithms for requirements' generation? Jacopo Christopher Farley wrote: > Si Chen ([hidden email]) wrote: > > >>>For example, if you have a product with the following properties: >>> >>>minimumStock: 10 >>>reorderQuantity: 20 >>>availableToPromiseTotal: 5 >>>order line Quantity: 1 >>> >>>The createRequirementFromItemATP service creates a requirement for... >>>only 1. It chooses the lesser of the quantityShortfall (based only >>>on minimumStock, it doesn't even consider reorderQuantity) or the >>>order line quantity. My service would take into account minimumStock >>>and reorderQuantity, and create a requirement for 25. >>> >>> >>> >> >>Yes, that's a bug. Can you fix it? > > > Fixing the problem properly could require some substantial > re-architecting. > > The major problem, IMO, is that in order to do > the calculations properly, you need to consider the existing > automatically generated requirements for that product/facility. If > you do not consider them, then each time you do a requirement > quantity calculation, you will be ignoring the quantities the system > previously required, and you will keep requiring more and more and > more... > > Now this seems weird to me, because you are now calculating the > required quantity on the basis of requirements that are in the database, > but not even approved. Also, I'm not 100% sure about this, but I don't > think you want to consider all requirements in your calculation. > If there's an internal requirement, or if manufacturing enters a > requirement, you should *not* use those in the calculation. (True??) > > So given that, here's how I think you could fix the bug: > > - Create a new requirementTypeId that is used by the automatic > requirement generation system, say AUTO_REQUIREMENT > - When it is time to generate a requirement by ATP, you will: > a. Search for all existing AUTO_REQUIREMENTs for the product/facility > with a status of REQ_CREATED or REQ_APPROVED > b. If there is not an existing AUTO_REQUIREMENT with a status of > REQ_CREATED, create one > c. Take the first requirement with a status of REQ_CREATED and update > its quantity according to this formula: > requirementQuantity = minimumStock + reorderQuantity - (availableToPromisQuantity + incomingShipmentQuantity + sumOfExistingRequirementQuantities) > d. You also need to add an orderRequirementCommitment to the > updated requirement for the new sales order line item. > > This solves a couple problems. Namely, the quantity calculation. > But it also fixes another ugly problem, where incoming sales orders > could generate hundreds of new requirements for the same exact item > at the facility. (Imagine if you were a supplier and you received > a 90 page purchase order for only three distinct items. Ick.) There > will only be one AUTO_REQUIREMENT for each product/facility. I think > it is possible to have many orderReqirementCommitments for a single > order line. And, on the purchase order, it should also be possible > to link multiple orderItemAssociations to a single order line. > > I'm not 100% sure about the details. Maybe it is fine to use the > existing PRODUCT_REQUIREMENT as the requirementTypeId. I'm not sure > what else creates PRODUCT_REQUIREMENTS, and if it would be sensible > to consider them. > > But all of this complexity is really unique to continuously generated > requirements (requirements generated after each sales order). Periodicly > generated requirements (aka "batch" or "bulk" requirements) are much > easier to handle. You don't really care about existing requirements, > especially if you segregate the periodic requirements with their own > requirementTypeId. You don't even link them to specific sales orders, so > its a lot easier to deal with overall... > > >>By the way, how are you getting a list of all products? From a >>warehouse? From a store? From a catalog? What if, for example, I had >>none of something in stock, so there's no InventoryItem for it. Will it >>create a Requirement? > > > I'm using ProductFacility to get a list of all products. Generally a > purchase order must come to a specific facility, and that's where > minimumStock and reorderQuantity are, so I figured it was sensible. > _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
Christopher, Jacopo -
I think Christopher brought up many good points. Do you have anything you can show us of what you've done? Jacopo - how would the MRP algorithms apply to this instance? Si Jacopo Cappellato wrote: > Hi Christopher, > > > this thread is very interesting. I'd like to have more time to jump > into it... > > Have you ever considered to use the MRP algorithms for requirements' > generation? > > Jacopo > > > Christopher Farley wrote: > >> Si Chen ([hidden email]) wrote: >> >> >>>> For example, if you have a product with the following properties: >>>> >>>> minimumStock: 10 reorderQuantity: 20 >>>> availableToPromiseTotal: 5 >>>> order line Quantity: 1 >>>> >>>> The createRequirementFromItemATP service creates a requirement for... >>>> only 1. It chooses the lesser of the quantityShortfall (based only >>>> on minimumStock, it doesn't even consider reorderQuantity) or the >>>> order line quantity. My service would take into account >>>> minimumStock and reorderQuantity, and create a requirement for 25. >>>> >>>> >>> >>> Yes, that's a bug. Can you fix it? >> >> >> >> Fixing the problem properly could require some substantial >> re-architecting. >> The major problem, IMO, is that in order to do >> the calculations properly, you need to consider the existing >> automatically generated requirements for that product/facility. If >> you do not consider them, then each time you do a requirement >> quantity calculation, you will be ignoring the quantities the system >> previously required, and you will keep requiring more and more and >> more... >> Now this seems weird to me, because you are now calculating the >> required quantity on the basis of requirements that are in the database, >> but not even approved. Also, I'm not 100% sure about this, but I >> don't think you want to consider all requirements in your calculation. >> If there's an internal requirement, or if manufacturing enters a >> requirement, you should *not* use those in the calculation. (True??) >> >> So given that, here's how I think you could fix the bug: >> >> - Create a new requirementTypeId that is used by the automatic >> requirement generation system, say AUTO_REQUIREMENT >> - When it is time to generate a requirement by ATP, you will: >> a. Search for all existing AUTO_REQUIREMENTs for the >> product/facility >> with a status of REQ_CREATED or REQ_APPROVED >> b. If there is not an existing AUTO_REQUIREMENT with a status of >> REQ_CREATED, create one >> c. Take the first requirement with a status of REQ_CREATED and >> update >> its quantity according to this formula: >> requirementQuantity = minimumStock + reorderQuantity - >> (availableToPromisQuantity + incomingShipmentQuantity + >> sumOfExistingRequirementQuantities) >> d. You also need to add an orderRequirementCommitment to the >> updated requirement for the new sales order line item. >> >> This solves a couple problems. Namely, the quantity calculation. >> But it also fixes another ugly problem, where incoming sales orders >> could generate hundreds of new requirements for the same exact item >> at the facility. (Imagine if you were a supplier and you received >> a 90 page purchase order for only three distinct items. Ick.) There >> will only be one AUTO_REQUIREMENT for each product/facility. I think >> it is possible to have many orderReqirementCommitments for a single >> order line. And, on the purchase order, it should also be possible >> to link multiple orderItemAssociations to a single order line. >> >> I'm not 100% sure about the details. Maybe it is fine to use the >> existing PRODUCT_REQUIREMENT as the requirementTypeId. I'm not sure >> what else creates PRODUCT_REQUIREMENTS, and if it would be sensible >> to consider them. >> But all of this complexity is really unique to continuously generated >> requirements (requirements generated after each sales order). Periodicly >> generated requirements (aka "batch" or "bulk" requirements) are much >> easier to handle. You don't really care about existing requirements, >> especially if you segregate the periodic requirements with their own >> requirementTypeId. You don't even link them to specific sales orders, so >> its a lot easier to deal with overall... >> >> >>> By the way, how are you getting a list of all products? From a >>> warehouse? From a store? From a catalog? What if, for example, I >>> had none of something in stock, so there's no InventoryItem for it. >>> Will it create a Requirement? >> >> >> >> I'm using ProductFacility to get a list of all products. Generally a >> purchase order must come to a specific facility, and that's where >> minimumStock and reorderQuantity are, so I figured it was sensible. >> > > > _______________________________________________ > Users mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/users > _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: [OFBiz] Users - Automatic Purchasing
|
|
Si Chen ([hidden email]) wrote:
> Christopher, Jacopo - > > I think Christopher brought up many good points. Do you have anything > you can show us of what you've done? I worked on it a bunch this weekend, and unfortunately reached another major stumbling block. In order to handle continous, automatic purchasing AND support something like reorderQuantity, something needs to change with purchase orders or requirements. The problem can be summed up as follows: When a sales order comes in for product X, a requirement is generated. It is certainly possible to support reorderQuantity -- you must inspect the existing requirements to make sure you do this properly. Next you go to order entry and enter a purchase order. You add the requirement for product X to the purchase order. Once the purchase order is placed, the requirements change status from "APPROVED" to "ORDERED". It is at this moment (after the purchase order has been created, but before any shipments have been entered on the purchase order) that there is a major inconsistency. If I'm not mistaken, purchase orders are associated with a company and not a facility. So if somebody enters a new sales order for product X, there are no existing requirements, and no incoming shipments, and you will generate a requirement for the reorderQuantity, which is NOT what you want to do. I can think of three possible solutions: 1. purchase orders are associated with a facility, so you can atomically change the requirement to 'ORDERED' and have a countable 'on order' quantity for a given product/facility. 2. Create a new status for requirements, say, REQ_COMPLETED. When the purchase order is received, the requirement can go from REQ_ORDERED to REQ_COMPLETED. When calculating reorder quantity, you would count requirements with a status of REQ_CREATED, REQ_APPROVED and REQ_ORDERED, and ignore those that were completed. 3. Abandon continuously-generated requirements altogether. Continuously generated requirements might save you a little bit of time, but they open up major cans of worms on several fronts. What happens if you change the facility's minimumStock or reorderQuantity after a requirement already exists? What happens if you do a physical count and adjust the quantity on hand/available to promise? Do you adjust the requirements to take this in to account? If so, when? When a sales order is placed? When the inventory adjustment is made? Furthermore, replentishment orders are generally made periodically (daily, weekly, monthly, etc). Then why not simply generate a list of requirements periodically, when you want to place an order. So, on the one hand it seems like a trivial bug, but on closer inspection it looks more like there are some architecture issues. -- Christopher Farley www.northernbrewer.com _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |