Chris74 Posted December 18, 2017 Share Posted December 18, 2017 I started a thread in the developer corner when it should be here. Admins please feel free to delete my other post. Hi I need help to fix a problem with the workflow of the order process that is a serious problem. I'm happy to pay for a developer to do this work for me. Here's the problem... On the latest version of the six template, (comparison order form) VAT is calculated before checkout, but the VAT calculation is optional and is open to abuse by the customer. In fact, it's an invitation to the customer to commit VAT fraud, either on purpose or accidentally. The "estimate taxes" option is a small tab next to the tab where you can add a discount code. Here are the problems... 1. Most customers won't even see this, or bother to use it. This will set the VAT rate incorrectly. 2. Entering the country and state are optional at this stage in the order process, but this is the point where VAT is calculated, so it's vital that this info be collected here. 3. The customer can change their country at the next stage in the process, after they have "estimated taxes", but changing the country at this stage doesn't change the VAT rate - so they can easily influence the price. The form invites them to choose any country they like for the tax rate, or not to bother, then set their country correctly so as to avoid suspicion. This will result in deliberate avoidance of the correct VAT and people paying the wrong amount just because they didn't notice the tab, or didn't understand it. WHMCS seems to think that paying the correct VAT rate should be optional, and that collecting accurate info from the customer during the order process is not important. Calculating the correct taxes is important, it's not an afterthought. What needs to be done? I have two possible suggestions... It would be preferable for the VAT to be calculated at the final stage, just like every other shopping cart system. Doing this would require the summary box on the right not to include the VAT calculation until checkout, so if this is not too difficult to do, an additional stage needs to be added into the process. Here's my first suggestion which is my preferred solution... 1. Remove the "Estimate Taxes" tab. 2. Remove the VAT calculation from the summary box until the final stage, so a sub total is only shown until they submit their address info. 3. Separate the final checkout process into two stages, entering and submitting info, then finally choosing a payment type and getting a correct summary - so that once the customer has entered their details, they have to submit and go to choose payment options, which will be on a final checkout page. To elaborate on point three, what I mean is that you have to submit the country and state before tax can be calculated - so moving the payment options to a final stage allows you to submit that data - and allows for the summary box to contain the VAT calculation at the last stage. Then the final page will just contain the payment options and the final summary box, terms and conditions checkbox. essentially, you're chopping the checkout in half and shoving the last section onto a new final step. This removes the need for a specific "estimate taxes" option, which is a stupid idea anyway. My second suggestion for a quick fix would be to keep the workflow the way it is currently, but.... 1. Remove the "Estimate Taxes" tab and instead add a section below for the customer to provide their country and state, so it is more prominent on the page. It must be mandatory with validation to stop them continuing unless that info has been entered. 2. When the customer enters their full address details later, they must not be able to change the country or state at this stage. Sure they can go back to the previous stage and change it, but they shouldn't be allowed to enter conflicting details. It is a fundamentally basic requirement that VAT is calculated on orders, but the way this currently works is just open to so much accidental or deliberate abuse. If I'd known it worked this way I wouldn't have upgraded to version 7. Now that I have, I need a fix for this problem as soon as possible -so if you can take this on, or you have any questions please let me know. Many thanks. 1 Quote Link to comment Share on other sites More sharing options...
andrew23 Posted December 18, 2017 Share Posted December 18, 2017 Hi, I could help you in solving this problem.. You can reach me on<removed> Best Wishes, Andrew 0 Quote Link to comment Share on other sites More sharing options...
brian! Posted December 18, 2017 Share Posted December 18, 2017 3 hours ago, Chris74 said: On the latest version of the six template, (comparison order form) VAT is calculated before checkout, but the VAT calculation is optional and is open to abuse by the customer. In fact, it's an invitation to the customer to commit VAT fraud, either on purpose or accidentally. The "estimate taxes" option is a small tab next to the tab where you can add a discount code. Here are the problems... just for the avoidance of doubt, you're not using the original "Comparison" template are you ?? that got deprecated 2 years ago in v6.1 and is no longer updated/shipped - i'm going to assume you're using one of it's three replacements (Premium, Pure or Supreme), because it sounds as though you're describing the later stages of Standard_Cart. 3 hours ago, Chris74 said: 1. Most customers won't even see this, or bother to use it. This will set the VAT rate incorrectly. it sets the VAT rate and assigns the country/state details to checkout... 3 hours ago, Chris74 said: 2. Entering the country and state are optional at this stage in the order process, but this is the point where VAT is calculated, so it's vital that this info be collected here. no it's not - it is the country/state chosen at checkout that determines the VAT rate used in the invoice... 3 hours ago, Chris74 said: 3. The customer can change their country at the next stage in the process, after they have "estimated taxes", but changing the country at this stage doesn't change the VAT rate - so they can easily influence the price. I just doubled checked this twice, first by setting to Germany (19%) in the estimate tax settings, but changing it to Italy (22%) at checkout - the invoice used Italy and charged 22% VAT... then I ordered again, set it to Italy @ viewcart (22%), but changed it to Iraq at checkout (no VAT) and the invoice correctly contains no tax. 3 hours ago, Chris74 said: The form invites them to choose any country they like for the tax rate, or not to bother, then set their country correctly so as to avoid suspicion. This will result in deliberate avoidance of the correct VAT and people paying the wrong amount just because they didn't notice the tab, or didn't understand it. the tab is irrelevant - what they put in checkout is the important detail... and if users want to commit tax fraud by saying they're in Iraq or wherever, then they can do it at checkout - though hopefully any fraud/geolocation methods you have in place should catch them doing that. 3 hours ago, Chris74 said: WHMCS seems to think that paying the correct VAT rate should be optional, and that collecting accurate info from the customer during the order process is not important. Calculating the correct taxes is important, it's not an afterthought. I will add that, during the Iraq test order at checkout, it did say that the Total Due Today was £60.99 - this would have been the amount due if they had been in Italy, so that amount didn't visually change after selecting a different country (Iraq) - the invoice amount is £49.99 - you could say that was a bug (though not by WHMCS own definition), but it's a design flaw... btw - i'm not arguing that the cart templates are great, they're really not and the whole cart process hasn't significantly changed in years... just that i'm not seeing the issue you're seeing. 3 hours ago, Chris74 said: I have two possible suggestions... It would be preferable for the VAT to be calculated at the final stage, just like every other shopping cart system. It is - though bear in mind that WHMCS can assume the customer is in the default country (from general settings -> localisation) until they either login, or select another country at checkout... so if you're default country is UK, and the products are taxable, then it would show VAT at 20% (assuming you've added a tax rate for UK)... this might change depending on whether you have the EU VAT addon enabled. 3 hours ago, Chris74 said: Doing this would require the summary box on the right not to include the VAT calculation until checkout, so if this is not too difficult to do, an additional stage needs to be added into the process. all the variables should be available in the ordersummary template if you want to remove tax being shown. 3 hours ago, Chris74 said: 1. Remove the "Estimate Taxes" tab. that's just deleting the <div role="tabpanel" class="tab-pane" id="calcTaxes"> block of code in the viewcart template... you could in theory use a Language Override to blank out {$LANG.orderForm.estimateTaxes}, but that wouldn't actually remove the tab, just visually seems to... but it's still there. 3 hours ago, Chris74 said: 2. Remove the VAT calculation from the summary box until the final stage, so a sub total is only shown until they submit their address info. as previously status, that's just a tweak to ordersummary.tpl 3 hours ago, Chris74 said: 3. Separate the final checkout process into two stages, entering and submitting info, then finally choosing a payment type and getting a correct summary - so that once the customer has entered their details, they have to submit and go to choose payment options, which will be on a final checkout page. To elaborate on point three, what I mean is that you have to submit the country and state before tax can be calculated - so moving the payment options to a final stage allows you to submit that data - and allows for the summary box to contain the VAT calculation at the last stage. Then the final page will just contain the payment options and the final summary box, terms and conditions checkbox. essentially, you're chopping the checkout in half and shoving the last section onto a new final step. This removes the need for a specific "estimate taxes" option, which is a stupid idea anyway. you can sort of already do that, but not in a simple way - and certainly not one that would be obvious to any user. if we go back to my original test order (Germany -> Italy), and to make things simpler, let's say the product is £10.... so setting the country to Germany in Estimate Taxes, sets the amount due to £11.90.... go forward to checkout, change the country to Italy and that amount doesn't change (but in fairness it's not designed to). but press the "Complete Order" button (with the ToS checkbox unticked or any required field not completed) and it recalculates the total using the updated VAT rate and refreshes the page.... and you'll get the usual error message about which fields have not yet been completed. so maybe you just need to redesign/reorder the checkout template, put a "Update Tax" button close to the country field and either hope by that stage they haven't completed the rest of the form, or find a workaround to that... untested, but it should work. 3 hours ago, Chris74 said: My second suggestion for a quick fix would be to keep the workflow the way it is currently, but.... the workflow is the workflow... it's not fit for purpose, but never really has been... hopefully v8 might change that, but that's many months away from even reaching beta. 3 hours ago, Chris74 said: 1. Remove the "Estimate Taxes" tab and instead add a section below for the customer to provide their country and state, so it is more prominent on the page. It must be mandatory with validation to stop them continuing unless that info has been entered. again, a tweak to viewcart.tpl - but is the second part necessary??... remove it by all means and let them choose a country at checkout...but I don't really think that ET is as much of an issue as you think it is - this is the first thread I can recall about it since the new templates were launched a couple of years ago. the splitting of estimate taxes out of the tabs has also been done in some commercially available orderform templates, such as Control. btw - we all know (but not WHMCS!) that "Bournemouth" is not a state/county of the UK... I don't even think it's a city, yet it's on the Counties list... I thought you might appreciate the irony given your other post... it's not technically difficult to do, just replacing tabs with 2 divs. 3 hours ago, Chris74 said: 2. When the customer enters their full address details later, they must not be able to change the country or state at this stage. Sure they can go back to the previous stage and change it, but they shouldn't be allowed to enter conflicting details. if you don't do 1) then 2) becomes irrelevant... though i'm tempted to think that the quick fix would be more hassle to do than the preferred solution. 3 hours ago, Chris74 said: If I'd known it worked this way I wouldn't have upgraded to version 7. then you should have tested first on a dev, or played with the Softaculous WHMCS Demo. 1 Quote Link to comment Share on other sites More sharing options...
Chris74 Posted December 18, 2017 Author Share Posted December 18, 2017 Ok, thanks for your detailed reply Brian. I have to confess that I didn't actually check out all the way - I went right to the end without submitting payment. I can see now that the total on the invoice is indeed different after you've checked out if you change the country - but as I'm sure you will agree, this is still not good enough. Most people won't get that far. Have people really been putting up with this? As you point out, the process is very badly flawed.In my opinion, It shouldn't include the VAT at all in the summary box until the last stage, after you have entered your details, just a sub total. Unfortunately that box doesn't exist past the second step anyway. It's incredibly confusing to the customer. If I placed an order and it told me all the way up until I submitted payment that the VAT rate was 20% when I was outside that VAT zone and I had zero VAT to pay, I wouldn't continue with the order. A customer isn't going to choose a payment method and submit payment if the incorrect cost to them is displayed before that point. It's the most poorly designed order process I've ever seen and this is supposed to be a specialist Billing product. It sucks. We're working with some pretty simple facts here. We don't know the net total until the customer enters their address details, so you'd expect the order process to be designed around that - but no, WHMCS simply does not tell the customer how much VAT they have to pay before they go to pay it! Like you point out, on the checkout page, the "Total due today" stays the same unless you make a mistake on the form, or add an update button as you suggest. I understand now why the "Estimate VAT" option has been included. It's a really lazy and dirty workaround for the above issue. It says "we cant be bothered to correctly design the order forms, so we'll just add this extra feature in to let people see how much tax they might end up paying before they check out" - but it just adds another layer of confusion to trip up the customer and the boxes are the wrong way around and if you clear the country it doesn't clear the state so you could end up being in Bolton, Uganda. It's infuriatingly useless. Honestly, I can't believe that I put my business essentially in the hands of a company that can't design a simple order form. If only there were better alternatives. Here's a question..... How possible would it be to "hide" the bottom section of the checkout page from " Payment Details " downwards, until a submit button was pressed? So the customer enters their details and chooses a password, then hits submit - at which point the payment details section is revealed, containing the correct "total due today" and payment options It would be pretty easy to expand that section to include sub total and VAT too as a final summary. I could even work that out for myself. I guess your earlier suggestion to update the totals with a button is similar and I have seen that done before, but its not quite enough for me. Ideally, I'd want to submit that form data before payment. Is there really no way to split the checkout template into two "pages" so that you submit your details, then "go to payment"? I'd really like to display a final payment page with the summary at the top. All the right stuff is already there , but of course its all one big form and I know enough about this stuff to think that it would be quite difficult to split out into two processes within the confines of the existing order templates. Is that right? I must find a solution though. This just will not do! 0 Quote Link to comment Share on other sites More sharing options...
Chris74 Posted December 19, 2017 Author Share Posted December 19, 2017 (edited) I've worked out that the templates that need changing are viewcart.tpl and checkout.tpl. I'm not sure what ordersummary.tpl does but it doesn't seem to factor into the process when using the premium comparison order form. Here's what I've achieved so far... 1. Create a language entries in /lang/overrides/english.php (and other files if needed) $_LANG['ordertotalbeforetax'] = "Total Due before tax"; $_LANG['calculatetaxheader'] = "Calculate VAT"; $_LANG['totaltax'] = "Total VAT"; $_LANG['calculatetaxdescription'] = "VAT is calculated based on your country. Click the button below to update the total due."; $_LANG['updatecheckouttotals'] = "Update Totals"; 2. Edit the templates/standard_cart/viewcart.tpl and Remove the following code... {if $taxenabled && !$loggedin} <li role="presentation"><a href="#calcTaxes" aria-controls="calcTaxes" role="tab" data-toggle="tab">{$LANG.orderForm.estimateTaxes}</a></li> {/if} 3. remove the following code... <div role="tabpanel" class="tab-pane" id="calcTaxes"> <form method="post" action="cart.php?a=setstateandcountry"> <div class="form-horizontal"> <div class="form-group"> <label for="inputState" class="col-sm-4 control-label">{$LANG.orderForm.state}</label> <div class="col-sm-7"> <input type="text" name="state" id="inputState" value="{$clientsdetails.state}" class="form-control"{if $loggedin} disabled="disabled"{/if} /> </div> </div> <div class="form-group"> <label for="inputCountry" class="col-sm-4 control-label">{$LANG.orderForm.country}</label> <div class="col-sm-7"> <select name="country" id="inputCountry" class="form-control"> {foreach $countries as $countrycode => $countrylabel} <option value="{$countrycode}"{if (!$country && $countrycode == $defaultcountry) || $countrycode eq $country} selected{/if}> {$countrylabel} </option> {/foreach} </select> </div> </div> <div class="form-group text-center"> <button type="submit" class="btn"> {$LANG.orderForm.updateTotals} </button> </div> </div> </form> </div> That gets rid of the "estimate taxes" tab. 4. Add a login condition to the following code... {if $loggedin} <div class="subtotal clearfix"> <span class="pull-left">{$LANG.ordersubtotal}</span> <span id="subtotal" class="pull-right">{$subtotal}</span> </div> {if $promotioncode || $taxrate || $taxrate2} <div class="bordered-totals"> {if $promotioncode} <div class="clearfix"> <span class="pull-left">{$promotiondescription}</span> <span id="discount" class="pull-right">{$discount}</span> </div> {/if} {if $taxrate} <div class="clearfix"> <span class="pull-left">{$taxname} @ {$taxrate}%</span> <span id="taxTotal1" class="pull-right">{$taxtotal}</span> </div> {/if} {if $taxrate2} <div class="clearfix"> <span class="pull-left">{$taxname2} @ {$taxrate2}%</span> <span id="taxTotal2" class="pull-right">{$taxtotal2}</span> </div> {/if} </div> {/if} <div class="recurring-totals clearfix"> <span class="pull-left">{$LANG.orderForm.totals}</span> <span id="recurring" class="pull-right recurring-charges"> <span id="recurringMonthly" {if !$totalrecurringmonthly}style="display:none;"{/if}> <span class="cost">{$totalrecurringmonthly}</span> {$LANG.orderpaymenttermmonthly}<br /> </span> <span id="recurringQuarterly" {if !$totalrecurringquarterly}style="display:none;"{/if}> <span class="cost">{$totalrecurringquarterly}</span> {$LANG.orderpaymenttermquarterly}<br /> </span> <span id="recurringSemiAnnually" {if !$totalrecurringsemiannually}style="display:none;"{/if}> <span class="cost">{$totalrecurringsemiannually}</span> {$LANG.orderpaymenttermsemiannually}<br /> </span> <span id="recurringAnnually" {if !$totalrecurringannually}style="display:none;"{/if}> <span class="cost">{$totalrecurringannually}</span> {$LANG.orderpaymenttermannually}<br /> </span> <span id="recurringBiennially" {if !$totalrecurringbiennially}style="display:none;"{/if}> <span class="cost">{$totalrecurringbiennially}</span> {$LANG.orderpaymenttermbiennially}<br /> </span> <span id="recurringTriennially" {if !$totalrecurringtriennially}style="display:none;"{/if}> <span class="cost">{$totalrecurringtriennially}</span> {$LANG.orderpaymenttermtriennially}<br /> </span> </span> </div> <div class="total-due-today total-due-today-padded"> <span id="totalDueToday" class="amt">{$total}</span> <span>{$LANG.ordertotalduetoday}</span> </div> {/if} That prevents the default VAT amounts from being displayed to new customers in the summary box. 4. Add this code underneath the above code... {if !$loggedin} <div class="total-due-today total-due-today-padded"> <span id="totalDueToday" class="amt">{$subtotal}</span> <span>{$LANG.ordertotalbeforetax}</span> </div> {/if} That displays only the sub total without VAT in the summary box for new customers. It looks like this... Edited December 19, 2017 by Chris74 0 Quote Link to comment Share on other sites More sharing options...
Chris74 Posted December 19, 2017 Author Share Posted December 19, 2017 (edited) Next step is to add the VAT summary into the checkout.tpl. This is a work in progress so it doesn't look very good currently... Edit /templates/standard_cart/checkout.tpl Add this on line 369, under the closing if statement... {if !$loggedin} <div class="sub-heading"> <span>{$LANG.calculatetaxheader}</span> </div> <div class="alert alert-success text-center large-text" role="alert"> <p>{$LANG.calculatetaxdescription}</p> {$LANG.ordersubtotal}: <strong>{$subtotal}</strong><br /> {$taxname} @ {$taxrate}% <br /> {$LANG.totaltax}: <strong>{$taxtotal}</strong><br /> {$LANG.ordertotalduetoday}: <strong>{$total}</strong><br /> <button type="submit" class="btn btn-primary btn-lg" onclick="this.value='{$LANG.pleasewait}'"> {$LANG.updatecheckouttotals} </button> </div> {/if} I've just used a submit button so right now all this does is submit the form, which errors - but has the desired effect of updating the details in the box. Obvioulsy it needs styling - I've just used an alert box for covenience. What I can't work out how to do is to update the totals without submitting the form. I wonder if anyone can help with that? Edited December 19, 2017 by Chris74 0 Quote Link to comment Share on other sites More sharing options...
brian! Posted December 19, 2017 Share Posted December 19, 2017 22 hours ago, Chris74 said: I have to confess that I didn't actually check out all the way - I went right to the end without submitting payment. testing 101 - go all the way! 22 hours ago, Chris74 said: but as I'm sure you will agree, this is still not good enough. if you were designing a billing program from scratch, it wouldn't (shouldn't) look anything like WHMCS - either admin or client side. 22 hours ago, Chris74 said: Have people really been putting up with this? yes... there have been occasional posts on here (from new members usually) saying WHMCS is the best thing since sliced bread (i'm paraphrasing!)... they must be seeing things that i'm not - or more likely, not seeing things that I do. 22 hours ago, Chris74 said: In my opinion, It shouldn't include the VAT at all in the summary box until the last stage, after you have entered your details, just a sub total. Unfortunately that box doesn't exist past the second step anyway. It's incredibly confusing to the customer. the quick fix (hack) for that would be to change your default country (in general settings -> localisation) to one that doesn't have a tax rate set in WHMCS... the most obvious one being "United States"... WHMCS will then assume that the user (unless logged in) is from the USA and will show pricing without tax... you could tweak the checkout page if you want it to show UK as the default country instead, but the other templates shouldn't then require any changes to remove the tax figures. 22 hours ago, Chris74 said: If I placed an order and it told me all the way up until I submitted payment that the VAT rate was 20% when I was outside that VAT zone and I had zero VAT to pay, I wouldn't continue with the order. A customer isn't going to choose a payment method and submit payment if the incorrect cost to them is displayed before that point. the cynic in me wonders whether WHMCS just tested this as USA users, where what you're seeing wouldn't occur... 22 hours ago, Chris74 said: It's the most poorly designed order process I've ever seen and this is supposed to be a specialist Billing product. It sucks. as I said previously, the process hasn't changed in years - it's still choose product/domain -> configure product --> configure domain -> viewcart -> checkout... if we had more flexibility with the process (without the need for serious coding), it would make the product so much better... even most commercial orderform templates are just css/design changes on the above process. 22 hours ago, Chris74 said: We're working with some pretty simple facts here. We don't know the net total until the customer enters their address details, so you'd expect the order process to be designed around that - but no, WHMCS simply does not tell the customer how much VAT they have to pay before they go to pay it! Like you point out, on the checkout page, the "Total due today" stays the same unless you make a mistake on the form, or add an update button as you suggest. it's crazy.... you treat this as normal because you see it every day... but take a step back, compare it to virtually any other modern cart system and it's just plain bewildering. 22 hours ago, Chris74 said: It's a really lazy and dirty workaround for the above issue. It says "we cant be bothered to correctly design the order forms, so we'll just add this extra feature in to let people see how much tax they might end up paying before they check out" yep... you can hear them thinking - "the cart system has always worked fine this way, but we'll just tweak it a little to get around the pesky issue of tax.".... i'm assuming they don't think it's an issue, otherwise it would be given the highest priority... but experience shows that when WHMCS has a core function that "works" in their eyes, they are loathed to change it. 22 hours ago, Chris74 said: Honestly, I can't believe that I put my business essentially in the hands of a company that can't design a simple order form. the inflexibility of the process is the big problem - free that up and easily allow additional pages in the process and you could transform the ordering experience to the user. 22 hours ago, Chris74 said: How possible would it be to "hide" the bottom section of the checkout page from " Payment Details " downwards, until a submit button was pressed? So the customer enters their details and chooses a password, then hits submit - at which point the payment details section is revealed, containing the correct "total due today" and payment options It would be pretty easy to expand that section to include sub total and VAT too as a final summary. I could even work that out for myself. I guess your earlier suggestion to update the totals with a button is similar and I have seen that done before, but its not quite enough for me. interesting question - enabling ToS would be useful for this as that would prevent the order going through until it's ticked - even if hidden, a payment gateway choice will automatically be made, so ToS would act as a brake on the process.... though that would also show an error stating that "You must accept our Terms of Service"... that might be a good thing or need to be suppressed. 22 hours ago, Chris74 said: Ideally, I'd want to submit that form data before payment. Is there really no way to split the checkout template into two "pages" so that you submit your details, then "go to payment"? I'd really like to display a final payment page with the summary at the top. All the right stuff is already there , but of course its all one big form and I know enough about this stuff to think that it would be quite difficult to split out into two processes within the confines of the existing order templates. Is that right? correct - it wouldn't be impossible to split, but would require some serious coding... e.g beyond simple template tweaks.... your hiding the payment details option would be simpler to complete. I suspect tomorrow is my last day here before Christmas (certainly for coding), and definitely I won't be around on Thursday, so i'll quickly take a look at the hiding option in the morning (unless you crack it first)... you'll have to post to the form to get the total updated - unless you recalc using jQuery etc but that might be unnecessary as posting should work for your needs. 1 Quote Link to comment Share on other sites More sharing options...
Chris74 Posted December 20, 2017 Author Share Posted December 20, 2017 Thanks again Brian, I think the only way to do this properly is with javascript. I'd considered using a modal box that pops up with the summary data after the address info had been entered, but again, this would require the form to be submitted, which would show error messages on the main form and I don't want to do that - and a modal box always runs the risk of being zapped by popup blockers. I think the javascript (ajax?) route is pretty straightforward, although too tricky for me. I guess it would involve assigning an ID to the country and state field, then updating a summary box in real time based on the contents of those fields. So this is still a service request to resolve this problem. Brian if you know javascript I'd gladly pay you to sort this out for me. 0 Quote Link to comment Share on other sites More sharing options...
Chris74 Posted December 20, 2017 Author Share Posted December 20, 2017 For now I've given in, but made the VAT calculation more prominent... 0 Quote Link to comment Share on other sites More sharing options...
xai Posted January 2, 2018 Share Posted January 2, 2018 @Chris74 I do have the exact same issue. Do you mind sharing the code changes for making the VAT calculation appearing more prominent? Thanks 0 Quote Link to comment Share on other sites More sharing options...
Chris74 Posted January 3, 2018 Author Share Posted January 3, 2018 @xai That was just a quick and dirty fix. The form fields don't really display properly on small devices. I've not had chance to re-visit this, however I think the best solution is for the order total on the viewcart stage to not include vat and only display a sub total - but display the correct vat and total at the checkout stage. Here is something I find very strange... In the latest version of WHMCS, they have included some javascript on the checkout page that specifically takes the country and updates the phone country code in real time, based on the country chosen. What I don't understand is why they haven't re-used that same javascript to update the "Total Due" in real time too, based on the vat rate of the country chosen! Surely that's pretty simple to do? In fact, doing so should be considered much more important than setting the country code, because that can easily be set manually. You'd think when they sat in a development meeting to introduce this javascript that someone would have mentioned this "total due" issue. I still find it completely ridiculous that the total due on the checkout page is entirely incorrect if you're outside the tax zone of the default country. This is inexcusable for a billing system. I wonder how many sales have been missed because of this. I also note that WHMCS are keeping very quiet about it. Would be interesting to hear what they have to say. 0 Quote Link to comment Share on other sites More sharing options...
xai Posted January 3, 2018 Share Posted January 3, 2018 @chris74 I agree ... the problem I have is that tax deduction doesn't work and wrong invoices are created for customers outside of the EU. If a new customer is ordering and creating a new account while ordering the default tax (in my case 20%) isn't deducted if the client is changing the country to another one where tax shouldn't be applied. These are the steps: New Customer adds product to cart Customer is NOT using the "estimate taxes" button to recalculate the price for his/her country Customer is creating the account during the order process and changes the country to one where the taxes should be deducted Invoice gets generated with the full price; price + tax instead of the price without tax. I have already created a support ticket and WHMCS support was able to replicate the issue on their end. I hope this is going to be fixed soon. 0 Quote Link to comment Share on other sites More sharing options...
Chris74 Posted January 4, 2018 Author Share Posted January 4, 2018 @xai I must say that the issue you're having is not the same. I would suggest that you've not configured your tax rules correctly, or you have a different problem. The issue here is related to the totals displayed on screen to the customer when ordering. Their VAT isn't calculated in the final total on the checkout page, BUT - the final amount is calculated correctly under normal circumstances, the client just doesn't get to see that until after they have entered their payment details, which is obviously not appropriate. They see a final total that is the incorrect amount. The invoice does have the correct amount but the client doesn't get to see the invoice until later - in most cases after they have paid. I would ask if you could please treat your issue as a separate problem that is specific to your installation. 1 Quote Link to comment Share on other sites More sharing options...
brian! Posted January 11, 2018 Share Posted January 11, 2018 On 1/3/2018 at 10:11, Chris74 said: In the latest version of WHMCS, they have included some javascript on the checkout page that specifically takes the country and updates the phone country code in real time, based on the country chosen. What I don't understand is why they haven't re-used that same javascript to update the "Total Due" in real time too, based on the vat rate of the country chosen! Surely that's pretty simple to do? WHCMS didn't write that javascript code - it was written by Jack O'Connor and freely made available on GitHub for others to use... and WHMCS have done so! https://github.com/jackocnr/intl-tel-input On 1/3/2018 at 10:11, Chris74 said: I wonder how many sales have been missed because of this. I can think of many WHMCS design flaws that will certainly have led to missed sales... there's no doubt in my mind... i've mentioned some of them directly to the highest WHMCS management.... silence was deafening... fingers in ears, head in the sand is their favourite position... I leave them to it now. btw - with great reluctance (as mentally I was preparing for Christmas) but curiosity, I did have a go at rewriting checkout.tpl before the festive break - it ended up being written entirely in Smarty and broke the page into two parts... first part included submitting contact details, country etc... then assuming there are no missing required fields, it shows the second half - password, gateways etc and the price for the order including the correct tax. I think I got it to about 80% finished... enough to see the idea would likely work, but might require further development - if you want to play with it as is, i'm happy to PM it to you. going down the ajax route seemed like too much work to me... you'd end up having to query the db to get the tax rates for each country and then do the calculations... thought it would be easier to let WHMCS do all the work and then try manipulate the output as required. 0 Quote Link to comment Share on other sites More sharing options...
Aaron Yarborough Posted November 29, 2018 Share Posted November 29, 2018 Hi all, We were stumbling into an issue where VAT was being applied to countries other than GB and had no way of changing the country within the cart (without having the user change it manually via the Estimate Taxes form). This isn't the most graceful solution, but it works pretty well for us: 1. Set a variable for the cart page so we can read the customer's country code. Luckily we're using Cloudflare which provides us with a country code value in $SERVER already however it wouldn't be too difficult to set one up yourselves. For our purposes it made sense to default the country value to GB if Cloudless doesn't provide one however it may not be ideal for others. function hook_template_vars_cart($vars) { $extra = array(); $extra['countrycode'] = $_SERVER["HTTP_CF_IPCOUNTRY"] !== 'XX' ? $_SERVER["HTTP_CF_IPCOUNTRY"] : 'GB'; return $extra; } add_hook('ClientAreaPageCart', 1, 'hook_template_vars_cart'); 2. We added a POST request via AJAX to the respective template for the first step in our checkout process (within orderforms/standard_cart/configureproductdomain.tpl). This shoots off the above variable's value to the server which then sets the country code against the user's session. <script type="text/javascript"> $.post('/cart.php?a=setstateandcountry&country={$countrycode}'); </script> Once the user gets all the way to the checkout screen, their country code has been updated and the correct VAT amounts show. It's worth mentioning that it's silly that there isn't something by default in place to handle circumstances like this however. After looking online it seems a lot of people are having the same or similar issues! Hope this helps somebody! 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.