feat: generate invoice for overdraft credits

[kushsharma]

It's necessary to configure the product name to calculate per unit price before the overdraft credits can be invoiced in billing.customer.credit_overdraft_product. If not set, invoice reconcilation and creation is skipped.

If there is already an invoice for overdraft credits for same time range, no new invoice will be created for that customer. Currently the system generates them on the first day of the month.
Reconciliation of these invoice happens on same cadence as invoices gets synced from the billing provider.

• feat(frontier): on demand trigger to generate credit overdraft invoices proton#373

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
frontier	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 11, 2024 4:44am

[coveralls]

Pull Request Test Coverage Report for Build 11772280490

Details

• 37 of 521 (7.1%) changed or added relevant lines in 13 files are covered.
• 5 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.4%) to 30.398%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
billing/usage/service.go	0	1	0.0%
cmd/serve.go	0	2	0.0%
billing/credit/credit.go	0	3	0.0%
billing/credit/service.go	0	3	0.0%
pkg/server/interceptors/authorization.go	0	3	0.0%
billing/invoice/invoice.go	0	6	0.0%
internal/api/v1beta1/billing_invoice.go	0	7	0.0%
pkg/utils/pointers.go	0	8	0.0%
pkg/db/db.go	24	41	58.54%
internal/store/postgres/billing_invoice_repository.go	0	32	0.0%

Files with Coverage Reduction	New Missed Lines	%
billing/invoice/service.go	5	1.36%

Totals
Change from base Build 11739744280:	-0.4%
Covered Lines:	7661
Relevant Lines:	25202

---

💛 - Coveralls

[AmanGIT07]

Is this done to prevent race condition?

[AmanGIT07]

I feel it will make system slow once we start to have good amount of transactions. Also we calculate balance by summing over all rows instead which may also get performance issues.

[kushsharma]

Is this done to prevent race condition?

Yes, this is to prevent race conditions. What other way do you propose here to prevent it?

I feel it will make system slow once we start to have good amount of transactions. Also we calculate balance by summing over all rows instead which may also get performance issues.

Yes, one way I was thinking was to maintain a monthly statement in system and only accumulate records since last statement. But this introduces complexity quite a lot and was postponing it until we hit the performance degradation. I want to know what part of it is the bottleneck before going ahead with this approach. Do you have anything else in mind?

[AmanGIT07]

Yes, this is to prevent race conditions. What other way do you propose here to prevent it?

We actually did analysis for the same. Shared a document with you. With current setup where we don't have an aggregated balance, we can use redis. If instead we can move to having an aggregated balance which each transactions update, then we can use pessimistic locks.