BOM for price calculation

[norber...@multimageweb.com]

hi,

we need to replace customer xls for calculating BOM. 

They have actually xls table a.) sales trade price (regular pricelist) b.)cost  c.) sales price inside BOM  d.) margin per row e. sum for each cols

e.g. 

product is for 10 USD avg  cost is 5 USD but in bundle sales could be calculated for 8 so discount is 2 USD

my idea is improve M_Product_BOM

1.) add column bundle sales price - users enter price here manually

2.) costs = exists on BOM tab

3.) add virtual column discount (regular pricelist price - entered price)

4.) add col. margin

etc.

the goal: use idempiere bom as calculator for prices

i want to do as part of simple manufacturing - no libero (too complex)

any idea pls ?

nb

[redhuan d. oon]

I agree Libero is too complex, that is why i took the BOM Configurator out http://wiki.idempiere.org/en/Plugin:_BOMDrop_Configurator

[norber...@multimageweb.com]

hi Red1

yes i see that is good starting point. i study and remember this plugin now.  

i think i need to do the following:

1. improve Product/BOM tab by fields (like on Sales Order Line):  pricelist, listprice, enteredprice, limitprice, discount + add callouts

2. support for process - update prices from price list -> select one - "update BOM prices"

3. support for process - manual change of prices - 1. change entered update discount 2. change discount update entered

4. Limit price could be used as featured price - enter manually (price is not available) - instead featured price could be used however looks me more complicated. (costing)

5. improve your plugin by columns: discount (edit) and enteredprice (it is there), listprice, Margin % 

wdyt ?

n

[redhuan d. oon]

Yes, and you can maybe try do a fragment instead of changing the plugin. Or no need as plugins can be swapped in console or defined as separate menu items.
And i think you can use a Rule model to make those parameters. So that anyone can edit, add to them without code. If take time to design well, as i always try to, it will be powerful and yet easier to maintain.

[redhuan d. oon]

By the way, the Project (Order) already has margin so better use that. In my Swing version, it does give the margin in pop up display. But in ZK it should be in the GrandTotal. Even if not, it is no issue to just fetch from Project (Order) field to the display. So dropping BOM into Project is a good idea to use for your case as Project model is more designable than messing with Sales Order.

Hiep has made a good interface which i built all these fetching from. The hard work is done. To improve further is easier but as i said, proper code design principle is important.