Action to Update Dates (or additional fields on the Update Schedule action)

[thenbrent]

This extension includes an action to change a subscription's billing period and interval. It doesn't provide a way to modify the dates that make up a subscription's schedule, like the:

• Next Payment Date
• Trial End Date
• End Date

Actions to update these dates would be very helpful for various use cases, like re-syncing payment dates after some kind of issue, like the recent gazillion scheduled webhook actions issue that would shift scheduled payment dates.

Doing so won't be as easy as adding date input fields for each of these dates. A workflow could be run at any time in the future so the input fields will need to have more flexibility.

Relative Date Input

Providing only a fixed date picker, where a specific date is chosen, will have more limited use than an input that makes it possible to change a date based on some variable value, like adding an additional month to the next payment date, or changing the date to be the 1st day of the next month.

One approach to support relative changes would be to accept any date format understood by DateTime::modify(), including strings like first day of next month, and pass those directly to a DateTime::modify() call.

This approach would be both the easiest to implement, and the most flexible for store owners.

Accepting any textual representation understood by DateTime::modify() does introduce some gotchas though and generally provides a lot of power to store owners (and we know what Voltaire & Uncle Ben say about great power). For example, PHP has the old +1 month gotcha, which could lead to accidentally setting all subscriptions to charge the next payment on the wrong date.

Subscriptions has quite strict rules for date validation, like making sure certain dates come after each other, and that Next Payment Dates are not in the past, but opening up the power of date strings to anyone will be a new test for those, and it's not something they were originally designed to guard against.

Supporting relative changes through additional UI that constrains the input would be a safer approach, but far more limited and difficult to implement.

[danielbitzer]

Suggestion: If supporting any string understood by DateTime::modify() I think it's worth instantly validating the user input via AJAX and even showing a preview date based on now.

[renansavidan]

Hi I read that is something being developed, is there a way to start to use it, even with limited features. help really appreciated about this. I code but this is a big piece and I guess i would need an hand.

[danielbitzer]

If you're interested in this feature please vote over on the ideas board: https://ideas.automatewoo.com/automatewoo/p/action-to-change-a-subscriptions-next-payment-date

[canny[bot]]

This issue has been linked to a Canny post: Action to change a subscription's next payment date :tada:

[danielbitzer]

Hey @renansavidan, apologies for not getting back to you sooner, I just saw this comment the other day.

Development has not started on this feature and it isn't currently on our short term roadmap. Feature prioritization is primarily going to depend on popularity as we see it on the ideas board.

[renansavidan]

Hi, OK no worries. I developed custom rules to make it work for me. Thanks for the update, Best regards,

[weseggs]

Hi Dan / Brent This is a great idea, we actually have an extra field called "Delivery Date". It would be great to have this new feature to be able to modify any custom fields like mine.

@renansavidan I would be interested to see how you have done this with AW?

[renansavidan]

Hi @weseggs I had to create my own process for my specific needs. The function I created is not a rule (see AutomateWoo custom rules) ; it is a custom action function I included in the workflow. It deletes next payment dates when triggered an it looks like this :

function snp_automatewoo_action_remove_next_payment( $workflow ) {
  $subscription = $workflow->data_layer()->get_subscription();
  $meta_value = 0;
  $meta_key  = '_schedule_next_payment';
  update_post_meta( $subscription->get_id(), $meta_key, $meta_value );
}

(To be honest I am not sure the code is so clean) I made tests and was happy that if you delete the next payment date this way it also automatically deleted the pending schedulled action for the payment. It worked for me. Actually I have noticed the last time it worked only for one type of subscription but that's another topic.

[leightona]

Hi Guys, Just trying to give our subscribers 3 months relief with this whole COVID-19 thing by extending their next payment date. Hoping to do it using a custom function via a manual trigger. Contacted support and they suggested coupons but doesn't look like that will work.

If you have the time would you mind taking a look at the following custom function to see where I'm going wrong?

Have put a job on Codeable but don't like my chances on such a specific and small job.

function nextpaymentdatechange( $workflow ){ $subscription = $workflow->data_layer()->get_subscription(); $meta_key = '_schedule_next_payment'; $subid = $subscription->get_id(); $nextdate = get_post_meta( $subid, '_schedule_next_payment', true ); $nextdate->modify('+3 month');

update_post_meta( $subid, $meta_key, $nextdate );

} Thanks

[danielbitzer]

Hi @leightona, I've just put together a code snippet for you. It seems like there could be quite a few stores needing to extend subscriptions right now.

https://gist.github.com/danielbitzer/23efd86fac499c52f9bef3f07e32c41a

Hope that helps!

[leightona]

Thanks Dan, really appreciate it. Your a legend!

On Thu, 2 Apr 2020 at 18:15, Daniel Bitzer notifications@github.com wrote:

Hi @leightona https://github.com/leightona, I've just put together a code snippet for you. It seems like there could be quite a few stores needing to extend subscriptions right now.

https://gist.github.com/danielbitzer/23efd86fac499c52f9bef3f07e32c41a

Hope that helps!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/woocommerce/automatewoo-subscriptions/issues/3#issuecomment-607665764, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJALSZ3FYESOU34EE3GILWTRKQ3P7ANCNFSM4GTEYZHQ .

[gbouhier]

Hi everyone,

I have some difficulties in setting up the operation I want with Automatewoo.

I propose a monthly box (single product) with different subscription options:

• Monthly payment with automatic renewal every month ($29/mo)
• Annual payment with automatic renewal every year (310$/year)
• 3-month subscription paid in one go at subscription ($82 gift card)
• 6 month subscription paid in one go at subscription ($160 gift card)
• 12-month subscription paid in one go at the time of subscription ($310 gift card)

For the first subscription option (monthly payment), I synchronised the monthly payments on the 11th, so it works correctly: when a subscription is purchased, the order immediately goes to the completed status and a new one will be created on the 11th of the next month.

For the second option (yearly payment), I followed the excellent guide on prepaid orders with Automatewoo and took inspiration from @danielbitzer 's snippet to add a custom function to set the first payment date (on the 11th of the following month). The problems are as follows:

• The first renewal is indeed pushed to the 11th of the following month but I still have an order with the status "processing" that appears and does not change to completed. This can be confusing when processing orders. I would like the order to be completed or the order not to be created at all.
• Since we are changing the price of the annual subscription from $310 to a monthly subscription of $0/mo, we can no longer have a correct estimate of the upcoming monthly/annual recurring revenue?

For the gift cards (3/6/12 months), I tried to set up the subscription as follows: $82 every 3 months, expires after 3 months, no signup fee. The problem is that with this configuration, Woocommerce Subscription estimates that the customer will need to be charged after three months, so it asks them to enter their credit card. I don't want this because it's a gift card...

So I tried to do it differently: $82 sign-up fee, $0/mo for 3 months, expires after 3 months. It works better because the user doesn't need to enter his credit card anymore, the gift card is enough. However I have read that this is not a good practice and should be avoided: use the Automatewoo guide on prepaid orders instead. Would this be feasible or could it cause problems: update schedule with Automatewoo?

I am really struggling, any help or tips to achieve this would be really grateful !

Thank you :)

[imodouglas]

HI team, any update on this?

[DIntriglia]

I would also like an update on this. It looks like there is another ticket with another potential solution: https://ideas.automatewoo.com/automatewoo/p/fill-a-date-from-variable