Notification system

[Kiên Hà]

Currently, Killbill computes notification queues effective time for each account only at each account reference time. This does not blend very well with daily recurring charges and Killbill provides no easy way to fine grain the Notification Queue occurence time. 

For example, the INVOICE_NOTIFCATION will be completely surpressed whatever the dryRun configuration is. Daily telephone bills are exceptionally easy to forget and would warrant a notification, for example.

Some tasks would likely be able to run right before some external events. Triggering cache superfetch for important transaction in 3rd party payment in 5 minutes or notify a human manager 6 hours before special invoices being generated. This behavior is currently implementable in a plugin if you listen for INVOICE_CREATION of recurring subscription and queue it yourself, and directly pool the notifications table. Both are too hacky and implementation dependant on Killbill, so I would like to see some native support, considering it's not difficult to implement. 

Another use case would be triggering usage aggregation on another service. Killbill doesn't provide a mechanism for subscription to actively query its usage. 

I'm still wrapping my head around why even dry run invoice generation notification need to run at reference time. I suppose there should be a valid reason for that, and for how Killbill surpress INVOICE_NOTIFICATION if generated invoice is 0 (having credit, for example). 

[karan bansal]

Hi Kien,

The invoicing works at the day boundary level. At the time of account creation, you have the option of setting up referenceTime in case you wish to have these operations at some specific time during the day as per your requirement for reporting/external events. In most of the cases, this core system should be able to handle the billing requirements. For any specific requirements, you will need to look into achieving it through custom plugins.

Dry run also shows you the billable items for a target date, so it also uses the reference time for consistency.

Regards

Karan

[Kiên Hà]

I understand why dry run is calculated as if it is at reference time, I do not understand why it should also always run at that time, considering you can manually trigger dry run at whatever time it is. 

In fact, if you set dry run configuration to for example, 1h, the dry run will be run at the same time (after the invoice due to how current notification queue is handled) with the target date of 3 hour after the reference time. To illustrate, if the bill is DAILY (or MONTHLY/ANNUAL), reference time is 00:00:00 at 1st January, then the sequence at 00:00:00 1/1 is: invoice run for 00:00:00 1/1 -> dry run for 03:00:00 1/1.

Killbill will automatically augment the target date to 00:00:00 2nd for dry run calculation. 

Killbill has a slight optimization to check for the target date and skip if it is past invoice time. That seems fair enough. What isn't fair is why dry run for notification is supposed to be ran at reference time? Change the effective date to 21:00:00 31/12 with target date to 00:00:00 1/1 would make the semantic much more intuitive, at least for me. I found nothing, but this may kill some cache, although the current way of running 1 day before doesn't preserve any cache anyway. 

Another slightly weird thing is how with enough credit, the invoice balance will be cancelled out, although an invoice did happen, since its balance is 0, no INVOICE_NOTIFICATION is fired, although an INVOICE_CREATION event is fired as normal. There is a check for that specific condition. This optimization is understandable but the semantic should be documented more clearly. 

Did I missed something? If the new semantic is desirable, I can create a Github Issues and a PR.

[Kiên Hà]

Slight typo

> In fact, if you set dry run configuration to for example, 1h, the dry run...

I meant 3h. 

[stephane brossier]

The dryRun notification schedule is driven from the property org.killbill.invoice.dryRunNotificationSchedule. From there, the code needs to translate this into an actual event, with a well defined effective date (fully specified datetime), so the internal queue can deliver this event when it is ready.

Therefore, when inserting such an event, the code needs to make a choice to decide which exact point in time should be associated with this event. All the logic we have in Kill Bill  uses the Account#referenceTime to compute such an effective date. This is a somewhat arbitrary choice, but it has the advantage to align things on a per-account level and spread the load on the system, as each account is likely to have a different Account#referenceTime.

There is no mechanism to allow specifying at runtime the logic that should be used on a per-account basis to compute the exact time component of the event.

--
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-us...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/killbilling-users/bd868744-70c3-4171-be78-35fcf736b9e3n%40googlegroups.com.