Product price based on the attribute values

[Saj]

Hi Team,

Can you advice on the below scenario. Thank you for your valuable time.

Senario:
I am running a curtain shop where I make curtain like products according to the customer requirements.
The fininshed product is curtain in different size and BOM are just cloth and buttons.

I shall cut the cloth according to the required size. So the making cost will differ with the size of the curtain.
If I choose the different size attribute, the price will varry accordingly.
The sales price can be define against the product. We need a system to define the product price according to the attribute value.

In the first look it seems to be very specific. While thinking on kitting and simple production process, it will be helpful to extend this feature in attribute level.

Please advice on this. Or do we have any work arround for this?

[redhuan d. oon]

This is an interesting scenario. Indeed anything, once defined or conceived well, can be achieved well. Regarding ASI (attribute set instance), it can be included during some process during price calculation. There is a case we are developing with http://wiki.idempiere.org/en/AulerSipel (not yet documented there) about Metal Charge, where a product such as a metal cable, has different price add-ons based on the type of metal it is, for example, steel or copper. And this metal charge is calculated separately as a new data model that is added as a sub tab to the OrderLine tab, to affect its individual price and taxation.

However I explored the use of ASI directly for the handling of different UOM lengths as in http://wiki.idempiere.org/en/Plugin:_Couple_Product. You may read through that to gain an idea what I am trying to explore. And now looking at your case here, leads me to rethink the pending Metal Charge case as possibly similar, i.e. using the ASI couple approach may be more elegant and less extra data modelling.

[norber...@multimageweb.com]

hi Saj and Red1,

i suggest to read related topics from idempiere workshop 2015: http://wiki.idempiere.org/en/IDempiere_workshop_2015/transcript#change_the_pricing_system

we discussed lot about how to improve pricing in idempiere, one relates to pricing depends on attributes. 

our local strategy: our customer has because missing attribute pricing approx 300 000 prices.They need prices based on attribute=Brand. So its on our mid-term development list. (probably we align this regards to workshop defined strategies.)

norbert

[Marco Longo]

Hi Norbert,

on migrating data from legacy to idempiere we are evaluating to reduce product list and use  product with ASI but we probabily we need Price base on ASI .

Did you complete your target ?  otherwise we will decide in short time what to do  .

bye and  thank you in advance

Marco

[norber...@multimageweb.com]

hi Marco,

sorry for late reply.  we have done next improvements help us reduce pricing complexity and achieve simplified maintenance.

1. we are able to define attribute and attribute value - on new tab under pricelist schema >> schema line >> Schema Attributes - user able to define attribute and his value then this condition stay as part of schema line e.g. seq 9999 apply 5% for all items excluding prio 8888 for brand = Nike where you apple 3 %. All features from schema lines are compatible.

2. we implement a reference list "pricelist list type" = Precalculated (legacy idempere way)/Document based - this applied Just in Time - to temporary table m_product_price_temp and returned on doc e.g. sales order when callout ask for price. this useful when customers has price PO price + x% markup.

3. we implement pricelist scope - options client, org, bpgroup, bp, campaign, general (legacy behaviour). This solve common use case - when company has PL  with 10 000 products then we define it as client or org wide price list (this is similar like navision has base price on item) and we apply hierarchy when getting price e.g  SO lookup for 10000 prices but SO has BP customer PL including only customer specific prices those overrides client wide price list prices. This introduce "hierarchical pricing" save tons of records.

this is a huge/complex implementation would be interesting to get it into core system well. however this cant - in my opninon -  distribute as plugin. In my estimation minimally 10 days review from our side + core team time. Important - hardest part were bug fixing and get it into production because impact on wrong pricing can be catastrophic for customer.

however we cant imagine without above solution to use pricing effectively.

norbert

[Marco Longo]

Hi Norbert,

That sounds good :-D

As you said, yes,  we need also "some times" of Carlos ;-) to do a "perfect job". 

Give me some time "to investigate" on our side ...  

anyone interested ? Maybe we could find other sponsor ;-)  

Marco

Marco Longo