-
Type:
Bug Report
-
Status: Resolved
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 5.1.0
-
Fix Version/s: 5.2.1-B2
-
Component/s: General
-
Labels:None
-
External issue URL:
-
Change Log Group:Fixed
-
Change Log Message:Prices in recurring orders were recalculated resulting for example in discount loss.
-
Story Points:1
-
External issue ID:1447
-
Copy Issue Key:
-
Patch Instructions:
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:
clones them (order with same contents, but "-001" sub-number and in Incomplete status is created)
updates prices in order to match current product prices in catalog
approves order, which triggers charging
removes "Recurring Billing" checkbox from order that was cloned
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.
- mentioned in
-
Wiki Page Loading...