Re: Proposed change to the SalesForecast entity

[David E. Jones]

This looks like it would be helpful information.



-David


On Feb 10, 2007, at 1:43 AM, Jacopo Cappellato wrote:

My only thought on these fields is that it might be good to introduce something like a "SalesForecastDetail" entity that would support multiple sets of these fields, ie multiple products and such, for a given forecast.

Hi,



quantityUomId
quantity
productId
productCategoryId

This is what I'd like to achieve:



The next steps would be these:

1) create ui and services to manage the entity


Does it make sense?

Jacopo

what do you think about adding the following fields to the SalesForecast entity? a) the new field quantityUomId could be used to specify the uom id for the new quantity field b) the new quantity field could be used to specify a sales forecast in terms of number of units (if quantityUomId is null), or in terms of, for example, tons of items (if quantityUomId is set to ton) c) productId could be used to specify the product id to which the sales forecast refers (e.g. WG-1111) c) productCategoryId could be used to specify the product category id to which the sales forecast refers (e.g. Widgets) 2) change the MRP to optionally take into account the sales forecasts over a period of time and create requirements for them 3) we'll need to find a way to specify a 'family of product' for planning purposes, that the mrp will explode into a set of real products (with different percentages); using a special type of ProductCategory is probably a good option (this is one of the reasons for which I'm asking you to add the SalesForecast.productCategoryId field).

smime.p7s
Description: S/MIME cryptographic signature