Is there any way to make the following happen
| Project: | UC Recurring Fees |
| Version: | 6.x-2.x-dev |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | normal |
| Assigned: | yurtboy |
| Status: | needs work |
1. Repeat a full order not just products in an order
2. Carry over the shipping which is a total of all the products which was created during the checkout (all products in this case have the recurring feature, weight, size etc.)
3. Have a checkbox in the form or with each product where the customer can on/off Make Recurring. Since uc_recurring is a feature of a product then you really need TWO Products if you want to give the user a chance to make it recurring or not?
For example they want a bag of coffee ONCE but the product has this feature on so it become recurring. Therefore the store admin needs to make two products ONE with this as true and one with it as false.
In this case it is just for coffee sales. All coffee products are in bags, with weights etc. So when and order / cart is done and the user checkouts the auto-shipping quote happens etc. But at this point uc_recurring seems to
a. treat each product with the recurring feature as a separate item to recur
b. not carry over the sku unless I tie it to a sku in the item setup which means EACH item would need to become say 3 items (Ground, Whole, Fine) and a 4th item would be the normal uc way of doing it with attributes and the feature set to false for recurring which would be a bummer since uc has the great attribute feature where each attribute can have a sku.
For example if coffee x is recurring with an attribute of whole, ground, fine each with it's on attribute sku and set to recurring then there is no default sku to set the recurring option to and then the recurring order for the next one is blank for sku? So the admin would have to make one product for each option and set the recurring to that sku. I am sure I can make this happen with a hook if the other stuff if possible.
c. and shipping is not carried over in the order.
Maybe uc_recurring is not even the right module? I've read quite a bit and thing it could work though since it does create new orders which is key etc.
Thanks
#1
Its difficult to create an order with multiple products having potentially different recurring schedules. Members may also want to cancel one recurring fee and not the other in that order.
At the moment its simpler to just split these up into different recurring fees and charge them on their own schedule.
You can use attributes with recurring fees. I have just launched a site that used attributes to provide monthly and yearly billing options for the one subscription product.
As for shipping, the whole idea of generating a new order at renewal is so that things like shipping can get added (although I haven't tested this myself).
If I understand you correctly what you are after though is not recurring fees on products, but a recurring order. So someone orders 6 bags of various coffee's and then you want them to have the option to make that an monthly order. What you want is to have the recurring options (monthly/6monthly) at the checkout and not when you are adding products to the order.
This should be possible to do with uc_recurring's API's, but you will need to build a module to create the user interface and possibly hook into the uc_recurring hooks at renewal to ensure the order is rebuilt correctly. There is a serialized array field 'data' in the uc_recurring_user table which other modules/gateways can use to add their own data that needs to be tracked.
#2
that is what I was thinking. Should I call it something else like uc_recurring_order or try and make it an add on to your module?
Thanks for the feedback.
#3
I'm thinking this should probably be its own module although we can include the module as part of the uc_recurring project inside the modules directory we already have to keep all the recurring stuff together.
uc_recurring_order seems like a good name to me.
#4
So it seems if I can alter two areas of your code via a hook I can continue to fully benefit from the uc_recurring module over all
1. create ONE total for the uc_recurring_users table from the order total. This would include shipping and all the rest.
2. then when uc_recurring is going to make a new order hook that to fill in the details that made the sum in #1. ie make a new order with the product(s) and shipping total in ONE order.
Seems simple enough. This way uc_recurring is still using the same tables and process to bill while my hooks basically substitue the ONE order to MANY recurring orders for ONE order to ONE recurring order. This still means I have to have the client mark ALL products as Recurring but this is fine because they might in a future date have some products that are not recurring like a t-shirt etc. And that will be another issue then.
Any thoughts?
Thanks
#5
I don't think you want to actually add the recurring product feature to each product.
I think you just want to alter either the 'cart' or 'cart/checkout' page to have an option appear somewhere to allow the user to select to make the order a recurring order. Then using hook_order you would create the recurring fee object and do what uc_recurring_process_order() is doing except instead of setting up recurring fees for each product in the order your function would just creates one $fee for the entire order.
As an extra feature, inside $fee->data you may want to save a list of the products and then on the hook_recurring_renewal_pending you can alter the order so that it regenerates all the products as items in the order - that will then allow it to continue working with any stock management you might have setup. But as an initial version you could just set the $fee->title to be something generic like "Renewal of order 123" and it should still work.
Actually the more I think about this the easier this sounds, the hardest part is probably adding that extra option to the cart or checkout pages.
#6
funny "the hardest part is probably adding that extra option to the cart or checkout pages" this particular situation the client does not want this option. All orders are recurring because that is the key to this site as they resell coffee donated from a good coffee roaster to raise money.
This site then becomes a generic template for these non-profits to theme out and sell their version of the coffee.
Maybe I should just pay you to do it? I am going to work a bit on it today but would be open to a quote.
#7
I too am trying to build a site to sell coffee with the same requirements of adding in the shipping cost and displaying skus on renewal orders, as well as allowing multiple items to be 'recurring'. Currently if I submit an order for 10 bags of coffee the renewal order only charges for one bag without the shipping cost and does not display the sku.
I would be willing to contribute to a bounty for this feature, I would need it to be compatible with single orders on the same site though...
#8
Attached is a patch for a new module that creates recurring orders. That is it creates a new order with all the items from the original order.
This module is not ready to be committed as if enabled it will automatically make all orders recurring on a monthly interval until cancelled- it needs some settings to allow this to be configurable.