Jump to content

Recommended Posts

I have a product which I need to charge full cycle on upgrade and to be billed on the 1st. In order to do this I require the upgrade to be charge full cycle on the next invoice (provided I set the original order to always bill on the 1st).

 

I select charge full cycle and this does not allow me to do it and the same amount appears if I choose pro rata.

 

 

I have ordered via another provider using whmcs and can select to upgrade now or next month and both options charge me full cycle.

Share this post


Link to post
Share on other sites

HI,

Regrettably this feature has not yet been implemented. It was an oversight that the checkbox was left there.

My apologies for the confusion.

Share this post


Link to post
Share on other sites

We need this feature too. We requested it several years ago and offered to pay to have it completed. (yes we need it that much!). For us it's critical because it allows access to resources (for us is sending emails) at a much higher level without paying for it fully, its especially and issue if the user upgrades at the end of their current cycle causing the prorata amount of the need product to be very small but yet still allow full use of those resources.

 

If anyone else is interested in this feature please post your thoughts here.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Similar Content

    • By dev_sarks
      Hi,
       
      We have some products that we are selling along with Domain Registration. The problem now is the user cannot Purchase the products for more than 3 years since the Product/Service configuration Pricing limits to 3 year.
       
      So How is it possible to overcome this issue ? How we can set product purchasing year to exactly same as like domains. ???
       
       
      Thanks in Advance,
       
      DevSarks....
    • By Seiya
      We get dozens of requests every week to upgrade monthly accounts to our much cheaper annual billing cycle. 90% of customers have Paypal subscriptions. The way we've been doing is as follows:
       
      1. Issue a prorated refund.
      2. Cancel Paypal subscription.
      3. Create new order with new billing cycle
      4. Copy over module information to new product. Terminate old product.
      5. Request customer to pay invoice for new order in client area.
       

       
      These steps which take about 10 minutes result in the customer having a new Paypal subscription for the new billing cycle. However the process makes us all cry followed by puking.
       
      However, if we use the WHMCS upgrade product button it calculates (days till next due date * future billing cycle day rate - days till next due date * current billing cycle day rate) which usually results in a credit to the customer which is discounted on the next due date. This would appear much easier than the process above however the invoice that it generates doesn't give the customer the option of setting up a Paypal subscription.
       
      Has anyone figured out how to do this with less effort and customer frustration? Its important that customers end up with a new Paypal subscription, that is all. Any help would be immensely appreciated by our team.
    • By epretorious
      We have a month-to-month hosting customer that would like to prepay for an entire year of hosting.
       
      How can I arrange that?
       
      - - - Updated - - -
       
      I just noticed the "Add Billable Item" feature in the Customer Profile (https://www.example.com/whmcs/admin/clientsbillableitems.php?userid=9999&action=manage) and found the Billable Items help page but I'm still not sure that this is the best / most appropriate way of handling the change.
       
      Ideas? Suggestions?
    • By brian!
      When choosing a product that has a recurring billing cycle, WHMCS will show the price in one of two fixed ways – depending on whether the "Monthly Pricing Breakdown" checkbox is ticked in the "Ordering" settings tab within the Admin Area.
       
      If it is not ticked, then the price will be displayed alongside the cycle names (taken from the language files) for the available cycles – if there are setup fees included for the cycle, they will be added to the end of the text (shown below on the left).
       
      However, if the checkbox is ticked, then WHMCS will not display the total cost of the cycles, but will calculate an equivalent monthly price for each of them instead (shown below on the right).
       



       
      A question was asked in the Community Forum by Ambarella about how to show the total price, the saving from the minimum cycle and also the monthly price for each cycle – e.g. for a layout such as this:
       
       
      http://forum.whmcs.com/showthread.php?84298-How-to-display-discounted-pricing-on-order-pages
       
      I was intrigued to see if there was an answer to this question as it has previously been asked many times and as far as I could tell, never really answered.
       
      Unfortunately, it is not possible to do this solely by changing any admin settings – the above two methods for displaying the cost of recurring billing cycles are hard-coded into WHMCS. If we were looking to only make a minor change to either layout, it would be possible to do so by slightly modifying the language files and tweaking the existing billing cycle variable in the template. However, Ambarella’s desired layout uses aspects of both methods and then additionally wishes to show the saving too - minor tweaking wouldn’t be sufficient to do this and so a more thorough solution has to be developed.
       
      The final solution turned out to be far simpler, from a coding point of view, than I had first imagined as most of the required variables were easily obtainable. I have also tried to keep it flexible and simple enough for others to modify for their own needs.
       
      This has been tested using the latest release of WHMCS as I write this, v5.3.4, and will work with all of the default order form templates (Ajaxcart, Boxes, Cart, Comparison, Modern, Slider, Verticalsteps and Web20Cart). If they’re similar in design to the default templates, I can see no reason why this solution shouldn’t work with customised order form templates either.
       
      There are three steps to this solution, listed below, and I will go through each of them briefly before bringing them all together to show the completed result.
       

      Possible changes to the language file(s).
      Creation of the new variables to calculate and store the required values.
      Modifying the template to use these new variables.

       
      Language Files
       
      The two default methods for showing recurring billing cycles use existing language variables in their display. When “Monthly Pricing Breakdown” is enabled, the following variables are used. In the example below, this is their values from the english.php language file:
       

      $_LANG['orderpaymentterm1month'] = "1 Month Price"; $_LANG['orderpaymentterm3month'] = "3 Month Price"; $_LANG['orderpaymentterm6month'] = "6 Month Price"; $_LANG['orderpaymentterm12month'] = "12 Month Price"; $_LANG['orderpaymentterm24month'] = "24 Month Price"; $_LANG['orderpaymentterm36month'] = "36 Month Price";
      When disabled, it uses the following variables:
       

      $_LANG['orderpaymenttermmonthly'] = "Monthly"; $_LANG['orderpaymenttermquarterly'] = "Quarterly"; $_LANG['orderpaymenttermsemiannually'] = "Semi-Annually"; $_LANG['orderpaymenttermannually'] = "Annually"; $_LANG['orderpaymenttermbiennially'] = "Biennially"; $_LANG['orderpaymenttermtriennially'] = "Triennially";
       
      Ideally, if you can use any of the above groups of variables without modifying them, then it is probably easier to do so.
       
      But if you feel that you need to modify any of them for use with this method, I would strongly urge you to consider the consequences carefully before doing so. The second group of variables (Monthly, Quarterly, Semi-Annually etc) are also used on the cart summary page, viewcart.tpl, and so any changes you make to them for use in the billing cycle page, will also affect their display on the cart summary page too.



       
       
      As an aside, I should probably add that if your WHMCS site only uses one language, then you could code the language directly in the template rather than using language variables – but for the sake of this tutorial, I will assume you are not and use the language files.
       
      Using the example of Ambarella’s desired output of "Monthly Cost", "Quarterly Cost" etc, you might think that it would be easier to use the existing variable for "Monthly", add another variable to store "Cost" - then use them together.
       
      While this might work in English, it would not necessary be grammatically correct in other languages – for example, in the French.php language file, the value for "Monthly" is:
       

      $_LANG['orderpaymenttermmonthly'] = "Mensuel";
      The French word for "Cost" is "coût" – so if we put them together, we would get "Mensuel coût". Using my (limited!) understanding of French, I think that it should really be "coût mensuel" – and this appears to be confirmed by Google Translate.
       
      So to make things easier, we will start by creating six new language variables for use with this recurring billing cycle solution and add them to the language override file(s).
       
       
      Language Overrides
       
      Although we can edit the existing language files in WHMCS, it is recommended that you do not because when you update WHMCS, you will overwrite these language files – and subsequently lose any changes that you have made to them.
       
      http://docs.whmcs.com/Language_Overrides
       
      To create a Language Override file, we would follow this procedure:
       

      Create the folder 'overrides' within the 'lang' folder.
      Create or copy the language file you want to override. For example, to create an override for the French language you create ./lang/overrides/french.php
      Open the newly created file in your preferred editor.
      Start the file with a PHP tag '<?php' indicating PHP code is to be used.

       
      Try to use variable names that make sense to where they’re being used, and have not previously been used. So, for our six recurring billing cycles, let’s use the following:
       

      $_LANG['billingcyclemonth'] = "Monthly Cost"; $_LANG['billingcyclequart'] = "Quarterly Cost"; $_LANG['billingcyclesemi'] = "Semi-Annual Cost"; $_LANG['billingcycleannual'] = "Annual Cost"; $_LANG['billingcyclebienn'] = "Biennial Cost"; $_LANG['billingcycletrienn'] = "Triennial Cost";
      To get Ambarella’s output, we will need two additional new language variables – one for “Saving” and another for “Per Month”.
       

      $_LANG['cyclesaving'] = "Save"; $_LANG['permonth'] = "P/m";
      Now that we have these language variables created, we can move on to making the calculations and saving
      them for use in the display.
       
       
      Calculations and Variables
       
       
      As the template system used by WHMCS is based on Smarty, I have used only Smarty code for this solution. It would be possible to perform these calculations using PHP within the template, but it is often frowned upon to use {php} tags in the templates. Also, I believe that as of Smarty v3, the option to do use {php} has been removed. Although WHMCS currently uses Smarty v2, I am sure that at some point it will be upgraded.
       
      Therefore, as it should be easier for others to follow, and hopefully avoid future upgrade complications, I decided to write the solution entirely using Smarty tags.
       
      We need to calculate the saving of a recurring billing cycle compared to the minimum billing cycle – this would probably be the monthly cycle, but this is not always the case. Usefully, the variable that stores the minimum billing cycle is available to us and so we can use it in our calculations to determine the correct savings for each enabled recurring billing cycle based on the minimum cycle.
       
      Additionally, we need to calculate the price per month of a recurring billing cycle – but this is simple as it is just the total price for the billing cycle divided by its total number of months.
       
      So let’s start with the easier step first – calculating the price per month of a cycle. Obviously, we don’t have to calculate the price per month for the monthly cycle, so we just need to work out the other five.
      For this we need two variables - the total billing cycle cost (which we can obtain from existing variables) and the number of months in each cycle (which we will define ourselves).
       
      First, we create a new variable and give it a value of zero to ensure that any calculations are not added to any previous total. Then, using the {math} Smarty tag, we assign our result to this variable; define what the equation is; specify the variables we’re using in the equation and set the format of the resulting answer... and then repeat the same process for the remaining recurring billing cycles.
       

      {assign var="qmonthprice" value=0} {math assign="qmonthprice" equation="d / b" b=3 d=$pricing.rawpricing.quarterly format="%.2f"} {assign var="smonthprice" value=0} {math assign="smonthprice" equation="d / b" b=6 d=$pricing.rawpricing.semiannually format="%.2f"} {assign var="amonthprice" value=0} {math assign="amonthprice" equation="d / b" b=12 d=$pricing.rawpricing.annually format="%.2f"} {assign var="bmonthprice" value=0} {math assign="bmonthprice" equation="d / b" b=24 d=$pricing.rawpricing.biennially format="%.2f"} {assign var="tmonthprice" value=0} {math assign="tmonthprice" equation="d / b" b=36 d=$pricing.rawpricing.triennially format="%.2f"}
      The above code will create the price per month for each recurring billing cycle and store it to two decimal places.
       
      Next we need to calculate the savings – this uses a similar method to the previous example, but there are more variables required and thus the equation itself is more complicated - we will also use an {if} statement to determine what the minimum billing cycle is.
       
      To calculate the saving, we also take into account any setup fees for each cycle. For the previous “price per month” calculation, I have ignored any setup fees – but these could easily be added by modifying the previous equations if you wished to include them.
       
      As the minimum billing cycle increases, there are fewer additional cycles available and so fewer calculations will be required. For "Monthly", there are five saving calculations to be made – but by the time the minimum cycle is "Biennial", there is only one calculation required. If the minimum billing cycle is "Triennial", then it will not necessary to calculate any savings as there will only be one recurring billing cycle available.
       
      Here is a small example of the required code...
       

      {if $pricing.minprice.cycle eq "monthly"} {assign var="qsaving" value=0} {math assign="qsaving" equation="((a * b) + c) - (d + e)" a=$pricing.rawpricing.monthly b=3 c=$pricing.rawpricing.msetupfee d=$pricing.rawpricing.quarterly e=$pricing.rawpricing.qsetupfee format="%.2f"} {/if}
      The above code will calculate the savings for the quarterly billing cycle based on the minimum billing cycle being monthly, and store it to two decimal places.
       
      So we have our modified language variables; we have created our equations to calculate the price per month / cycle savings and assigned them to new variables – the third step is to integrate these into the templates.
       
      Template Modifications
       
      As I stated earlier in this tutorial, this solution will work for all of the default order form templates and should work for customised order form templates too.
       
      While there might be slight variations in the code used to create the billing cycle table in the different order form templates, the six important variables remain the same – and it is only these that you will need to replace with my new code.
       
       
      If we use "Comparison" as an example and look at the current code for displaying the monthly cycle:
       

      {if $pricing.monthly}<tr><td class="radiofield"> <input type="radio" name="billingcycle" id="cycle1" value="monthly"{if $billingcycle eq "monthly"} checked{/if} onclick="submit()" /></td><td class="fieldarea"><label for="cycle1">{$pricing.monthly}</label></td></tr>{/if}
      To use the new modified code to display our customised layout, you need to replace the above with:
       

       
      As you can see, the basics of the layout remain exactly the same, all we have done is replaced {$pricing.monthly} with the following:
       

      {$LANG.billingcyclemonth} {$currency.prefix}{$pricing.rawpricing.monthly}{$currency.suffix}{if $pricing.rawpricing.msetupfee neq 0} + {$currency.prefix}{$pricing.rawpricing.msetupfee}{$currency.suffix} {$LANG.ordersetupfee}{/if}
       
      Some of these variables you will recognise as we have created them previously – the others are defined by WHMCS, either to store price / setup fee values, or currency strings.
       
      {$currency.prefix} - The prefix defined in your currency settings, e.g. $, £, € etc or left blank.
      {$currency.suffix} - The suffix defined in your currency settings, e.g. USD, GBP, EUR etc or left blank.
       
      If we take a look at the next billing cycle, in this case quarterly, you will see some additional code that will generate the saving text (which obviously is not used on the minimum billing cycle).
       
       
      After adding the code for the remaining billing cycles, the output using the Comparison order form would be as follows:
       



       
      In the above examples, I’ve intentionally setup some billing cycles to have setup fees and others not – this was to thoroughly test the equations used.
       
      So that’s a brief explanation of the theory, next we will assemble the three steps and bring them together for the finished solution.
       
       

      Language Files

       
       
      As I previously listed, here are the eight new language variables - if you want to use them, remember to add them to your language override file(s). Should you need to add more or change these, please do so!
       

      $_LANG['billingcyclemonth'] = "Monthly Cost"; $_LANG['billingcyclequart'] = "Quarterly Cost"; $_LANG['billingcyclesemi'] = "Semi-Annual Cost"; $_LANG['billingcycleannual'] = "Annual Cost"; $_LANG['billingcyclebienn'] = "Biennial Cost"; $_LANG['billingcycletrienn'] = "Triennial Cost"; $_LANG['cyclesaving'] = "Save"; $_LANG['permonth'] = "P/m";
       
       

      Calculations and Variables


       
      If you require calculations and new variables for your solution, add them to the template before the lines in which these newly created variables are called.
       
      For this solution, we will need to add the following to the 'configureproduct.tpl' order form template(s) *before* the template modifications of step 3.
       

      {* Calculate the price per month *} {assign var="qmonthprice" value=0} {math assign="qmonthprice" equation="d / b" b=3 d=$pricing.rawpricing.quarterly format="%.2f"} {assign var="smonthprice" value=0} {math assign="smonthprice" equation="d / b" b=6 d=$pricing.rawpricing.semiannually format="%.2f"} {assign var="amonthprice" value=0} {math assign="amonthprice" equation="d / b" b=12 d=$pricing.rawpricing.annually format="%.2f"} {assign var="bmonthprice" value=0} {math assign="bmonthprice" equation="d / b" b=24 d=$pricing.rawpricing.biennially format="%.2f"} {assign var="tmonthprice" value=0} {math assign="tmonthprice" equation="d / b" b=36 d=$pricing.rawpricing.triennially format="%.2f"} {* Calculate the cycle savings *} {if $pricing.minprice.cycle eq "monthly"} {assign var="qsaving" value=0} {math assign="qsaving" equation="((a * b) + c) - (d + e)" a=$pricing.rawpricing.monthly b=3 c=$pricing.rawpricing.msetupfee d=$pricing.rawpricing.quarterly e=$pricing.rawpricing.qsetupfee format="%.2f"} {assign var="ssaving" value=0} {math assign="ssaving" equation="((a * b) + c) - (d + e)" a=$pricing.rawpricing.monthly b=6 c=$pricing.rawpricing.msetupfee d=$pricing.rawpricing.semiannually e=$pricing.rawpricing.ssetupfee format="%.2f"} {assign var="asaving" value=0} {math assign="asaving" equation="((a * b) + c) - (d + e)" a=$pricing.rawpricing.monthly b=12 c=$pricing.rawpricing.msetupfee d=$pricing.rawpricing.annually e=$pricing.rawpricing.asetupfee format="%.2f"} {assign var="bsaving" value=0} {math assign="bsaving" equation="((a * b) + c) - (d + e)" a=$pricing.rawpricing.monthly b=24 c=$pricing.rawpricing.msetupfee d=$pricing.rawpricing.biennially e=$pricing.rawpricing.bsetupfee format="%.2f"} {assign var="tsaving" value=0} {math assign="tsaving" equation="((a * b) + c) - (d + e)" a=$pricing.rawpricing.monthly b=36 c=$pricing.rawpricing.msetupfee d=$pricing.rawpricing.triennially e=$pricing.rawpricing.tsetupfee format="%.2f"} {elseif $pricing.minprice.cycle eq "quarterly"} {assign var="ssaving" value=0} {math assign="ssaving" equation="((a * b) + c) - (d + e)" a=$pricing.rawpricing.quarterly b=2 c=$pricing.rawpricing.qsetupfee d=$pricing.rawpricing.semiannually e=$pricing.rawpricing.ssetupfee format="%.2f"} {assign var="asaving" value=0} {math assign="asaving" equation="((a * b) + c) - (d + e)" a=$pricing.rawpricing.quarterly b=4 c=$pricing.rawpricing.qsetupfee d=$pricing.rawpricing.annually e=$pricing.rawpricing.asetupfee format="%.2f"} {assign var="bsaving" value=0} {math assign="bsaving" equation="((a * b) + c) - (d + e)" a=$pricing.rawpricing.quarterly b=8 c=$pricing.rawpricing.qsetupfee d=$pricing.rawpricing.biennially e=$pricing.rawpricing.bsetupfee format="%.2f"} {assign var="tsaving" value=0} {math assign="tsaving" equation="((a * b) + c) - (d + e)" a=$pricing.rawpricing.quarterly b=12 c=$pricing.rawpricing.qsetupfee d=$pricing.rawpricing.triennially e=$pricing.rawpricing.tsetupfee format="%.2f"} {elseif $pricing.minprice.cycle eq "semiannually"} {assign var="asaving" value=0} {math assign="asaving" equation="((a * b) + c) - (d + e)" a=$pricing.rawpricing.semiannually b=2 c=$pricing.rawpricing.ssetupfee d=$pricing.rawpricing.annually e=$pricing.rawpricing.asetupfee format="%.2f"} {assign var="bsaving" value=0} {math assign="bsaving" equation="((a * b) + c) - (d + e)" a=$pricing.rawpricing.semiannually b=4 c=$pricing.rawpricing.ssetupfee d=$pricing.rawpricing.biennially e=$pricing.rawpricing.bsetupfee format="%.2f"} {assign var="tsaving" value=0} {math assign="tsaving" equation="((a * b) + c) - (d + e)" a=$pricing.rawpricing.semiannually b=8 c=$pricing.rawpricing.ssetupfee d=$pricing.rawpricing.triennially e=$pricing.rawpricing.tsetupfee format="%.2f"} {elseif $pricing.minprice.cycle eq "annually"} {assign var="bsaving" value=0} {math assign="bsaving" equation="((a * b) + c) - (d + e)" a=$pricing.rawpricing.annually b=2 c=$pricing.rawpricing.asetupfee d=$pricing.rawpricing.biennially e=$pricing.rawpricing.bsetupfee format="%.2f"} {assign var="tsaving" value=0} {math assign="tsaving" equation="((a * b) + c) - (d + e)" a=$pricing.rawpricing.annually b=3 c=$pricing.rawpricing.asetupfee d=$pricing.rawpricing.triennially e=$pricing.rawpricing.tsetupfee format="%.2f"} {elseif $pricing.minprice.cycle eq "biennially"} {assign var="tsaving" value=0} {math assign="tsaving" equation="((a * b) + c) - (d + e)" a=$pricing.rawpricing.biennially b=1.5 c=$pricing.rawpricing.bsetupfee d=$pricing.rawpricing.triennially e=$pricing.rawpricing.tsetupfee format="%.2f"} {/if}
       
       

      Template Modifications

       
       
      In the previous step, we modified the 'configureproduct.tpl' to calculate and assign some new variables. Next, we will replace the existing recurring billing cycle code in that same template file with the new code.
       
      To make this solution complete, I will go through the default order form templates and show the existing code, plus the new code to replace it with.
       
       
      Ajaxcart
       
       

       


      The default recurring billing cycle code for Ajaxcart (configureproduct.tpl) is...
       
       
      Replace the above with the new modified code...
       
      Please note: This code appeared not to work in v5.3.3, but following the v5.3.4 maintenance release, the pricing bugs have been fixed in WHMCS and this solution now works using Ajaxcart in v5.3.4
       
       
      Boxes
       
       



      The original code and the replacement code are the same as for Ajaxcart.

       
      Cart
       
       



       
      The original code and the replacement code are the same as for Ajaxcart.
       
      Comparison
       
       
      The default recurring billing cycle code for Comparison (configureproduct.tpl) is...
       
      Replace the above with the new modified code...
       
       
       
      Modern & Slider




       
      The default recurring billing cycle code for Modern & Slider (configureproduct.tpl) is...
       
      Replace the above with the new modified code...
       
       
      Verticalsteps
       
       



       
      The original code and the replacement code are the same as for Ajaxcart.
       
       
      Web20Cart
       



       
      The original code and the replacement code are the same as for Ajaxcart.
       
       
      Taking the solution to the next level
       
       
      During this tutorial, I’ve shown how, instead of using either of the default WHMCS predefined displays of recurring billing cycles, we can define and use our own specified layout.
       
      But, why stop there? Now that we are no longer constrained by hardcoded displays, we could take this further and make other changes... some trivial, others cosmetic and perhaps one or two that are very powerful!
       
      Ok, let’s start off with something trivial that you can use on those templates that don’t have a dropdown to display the cycles – e.g., Comparison, Modern and Slider.
       
      If you wanted to bold the billing cycle names, and perhaps highlight any potential savings by showing them in red, you could use the following code:
       



       
      When originally working out the Smarty code for this tutorial, I did consider using combined variables as WHMCS currently does, e.g $pricing.monthly etc, where a number of variables are assembled together to create a single easily callable variable.
       
      However, I decided against doing this for a number of reasons – firstly, I wanted to show all the component variables separately to make it easier for others to remove or add variables themselves; Secondly, because the variables are separate, each can be modified (either with Smarty code or as with the above html/css) individually and thirdly, in most circumstances I can foresee with this, I don’t think there’s any real advantage in doing so!
       
      So we’ve modified the display a little, but why don’t we try to do something a little more powerful!
       
      Up until this point, we have simply been replacing the default method of displaying the recurring billing cycles with our customised solution - but if we can create one solution, why not a second, a third or a hundred?
       
      We are now in a position where, instead of WHMCS just using one recurring billing cycle display method for the entire site, we can specify different cycle displays for each product and/or product group.
       
      Put simply – each individual product or product group can use its own method for displaying recurring billing cycles, as defined by you!
       
      The code itself is straightforward and uses the variables for Group ID (gid) and Product ID (pid) – these values can be obtained from the “Direct Cart Links” section of the Product or Product Group in the Admin Area - http://docs.whmcs.com/Products_and_Services#Links_tab
       
      As an example, let’s use Ajaxcart and specify a custom display method for one product – all other products will use the default method of display (in practice this could be another custom layout, but to save time and keep things simple, we’ll use the default display code).
       
      in basic terms, this:
       
       
      In actual code...
       
       
      If you wanted to select product groups and individual products to use the same display method, then you could use...
       
       
      You can add as many products and/or groups you want to the above statement or use multiple {if} statements - just remember to end the block of code with a closing {/if},
       
      This advanced solution should hopefully allow you to make the shopping process slightly easier for your customers by enabling you to use more appropriate billing cycle text for each product and/or group.
       
      I suspect that I've only scratched the surface of what is possible with this technique... so if anyone turns this into a commercial addon, I'd appreciate a share of the profits, a mention - or at the very least, a small glass of cooking sherry to get me through the day.*
       
      * I'd add a smilie at this point, but I'm limited to ten images and can't add one! lol
  • Recently Browsing   0 members

    No registered users viewing this page.

×

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated