Imported variation subscriptions unable to use upgrade/downgrade to other variation's in product

[duttonw]

was migrating a website which had a standard subscription, i updated the product id's to match the new website product id's and added in the new meta-data key value pairs.

product_id:1568|name:Corporate |quantity:1|total:649.00|meta:sub-accounts=10|tax:0.00

this does not act like a variation subscription made with the front end vs this importer.

i've also tested a valid variation subscription export from the website, change the user to a new user and re-imported and the new subscription on the new user can't be upgraded/downgraded but the subscription/user it was exported from can.

i'll continue looking into this as i don't want to manually create all these subscriptions.

[mattallan]

Thanks for bringing this up @duttonw. WooCommerce Subscriptions does not allow customers to switch items unless the subscription has a last payment date. Unfortunately a last payment date doesn't exist on newly imported subscriptions that haven't renewed yet.. so we'll have to work out a way for store managers to get around this

Some ideas:

1. Generate (at the very least) an initial order for imported subscriptions by having it as an option on the front page (or even per CSV row to not slow things down too much). I'm thinking this will just create a completed order for active, pending-cancel, cancelled and expired subscriptions and then pending payment for pending and on-hold subscriptions.
2. Patch WC Subscriptions so that if the last order doesn't exist on manually created (or imported) subscriptions, use the subscription post date as a last payment date

I'm sure there's issues with implementing B) that im just not seeing yet. Any other ideas?

[thenbrent]

Generate (at the very least) an initial order for imported subscriptions by having it as an option on the front page (or even per CSV row to not slow things down too much). I'm thinking this will just create a completed order for active, pending-cancel, cancelled and expired subscriptions and then pending payment for pending and on-hold subscriptions.

The (minor) issue here is that the order needs to be for $0 to avoid throwing out report total. In which case, you have an order for $0, serving very little purpose.

I'm sure there's issues with implementing B) that im just not seeing yet.

The only issue is with proration. Should we use the subscription's current recurring total as the base for proration calculations? Or should we use $0? (because that's how much has actually been paid as far as Subscriptions/WC knows).

[duttonw]

How about, adding the most recent order to be included on the exporter which the importer can use to generate a backdated order with the correct values for that past order to when it was last renewed or started. This would not be of the current month and should have a note attached to say created by importer like the subscriptions.

?? Could this order that is created have a discount of the same amount but still allow proration as the payment or would this interfere with it?

Of course there need to be a checkbox to include order data export or import that order details.

On another note: Currently the WCS_Exporter is a static class, but i feel it would work better with it being non singleton as the function calling it is not static. We can then feed the csv headers and backing internal object location in a key/value array (like woocommerce input form arrays) this may reduce the amount of switch case that needs to happen and can allow the system to export from the subscription object and the order that is connected. This also allows header names to be changes before export (i don't think this is needed unless they are leaving the woocommerce ecosystem) (maybe using http://php.net/manual/en/function.call-user-func-array.php )

I'll try and put together a pull request for this in the coming days/week unless someone else beats me to it. ;)

[duttonw]

@thenbrent i have tested this fix/workaround and it does all calculations on proration etc. Where the subscription is not that new/in trial.

The last paid date is in the csv file but the plugin as it stands is passing this date to the update_dates function which just ensure its in the right order then drops it.

Maybe in the future it would be faster to store against the subscription the last payment date so that we don't have to do that expensive order lookup. the reason i say expensive is that once you have a VERY long running subscription in the order of years where the renewal could be set to the week. it has all of these orders which it just finds and then drops.

this more likely will need to be done with backward compatibility in mind as well as ensure we update that field when payments do go passed paid in the main plugin.

[stephano41]

Has there been an update on the work around for this problem?