Happy Business Starts Here

Highlighted
Partner

RatePlan Report and API Query give different number of results

Hello,

 

I need to access the list of all rateplans from a customer to match the associated subscription for rateplanacharges. I ran into trouble since some rate plans are not exported by the API, where ich use the rest api with query action. a simple `Select Id, SubscriptionId from RatePlan`. I get about 46300 rate plans back. When I export the list of rateplans using data source I get about 47400. And I seem to exactly need the missing ones which point to rate plans of active subscriptions but not for the lastest segment.

 

Is there an explanation? The only thing I could find is related to deleted items, but the subscription of the missing rateplans is active, so I doubt that these can be deleted.

 

Any help is highly appreciated! Thanks

7 REPLIES 7
Support SME

Re: RatePlan Report and API Query give different number of results

Hi @jhprinz could you send me your tenant ID in a private message, along with a few example IDs that are missing from the query results?

Thanks!



If you found my answer helpful, please give me a kudo ↑
Help others find answers faster by accepting my post as a solution √

Partner

Re: RatePlan Report and API Query give different number of results

How do I send you a PM ? Sorry, first post...

Partner

Re: RatePlan Report and API Query give different number of results

To add some more details:

 

I need to know all currently active charge segments and for some reason using all RatePlans, all Subscriptions and all RatePlanCharges only gives me the last segment or at least only one segment per subscription. 

Support SME

Re: RatePlan Report and API Query give different number of results

Thanks for the details @jhprinz I have replicated a similar scenario on my own environment and am investigating the details.



If you found my answer helpful, please give me a kudo ↑
Help others find answers faster by accepting my post as a solution √

Partner

Re: RatePlan Report and API Query give different number of results

Good, (or not), so I am not crazy. This is also related to the ZuoraSync for Salesforce where the data is also missing in SF. Goal was to add the missing charge segments. I think I found a workaround by using the rest subscription GET route and retrieving all charges. This circumvents using charges, but the additional overhead in complexity is huge...

Support SME

Re: RatePlan Report and API Query give different number of results

@jhprinz 

Basically the "missing" RatePlanIds in the exports are for charges that have been already removed. In the following example, I have removed C-00013401 from the 1st version of the subscription, but as you can see consecutive subscription versions still continue to have it:

 

dse.jpg

 

Since every charge needs a "parent" rateplanid, these ids will pop up in Exports - but are hidden from queries. I have discussed this with our internal teams and this is expected operation.

 

If you'd like to have the same result set for your exports, you could exclude these rows by adding "and amendment.type != 'RemoveProduct'" to your export query. These should not relate to any segments in use, as explained by this article too:

 

https://community.zuora.com/t5/Billing-Payments/How-to-find-all-latest-charges-of-active-subscriptio...

 

Let me know if this helps finding what you're looking for.



If you found my answer helpful, please give me a kudo ↑
Help others find answers faster by accepting my post as a solution √

Partner

Re: RatePlan Report and API Query give different number of results

Please excuse the late reply. I think I understand the reason, but that was actually what needed to get things working. I found a way to access all currently active charges using the ReST api call and query all charges by account. This increases the load, but I get all information I need to completely trace the time evolution of the currently latest version of the subscriptions, even if charges are long past due or will become active in the future.

 

Thanks for your help. I consider this issue solved.