more than one unit of measue fo the same product: advice requested.
Locked
12
12
more than one unit of measue fo the same product: advice requested.
 
|
Re: more than one unit of measue fo the same product: advice requested.
|
|
Re: more than one unit of measue fo the same product: advice requested.
|
Re: more than one unit of measue fo the same product: advice requested.
|
|
Hi Hans,
Sorry if this is a silly question, but why not just use different products for different UOMs? You could use virtual/variants if you wanted the UOM to be selectable on a single product page and also marketing packages to automatically produce inventory for the desired UOM from the base UOM. Regards Scott HotWax Media http://www.hotwaxmedia.com On 3/10/2010, at 3:54 PM, Hans Bakker wrote: > Thank you BJ, > > I had in mind to create and 'productUomAlternatives' table to the > product with a conversion for example from pieces to boxes with an > optional price adjustment percentage. > The system will have however only one uom where everything gets > converted to. > > Anybody else other solutions? > > Regards, > Hans. > > > On Sat, 2010-10-02 at 10:21 -0700, BJ Freeman wrote: >> Yes also like a Feed store will have boxes, Sacks, and loose feed. >> I used the multiple pricing model for the Uom Measure >> in the product screen made it allow multiple UOM. >> >> added to the code that converts from what is received in inventory to >> what is sold so it walks through the Uom. for instance a feed store >> Receives feed in Bulk and then sacks it as inventory is required. >> The Inventory levels have to be checked to see how many in a product >> run to generate to sack up the grain. This Triggers an Seca. >> >> >> I think a nice touch would be that the could generates the product data >> to show up in orders, based on the Uoms that were generated for the >> products. it would follow the same model for inventory levels on the >> orderentry and Ecommerce >> >> >> Hans Bakker sent the following on 10/2/2010 4:29 AM: >>> A question to the community: >>> >>> sometimes the same products are sold with different units of measure. >>> Example gold jewelry. >>> >>> Per piece, per box of 10, per box of 50 and per gram gold weight. >>> >>> Is here a preference how to implement that? >>> >>> Remember this has to show up in e-commerce, orders, shipments and >>> invoices... >>> >>> Regards, >>> Hans >>> >> > > -- > Ofbiz on twitter: http://twitter.com/apache_ofbiz > Myself on twitter: http://twitter.com/hansbak > Antwebsystems.com: Quality services for competitive rates. > |
smime.p7s (3K)
Re: more than one unit of measue fo the same product: advice requested.
|
|
Re: more than one unit of measue fo the same product: advice requested.
|
|
If you were to go the marketing package route, the box of 10 would be the marketing package and the single piece would be the product that all inventory is stored against. The ProductAssoc (type "component" I think) between the box of 10 and the piece would have a quantity of 10. Whenever the box is ordered the system would automatically create a production run which will convert 10 pieces into 1 box.
So you have a standard finished good as your lowest UOM and then each higher UOM is a marketing package with the conversion factor stored in ProductAssoc.quantity. I can't remember exactly if it is the case, but I think marketing packages are capable of deriving the selling price from the components if a ProductPrice isn't defined for it, in that way you'd only need to maintain specific prices when you need to provide a lower cost for ordering in bulk. Regards Scott On 3/10/2010, at 6:02 PM, Hans Bakker wrote: > Hi Scott, this is sure an interesting idea, but then how does the system > know that they are for example 10 pieces in a box? I still what to have > the same inventory for boxes and pieces. > We should be able to store the conversion between the uom's for this > product somewhere? > > Thanks for you input! > > Regards, > Hans > > On Sun, 2010-10-03 at 17:39 +1300, Scott Gray wrote: >> Hi Hans, >> >> Sorry if this is a silly question, but why not just use different products for different UOMs? You could use virtual/variants if you wanted the UOM to be selectable on a single product page and also marketing packages to automatically produce inventory for the desired UOM from the base UOM. >> >> Regards >> Scott >> >> HotWax Media >> http://www.hotwaxmedia.com >> >> On 3/10/2010, at 3:54 PM, Hans Bakker wrote: >> >>> Thank you BJ, >>> >>> I had in mind to create and 'productUomAlternatives' table to the >>> product with a conversion for example from pieces to boxes with an >>> optional price adjustment percentage. >>> The system will have however only one uom where everything gets >>> converted to. >>> >>> Anybody else other solutions? >>> >>> Regards, >>> Hans. >>> >>> >>> On Sat, 2010-10-02 at 10:21 -0700, BJ Freeman wrote: >>>> Yes also like a Feed store will have boxes, Sacks, and loose feed. >>>> I used the multiple pricing model for the Uom Measure >>>> in the product screen made it allow multiple UOM. >>>> >>>> added to the code that converts from what is received in inventory to >>>> what is sold so it walks through the Uom. for instance a feed store >>>> Receives feed in Bulk and then sacks it as inventory is required. >>>> The Inventory levels have to be checked to see how many in a product >>>> run to generate to sack up the grain. This Triggers an Seca. >>>> >>>> >>>> I think a nice touch would be that the could generates the product data >>>> to show up in orders, based on the Uoms that were generated for the >>>> products. it would follow the same model for inventory levels on the >>>> orderentry and Ecommerce >>>> >>>> >>>> Hans Bakker sent the following on 10/2/2010 4:29 AM: >>>>> A question to the community: >>>>> >>>>> sometimes the same products are sold with different units of measure. >>>>> Example gold jewelry. >>>>> >>>>> Per piece, per box of 10, per box of 50 and per gram gold weight. >>>>> >>>>> Is here a preference how to implement that? >>>>> >>>>> Remember this has to show up in e-commerce, orders, shipments and >>>>> invoices... >>>>> >>>>> Regards, >>>>> Hans >>>>> >>>> >>> >>> -- >>> Ofbiz on twitter: http://twitter.com/apache_ofbiz >>> Myself on twitter: http://twitter.com/hansbak >>> Antwebsystems.com: Quality services for competitive rates. >>> >> > > -- > Ofbiz on twitter: http://twitter.com/apache_ofbiz > Myself on twitter: http://twitter.com/hansbak > Antwebsystems.com: Quality services for competitive rates. > |
Re: more than one unit of measue fo the same product: advice requested.
|
|
Re: more than one unit of measue fo the same product: advice requested.
|
|
Re: more than one unit of measue fo the same product: advice requested.
|
|
Hi Hans,
I'm not sure I understand what you proposed, could you explain it further? Virtual/variants and the marketing packages would serve different purposes in what I was suggesting, the marketing packages would serve to convert the base uom product to each of the marketing package's uom whereas the virtual/variant would just serve to combine all uom products under a single virtual product. Each variant would be a marketing package except for the base uom product which would be a regular finished good. Marketing packages do cause an automatic production run to be created and completed, but I don't really see that as a big deal. It serves as a record for the conversion and also if the base uom doesn't have enough inventory available then the production run is left open until more is available, so it serves well as a reservation mechanism of sorts as well. Production runs have always been our primary mechanism of converting one or more products into a different product which is exactly what is happening here. Marketing packages/production runs also support decomposing manufactured products back into their original components which would serve you well for returns and the like. Regards Scott On 3/10/2010, at 8:52 PM, Hans Bakker wrote: > But involving the complete manufacturing process? please have a look at > my earlier message about adding a field to the productassoc entity.... > > On Sun, 2010-10-03 at 18:13 +1300, Scott Gray wrote: >> If you were to go the marketing package route, the box of 10 would be the marketing package and the single piece would be the product that all inventory is stored against. The ProductAssoc (type "component" I think) between the box of 10 and the piece would have a quantity of 10. Whenever the box is ordered the system would automatically create a production run which will convert 10 pieces into 1 box. >> >> So you have a standard finished good as your lowest UOM and then each higher UOM is a marketing package with the conversion factor stored in ProductAssoc.quantity. I can't remember exactly if it is the case, but I think marketing packages are capable of deriving the selling price from the components if a ProductPrice isn't defined for it, in that way you'd only need to maintain specific prices when you need to provide a lower cost for ordering in bulk. >> >> Regards >> Scott >> >> On 3/10/2010, at 6:02 PM, Hans Bakker wrote: >> >>> Hi Scott, this is sure an interesting idea, but then how does the system >>> know that they are for example 10 pieces in a box? I still what to have >>> the same inventory for boxes and pieces. >>> We should be able to store the conversion between the uom's for this >>> product somewhere? >>> >>> Thanks for you input! >>> >>> Regards, >>> Hans >>> >>> On Sun, 2010-10-03 at 17:39 +1300, Scott Gray wrote: >>>> Hi Hans, >>>> >>>> Sorry if this is a silly question, but why not just use different products for different UOMs? You could use virtual/variants if you wanted the UOM to be selectable on a single product page and also marketing packages to automatically produce inventory for the desired UOM from the base UOM. >>>> >>>> Regards >>>> Scott >>>> >>>> HotWax Media >>>> http://www.hotwaxmedia.com >>>> >>>> On 3/10/2010, at 3:54 PM, Hans Bakker wrote: >>>> >>>>> Thank you BJ, >>>>> >>>>> I had in mind to create and 'productUomAlternatives' table to the >>>>> product with a conversion for example from pieces to boxes with an >>>>> optional price adjustment percentage. >>>>> The system will have however only one uom where everything gets >>>>> converted to. >>>>> >>>>> Anybody else other solutions? >>>>> >>>>> Regards, >>>>> Hans. >>>>> >>>>> >>>>> On Sat, 2010-10-02 at 10:21 -0700, BJ Freeman wrote: >>>>>> Yes also like a Feed store will have boxes, Sacks, and loose feed. >>>>>> I used the multiple pricing model for the Uom Measure >>>>>> in the product screen made it allow multiple UOM. >>>>>> >>>>>> added to the code that converts from what is received in inventory to >>>>>> what is sold so it walks through the Uom. for instance a feed store >>>>>> Receives feed in Bulk and then sacks it as inventory is required. >>>>>> The Inventory levels have to be checked to see how many in a product >>>>>> run to generate to sack up the grain. This Triggers an Seca. >>>>>> >>>>>> >>>>>> I think a nice touch would be that the could generates the product data >>>>>> to show up in orders, based on the Uoms that were generated for the >>>>>> products. it would follow the same model for inventory levels on the >>>>>> orderentry and Ecommerce >>>>>> >>>>>> >>>>>> Hans Bakker sent the following on 10/2/2010 4:29 AM: >>>>>>> A question to the community: >>>>>>> >>>>>>> sometimes the same products are sold with different units of measure. >>>>>>> Example gold jewelry. >>>>>>> >>>>>>> Per piece, per box of 10, per box of 50 and per gram gold weight. >>>>>>> >>>>>>> Is here a preference how to implement that? >>>>>>> >>>>>>> Remember this has to show up in e-commerce, orders, shipments and >>>>>>> invoices... >>>>>>> >>>>>>> Regards, >>>>>>> Hans >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz >>>>> Myself on twitter: http://twitter.com/hansbak >>>>> Antwebsystems.com: Quality services for competitive rates. >>>>> >>>> >>> >>> -- >>> Ofbiz on twitter: http://twitter.com/apache_ofbiz >>> Myself on twitter: http://twitter.com/hansbak >>> Antwebsystems.com: Quality services for competitive rates. >>> >> > > -- > Ofbiz on twitter: http://twitter.com/apache_ofbiz > Myself on twitter: http://twitter.com/hansbak > Antwebsystems.com: Quality services for competitive rates. > |
Re: more than one unit of measue fo the same product: advice requested.
|
|
Re: more than one unit of measue fo the same product: advice requested.
|
|
You wouldn't use marketing packages in that situation, you'd just use regular products and regular production runs.
Regards Scott On 4/10/2010, at 12:07 AM, BJ Freeman wrote: > how would the marketing package allow for inventory levels to be established for different UOM. is marketing not a "Just in time" type of management? > What about inventory that takes long lead times to process, that would delay shipments beyond a reasonable time. This could be from too many products that need conversion beyond staff capability to handle orders, against processing a certain level of Inventory as stock, based on ERP. > > Scott Gray sent the following on 10/3/2010 2:15 AM: > > >> Hi Hans, >> >> I'm not sure I understand what you proposed, could you explain it further? >> >> Virtual/variants and the marketing packages would serve different purposes in what I was suggesting, the marketing packages would serve to convert the base uom product to each of the marketing package's uom whereas the virtual/variant would just serve to combine all uom products under a single virtual product. Each variant would be a marketing package except for the base uom product which would be a regular finished good. >> >> Marketing packages do cause an automatic production run to be created and completed, but I don't really see that as a big deal. It serves as a record for the conversion and also if the base uom doesn't have enough inventory available then the production run is left open until more is available, so it serves well as a reservation mechanism of sorts as well. Production runs have always been our primary mechanism of converting one or more products into a different product which is exactly what is happening here. Marketing packages/production runs also support decomposing manufactured products back into their original components which would serve you well for returns and the like. >> >> Regards >> Scott >> >> On 3/10/2010, at 8:52 PM, Hans Bakker wrote: >> >>> But involving the complete manufacturing process? please have a look at >>> my earlier message about adding a field to the productassoc entity.... >>> >>> On Sun, 2010-10-03 at 18:13 +1300, Scott Gray wrote: >>>> If you were to go the marketing package route, the box of 10 would be the marketing package and the single piece would be the product that all inventory is stored against. The ProductAssoc (type "component" I think) between the box of 10 and the piece would have a quantity of 10. Whenever the box is ordered the system would automatically create a production run which will convert 10 pieces into 1 box. >>>> >>>> So you have a standard finished good as your lowest UOM and then each higher UOM is a marketing package with the conversion factor stored in ProductAssoc.quantity. I can't remember exactly if it is the case, but I think marketing packages are capable of deriving the selling price from the components if a ProductPrice isn't defined for it, in that way you'd only need to maintain specific prices when you need to provide a lower cost for ordering in bulk. >>>> >>>> Regards >>>> Scott >>>> >>>> On 3/10/2010, at 6:02 PM, Hans Bakker wrote: >>>> >>>>> Hi Scott, this is sure an interesting idea, but then how does the system >>>>> know that they are for example 10 pieces in a box? I still what to have >>>>> the same inventory for boxes and pieces. >>>>> We should be able to store the conversion between the uom's for this >>>>> product somewhere? >>>>> >>>>> Thanks for you input! >>>>> >>>>> Regards, >>>>> Hans >>>>> >>>>> On Sun, 2010-10-03 at 17:39 +1300, Scott Gray wrote: >>>>>> Hi Hans, >>>>>> >>>>>> Sorry if this is a silly question, but why not just use different products for different UOMs? You could use virtual/variants if you wanted the UOM to be selectable on a single product page and also marketing packages to automatically produce inventory for the desired UOM from the base UOM. >>>>>> >>>>>> Regards >>>>>> Scott >>>>>> >>>>>> HotWax Media >>>>>> http://www.hotwaxmedia.com >>>>>> >>>>>> On 3/10/2010, at 3:54 PM, Hans Bakker wrote: >>>>>> >>>>>>> Thank you BJ, >>>>>>> >>>>>>> I had in mind to create and 'productUomAlternatives' table to the >>>>>>> product with a conversion for example from pieces to boxes with an >>>>>>> optional price adjustment percentage. >>>>>>> The system will have however only one uom where everything gets >>>>>>> converted to. >>>>>>> >>>>>>> Anybody else other solutions? >>>>>>> >>>>>>> Regards, >>>>>>> Hans. >>>>>>> >>>>>>> >>>>>>> On Sat, 2010-10-02 at 10:21 -0700, BJ Freeman wrote: >>>>>>>> Yes also like a Feed store will have boxes, Sacks, and loose feed. >>>>>>>> I used the multiple pricing model for the Uom Measure >>>>>>>> in the product screen made it allow multiple UOM. >>>>>>>> >>>>>>>> added to the code that converts from what is received in inventory to >>>>>>>> what is sold so it walks through the Uom. for instance a feed store >>>>>>>> Receives feed in Bulk and then sacks it as inventory is required. >>>>>>>> The Inventory levels have to be checked to see how many in a product >>>>>>>> run to generate to sack up the grain. This Triggers an Seca. >>>>>>>> >>>>>>>> >>>>>>>> I think a nice touch would be that the could generates the product data >>>>>>>> to show up in orders, based on the Uoms that were generated for the >>>>>>>> products. it would follow the same model for inventory levels on the >>>>>>>> orderentry and Ecommerce >>>>>>>> >>>>>>>> >>>>>>>> Hans Bakker sent the following on 10/2/2010 4:29 AM: >>>>>>>>> A question to the community: >>>>>>>>> >>>>>>>>> sometimes the same products are sold with different units of measure. >>>>>>>>> Example gold jewelry. >>>>>>>>> >>>>>>>>> Per piece, per box of 10, per box of 50 and per gram gold weight. >>>>>>>>> >>>>>>>>> Is here a preference how to implement that? >>>>>>>>> >>>>>>>>> Remember this has to show up in e-commerce, orders, shipments and >>>>>>>>> invoices... >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Hans >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz >>>>>>> Myself on twitter: http://twitter.com/hansbak >>>>>>> Antwebsystems.com: Quality services for competitive rates. >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz >>>>> Myself on twitter: http://twitter.com/hansbak >>>>> Antwebsystems.com: Quality services for competitive rates. >>>>> >>>> >>> >>> -- >>> Ofbiz on twitter: http://twitter.com/apache_ofbiz >>> Myself on twitter: http://twitter.com/hansbak >>> Antwebsystems.com: Quality services for competitive rates. >>> >> |
Re: more than one unit of measue fo the same product: advice requested.
|
|
Re: more than one unit of measue fo the same product: advice requested.
|
|
Re: more than one unit of measue fo the same product: advice requested.
|
|
Re: more than one unit of measue fo the same product: advice requested.
|
|
In reply to this post by BJ Freeman
I'm sorry you're not making any sense. I've explained how multiple UOMs are supported OOTB for both just-in-time conversion and for longer lived UOM inventory that may require effort to produce.
What is so wrong with the current functionality that we need to add new tables? How would a SECA on ProductPricing (?) populate the virtual/variants? For just-in-time conversion marketing packages are a very simple approach, you just select the product type and then setup a single ProductAssoc record to define the component Product and the quantity. Regards Scott On 4/10/2010, at 2:04 AM, BJ Freeman wrote: > So having a entity that defines the different UOM that can be sold in inventory would be a good Idea, at a minimum. > and as Hans Says have a price differential for each UOM. > use a SECA to trigger on the ProductPricing service to run a service to populate for the Virtual/variants > So all the user has todo is put fill in the new entity. > > Scott Gray sent the following on 10/3/2010 5:44 AM: >> You wouldn't use marketing packages in that situation, you'd just use regular products and regular production runs. >> >> Regards >> Scott >> >> On 4/10/2010, at 12:07 AM, BJ Freeman wrote: >> >>> how would the marketing package allow for inventory levels to be established for different UOM. is marketing not a "Just in time" type of management? >>> What about inventory that takes long lead times to process, that would delay shipments beyond a reasonable time. This could be from too many products that need conversion beyond staff capability to handle orders, against processing a certain level of Inventory as stock, based on ERP. >>> >>> Scott Gray sent the following on 10/3/2010 2:15 AM: >>> >>> >>>> Hi Hans, >>>> >>>> I'm not sure I understand what you proposed, could you explain it further? >>>> >>>> Virtual/variants and the marketing packages would serve different purposes in what I was suggesting, the marketing packages would serve to convert the base uom product to each of the marketing package's uom whereas the virtual/variant would just serve to combine all uom products under a single virtual product. Each variant would be a marketing package except for the base uom product which would be a regular finished good. >>>> >>>> Marketing packages do cause an automatic production run to be created and completed, but I don't really see that as a big deal. It serves as a record for the conversion and also if the base uom doesn't have enough inventory available then the production run is left open until more is available, so it serves well as a reservation mechanism of sorts as well. Production runs have always been our primary mechanism of converting one or more products into a different product which is exactly what is happening here. Marketing packages/production runs also support decomposing manufactured products back into their original components which would serve you well for returns and the like. >>>> >>>> Regards >>>> Scott >>>> >>>> On 3/10/2010, at 8:52 PM, Hans Bakker wrote: >>>> >>>>> But involving the complete manufacturing process? please have a look at >>>>> my earlier message about adding a field to the productassoc entity.... >>>>> >>>>> On Sun, 2010-10-03 at 18:13 +1300, Scott Gray wrote: >>>>>> If you were to go the marketing package route, the box of 10 would be the marketing package and the single piece would be the product that all inventory is stored against. The ProductAssoc (type "component" I think) between the box of 10 and the piece would have a quantity of 10. Whenever the box is ordered the system would automatically create a production run which will convert 10 pieces into 1 box. >>>>>> >>>>>> So you have a standard finished good as your lowest UOM and then each higher UOM is a marketing package with the conversion factor stored in ProductAssoc.quantity. I can't remember exactly if it is the case, but I think marketing packages are capable of deriving the selling price from the components if a ProductPrice isn't defined for it, in that way you'd only need to maintain specific prices when you need to provide a lower cost for ordering in bulk. >>>>>> >>>>>> Regards >>>>>> Scott >>>>>> >>>>>> On 3/10/2010, at 6:02 PM, Hans Bakker wrote: >>>>>> >>>>>>> Hi Scott, this is sure an interesting idea, but then how does the system >>>>>>> know that they are for example 10 pieces in a box? I still what to have >>>>>>> the same inventory for boxes and pieces. >>>>>>> We should be able to store the conversion between the uom's for this >>>>>>> product somewhere? >>>>>>> >>>>>>> Thanks for you input! >>>>>>> >>>>>>> Regards, >>>>>>> Hans >>>>>>> >>>>>>> On Sun, 2010-10-03 at 17:39 +1300, Scott Gray wrote: >>>>>>>> Hi Hans, >>>>>>>> >>>>>>>> Sorry if this is a silly question, but why not just use different products for different UOMs? You could use virtual/variants if you wanted the UOM to be selectable on a single product page and also marketing packages to automatically produce inventory for the desired UOM from the base UOM. >>>>>>>> >>>>>>>> Regards >>>>>>>> Scott >>>>>>>> >>>>>>>> HotWax Media >>>>>>>> http://www.hotwaxmedia.com >>>>>>>> >>>>>>>> On 3/10/2010, at 3:54 PM, Hans Bakker wrote: >>>>>>>> >>>>>>>>> Thank you BJ, >>>>>>>>> >>>>>>>>> I had in mind to create and 'productUomAlternatives' table to the >>>>>>>>> product with a conversion for example from pieces to boxes with an >>>>>>>>> optional price adjustment percentage. >>>>>>>>> The system will have however only one uom where everything gets >>>>>>>>> converted to. >>>>>>>>> >>>>>>>>> Anybody else other solutions? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Hans. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, 2010-10-02 at 10:21 -0700, BJ Freeman wrote: >>>>>>>>>> Yes also like a Feed store will have boxes, Sacks, and loose feed. >>>>>>>>>> I used the multiple pricing model for the Uom Measure >>>>>>>>>> in the product screen made it allow multiple UOM. >>>>>>>>>> >>>>>>>>>> added to the code that converts from what is received in inventory to >>>>>>>>>> what is sold so it walks through the Uom. for instance a feed store >>>>>>>>>> Receives feed in Bulk and then sacks it as inventory is required. >>>>>>>>>> The Inventory levels have to be checked to see how many in a product >>>>>>>>>> run to generate to sack up the grain. This Triggers an Seca. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think a nice touch would be that the could generates the product data >>>>>>>>>> to show up in orders, based on the Uoms that were generated for the >>>>>>>>>> products. it would follow the same model for inventory levels on the >>>>>>>>>> orderentry and Ecommerce >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hans Bakker sent the following on 10/2/2010 4:29 AM: >>>>>>>>>>> A question to the community: >>>>>>>>>>> >>>>>>>>>>> sometimes the same products are sold with different units of measure. >>>>>>>>>>> Example gold jewelry. >>>>>>>>>>> >>>>>>>>>>> Per piece, per box of 10, per box of 50 and per gram gold weight. >>>>>>>>>>> >>>>>>>>>>> Is here a preference how to implement that? >>>>>>>>>>> >>>>>>>>>>> Remember this has to show up in e-commerce, orders, shipments and >>>>>>>>>>> invoices... >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Hans >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz >>>>>>>>> Myself on twitter: http://twitter.com/hansbak >>>>>>>>> Antwebsystems.com: Quality services for competitive rates. >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz >>>>>>> Myself on twitter: http://twitter.com/hansbak >>>>>>> Antwebsystems.com: Quality services for competitive rates. >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz >>>>> Myself on twitter: http://twitter.com/hansbak >>>>> Antwebsystems.com: Quality services for competitive rates. >>>>> >>>> >> > |
Re: more than one unit of measue fo the same product: advice requested.
|
|
Re: more than one unit of measue fo the same product: advice requested.
|
|
A difficult to use UI dictates the need for a better UI, it doesn't mean that you need to add new tables and alter the underlying business logic when the existing processes work just fine.
There is no reason why the user couldn't setup the base UOM product and then have a special screen/form to generate the other UOMs for them. Alternatively they could create the virtual product and similarly use a special form to create the base and derived UOMs, using that approach you'd only need to maintain any common data on the virtual. Regards Scott On 4/10/2010, at 10:38 AM, BJ Freeman wrote: > Scott I followed you on the Marketing UOM but I can't find you comments on Inventory side except to say to use standard procedures.when I did my multiple UOM I could not find where you would have the all the Products UOM with out first adding Virtual/variants. this is all by hand and time consuming. in business time is money and overhead. Something both Hans and I agree on. > > to make this easier for my clients they fill out the different UOM they receive the product and the UOM they will sell the product in. > I coded a service that takes this and generates the Virtual/variants products, sort of like the setup does the first product, which to me is even simpler to the end user. > > so I was hoping to inject the ability to do this in the OOTB in a future date. > > > > > Scott Gray sent the following on 10/3/2010 12:52 PM: >> I'm sorry you're not making any sense. I've explained how multiple UOMs are supported OOTB for both just-in-time conversion and for longer lived UOM inventory that may require effort to produce. >> >> What is so wrong with the current functionality that we need to add new tables? How would a SECA on ProductPricing (?) populate the virtual/variants? >> >> For just-in-time conversion marketing packages are a very simple approach, you just select the product type and then setup a single ProductAssoc record to define the component Product and the quantity. >> >> Regards >> Scott >> >> On 4/10/2010, at 2:04 AM, BJ Freeman wrote: >> >>> So having a entity that defines the different UOM that can be sold in inventory would be a good Idea, at a minimum. >>> and as Hans Says have a price differential for each UOM. >>> use a SECA to trigger on the ProductPricing service to run a service to populate for the Virtual/variants >>> So all the user has todo is put fill in the new entity. >>> >>> Scott Gray sent the following on 10/3/2010 5:44 AM: >>>> You wouldn't use marketing packages in that situation, you'd just use regular products and regular production runs. >>>> >>>> Regards >>>> Scott >>>> >>>> On 4/10/2010, at 12:07 AM, BJ Freeman wrote: >>>> >>>>> how would the marketing package allow for inventory levels to be established for different UOM. is marketing not a "Just in time" type of management? >>>>> What about inventory that takes long lead times to process, that would delay shipments beyond a reasonable time. This could be from too many products that need conversion beyond staff capability to handle orders, against processing a certain level of Inventory as stock, based on ERP. >>>>> >>>>> Scott Gray sent the following on 10/3/2010 2:15 AM: >>>>> >>>>> >>>>>> Hi Hans, >>>>>> >>>>>> I'm not sure I understand what you proposed, could you explain it further? >>>>>> >>>>>> Virtual/variants and the marketing packages would serve different purposes in what I was suggesting, the marketing packages would serve to convert the base uom product to each of the marketing package's uom whereas the virtual/variant would just serve to combine all uom products under a single virtual product. Each variant would be a marketing package except for the base uom product which would be a regular finished good. >>>>>> >>>>>> Marketing packages do cause an automatic production run to be created and completed, but I don't really see that as a big deal. It serves as a record for the conversion and also if the base uom doesn't have enough inventory available then the production run is left open until more is available, so it serves well as a reservation mechanism of sorts as well. Production runs have always been our primary mechanism of converting one or more products into a different product which is exactly what is happening here. Marketing packages/production runs also support decomposing manufactured products back into their original components which would serve you well for returns and the like. >>>>>> >>>>>> Regards >>>>>> Scott >>>>>> >>>>>> On 3/10/2010, at 8:52 PM, Hans Bakker wrote: >>>>>> >>>>>>> But involving the complete manufacturing process? please have a look at >>>>>>> my earlier message about adding a field to the productassoc entity.... >>>>>>> >>>>>>> On Sun, 2010-10-03 at 18:13 +1300, Scott Gray wrote: >>>>>>>> If you were to go the marketing package route, the box of 10 would be the marketing package and the single piece would be the product that all inventory is stored against. The ProductAssoc (type "component" I think) between the box of 10 and the piece would have a quantity of 10. Whenever the box is ordered the system would automatically create a production run which will convert 10 pieces into 1 box. >>>>>>>> >>>>>>>> So you have a standard finished good as your lowest UOM and then each higher UOM is a marketing package with the conversion factor stored in ProductAssoc.quantity. I can't remember exactly if it is the case, but I think marketing packages are capable of deriving the selling price from the components if a ProductPrice isn't defined for it, in that way you'd only need to maintain specific prices when you need to provide a lower cost for ordering in bulk. >>>>>>>> >>>>>>>> Regards >>>>>>>> Scott >>>>>>>> >>>>>>>> On 3/10/2010, at 6:02 PM, Hans Bakker wrote: >>>>>>>> >>>>>>>>> Hi Scott, this is sure an interesting idea, but then how does the system >>>>>>>>> know that they are for example 10 pieces in a box? I still what to have >>>>>>>>> the same inventory for boxes and pieces. >>>>>>>>> We should be able to store the conversion between the uom's for this >>>>>>>>> product somewhere? >>>>>>>>> >>>>>>>>> Thanks for you input! >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Hans >>>>>>>>> >>>>>>>>> On Sun, 2010-10-03 at 17:39 +1300, Scott Gray wrote: >>>>>>>>>> Hi Hans, >>>>>>>>>> >>>>>>>>>> Sorry if this is a silly question, but why not just use different products for different UOMs? You could use virtual/variants if you wanted the UOM to be selectable on a single product page and also marketing packages to automatically produce inventory for the desired UOM from the base UOM. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Scott >>>>>>>>>> >>>>>>>>>> HotWax Media >>>>>>>>>> http://www.hotwaxmedia.com >>>>>>>>>> >>>>>>>>>> On 3/10/2010, at 3:54 PM, Hans Bakker wrote: >>>>>>>>>> >>>>>>>>>>> Thank you BJ, >>>>>>>>>>> >>>>>>>>>>> I had in mind to create and 'productUomAlternatives' table to the >>>>>>>>>>> product with a conversion for example from pieces to boxes with an >>>>>>>>>>> optional price adjustment percentage. >>>>>>>>>>> The system will have however only one uom where everything gets >>>>>>>>>>> converted to. >>>>>>>>>>> >>>>>>>>>>> Anybody else other solutions? >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Hans. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Sat, 2010-10-02 at 10:21 -0700, BJ Freeman wrote: >>>>>>>>>>>> Yes also like a Feed store will have boxes, Sacks, and loose feed. >>>>>>>>>>>> I used the multiple pricing model for the Uom Measure >>>>>>>>>>>> in the product screen made it allow multiple UOM. >>>>>>>>>>>> >>>>>>>>>>>> added to the code that converts from what is received in inventory to >>>>>>>>>>>> what is sold so it walks through the Uom. for instance a feed store >>>>>>>>>>>> Receives feed in Bulk and then sacks it as inventory is required. >>>>>>>>>>>> The Inventory levels have to be checked to see how many in a product >>>>>>>>>>>> run to generate to sack up the grain. This Triggers an Seca. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I think a nice touch would be that the could generates the product data >>>>>>>>>>>> to show up in orders, based on the Uoms that were generated for the >>>>>>>>>>>> products. it would follow the same model for inventory levels on the >>>>>>>>>>>> orderentry and Ecommerce >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hans Bakker sent the following on 10/2/2010 4:29 AM: >>>>>>>>>>>>> A question to the community: >>>>>>>>>>>>> >>>>>>>>>>>>> sometimes the same products are sold with different units of measure. >>>>>>>>>>>>> Example gold jewelry. >>>>>>>>>>>>> >>>>>>>>>>>>> Per piece, per box of 10, per box of 50 and per gram gold weight. >>>>>>>>>>>>> >>>>>>>>>>>>> Is here a preference how to implement that? >>>>>>>>>>>>> >>>>>>>>>>>>> Remember this has to show up in e-commerce, orders, shipments and >>>>>>>>>>>>> invoices... >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Hans >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz >>>>>>>>>>> Myself on twitter: http://twitter.com/hansbak >>>>>>>>>>> Antwebsystems.com: Quality services for competitive rates. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz >>>>>>>>> Myself on twitter: http://twitter.com/hansbak >>>>>>>>> Antwebsystems.com: Quality services for competitive rates. >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz >>>>>>> Myself on twitter: http://twitter.com/hansbak >>>>>>> Antwebsystems.com: Quality services for competitive rates. >>>>>>> >>>>>> >>>> >>> >> > |
Re: more than one unit of measue fo the same product: advice requested.
|
|
Re: more than one unit of measue fo the same product: advice requested.
|
|
Re: more than one unit of measue fo the same product: advice requested.
|
|
| Free forum by Nabble | Edit this page |