Subscriptions Ideas

TrixabelleCP

Suggestion: Allow renewal prices that have been auto increased to be rounded to 2 decimal places. More info: When " Default Price Change for Product Charges" is set to "percentage increase", renewal prices can end up with more than 2 decimal places which can cause a discrepancy between the calculated totals and the display values, and in our experience this causes confusion for customers and delays in the approval process. For example: Default price change = 5% Monthly price: $23 Next renewal price = 105% x $23 = $24.15 (this is ok as still only 2 decimal places) Next renewal price = 105% x $24.15 = $25.3575 (becoming problematic as the price used is now 4 decimal places) However I don't want to display $25.3575 on quotes, so it's rounded to $25.36. And now the price that is used in calculations doesn't match the price displayed and assuming you show quantity x period x unit cost on a quote PDF you can end up with discrepancies. Eg. Actual calculation: 10 users x 12 months x $25.3575 = $3042.90 Displayed values: 10 users x 12 months x $25.36 (= $3043.20 if using the displayed values; but $3042.90 if displaying the value Zuora is using) For a large deals these differences can be significant and we've has customers refuse to sign purchase orders because of it. My suggestion is to allow the price uplift to be rounded to a set number of decimal places (that matches real-world currencies) and use this number in calculations. I can't think of any scenarios where people want to be charging customers prices like $34.3433533.

Terue · ‎10-05-2020

For Japanese users, “Subscription start day” callout is always triggered on next day. Ex. if the service start date is Oct 1, the callout is triggered on Oct 2 in JST*. (*) AM 9:45 Oct 1 (Los Angels) = AM 0:45 Oct 2 (Tokyo) This is because Zuora callout based on the system date as it is described in KC. This is critical issue for our customers that their end-users cannot start using their service on time. The trigger timing for the events such as “Subscription Start Date” , “Term Start Date ” should be consider the business timezone.

Menelion · ‎10-20-2020

Hello, Currently the status for canceled subscription is *cancelled* (with a double L). Whether it is British spelling or a typo, it should be consistent with other statuses (like, for instance, the corresponding status for invoices is *Canceled*). this might lead to confusion and hard-to-catch bugs in API implementations. As there are quite a number of current implementations already, I would suggest to support both *canceled* and *cancelled* for some time, before a breaking change could be possible. Thanks.

perswardh · ‎06-12-2018

Currently there are no support for changing trigger dates (Contract Effective Date, Service Activation Date, Customer Acceptance Date) using the orders functionality. It is possible using amendments but not orders. This is needed when unintentiallly setting the wrong trigger dates when creating subscriptions using orders. See https://knowledgecenter.zuora.com/BC_Subscription_Management/Orders/C_Known_Limitations_in_Orders "Trigger Dates: Once rate plan charge trigger dates are set, you cannot directly update or override the trigger dates."

linus · ‎02-08-2019

Using orders in Zuora Currently Zuora only supports that a suspended subscription can be resumed within a current term. Example: Subscriber has a subscription 3 month termed that will be renewed to evergreen after that first term. The subscriber is allowed to suspend the subscription. This will result in no invoices being created during the suspension. As now in Zuora the subscription needs to be resumed withing that first term. As suggested without this rule the date for resume could be set 5 months from now. When resumed the term would continue as agreed upon. How it is today -Customer buys 3 month termed subscription 2019-01-01 (Will be renewed to evergreen) -Customer is only allowed to suspend subscription withing term 2019-02-01 - 2019-02-28 My suggestions -Customer buys 3 month termed subscription 2019-01-01 (Will be renewed to evergreen) -Customer is allowed to suspend subscription 2019-02-01 - 2019-07-01 (5 months in this case) with action to continue the term after resume true/false (up to company to set true or false). -Customers subscription is resumed 2019-07-01 and from that date the term will continue for another 2 months before it is renwed to evergreen.

nlittlefield · ‎09-01-2017

It would be very helpful for our team to have the option to Clone an existing subscription in the user interface. Ideally it would create a new subscription for that account with all the same rate plans and products assigned to it as the original, having it prompt only for a new contract/activation date.

vpoliseno · ‎02-17-2017

We'd like to be able to have a template to mass update the following field: Additional Email Addresses Invoice Template Communication Profile to the Account Tax Exempt Certificate ID Tax Exempt Issuing Jurisdiction?

gelaimr · ‎08-10-2017

Issue: Currently, OriginalID and CancelledDate fields not returned via GET " https://rest.zuora.com/v1/subscriptions/accounts/{account-key}" The customer can use the CRUD call, but they are trying to reduce the number of round trips and complexity of getting all the subscription information. Right now if a user has several subscriptions they need to loop through and get the two additional fields of data for each subscription, if this information could just be returned with " https://rest.zuora.com/v1/subscriptions/accounts/{account-key}" it would reduce complexity. Reference: SUB-5844

jmorris7 · ‎10-24-2017

Issue: Inability to remove renewal amendments Description: If a customer accidentally renews the wrong account or renews twice we are unable to remove this renewal. This is due to the fact you can't delete an amendment after invoicing/processing a payment. This is causing us to have to cancel the subscription, apply a credit to the account and have the customer repurchase. This happens very frequently and has caused a high level of aggravation for our customers.

jpawlyn · ‎01-24-2018

We contacted support recently to ask about the status of the API /v1/catalog/product/{id} and it turns out that this is an internal API. We would like to use this API but because it is categorized as internal, hesitate to use it for production purposes. If it could be re-classified as a public API and documented that would be great. Jolyon

jbrown · ‎09-15-2016

The Billing Period Alignment options allow for "Align to Charge" and "Align to Term." However, if you want all of your recurring charges to invoice on the same schedule, no matter what the renewal term or billing term, there is no setting. We use "Align to Term" now and if customers have matching Billing Period and Renewal Term (Monthly billing and 1 month Renewal, for example), a mid-term change will generate a prorated invoice for the remainder of the month and then pick up all charges at the next billing period. This works great. But when we have a customer that has Quarterly billing period and monthly renewals for example, a mid-term change misaligns those same charges with the same settings. Since charges are configured by Billing Frequency, we only have the ability to configure our Quarterly charge with one option. So changes for this customer are manual every time.

zedmundson · ‎11-20-2017

We have customers with multiple (about 20) active subscriptions at a time. If we want to cancel a customer account with an effective date, we have to cancel one subscription at a time rather than if the "Cancel Customer Account" feature adding a new pop-up that would let you mass cancel all pending subscriptions. This could be with the same terms for cancelling subscriptions (end of term, last invoice date), but it would be done at a larger scale and saving us time.

Kenta · ‎03-15-2018

Currently, the option of 'Enable Automatic Price Change when Subscriptions are Renewed?' only works with Termed Subscription. If a Subscription is designed to be monthly Evergreen, we would have to structure it as 1 Month Term Subscription, which results in a ton of Amendments. I would like to recommend that the option also be compatible with Evergreen Subscription

bolaurent · ‎01-05-2018

We prefer to keep the subscription name the same as (or related to) the opportunity name in Salesforce. But once a subscription is activated, the name cannot be changed. Sometimes the subscription was manually entered, and the user forgot to set the name, then we get a really terrible name that is meaningless. Or sometimes there is a typo in the SFDC opp name, and it is changed sometime after the Zuora sub has been created. I wonder why Zuora is so rigid about this? Isn't the subscription ID the unique key?

bolaurent · ‎03-23-2017

let me set the order in which productrateplans are displayed (on product page and in dropdown when adding to a subscription)

bolaurent · ‎03-02-2017

I'm experimenting with ways to enter complex deals, and a very talented Zuora SA is working with me. We are entering multiple recurring charges on a rate plan, with each set to end after one billing period. It's requiring significant experimentation to arrive at the result we want. We sure wish, when we need to run the experiment again, we could clone an existing subscription in draft mode and edit the thing. An alternative would be (in sandbox) to allow me to unlock a sub even after it has been activated.

timozuid · ‎01-05-2018

It would be helpfull to get thousand separators in the Quote quantity fields. The reason for this when a customer is in CPM business the offered quantities can be millions and it's hard the work out the number of zero you have to enter.

kcoyne · ‎11-30-2017

We would like to request a different status for our one time only subscriptions once they have billed as techinically they are no longer active. This new status would enhance the team's reporting when searching for truly active subscriptions.

fredkao · ‎05-15-2018

Please make the description field on the rate plan charge editable. Thanks!

waterstorm · ‎02-20-2017

I'm using the product catalog call to return the entire catalog of products to show all available prodcuts in an application. However I'd only need the products currently active (see "Effective Start" and "Effective End"). For subscriptions there is an option in the call to filter for active subscriptions (using ?charge-detail=current-segment). I suggest implementing a similar option for the product catalog, e.g.: ?currently-active=true which should only return products where the "Effective Start" date is after and the "Effective End" date is before the current date.

Happy Business Starts Here

Vision

Products

Zuora Central Platform

Products

Zuora Marketplace

Solutions

By Industry

By Role

Customers

Resources

Resources

Subscribed

Support

Company

Subscriptions Ideas

Default Price Change for Product Charges: Percentage - round uplifted prices to set 2 decimal places

“Subscription start day” callout should be triggered on local time

Zuora statuses should adhere to one spelling norm

Support for changing trigger dates using orders

Improve suspend and resume options for subscriptions

Subscription Clone Feature

Template to mass update customer account fields

Add OriginalId and CancelledDate to REST Subscription API

Inability to Remove Renewal Amendments

Make the product catalog API official (/v1/catalog/product/{id})

Add Align to Billing Term Option

Ability to Cancel all pending subscriptions when attempting to Cancel Customer Account

Allow Evergreen to use 'Subscription Charge Price increase Following Renewal'

Allow subscription name to be changed

let me set the order in which productrateplans are displayed

Allow subscriptions to be cloned (at least in sandbox)

Having thousand separators in Quote quantity fields

New Subscription Status

Allow rate plan charge description to be editable

[REST] Add filter possibilities to product catalog call in REST API

Option to have Fixed Amount Discounts Prorate on early cancellation

Ability to add attachments to subscriptions

Ability to cancel a subscription with an Effective Date in a Closed Accounting Period