Strange problem with prices displayed at final stage of checkout

I was just doing some final testing before going live and I noticed some strange behaviour with the prices displayed at the final stage of checkout. I'm not sure if the problem is being generated by the template I'm using (ZCA Bootstrap-4) or the mod for displaying prices with and without VAT, but on the default green template it does appear to show everything correctly.

Test 1 - A dummy test product with a cost of £1.00 (£1.20 inc vat), the correct information is show at each stage of the checkout process.

Test 2 - A syringe which costs £2.75 (£3.30 inc vat). The prices are shown correctly on the product info page and in the shopping cart. But the final stage of the checkout process it has changed the products base price to £3.00. The total price at the bottom is correct but the inc vat and ex vat prices are both wrong.

I'm using store collection on both test to keep things simple.

When you say "last stage" of checkout, can you clarify? Would this be checkout_success?

As far as the template goes, what checkout relate pages in the template or modules within includes/modules/YOUR_TEMPLATE are/were modified as compared to the base fileset and how are they different? Is it just formatting or are there notifiers and other data processing features missing/different?

Sorry, it's 'step 2 of 3 - payment information' (index.php?main_page=checkout_payment) which is showing the wrong information. It looks like the ex vat price at the top is rounding to the nearest full GBP. If I set the products base price to £2.50 it shows £3.00 on the last page before paying. If I set the base price as £2.49 then it shows £2.00 on the same page.

I'll see if I can find the relevant template file and see if I can work out what is going on.

I was unable to get my head around where the rounding was occurring but it was definitely the inc/ex vat mod. I uninstalled the mod and replaced the relevant files with zen 1.5.7c and Bootstrap files and the totals are displaying correctly. I'll just have to find another method of enabling the display of prices including VAT.

Have you looked over your currency settings by chance and also can you identify the link to the module that was installed? It would be unusual for it to "blindly" round especially to the decimal instead of at least the number of places for the associated currency(ies)...

The mod i've been using for a long time is Display price with VAT/TAX and Ex VAT/TAX (https://www.zen-cart.com/downloads.php?do=file&id=597).

After uninstalling it I did try reinstalling and was able to replicate the same issue with rounding up and down on that final step before taking payment.

I have it working the way I want now but I've had to use the bootstrap template's version of tpl_modules_order_totals.php instead of the inc/ex vat mod's version to ensure confusing information is not displayed before taking payment.

https://www.thegluepeople.co.uk/

May I suggest posting the issue and resolution to this at the forum for the plugin? It may be that the instructions might get updated for this or others may benefit.

I just fixed this myself in 1.57c after seeing the rounding problem. The issue is that $currencies, which is a global, appears not to have been declared as global and therefore a local copy is used instead, which doesn't contain anything. I assume in previous Zen Cart versions it was declared global in some code that included the template (I've only previously tried it up to 1.55f so I can't comment on 1.56 versions).

The solution for me was to edit the template file includes/templates/YOUR_TEMPLATE/templates/tpl_modules_order_totals.php as follows.

Original:

<?php 
/**
 * Displays order-totals modules' output
 */
  for ($i=0; $i<$size; $i++) { ?>

to:

<?php 
/**
 * Displays order-totals modules' output
 */
  global $currencies;
  
  for ($i=0; $i<$size; $i++) { ?>

Having found and fixed the problem, however, I may now just delete the template override altogether as I think I prefer never to display the subtotal with VAT, even when showing prices invclusive of VAT to our UK customers. Including VAT in the subtotal and then showing the VAT on a separate line on the invoice prompts periodic queries from customers who think they have been charged VAT twice and haven't actually tried totting up the numbers to see that they haven't. I currently get around this by changing the "VAT: £x.xx" line to read "(Includes VAT £x.xx)" but it is conventional for the subtotal not to include VAT.

I just fixed this myself in 1.57c after seeing the rounding problem. The issue is that $currencies, which is a global, appears not to have been declared as global and therefore a local copy is used instead, which doesn't contain anything. I assume in previous Zen Cart versions it was declared global in some code that included the template (I've only previously tried it up to 1.55f so I can't comment on 1.56 versions).

The solution for me was to edit the template file includes/templates/YOUR_TEMPLATE/templates/tpl_modules_order_totals.php as follows.

Original:

<?php 
/**
 * Displays order-totals modules' output
 */
  for ($i=0; $i<$size; $i++) { ?>

to:

<?php 
/**
 * Displays order-totals modules' output
 */
  global $currencies;
  
  for ($i=0; $i<$size; $i++) { ?>

Having found and fixed the problem, however, I may now just delete the template override altogether as I think I prefer never to display the subtotal with VAT, even when showing prices inclusive of VAT to our UK customers. Including VAT in the subtotal and then showing the VAT on a separate line on the invoice prompts periodic queries from customers who think they have been charged VAT twice and haven't actually tried totting up the numbers to see that they haven't. I currently get around this by changing the "VAT: £x.xx" line to read "(Includes VAT £x.xx)" but it is conventional for the subtotal not to include VAT.

BillJ:

I just fixed this myself in 1.57c after seeing the rounding problem. The issue is that $currencies, which is a global, appears not to have been declared as global and therefore a local copy is used instead, which doesn't contain anything. I assume in previous Zen Cart versions it was declared global in some code that included the template (I've only previously tried it up to 1.55f so I can't comment on 1.56 versions).

The solution for me was to edit the template file includes/templates/YOUR_TEMPLATE/templates/tpl_modules_order_totals.php as follows.

Original:

> 
> to:
> ```
<?php 
/**
 * Displays order-totals modules' output
 */
  global $currencies;
  
  for ($i=0; $i<$size; $i++) { ?>

Having found and fixed the problem, however, I may now just delete the template override altogether as I think I prefer never to display the subtotal with VAT, even when showing prices inclusive of VAT to our UK customers. Including VAT in the subtotal and then showing the VAT on a separate line on the invoice prompts periodic queries from customers who think they have been charged VAT twice and haven't actually tried totting up the numbers to see that they haven't. I currently get around this by changing the "VAT: £x.xx" line to read "(Includes VAT £x.xx)" but it is conventional for the subtotal not to include VAT.

While this may have prevented the problem seen, it still doesn't look like the right solution or perhaps the problem is caused by something else.

The tpl_ files are expected to be in the global space. That means any variable referenced within them is expected to be in the global space. The $currencies variable when needed is routinely loaded either in the associated header_php.php file for the page or its main_template_vars like file. Having to declare $currencies as a global indicates that this template file is being loaded/run within some other code section like a function or class method. If that is the case, the function/class method really should ensure that the variable is brought into the current space rather than the file that is being called. Meaning, where global $currencies has been added, it should be within the out-of-scope code section that is calling this template file.

In other words would suggest using tools->developers tool kit to search for: tpl_modules_order_totals. I would suggest giving a few lines before/after so that might be able to tell when/where it is called within another function/class method and report the results.

mc12345678:

While this may have prevented the problem seen, it still doesn't look like the right solution or perhaps the problem is caused by something else.

The tpl_ files are expected to be in the global space. That means any variable referenced within them is expected to be in the global space. The $currencies variable when needed is routinely loaded either in the associated header_php.php file for the page or its main_template_vars like file. Having to declare $currencies as a global indicates that this template file is being loaded/run within some other code section like a function or class method. If that is the case, the function/class method really should ensure that the variable is brought into the current space rather than the file that is being called. Meaning, where global $currencies has been added, it should be within the out-of-scope code section that is calling this template file.
I do see what you're saying and I agree, to a point.
However, doesn't this mean that the function (or the page) including a template must predict all of the global variables a custom override might require and declare all of them in the function? It has no idea what code is in the overriding template, what it is doing and which globals it needs in order to do it.

As you say, though, perhaps the problem is caused by something else and the template shouldn't be included in a context that isn't truly global.

BillJ:

I do see what you're saying and I agree, to a point.
However, doesn't this mean that the function (or the page) including a template must predict all of the global variables a custom override might require and declare all of them in the function? It has no idea what code is in the overriding template, what it is doing and which globals it needs in order to do it.

If this were the style of design to consider the possibility of any template file to be so used, then every variable within every template should be declared as global and used as such; however, can see two parts to this, why would there be the design to include a normally expected global file in a non-global context and not know what it needs to support operation? Design by design, right? So, that leads to...

BillJ:

As you say, though, perhaps the problem is caused by something else and the template shouldn't be included in a context that isn't truly global.
There are multiple ways to activate or prepare a template file to be displayed/loaded in the global space. Of course, one question is why would/do ZC template files contain executable code rather than "reference" or fill-in-the-blank variables (obvious answer is that it was inherited and isn't actually in the way of operation)? If/when the template system gets so or similarly revised, it would be possible to set/modify the associated variable(s) to contain the information necessary though that wouldn't fix the template file within the limited scope function (as compared to an init_include, module, or other on-demand global scoped template file).

Yes, there may be a "reason" to load that template file within a function instead of some other way, inquiring minds certainly would like to hear. Good discussion, I think.