Un sistema de facturación postpago

Últimamente mi blog había tomado una deriva demasiado personal, con lo cual esta vez voy a cambiar el tercio y Wilson os va a contar como funciona un sistema de facturación postpago ("post paid billing system" que diría el amigo de Domingo) usado por unos 250 operadores de telefonía móvil en el mundo (entre ellos Vodafone España) para emitir sus facturas a sus clientes. Creo que puede ser interesante para el público en general de cara a comprender cómo se genera la factura que le llega a casa y que mágicamente refleja (por lo general) con tremenda exactitud las llamadas que ha realizado y los descuentos que se le han aplicado, amén de otras cosas que a continuación detallaré.

Primeramente veamos como es la arquitectura del sistema:

Quedaros con este esquema pues hablaremos de las distintas partes a lo largo del post. Los no informáticos no os asusteis que la cosa es mucho más sencilla de lo que a primera vista parece. Dividiremos el sistema en 4 áreas operacionales:

• Configuración
• Provisionamiento
• Tarificación de uso
• Facturación

Configuración

Aquí habremos de configurar las promociones que queremos ofrecer a nuestros clientes como operador de telefonía móvil. Os detallo los elementos más comunes y un ejemplo de cada uno de ellos:

• RC (Recurring Charge o Cargo Recurrente) - "10EUR de cuota mensual"
• NRC (Non Recurring Charge o Cargo No Recurrente) - "25EUR de cuota de alta"
• DC (Discount o Descuento) - "50% de descuento en las llamadas entre las 20:00 y las 23:00"
• UC (Unit Credit o Unidad de Crédito) - "100 SMS gratis al mes"
• Usage Rate (Tarificación de uso) - "0,2 céntimos el minuto desde las 9:00 a las 18:00"
• Contract (Contrato) - "Contrato de permanencia de 18 meses"
• Component (Componente) - Agrupa unidades (RC, NRC, DC...)
• Package (Paquete) - Agrupa componentes

Imaginemos que queremos configurar la siguiente promoción:

"Promoción EL FLASH DEL VERANO para nuevos clientes: pague una cuota de alta de 25EUR y las llamadas nacionales a cualquier móvil o teléfono fijo nacional sólo le costarán 0,2 céntimos desde las 9:00 a las 18:00 (0,5 céntimos el resto de tramos horarios y 0,9 céntimos las llamadas internacionales). Además de esto, si lo desea, pagando sólo 10EUR al mes recibirá 100 SMS gratis al mes y un 50% de descuento en las llamadas internacionales. Esta promoción está sujeta a un contrato de permanencia de 18 meses, caso de cancelarlo anticipadamente deberá abonar 150EUR".

Vamos a desglosar esta promoción en las entidades que necesitamos:

• NRC1 25EUR de cuota de alta (es un cargo no recurrente que se paga una sola vez)
• Usage Rate:
• 0,2EUR el minuto llamadas nacionales desde las 9:00 a las 18:00 (UR1)
• 0,5EUR el minuto llamadas nacionales desde las 18:01 a las 8:59  (UR2)
• 0,9EUR el minuto llamadas internacionales desde las 0:00 a las 23:59 (UR3)
• RC1 10EUR de cuota mensual (es un cargo recurrente que se paga una vez al mes)
• UC1 100SMS
• DC1 50% en llamadas internacionales
• CONTRACT1 de 18 meses
• NRC2 150EUR (es un cargo no recurrente que se paga una sola vez si el cliente cancela el contrato antes de que expire a los 18 meses)

 En la promoción podemos identificar 2 componentes:

• Componente obligatorio, compuesto de:
• NRC1
• UR1, UR2, UR3
• CONTRACT1
• NRC2 (ligado a CONTRACT 1)
• Componente opcional, compuesto de:
• RC1
• UC1
• DC1

Podemos agrupar ambos componentes bajo un mismo paquete (EL FLASH DEL VERANO) que representará la promoción que hemos configurado.

La configuración de todo esto se guardará en unas cuantas tablas de la base de datos de Admin (ver diagrama de la arquitectura).

Provisionamiento

Ya tenemos configurada nuestra flamante promoción EL FLASH DEL VERANO parida por los genios del departamento de marketing y como tal ya puede publicitarse por tierra, mar y aire.

Llama nuestro primer cliente que quiere darse de alta como cliente en esta promoción, el operador u operadora (también conocido en el mundillo como "CSR") le pregunta si además de la promoción estandar quiere abonarse a la promoción opcional y el cliente dice que sí. El CSR mediante una aplicación al efecto le toma los datos al cliente (nombre, dirección, número de cuenta, etc) y lo da de alta en el sistema.

Veamos que ocurre en las tripas de la bestia cuando el CSR confirma el alta: los datos de la cuenta (el cliente) se guardan en la base de datos de Customer, en el esquema de la arquitectura que he puesto antes están representadas 4 bases de datos de Customer pero hay operadores que tienen 15 o 20, tened en cuenta que estamos hablando de operadores que en algunos casos tienen MILLONES de clientes entonces, obviamente, no pueden ir todos en una misma máquina y base de datos por temas de eficiencia de procesamiento.

Lo que se hace es lo siguiente:

1. Se guarda en la base de datos de Catalog la información mínima imprescindible (número de teléfono móvil (external_id) asignado por el sistema sacado de un inventario (tabla que guarda los números de teléfono disponibles y aún no asignados)  y un identificador UNICO interno (internal_id), que será como el "DNI" del cliente dentro del sistema). Asimismo también se guarda el número de servidor dónde está provisionada esa cuenta.
2. Mediante un algoritmo de balanceo de carga (que bien me ha quedado esto) el sistema decide cual de las N bases de datos de Customer alojará los datos "gruesos" de la cuenta (nombre, dirección, paquetes/componentes provisionados, etc). El objetivo es que las bases de datos de Customer cuenten "más o menos" con el mismo número de registros.

En nuestro ejemplo supongamos que tenemos 4 bases de datos de Customer y los datos de provisionamiento de nuestro cliente han sido almacenados en la base de datos Customer número 3.

Asimismo, comentar que hay 2 procesos que replican la información:

1.  De la base de datos de Catalog a cada una de las bases de datos de Customer. Esto es necesario ya que en Customer también necesitamos tener la información mínima (external_id = número de teléfono).
2. De la base de datos de Admin a cada una de las bases de datos de Customer. Esto es necesario ya que necesitamos la información de la configuración en cada base de datos de Customer (veremos luego porqué).

Por tanto, recapitulemos la información que hemos guardado de nuestro nuevo cliente:

• Catalog:
• external_id = 680696969 (número de teléfono)
• internal_id = 1837 (identificador interno)
• server_id = 3 (nos indica en que servidor/BD de Customer está alojada esta cuenta)
• Customer:
• internal_id = 1837
• fecha_de_alta = 1-5-2010
• Paquete EL FLASH DEL VERANO provisionado a internal_id = 1837

Tarificación de uso

Al cabo de los pocos días nuestro cliente recibe en su casa su flamante teléfono móvil (regalo de la operadora por serle fiel 18 meses) con su tarjeta SIM con el número 680696969. Vamos a suponer que en todo el mes Mayo realiza 3 llamadas:

1. Una nacional el día 6-5-2010 a las 14:27:53 de 10 minutos
2. Una internacional el día 15-5-2010 a las 17:05:39 de 20 minutos
3. Una nacional el día 23-5-2010 a las 23:00:07 de 30 minutos

Cada vez que se hace una llamada el switch del sistema de telefonía móvil genera un registro en un fichero de texto plano con toda la información de la llamada, entre otros muchos datos: número originario de la llamada, número destinatario de la llamada, hora de inicio de la llamada, segundos consumidos, etc, etc. En realidad en nuestro sistema de facturación postpago nos importa muy poco la tecnología que hay detrás de una red de telefonía móvil, simplemente nos interesa el fichero de uso que tenemos que procesar para tarificar y posteriormente facturar esas llamadas.

Entonces, para tarificar la llamada contamos con 3 procesos batch que están permanentemente corriendo:

1. Proceso "COM": simplemente recoge los ficheros de uso generados por los switches y los mueve a un directorio de nuestro sistema, en el servidor Admin.
2. Proceso "MCAP": procesa los ficheros de uso en el servidor de admin dejados allí por COM, va registro a registro examinando el external_id (número de teléfono originario) determinando en que servidor de Customer se encuentra la cuenta que ha hecho esa llamada. En cada servidor de Customer genera unos ficheros de uso con registros que contienen UNICAMENTE llamadas de cuentas pertenecientes a ese servidor/BD de Customer.
3. Proceso "CAP": proceso que corre en cada servidor de customer y que procesa los ficheros de uso dejados allí por MCAP, por cada registro TARIFICA el coste de la llamada y guarda esta información en una tabla de la base de datos de Customer llamada CDR_DATA.

Volvamos al ejemplo de nuestro cliente y a la tarifa que tiene provisionada por adherirse a la promoción EL FLASH DEL VERANO, como dijimos hizo 3 llamadas y vamos a suponer que venían 2 llamadas en un fichero de uso y otra en otro:

1. COM movió los ficheros a Admin.
2. MCAP detectó 3 registros (llamadas) con el número originario de la llamada 680696969 y supo que esos registros deberían mandarse a un fichero en el servidor Customer 3 consultando la base de datos de Catalog (tan simple como esta query: SELECT server_id FROM EIEM WHERE external_id = '680696969').
3. CAP tarificó en el servidor de Customer las llamadas en base a la tarifa que tiene provisionada la cuenta guardando en CDR_DATA toda la informacion de la llamada y la tarificación:

•  "nacional el día 6-5-2010 a las 14:27:53 de 10 minutos" = UR1 (0,2EUR/min) = 10 x 0,2 = 2EUR
• "internacional el día 15-5-2010 a las 17:05:39 de 20 minutos" = UR3 (0,9EUR/min) = 20 x 0,9 = 18EUR
• "nacional el día 23-5-2010 a las 23:00:07 de 30 minutos" = UR2 (0,5EUR/min) = 30 x 0,5 = 15EUR

Facturación

En nuestro sistema existe una cosa que es el "ciclo de facturación", esto es, a cada cliente le asignamos cada cuanto tiempo (mensual, bi-mensual, etc) debe ser facturado. Asumiendo que todos nuestros clientes deben ser facturados mensualmente, para hacer la facturación se correrá en cada servidor de Customer un proceso batch llamado "BIP" que se ejecutará a diario de tal manera que si un cliente se ha dado de alta el 1-5-2010 entonces el 1-6-2010 (un mes después) será "seleccionado" y procesado por BIP y se generará su factura calculando los distintos cargos que se le pueden imputar basado en lo que tiene configurado y el uso (llamadas) que se hicieron ese mes (es por ello que es necesario tener replicada toda la información de configuración de Admin en Customer). El detalle de todos los cargos calculados se almacenarán en un par de tablas (BILL_INVOICE + BILL_INVOICE_DETAIL). A partir de aquí generar la factura es pan comido, basta cualquier aplicación para leer de esas tablas e imprimir en papel o exportar adónde queramos (por ejemplo a un HTML para que el cliente pueda ver su factura on-line en la web).

Veamos que pasó el 1-6-2010 con nuestro conejillo de indias, BIP le calculó los siguientes cargos:

NRC1 = 25EUR
TOTAL USO = 2 + 18 + 15 = 35EUR
RC1 = 10EUR
DC1 = 50% en llamadas internacionales = 50% de 18EUR = -9EUR

Por tanto el total de su factura sería: 25 + 35 + 10 - 9 = 61EUR

Veamos que pasaría el 1-7-2010 si no hace ninguna llamada en todo el mes de Junio:

TOTAL_USO = 0
RC1 = 10EUR

Sólo pagaría 10EUR (nótese que ya no le cobramos el NRC1 que era la cuota de alta)

BONUS TRACK

Este sistema de facturación también sirve para facturar otros servicios como puede ser el consumo de una línea 3G (podemos cobrar X EUR por Megabyte o Kilobyte...) o incluso está funcionando en algunas cadenas de televisión de pago por visión, pensad que el hecho de "comprar una película" no es más que un evento de uso comparable a mandar un SMS... es decir, en nuestro sistema recibimos un fichero con uso y nos da igual si ese uso viene de un móvil o de un decodificador de TV... nos da igual lo que hay "detrás". Incluso este sistema está siendo usado por 2 compañías de agua y luz para facturar sus servicios (nuevamente recibimos un fichero con los litros o kilowatios consumidos...). El lema es: si se puede medir se puede facturar :)

Me dejo en el tintero muchas cosas (gestión del roaming, gestión de morosos, gestión de pagos, etc) pero creo que con esto es suficiente por hoy ;)

La enorme ventaja de este sistema para los operadores es que pueden implementar CONFIGURANDO el sistema las promociones más maquiavélicas que pueden salir del departamento de marketing y creedme que hay algunas que tienen miga!! Obviamente siempre hay cosas que el sistema no puede cubrir y hay que customizarlo pero en general funciona muy bien y evita que el operador tenga un ejército de programadores que cambien el sistema cada vez que quieren sacar una promoción nueva.

A modo de anécdota comentaros que este sistema fue ideado y creado por un indio que a día de hoy es una de las grandes fortunas de la informática, el tío vendió la compañía por un pastón justo antes de la crisis de las .com, mejor timing imposible jeje.

Si en la III edición del reto blogger este señor me deja participar, os contaré como funciona un sistema de facturación prepago, en el cual si que nos importa y mucho el hardware que hay detrás al ser un sistema en tiempo real. Esto es lo que se lleva ahora :)