Quote Originally Posted by GoldBuckle View Post
I use my attributes to calculate any quantity the customer wants for a specific product. I do this by using an offline estimating tool I wrote & use to estimate printing prices. I separate the fixed charges (such as a setup charge for the printing press, or the cost to make a plate) for each attribute from running charges (cost of each print which consists of paper costs and shop labor per print), so for many attributes the running charge is multiplied by the quantity the customer enters in the quantity box and added to the fixed charge (one time charges in the attributes controller). With the DPU it adds all this up and gives the customer one price displayed until it is put in the cart, there it shows the breakdown by 2 lines, one lines shows all the one time charges and the other line on top shows the price of all combined attributes running charges x the quantity in the quantity box.
Based on your above explanation of using one-time attribute fees in conjunction with a fee per quantity of product/attribute, I was able to reproduce the visualization of two fees stacked on top of each other in the shopping cart page as you described and showed. The "cause" of the stacked values on the shopping cart page is from the header_php.php file of the shopping cart: includes/modules/pages/shopping_cart/header_php.php

In this file when there are one-time payments calculated, an additional "row" is added to the product information so that the individual prices associated with the total are presented. In many cases this is ideal so that the customer is able to see how the total is determined. Perhaps additional verbiage could be added or it is possible to add an additional row that shows the total for that product when such a condition exists. I haven't gone through all of the potential iterations and sub-totals that could be displayed; however, it seems that it would be in this generation of product information that you may want to either add a total row (when there are one-time charges to be applied or any other additional charge added to the "base" price of the product).

All that said, and while this issue may have been observed as a result of using DPU, unless the goal is for DPU to update the individual prices when the quantity on the shopping cart page is modified, I would actually suggest either starting a new thread about this topic (more people seeing a similar condition and wanting to have a similar solution would likely see it and also benefit from it) or seeking support for this customization (perhaps allowing such customization to be returned to the community). I suggest this also because the result seen/sought is not directly associated with the functionality added by DPU.