Allow Initial and Recurring price to be altered when Recurring orders are created

No need to do this, you can just use a different price field on the "commerce_recurring_generate_recurring_product" action.

I will add a shortcut to do this, but rules currently allows you to do this via rule sets.

Hmm... I don't quite follow.

I have a site that allows a custom donation amount to be entered. That works for single payments, and the first payment of a recurring product, but then each recurring payment is $0.

I think you're describing what I want, but don't know how to implement it...

bjlewis2 I am having the same issue with payments recurring at $0. Did you manage to sort this out?

No. I'm not currently allowing recurring payments since I couldn't get this figured out. Kind of a pain, but I'm limited to what I know how to do...

I might not be understanding the issue, feel free to drop me an email with the use case, but I'd say it's the other way around, you set the desired recurring price in your product (Recurring price field) and 0 as the Initial price you'd get a initial payment of 0 and then subscriptions at the given price in the product.

@pcambra to make sure I'm understanding what you are describing:

I should create a custom price field on my recurring entity.

I should then clone or alter the "commerce_recurring_set_price" rule to set the price for my custom field alongside the other price fields you have in place.

I should clone or alter the "commerce_recurring_override_price" rule, and set it to use my new field.

Unfortunately, I don't think editing rules is a simple solution for our use case. We are using a tool we built to integrate with commerce_recurring called redhen_donation, which provide a single-page donation form. The donation value is variable for each recurring entity. That means our product's price is completely ignored: trying to use the product to figure out what price to use when the donation recurs is not particularly helpful. The product is just a placeholder: the price is self-selected by the customer.

My problem is that the override_price rule doesn't give me access to my recurring entity. You do this in code with a fancy commerce_product_is_recurring() function, followed by loading the recurring entity based on $line_item->data['recurring_entity']. I can't do that in rules. Instead, I end up writing a custom action that has to repeat all that logic you are already using in "commerce_recurring_rules_set_price". It's seems more sensible to let me hook in there and customize the values, unless you want to provide some rules checks and values to give us deeper access to the recurring entity when looking at a line item.

If I add my own field, it also becomes a strange UI experience for admins, seeing an unused "fixed price" field and then some other, "recurring amount" field on the entity. You have a field there, what's wrong with using it?

For reference, this is the code we are using that implements the hook in this patch:

/**
 * Implements hook_commerce_recurring_recurring_price_alter().
 *
 * see: https://drupal.org/node/2263371
 */
function redhen_donation_commerce_recurring_recurring_price_alter(&$recurring_price, $line_item, $recurring_entity) {
  $recurring_wrapper = entity_metadata_wrapper('commerce_recurring', $recurring_entity);
  $recurring_price['amount'] = $recurring_wrapper->commerce_recurring_fixed_price->amount->value();
}

I'm also having problems with this.

The user can select the donation amount they'd like when they add the product to their cart, so the amount isn't on the product at all, it's on the line item for that product within the order.

I have a rule that's correctly setting the fixed price in the recurring entity with that value, but that price isn't used ever again.

What's needed is the recurring entity to be available within the Calculate sell price reaction so that the line item can be updated with the fixed price from the recurring entity.

Same need.

Anonymous user select the amount to donate for a recurring donation.
I have created a recurring product with fake or dummy initial and recurring prices (the real price is on the line item selected by the user at the moment of adding the product to the cart).

Initial order is created with that custom amount, however the recurring entity is referencing the recurring product and is using the product's recurring amount to build the subsequent recurring orders.

Which is the rule I need to touch to set the line item amount instead the recurring product price?

Thanks.

@KarlShea & @ @akanelson: both of you can apply the patch @bleedev posted to commerce_recurring, and then implement the hook as per my example in #8 to make this happen. It is not currently possible with the recurring framework & rules, as far as I know.

Hi @gcb,

I am using the standard recurring entity fixed price.

Let me explain again.
I have a recurring product. The product price is not important. it's a placeholder.
The user selects a custom amount and I'm updating the line-item price with the custom one.
So the product's price is not in use.
The order is created just fine, the order amount is the same than the line-item price.

When recurring due date takes place, new order is created but instead using the recurring entity fixed price fields it is using the original product's recurring price.

What I need is that all new recurring orders created have all the same recurring entity fixed price.

I was playing with the core rules created by the installed modules but non of them seems to change the recurring order amount.

I'm sure this should be done with rules.
I'm not seeing something.

Does it make sense?

Thanks.

Please read the whole thread. I have the exact same problem. I cannot solve with Rules. @pcambra's instructions are not feasible. You need to use the patch by Bleedev and implement the hook it enables. My earlier comment shows an implementation of that hook. I understand your issue, because I have implemented this behavior on many sites using the Redhen Donation module.

OK, thanks.
I read the full thread and also other 500.
I spent 2 full days trying to make this work.
I just applied the patch, no visible changes so far.

I'm seeing the rule "Override price for recurring" -> action: "Replace listing price by the initial price for recurring".
I see I can easily change the "Price used for listings", "Price used for initial recurring" and "Price used for consequent recurrings".

So I changed
commerce-line-item:commerce_product:commerce-recurring-ini-price
With
commerce-line-item:commerce-unit-price
And also
commerce-line-item:commerce-total

But none of them seems to produce any difference.
When the new recurring order is created, it is set with the recurring product prices.

Once more, I'm not using a custom field here, I'm just manipulating with rules the initial line item when the first order is created and then I need the subsequent recurring orders be created with the same original recurring entity fixed field. No custom fields are in use.

I'll try your hook anyway to see what happens.

Thanks again and sorry for the insistence.

Ok. To clarify: you cannot do this with Rules. You need to write PHP code, or find someone who can.

I am not a maintainer of this module, just a regular user of it who has to use patches and custom code to get the desired behavior. Rules will not be adequate. Apply this patch, then add custom code to your project implementing the hook.

I'm lying, the only custom field I'm really using is a donation amount I created at the line-item type to store the amount entered by the user.

Then, there is a rule that sets the product price using that field.

OK, I implemented your suggested hook.
No changes.

Take a look at the attachments:
1. Orders showing #30 as the original order. Then #31, #32, etc are recurring orders created when cron runs. They should be of $2,500 as the initial one but they are of $40 like the product recurring price.
2. Recurring Entity details showing that the recurring entity is properly set with $2,500 as the fixed price. All recurring orders created are coming from that information.

Hope it helps to clarify.

Thanks again.

I ended up just writing a condition/action that did what I needed and ended up not needing the patch.

@KarlShea can you explain how did you write that rule ? Thanks

I basically just reimplemented the existing condition/action, except I changed the callback for setting the price so I could do what I needed. The only interesting function here is your_module_recurring_rules_set_price(), which is similar to what #8 is doing.

You'd have to change the code in that callback to check the fields you want to check, but whatever gets set in there is what ends up getting charged.

Then the "Calculating the sell price of a product" rule gets set up like normal, just choose your custom condition/action and pass in the line item.

In a custom module this should be in your_module.rules.inc:

/**
 * @file
 * Additional recurring rules
 */

/**
 * Implements hook_rules_condition_info().
 */
function your_module_recurring_rules_condition_info() {
  $conditions = array();

  $conditions['your_module_recurring_line_item_has_recurring_entity'] = array(
    'label' => t('Line Item has Recurring entity'),
    'parameter' => array(
      'commerce_line_item' => array(
        'type' => 'commerce_line_item',
        'label' => t('Line Item'),
      ),
    ),
    'group' => t('Commerce recurring'),
    'callbacks' => array(
      'execute' => 'your_module_recurring_rules_line_item_has_recurring_entity',
    ),
  );

  return $conditions;
}

/**
 * Implements hook_rules_action_info().
 */
function your_module_recurring_rules_action_info() {
  $actions = array();

  $actions['your_module_recurring_set_price'] = array(
    'label' => t('Replace line item price by the recurring fixed price in the line item data.'),
    'parameter' => array(
      'commerce_line_item' => array(
        'type' => 'commerce_line_item',
        'label' => t('Line item'),
      ),
      'component_name' => array(
        'type' => 'text',
        'label' => t('Price component type'),
        'description' => t('Price components track changes to prices made during the price calculation process, and they are carried over from the unit price to the total price of a line item. When an order total is calculated, it combines all the components of every line item on the order. When the unit price is altered by this action, the selected type of price component will be added to its data array and reflected in the order total display when it is formatted with components showing. Defaults to base price, which displays as the order Subtotal.'),
        'options list' => 'commerce_line_item_price_component_options_list',
        'default value' => 'base_price',
      ),
      'round_mode' => array(
        'type' => 'integer',
        'label' => t('Price rounding mode'),
        'description' => t('Round the resulting price amount after performing this operation.'),
        'options list' => 'commerce_round_mode_options_list',
        'default value' => COMMERCE_ROUND_HALF_UP,
      ),
    ),
    'group' => t('Commerce recurring'),
    'callbacks' => array(
      'execute' => 'your_module_recurring_rules_set_price',
    ),
  );

  return $actions;
}

/**
 * Condition to check if a line item has a recurring entity
 *
 * @param $line_item
 * @return bool
 */
function your_module_recurring_rules_line_item_has_recurring_entity($line_item) {
  return !empty($line_item->data['recurring_entity']);
}

/**
 * Set the line item price to the fixed price in the line item's recurring entity
 *
 * @param $line_item
 */
function your_module_recurring_rules_set_price($line_item, $component_name, $round_mode) {
  $recurring_entity = entity_load_single('commerce_recurring', $line_item->data['recurring_entity']);
  $recurring_wrapper = entity_metadata_wrapper('commerce_recurring', $recurring_entity);
  $fixed_price = commerce_price_wrapper_value($recurring_wrapper, 'commerce_recurring_fixed_price', TRUE);

  commerce_line_item_unit_price_amount($line_item, $fixed_price['amount'], $component_name, $round_mode);
}

@bleedev thanks for the patch and @gcb thanks for the hook example! I was struggling to get this to work until I realized that I didn't have the "Override price for recurring" rule enabled, it isn't explicitly mentioned in the workflow above. So for anybody else confused or coming to this case for the first time, here are the steps that should be followed:

1. Apply the patch provided in comment #1
2. Implement the alter hook as illustrated in comment #8
3. Enable the "Override price for recurring" rule if not already enabled
4. Test by changing the "Fixed price" field value on a recurring entity, set the "Due date" in the past and then run the "commerce_recurring_cron" job. A new order should be created with the "Fixed price" you defined as the total.

I can verify that following the steps in post #20 work. Was able to roll back the time on the order and fire it again with cron. Payment processed via Stripe perfectly with Card On File module.

Patch in #1 committed. I believe that patch was the best course of action here as it allows for more flexibility with development. If anyone disagrees and would prefer another solution please feel free to comment and I will review this again.

Thanks @deggertsen! Nice to see maintainers in the queue. Crossing my fingers this means a release is in the works.

@gcb I'm not sure if we will ever get a "stable" release for 7.x without a lot more help. I'm willing to go through the issue queue to review and commit patches, but I'm not prepared to spend the time of actually going through to prepare a stable release. So unless someone wants to take that on it will probably just stay as a development release.

How about an alpha, just so I can put something besides a commit ID into my makefiles?

@gcb is there any chance you can help fix the tests so that they work or point me in a good direction for learning how to setup automated tests. I've never learned how the automated test system works and have avoided it for some time... That is one thing that I feel like is a blocker for posting a release.

As far as fixing the existing tests, start by enabling "simpletest" module in your local dev environment and using its menu tools (or drush) to run them! It should give you a nice output of which ones are failing, and then you get to figure out if the test is simply obsolete/buggy or if it's actually showing you something isn't working. You can also just delete any tests that are failing, although that is obviously not ideal.

My hope would be that they are all pretty obvious to fix, just haven't quite been kept up to date.

Thank you. That's very helpful. I wasn't really aware of the simpletest module before. I'll see if I can find some time to look that over.

I'm currently setting up a non-profit's website to use Drupal Commerce with Commerce Recurring Framework and Commerce Card on File in order to allow recurring monthly donations of a user-selected amount. Am I understanding correctly that the current best practice would be to follow the steps in #20 (minus step 1 since the patch is now committed on 7.x-2.x-dev)? Does the code in #8 need to go in a custom module? I have not dealt with making a custom module before so if anyone has a recommended tutorial for that please point me toward it.

Or alternatively, what about the approach outlined in #19? Which approach would you take if you are doing this from the start for the first time, #19 or #20?

@83steps, if you can get it working using #20 that's the way to go. The only real difference between what I wrote in #19 and what's in #8 is where the calculation happens.

The only part of my code (#19) that's not standard rules boilerplate is your_module_recurring_rules_set_price(), where in #8 it's using a price alter hook instead. #8's price alter hook depends on the patch, where mine is really sidestepping the need for the patch by implementing an entire rules condition/action.

Does that make sense? Now that the patch is in if I felt the need to revisit that code I'd do what #19 is doing.

See here for how to make a custom module, for this it will be very simple. You'll just need a yourmodule.info and yourmodule.module containing yourmodule_commerce_recurring_recurring_price().

@KarlShea I really appreciate you taking the time to reply. Super helpful. I got the custom module set up and on first look it seems like the code is all working together great.

Recurring entity was created correctly but now I'm roadblocked by a separate issue where the recurring entity can't be edited, which makes further testing really hard!