[In-Commerce] Product price change in Catalog breaks down all associated Reoccurring Orders

[Alexander Obuhovich]

In-Portal has own implementation of reoccurring orders, that doesn't use one (if any), provided by payment gateway.

Each order in In-Commerce has 2 extra fields, located on "Billing" tab on order editing page, that allow to do that:

• "Recurring Billing" - checkbox, that determines if next charge should happen automatically
  
• "Next Charge Date" - date, when next change should happen if "Recurring Billing" is checked

Then cron looks for Processed/Archived orders with both fields set (and next change date in past) and does following to them:

1. clones them (order with same contents, but "-001" sub-number and in Incomplete status is created)
2. updates prices in order to match current product prices in catalog
3. approves order, which triggers charging
4. removes "Recurring Billing" checkbox from order that was cloned
5. sets "Recurring Billing" checkbox and "Next Charge Date" checkbox to newly created order

This all might seem right, but problem lies in 2nd step where prices in cloned order are updated from catalog. I personally think, that if customer brought a product for $10, then he should be automatically charged next time (by cron) for same $10 no matter if greedy website administrator set that product price to $15 in catalog.

Looks like 1 part of In-Commerce was thinking this way and prevented these unfair order from ever being charged and kept them in Incomplete status.

In attached patch I've removed 2nd step, so user will only be charged for same amount what he originally paid.

Task: http://tracker.in-portal.org/view.php?id=1447

Ready for testing.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com