[PHREAKNET-41] Allow for more granular billing based on switch ZIP code

This issue is loosely (but only loosely) related to [PHREAKNET-10] (no dependencies between the two). At a high level, this proposal is to allow associating a location with a particular switch, as opposed to requiring all switches associated with a user (!) (not even just a server) to share the same location.

This will involve updating all billing elements, including:

adding field associating switches with locations, optionally (what kind, e.g. V&H, what the GBP is, is yet to be determined). Default is still to fall back to user location
billing frontend
rate quote system
distance calculation subsystem and cache

References:

T:\Documents\Billing (internal)

The most difficult part of updating the business logic will likely involve the process of determining the distance between the caller and callee. Currently, this is done by looking up the ZIP codes associated with the caller and callee. For the most part, as would be ideal, this is done in SQL. Many of the billing queries are already quite complicated. This will significantly increase the complexity, since we'll be going from simply going from number -> user -> ZIP code on both ends to something more along the lines of number -> switch -> GBP? (e.g. V&H, ZIP code, etc.) and if that's available, use that, otherwise fall back to switch -> user -> ZIP code. Additionally, if the GBP is not a ZIP code (and ideally, it would be more granular, like V&H), then we will have two incompatible units of measurement and will need a way of converting the distance between them.

A possible benefit of using V&H coordinates is we may be able to calculate the distance more easily, instead of needing a lookup table of the distance between every possible pair of ZIP codes (though I have not verified this). If this is the case, it may be ideal to convert everything to the new GBP system system-wide, i.e. associating every server (using the server as the top-level unit, instead of the user), with a GBP.

Worst case, we can manually go in and make up a GBP for every server based on the ZIP code, that would be relatively easy compared to the work to get to that point.

Chris summed this up nicely already so I'm copying/pasting his original proposal here, with the addition that there was some background on making use of V&H coordinates for the location rather than something larger, like a ZIP code:

I feel for the sake of clarity I should avoid any currently used terms and define the entity which carries the critical geographic information that billing is based on as the "Geographic Billing Point" or "GBP"

My idea would be that, either as a submenu of "my switches" or as its own somehow related page, there would be an option to create a Geographic Billing Point. This option, wherever it would be located, would be where things like City Name, State / Country, V&H / LAt and Long would be entered.

In this case, let's say I set up a "Memphis 1" GBP, and an "Atoka 1" GBP (Atoka being a rural area 30 miles north of Memphis, for the sake of a real reference point). I may, perhaps, go back to the My Switches" option and, on the page where one would edit a given switch, I could assign a GBP to a given Switch, and calls to and from that switch would treat that as the billing location.

The page to assign GBP's doesn't HAVE to be on My Switches, of course, it could be anywhere that makes sense. It's just the idea of "attaching" a GBP to a switch / CLLI which matters.

Back on the workflow example, in practice I could assign MMPHTNATMG0 and MMPHTNMAMG0 to Memphis 1, and assign MMPHTNTRSG0 to Atoka 1. This means calls between ATMG0 and MAMG0 would be local, managed whatever way is chosen for such calls, but a call to TRSG0 would be billed from MAMG0 at the rate of a 30 mile distant call. In this case, the same would be said the other way -- calls from Atoka 1 to Memphis 1 switches would be billed at that same rate, for simplicity sake in this description.

That's as far as I'm heavily concerned with this concept -- just enough that we have an internal location system that each switch owner maintains that would manage the physical location of a given switch, with the billing system taking over from there. This would accomplish the exact effect that I was going for with my original idea of each switch having it's own zip code assigned; it really is the same thing, but with improvements added on which are unrelated to my idea but not ignorable as they have been brought up in this discussion.

I apologize if this usage case description is somewhat vague, but I don't see the actual process as being too complex beyond creating a GBP, assigining it a geographic location, then assigning a switch(es) to it. Anything beyond that is, to me, it's own thing, not to be ignored but beyond the scope of my original idea.

Comments

You must be logged in to leave a comment.