2018-05-08 12:09:29 +01:00
|
|
|
from datetime import datetime
|
|
|
|
|
|
2017-10-24 13:23:24 +01:00
|
|
|
create_or_update_free_sms_fragment_limit_schema = {
|
2022-04-08 17:05:59 +01:00
|
|
|
"$schema": "http://json-schema.org/draft-07/schema#",
|
2017-10-24 13:23:24 +01:00
|
|
|
"description": "POST annual billing schema",
|
|
|
|
|
"type": "object",
|
|
|
|
|
"title": "Create",
|
|
|
|
|
"properties": {
|
2022-02-25 12:01:20 +00:00
|
|
|
"free_sms_fragment_limit": {"type": "integer", "minimum": 0},
|
2017-10-24 13:23:24 +01:00
|
|
|
},
|
2017-11-02 12:19:17 +00:00
|
|
|
"required": ["free_sms_fragment_limit"]
|
2017-10-24 13:23:24 +01:00
|
|
|
}
|
2018-05-08 12:09:29 +01:00
|
|
|
|
|
|
|
|
|
2022-04-20 18:00:30 +01:00
|
|
|
def serialize_ft_billing_remove_emails(rows):
|
|
|
|
|
return [
|
|
|
|
|
{
|
|
|
|
|
"month": (datetime.strftime(row.month, "%B")),
|
|
|
|
|
"notification_type": row.notification_type,
|
2022-04-20 16:55:38 +01:00
|
|
|
# TEMPORARY: while we migrate away from "billing_units"
|
2022-04-20 18:00:30 +01:00
|
|
|
"billing_units": row.billable_units,
|
2022-04-20 16:55:38 +01:00
|
|
|
"chargeable_units": row.chargeable_units,
|
|
|
|
|
"notifications_sent": row.notifications_sent,
|
2022-04-20 18:00:30 +01:00
|
|
|
"rate": float(row.rate),
|
|
|
|
|
"postage": row.postage,
|
Add costs to each row in yearly usage API
This will replace the manual calculations in Admin [^1][^2] for SMS
and also in API [^3] for annual letter costs.
Doing the calculation here also means we correctly attribute free
allowance to the earliest rows in the billing table - Admin doesn't
know when a given rate was applied so can't do this without making
assumptions about when we change our rates.
Since the calculation now depends on annual billing, we need to
change all the tests to make sure a suitable row exists. I've also
adjusted the test data to match the assumption that there can only
be one SMS rate per bst_date.
Note about "OVER" clause
========================
Using "rows=" ("ROWS BETWEEN") makes more sense than "range=" as
we want the remainder to be incremental within each group in a
"GROUP BY" clause, as well as between groups i.e
# ROWS BETWEEN (arbitrary numbers to illustrate)
date=2021-04-03, units=3, cost=3.29
date=2021-04-03, units=2, cost=4.17
date=2021-04-04, units=2, cost=5.10
vs.
# RANGE BETWEEN
date=2021-04-03, units=3, cost=4.17
date=2021-04-03, units=2, cost=4.17
date=2021-04-04, units=2, cost=5.10
See [^4] for more details and examples.
[^1]: https://github.com/alphagov/notifications-admin/blob/master/app/templates/views/usage.html#L60
[^2]: https://github.com/alphagov/notifications-api/blob/072c3b207940597aacb5bebdbf3757f848d22cd6/app/billing/billing_schemas.py#L37
[^3]: https://github.com/alphagov/notifications-admin/blob/474d7dfda834ebf2f0966f176fb6da556808d8a1/app/templates/views/usage.html#L98
[^4]: https://learnsql.com/blog/difference-between-rows-range-window-functions/
2022-04-20 17:14:17 +01:00
|
|
|
"cost": float(row.cost),
|
2022-04-21 12:55:30 +01:00
|
|
|
"free_allowance_used": row.free_allowance_used,
|
2018-05-08 12:09:29 +01:00
|
|
|
}
|
2022-04-20 18:00:30 +01:00
|
|
|
for row in rows
|
|
|
|
|
if row.notification_type != 'email'
|
|
|
|
|
]
|
2018-05-11 16:25:16 +01:00
|
|
|
|
|
|
|
|
|
2022-04-20 18:00:30 +01:00
|
|
|
def serialize_ft_billing_yearly_totals(rows):
|
|
|
|
|
return [
|
|
|
|
|
{
|
|
|
|
|
"notification_type": row.notification_type,
|
2022-04-20 16:55:38 +01:00
|
|
|
# TEMPORARY: while we migrate away from "billing_units"
|
2022-04-20 18:00:30 +01:00
|
|
|
"billing_units": row.billable_units,
|
2022-04-20 16:55:38 +01:00
|
|
|
"chargeable_units": row.chargeable_units,
|
|
|
|
|
"notifications_sent": row.notifications_sent,
|
2022-04-20 18:00:30 +01:00
|
|
|
"rate": float(row.rate),
|
Add costs to each row in yearly usage API
This will replace the manual calculations in Admin [^1][^2] for SMS
and also in API [^3] for annual letter costs.
Doing the calculation here also means we correctly attribute free
allowance to the earliest rows in the billing table - Admin doesn't
know when a given rate was applied so can't do this without making
assumptions about when we change our rates.
Since the calculation now depends on annual billing, we need to
change all the tests to make sure a suitable row exists. I've also
adjusted the test data to match the assumption that there can only
be one SMS rate per bst_date.
Note about "OVER" clause
========================
Using "rows=" ("ROWS BETWEEN") makes more sense than "range=" as
we want the remainder to be incremental within each group in a
"GROUP BY" clause, as well as between groups i.e
# ROWS BETWEEN (arbitrary numbers to illustrate)
date=2021-04-03, units=3, cost=3.29
date=2021-04-03, units=2, cost=4.17
date=2021-04-04, units=2, cost=5.10
vs.
# RANGE BETWEEN
date=2021-04-03, units=3, cost=4.17
date=2021-04-03, units=2, cost=4.17
date=2021-04-04, units=2, cost=5.10
See [^4] for more details and examples.
[^1]: https://github.com/alphagov/notifications-admin/blob/master/app/templates/views/usage.html#L60
[^2]: https://github.com/alphagov/notifications-api/blob/072c3b207940597aacb5bebdbf3757f848d22cd6/app/billing/billing_schemas.py#L37
[^3]: https://github.com/alphagov/notifications-admin/blob/474d7dfda834ebf2f0966f176fb6da556808d8a1/app/templates/views/usage.html#L98
[^4]: https://learnsql.com/blog/difference-between-rows-range-window-functions/
2022-04-20 17:14:17 +01:00
|
|
|
# TEMPORARY: while we migrate to "cost" in the Admin app
|
2022-04-20 18:00:30 +01:00
|
|
|
"letter_total": float(row.billable_units * row.rate) if row.notification_type == 'letter' else 0,
|
Add costs to each row in yearly usage API
This will replace the manual calculations in Admin [^1][^2] for SMS
and also in API [^3] for annual letter costs.
Doing the calculation here also means we correctly attribute free
allowance to the earliest rows in the billing table - Admin doesn't
know when a given rate was applied so can't do this without making
assumptions about when we change our rates.
Since the calculation now depends on annual billing, we need to
change all the tests to make sure a suitable row exists. I've also
adjusted the test data to match the assumption that there can only
be one SMS rate per bst_date.
Note about "OVER" clause
========================
Using "rows=" ("ROWS BETWEEN") makes more sense than "range=" as
we want the remainder to be incremental within each group in a
"GROUP BY" clause, as well as between groups i.e
# ROWS BETWEEN (arbitrary numbers to illustrate)
date=2021-04-03, units=3, cost=3.29
date=2021-04-03, units=2, cost=4.17
date=2021-04-04, units=2, cost=5.10
vs.
# RANGE BETWEEN
date=2021-04-03, units=3, cost=4.17
date=2021-04-03, units=2, cost=4.17
date=2021-04-04, units=2, cost=5.10
See [^4] for more details and examples.
[^1]: https://github.com/alphagov/notifications-admin/blob/master/app/templates/views/usage.html#L60
[^2]: https://github.com/alphagov/notifications-api/blob/072c3b207940597aacb5bebdbf3757f848d22cd6/app/billing/billing_schemas.py#L37
[^3]: https://github.com/alphagov/notifications-admin/blob/474d7dfda834ebf2f0966f176fb6da556808d8a1/app/templates/views/usage.html#L98
[^4]: https://learnsql.com/blog/difference-between-rows-range-window-functions/
2022-04-20 17:14:17 +01:00
|
|
|
"cost": float(row.cost),
|
2022-04-21 12:55:30 +01:00
|
|
|
"free_allowance_used": row.free_allowance_used,
|
2018-05-11 16:25:16 +01:00
|
|
|
}
|
2022-04-20 18:00:30 +01:00
|
|
|
for row in rows
|
|
|
|
|
]
|