[jira] Commented: (OFBIZ-194) Implement sales forecast analysis

["Si Chen (JIRA)" <ji...@apache.org>]

    [ http://issues.apache.org/jira/browse/OFBIZ-194?page=comments#action_12455053 ] 
            
Si Chen commented on OFBIZ-194:
-------------------------------

For sales forecast we can probably extend the existing SalesForecast entities with a SalesForecastItem entity (to follow pattern...) and then make a multi-form which can be used to enter many items at a time fairly quickly, productId, quantity, etc.  This should be simple.  People can then write their own analytical routines to create sales forecast + items automatically.

So why do we need the "family of products" concept?  Is it because MRP is always creating Requirements?  In that case, is it possible to alter the MRP routines to run in a "reporting" mode and just return a big List of GenericValues which are not stored, or alternatively to change the Requirements created in a new state like "MRP_PLANNING" which can then be made into real requirements or canceled?

> Implement sales forecast analysis
> ---------------------------------
>
>                 Key: OFBIZ-194
>                 URL: http://issues.apache.org/jira/browse/OFBIZ-194
>             Project: OFBiz (The Open for Business Project)
>          Issue Type: New Feature
>          Components: manufacturing
>            Reporter: Jacopo Cappellato
>            Priority: Minor
>
> At the beginning of the simulation process, the MRP algorithm collects information about real purchase orders, sales orders, production runs and stock levels.
> We should add to these the sales forecasts; this issue involves:
> * ui and services to manage (create/edit/delete) sales forcasts
> * mods to the MRP process
> Some of the implementation details  (taken from a mail I've recently sent to the user list):
> let's say that your forecast is to sell 10000 t-shirt of type "A" in the next 2 months; the t-shirt "A" are virtual product that are available in two sizes, S and L.
> You would like to simulate (materials and resources needed) the manufacturing process to create 10000 t-shirt of type "A", regardless of their sizes.
> I'd recommend to implement something different:
> 1) introduce the concept of a "family of products"; this could be a special type of Product that is only used as a planning tool; in the example above, you could create a new product of type "family of products" to represent your type "A" t-shirts
> 2) create a bom for your family of products where each component is a variant product; for example: family "A" has two components, the variant product "t-shirt A size S" and "t-shirt A size L"; the bom coefficient is used here to forecast the number of sizes that will be sold (for example, 0.4 for S and 0.6 for L)
> 3) then you'll create one production run for the family "A" of 10000 units with start date in the future; the production run will never be executed (i.e. its components, the variant products, will not be taken from warehouse)
> 4) by running the MRP you'll get a simulation of the materials needed (to manufacture 4000 t-shirt of size S and 6000 t-shirt of size L) and it will generate the *requirements* for them (that once approved will become new production runs for real variant products).
> Comment by Jacopo Cappellato [01/Sep/06 02:59 AM]
> [ Permlink ]
> A follow-up to the above comment to specify some of the design details:
> a) a new product type for the family of products
> b) a new status for the requirements generated from MRP to specify that they are a "simulation"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira