Trabajo 3

 Durante el desarrollo del proyecto se realizaron diferentes correcciones, las cuales afectaron más que todo al de movimientos ya que se cambiaron algunos movimientos y se eliminaron algunos. El encargado de realizar los cambios fue el compañero Aarón Ortiz. De esto salen las siguientes observaciones. 1. Para cierto movimientos al principio ya venían con el monto, sin embargo estos provenían de reglas de negocios, por lo que se tuvieron que realizar cambios a la función que calcula el monto de la regla de negocios, sin embargo, se realizo otro cambio eliminando algunos, ya que el estado de cuenta se encargaba de procesarlos, por lo tanto se volvió a cambiar, pero este no significo un gran cambio y se realizo en menor tiempo. Tiempo estimado 1 hora. 2. Otro de los cambios fue cambiar que los contadores se pre-procesarán , por lo que se agrego una variable tabla para calcularlo y agregarlos directamente, esto no genero ninguna dificultad. Tiempo estimado 2 horas.

 Se creo el stored procedured encargado de realizar el procesamientos de nuevas tarjetas física diarios que se encuentran el xml de operaciones brindado, con haber realizado la creación de los anterior, en especificos los CTM y CTA. Dichos Procedured estaba acargo del compañero Aarón Ortiz, de esto se otorga las siguientes observaciones. 1. Con los anteriores SP, con los cuales tiene un parecido durante el procedimiento supuso ninguna complicación el proceso de carga los datos del xml a una variable tabla, sin embargo, solo hubo un pequeño inconveniente con un dato especifico de el cual es la fecha, dicho caso, no supuso mayor dificultad, ya que se realizo una investigación en guías encontradas en internet, como herramientas, se resolvió en menor tiempo. Tiempo estimado 1 hora. 2. Cabe aclarar, este proceso era necesario, debido al proceso de movimientos requiere los datos de las Tarjetas físicas, por lo que se realizo en el menor tiempo posible para poder continuar con el desarrol...

 Se debía realizar un SP con la lógica compuesta en la documentación, se dividió el proceso en dos partes pero que se realizan en el mismo SP, la parte 1 seria en los casos donde la cuenta que se cierra es maestra, y por otro lado la parte 2 no es maestra, aquí evidentemente surgieron contratiempos a la hora de entender la lógica dispuesta en la documentación puesto que es un poco mas compleja. 1. Para empezar entonces se mapean las variables necesarias para la ejecución correcta del SP, y con esto se aplica el uso de una tabla variable como en todos los demás procedimientos, cabe recalcar que se calculan todos los datos antes de comenzar a insertar o editar tablas, y debido a la complejidad de dicha transacción, muchos de los datos se mapean por separado, haciendo que se complique un poco la legibilidad del SP. Tiempo estimado 2 horas. 2. Aquí entonces se dividió el SP en dos partes, como se comentaba anteriormente era necesario hacer esta división puesto que hay cuentas que son m...

 En este procedimiento hubieron varios contratiempos que se salieron de las manos de nosotros, esto debido a que hubieron muchas actualizaciones del XML que involucraban esta parte, por este motivo se hizo bastante tedioso la implementación del mismo, sin embargo, se completo en su totalidad. 1. Se siguieron las instrucciones propuestas por el XML, para introducir las mecánicas de validación de TF, sin embargo, cabe recalcar que eran un poco ambiguas, y causaron bastantes contratiempos en su lectura. Tiempo estimado 1 hora. 2. Se implemento el código según dadas instrucciones, la lógica por si sola no era complicada, sin embargo al juntarla con las implicaciones de las TF y el XML se hizo un poco mas elaborado, en este mismo proceso se tuvieron que hacer exhaustivas correcciones por las mismas razones descritas al inicio, puesto que día con día se realizaban correcciones en el XML. Tiempo estimado 6 horas.

  Para insertar la información en la tabla de usuario, en la tabla de artículos y la de clase de artículos era necesario leer un XML y extraer la información desde ahí, sin embargo hubieron varios factores que demoraron este proceso, se destacan los siguientes puntos: 1. Se creo un Stored Procedure que leyera la información del XML y pudiera traducir dicha información en las tablas, insertando valor por valor cada uno de los elementos. Tiempo estimado 1 horas. Nos basamos mucho en la lectura pasada del XML, sin embargo, modificamos algunos factores para que funcionara correctamente a la hora de introducir los catálogos, y al ser un proceso un poco mas completo, se hizo un poco mas complicado.

 Se realiza el mismo procedimiento que en el de cargos corrientes, siguiendo las instrucciones dictadas por la documentación, se implementan los pasos necesarios para el SP, para empezar seguía una estructura muy similar por no decir que igual que el de corrientes, con la única diferencia que implementaba mas condiciones para la hora de realizar la función:  1. Lo que realmente se percibió como un reto fue el lograr captar las condiciones ejemplificadas en la documentación, por algún motivo u otro no me parecían para nada claras, sin embargo, consultando con compañeros e incluso al profesor se logro superar esa barrera, a partir de ahí la implementación del algoritmo no fue complicada. Tiempo estimado 3 horas.

Se crea el stored procedure dispuesto para calcular los intereses diarios que se acumulan debido a morosidades, para empezar se crea usando de base la documentación dada por el profesor, se detalla en la siguiente imagen:  Fue un poco complicado entender el concepto que hay detrás de esta función, puesto que no se entendía muy bien las condicionales que aplicaban en ciertos casos, sin embargo el inconveniente se logro resolver, por otro lado la lógica como tal no fue complicada de aplicar, se realizaron los procesos necesarios y se implemento como en todos los procedures con un try and catch para facilitar errores: Se realiza en un proceso de transacción de uno a uno para facilitar el roll-back, fuera de eso se aplican las reglas y condicionales descritas en la documentación. Tiempo estimado 3 horas.

 Se creo el Stored procedure que se encarga de procesar lo movimientos, cabe aclarar que una de los procesos que equivalio mayor desarrollo, de lo cual ocupa valores de diferentes tablas, como los CTM, CTA, TF, Estados de Cuentas y Sub-Estados de cuenta. Dicho desarrollo del Stored Procedured estuvo a cargo del compañero Aarón Ortiz. De esto salen las siguientes observaciones. 1. Este procedured posee mucha complejidad ya que necesitaba buscar mucha información entre diferentes tablas, por lo cual vamos a destacar varios puntos. Muchos de los datos que se necesitaban actualizar (Saldo del CTM, Contadores del estado de cuenta y sub- estados de cuenta) se requerian buscar muchos datos como id de CTM Y CTA para identificar los estados de cuenta y sub Estados de Cuenta. Tiempo estimado: 1 hora  Otros datos que se requiere procesar son los tipos de movimientos, ya que algunos suman ciertos contadores, como obtener los montos, por lo cual se decidio de realizar varias funciones para...

 Se crearon los diferentes Stored Procedured encargados de mostrar las diferentes cuentas, Estados de cuentas o Sub-estados de cuentas relacionadas a las cuentas, y los movimientos. Son necesarios para mostrar los datos desde la aplicación web en asp.NET. El encargado de crear los procedured fue el compañero Aarón Ortiz. De esto salen las siguientes observaciones. 1. Muchos de los procedured que se ocupaban para mostrar la información en la aplicación no supuso un mayor problema, debido a las experiencias de los proyectos anteriores, aunque era necesario varios joins, sin embargo este no supuso mayor problema, más que todo los de mostrar todas las cuentas, y el de mostrar cuentas asociadas, ya que estas dos tienen solo una diferencía ya que uno tiene que filtrar las cuentas asociadas a la tarjeta habiente, mientras que la otra no. Tiempo estimado 1 hora. 2. Otro de los Stored Procedured desarrollados son lo que muestran los estados de cuentas o sub-estados de cuenta, aunque se tuvo...

Se crearon los procedimientos para procesar los nuevos CTM y CTA diarios que se encuentren en el XML de operaciones, luego de tener listo el sp de nuevos Tarjeta Habientes, facilito o brindo más información para desarrollar los procedure. Dicha tarea se encargo el compañero Aarón Ortiz, del cual nos brinda las siguiente observaciones. 1) Con la creación del Stored Procedured de Tarjeta Habiente, este facilito la comprensión para crear para los de CTM y CTA, sin embargo, en el caso de CTM este no realiza tanto join entre tablas, pero las que se destaca las que se realizaron fue con tarjeta habiente, ya que se ocupaba el id de TH asociadas a las nuevas cuentas, pero unicamente con esa tabla. Por otra parte, el de CTA ocupaba realizar dos, que sería al TH y CTM, pero hay que destacar que no equivalio un problema. Tiempo estimado 3 horas. 2) Por otro lado, durante la creación de ambos SP, se tuvieron que tomar varias decisiones durante el desarrollo de la mismas, que en este caso fue la cr...

 Se crea la el store procedured Diario que se encarga de procesar los nuevos tarjeta habientes que vengan del xml de operaciones brindada. Luego de definir un modelo conceptual de la base, se pudo comprender como procesar los nuevos tarjetas habientes que diariamente se deberían de cargar. Con la distribución de las tareas entre los integrantes, el encargado de crearlo fue el compañero Aarón Ortiz, de eso salieron las siguientes observaciones: 1. Al ser el primer script donde se realiza inserciones de manera masiva, su desarrollo fue pausado debido a falta de experiencia, sin embargo al no necesitar demasiados joins a muchas tablas no fue complicado. Para la creación de tabla variables que permiten cargar los datos como realizar el pre-procesamiento, no fue tan complicado comprenderlos. Tiempo estimado 1 horas. 2. Por ultimo uno de los inconvenientes durante la creación fue como obtener los nodos específicos de ciertos nodos, sin embargo investigando, más con la herramienta de chat...