Suggested Labels: endpoint/accesses
Background:
It is increasingly more problematic to analyze and understand, from a ISP point of view, what CO price list a given access should apply to. More and more CO divides their accesses into different price groups. Examples are SDU vs MDU, special aggreements with a larger Network Owners, the wish to offer lower prices company services in certain areas, citylans vs fiber association (stadsnät vs byalag) etc.
No field in the current accesses endpoint is dedicated to this. No field is for CO->ISP specifically.
The current approach has been to use other fields (by themselves or in combination) or even to analyze the available services in the services-sup-part. Neither of them solves the problem and are scalable.
The primary field today is "population". It is a CO field and was not intended to be used for logic. It is a freetext field so prone to spelling errors. When the number of different price lists increases, the ISP side needs to include more and more logic to effectively parse the texts.
The secondary field is "premisesType" and is currently mostly used when there is a need to handle price lists for SDU, MDU and Company. If the CO has different regions, special agreements etc then this field is not enough by itself and then needs to be combined with other fields ("population" or available services).
A third use is to make ISP check the available services sub-part of the access and to use freetext search to identify what available services there are and with that data apply a price list. Just like "population" this does not scale, is not really futureproof (se #47 for changes to this structure) and suffers from the same spelling problem as above. The ISP also has to store all that data.
An example:
A CO called "BestFiberCO" has only one product (for simplicity) and implements a price list structure as follows:
Default:
- SDU/Residentual building: 200 SEK
- MDU/Apartment: 100 SEK
RegionNorth:
- All: 250 SEK
BigStockholmApartmentCustomer:
- All: 150 SEK
A customer wants to order and gives AID 123456. From the data in that access object the ISP now must know what price list to use in order to calculate end price. It must match to 1 and only 1 price list.
If the CO insists the population field is used for their purposes and only stores landlord (for example) the matching is virtually impossible.
If the CO has accurately used premisesType then we can differentiate between SDU and MDU but that will still not help us as RegionNorth and BigStockholm has different prices.
Population is therefore needed. If population is empty then use premisesType to see if SDU or MDU and apply either 200 (SDU) or 100 (MDU). If population is RegionNorth apply 250 to all and if it is BigStockholm then use 150. The CO could obviously also tag population="SDU" and population="MDU" and then premisesType would not be needed.
However there is a CO today that refuses to use population for these purposes. A combination of premisesType and searching the services sub-part of the access object for available services names is their solution.
Proposed solution:
A special field that is exclusively dedicated to this problem needs to be addes to the access object. The field should NOT be text and must not be null or empty.
Proposed name: priceGroup (unsigned integer)
0 = Special value the defines it as default price list.
1+ = Used by CO to "name" their price lists. Must be set and included in the CO-ISP price list agreement.
Every access MUST be matched to 1 and only 1 priceGroup. Changes must be communicated to ISP well in advance.
In the example above:
0 = Default SDU
1 = Default MDU
10 = RegionNorth
100 = BigStockholm
If a group of SDUs join together and negotiates a special price they can just be changed to a new priceGroup 20 and CO communicates the change and times. They are still premisesType=ResidentialBuilding, their population is intact, no need for naming special services.