Entradas

Mostrando entradas de diciembre, 2020

Correción segunda vista -

  Jarod Cervantes Gutiérrez.                18:00 p.m. - 16:40                       40 m  Se corrigió esta parte, se cambió [HttpPost] que antes estaba [HttpGet] y ya había otra función con [HttpGet]. Pero igual no estaba pasando el parámetro al controlador, pues hay dos funciones llamadas igual pero con diferentes parámetros de entrada. Luego se vio que en el archivo html, en el form, el input, la parte del name tiene que ser llamada igual que el parámetro de entrada de la función, pues como no estaba este entraba como null.

Vista Segunda Consulta -

 Jarod Cervantes Gutiérrez.            13:30 p.m. - 14:10                      40 m  Se agregó la vista de la segunda consulta en la que debe insertar los días, pero por el momento no está cargando.

Segunda Consulta de Admi

Imagen
 Jarod Cervantes Gutiérrez                     11:00 a.m. - 12:30 p.m.    1 h 30 m Se hizo la segunda consulta. Revisarla porque no estoy seguro si está bien hecha. Este primer if esta para cargar todas las cuentas, esto para abrir la vista que despliegue todo. Luego cuando se le de un parámetro, @inDias, haría la consulta respecto a los días dados.

Vistas de Primer y Tercer Consulta de Admi

 Jarod Cervantes Gutiérrez                          8:00 p.m. - 10:00 p.m.     2h Se crearon las vistas para la primer y tercer consulta. Accediendo desde una cuenta de administrador se escoge que acción tomar, aparece un botón para "Consultas" que cargará otra pantalla para cargar cada una de las consultas. Por ahora solo carga la primer, la tercera debería cargar pero no funciona por ningún motivo.

Tercer Consulta Admi

Imagen
 Jarod Cervantes Gutiérrez                5:30 p.m. - 7:30 p.m.                2 h La consulta consiste en obtener todos los beneficios de cada Beneficiario. Este se procedió realizando pruebas, para ver en que orden hacer los join o las consultas anidadas. La consulta base fue esta : Y a partir de ella salieron la suma total de beneficios, cual era el mejor beneficio y total de cuentas. Se tratará de cambiar porque las últimas tres consultas anidadas son muy parecidas. Antes de terminar nos dimos cuenta que una estaba más y paso de esto: A esto:

Segunda Consulta Admi

Imagen
 Jarod Cervantes Gutiérrez                                                      3 :30p.m - 5:00p.m               1 h 30 min La segunda consulta se realiza sobre aquellas cuentas que han excedido más de 5 veces la multa de retiros de atm en los últimos n días. Se trató de hacer iterativa, y quedó así: Como se ve, dentro del while está comentado puesto que no se sabia con seguridad si serviría. Así que por el momento este sp claramente no funciona. Se decidio proseguir con la tercer consulta de admi.

Mostrar movimientos CO y movimientos CO con intereses

 Natalia Vargas Reyes de 10 am a 11 am y de 1 pm a 2 pm (2 horas) Se creó la vista, controlador y clases necesarias para mostrar en vista los movimientos de de CO, esto lo hice con Jarod con el objetivo de entendiera más fácilmente la parte de capa lógica pues con anterioridad el había trabajado sobretodo el capa de datos, es decir la parte del script.  ALTER PROCEDURE [dbo].[SPObtenerMovimientosCO] (          @pIdCO INT  )       AS BEGIN  BEGIN TRY    SELECT  M.Id ,M.IdCuentaObjetivo ,T.Nombre ,M.Fecha ,M.Monto ,M.NuevoSaldo ,M.Descripcion FROM  [dbo].[MovimientoCuentaObjetivo] AS M INNER JOIN [dbo].[TipoMovimientoCuentaObjetivo] AS T ON  T.Id = M.IdTipoMovimientoCuentaObjetivo WHERE M.IdCuentaObjetivo = @pIdCO  ORDER BY M.Fecha DESC END TRY BEGIN CATCH PRINT 'Error al mostrar movimientos CO' INSERT INTO dbo.BE_DBErrors...

Correción SPCierreEstado y primer consulta admi

Imagen
 Jarod Cervantes Gutiérrez                                                               5:15 p.m - 7:15 p.m                            2 h  La ejecución del spcierre fallaba, se estuvo revisando por media hora y nos dimos cuenta que era debido a que se estaba usando un archivo xml incorrecto, en el que existía un tipoMovimiento = 0. Se empezó con la realización de la primer consulta de admi.  Quedó muy grande y con otras consultas anidadas. Se tratará de hacer iterativa para achicarla, dado que hay varias consultas que son iguales, como la del case para obtener los meses totales, y también el de de depósitos totales.

Depósito, intereses y redención de CO

Imagen
 Natalia Vargas Reyes de 5:30 pm a 10:30 pm (5 horas) Se crearon los SP necesarios para las cuentas objetivo, no obstante falta mejorarlo, porque se necesita agregar un par de campos más en algunas tablas y poder sumar veces en las tablas en cada iteración. Este corresponde al procesamiento de cuentas, se llama desde el script de lectura e insert masivo. Para el de procesamiento de intereses Y finalmente para la redención 

Corrección SPCierreEstado

Imagen
Jarod Cervantes Gutiérrez                          2 horas  9:30 pm - 11: 30 pm Se cambio el uso de un select dentro de otro por un join. Luego en se agregó un seteo de saldos de la cuenta para los diferentes movimientos. Y se cambió el orden de la transacción al siguiente : CuentaAhorro, EstadoCuenta y Movimiento

Cambios sugeridos por el profesor en la Progra 2

 Natalia Vargas Reyes (2 horas) de 8:00 pm a 10:00 pm Cambios como usar joins en lugar de tantos select, utilizar bien los campos de cantidad de retiros automáticos o humanos en lugar de hacer counts que ralentizaban el proceso. La nueva versión, con todos los insert y llamadas a funciones y otros SP, en una tercra versión quedó de la siguiente manera: Nota: Solo son algunas mejoras, aún no se ha iniciado con lo que respecta a las Cuentas Objetivo ------------------------------Persona----------------------------------------- INSERT INTO [dbo].[Persona] ( [IdTipoDocumentoIdentidad] ,[Nombre] ,[ValorDocumentoIdentidad] ,[FechaNacimiento] ,[CorreoElectronico] ,[Telefono1] ,[Telefono2] ,[InsertAt] ,[UpdateAt] ,[InsertBy] ,[UpdateBy] ,[InsertIn] ,[UpdateIn] ) SELECT d.value('@TipoDocuIdentidad', 'INT') , d.value('@Nombre', 'VARCHAR(1...

Triggers de Eventos

Natalia Vargas Reyes (1 hora 30 mins) de 1:10 pm a 2:40 pm  Se crearon  4 triggers, tanto para beneficiarios como para Cuentas Objetivo, estos triggers insertan en la tabla de eventos dependiendo si es un insert o un update. -- ========================================================================= -- Natalia Vargas Reyes -- Trigger para insertar evento si inserta una CO -- ========================================================================= SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TRIGGER TR_CuentaObjetivo_AI ON [dbo].[CuentaObjetivo] AFTER INSERT AS  BEGIN SET NOCOUNT ON; DECLARE @xml xml; SET @xml = ' ';     INSERT INTO [dbo].[Evento]( [IdTipoEvento]     ,[IdUser] ,[Ip] ,[Fecha] ,[XMLAntes] ,[XMLDespues] ) VALUES  ( 1 ,1  --De dónde me saco el id de usuario? ,NEWID() ,GETDATE() ,@xml ,(SELECT  ICO.Id    ,ICO.IdCuentaAhorrro ...

To do list

 Natalia Vargas Reyes (1 hora) de 3:00 pm a 4:00pm Hacer una Lista de cosas por hacer en la progra la cual es  1.Agregar codigo a la cuenta objetivo, para agregar desde xml. Verificar el modelo con respecto a CO.  LISTO  2. El interes había que dividirlo entre 12. De paso usar los campos de Cuenta ahorro  en lugar de tantos SELECT. 3. Calcular tasa de interes de CO, la cual depende cantidad de meses que existirá  (según fechaF-fechaI) 0.5% de interés por cada mes, mes entero. El interés es anualizado. Si la suma de los meses es 5, la tasa 2.5% anualizada, por día seria 2.4% dividido entre 365.  En la simulación calcular intereses diarios de CO. 4. Se insertan intereses todos los días en la tabla MovimientosCO. El dia del deposito, primero se hace el deposito, despues se calcula el interes,  luego se crea el credito(movimiento) y se acumula el monto. 5. En la simulación, su script, cuando procesa un día, antes de realizar el proceso de estados de c...

Análisis de los resultados

Imagen
  CANTIDAD DE HORAS INVERTIDAS POR CADA UNO DE LOS COLABORADORES Natalia Vargas Reyes  27 horas y 45 minutos Jarod Cervantes Gutiérrez  20  horas y 25 minutos  CONTRIBUCIONES DE LOS COLABORADORES EN GITHUB cantidad de contribuciones al github: 19 cantidad de contribuciones al github:  9 Se empezó la tarea desde el 20 de noviembre  Sin embargo hasta el 24 empezaron a haber avances de la tarea 2 pues, en los primeros días tratamos de pasarnos a local, a otro server de AWS o a Azure. ANALISIS DE LOS RESULTADOS OBTENIDOS El script de operaciones fue la parte de más proceso en el proyecto, sin embargo se completó con éxito. Hubieron problemas con el trigger pero la solución fue iterar sobre la carga de cuentas, pues de esta manera la tabla inserted en el trigger sabría exactamente cúal fue el último insert de cuenta. La búsqueda en movimientos quedó muy bien y en general todo lo agrega en vistas, como cuentas objetivo y demás no generó más que errores peque...

Cambio tabla Estado, corrección de simulación

Imagen
 Jarod Cervantes Gutiérrez                     20:40-22:40|                    2 horas     Se agregaron las columnas saldoMinimo, QOCH y QOCA a la tabla Estado de Cuenta. Estos cambios repercutieron en el SP de simulación. Pues su forma de insertar movimientos cambio. Esta primer parte toma los datos del XML. A continuación prepara los datos para insertarlos en Movimiento, y realizarle update a CuentaAhorro y Estados.

Corrección definitiva? del SP de Cierre de Estados

Imagen
Jarod Cervantes Gutiérrez                18:00-18:30                    30 min   Se encontraron dos errores. Primero no se contaban los movimientos de retiro y deposito de ATM para calcular la multa por exceso. Únicamente se contaba el retiro. Lo mismo para Humano. Segundo error, para el calculo de intereses se usaba el monto de movimiento mínimo en lugar de saldo de cuentaAhorro mínimo. Por lo que habían meses en los que no se realizaban movimientos, y al no haber movimiento no había monto con el cual calcular intereses, por lo que no se realizaban movimientos de intereses. Muestra del cambio de código. Se ve que solo cuenta los movimientos de retiro para ATM(2) y humano(3) La corrección presenta la adhesión del tipo movimiento de deposito ATM (4) y humano (5). Del segundo error se tenia el siguiente código. Dónde da el monto de movimiento, no el saldo de cuenta. Además que los mese...

Cambio SP cierre de Estado

Imagen
Jarod Cervantes Gutiérrez           10:30 -11:00           30 min   Para el SP de cierre de estados de cuentas se corrigia la parte final donde inserta movimientos (multas de retiro, cobro de comisión e intereses), se realiza el update de estado de cuenta para cerrarlo y la creación del siguiente estado, esto para que estuviesen dentro de una transacción. El codigo paso de : Donde pregunta si habían multas y seteaba el valor de la multa, para insertarlo. Esto se repetía en multas humano, calculo de intereses y multa de saldo mínimo. Y luego esta parte donde actualiza el estado de cuenta, setea valores para la creación del siguiente estado. Luego el código se corrigia para añadir la transacción, sacando de la misma todas las asignaciones de valores. Acá se ve donde la asignación de valores está fuera de la transacción. Ya aquí iría la transacción: Se continua con multa humano, multa saldo mínimo, calculo de intereses y por ...

Buscar en Movimientos y arreglo del Update Cuentas objetivo

Imagen
 Natalia Vargas Reyes de 5:00 pm 8:00 pm (3 horas) Se terminó el buscar de los movimientos, el cual se ve de la siguiente forma En este buscar tardé al menos 2 horas tratando de entender el ViewBag, pues aunque tenía el Id del estado en una etiqueta no sabía cómo pasarle el Id por algún método post para supiera en cuál estado buscar.  Finalmente lo entendí y apliqué lo mismo para hacer el Update y mejorar el create de cuentas objetivo, que de hecho tenía el defecto de necesitar el Id de la cuenta a la cual se iba a crear, y pues es algo que sucedió desde la tarea 1. También descubrí un error en un SP viejo, que hacía que todas las cuentas de un usuario puede ver tuvieran el mismo id al menos en el manejo en capa lógica, entonces sucedían cosas que no debían.  En la siguiente imagen se nota lo que trato de explicar: Era literalmente una linea en un SP. Y finalmente aproveché para hacer algo que me tenía con dudas desde la primer progra pero que realmente era muy fácil al e...

Simulación - Hecha

Imagen
Jarod Cervantes Gutiérrez 1:00 - 1:30, 5:00 - 9:30 (5 horas) Se lee totalmente el XML, y se realizan los cálculos finales para realizar el cierre del Estado de cuenta. El SPCargarOperacionesv2 se encarga de leer el archivo XML. Lo que hace es tomar el primer nodo fecha y el último, para calcular los días (n) entre esas dos fechas. Una vez las calcula se procede a realizar una iteración n veces de esos días. Se van manejando dos fechas, @fechaItera que es inherente a las fechas dentro del XML, se calcula @fechaInicial + @iterador y @fechaOperacion que se asigna desde el XML. Luego se compara si @FechaOperacion es igual @fechaItera, y si lo son es porque existe un nodo en el XML el cual hay que leer e insertar los datos ahí presentes.  La lectura de Persona, Cuenta, Beneficiario y Movimiento está tal cual se describió anteriormente. Solo se agrego la lectura de Usuario y UsuarioPuedeVer que sigue el mismo estilo que las lecturas anteriores. En el caso que las fechas sean distintas no...