Proposed change to the SalesForecast entity

[Jacopo Cappellato]

Hi,

what do you think about adding the following fields to the SalesForecast
entity?

quantityUomId
quantity
productId
productCategoryId

This is what I'd like to achieve:

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)

The next steps would be these:

1) create ui and services to manage the entity
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).

Does it make sense?

Jacopo

[Jacopo Cappellato]

This effort is related to:

https://issues.apache.org/jira/browse/OFBIZ-194

Jacopo

Jacopo Cappellato wrote:

> Hi,
>
> what do you think about adding the following fields to the SalesForecast
> entity?
>
> quantityUomId
> quantity
> productId
> productCategoryId
>
> This is what I'd like to achieve:
>
> 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)
>
> The next steps would be these:
>
> 1) create ui and services to manage the entity
> 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).
>
> Does it make sense?
>
> Jacopo

[David E Jones]

This looks like it would be helpful information.

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.

-David


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

> Hi,
>
> what do you think about adding the following fields to the  
> SalesForecast entity?
>
> quantityUomId
> quantity
> productId
> productCategoryId
>
> This is what I'd like to achieve:
>
> 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)
>
> The next steps would be these:
>
> 1) create ui and services to manage the entity
> 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).
>
> Does it make sense?
>
> Jacopo
>

[Jacopo Cappellato]

David,

yes, it seems like a good idea, and, if I am not wrong, Si suggested
something very similar to this in
https://issues.apache.org/jira/browse/OFBIZ-194

To summarize:

* SalesForecast (leave as is now): used to set the period, the currency
and global amounts

* SalesForecastDetail (optional, can be used to specify detailled
forecasts, for units to be sold or amounts, by category or product):
### salesForecastId (PK)
### salesForecastDetailSeqId (PK)
### amount (in the currency set in SalesForecast)
### quantityUomId
### quantity
### productId
### productCategoryId

Is it ok?

Jacopo


David E. Jones wrote:

>
> This looks like it would be helpful information.
>
> 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.
>
> -David
>
>
> On Feb 10, 2007, at 1:43 AM, Jacopo Cappellato wrote:
>
>> Hi,
>>
>> what do you think about adding the following fields to the
>> SalesForecast entity?
>>
>> quantityUomId
>> quantity
>> productId
>> productCategoryId
>>
>> This is what I'd like to achieve:
>>
>> 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)
>>
>> The next steps would be these:
>>
>> 1) create ui and services to manage the entity
>> 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).
>>
>> Does it make sense?
>>
>> Jacopo
>>
>

[David E Jones]

Jacopo,

That looks good to me.

-David


On Feb 12, 2007, at 12:58 AM, Jacopo Cappellato wrote:

> David,
>
> yes, it seems like a good idea, and, if I am not wrong, Si  
> suggested something very similar to this in
> https://issues.apache.org/jira/browse/OFBIZ-194
>
> To summarize:
>
> * SalesForecast (leave as is now): used to set the period, the  
> currency and global amounts
>
> * SalesForecastDetail (optional, can be used to specify detailled  
> forecasts, for units to be sold or amounts, by category or product):
> ### salesForecastId (PK)
> ### salesForecastDetailSeqId (PK)
> ### amount (in the currency set in SalesForecast)
> ### quantityUomId
> ### quantity
> ### productId
> ### productCategoryId
>
> Is it ok?
>
> Jacopo
>
>
> David E. Jones wrote:
>> This looks like it would be helpful information.
>> 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.
>> -David
>> On Feb 10, 2007, at 1:43 AM, Jacopo Cappellato wrote:
>>> Hi,
>>>
>>> what do you think about adding the following fields to the  
>>> SalesForecast entity?
>>>
>>> quantityUomId
>>> quantity
>>> productId
>>> productCategoryId
>>>
>>> This is what I'd like to achieve:
>>>
>>> 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)
>>>
>>> The next steps would be these:
>>>
>>> 1) create ui and services to manage the entity
>>> 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).
>>>
>>> Does it make sense?
>>>
>>> Jacopo
>>>
>
>