magentoerpconnect-community team mailing list archive

[Joël Grand-Guillaume <joel.grandguillaume@xxxxxxxxxxxxxx>]

Dear all,


Regarding this problematic, I agree we should keep both solutions. I like the nan_product_pack cause it is simple,
remove the MRP dependence. So this is the perfect solution in standard/simple use case.

But then, using BoM is also good when managing other kind of use case (like David Michel said). As well, if you have the grouped product in
the SO, the turnover will go in the good account. By splitting the grouped product in many line, the sale turnover will not go for
the grouped product, but for all his components. In some cases (this is mainly why we opted for this one), it's very important
to have the turnover on the grouped product and not the components.

As long as the nan_product_pack doesn't break the other solution, I think this is just perfect : keep both way :) !

Regards,


Joël



Le 11 févr. 2011 à 21:03, David Mitchell a écrit :

> Hi Raimon et al,
> 
> While we like the nan_product_pack functionality. But in exchanging information with Albert it didn't fit our specific use case - hence our direction for the Assembly BoM to meet the needs of our distributors and manufacturers.
> 
> Our Use Case
> Our clients pre-build kits and put the entire kit on the shelf (one box) - Normal BoM (Product is a single kit)
> Our companies also have Assembly/Sales Kits - in which separate products are kitted up at time of picking and packaged together (one or more boxes). The end-customer only sees that Kit A is purchased when they order- and really isn't interested in seeing the subcomponents of a kit listed (Normal BoM or Assembly/Sales BoM). To them it is just a kit.
> 
> For eCommerce - the use case is to use OpenERP as the Master. The customer orders a kit - all they see on their order is Kit #123456abcd. From their perspective - they don't really care if it is a pre-build kit or Assembly Sales Kit. They just want the Kit. To them it is just one product. 
> 
> The warehouse then pulls what they need in the manner required - either they pull a prebuilt kit or at picking package the Assembly/Sales Kit. If the "prebuilt kit" is Made to Order - then a production order is created - executing the Normal BoM.
> 
> Customer receives the packing list - which only shows the "sales kit" not the subcomponents.
> 
> I guess it all depends on your specific use case on whether the functionality fits or "if it is needed".
> 
> If normal BoMs are required for a business as well and if the nan_product_pack is installed from a usability perspective now you are managing BoMs in different functional locations with mrp and nan_product_pack installed.
> 
> If only a Sales BoM is required and you want to display all the components of a "kit" in the sales order lines/quotations then of course nan_product_pack seems viable - at least to us.
> 
> Everyone can of course do anything they wish - we only wanted to point out and communicate the direction on the Assembly BoM. We envision bypassing all the MRP operations input, etc when defining an Assembly BoM as well - as all the mrp operations are really needed either to keep it light - only good coordination with picking/operation is required.
> 
> I guess the issue with Magento is - which application will be responsible for exploding the grouping/pack - OpenERP or Magento?. Personally, for our use case it fits that Magento orders the product/kit and sends that specific product/kit order to OpenERP. We don't want Magento to do the grouping only order the individual product (kit, or single product).
> 
> Of course there is also the "configurator" issue of having customers select/build-up their kit at time of order on Magento - e.g. selecting individual components of a bicycle and having that be sent over to OpenERP. Sometimes would see these as individual products passed over and picked as part of a sale. However, if there is assembly involved (e.g. welding a custom bike frame) then a product would generate a Normal BoM for that activity - at least for some of the products - so it needs to support a "mixed environment too" - production and then a Sales/BoM. The issue we often see is how to best track and measure these types of purchases from a management standpoint/to improve forecasting capabilities. Hence we try to simplify the environment to aid in measurement and metrics - which also feeds into our use case.
> 
> 
> Best Regards,
> 
> David Mitchell
> NovaPoint Group LLC
> 
> 
> 
> On Fri, Feb 11, 2011 at 10:26 AM, Raimon Esteve <resteve@xxxxxxxxxxxxxxx> wrote:
> nan_product_pack is simple, usuability and production module for packagin product. It is very simple understand it and not requiered hard configuration (sorry, don't need!)
> 
> +1 to nan_product_pack
> 
> note:
> We develop/adapt nan_product_pack for point_of_sale also (same sale orders)
> 
> -- 
> Raimon Esteve
> // OpenERP, gestió empresarial flexible
> // Botigues virtuals dinàmiques amb OpenERP
> // AulaERP, formació online
> www.zikzakmedia.com
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~magentoerpconnect-community
> Post to     : magentoerpconnect-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~magentoerpconnect-community
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~magentoerpconnect-community
> Post to     : magentoerpconnect-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~magentoerpconnect-community
> More help   : https://help.launchpad.net/ListHelp

-- 

Joël Grand-Guillaume 
Division Manager
Business Solutions

Camptocamp SA
PSE A, CH-1015 Lausanne
http://openerp.camptocamp.com/

Phone: +41 21 619 10 28
Office: +41 21 619 10 10
Fax: +41 21 619 10 00
Email: joel.grandguillaume@xxxxxxxxxxxxxx