Chris74

Nope. You seem to have misunderstood completely. What I'd like in the short term is for the amount due to the customer to be accurate, before they go to pay it. But it is very clear that the whole order process is very badly designed and the forms are laid out in an illogical and confusing way. On top of this, you make redesigning these impossible without using a whole lot of PHP to get around the inflexibility -which then takes a lot of upkeep when WHMCS is updated. that's why most WHMCS templates still use this awful standard cart. But of course, you are fully aware of all of this and you're just being pedantic with your reply. You know full well how badly designed your product is. What you need to do is go look at some good billing systems and see the way the order flow works - get an idea of how it should be done, then re-design your order forms. Of course you should really have done this properly in the first place. I would recommend that you hire a designer /developer who has a good understanding of user experience and user interface design because you clearly have nobody in your company who is capable of doing this properly at the moment. Constructive criticism.

Also, just to add to the above. Your form fields are the wrong way around and that javascript you added is pointless... You put the telephone field at the top of the form, so it is filled out by the customer early on. This means the customer will manually select the phone country code. When the customer selects the phone country code, this does not automatically update the country field further down the page. When they eventually get to the country field, it is below the state field, so they are asked to choose the state before choosing the country - but the state dropdown doesn't appear until after the country has been chosen. When they choose their country, this will automatically update the phone country field at the top of the page - but they already entered that manually anyway, so the javascript you've added to do this will never be used. A school child could design this form better than you have. There is a simple logical workflow required here that you have completely ignored. It's very basic stuff done very badly. Sorry if that's offensive to you but it's just true.

@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.

I'm aware of how it works. Obviously you don't see it as a problem that the customer never gets to see the total amount due calculated correctly before they go to pay. In my opinion, for any billing system, that's a fundamental requirement. You don't see it that way? You've designed it so that VAT is calculated before the client enters their location. That's a mistake. You think it is appropriate to calculate VAT (for display on screen) at the default country rate, all the way up until the client gets to the payment gateway, even after they have entered their country and state. It's just not appropriate to do that. VAT should be displayed based on their tax zone. You've provided a pretty useless workaround that suggests to the customer they might want to "estimate" their tax. tax isn't an estimation its an exact thing. As I said, this is easily missed and not enforced, so it doesn't really do anything to help this problem. When they get to the checkout, displayed on screen is the order total, but even if they change their country on that page, the order total stays the same - with the wrong total due to pay. You are consistently providing the incorrect due amount to the customer. They need to know how much it will cost before they choose a payment method - not afterwards! So what if the invoice is correct - they won't get that far! You've added some javascript to the checkout page that automatically updates the phone code in real time, based on the country. Why don't you think that it is important to do the same thing for the total due amount - which is specifically dependant on the tax rate of the country selected? You said... Yes but as I have explained above, this is calculated in the background and you don't tell the customer that. They don't get to see the revised amount until after they have chosen payment, so they are given the wrong amount to pay displayed on screen. The total displayed on the checkout page lists the amount due to pay. This is just above the payment method selection. It is there for the customer to check the amount they are being charged before deciding to pay - but for anyone that is outside of the default country, this total will be incorrect, even after they have entered their country and state, so it is hugely off putting for the customer and will easily result in lost sales at that crucial point where they are entering their card details to pay. A prime example is an Australian customer clearly being shown that they are paying 20% VAT when they shouldn't be paying any. Do you think that they will just get their card out any pay, when faced with the info on screen that they are being charged 20% more than they should? If you can't see how obvious that is, then there is no hope!

Invoices? Who said anything about invoices? Please see this...

@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.

"East Riding of Yorkshire" is missing from the above for some reason. states['GB'] = ["Aberdeenshire","Angus","Antrim","Argyll and Bute","Armagh","Ayrshire","Banffshire","Bath and North East Somerset","Bedfordshire","Berkshire","Berwickshire","Blaenau Gwent","Borders","Bridgend","Bristol","Buckinghamshire","Caerphilly","Caithness","Cambridgeshire","Cardiff","Carmarthenshire","Ceredigion","Channel Islands","Cheshire","Clackmannanshire","Conwy","Cornwall","County Durham","Cumbria","Denbighshire","Derbyshire","Devon","Dorset","Down","Dumfries and Galloway","Dunbartonshire","East Ayrshire","East Dunbartonshire","East Lothian","East Renfrewshire","East Riding of Yorkshire","East Sussex","Essex","Fermanagh","Fife","Flintshire","Gloucestershire","Greater London","Greater Manchester","Gwynedd","Hampshire","Herefordshire","Hertfordshire","Highland","Inverclyde","Isle of Anglesey","Isle of Wight","Isles of Scilly","Kent","Kincardineshire","Lanarkshire","Lancashire","Leicestershire","Lincolnshire","Londonderry","Merseyside","Merthyr Tydfil","Midlothian","Monmouthshire","Moray","Neath Port Talbot","Newport","Norfolk","Northamptonshire","North Ayrshire","North Lanarkshire","North Somerset","Northumberland","North Yorkshire","Nottinghamshire","Orkney","Oxfordshire","Pembrokeshire","Perth and Kinross","Powys","Renfrewshire","Rhondda Cynon Taff","Rutland","Shetland","Shropshire","Somerset","South Ayrshire","South Gloucestershire","South Lanarkshire","South Yorkshire","Staffordshire","Stirlingshire","Suffolk","Surrey","Swansea","Torfaen","Tyne and Wear","Tyrone","Vale of Glamorgan","Warwickshire","West Dunbartonshire","Western Isles","West Lothian","West Midlands","West Sussex","West Yorkshire","Wiltshire","Worcestershire","Wrexham","end"];

Here's the formatted list that can be pasted directly into the statesdropdown.js file. Note: I've added "Channel Islands" to my list in order to set up a VAT rule as they are tax exempt. Note: I've not added "co. " to the Northern Ireland counties. Just my preference. Up to you if you want to change that. Note: I've replaced "&" with "and" - again just my preference. states['GB'] = ["Aberdeenshire","Angus","Antrim","Argyll and Bute","Armagh","Ayrshire","Banffshire","Bath and North East Somerset","Bedfordshire","Berkshire","Berwickshire","Blaenau Gwent","Borders","Bridgend","Bristol","Buckinghamshire","Caerphilly","Caithness","Cambridgeshire","Cardiff","Carmarthenshire","Ceredigion","Channel Islands","Cheshire","Clackmannanshire","Conwy","Cornwall","County Durham","Cumbria","Denbighshire","Derbyshire","Devon","Dorset","Down","Dumfries and Galloway","Dunbartonshire","East Ayrshire","East Dunbartonshire","East Lothian","East Renfrewshire","East Sussex","Essex","Fermanagh","Fife","Flintshire","Gloucestershire","Greater London","Greater Manchester","Gwynedd","Hampshire","Herefordshire","Hertfordshire","Highland","Inverclyde","Isle of Anglesey","Isle of Wight","Isles of Scilly","Kent","Kincardineshire","Lanarkshire","Lancashire","Leicestershire","Lincolnshire","Londonderry","Merseyside","Merthyr Tydfil","Midlothian","Monmouthshire","Moray","Neath Port Talbot","Newport","Norfolk","Northamptonshire","North Ayrshire","North Lanarkshire","North Somerset","Northumberland","North Yorkshire","Nottinghamshire","Orkney","Oxfordshire","Pembrokeshire","Perth and Kinross","Powys","Renfrewshire","Rhondda Cynon Taff","Rutland","Shetland","Shropshire","Somerset","South Ayrshire","South Gloucestershire","South Lanarkshire","South Yorkshire","Staffordshire","Stirlingshire","Suffolk","Surrey","Swansea","Torfaen","Tyne and Wear","Tyrone","Vale of Glamorgan","Warwickshire","West Dunbartonshire","Western Isles","West Lothian","West Midlands","West Sussex","West Yorkshire","Wiltshire","Worcestershire","Wrexham","end"];

For now I've given in, but made the VAT calculation more prominent...

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.

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}: &nbsp; <strong>{$subtotal}</strong><br /> {$taxname} @ {$taxrate}% <br /> {$LANG.totaltax}: &nbsp; <strong>{$taxtotal}</strong><br /> {$LANG.ordertotalduetoday}: &nbsp; <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?

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...

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!

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.

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.