Proyecto de Procesamiento de Recibos de Luz

Alcance

Se requiere de un sistema que pueda ser capaz de leer los archivos de recibos de luz almacenados
en un bucket y solo tomará en cuenta cuando el cliente del recibo sea IPT (ruc 20602982174 o
nombre Internet Para Todos).

El usuario final dejara los archivos por winscp en un bucket de GCP donde debe existir una
carpeta por cada compañía eléctrica y dentro de estas se colocarán los archivos del mes que
luego de procesarse además de insertarse en la base de datos, debe generar un resumen csv que
contendrá los datos de los archivos dejados en cada carpeta con el detalle de la ejecución de
estos y de los archivos hijos resultantes y el contenido de los recibos del mes al que corresponde.

Debe existir una tabla de constantes donde se parametrice toda la aplicación de acuerdo con el
ambiente en que se encuentre y estas deben estar habilitadas por defecto, pero pueden ser
desactivadas para escoger entre una u otra.

Se debe entregar configurado 20 compañías eléctricas de las cuales algunas cuentan con dos
formatos diferentes. Se tienen alrededor de 2200 recibos de luz repartidos entre las 20
compañías eléctricas y el consumo del procesamiento no debe exceder los 200 dólares mensuales
en total por todos los servicios involucrados en las ejecuciones para este proyecto sobre la nube
de GCP.
El 98% de recibos se encuentra en los 14 primeros elementos de la siguiente lista de compañías
eléctricas. Las 10 primeras compañías eléctricas de la lista deben llegar a un 100% de eficiencia,
el resto debería superar el 95% de efectividad. Esto sumada a la trazabilidad completa del ciclo
de vida del procesamiento de recibos y todos los entregables completos y validados debería ser
un buen indicador de éxito.

EMPRESA ENERGIA RUC

ELECTROCENTRO S.A. 20129646099
ELECTRO SUR ESTE S.A.A. (ELSE) 20116544289
ELECTRO ORIENTE S.A. (ELOR) 20103795631
HIDRANDINA S.A. 20132023540
ELECTRONOROESTE SA (ENOSA) 20102708394
ADINELSA S.A. 20425809882
ELECTRO PUNO S.A.A. 20405479592
ELECTRONORTE ENSA 20103117560
ELECTRO DUNAS S.A.A 20106156400
SEAL 20100188628
ELECTRO TOCACHE S.A. 20143611893
ELECTRO UCAYALI S.A. 20232236273
LUZ DEL SUR S.A.A. 20331898008
PRESIDENCIA REG.PROYECTO ESP.CHAVIMOCHIC 20156058719
COELVISAC (CONSORCIO ELECTRICO DE VILLACURI SAC) 20178344952
EMSEU S.A.C. 20288529087
ENEL 20269985900
ESEMPAT 20530648339
ELECTRO SAN GABAN (MUNICIPALIDAD DISTRITAL DE SAN GABAN) 20195270938
EMSEMSA 20177698122

Con la lectura de estos archivos se espera que automáticamente podamos contar con
información de (resumen a continuación, extendida en la sección de Diagrama referencial):

• Compañías de Luz con las que trabajamos (debe contar con mantenimiento)
o RUC de Empresa de Luz
o Dirección de Empresa de Luz
o Nro de Cuenta *llenado manualmente o mediante algún proceso masivo
• Suministros (debe contar con mantenimiento, un suministro pertenece a una compañia)
o Nro de Suministro
o Medidor
o Potencia
o Tarifa
o Dirección del Medidor
o Dpto/Prov/Distrito
o Identificador del sitio *llenado manualmente o mediante algún proceso masivo
para relacionar el sitio y el suministro
• Se debe almacenar datos del recibo tales como
o Energía a facturar
o Nro de Recibo
 o Fecha de Emisión
o Fecha de Vencimiento
o Fecha de Corte
o Total, Facturado

La información de compañías y suministros deben ser insertados o actualizados y relacionados

al momento de realizar las lecturas, no borrando el nro de cuenta e identificador del sitio en caso
este ya se haya configurado manualmente.

La primera validación sobre el archivo inicial debe ser el verificar que el recibo pertenezca al RUC
o nombre de IPT para continuar con la lectura.

Se debe configurar y validar que los recibos deban contar con nro de suministro, nro de recibo,
total, fecha de emisión, fecha de corte, fecha de vencimiento, como campos obligatorios y
parametrizables en la tabla de constantes.

Debe existir relación de tablas entre las compañías, formatos, suministros, archivos padres,
archivos hijos, recibos y las tablas deben contar con campos de auditoría que permitan identificar
si las modificaciones fueron hechas por la web o mediante el proceso automático, quien lo hizo,
cuando se creó y se modificó el registro.

Se debe realizar una lectura masiva de los archivos pdf que de acuerdo con las características del
archivo lean el contenido ya que los archivos pueden venir con:

o Recibos con una página por archivo o con muchas páginas por archivo
o Páginas en horizontal
o Páginas en vertical
o Páginas con recibos girados
o Páginas con un recibo por pagina
o Páginas con más de un recibo por pagina
o Páginas con imágenes escaneadas de uno o más recibos

Cada recibo procesado debe generar un nuevo archivo pdf con el contenido correspondiente del
recibo de luz y se debe grabar su relación para mediante el registro en base de datos ubicar el
archivo. Ejem: Un Archivo pdf X tiene 10 recibos dentro, el proceso corta los 10 recibos en
archivos independientes que identifican cada uno a un solo recibo.

Debe existir tablas que permitan hacer trazabilidad a todas las ejecuciones así estas resulten
fallidas donde se podrá encontrar toda la información necesaria para determinar que sucedió
con el archivo que se procesó, cuando ocurrió, que ocurrió y donde encontrar el archivo base y el
archivo independiente.

De tener problemas con la lectura de algún archivo, se debe almacenar el registro del proceso
para saber en qué fallo y solicitar un archivo legible o darnos cuenta si el formato del archivo
cambio o debemos registrar manualmente este recibo.

Cada recibo debe ser leído y almacenado en una base de datos.

El procesamiento automático debe tener una constante de encendido para poder apagarlo a
voluntad como contingencia y debe contar con una constante que indique la cantidad de veces
que se ejecutara durante el día y/o las horas de ejecución por día separados por coma.
Al termino de cada procesamiento en el bucket del usuario final debe escribirse o actualizarse un
archivo csv (Ejem: archivo procesados_092022.csv como en la primera imagen del winscp) con
el resultado de todos los archivos procesados (originales/padres) en el mes cuyo contenido debe
ser tanto de procesos exitosos como erróneos con el detalle de cada proceso de cada archivo
resultante (hijos) y mostrando el detalle de cada recibo/boleta que se consiguió leer.

Debe existir una web creada en Django con bd en Mysql e integrada con el Portal de IPT, podemos
proporcionar la base del proyecto donde se trabajará la web que será un módulo dentro del
Portal, para manejar un estándar respecto a otros desarrollos que venimos realizando.

Esta web a la que por ahora llamaremos “Recibos Suministros IPT” debe permitir realizar los
mantenimientos de:

• Constantes (datos requeridos para parametrizar la aplicación)

• Compañías eléctricas (registro individual o masivo)
• Formatos (configuración integrada al proceso de lectura de archivos)
• El sistema debe ser capaz de poder configurar una nueva compañía eléctrica con un
nuevo formato de recibo mediante el cual se debe conocer las secciones de donde
extraerá la información en cada tipo de recibo por compañía eléctrica.
• Suministros (registro individual o masivo).
• Recibos de Luz podrán ser editados manualmente luego del procesamiento en caso se
requieran limpiar o afinar ciertos datos que no llegaron a obtener el dato real, esto podrá
realizarse mediante un listado que permita ir revisando los recibos y editándolos uno por
uno o en bloque.

Se debe poder monitorear/consultar el histórico filtrado por año, mes y compañías de los
archivos que se fueron subidos por winscp por el usuario y se debería ver las siguientes opciones.

• Se debe contar con una opción de Archivos Subidos donde debe aparecer un listado de
los archivos que fueron subidos por el usuario y que debe estar almacenado en la tabla
archivos, donde podría descargarme el archivo que se subió y ver el detalle de los
archivos resultantes generados por el proceso, cada uno con el indicador de si está en
proceso o ya termino.
• Se debe poder ver el detalle de cada recibo grabado en la base de datos.
• Esta opción anterior debe permitir una ejecución manual en caso el archivo haya fallado,
incluso debería conocer desde aquí sobre el error ocurrido.
• Se debe poder exportar a Excel el listado mostrado de los archivos que fueron procesados
y los que no, con mensaje del problema de ser el caso.
• Se debe poder descargar comprimidos en formato zip los archivos especificados en el
filtro de búsqueda.

Se debe exponer un endpoint donde podamos consultar los recibos procesados correctamente
en un rango de fecha determinado con una estructura cabecera y detalle con campos como ruc
compañía eléctrica, razón social, banco, número de cuenta, número cci, nro de suministro,
medidor, potencia, tarifa, código de sitio, nombre de estación, categoría, ubigeo, nro de recibo,
kwh a facturar, fecha de recibo, fecha de corte, fecha de vencimiento, total facturado.

Además, en la cabecera debe considerarse la cantidad total de recibos procesados, leídos

correctamente, con error y debe ir lo común como son los campos de la compañía y en el detalle
solo los campos de cada suministro con los campos del recibo y los registros que fueron leídos
correctamente.
Diagrama referencial
Detalles del diagrama ER referencial

Este resumen busca concientizar sobre lo necesario que es tener bien dimensionadas las tablas
ya que en una POC no se tomo en cuenta la trazabilidad que debe existir, este diagrama puede
mejorarse, pero como mínimo se espera que cumpla con las tablas ya indicadas.

En general las fechas de creación y modificación deben ser campos default que graben las fechas
en formato datetime y cada que se actualice la tabla el dato a afectarse solamente sería la fecha
de modificación.

Tabla: Constante

Aquí se almacenarán las constantes necesarias para que el

sistema sea parametrizable como puede ser el ruc de IPT, el
nombre de la empresa o posibles coincidencias divididos con
un separador.

Se debe considerar un id, clave, valor y grupo en caso se

requiera agrupar constantes como puede ser el caso de los
campos obligatorios en los formatos, una descripción por si se
requiere y fechas de auditoría.

Tabla: CompañiaElectrica

Se debe considerar un id, ruc, razonsocial, direccion obtenidos

de los recibos de forma automática, si existe contenido debería
actualizarse la razonsocial, dirección y fecha de modificación.

Los campos banco, nro_cuenta, nro_cci hacen referencia a un

campo que podra actualizarse posteriormente.

El campo nom_carpeta debe ser el nombre de la carpeta al cual

se haga referencia en el bucket donde el usuario final sube los
archivos y si el flag fuera verdadero esa carpeta siempre debe
crearse en caso se elimine.

El campo usr_modificador hace referencia al usuario que

modifica el registro, si el registro es modificado por la web
debe grabarse el correo de la persona que modifico, si fuera mediante el proceso de documentAI
entonces debe grabarse un default con la palabra documentAI.

El campo procesar_documentAI hace referencia a si la compañia electrica registrada estara

presente dentro de las compañias que deben procesarse mediante DocumentAI, default true.
Solo debe considerarse en el proceso de creación de carpetas y procesamiento automático y
manual a las compañias que tengan el flag de procesar_documentAI en true.

Si la lectura del archivo que le pertenece a una compañía eléctrica falla, debe grabarse todos los
archivos correspondientes en una carpeta que respete la estructura de (/AÑO/MES/NOMBRE
CARPETA de tabla CompañiaElectrica/ERROR_LOGS/).
 Tabla: Formato

Se debe considerar un id, una relación con la tabla

CompaniaElectrica mediante la llave foranea
id_compania considerando que una compañia electrica
puede tener mas de un formato.

Además, se debe considerar un código para cada formato

para así distinguirlos en subcarpetas dentro del bucket de
archivos originales procesados (/AÑO/MES/NOMBRE
CARPETA de tabla CompañiaElectrica/CODIGO de tabla
Formato/).

El campo formato_documentAI debe almacenar un JSON

formato de lectura proporcionado por el documentAI que fue obtenido al momento de configurar
el formato inicial desde la web.

El campo formato validaciones debe almacenar un JSON donde figuraran todos los campos a
obtener y la forma de obtenerlos y/o limpiarlos, las constantes que pertenecen al grupo de
campos requeridos en todos los formatos deben estar asociados a los campos que aquí aparecen.

Tabla: Suministro

Se debe considerar un id, id_compania como llave

foranea de la compañia a la que pertenece, medidor,
potencia, tarifa, dirección, departamento, provincia,
distrito, centro_poblado, siempre que los campos existan
en el formato.

Los campos cod_sitio, nom_estacion, categoria, ubigeo,

latitud, longitud, son campos que se actualizarán
mediante otro proceso pero deben ser considerados.

El campo usr_modificador debe grabar el correo de quien

lo modifica en caso sea por la web y tener un default con
la palabra documentAI si el que escribe es el proceso
automático.
 Tabla: ReciboLuz

Se debe considerar un id, id_suministro, id_compania,

id_formato relacionados a las tablas foraneas con la
integridad referencial correspondiente.

Se debe grabar el num_recibo, kwh_facturar (número

limpio), fecha_emisión, fecha_vencimiento, fecha_corte,
total_facturado obtenidos del recibo pdf único procesado
asociado al campo id_archivo que hace referencia a un
archivo independiente que ya fue rotado y cortado de la
tabla ArchivoHijo.

El campo lectura_exitosa debe indicar si finalmente el recibo

fue leido correctamente

El campo usr_modificador debe grabar el correo de quien lo

modifica en caso sea por la web por si se desea rectificar
algún dato manualmente de lo que ya se cargó y tener un
default con la palabra documentAI cuando el proceso
automático inserte.

Los campos pago_realizado, total_pagado, observacion,

fecha_pago, son campos que se actualizarán mediante otro
proceso pero deben ser considerados.

Tabla: ArchivoPadre

Se debe considerar un id, id_formato (siempre que se

identifique cual es el formato que le corresponde debería
almacenarse para tomar la ruta del formato como la
referencia, de no tener un formato relacionado el proceso
para este archivo se corta y estos archivos deben moverse a
una carpeta SIN FORMATO e inmediatamente marcar el
campo archivo_error en true indicando el error_descripcion.
Ejem: El archivo sin formato deberia colocarse en
(/AÑO/MES/NOMBRE CARPETA de tabla
CompañiaElectrica/SIN FORMATO/), ruta_completa (con
ruta_formato de la tabla Formato y que debe incluir el
nombre de archivo que fue cargado por el usuario), ruta
(similar al anterior pero sin nombre del archivo),
nombre_original (nombre del archivo pdf original sin ruta),
nombre_cambiado (CODIGO de la tabla Formato relacionado
al id_formato concatenado al símbolo subrayado con la fecha
de proceso en formato DDMMYYYY concatenado al símbolo subrayado con el id. Ejem:
/2022/09/ADINELSA/ADINELSA_MAYORES/PADRES/adinelsa_mayores_20220910_1.pdf),
nro_recibos (cantidad de recibos encontrados dentro de este recibo, default 0), nro_intentos
(cantidad de intentos realizados para el procesamiento del archivo padre ya que hay que
considerar que podemos reprocesarlo si el usuario lo vuelve a colocar en el bucket inicial o si lo
ejecutamos de forma manual, default 0), nro_exitos (cuantos de sus archivos hijos cortados se
leyeron exitosamente, default 0), nro_fracasos (cuantos de sus archivos hijos cortados cayeron
en error, default 0), archivo_girado (indica si el archivo tuvo que ser girado para orientarlo de
forma legible), archivo_enproceso (que debe ser un default true que debe actualizarse cuando el
archivo padre haya terminado de ser girado y cortado en sus correspondientes hijos),
archivo_error (que indica si el proceso de lectura del archivo padre dio error por algún motivo),
error_descripcion (descripción del error en caso se de), fecha_inicioproceso (cuando se inicio el
procesamiento del archivo padre), fecha_finproceso (cuando se termino con el procesamiento
del archivo padre).

Tabla: ArchivoHijo

Se debe considerar id, id_padre en relación al archivo que

origino este archivo, nombre (que debe ser la
concatenación del nombre_cambiado de ArchivoPadre
más símbolo de subrayado concatenado con el id de este
archivo hijo), la ruta debe ser la ruta donde se está
grabando al archivo hijo resultante que es un único
archivo de donde se esta obteniendo toda la información
para registrarla en ReciboLuz (/AÑO/MES/NOMBRE
CARPETA de tabla CompañiaElectrica/CODIGO de tabla
Formato/HIJOS/), lectura_exitosa indica si la lectura final
del archivo hijo fue satisfactoria o no, lectura_mensaje
indica el mensaje de error en caso exista o un OK,
contenido indica el JSON del contenido del archivo,
archivo_enproceso indica si el proceso se está
ejecutando o no y es default true al insertarse el registro, fecha_iniciolectura es la fecha y hora
de cuando se inició la lectura de los campos en el archivo y fecha_terminolectura es la fecha y
hora de cuando termino el proceso de lectura.
Pasos y Ejemplos:

0. Teniendo las Constantes de buckets configurados, campos obligatorios, compañias registradas

junto con sus formatos desde la web.

1. El usuario coloca un archivo llamado archivo1.pdf en la carpeta /ADINELSA de una compañía

eléctrica en el bucket inicial.

2. El proceso automático copia el archivo y se lo lleva a una carpeta con el mismo nombre al
bucket de procesados.

3. El proceso automático mediante un flujo interno gira el archivo e intenta detectar el formato
al cual pertenece.

3.1 Si el proceso pudo detectar a que formato pertenece, mueve el archivo original hacia la
carpeta PADRES dentro de la carpeta del formato correspondiente. Ejem:
/ADINELSA/ADINELSA_MENORES/PADRES/, siendo la ruta previa a /PADRES/ un valor tomado
de la ruta_formato de la tabla Formato.

3.1.1 El nombre del archivo padre debe ser renombrado por uno que pueda ser mejor ubicado y
que se indicó previamente en la tabla ArchivoPadre, los valores de los nombres originales y el
nombre nuevo deben ser almacenados en la tabla de ArchivoPadre.

3.2 Si el proceso no pudo detectar a que formato pertenece entonces debe mover el archivo a
una ruta similar a /2022/09/ADINELSA/SIN FORMATO/

4. Si ya se tiene el archivo padre ubicado en la carpeta /PADRES/ debe cortarse el archivo pdf en
sus correspondientes hijos para tener un recibo por archivo pdf y debe colocarlos en la ruta que
corresponda. Ejem: /ADINELSA/ADINELSA_MENORES/HIJOS/, siendo la ruta previa a /HIJOS/ un
valor tomado de la ruta_formato de la tabla Formato.

4.1 El proceso de lectura de cada archivo hijo se va registrando en la tabla ArchivoHijo.

4.2 Si el proceso de lectura de algún archivo falla deben indicarse en la misma tabla sobre la
falla, dar una pista del error, guardando el contenido JSON y terminando el proceso de lectura,
continuando con el siguiente archivo hijo y contabilizando el éxito o el error en la tabla padre.

4.3 Toda la trazabilidad de las ejecuciones debe grabarse en base de datos, si un archivo fallo
debo tener un monitor que me permita ejecutar el proceso manual de forma masiva (sin importar
la hora de ejecución configurada en constantes) o de manera individual seleccionando el archivo
que quiero reprocesar lo cual sumaria 1 a nro_intentos en la tabla ArchivosPadre.

5. Al final del proceso se genera un archivo CSV con todo el contenido de los archivos procesados
que incluyen todos los archivos leídos en el mes en curso considerando ejecuciones correctas e
incorrectas.

6. Se debe remover de la carpeta del usuario final los archivos que si pasaron de forma
satisfactoria, dejando los archivos pdf errados y sin renombrar en la carpeta /ERROR_LOGS/ del
bucket del usuario (/AÑO/MES/NOMBRE CARPETA de tabla CompañiaElectrica/ERROR_LOGS/)