You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacopo Cappellato <ti...@sastau.it> on 2007/02/10 09:43:01 UTC

Proposed change to the SalesForecast entity

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


Re: Proposed change to the SalesForecast entity

Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
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
>>>
>
>


Re: Proposed change to the SalesForecast entity

Posted by Jacopo Cappellato <ti...@sastau.it>.
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
>>
> 



Re: Proposed change to the SalesForecast entity

Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
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
>


Re: Proposed change to the SalesForecast entity

Posted by Jacopo Cappellato <ti...@sastau.it>.
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