[OFBiz] Users - generating minimum stock requirements
Locked
 
|
Hi Jacopo,
I'm trying out the new requirements feature. The feature to gnerate requirement automatically for every sales order works very well (thank you!) However, I can't get it to generate requirements when QOH quantities fall below minimum. I set the Product's requirement enum Id to "When QOH reaches minimum stock for product-facility" and then for the warehouse facility the minimum stock and reorder quantities are 5 and 50, respectively. Then I order the item but even though the QOH is now negative no requirements are generated. Which service is supposed to create the requirements? How is it supposed to be set up (configured as a SECA)? If it's not a problem with the way I've set it up above, I'd like to look through and find out what happened to it. Thanks! Si _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: [OFBiz] Users - generating minimum stock requirements
|
|
Hi Si,
first of all: I'm very happy to see you are interested in the auto requirement stuff. Second: I've developed the "minimum stock requirement" stuff to provide richer auto requirement features to the OFBiz community but (at least until now) I'm not using it so I've made just a few test (I've only used the "auto requirement for every sales order" method so far)... so it's great to get your help over this! Third: your setup seems good. You can set the requirement generation method both at product level or at product store level. Here are some details: The service is called "checkCreateStockRequirement" and is defined in the order/servicedef/services.xml file The simple method implementation is in the order/script/org/ofbiz/order/order/OrderServices.xml file The service is triggered thru the following two secas defined in order/servicedef/secas.xml file: <!-- Requirement / stock level --> <eca service="createItemIssuance" event="invoke"> <condition field-name="quantity" value="0" operator="greater" type="Double"/> <action service="checkCreateStockRequirement" mode="sync"/> </eca> <eca service="updateItemIssuance" event="invoke"> <condition field-name="quantity" value="0" operator="greater" type="Double"/> <action service="checkCreateStockRequirement" mode="sync"/> </eca> Please, let me know if you need more information. Jacopo Si Chen wrote: > Hi Jacopo, > > I'm trying out the new requirements feature. The feature to gnerate > requirement automatically for every sales order works very well (thank > you!) However, I can't get it to generate requirements when QOH > quantities fall below minimum. > > I set the Product's requirement enum Id to "When QOH reaches minimum > stock for product-facility" and then for the warehouse facility the > minimum stock and reorder quantities are 5 and 50, respectively. Then I > order the item but even though the QOH is now negative no requirements > are generated. > > Which service is supposed to create the requirements? How is it > supposed to be set up (configured as a SECA)? If it's not a problem > with the way I've set it up above, I'd like to look through and find out > what happened to it. > > Thanks! > > Si > > _______________________________________________ > Users mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/users > > _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
Jacopo -
Found what I think might be the issue: in checkCreateStockRequirement, you have this if statement: <if-compare-field field-name="quantityOnHandTotal" to-field-name="productFacility.minimumStock" operator="greater-equals" type="Double"> So basically you are making sure that the QOH total starts out being greater than minimum stock before issuing a requirement. Thus, if the item is already below minimum stock, no more requirements will be created. I think we should change this code so that: 1. We should always calculate what the new QOH will be 2. If the new QOH is below the minimum stock, then first see if a requirement for this facility and product already exists and is in the state of CREATED. If it is, then update this requirement with the new quantity. If not, then create a new requirement. That way, as an item is continuously ordered, the amount required is added to, until a person can intervene and order it. Also, do you think the Requirements should have the facilityId field filled in. Finally, in the order manager, are you using the requirement status to control which requirements can be used to add to the order? If not, should we do that? Si Jacopo Cappellato wrote: > Hi Si, > > first of all: I'm very happy to see you are interested in the auto > requirement stuff. > Second: I've developed the "minimum stock requirement" stuff to > provide richer auto requirement features to the OFBiz community but > (at least until now) I'm not using it so I've made just a few test > (I've only used the "auto requirement for every sales order" method so > far)... so it's great to get your help over this! > Third: your setup seems good. You can set the requirement generation > method both at product level or at product store level. > > Here are some details: > > The service is called "checkCreateStockRequirement" and is defined in > the order/servicedef/services.xml file > The simple method implementation is in the > order/script/org/ofbiz/order/order/OrderServices.xml file > > The service is triggered thru the following two secas defined in > order/servicedef/secas.xml file: > > <!-- Requirement / stock level --> > <eca service="createItemIssuance" event="invoke"> > <condition field-name="quantity" value="0" operator="greater" > type="Double"/> > <action service="checkCreateStockRequirement" mode="sync"/> > </eca> > <eca service="updateItemIssuance" event="invoke"> > <condition field-name="quantity" value="0" operator="greater" > type="Double"/> > <action service="checkCreateStockRequirement" mode="sync"/> > </eca> > > > Please, let me know if you need more information. > > Jacopo > > > Si Chen wrote: > >> Hi Jacopo, >> >> I'm trying out the new requirements feature. The feature to gnerate >> requirement automatically for every sales order works very well >> (thank you!) However, I can't get it to generate requirements when >> QOH quantities fall below minimum. >> >> I set the Product's requirement enum Id to "When QOH reaches minimum >> stock for product-facility" and then for the warehouse facility the >> minimum stock and reorder quantities are 5 and 50, respectively. >> Then I order the item but even though the QOH is now negative no >> requirements are generated. >> >> Which service is supposed to create the requirements? How is it >> supposed to be set up (configured as a SECA)? If it's not a problem >> with the way I've set it up above, I'd like to look through and find >> out what happened to it. >> >> Thanks! >> >> Si >> >> _______________________________________________ >> Users mailing list >> [hidden email] >> http://lists.ofbiz.org/mailman/listinfo/users >> >> > > > > _______________________________________________ > 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 - generating minimum stock requirements
|
|
Si,
these are all good points. It's true, I'm not considering pending requirements (i.e. requirements in the CREATED or APPROVED status) in the checkCreateStockRequirement service. I made the assumption that the reorder quantity (and the lead times) is properly set to cope with the average number of incoming orders and so I kept things very simple: when the minimum quantity is reached one requirement for the reorder quantity is created (this new requirement SHOULD be sufficient for the average number of orders entered from now on at least for the next few weeks). By the way, your approach is better than mine so it would be very nice to see it implemented. About the facilityId field: yes, it would be nice to fill it, however under some circumstances it's difficult to say for which facility we are creating the requirement... About your last question about requirements' status: yes, the requirements' status is considered when the requirement is added to an order; in the order entry page you can only see requirements in the APPROVED status; at now you can approve a requirement in two ways: - by editing the requirement in the ordermgr - by selecting the requirement in the "Approve requirements" page in the manufacturing component When the order is checked out, the requirements' status is changed to ORDERED. We should only update the quantity of the requirements in CREATED status, not APPROVED. Jacopo Si Chen wrote: > Jacopo - > > Found what I think might be the issue: > > in checkCreateStockRequirement, you have this if statement: > > <if-compare-field field-name="quantityOnHandTotal" > to-field-name="productFacility.minimumStock" operator="greater-equals" > type="Double"> > > So basically you are making sure that the QOH total starts out being > greater than minimum stock before issuing a requirement. Thus, if the > item is already below minimum stock, no more requirements will be created. > > I think we should change this code so that: > 1. We should always calculate what the new QOH will be > 2. If the new QOH is below the minimum stock, then first see if a > requirement for this facility and product already exists and is in the > state of CREATED. If it is, then update this requirement with the new > quantity. If not, then create a new requirement. > > That way, as an item is continuously ordered, the amount required is > added to, until a person can intervene and order it. > > Also, do you think the Requirements should have the facilityId field > filled in. > > Finally, in the order manager, are you using the requirement status to > control which requirements can be used to add to the order? If not, > should we do that? > > > Si > _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
Hi Jacopo,
I am now wondering if my original idea was good. Which do you think is better - 1. Keep adding to one requirement for the product and facility combination - or 2. Create a separate requirement for each item issuance or order item, so we can trace back to the original order? That way, we can trace from a purchase order back to the original sales order or item issuance. What was your original idea behind the requirements? If we implement (1), how do we make it so that we can relate the original order item or item issuance to the requirement and thru to purchase orders? Thanks! Si Jacopo Cappellato wrote: > Si, > > these are all good points. > It's true, I'm not considering pending requirements (i.e. requirements > in the CREATED or APPROVED status) in the checkCreateStockRequirement > service. > I made the assumption that the reorder quantity (and the lead times) > is properly set to cope with the average number of incoming orders and > so I kept things very simple: when the minimum quantity is reached one > requirement for the reorder quantity is created (this new requirement > SHOULD be sufficient for the average number of orders entered from now > on at least for the next few weeks). > > By the way, your approach is better than mine so it would be very nice > to see it implemented. > > About the facilityId field: yes, it would be nice to fill it, however > under some circumstances it's difficult to say for which facility we > are creating the requirement... > > About your last question about requirements' status: > > yes, the requirements' status is considered when the requirement is > added to an order; in the order entry page you can only see > requirements in the APPROVED status; at now you can approve a > requirement in two ways: > - by editing the requirement in the ordermgr > - by selecting the requirement in the "Approve requirements" page in > the manufacturing component > When the order is checked out, the requirements' status is changed to > ORDERED. > We should only update the quantity of the requirements in CREATED > status, not APPROVED. > > Jacopo > > Si Chen wrote: > >> Jacopo - >> >> Found what I think might be the issue: >> >> in checkCreateStockRequirement, you have this if statement: >> >> <if-compare-field field-name="quantityOnHandTotal" >> to-field-name="productFacility.minimumStock" >> operator="greater-equals" type="Double"> >> >> So basically you are making sure that the QOH total starts out being >> greater than minimum stock before issuing a requirement. Thus, if >> the item is already below minimum stock, no more requirements will be >> created. >> >> I think we should change this code so that: >> 1. We should always calculate what the new QOH will be >> 2. If the new QOH is below the minimum stock, then first see if a >> requirement for this facility and product already exists and is in >> the state of CREATED. If it is, then update this requirement with >> the new quantity. If not, then create a new requirement. >> >> That way, as an item is continuously ordered, the amount required is >> added to, until a person can intervene and order it. >> >> Also, do you think the Requirements should have the facilityId field >> filled in. >> >> Finally, in the order manager, are you using the requirement status >> to control which requirements can be used to add to the order? If >> not, should we do that? >> >> >> Si >> > > > _______________________________________________ > Users mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/users > _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
Jacopo,
I just noticed that the requirements for "Automatic on Every Order" products allows the Purchase and Sales Order items to be linked. This is a really nice feature. How do I implement requirements for QOH/ATP quantity triggers that also allows PO-SO items to be linked? Do you think I should create a new requirement each time it is triggered, in quantity equal to the additional quantity required? Si Si Chen wrote: > Hi Jacopo, > > I am now wondering if my original idea was good. Which do you think > is better - > 1. Keep adding to one requirement for the product and facility > combination - or > 2. Create a separate requirement for each item issuance or order > item, so we can trace back to the original order? That way, we can > trace from a purchase order back to the original sales order or item > issuance. > > What was your original idea behind the requirements? If we implement > (1), how do we make it so that we can relate the original order item > or item issuance to the requirement and thru to purchase orders? > > Thanks! > > Si > > Jacopo Cappellato wrote: > >> Si, >> >> these are all good points. >> It's true, I'm not considering pending requirements (i.e. >> requirements in the CREATED or APPROVED status) in the >> checkCreateStockRequirement service. >> I made the assumption that the reorder quantity (and the lead times) >> is properly set to cope with the average number of incoming orders >> and so I kept things very simple: when the minimum quantity is >> reached one requirement for the reorder quantity is created (this new >> requirement SHOULD be sufficient for the average number of orders >> entered from now on at least for the next few weeks). >> >> By the way, your approach is better than mine so it would be very >> nice to see it implemented. >> >> About the facilityId field: yes, it would be nice to fill it, however >> under some circumstances it's difficult to say for which facility we >> are creating the requirement... >> >> About your last question about requirements' status: >> >> yes, the requirements' status is considered when the requirement is >> added to an order; in the order entry page you can only see >> requirements in the APPROVED status; at now you can approve a >> requirement in two ways: >> - by editing the requirement in the ordermgr >> - by selecting the requirement in the "Approve requirements" page in >> the manufacturing component >> When the order is checked out, the requirements' status is changed to >> ORDERED. >> We should only update the quantity of the requirements in CREATED >> status, not APPROVED. >> >> Jacopo >> >> Si Chen wrote: >> >>> Jacopo - >>> >>> Found what I think might be the issue: >>> >>> in checkCreateStockRequirement, you have this if statement: >>> >>> <if-compare-field field-name="quantityOnHandTotal" >>> to-field-name="productFacility.minimumStock" >>> operator="greater-equals" type="Double"> >>> >>> So basically you are making sure that the QOH total starts out being >>> greater than minimum stock before issuing a requirement. Thus, if >>> the item is already below minimum stock, no more requirements will >>> be created. >>> >>> I think we should change this code so that: >>> 1. We should always calculate what the new QOH will be >>> 2. If the new QOH is below the minimum stock, then first see if a >>> requirement for this facility and product already exists and is in >>> the state of CREATED. If it is, then update this requirement with >>> the new quantity. If not, then create a new requirement. >>> >>> That way, as an item is continuously ordered, the amount required is >>> added to, until a person can intervene and order it. >>> >>> Also, do you think the Requirements should have the facilityId field >>> filled in. >>> >>> Finally, in the order manager, are you using the requirement status >>> to control which requirements can be used to add to the order? If >>> not, should we do that? >>> >>> >>> Si >>> >> >> >> _______________________________________________ >> Users mailing list >> [hidden email] >> http://lists.ofbiz.org/mailman/listinfo/users >> > > _______________________________________________ > 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 - generating minimum stock requirements
|
|
Si,
yes, the "Automatic on Every Order" requirements create a link between the original sales order and the purchase order created from the requirement: sales order --> auto requirement --> purchase order |________________________________________^ I also think this is a nice feature: in fact I implemented it a few months ago according with your requests ;-) On the other hand I'm not sure it is correct to follow the same path for the requirements generated by stock levels: they are typically requirements that should be made for the warehouse and not for a specific sales order. In order to better explain my original idea, here is an example: Let's say that my company sells about 100 pieces (this is an average number based on statistics) of WG-1111 every month; the average number of sales order items for this product is 20 (so the average number of pieces sold in each order is 5). The average lead time to receive WG-1111 from the supplier of 10 days (from the date of the purchase order). Let's say I set the following info in the ProductFacility: minimumQuantity = 50, reorderQuantity = 200, leadTime = 10 Let's say I select the "Auto Requirements on stock levels" method for WG-1111. Let's say I have in stock 60 pieces of WG-1111. Then I get the sales order 10000 for 5 pieces --> QOH = 55 Then I get the sales order 10001 for 4 pieces --> QOH = 51 Then I get the sales order 10002 for 6 pieces --> QOH = 45 A requirement is automatically generated for WG-1111 with quantity = 200 (this is the reorder quantity) because we have reached the minimum level of 50 pieces The requirement is transformed into a purchase order of 200 pieces of WG-1111 The purchase order is not linked to a sales order (because it is made for the warehouse) Then I get the sales order 10003 for 10 pieces --> QOH = 35 Then I get the sales order 10004 for 2 pieces --> QOH = 33 Then I get the sales order 10005 for 13 pieces --> QOH = 20 The purchase order is received, so QOH is now 220 etc... what do you think about this? Jacopo Si Chen wrote: > Jacopo, > > I just noticed that the requirements for "Automatic on Every Order" > products allows the Purchase and Sales Order items to be linked. This > is a really nice feature. How do I implement requirements for QOH/ATP > quantity triggers that also allows PO-SO items to be linked? > > Do you think I should create a new requirement each time it is > triggered, in quantity equal to the additional quantity required? > > Si > > Si Chen wrote: > >> Hi Jacopo, >> >> I am now wondering if my original idea was good. Which do you think >> is better - >> 1. Keep adding to one requirement for the product and facility >> combination - or >> 2. Create a separate requirement for each item issuance or order >> item, so we can trace back to the original order? That way, we can >> trace from a purchase order back to the original sales order or item >> issuance. >> >> What was your original idea behind the requirements? If we implement >> (1), how do we make it so that we can relate the original order item >> or item issuance to the requirement and thru to purchase orders? >> >> Thanks! >> >> Si >> >> Jacopo Cappellato wrote: >> >>> Si, >>> >>> these are all good points. >>> It's true, I'm not considering pending requirements (i.e. >>> requirements in the CREATED or APPROVED status) in the >>> checkCreateStockRequirement service. >>> I made the assumption that the reorder quantity (and the lead times) >>> is properly set to cope with the average number of incoming orders >>> and so I kept things very simple: when the minimum quantity is >>> reached one requirement for the reorder quantity is created (this new >>> requirement SHOULD be sufficient for the average number of orders >>> entered from now on at least for the next few weeks). >>> >>> By the way, your approach is better than mine so it would be very >>> nice to see it implemented. >>> >>> About the facilityId field: yes, it would be nice to fill it, however >>> under some circumstances it's difficult to say for which facility we >>> are creating the requirement... >>> >>> About your last question about requirements' status: >>> >>> yes, the requirements' status is considered when the requirement is >>> added to an order; in the order entry page you can only see >>> requirements in the APPROVED status; at now you can approve a >>> requirement in two ways: >>> - by editing the requirement in the ordermgr >>> - by selecting the requirement in the "Approve requirements" page in >>> the manufacturing component >>> When the order is checked out, the requirements' status is changed to >>> ORDERED. >>> We should only update the quantity of the requirements in CREATED >>> status, not APPROVED. >>> >>> Jacopo >>> >>> Si Chen wrote: >>> >>>> Jacopo - >>>> >>>> Found what I think might be the issue: >>>> >>>> in checkCreateStockRequirement, you have this if statement: >>>> >>>> <if-compare-field field-name="quantityOnHandTotal" >>>> to-field-name="productFacility.minimumStock" >>>> operator="greater-equals" type="Double"> >>>> >>>> So basically you are making sure that the QOH total starts out being >>>> greater than minimum stock before issuing a requirement. Thus, if >>>> the item is already below minimum stock, no more requirements will >>>> be created. >>>> >>>> I think we should change this code so that: >>>> 1. We should always calculate what the new QOH will be >>>> 2. If the new QOH is below the minimum stock, then first see if a >>>> requirement for this facility and product already exists and is in >>>> the state of CREATED. If it is, then update this requirement with >>>> the new quantity. If not, then create a new requirement. >>>> >>>> That way, as an item is continuously ordered, the amount required is >>>> added to, until a person can intervene and order it. >>>> >>>> Also, do you think the Requirements should have the facilityId field >>>> filled in. >>>> >>>> Finally, in the order manager, are you using the requirement status >>>> to control which requirements can be used to add to the order? If >>>> not, should we do that? >>>> >>>> >>>> Si >>>> _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
Jacopo,
All done (SVN r5409). You can try it with this patch file (sorry, I can't commit to the product component). I also re-factored some of your simple-methods to re-use the code better. I had to implement a new feature in checkCreateStockRequirement -- if requirements already exist, I have to check if the total quantities from past requirements is already sufficient to cover the inventory shortfall. Does this apply to the rest of your application? Also, noticed a couple of other things along the way: 1. You can add requirements which aren't approved to the purchase order 2. The link to EditRequirement in Manufacturing from the order items is broken 3. When you add the same item from multiple requirements, they are consolidated to one item on the purchase order. Hence, the PO-SO link could not go back to all the items. Maybe we need to fix it so that items from separate requirements aren't added to the same shopping cart item? Thanks, Si Jacopo Cappellato wrote: > Si, > > yes, the "Automatic on Every Order" requirements create a link between > the original sales order and the purchase order created from the > requirement: > > sales order --> auto requirement --> purchase order > |________________________________________^ > > I also think this is a nice feature: in fact I implemented it a few > months ago according with your requests ;-) > > On the other hand I'm not sure it is correct to follow the same path > for the requirements generated by stock levels: they are typically > requirements that should be made for the warehouse and not for a > specific sales order. > > In order to better explain my original idea, here is an example: > > Let's say that my company sells about 100 pieces (this is an average > number based on statistics) of WG-1111 every month; the average number > of sales order items for this product is 20 (so the average number of > pieces sold in each order is 5). The average lead time to receive > WG-1111 from the supplier of 10 days (from the date of the purchase > order). > Let's say I set the following info in the ProductFacility: > minimumQuantity = 50, reorderQuantity = 200, leadTime = 10 > Let's say I select the "Auto Requirements on stock levels" method for > WG-1111. > Let's say I have in stock 60 pieces of WG-1111. > Then I get the sales order 10000 for 5 pieces --> QOH = 55 > Then I get the sales order 10001 for 4 pieces --> QOH = 51 > Then I get the sales order 10002 for 6 pieces --> QOH = 45 > A requirement is automatically generated for WG-1111 with quantity = > 200 (this is the reorder quantity) because we have reached the minimum > level of 50 pieces > The requirement is transformed into a purchase order of 200 pieces of > WG-1111 > The purchase order is not linked to a sales order (because it is made > for the warehouse) > Then I get the sales order 10003 for 10 pieces --> QOH = 35 > Then I get the sales order 10004 for 2 pieces --> QOH = 33 > Then I get the sales order 10005 for 13 pieces --> QOH = 20 > The purchase order is received, so QOH is now 220 > etc... > > what do you think about this? > > Jacopo > > > > > > > Si Chen wrote: > >> Jacopo, >> >> I just noticed that the requirements for "Automatic on Every Order" >> products allows the Purchase and Sales Order items to be linked. >> This is a really nice feature. How do I implement requirements for >> QOH/ATP quantity triggers that also allows PO-SO items to be linked? >> >> Do you think I should create a new requirement each time it is >> triggered, in quantity equal to the additional quantity required? >> >> Si >> >> Si Chen wrote: >> >>> Hi Jacopo, >>> >>> I am now wondering if my original idea was good. Which do you think >>> is better - >>> 1. Keep adding to one requirement for the product and facility >>> combination - or >>> 2. Create a separate requirement for each item issuance or order >>> item, so we can trace back to the original order? That way, we can >>> trace from a purchase order back to the original sales order or item >>> issuance. >>> >>> What was your original idea behind the requirements? If we >>> implement (1), how do we make it so that we can relate the original >>> order item or item issuance to the requirement and thru to purchase >>> orders? >>> >>> Thanks! >>> >>> Si >>> >>> Jacopo Cappellato wrote: >>> >>>> Si, >>>> >>>> these are all good points. >>>> It's true, I'm not considering pending requirements (i.e. >>>> requirements in the CREATED or APPROVED status) in the >>>> checkCreateStockRequirement service. >>>> I made the assumption that the reorder quantity (and the lead >>>> times) is properly set to cope with the average number of incoming >>>> orders and so I kept things very simple: when the minimum quantity >>>> is reached one requirement for the reorder quantity is created >>>> (this new requirement SHOULD be sufficient for the average number >>>> of orders entered from now on at least for the next few weeks). >>>> >>>> By the way, your approach is better than mine so it would be very >>>> nice to see it implemented. >>>> >>>> About the facilityId field: yes, it would be nice to fill it, >>>> however under some circumstances it's difficult to say for which >>>> facility we are creating the requirement... >>>> >>>> About your last question about requirements' status: >>>> >>>> yes, the requirements' status is considered when the requirement is >>>> added to an order; in the order entry page you can only see >>>> requirements in the APPROVED status; at now you can approve a >>>> requirement in two ways: >>>> - by editing the requirement in the ordermgr >>>> - by selecting the requirement in the "Approve requirements" page >>>> in the manufacturing component >>>> When the order is checked out, the requirements' status is changed >>>> to ORDERED. >>>> We should only update the quantity of the requirements in CREATED >>>> status, not APPROVED. >>>> >>>> Jacopo >>>> >>>> Si Chen wrote: >>>> >>>>> Jacopo - >>>>> >>>>> Found what I think might be the issue: >>>>> >>>>> in checkCreateStockRequirement, you have this if statement: >>>>> >>>>> <if-compare-field field-name="quantityOnHandTotal" >>>>> to-field-name="productFacility.minimumStock" >>>>> operator="greater-equals" type="Double"> >>>>> >>>>> So basically you are making sure that the QOH total starts out >>>>> being greater than minimum stock before issuing a requirement. >>>>> Thus, if the item is already below minimum stock, no more >>>>> requirements will be created. >>>>> >>>>> I think we should change this code so that: >>>>> 1. We should always calculate what the new QOH will be >>>>> 2. If the new QOH is below the minimum stock, then first see if a >>>>> requirement for this facility and product already exists and is in >>>>> the state of CREATED. If it is, then update this requirement with >>>>> the new quantity. If not, then create a new requirement. >>>>> >>>>> That way, as an item is continuously ordered, the amount required >>>>> is added to, until a person can intervene and order it. >>>>> >>>>> Also, do you think the Requirements should have the facilityId >>>>> field filled in. >>>>> >>>>> Finally, in the order manager, are you using the requirement >>>>> status to control which requirements can be used to add to the >>>>> order? If not, should we do that? >>>>> >>>>> >>>>> Si >>>>> > > > _______________________________________________ > Users mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/users > Index: product/data/ProductTypeData.xml =================================================================== --- product/data/ProductTypeData.xml (revision 5355) +++ product/data/ProductTypeData.xml (working copy) @@ -301,8 +301,9 @@ <Enumeration description="Automatic For Every Sales Order" enumCode="AUTO" enumId="PRODRQM_AUTO" sequenceId="02" enumTypeId="PROD_REQ_METHOD"/> <!-- STOCK: a requirement is created when qoh reaches the minimum stock quantity (from ProductFacility) --> <Enumeration description="When QOH Reaches Minimum Stock for Product-Facility" enumCode="STOCK" enumId="PRODRQM_STOCK" sequenceId="03" enumTypeId="PROD_REQ_METHOD"/> + <!-- ATP: a requirement is created when atp reaches the minimum stock quantity (from ProductFacility) --> + <Enumeration description="When ATP Reaches Minimum Stock for Product-Facility" enumCode="STOCK" enumId="PRODRQM_STOCK_ATP" sequenceId="04" enumTypeId="PROD_REQ_METHOD"/> - <!-- inventory item status --> <StatusType description="Inventory Item" hasTable="N" parentTypeId="" statusTypeId="INVENTORY_ITEM_STTS"/> <StatusType description="Serialized Inventory Item" hasTable="N" parentTypeId="INVENTORY_ITEM_STTS" statusTypeId="INV_SERIALIZED_STTS"/> _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: [OFBiz] Users - generating minimum stock requirements
|
|
Hi Si,
please see my comments inline: Si Chen wrote: > Jacopo, > > All done (SVN r5409). You can try it with this patch file (sorry, I > can't commit to the product component). Ok, I've added the new requirement method to the product's seed data. > I also re-factored some of your simple-methods to re-use the code > better. I had to implement a new feature in checkCreateStockRequirement > -- if requirements already exist, I have to check if the total > quantities from past requirements is already sufficient to cover the > inventory shortfall. Does this apply to the rest of your application? > I had a quick look at your work and it seems excellent: many thanks for all the improvements you've introduced. > Also, noticed a couple of other things along the way: > 1. You can add requirements which aren't approved to the purchase order This is now fixed in svn rev 5413 > 2. The link to EditRequirement in Manufacturing from the order items is > broken Are you sure? It works for me... could you give me more info please? > 3. When you add the same item from multiple requirements, they are > consolidated to one item on the purchase order. Hence, the PO-SO link > could not go back to all the items. Maybe we need to fix it so that > items from separate requirements aren't added to the same shopping cart > item? > This should be fixed in SVN with rev 5414. > Thanks, > > Si > Thanks, Jacopo _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
Jacopo,
Thanks! Everything looks great. I saw your comments in the commit: However I think that we should standardize the requirements types; for example, what are the types that can be fulfilled by a production run? what are the types that can be fulfilled by a purchase order? What do you mean by this? Si Jacopo Cappellato wrote: > Hi Si, > > please see my comments inline: > > Si Chen wrote: > >> Jacopo, >> >> All done (SVN r5409). You can try it with this patch file (sorry, I >> can't commit to the product component). > > > Ok, I've added the new requirement method to the product's seed data. > >> I also re-factored some of your simple-methods to re-use the code >> better. I had to implement a new feature in >> checkCreateStockRequirement -- if requirements already exist, I have >> to check if the total quantities from past requirements is already >> sufficient to cover the inventory shortfall. Does this apply to the >> rest of your application? >> > > I had a quick look at your work and it seems excellent: many thanks for > all the improvements you've introduced. > >> Also, noticed a couple of other things along the way: >> 1. You can add requirements which aren't approved to the purchase order > > > This is now fixed in svn rev 5413 > >> 2. The link to EditRequirement in Manufacturing from the order items >> is broken > > > Are you sure? It works for me... could you give me more info please? > >> 3. When you add the same item from multiple requirements, they are >> consolidated to one item on the purchase order. Hence, the PO-SO >> link could not go back to all the items. Maybe we need to fix it so >> that items from separate requirements aren't added to the same >> shopping cart item? >> > > This should be fixed in SVN with rev 5414. > > >> Thanks, >> >> Si >> > > Thanks, > > Jacopo > > > _______________________________________________ > 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 - generating minimum stock requirements
|
|
Hi Si,
I mean that we should make clear the meaning of the requirements' types; the MRP process generates two kind of requirements: MRP_PRO_PURCH_ORDER this can generate a purchase order MRP_PRO_PROD_ORDER this can generate a production run the three auto requirement methods generate the following requirements' type: PRODUCT_REQUIREMENT that can generate a purchase order It would be interesting to have also auto requirements' methods that create requirements for prodution runs. In general, it would be nice to review the names of all the RequirementTypes to make their meaning more clear. What do you think? Jacopo Si Chen wrote: > Jacopo, > > Thanks! Everything looks great. > > I saw your comments in the commit: > > However I think that we should standardize the requirements types; for > example, what are the types that can be fulfilled by a production run? > what are the types that can be fulfilled by a purchase order? > > What do you mean by this? > > Si > _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
Jacopo,
Is it necessary to fix the type of requirement so that it can only be fulfilled by a purchase order or production run? It might be nice so that once requirements are generated, products can be bought from the outside or manufactured internally. I know some companies that do both, depending on whichever is cheaper and how much capacity is available in house. Si Jacopo Cappellato wrote: > Hi Si, > > I mean that we should make clear the meaning of the requirements' types; > the MRP process generates two kind of requirements: > MRP_PRO_PURCH_ORDER this can generate a purchase order > MRP_PRO_PROD_ORDER this can generate a production run > the three auto requirement methods generate the following > requirements' type: > PRODUCT_REQUIREMENT that can generate a purchase order > > It would be interesting to have also auto requirements' methods that > create requirements for prodution runs. > In general, it would be nice to review the names of all the > RequirementTypes to make their meaning more clear. > > What do you think? > > Jacopo > > Si Chen wrote: > >> Jacopo, >> >> Thanks! Everything looks great. >> >> I saw your comments in the commit: >> >> However I think that we should standardize the requirements types; >> for example, what are the types that can be fulfilled by a production >> run? what are the types that can be fulfilled by a purchase order? >> >> What do you mean by this? >> >> Si >> > > > _______________________________________________ > 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 - generating minimum stock requirements
|
|
Si (and other interested),
I think that this is a very interesting discussion. In my opinion, even if under some circumstances it would be nice to have a 'generic' requirement (that can be fulfilled by a purchase or manufacturing order), it is often better to have requirements for purchase or manufacturing orders automatically generated: 1) first of all, to avoid to leave to the user the task to manually divide purchase requirements by manufacturing requirements 2) second because However you are totally right when you say that the same product could be purchased or manufactured depending on many factors (work or tools availability, cost, time available etc...): in fact it is a very common approach of many ERP systems, to set the supply strategy (purchase, manufacture, transfer from another warehouse) at product-facility level, instead of product level. So for example, we could stock the product WG-1111 into the manufacturing warehouse FACILITY_MAN (with 'manufacturing' supply strategy) and into the distribution warehouse FACILITY_WAR (with the 'transfer' supply strategy). So, if the product's minimum qty is reached in FACILITY_MAN then a requirement for a manufacturing order is created, if the product's minimum qty is reached in FACILITY_WAR then a requirement for a distribution order is created (to transfer the product from FACILITY_MAN to FACILITY_WAR); in the same way we could have a facility with a 'purchase' supply strategy. Now, back to OFBIz. How could we store this information into the data model? Probably the best solution is to add a new field to the ProductFacility entity. However, it is very important, when taking a sales order, to know exactly the facility we should look at (thru product store?), in order to know the supply strategy. I'd like to hear your opinion! Thanks, Jacopo Si Chen wrote: > Jacopo, > > Is it necessary to fix the type of requirement so that it can only be > fulfilled by a purchase order or production run? It might be nice so > that once requirements are generated, products can be bought from the > outside or manufactured internally. I know some companies that do both, > depending on whichever is cheaper and how much capacity is available in > house. > > Si > > Jacopo Cappellato wrote: > >> Hi Si, >> >> I mean that we should make clear the meaning of the requirements' types; >> the MRP process generates two kind of requirements: >> MRP_PRO_PURCH_ORDER this can generate a purchase order >> MRP_PRO_PROD_ORDER this can generate a production run >> the three auto requirement methods generate the following >> requirements' type: >> PRODUCT_REQUIREMENT that can generate a purchase order >> >> It would be interesting to have also auto requirements' methods that >> create requirements for prodution runs. >> In general, it would be nice to review the names of all the >> RequirementTypes to make their meaning more clear. >> >> What do you think? >> >> Jacopo >> >> Si Chen wrote: >> >>> Jacopo, >>> >>> Thanks! Everything looks great. >>> >>> I saw your comments in the commit: >>> >>> However I think that we should standardize the requirements types; >>> for example, what are the types that can be fulfilled by a production >>> run? what are the types that can be fulfilled by a purchase order? >>> >>> What do you mean by this? >>> >>> Si >>> >> >> >> _______________________________________________ >> Users mailing list >> [hidden email] >> http://lists.ofbiz.org/mailman/listinfo/users >> > > _______________________________________________ > Users mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/users > > _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
Just my opinion- I think it's hard to know when taking the order how it
should be fulfilled. One thing we could do is sub-type the requirement types. Then, we could create the requirement as generic requirements, then provide a screen to classify generic requirements into either purchase or manufacture or inventory transfer requirements. We could also allow the particular implementation to create a service that can hook in as a seca to automate this if necessary. Si Jacopo Cappellato wrote: > Si (and other interested), > > I think that this is a very interesting discussion. > In my opinion, even if under some circumstances it would be nice to > have a 'generic' requirement (that can be fulfilled by a purchase or > manufacturing order), it is often better to have requirements for > purchase or manufacturing orders automatically generated: > 1) first of all, to avoid to leave to the user the task to manually > divide purchase requirements by manufacturing requirements > 2) second because > > However you are totally right when you say that the same product could > be purchased or manufactured depending on many factors (work or tools > availability, cost, time available etc...): in fact it is a very > common approach of many ERP systems, to set the supply strategy > (purchase, manufacture, transfer from another warehouse) at > product-facility level, instead of product level. > So for example, we could stock the product WG-1111 into the > manufacturing warehouse FACILITY_MAN (with 'manufacturing' supply > strategy) and into the distribution warehouse FACILITY_WAR (with the > 'transfer' supply strategy). > So, if the product's minimum qty is reached in FACILITY_MAN then a > requirement for a manufacturing order is created, if the product's > minimum qty is reached in FACILITY_WAR then a requirement for a > distribution order is created (to transfer the product from > FACILITY_MAN to FACILITY_WAR); in the same way we could have a > facility with a 'purchase' supply strategy. > > Now, back to OFBIz. How could we store this information into the data > model? Probably the best solution is to add a new field to the > ProductFacility entity. > However, it is very important, when taking a sales order, to know > exactly the facility we should look at (thru product store?), in order > to know the supply strategy. > > I'd like to hear your opinion! > > Thanks, > > Jacopo > > > Si Chen wrote: > >> Jacopo, >> >> Is it necessary to fix the type of requirement so that it can only be >> fulfilled by a purchase order or production run? It might be nice so >> that once requirements are generated, products can be bought from the >> outside or manufactured internally. I know some companies that do >> both, depending on whichever is cheaper and how much capacity is >> available in house. >> >> Si >> >> Jacopo Cappellato wrote: >> >>> Hi Si, >>> >>> I mean that we should make clear the meaning of the requirements' >>> types; >>> the MRP process generates two kind of requirements: >>> MRP_PRO_PURCH_ORDER this can generate a purchase order >>> MRP_PRO_PROD_ORDER this can generate a production run >>> the three auto requirement methods generate the following >>> requirements' type: >>> PRODUCT_REQUIREMENT that can generate a purchase order >>> >>> It would be interesting to have also auto requirements' methods that >>> create requirements for prodution runs. >>> In general, it would be nice to review the names of all the >>> RequirementTypes to make their meaning more clear. >>> >>> What do you think? >>> >>> Jacopo >>> >>> Si Chen wrote: >>> >>>> Jacopo, >>>> >>>> Thanks! Everything looks great. >>>> >>>> I saw your comments in the commit: >>>> >>>> However I think that we should standardize the requirements types; >>>> for example, what are the types that can be fulfilled by a >>>> production run? what are the types that can be fulfilled by a >>>> purchase order? >>>> >>>> What do you mean by this? >>>> >>>> Si >>>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> [hidden email] >>> http://lists.ofbiz.org/mailman/listinfo/users >>> >> >> _______________________________________________ >> Users mailing list >> [hidden email] >> http://lists.ofbiz.org/mailman/listinfo/users >> >> > > > > > _______________________________________________ > Users mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/users > _______________________________________________ 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 |