Generation kWh
⚡ Las entrañas de la bestia ⚡
Som Energia
Intro
Objetivo
Familiarizar al equipo de proyecto y al resto de IT de los detalles de implementacion del Generation kWh que se necesitan para entender su dinámica.
Proyectos: entender las recientes incidencias y repensar el nuevo modelo de inversión
IT: mapa mental para entrar al código
¿Qué es?
Una forma colectiva de invertir en renovables.
En vez de dar intereses 💰,
da derecho a usar los kWh producidos 💡
a precio de coste.
Funcionamiento
Las socias realizan inversiones para construir plantas
Se retorna en 25 años, sin intereses, año de carencia
Una vez construidas, los kWh producidos se transforman en derechos de uso para las inversoras, proporcionalmente a su inversión.
Los derechos se usan en diferentes contratos según las asignaciones definidas por cada inversora.
En las facturas se separan los kWh a precio Generation de los que son a precio de mercado.
Documentación
Road Map
Modelos de inversión
Concesión de derechos
Asignación de contratos
Uso de derechos
Corrección de derechos
Módulos (IT)
Modelos de inversión
Modelo de inversión
Define el ciclo de vida de una inversión
Qué operaciones podemos hacer
Entre que estados transiciona
Generation kWh
Aportaciones voluntarias
Títulos participativos
Operaciones (ERP)
Generalizando
Objetivo: Un solo modelo parametrizado
¿Se pagan intereses? ¿Se amortiza? ¿Carencia? ¿Penalización por desinversión?
Estamos a medias: pasamos el Generation pero hay que incorporar los otros
Generalizar implica migrar
Migrar implica interpretar la contabilidad como operaciones del ciclo de vida.
Nuevo modelo de inversión
¿Cabe el nuevo modelo que se está pensando?
¿Hay nuevas operaciones?
¿Hay que modificar el diagrama de estados?
Concesión de derechos
Derechos
kWh a precio Generation disponibles
para uso de un socio inversor
Regla de tres entre:
- la producción de las plantas (hora a hora)
- la inversión del socio (día a día)
- el coste de las plantas construidas (día a día)
Están vinculados a la hora de producción
Solo se pueden gastar en el mismo periodo tarifario en que fueron producidos
Precálculo por perfil
No almacenamos curvas de derechos para cada socio
Precalculamos para cada número de acciones (Perfil)
Ojo: Un socio cambia de perfil cuando se activa o expira una inversión
La curva de derechos de un socio concreto será un collage de curvas de varios perfiles
Flujo de cálculo
Mix-Planta-Contador
Producción contador
Producción agregada
Curva horaria con la producción disponible para el Generation
Suma hora a hora de la producción de los contadores.
Solo sumamos los dias en que contador y planta estan activos.
No se almacena, se calcula cada vez que queremos generar derechos.
Acciones construidas
Curva horaria que agrega el valor en acciones de cada planta activa.
Cuando activamos una planta la curva sube.
Baja cuando jubilamos la planta.
Sirve para relativizar el valor de las acciones de las socias.
Cuantización
Cuantización
Obtener, para cada perfil, derechos en kWh enteros sin perder fracciones entre hora y hora
- Convertir producción agregada a Wh (
*1000) - Aplicar proporción: acciones / construidas
- Suma acomulada hora a hora (integral)
- Cuantizar a kWh (
//1000) - Diferencia hora a hora
Guardamos el remanente (en Wh) del intérvalo calculado para usarlo para el pròximo intérvalo.
Remanentes
Restos de kWh del último día calculado
Se guardan para cada perfil en el modelo Remainders
También indica la siguiente fecha a calcular de ese perfil
Si un perfil no tienen ningún remanente,
calcular desde el principio
Derechos por perfil
Asignación de contratos
Asignaciones
Contratos beneficiarios
de las inversiones de una socia
Cualquier contrato de Som Energia
No se requiere vinculacion con la socia
(como titular, pagadora…)
Puede haber más de un contrato beneficiario
Se establecen prioridades entre ellos
Asignaciones (ERP)
Asignación inicial
Un mes antes de activarse la inversión,
se hace una asignación por defecto y se notifica a la socia por si quiere cambiarla.
Con prioridad 0 el contrato con más consumo con la inversora como titular. Si no tiene contratos como titular, el que tenga más consumo figurando como pagadora.
Con prioridad 1 todo el resto de contratos en los que figure como pagadora o titular.
Prioridades
Un contrato más prioritario tiene la opción de gastar primero los derechos, hasta que factura la fecha en que se han producido. A partir de ahí, esos derechos quedan disponibles para el resto de contratos.
Se implementa con el punto de vista inverso:
Una factura de un contrato no puede usar derechos generados a fechas que otro contrato más prioritario no haya facturado aún.
Porqué prioridad laxa
La generación de facturas no es ordenada
Cada contrato puede salir antes o despues que otro
Hay contratos con facturación bloqueada
Abonos, refacturaciones, borradores…
A misma prioridad o en zona no restringida, el primero que factura se lo lleva.
Múltiples fuentes
Un contrato puede recibir derechos de varios inversoras
No está definido de cual recibe primero
En la factura, aparecen en linias separadas con el nombre de cada inversora
Uso de derechos
Anotando el uso
El uso de los derechos sí que
se almacena por cada socia
A medida que usamos kWh,
la curva de uso del socio
va igualando, sin superar,
a su curva de derechos, hora a hora
Derechos usados
Uso y retorno
Se reservan derechos
cuando se crea una factura en borrador
Se devuelven derechos
cuando se borra, abona, rectifica…
Ojo: facturas en borrador reservan derechos
¡Hay que borrarlas si no son buenas!
Ventana de uso
Uso de derechos
Dentro de la ventana de uso:
Se usan los mas antiguos sin usar
Se devuelven los más modernos usados
Las facturas no se guardan
de qué días/horas cogieron los derechos
Tampoco en la curva de uso se guarda
a qué facturas fueron ¿deberiamos?
Periodos P1, P2…
Se reservan derechos de forma independiente
para cada periodo horario de la tarifa
Solo se pueden gastar los derechos
generados a las horas que le corresponden
Corrección de derechos
¿Por què?
Nos han llegado las primeras lecturas tarde
Nos equivocamos con el código del contador
Detectamos un error en como se calcula
…
💩 happens, so 💃
¿Reescribimos los derechos?
Problema
No podemos reescribir la curva por debajo
porque esos derechos ya se han otorgado
La curva de uso estaría por encima de los derechos otorgados.
Aunque en global se den más derechos,
ha de ser mayor hora a hora
Solución
Algoritmo para regenerar la curva, respetando los derechos ya otorgados.
Cuando, por respetar los derechos ya dados,
se dan derechos de más en algunas horas
se compensa en las horas posteriores en que se dió de menos.
Genera una corrección.
Visualmente
Curva de corrección
La curva corregida es fea de enseñar
Guardamos la corrección para recuperar la bonica
otorgados corrección original
2019-01 109 0 109
2019-02 114 0 114
2019-03 157 25 132
2019-04 250 79 171
2019-05 48 -104 152
2019-06 201 0 201
2019-07 192 3 189
2019-08 160 0 160
2019-09 112 0 112Módulos
IT Warning
Mapa
ERP vs Pure Python
La lógica de negocio se ha extraido fuera del ERP
Objetivo:
Agilizar la ejecucion de los test unitarios
Facilitar una eventual migración a otro ERP o versión
Estrategias:
Controlador de estado
Inyección y delegación
State controller
Máquina de estados que controla una serie de atributos de un modelo del ERP.
El constructor recibe los atributos leidos del ERP.
Sus metodos son las acciones que cambian el estado del modelo (transiciones).
Se le puede consultar los atributos modificados,
para hacer el write de vuelta al ERP.
De los side effects se encarga el modelo
Inyección y delegación
API: Modelo ERP sin tabla (en memoria)
Classe pura: Clase (no ERP) con el mismo nombre
Proveedores de datos: Interfaz no manchada con cursor y uid para acceder a datos del ERP
Cuando la API sirve una llamada:
- crea los proveedores de datos,
- crea la clase pura inyectandole los proveedores
- delega la funcionalidad a la clase pura
Data providers
Abstraen el acceso a datos del ERP
Substituibles por mocks para testear la lógica de negocio en las clases puras
Su interfaz ha de ser independiente del ERP
(menos el constructor)
Clase base ErpWrapper:
el constructor recibe los parametros cursor, uid
los otros métodos los ven como miembros.
Test Funcionales
Abusamos del concepto.
Son los que necesitan el ERP
y usan erppeek para testear.
Intentamos que solo sean los funcionales y que la lógica esté testeada ya en los unitarios.
Cubren API’s (propiamente funcionales) pero también los data providers y los side effects de los modelos con state controller.
Test Helpers
API’s que usamos solo para testear
Wrappers para traducir parámetros y retornos
a tipos serializables por XMLRPC
También helpers comunes para setUp y tearDown.
Investments
Modelo ERP: generationkwh.investment
Delega manipulacion de estado a investmentstate. Añade creacion de facturas, remesas…
investmentstate máquina de estados de inversión. Se inicializa y serializa en un diccionario como el del erp.
investmentmodel encapsula expecificidades de Generation de cara a parametrizarlas algun día.
genkwh_investments.py
cli para gestionar las inversiones