Hi guys,

(This is not a feature request, it is a feature offer, really!)

I have a need for one of my websites to be able to make a single recurring fee for all the items that a user purchases. The problem is that each user may purchase products one at a time, and on a long scale in regard to time (i.e. on day 1, they get product A, two months later, they get product B.)

So my idea would be to get all the order together under a single recurring fee (i.e. right now you attach one recurring fee to each product, I'd like to share the same recurring fee for all those products and I could have different sets of products that share different recurring fees...)

I do not expect you to program this feature, but I was wondering, if I were to do so, would you agree to apply the fix, so that way I don't have to do so on each one of your other updates?

My current insight would be something like this (see attached picture as well):

  1. Add an entry so someone can attach the UC Recurring fees of an object to a taxonomy. That taxonomy is specific to the UC Recurring module and is used to group different recurring fees together.

    This means you still have separate recurring fees objects, but we can easily know which one to "trigger" based on their current term (i.e. only the first one would trigger a payment with the total of itself and all the others that have the same term attached to them.) That way, also, it gives users a chance to very easily cancel an order and have everything go back to what you'd expect: i.e. only all the other payments get the recurring fee, not the one that was canceled.

  2. Add support for a pro-rata payment... we know that the first order would generate a charge of $X for 1 month (assuming the recurring fee is once a month...) So the 1st month was already paid in full. The next step is the charge of the recurring fee. The next one may happen in 2 weeks only, so that recurring fee should include all the other orders + 15 days of the new order... that means the customer is charged "early" on that newest order, but only for the missing days and not for an entire month.

The pro-rata support could come in later. At first, we could ignore any fee that has been already been paid in the last month and lose a little money every now and then. But the result would be good enough.

So... feel free to ask questions if this is not clear enough and let me know whether you'd accept such a feature in your module. Otherwise, I'd have to create a new module from your code... kind of a waste, I think. 8-)

Another thing I could then add to this module is a way to adjust the date for the 1st and following payments. I would prefer to have all my payments go through on the 1st of the month. But that can be a separate issue too.

Thank you.
Alexis Wilke

CommentFileSizeAuthor
RecurringFeeEnhancements.png52.04 KBAlexisWilke

Comments

univate’s picture

univate commented

Its hard to give a definitely yes without seeing how this would be implemented or what you would be changing in uc_recurring. If it could be done cleanly (so uc_recurring code does not become unmaintainable) and not effect any existing functionality I would be willing to consider it.

I would be curious though to see if you could implement this feature as a new module (which I would be willing to add to the uc_recurring project) that uses the current uc_recurring hooks - I think you should be able to hook into any part of the recurring process to make this happen, although if you did need another hook we could add that simply enough.

AlexisWilke’s picture

AlexisWilke commented

That sounds good. I had a quick look and the renewal fee cannot be legally canceled, which is what I would need to avoid the 2nd order recurring fee to be processed.

  // Give other modules a chance to modify the new order before processing
  foreach (module_implements('recurring_renewal_pending') as $module) {
    $func = $module .'_recurring_renewal_pending';
    if ($func($new_order, $fee) === FALSE) {
      // renewal was canceled by the module
      return FALSE;
    }
  }

As far as I can tell, the addition of a taxonomy would otherwise be transparent to your module (i.e. through the hook_form_alter() that the Core provides.)

So, I'll get on it that way and I'll keep you abreast of what changes I need so it works with your module.

Thank you.
Alexis

maedi’s picture

maedi commented

+1 for this functionality. subscribing

maedi’s picture

maedi commented

Hi Alex, did you have any luck with this feature? I wouldn't mind chipping in.

AlexisWilke’s picture

AlexisWilke commented

Maedi,

Soon... I did not start yet. I have to get a site on the air, then I'll do this and a few other things I wanted to do.

Thank you.
Alexis

puravida’s picture

puravida commented

+1 subscribing

Even though this thread hasn't been updated in many months, it may be a solution for one of our slated tasks too, unless we find a better way to meet our needs.

Basically, we have an ALL PRO package that contains several individual PRO features.

It is very common that a user upgrades to a single or couple of PRO features and then later decides to upgrade to ALL PRO. When that happens, it is a bit of a headache for us, because we must:

1. Cancel the existing recurring items
2. Have the user purchase the ALL PRO upgrade
3. Issue a pro-rated refund for the difference (between then and renewal)

It sounds like this could automate that process and we would be willing to sponsor that development. If interested, please contact us through here or via our site contact: http://www.shrinktheweb.com/contact.

Thank you,

Brandon

muschpusch’s picture

muschpusch commented

I need that feature too and had some look at the code and UI. A proposal and questions:

1.) setting a recurring invoice setting: A select box about how often should services being invoiced. I wouldn't use a taxonomy term that's a detail. At what level should we set the configuration: at order level / user level or a general uc_recurring setting configuration? What's best?

2.) ok when to know where to save the setting we would need to adjust "uc_recurring_renew($fee)" that if the configuration var is set it consolidates the orders into one.

3.) What did i missed ? :)

puravida’s picture

puravida commented

I've communicated with a coupe of users, including Alexis, on this but have not heard back yet --probably due to the holidays. Hopefully someone will be able to push this feature forward at a reasonable price.

-Brandon

Shadlington’s picture

Shadlington commented

I'm very interested in this.

+1

mattcasey’s picture

mattcasey commented

subscribing

puravida’s picture

puravida commented

Quick update: I never did hear back from anyone on advancing this topic.

However, ShrinkTheWeb will not be sponsoring this update now, because we are being forced to migrate away from Ubercart.
http://drupal.org/node/911664#comment-4413294