Comienzo de la segunda parte

Segundo Blog para resumir entradas anteriores y modificaciones del proyecto.

<!-- FECHA 16/06/2020 -->

Inicio de la segunda entrega de proyecto #1: 4h 30min

Se hacen cambios en la base de datos para poder tener todas las correcciones bien de acuerdo a las correcciones que se hicieron el dia de la entraga de la parte anterior. Se empieza a trabajar con base en el segundo enunciado (version casi final)

Y se hacen las tablas nuevas que se necesitan para el proyecto. En esta parte no se requiere mucho tiempo dado que las tablas y el diagrama ya fueron discutidos por el profesor en clases. 

Toma aproximadamente 4.5 horas en total, aunque hubo un error de como se hizo la herencia en una de las tablas nuevas.

<!-- FECHA 17/06/2020 -->

Bitacora #1: 4 horas

Lo mas dificil para esta parte fue aprender a generar los json. Lo que se hizo fue estudiar el formato json y esto segun el estimado de github se tardo 1h. En la siguiente sesion se busco en PaginaJSON. 

El mismo dia se hizo otro commir donde se termino los json de propietario, se logro gracias a la pagina de microsoft que explciaba como generar json con AUTO. Tuvo una duracion de 3 horas.

<!-- FECHA 18/06/2020 -->

Bitacora #2: 2 horas

Se hizo una actualizacion del CRUD de propietario para la insercion de propietarios y de biitacora. En este caso no se acudio a ninguna pagina web para los cambios.

Tuvo una duracion de 2 horas.

<!-- FECHA 25/06/2020 -->

Trigger #1: 4horas
Se hacen los triggers masivos en la parte de la propiedades y se tarda 3 horas. Tambien se hace un insert no masivo de la propiedades se tarda 2 horas. La tarea dice que hay que hacer un proceso masivo y era ese pero no sirvio. Un insert masivo con trigger coge elementos de 8 en 8 entonces no inserta todos sin recorrer la tabla de 8 elementos haciendolo iterativo o en el trigger o en la insercion de datos.

Declaracion de variables tipo tabla para hacer el proceso masivo. Se logra con la ayuda de una amigo.

Se comenta con profe el problema y se deja iterativo pero como se trabajo masivo aprendimos a hacer procedimientos masivos que era parte del proposito de esta segunda etapa.

Se hace un SP_Recibo para insertar recibos de pago se dura unas 2 horas. Luego se hace un SP_GenerarRecibos usando SPI_Recibo con una iteracio masica de datos se dura 2 horas en la idea y 1 hora programando. 

Se hace el update masico de las propiedades implementado en un xml de prueba porque todavia no estaba el final. 1 hora

CASOS DE PRUEBA.


<!-- FECHA 27/06/2020 -->
Trigger #2 (Arreglo): 3 horas

Se hace en el XML un while para las propiedad en vez de el insert masivo. Se hacen pruebas y tiene una duracion de 1 hora.

==========================
Break para el curso de algoritmos.

==========================

Algunos companeros hacen consultas como que no se pueden hacer FK nulos, en nuestor caso se intento (2h), pero al final con la ultima version se decidio hacer uma tabla intermedia.

Hacen la primera version del XML y luego lo corrigen el mismo dia.

<!-- FECHA 05/07/2020 -->

Error handling: 15min
Se agregan nuevos codigos de error correspondientes a los codigos nuevos de los SP (15 min)

Recibo y Comprobante: 3h
Con la ayuda de los companeros se consulta y crea la tabla Recibo_por_ComprobantePago que es la tabla que elimina el nulo en recibo llamada Comprobante de pago que era un FK a comprobante de pago. (2 horas)

Se hacen correcciones minimas en las tablas para poder aplicar las funcionalidades nuevas (1 hora).

Intereses Moratorios: 20min
Se corrige el insert de los intereses moratorios en la tabla de Concepto de Cobro. Se corrige el insert de elementos de porcentaje en la tabla de Concepto de Cobro.
(20 min)

<!-- FECHA 06/07/2020 -->

Movimineto de Agua: 3h

Se hace la parte de los movimientos de ajuste y movimeintos de Agua. (3 horas)

Se hace un SP_ConsumoMovimiento, no hay mayor problema con esta parte. Se hace el SPI_Movimiento de agua al principio el documento tenia dos tipos de datos Ajuste y Consumo. Despues de hablar y aclarar con los companeros del XML entonces se cambio a que habia un id que representaba que tipo de movimiento es. Podia ser (1,2).


<!-- FECHA 07/07/2020 -->
Recibos Corte: 1h 30min

Se hace los GenerarRecibos_Corte (30 min) donde se van a insertar por una fecha los recibos corte de porpiedades que no han pagado agua en una fecha dada.

Luego se hace un SPI_ReciboReconexion (1 h) donde primer inserta un recibo de reconexion utilizando un SPI_Recibo con un tipo fijado (10 tipo reconexion) y luego hace una herencia con reconexion para finalmente unirla a un recibo de corte.

Este proceso no fue dificil pero tenia muchos pasos distintos y por eso se duro probando que todo funcionara. 

<!-- FECHA 08/07/2020 -->

Intereses Moratorios: 4h

Se consulta a los companeros del XML como es que sirve los intereses moratorios. Luego se hace la idea de como calcular el monto y se le pregunta al profesor sobre las especificaciones de los intereses moratorios. (1 hora)

Se hace un cambio en Conceptos_Cobro y luego se tiene el tipo Interes Moratorio junto al calculo del monto. (1 hora)

Se hace el metodo SPI_ReciboIntereses  (2 horas) es un insert de intereses pero lo dificil fue calcular el monto basado en la cantidad de dias que habia expirado. Se busca la funcion DATEDIFF() en pagina

Pago de Recibos y Comprobante Pago:  3h 30min

Se hace pero el SPI_Comprobante de la tabla intermedia entre el Recibo y el Comprobante de Pago luego se hace que si el recibo tiene la misma fecha y monto entonces no se genere un nuevo comprobante para evitar datos repetitivos. (30 min) 

Nota: Se le pregunto al profe (10/07/2020) si estaba bien hacer eso o el comprobante de pago es necesario generar datos de comprobante repetidos por ser de otras propiedades. Despues de la consulta se considero que en efecto la tabla intermedia ayudaba a diferenciar la informacion entonces no habia necesidad de duplicarla. 

"Si las propiedades son diferentes, no hay razon para que se duplique informacion."

"Asi es, las FK a propiedades o recibos deben tener algo diferente que los hacen unicos"

 

Se hace el pagado multiple de recibos que rexibe un numero de finca un tipo de recibo y finalmente una fecha en la que se desea pagar el recibo. (3 horas) Este es probablemente el metodo mas dificil de toda la progra que vale un 26 por ciento. La mayor complicacion fue ordenar las pasos del algoritmos que son los siguientes:

- Generar una tabla temporal con los recibos del dia (@Recibos del dia) 
- Generar por cada recibo y analizar si se debe pagar un interes
- Tomar la lista de @PagarDia con recibos tanto de interes como de tipo que el usuario quiere pagar y pagarlos (cambiar de estado 0 a 1)
- Generar un comprobante con el monto acumulado por esos recibos.

Nota: Dado que la idea anterior era pagar el ultimo recibo y luego cambio a pagar todos se hizo dificil entender que hacer en primera instancia pero con un poco de consulta con los companeros y el profesor se aclaro. 

Lo mas dificil fue probar que las cosas funcionaban dado que no se tenia punto de comparacion y generar casos especificos es bastante tardado y dificultoso.


Recibos de Reconexion: 1h

Por ultimo se trabajaron los recibos de reconexion y esto fue porque para generar los recibos de reconexion no solo habia que saber cuales propiedades tenian recibos de corte no pagados sino que tambien habia que pagarlos y luego reconectarlos. No hay una reconexion en SP se hace junto al pagado. (1 hora)

Chachadosidad : Es una chanchada que a la hora de pagar tambien se reconecten porque no es modular. Pero es que siempre que se paga una reconexion se va a tener que reconectar entonces queda mas comodo hacerlo en el mismo metodo ademas economisa tiempo. No esta mal hecho solamente no es la mejor manera. 

<!-- FECHA 9/07/2020 -->

XML Pagos: 4h

Por ultimo se hacen pruebas y corridas de la carga de datos en el xml con la parte de pago implementada. El proceso de insecion pasa de 40 seg a unos 3 min de duracion y se hacen varias prubas para ver la consistencia y arreglar errores y quitar prints innecesarios. 4h

<!-- FECHA 10/07/2020 -->

Fixes: 4h

Se hacen diversos fixes despues de probar en distintas tablas algunos SP que tenian errores dado a los cambios que se hicieron.

Store Procedures de Comprobante de Pago: 1.30 horas

Se crearon los siguientes store procedures:

-dbo.[SPS.Bitacora]

-dbo.[SPS_ComprobanteDePago]

-dbo.[SPS_Recibos]

Para poder implementarlos en la pagina web de modo que se obtenga el 6 por ciento de la implementacion de la pagina web.

Controlador Bitacora: 2 horas

Se creo el contorlador de Bitacora, este llama a los metodos de Bitacora_Conexion para formar el ViewModel que se necesita para mostrar al usuario administrador las bitacoras de todas las entidades de la base de datos.

La mayor parte del tiempo se ocupo en buscar como manejar un json en C#.

En esta página se encontró la manera de usar el JSON :
https://www.campusmvp.es/recursos/post/Como-usar-JSON-en-NET-facilmente.aspx

Tambien se necesitaba una manera de iterar en el json de forma dinamica ya que las llaves cambiaban dependiendo de la entidad. La solucion se encontró en la siguiente página:
https://stackoverflow.com/questions/11132288/iterating-over-json-object-in-c-sharp

Además se tuvieron que solucionar varios erroes entre ellos uno en particular fue el hecho de que el parser que utilice para convertir de String a Json no funcionaba con comillas dobles ( "") por lo cual se tuvo que hacer un replace del string por comillas simples. La respuesta a este error se encontró en la siguiente página:
https://stackoverflow.com/a/61606181/13772118

Controlador Recibo: 40 min

Se creo el controlador recibo que maneja los metodos de conexion de Recibo_conexion para obtner los recibos de una propiedad y concepto de cobro en especifio. En este se reciben datos como los recibos pendientes, recibos pagados y comprobantes de pago.

Vistas de Bitacora y Recibo: 1.2 horas

Se creo la vista que muestra las bitacoras de las entidades

Y la vista que muestra los recibos pendientes, recibos pagados y comprobantes de pago de una propiedad y concepto de cobro en especifico, ademas permitirá pagar los recibos pendientes

<!-- FECHA 11/07/2020 -->

Store Procedure SPS_ComprobanteDePago: 15min

Se creo SPS_RecibosPorComprobante, recibe como entrada el id del comprobante, la fecha de pago, y el numero de finca, este devuelve el detalle de todos los recibos que se pagaron y estan asociados a ese comprobante de pago.

Modelos RecibosPorComprobante y Pago de recibo: 1.5h
En el Modelo de conexion a la Base de datos se agrego el metodo que llama a SP_Pagado_Multiple que se encarga de pagar los recibos de un concepto de cobro y generar los respectivos intereses.

Tambien se creo el metodo de que llama a SPS_RecibosPorComprobante.  Con este metodo se obtuvo el error de que el formato de fechas recuperado por la base de datos a la hora de pasarlo a una variable DateTime de C# se modificaba, entonces estos no coincidian. La solucion fue pasar los parametros de la fecha al controlador por partes /dia/mes/año, luego en el metodo del controlador se creaba el objeto DateTime y en la conexion se hacia 'parsing' al formato de SQL en la BD. Esta solución se encontró en la siguiente página:
https://stackoverflow.com/questions/16814012/c-sharp-string-to-sqldatetime-how-to-set-format-for-recognition

Se creó el modelo ReciboPorComprobante que es un recibo pagado que esta asociado a un comprobante de pago. Tambien el modelo ReciboPorComprobanteViewModel que contiene la lista de recibos del comprobante de pago, asi como el monto total y la fecha de pago.

Actions de ReciboController y las Vistas: 1.5h
En el controlador Recibo se agregó el action que Paga los recibos de un concepto de cobro.
También el Action que recibe un Comprobante de pago para obtener los detalles de este.

Se construyo la vista que despliega los recibos pagados en un concepto de cobro y tambien se agrego la funcion de pagar en la Vista de Recibos