Display each cart item field as a separate line in the cart summary table

Hi HikaShop team,

We are customizing the checkout cart template (show_block_cart.php) to display each product option and cart item field as a separate line in the cart summary table, with individual unit price, quantity, and total columns.

While implementing this, we found that cart item fields (stored in $cart->cart_products[$i]->field_namekey) lack some metadata that would be essential for correct display:

1. No tax rate available for item fields
The field value stored in the cart item is the price excluding tax (e.g. 42.975), but there is no associated tax rate or tax category accessible from the template. We had to hardcode × 1.21 (21% VAT) because it happened to match the configured tax for that service. If a field uses a different tax rate (10%, 4%, etc.), the displayed price with tax will be wrong.

Suggested improvement: Include the tax rate or computed price_value_with_tax alongside the raw field value in the cart item data, similar to how prices[0]->price_value_with_tax is available for product options.

2. No indication of whether a field price scales with quantity
Some item fields represent a per-unit cost (should multiply by cart quantity), while others represent a flat one-time service fee (should not multiply). Currently there is no way to distinguish these cases from the template — we have to guess based on business logic.

Suggested improvement: Add a metadata flag to field definitions (e.g. field_multiply_by_quantity: true/false) so templates can handle both cases correctly without hardcoding assumptions.

3. prices[0]->unit_price in option elements equals prices[0]->price_value_with_tax
When displaying grouped options (group_options = 1), the unit_price nested object inside prices[0] of an option element contains the same value as price_value_with_tax (i.e. total price, not unit price). This makes it impossible to retrieve the true per-unit price for display without manually dividing by cart_product_quantity.

Suggested improvement: Ensure prices[0]->unit_price->price_value_with_tax consistently reflects the price for one unit, regardless of cart quantity.

These improvements would allow template developers to build accurate per-line breakdowns without relying on hardcoded business logic or reverse-engineering prices from totals.

Thank you for considering these improvements.

Hi Nicolas,
Sorry, this is related to this thread: www.hikashop.com/support/forum/product-c...er-vehic.html#370015 . It's a project shared between Pablo and me, that's whay you cannot find that plugin under his account, but you can in mine.

Hi,

Thank you for the updated calculations plugin — we really appreciate the quick response.

After reviewing it, we can see that price_calculation->fields[] is now populated with name, raw_value, resolved_value, taxed, tax_id and value_used, which is a great step forward. However, in our case taxed still comes as false and tax_id as 0, because our item field does not have product_tax_id_for_custom_values set on the product. The tax ends up being applied elsewhere in the price pipeline, so the plugin has no visibility of it at that point.

The two remaining gaps that we still cannot solve generically are:

1. Tax information for item fields without product_tax_id_for_custom_values
When the field value gets taxed through the product's own tax group rather than through product_tax_id_for_custom_values, the taxed flag stays false and tax_id stays 0. As a result, we cannot determine the with-tax value of the field from price_calculation->fields[] alone and have to fall back to calling getTaxedPrice() with the parent product's tax ID, which may be incorrect if the item field carries a different tax rate.

2. Whether an item field scales with quantity or is a flat one-time charge
This is still not exposed anywhere. We are hardcoding quantity = 1 for all numeric item fields, which will be wrong as soon as we have a per-unit item field on a different product.

Would it be possible to address these two points in a future update? We are happy to provide a reproducible test case if that would help.

Thanks again for your support.

Hi,

I’m sharing some additional context to help clarify the situation.

This is the production website:
neumaticosacueducto.com/

And here is an example product:
neumaticosacueducto.com/neumaticos/turis...imacy-hp-mo-mercedes

In our case, the additional services (Ecotasa, Mounting, Inflation, and Rotation) are configured as products that are added together with the tire.
Among them, Ecotasa and Mounting are mandatory, while Inflation and Rotation are optional.

On the other hand, Alignment/Geometry is configured as a characteristic, using the price calculation plugin.

The issue appears when the user adds these additional services to the cart. At that point, the cart view does not display the prices clearly, as the different items are not properly separated, which creates confusion.

In fact, several users have already reported that this lack of clarity in the cart summary reduces their trust in the purchase process.

I hope this explanation helps clarify the situation. If you need any additional information or further examples, please let me know.

Thank you again for your support.

Hi,

Thank you for the $beforeCalculation suggestion. We implemented the equivalent logic directly in our template override (without modifying view.html.php) by reading $product->price_calculation->price_before_with_tax directly. This works well for the unit price display.

However, we still have two assumptions in our override that we cannot resolve with the current data available in the cart object. We are attaching a screenshot of what we want to achieve and the relevant section of our override code.

Remaining problem 1: Tax rate for numeric item fields

When a numeric item field (e.g. alignment_service) is added to the cart, its value is stored as a raw price excluding tax. To display it with tax in the cart, we need to apply the correct tax rate. The price_calculation->fields[] objects have taxed: false and tax_id: 0 for this field, so we cannot read the tax rate from there. We are currently falling back to getTaxedPrice() using the parent product's product_tax_id, which happens to work for us because the alignment service uses the same tax rate as the tyre — but this will break if a future product has an item field with a different tax rate.

Is there a way to know the correct tax ID (or the taxed value) for each item field at cart display time?

Remaining problem 2: Whether an item field scales with quantity

Some item fields represent a flat one-time service (e.g. wheel alignment: one charge regardless of how many tyres are purchased), while others could represent a per-unit cost. There is no attribute on the field or on the cart product that tells us which behaviour applies. We are currently hardcoding quantity = 1 for all numeric item fields, which will be wrong for per-unit fields.

Is there a field attribute or cart product property that indicates whether a numeric item field should be multiplied by cart_product_quantity or treated as a flat fee?

Hi,

Thank you very much for your reply, and apologies for the delay in getting back to you.

We are currently testing the new plugin update and working on configuring the cart view according to the client’s requirements. Once we have this completed, I will get back to you with an update.

Thank you very much for your support.

Best regards