For any price component defined in the system, such as a Tax or Fee calculated into a product's price ... it would be handy to expose the component to the field formatter, instead of just the data[] array. This would make it easier to display just the "taxable" amount, or just the "fees" attached to a specific product ... or going a step further, make reports of "taxes" or "fees" in Views that use a filter which simply chooses the component to target.

Thoughts?

Comments

rszrama’s picture

rszrama commented

I agree, but I think it's of dubious benefit until we change the storage method for price component data (i.e. a price component table of sorts as opposed to serialized storage). As a related request (and possibly duplicate), there's #1232320: Price components: display and rules integration.

wjaspers’s picture

wjaspers commented

I don't think the price component storage method is wrong ... confusing to update or alter, perhaps, but it gets the job done. By serializing it, (the same as a product line item stores a product), you get the exact structure of a price with minimal db overhead to retrieve a price.

Maybe a commerce_price_component_type table makes sense, so that a UI can access/store price component types that are created. Would it work similar to that of commerce_tax? Wherein a tax type can be defined by a module, but additional types added via the info hook?

Thanks for the link to 1232320, I didn't find that one before.

jsacksick’s picture

jsacksick commented
Issue summary: View changes
Status: Active » Closed (outdated)