Cancel subscription at end of term cancels immediately

[rr...@hotmail.de]

Hello all,

I am having some problems with the cancellation of subscriptions in the java client:
Currently we have three base subscriptions, "Starter", "Standard" and "Power", each with some addons.
Now when the user wants to change his base subscription (which is done by cancelling the old and creating a new subscription), the old subscription should stay active until the billcycleday, because the addons basically only are usages and the usage still has to be booked. However, as it seems, the subscription is cancelled immediately.

The cancelPolicy in the catalog is set to END_OF_TERM.
I tried with EntitlementActionPolicy and BillingActionPolicy, but the cancelledDate is set to the date of the last term when I use END_OF_TERM (As example, let´s say the last term was 2017-08-15 to 2017-09-15. If I cancel it today - 2017-09-25, it should run until 10-15, but the cancelled date is 09-15.)
When I use IMMEDIATE, it is set to the current date (of Kill Bill).
(The same things are happening in the KAUI)
I also tried requestedDate, but this didn´t seem to change anything.


What exactly does the "requestedDate" on cancelSubscription do?
What should I try or do to get the behavior I mentioned?


I´m pretty new to Kill Bill, so I probably misunderstood something and forgot some details. (I already had some trouble, as example with creating subscriptions for addons, because you have to specify the product category - isn´t this in the catalog already?)

Regards, Richard

[Pierre-Alexandre Meyer]

On Mon, Sep 25, 2017 at 1:05 PM, <rr...@hotmail.de> wrote:

Now when the user wants to change his base subscription (which is done by cancelling the old and creating a new subscription)

Out of curiosity, why do you cancel the subscription instead of triggering a change plan?

 

I tried with EntitlementActionPolicy and BillingActionPolicy, but the cancelledDate is set to the date of the last term when I use END_OF_TERM (As example, let´s say the last term was 2017-08-15 to 2017-09-15. If I cancel it today - 2017-09-25, it should run until 10-15, but the cancelled date is 09-15.)

Are you billing in advance or in arrear?

 

What exactly does the "requestedDate" on cancelSubscription do?

This is the date at which the entitlement should be canceled:

https://github.com/killbill/killbill/blob/2e8156f27ee9368b1d7b815a440af5829f9000aa/jaxrs/src/main/java/org/killbill/billing/jaxrs/resources/SubscriptionResource.java#L652

It sounds like you want to use a policy instead (END_OF_TERM, for both entitlement and subscription). Here is an example:

https://github.com/killbill/killbill/blob/2e8156f27ee9368b1d7b815a440af5829f9000aa/profiles/killbill/src/test/java/org/killbill/billing/jaxrs/TestEntitlement.java#L154-L155

Can you verify the server logs and make sure the policy is taken into account?

--

Pierre

[rr...@hotmail.de]

> Out of curiosity, why do you cancel the subscription instead of triggering a change plan?

The prices for the addons differ, depending on the base subscription, so a user with the base subscription "Starter" has to pay more for every usage than a user with "Power". I´m not sure whether this is possible by just changing the base subscription? (Currently there are three plans for every addon. And would it be possible to get the plan or product for the next term, when changing the subscription?)

> Are you billing in advance or in arrear?

In arrear, both the recurring prices for the base subscriptions and the usage prices for the addons.

Well, after looking into the SubscriptionResource.java and testing again today, it seems as if the problem I had with the requested date only appears when calling cancelSubscription with given policies. Calling cancelSubscription with requested date and null for the policies uses the requested date. Is this what it should do? If yes - why is there no cancelSubscription only with requested date?

(I think my problem is solved by using requested date and null-policies. Thank you very much already!)


Richard

[Pierre-Alexandre Meyer]

On Tue, Sep 26, 2017 at 8:11 AM, <rr...@hotmail.de> wrote:

The prices for the addons differ, depending on the base subscription, so a user with the base subscription "Starter" has to pay more for every usage than a user with "Power". I´m not sure whether this is possible by just changing the base subscription? (Currently there are three plans for every addon. And would it be possible to get the plan or product for the next term, when changing the subscription?)

You would need to trigger a change plan for the add-ons as well.

> Are you billing in advance or in arrear?
In arrear, both the recurring prices for the base subscriptions and the usage prices for the addons.

Note that when billing in arrear, the charged through date will be in the past, while it is in the future for subscriptions paid in advance. This will affect how policies compute the cancellation date:

  https://github.com/killbill/killbill/blob/2e8156f27ee9368b1d7b815a440af5829f9000aa/entitlement/src/main/java/org/killbill/billing/entitlement/api/DefaultEntitlement.java#L520-L539

Well, after looking into the SubscriptionResource.java and testing again today, it seems as if the problem I had with the requested date only appears when calling cancelSubscription with given policies. Calling cancelSubscription with requested date and null for the policies uses the requested date. Is this what it should do? If yes - why is there no cancelSubscription only with requested date?

No specific reason, it would be trivial to add it (it's just syntactic sugar on the client side):

  https://github.com/killbill/killbill-client-java/blob/87eec8319c17f2794f09796fa7357950a831f776/src/main/java/org/killbill/billing/client/KillBillClient.java#L885 

--

Pierre

[lucas...@iquall.net]

Hi. I'm a very facing a similar problem.

I'm currently not using add-ons and I'm using in-advance billing. The only cancelPolicy that I have in my catalog is a default one, which is END_OF_TERM.

When I delete a subscription specifying no policy(using the API), it gets deleted immediately.

I get that Richard found a solution, but don't fully understand it. Should I explicitly specify the policy (END_OF_TERM) via the API in the "DELETE /subscription/{id}"? Or is there any way to use the default policy? I'm surely missing some config.

Thanks!

[stephane brossier]

Lucas,

Could you provide 1. a snippet of your catalog -- just the Plan/Product you are using-- 2. The details of the call you are making -- arguments, .. 3. The rows from the 'subscription_events' associated with your subscription -- ideally in a format that is easy to read.

Stéphane

--
You received this message because you are subscribed to the Google Groups "Kill Bill users mailing-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to killbilling-users+unsubscribe@googlegroups.com.
To post to this group, send email to killbilling-users@googlegroups.com.
Visit this group at https://groups.google.com/group/killbilling-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/killbilling-users/fbad29ef-fd03-46ab-aabe-247699da3f35%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Lucas Hamie]

Hi Stephane,

1)

<catalog xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="CatalogSchema.xsd">
    <effectiveDate>2018-01-03T00:00:00Z</effectiveDate>
    <catalogName>test</catalogName>
    <recurringBillingMode>IN_ADVANCE</recurringBillingMode>

        <product name="test-product">

            <category>BASE</category>

            <included/>

            <available/>

            <limits/>

        </product>

<plan name="test-product-Monthly">

<product>test-product</product>

<initialPhases/>

<finalPhase type="EVERGREEN">

<duration>

<unit>UNLIMITED</unit>

<number>-1</number>

</duration>

<recurring>

<billingPeriod>MONTHLY</billingPeriod>

<recurringPrice>

<price>

<currency>USD</currency>

<value>90.00</value>

</price>

</recurringPrice>

</recurring>

<usages/>

</finalPhase>

<plansAllowedInBundle>-1</plansAllowedInBundle>

</plan>

2) When calling the API I'm just calling DELETE on /1.0/kb/subscriptions/{id} with no special parameters

3) I'm attaching the JSON response from calling GET on /1.0/kb/bundles/{bundleId}

 

Let me know if there's anything else I should add.

[stephane brossier]

How is the cancelPolicy rule section of your catalog defined?

[Lucas Hamie]

   <rules>
        <changePolicy>
            <changePolicyCase>
                <policy>END_OF_TERM</policy>
            </changePolicyCase>
        </changePolicy>
        <changeAlignment>
            <changeAlignmentCase>
                <alignment>START_OF_BUNDLE</alignment>
            </changeAlignmentCase>
        </changeAlignment>
        <cancelPolicy>
            <cancelPolicyCase>
                <policy>END_OF_TERM</policy>
            </cancelPolicyCase>
        </cancelPolicy>
        <createAlignment>
            <createAlignmentCase>
                <alignment>START_OF_BUNDLE</alignment>
            </createAlignmentCase>
        </createAlignment>
        <billingAlignment>
            <billingAlignmentCase>
                <alignment>ACCOUNT</alignment>
            </billingAlignmentCase>
        </billingAlignment>
        <priceList>
            <priceListCase>
                <toPriceList>DEFAULT</toPriceList>
            </priceListCase>
        </priceList>
    </rules>

    Lucas G. Hamie
    Av. Honorio Pueyrredón 1475
    C.A.B.A. República Argentina
    TEL+54.11.4855.6041 (Ext. 526)
    lucas...@iquall.net
    www.iquall.net

[stephane brossier]

I created issue #861 for investigation -- by just reading the code, it seems like logic is correct. Could you send me the exact command you are using for your cancellation?