Insert charge for CDR
Trigger to insert a transaction charging the customer for the amount owed for
an INSERTed CDR.
Function to compute the amount to charge a customer for a given cdr
This takes into account how much of their "included" minute credit has already
been used in the calendar month.
Store plans data in a table
Ideally this would come via FDW, but for now we can easily have a script push to
this table from the source of truth.
Table for call_rates and view to augment CDRs with that data
New debian stable doesn't have postgres 11
For every $15 deposited, add one invite code
View to get all invites not yet used up.
Table to store invite codes and their status. Stores who make the code and
when, who used the code (if anyone has used it yet) and when, and the code
itself. Codes are single-use so once used_by_id is set the code cannot be used again.
Creating with a literal stored the time that was 'now' when the view was
created. We want the current time when the view is accessed.
plan_log uses a tsrange instead of two timestamps now
This is honestly just more correct, but also allows for easy checking of
non-overlapping ranges, which we now do.
tag for deploy of jmp-pay to production
Give plan_log a primary key
Can't have two entries starting at the same time
Add an optional note to transactions
Verification shouldn't actually select all data
Running these in prod later would be slow otherwise.
Merge sub_cent_transaction plan item into transactions
Since none of this is deployed or tagged yet, there's no reason for the overly
complex alter table schenanigans. We have to leave the empty plan item though,
since it's in the git history and otherwise sqitch rebase would break
Will get the hang of this tooling!
Create table for cdr storage
Some of this data is not needed for billing (such as disposition, or full tel of
the other side vs a prefix) however it will be very useful if we expose call
logs to the user. If this is a privacy concern we can allow users to request
deletion of CDRs from past billing periods in the future.
View for the most current plan for each customer
This includes a plan even if it is expired, with the expires_at present for
checking if desired. This is because an expired user may still want to may a
payment or similar, and checking their plan is how we know what currency to
charge them in.
Table to log plans active on different accounts