Invoicing Optimaztion Query

[Prashant Kumar]

Hi Kill Bill team,

We have a use case involving usage-based billing, where each event triggers an invoice generation. However, as the volume of events increases significantly, we encounter issues with invoice generation. For example, we have a monthly subscription with auto-invoice disabled for the account, and events continue to be pushed into the rolled_up_usage table. On a daily basis, we receive around 40,000 events. While we manually generate invoices daily, the large number of events in the rolled_up_usage table results in high CPU utilization.

Now, consider a scenario where we generate an invoice for each event as it comes in. This results in one invoice and one invoice item per event. Upon reviewing the code, we noticed that the logic retrieves all existing invoices and compares the past two billing periods' usage before generating a new invoice.

Is there a way to optimize the invoice generation process to reduce the number of existing invoices fetched, especially when generating invoices for each event? Additionally, how can we optimize invoice generation when processing a high volume of events, such as 40,000 in a single day?

We appreciate any insights or recommendations you can provide.

Thanks and regards

Prashant

[Shaun Forgie]

Hi Prashant,

Why have a monthly plan with auto invoicing disabled for the account that you then manually generate invoices for on a daily basis? Did you consider setting up billing plans that have a daily billing cycle?

Normal billing behaviour can then be controlled more naturally through the standard system configuration options you have available. I have included screenshots of some of the invoicing options that will impact the performance of the invoicing processing.

Documentation about the invoicing configuration options can be found here https://docs.killbill.io/latest/userguide_configuration#_invoice_properties

In terms of usage 40k daily events seems like quite a small number. I would be surprised if ingesting this volume of events was the root cause of your performance issues.

Rgs

Shaun

--
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/33737b4d-3cd8-4729-b439-07f81326efcfn%40googlegroups.com.

--

Shaun Forgie [Principal] - Method Maker Ltd
57a McIntyre Rd, Manukau 2022, Auckland, New Zealand
Mobile +64 21 666 910 https://www.linkedin.com/in/shaunforgie/

[Prashant Kumar]

Hi Shaun,

we have written a plugin which helps us to map the invoice that killbill generate with out internal invoice system. So to not generate the invoice automatically we have set the auto-inovice off and we setup a schedule which on the daily basis generate invoice and map the contract with our internal invoice system.

Also i have verified all the configs, we are using the default config as you mentioned in the screenshot.

Thanks and regards

Prashant Kumar

[Prashant Kumar]

Hi Shaun,

Can reducing the invoice generation computation time be achieved by setting MaxInvoiceLimit to 2M (basically take the invoice items of only previous 2M instead of 200Y back) and MaxRawUsagePreviousPeriod to 1 (Take previous usage )? Will this configuration reduce computation time because why it 200Y back invoice items are needed? Additionally, could it lead to incorrect charge or invoice calculations? What potential impact might this have on overall system performance?

Thanks and Regards,
Prashant Kumar

[Shaun Forgie]

Hi Prashant,

These settings are reliant on the billing cycle being set for the subscription. DWMY etc...The previous period is an example of that. 

My recommendation was to set up the plan in the catalog with a daily billing cycle and play with the settings.

Rgs

Shaun

To view this discussion visit https://groups.google.com/d/msgid/killbilling-users/e27fed21-c9ac-4f43-a1f3-3536137abd6dn%40googlegroups.com.