Bitácora de proyecto I

Avance : Continuamos con la creación del SPGeneraciónReconexiones y se actualizan los CRUDS (que no son de propiedad, registren sus cambios en la bitácora). Problemas : Debido a que tienen lógica propia, mejor elegimos separar los pagos de tipo reconexión de los otros. Asimismo, encontramos el problema de que al existir el trigger de la tabla propiedad los nuevos cambios que se generan desde el portal web quedan con los valores alambrados. Solución : Se procede a crear un SPGenearReconexiones que recibe como parámetros una tabla de los pagos procesados en el día de tipo reconoexión, así como la fecha actual. Genera la misma lógica que en el generador de pagos. Sin embargo, al ser una reconexión se asume que todos los recibos están vencidos y se generan los intereses moratorios correspondientes de cada uno. Luego, se procede a reconectar a la propiedad al agua y se inserta una reconexión en la tabla Reconecta. Posteriormente editamos los CRUDS que se utilizan en el portal web (propietar...

Avance : Se crearon los SP's GenerarPagos y GenerarCortes. Problemas : No se encontraron problemas en este avance. Sin embargo, dado a la complicación que podría causar, se deciden separar los pagos de los recibos de agua tipo Reconexión.  Solución : Para estos SP's fue un poco más sencilla su implimentación, en gran parte a todo el conocimiento que hemos adquirido en la realización de los SP anteriores. Para el generador de pagos, primeramente se pasa como parámetro una tabla con los pagos de ese día (según la simulación) y además, la fecha correspondiente a ese día. Seguidamente, se evalúa cada uno de pagos a nivel individual y dado su carácter retroactivo, se procede a pagar todos los recibos pendientes, que tenga una propiedad, de un determinado tipo de concepto de cobro. Luego se revisa si el recibo se encuentra vencido (basado en su fecha de vencimiento comparado con la fecha de pago) y se emite el concepto de cobro interés moratorio del recibo , generando a su vez un nue...

Avance : Continuando con el desarrollo del SP anterior, fue necesaria la creación de un trigger que registrara los cambios realizado en la tabla Propiedad. Además realizamos el SP GenerarRecibos. Problemas : Desconocíamos como funcionaban los triggers en SQL Server. Además, tuvimos que investigar como genera un JSON para que fuera almacenado tanto en Antes como en Después.  Solución : Luego de una investigación exhaustiva entendimos el funcionamiento de los triggers. Básicamente solo es de indicar el tipo de CRUD que lo activa (en nuestro caso INSERT y UPDATE), luego especificar la serie de instrucciones que debe realizar. En este caso solamente era una inserción en la tabla BitácoraCambios, la cual recibía como parámetros alambrados el usuario y el ip (debido a que es una simulación). Asimismo nos tomó tiempo comprender que cuando se activa de forma masiva, lo hace en forma de batches o grupos de 8 elementos. Por lo tanto, ideamos una forma de iterar sobre el batch y ejecutar el ...

Avance : Comenzamos con la creación del SP GenerarTransConsumoAgua y GenerarCambiosValor propiedad debido a que son etiquetas que ya vienen específicadas en el documento XML. Problemas : Necesitábamos una forma en la cual poder enviar las etiquetas que se leían del XML. Ya que se debía procesar una por una. No sabíamos como crear un tipo de datos de SQL y que se necesitaba para utilizar tablas como parámetros. Solución : Para solucionar el problema que representaba la comunicación entre XML y SP (ya que nos quedaba más sencillo hacerlo interativo y procesar una por una), recurrimos a utilizar una variable tabla que pudiéramos pasarle como párametro a ambos SP's. Esta idea derivó en tener que aprender a declara un  tipo de  dato.Ya que no se pueden enviar variables tablas de tipo genéricos. Procedimos a declara un tipo de dato para cada tipo de etiqueta, luego aprovechamos el recorrido interativo que va realizando la simulación día a día para cargar en una variable tabla (de un...

Avance : Iniciamos con la construcción de la base de datos, actualizando las tablas que ya teníamos y generando las tablas nuevas. Modificamos el esquema de la base de datos original, agregándole las tablas de Recibo, Comprobante de Pago, Cortes, Reconexión, Reconecta, BitácoraCambios, TipoEntidad, TranscConsumo, TipoTransacConsumo. En todas estás se generaron los inserts (ya que eran indispensables para su  utilización a lo largo del desarrollo del proyecto) y en algunas se crearon otro tipos de CRUDS como Select, Update y Delete. En las tablas que se tuvieron que actualizar se encuentra la tabla propiedad. En la cual se agregan dos columnas adicionales (ConsumoAcumM3 y UltimoReciboM3). Estas columnas ayudan a realizar la lógica de transacciones de consumo y recibos más fácilmente. Problemas :   Teníamos de forma incorrecta la relación entre Comprobante Pago y Recibo. Además, teníamos problemas en la inserción de la tabla Recibos y BitacoraCambios. Solución : Procedimos a cor...

Avance : Ya con todas las dudas aclaradas, los catálogos hechos y los datos pasados arreglados, procedimos a crear el programa que genera los nuevos datos. En este se deben establecer los criterios para colocar las etiquetas en diferentes partes del XML. Problemas : Nos encontramos con problemas a la hora de diseñar el programa, ya que necesitábamos validar que los pagos existieran sobre propiedades que ya estuvieran insertadas y que para determinada fecha ya tuvieran un concepto de cobro determinado asociado a ella. Asimismo, se debe considerar que las transacciones de agua se realicen sobre propiedades que tienen concepto de agua asociad; lo mismo sucede con los pagos de reconexión.  Solución : Para solucionar los problemas anteriormente descritos procedimos a utilizar listas donde filtrábamos las propiedades con las características específicas que requeríamos, y mediante la utilización de un ciclo for se iban incorporando a las listas las propiedades que cumplían las característ...

Avance : Tuvimos una reunión con el profesor luego de la clase de las 7:30 am. En dicha reunión aclaramos diversas dudas que teníamos respecto a la implementación de las etiquetas xml y sus atributos. Problemas : Malinterpretamos la etiqueta de pagos. En un inicio pensábamos que un pago correspondía a un solo recibo. Sin embargo, la interpretación del profesor es una activación retroactiva de los pagos. En la cual una etiqueta pago,  con un determinado tipo de concepto de cobro y número de finca, activa el pago el todos los recibos pendientes emitidos previamente a una determinada fecha que corresponda al mismo tipo de concepto de cobro sobre una propiedad. Asimismo llegamos a un acuerdo con el profesor sobre crear una única etiqueta transConsumo , la cual iba a contener un atributo que se encarga de su categorización (lectura mensual, reclamo o debito y ajuste o crédito). De igual forma conversamos con el profe sobre un error en los estados de recibo (hacía falta el estado 2). Sol...

Avance : Empezamos a desarrollar el programa para generar los nuevos datos y nos empiezan a surgir dudas por lo que agendamos una reunión con el profesor para el 17 de junio del 2020.  Problemas : Nos dimos cuenta que debemos generar nuevos catálogos que se utilizan en la segunda entrega del proyecto. Revisando los datos originales notamos problemas que si bien, no afectaban en las primera entrega del proyecto, para efectos de esta segunda entrega nos podrían complicar las cosas  Solución : Primeramente se procedió a arreglar los datos originales. Se le agregó a los usuarios su respectiva categorización entre administrador y cliente. Luego, se corrigen diversos atributos en los conceptos de cobro (algunos que eran fijos aparecían como impuesto y viceversa, había un concepto de cobro duplicado, además para simplificar la generación de recibos se colocan todos los cobros comunes como recurrentes). Se procede a añadir los conceptos de cobro impuesto moratorio y reconexión . Fin...

Avance : Como nos fueron asignados los datos empezamos a desarrollarlos antes de comenzar con el desarrollo de la segunda entrega de la base. Para esta segunda parte del proyecto era necesario que se realizaran las etiquetas para el registro de las transacciones de agua (y sus diferentes tipos), las de pago de los servicios y las etiquetas para indicar los cambios realizados a una propiedad (específicamente cambios de valor en el monto del inmueble). Problemas : Nos vimos  en el dilema de si realizar los datos manualmente o si desarrollar un programa con el propósito de alterar el XML original de operaciones y que agregara las nuevas etiquetas. Por un lado hacerlo manualmente implicaba un gasto importante de tiempo y éramos propensos a cometer errores humanos que repercutarían en el desarrollo del proyecto nuestro y el de nuestros compañeros. Por otro lado, para la realización del programa debíamos considerar muchos factores y restricciones a la hora de colocar una etiqueta en un d...

Se inicia la segunda parte de la tarea programada Avance : Revisión de la segunda tarea programada para entender los requerimientos y hacer consulta al profesor. La llamada se efectuó exitosamente y logramos resolver las dudas del momento Problemas : Nuestras dudas fueron básicamente  qué tabla me despliega los conceptos o si debería ser los recibos, modelado completo para observar las otras relaciones y qué estructura debe tener el JSON de cambios.  Solución : Solamente agregar las tablas nuevas y sus respesctivos atributos. Estructura JSON : Todos como estaban antes y todos después.  IP es en capa lógica y se envía como parametro. Mostrar Propiedades y sus recibos pagados y pendientes Ajustes por errores al ingreso de datos para aumentar  Recibo Anulado en vez de cancelado string en estados de recibos con la mod de arriba Somos el grupo de los datos Mejora en el ejemplo del calculo del monto del movimiento de consumo de agua (diferencia entre lectura del medidor y ...

Descripción : La página simula un portal web amigable con el usuario para una municipalidad (gobierno local en Costa Rica). Desde él se pueden consultar propiedades registradas, propietarios (incluyendo de tipo jurídico), usuarios registrados en el portal y conceptos de cobro sobre los servicios municipales.  Si se utiliza el modo administrador es posible alterar las diversas relaciones entre los objetos del portal, por ejemplo: Añadir propiedades, propietarios, usuarios y conceptos de cobro; modificar los diferentes propietarios de cierta propiedad, los usuarios que tienen derecho consultar la propiedad y los conceptos de cobro que van a ser asociados a los diferentes bienes inmuebles.  Características: Utilización de CRUD's para realizar las diferentes acciones de la página web.  Scripts para carga desde archivos XML tipo simulación. Manejo de errores por medio de códigos personalizados. Validaciones en capa de datos y en capa lógica para evitar al ...

Algunas imágenes del Portal web para la Municipalidad Vista de Propietarios Vista de Propietarios Jurídicos Vista de Usuarios Insertar Propietario Propietarios de una propiedad Vista de Propiedades de un propietario Actualización de datos para un propietario 

Total horas laboradas por persona: Se trabajaron 57 horas por parte de Jose Pablo Salazar y un total de 54 horas por parte de Esteban Salas.  La diferencia de horas debe a que Jose tenía que realizar las pruebas entre base y portal web. Debido a que ambos carecíamos de experiencia en desarrollo web, se requirió una mayor inversión de tiempo en cualquier cambio que se le quisiera hacer a la página web. Métricas de Github: Link para clonar repositorio: https://github.com/joseSalazar4/bases-datos.git Link de la página:   https://github.com/joseSalazar4/bases-datos Desarrollo de la página web medido en commits por días del mes. Días de semana más productivos. Métricas de la base:  Las versiones de la base se encuentran en el mismo repositorio de Github. Esto se logró subiendo los scripts que genera SSMS para la creación de la base completa y de los stored procedures . Se adjuntan de igual forma las credenciales para la co...