J-B Posted January 7, 2018 Share Posted January 7, 2018 Hi, I have report this Bug to WHMCS but WHMCS dont accept it and say to me to submit a request to the feature requests tracker. If I want to pay a invoice with my credit, I must use the format 12.23 in the input field. But I have configured my Currency Format (admin/configcurrencies.php) to 12,23 (with comma NOT point). So, we in germany dont use Point (.), we use comma (,). In the clientarea under viewinvoice.php?id=XXX the customers see the Credit in right Format "€65,45EUR" but the customers cant use this format in the Input field to pay the invoice. The customers goes crazy, why he cant pay this invoice. The customers are trying the format with the comma. How should the customer know that he must use the (US/UK) format with point here? That is a terrible Bug and I dont know why WHMCS dont accept it?! I can not expect that the customers must use a mix of formats. Link to comment Share on other sites More sharing options...
sentq Posted January 7, 2018 Share Posted January 7, 2018 if WHMCS point you Requests section, then they believe/pretend that what you ask for is something new or there is no bug at all and everything should work as expected. it might be helpful if you share WHMCS support response Link to comment Share on other sites More sharing options...
J-B Posted January 8, 2018 Author Share Posted January 8, 2018 Quote Hello J-B, Thank you for contacting WHMCS. This is the intended behavior of WHMCS. The Currency Format option only changes how currencies are displayed for customers. This functionality does not affect how they must be entered into the system; they must still be entered into the system as "12.23". However I can see how extending the Currency Format functionality so that it applies to input fields could be useful. Therefore I would encourage you to please submit a request to our feature requests tracker at http://requests.whmcs.comwhere other users can contribute to and vote on your idea. Ideas with the most votes and activity do get reviewed by our team. Best regards, my answer: Quote I think you are not understanding. You wrote "The Currency Format option only changes how currencies are displayed for customers ...", the viewinvoice (viewinvoice.php?id=XXX) is the customer area and the format are displaying wrong! In the admin area it can be the format "12.23" but for the customers it must be "12,23". Go to the Clientarea and try to pay you invoice with the credit. You will see that it is the format "12.23" and not "12,23" that I have configured. That is the clientarea not the adminarea, so it is a bug. Please fix it asap. WHMCS answer: Quote Hello J-B, I understand the behavior that you are describing. The Currency Format option is not designed to apply to any input fields in either the Client or Admin Areas. It only affects how currency values are displayed. All input fields must have data entered in as 12.34 ; this behavior extends to both the Admin and Client Areas. This is the intended behavior. If you would like to see the Currency Format functionality extended to input fields then I would recommend submitting a Feature Request. Best regards, Link to comment Share on other sites More sharing options...
brian! Posted January 10, 2018 Share Posted January 10, 2018 On 1/8/2018 at 09:10, J-B said: I would recommend submitting a Feature Request. New Year - same old drivel from Support... absolutely drives me nuts when Support says that... this is an issue the OP wants addressing now... not in a few weeks/months/years time. if they're calling it intended behaviour, then they don't see it as a bug... plump up a cushion, you may be waiting a while for a fix. two possible quick fixes would be to... 1. use Language Overrides to modify the text to tell the user that they need to use . and not , in the amount. 2. use a HMTL5 pattern tag in the input field in the checkout template to prevent them entering , and display an appropriate error message in German. using a hook would be another option, either to change the amount value to xx.xx rather than xx,xx - though that might still require a template edit to only use the modified value in the input box and not elsewhere.... or perhaps to modify it upon submission.... though I currently haven't investigated the credit payment options to know if modifying upon submission would work with this. 1 Link to comment Share on other sites More sharing options...
J-B Posted January 11, 2018 Author Share Posted January 11, 2018 @brian! Thank you for agreeing! Quote 1. use Language Overrides to modify the text to tell the user that they need to use . and not , in the amount. Thats look like very unprofessionell! That isnt a option for me. 11 hours ago, brian! said: 2. use a HMTL5 pattern tag in the input field in the checkout template to prevent them entering , and display an appropriate error message in German. using a hook would be another option, either to change the amount value to xx.xx rather than xx,xx - though that might still require a template edit to only use the modified value in the input box and not elsewhere.... or perhaps to modify it upon submission.... though I currently haven't investigated the credit payment options to know if modifying upon submission would work with this. I am not a coder to to realize that That is very sad that WHMCS dont accept this bug. I am very unhappy. When WHMCS want to be only a system for UK and US market, that whmcs must tell us this! Link to comment Share on other sites More sharing options...
brian! Posted January 11, 2018 Share Posted January 11, 2018 6 hours ago, J-B said: Thank you for agreeing! they have a habit of doing that - in my opinion, this isn't a case for a feature request, it's a bug... or at the very least, horrendously bad design and testing of the feature. 6 hours ago, J-B said: That looks like very unprofessional! That isn't a option for me. I didn't think it would be, but thought it worth mentioning! though one of the points you make in your post is very valid - how/why should the customer know that they have to enter the amount in xx.xx format?? logically it shouldn't even occur to them that they should need to... this feature either needs to support currency formats that use commas, or tell the user what format is acceptable. 6 hours ago, J-B said: I am not a coder to to realize that i've posted similar code before, it's going to be along the lines of... (viewinvoice.tpl ~ line 141) <input type="text" name="creditamount" value="{$creditamount}" class="form-control" pattern="^[0-9.]*$" oninvalid="this.setCustomValidity('Please use xx.xx rather than xx,xx')" oninput="setCustomValidity('')" /> this will only allow the numbers 0-9 and . to be entered - anything else, e.g a comma, and it will display an error message... if you wanted the error message to use German, you could use - forgive Google Translate, i'm sure you can use better German! <input type="text" name="creditamount" value="{$creditamount}" class="form-control" pattern="^[0-9.]*$" oninvalid="this.setCustomValidity('Bitte benutzen Sie xx.xx statt xx,xx')" oninput="setCustomValidity('')" /> or if you wanted the error message to be shown using the client's language, then use a Language Override... <input type="text" name="creditamount" value="{$creditamount}" class="form-control" pattern="^[0-9.]*$" oninvalid="this.setCustomValidity('{$LANG.customfieldvalidationerror}')" oninput="setCustomValidity('')" /> to save time in the above code, i'm using an existing language file string - but you should probably create your own (using the Language Overrides documentation) for each language that you use on your website. actually, there is an annoying bug with WHMCS original code in that when you add 40,34 in credit, it adds the €40 as credit but ignores the ,34... how something like that got past any basic internal testing is beyond me. now having given you two options, one of which you rejected(!), let me give you a third that should solve the problem until WHMCS get their act together on this.. it occurred to me that rather than using Smarty, or an action hook to react to the form submission, to use javascript to react *before* the form is submitted and change xx,xx to xx.xx in the background without the user noticing - so basically the client can now use xx.xx or xx,xx and both will (should!) work. in viewinvoice.tpl, within the <head> section, add the following... <script> function ChangeComma(){ str = document.usecredit.creditamount.value; res = str.replace(",", "."); document.usecredit.creditamount.value = res; document.getElementById("usecredit").submit(); } </script> and then the {if $manualapplycredit} changes from... {if $manualapplycredit} <div class="panel panel-success"> <div class="panel-heading"> <h3 class="panel-title"><strong>{$LANG.invoiceaddcreditapply}</strong></h3> </div> <div class="panel-body"> <form method="post" action="{$smarty.server.PHP_SELF}?id={$invoiceid}"> <input type="hidden" name="applycredit" value="true" /> {$LANG.invoiceaddcreditdesc1} <strong>{$totalcredit}</strong>. {$LANG.invoiceaddcreditdesc2}. {$LANG.invoiceaddcreditamount}: <div class="row"> <div class="col-xs-8 col-xs-offset-2 col-sm-4 col-sm-offset-4"> <div class="input-group"> <input type="text" name="creditamount" value="{$creditamount}" class="form-control" /> <span class="input-group-btn"> <input type="submit" value="{$LANG.invoiceaddcreditapply}" class="btn btn-success" /> </span> </div> </div> </div> </form> </div> </div> {/if} to... {if $manualapplycredit} <div class="panel panel-success"> <div class="panel-heading"> <h3 class="panel-title"><strong>{$LANG.invoiceaddcreditapply}</strong></h3> </div> <div class="panel-body"> <form method="post" action="{$smarty.server.PHP_SELF}?id={$invoiceid}" name="usecredit" onsubmit="ChangeComma();"> <input type="hidden" name="applycredit" value="true" /> {$LANG.invoiceaddcreditdesc1} <strong>{$totalcredit}</strong>. {$LANG.invoiceaddcreditdesc2}. {$LANG.invoiceaddcreditamount}: <div class="row"> <div class="col-xs-8 col-xs-offset-2 col-sm-4 col-sm-offset-4"> <div class="input-group"> <input type="text" name="creditamount" value="{if $totalcredit|strstr:','}{$creditamount|replace:'.':','}{else}{$creditamount}{/if}" class="form-control"/> <span class="input-group-btn"> <input type="submit" value="{$LANG.invoiceaddcreditapply}" class="btn btn-success" /> </span> </div> </div> </div> </form> </div> </div> {/if} so this code makes three changes - it no longer uses pattern to display an error message (though you could put it back in with different conditions if you wanted to); it replaces any , with . before submitting the form; and it changes the credit amount shown in the form - but only if the client has a , in their $totalcredit amount (e.g a quick way to test if they're using a currency formatted xx,xx). the js part you could do as a hook, but the form has no name and so the template would likely have to be edited anyway to add a name... also, I haven't tested how this works if the client has 1000+ of credit... if it causes an issue, it should be fixable, but hopefully it's unlikely a client would have that much credit. I should also add that the above template code is from v7.4.1 but I don't think the latest version at this time (v7.4.2) has changed this template so the above code should be valid. 1 Link to comment Share on other sites More sharing options...
J-B Posted January 12, 2018 Author Share Posted January 12, 2018 Hey @brian! thanks a lot for your work! I have test it and it works! Link to comment Share on other sites More sharing options...
Recommended Posts