#joshglazebrook

1 messages · Page 1 of 1 (latest)

dusky raftBOT
paper pewter
#

Hi, not fully follow your use case but yes what you described could work, that you are free to modify the draft Invoice and add as many InvoiceItems as you wish.

solar drum
#

So my service essentially is a fixed monthly cost for access to the service, and the users can place "orders", which for customers I want to invoice once a month, I have been using a price with metering, so I can just increment the quantity throughout the month. But I also have additional "addons" that can be included in the order, which if I want to keep track of those throughout the month I would need to add every "addon" to the subscription (as a metered price) to increment. But there are dozens of addons, so keeping track of every subscription item id to use when creating usage is not ideal.

#

But yea alternative I thought of was just to tabulate the usage (based on my order database) when their invoice is created, add the orders and addons as lineitems (with quantity) befor eits finalized. instead

#

Just was wondering if there were any gotchas or potential issues with this method. I think ideally I wouldn't try to tabulate this all in the live path of the webhook request, but just use a worker queue or pub/sub for this so another process (worker) can do the actual work.

paper pewter
#

qq, does "addon" have quantity? ie. addon A can have from 1 to n

#

But I do think what you described makes sense. Yes you would want to use some worker queue to avoid hanging too long on a webhook handler, and yes just modify all the items you want

solar drum
#

there can be multiple addons per order, and potentially more than 1 of each type per order, so yes i think

#

before I went in the metered usage direction for these, I was thinking of just using invoice items and incrementing the quantity myself as orders (and any addons) were placed, but the problem with that was being able to avoid race conditions as there isn't an increment for invoice items, only setting the quantity value directly.

#

which even if I were to put these onto a worker queue, there still is potential for race conditions if there is more than one worker. But if there is only one "tabulate everything for the last billing period" job for each customer I guess that avoids that issue

paper pewter
#

yeah makes sense

solar drum
#

(the invoiceitems here being what i would tabulate at the end of the billing cycle)

paper pewter
#

Yes. Upcoming Invoice is a simulation. You put it your assumption items and it will gives you a preview

dusky raftBOT