Entrada Final (Recopilación de Datos)

Entrada Final

Análisis de Resultados

Como entrada final de la bitácora, se procede a realizar un recuento de todo el trabajo realizado, donde se involucrarán datos como la cantidad de horas que requirió para elaborarla, las secciones que funcionan y las que no.

La creación de las tablas y sus relaciones se basó en el diseño del modelo visto en clase  brindado por el profesor. No obstante es importante darse cuenta que durante el avance y desarrollo de la aplicación, algunas relaciones y atributos irían cambiando, por lo que el modelado final no  es idéntico al original, pero si se revisan con cautela todas las entradas de la bitácora, se irán mostrando estos cambios que a la postre son mínimos. ejemplo de estos son los mostrados en la sección Ultimas Modificaciones. 

Posterior a la creación de la base de datos, llamada "VacacionesBD", se procede con la creación y conexión de la BD hacia la aplicación en capa lógico. Cabe mencionar que no fue una tarea muy ardua aunque de cierta manera suene arrogante, pero esto realmente es debido a que se encontró material de apoyo suficiente para poder comprender el funcionamiento entre estos dos manejadores.

Una vez llegados a este punto sólo bastaría comenzar con la creación de los SP y de los métodos en capa lógica, donde los mismos iban siendo creados a conforme se fuesen necesitando, ya que no se podía predecir con facilidad que SPs serían necesarios y cuales no, por lo tanto se optó por su creación en el momento que surgiese la necesidad tal como se menciona en los reglones previos.

Por otra parte, y dando como terminada a grandes rasgos esta reseña del proceso con el que fue creada la aplicación, sólo nos bastará mencionar aquellas partes o secciones que cumplieron a cabalidad con las especificaciones de la tarea programada, y por su puesto las que no. Para ello dividimos esta porción en dos interrogantes:

¿Que funciona?:

Basándonos en los resultados obtenidos, se podría decir que todo lo solicitado en la especificación de la tarea programada se ha cumplido con éxito, no obstante se es consiente de que siempre el sistema podrá llegar a presentar fallos, más si este no ha sido depurado al máximo. Cabe resaltar que hasta el momento no se ha detectado ninguno por lo que el sistema ha corrido perfectamente.
Entre algunas de los aspectos que funcionan, se podrían mencionar las siguientes:

• Se solicita cuenta y clave para que el empleado pueda ingresar.
• Un empleado llena una solicitud de vacaciones, indicando fecha de inicio, fecha de fin.
• Un administrador puede agregar un movimiento, de crédito (bono vacacional, o ajuste – devolución de débito) o débito (venta de vacaciones o ajuste – devolución de crédito).
• Un empleado jefe puede ver las solicitudes de sus empleados subordinados. Puede filtrar entre solicitudes pendientes de aprobar y las aprobadas, Sobre las pendientes de aprobar, puede seleccionar una y aprobarla.
• Se lista las fechas en las que ha corrido el proceso, junto a la cantidad de días acreditados como vacaciones.se listan todos los empleados que recibieron un crédito de vacaciones por cumple mes.
• Se lista los empleados a los que se les aplicó débito de vacaciones por vacaciones disfrutadas
• Se solicita un rango de fechas, fecha de inicio y fecha de fin para la consulta. Se listan todos los empleados que disfrutaron vacaciones
• Se genera movimientos de débitos de vacaciones por motivo de disfrute para todos los empleados que tienen solicitudes de vacaciones aprobadas y cuya fecha actual está dentro del rango de fechas de la solicitud aprobada, a través de la simulación de un "Job" que ejecuta un procedimiento Masivo.
• Por último se agrega una tabla para control del proceso masivo, con identificación del proceso, fecha de corrida, y si finalizó con éxito. Los procesos se controla que no se brincan días y que no corran en duplicado..
  

¿Que no funciona?:

• Creemos que el proyecto cumple con los parámetros establecidos en la solicitud efectuada por el profesor a cargo de supervisar el proyecto, aunque aún no se han hecho pruebas suficientes para "debuggear" al 100% la funcionalidad de la herramienta web.

Registro de horas trabajadas:

Como punto final pero no menos importante, se pide realizar un recuento de las horas que se invirtieron en el desarrollo de la aplicación. Para ello se detallará entrada a entrada cuantas horas se invirtieron en las mismas, y por último el total de horas.

Nota: 

El tiempo considerado para cada entrada es calculado según el tiempo efectivo trabajado. Esto debido a que consideramos como una falacia el hecho de poner un conteo de horas donde se abarquen grandes periodos, ya que evidentemente uno tiende a procrastinar y por ende 'pierde'  tiempo en cosas ajenas y distantes al trabajo.

A continuación se presenta el reparto de horas entre las diferentes etapas de la creación de la aplicación:

***********  Nombre de la Entrada  ******************  Horas Invertidas  ***********

1. Creación de la Base de Datos entre tablas                             0.5     horas
2. Tabla de Historial de Procesos Masivos                                1        horas
3. Creación de Procedimientos Almacenados                           2        horas
4. Investigación XML, XLS y SQL                                          1.5      horas
5. Creación de la Página Web                                                   4         horas
6. Modificaciones al diseño de la Base de Datos                      0.5      horas
7. Actualizacion de procedimientos almacenados                    1         horas
8. Inserción de algunos Datos Predeterminados                       0.5      horas
9. SP de Simulacion de Créditos por Concepto de Mes           1.5      horas
10. SP de Simulacion de Débitos por Disfrute de Vacaciones   1         horas
11. Declaración de los métodos en las diferentes clases            2         horas
12. Declaración de los Store Procedures                                    2         horas

********************** Total de Horas Trabajadas: |     20 horas     |  **********************

Declaración de los Store Procedures

El día de hoy se lleva a cabo la programación de todos los Store Procedures que serán utilizados en la base de datos, para hacer consultas, actualizaciones, borrados, entre otras cosas.

En las imágenes que se muestran a continuación se pueden visualizar todos estos procesos, y además de ello una pequeña descripción por cada uno.

SP Utilizado para Cambiar el estados
de una solicitud

SP Utilizado para Filtrar a los empleados

SP Utilizado para Tomar a todos los empleados que se les
debitó o acreditó días de vacaciones en una fecha
determinada

SP Utilizado para Seleccionar todos los procesos masivos

SP Utilizado para insertar un movimiento manualmente

SP Utilizado para Ingresar una nueva solicitud de vacaciones
por parte de algún empleado

SP Utilizado para obtener las solicitudes de
vacaciones Aprobadas o Rechazadas

SP Utilizado para Obtener todas las solicitudes
de vacaciones pendientes

SP Utilizado para probar la existencia del
User y Pass ingresados (Probar Login)

SP Utilizado para Seleccionar todos los usuarios
que disfrutaron vacaciones en una fecha determinada, y
el costo de las mismas 

SP Utilizado para Seleccionar todos los procesos masivos
que debitaron o creditaron días de vacaciones, y además
de esto la cantidad de días afectados

SP Utilizado para seleccionar todos los empleados

Nota:
Cabe resaltar que en este apartado no se incluyen los procesos masivos ni las funciones utilizadas por cada uno de estos, debido a que en las entradas previas de la bitácora ya han sido ilustrados. No obstante si desea darles un vistazo, de click en este link: CréditoMasivo para visualizar el SP masivo de crédito, o en el siguiente: DébitoMasivo para visualizar el SP masivo de débitos..


Tiempo Invertido: 8 horas y 30 minutos

Declaración de los métodos en las diferentes clases

Este avance consistió en declarar todos los métodos en las clases(Conexión, Administrador, Jefe, Empleado) que serán necesarios para la implementación de la página web. Cabe resaltar que estos métodos son los que se encargan de llamar a los respectivos SP en base de datos, es decir son los que abren la conexión con VacacionesBD (nombre de la base de datos) y ejecutan un respectivo procedimiento.
Sin más preámbulo, a conitnuación se muestran todos estos métodos ordenados por las clases a las que pertenecen.

Clase Conexión:
Esta clase es la encargada de albergar el string de conexión con la base de datos, y es de la cual las demás heredan. La herencia se hace con el fin de que las otras clases poseen al igual que la clase "padre" (conexión) el atributo Conn, que alberga como se mencionó anteriormente el string de conexión.
Métodos de la clase Conexión:

Método encargado de probar el Login
o la cuenta de usuario que se está
ingresando al sistema.

Métodos utilizados tanto para tomar como setear
el valor de las respuestas que han de
devolver los SP ejecutados

Clase Empleado:
Esta clase es la encargada de albergar los métodos ejecutados por el empleado, los cuales son el ingreso de una solicitud de vacaciones al sistema, y tanto la toma como el seteo de las respuestas brindadas por el  SP ejecutado
Métodos de la clase Empleado:

Método encargado de ingresar una nueva solicitud al sistema,
esto desde una fecha de Inicio, hasta una fecha fin.

Métodos utilizados tanto para tomar como setear 
el valor de las respuestas que han de 
devolver los SP ejecutados

Clase Jefe:
Esta clase es la encargada de albergar los métodos ejecutados por el jefe, el cual realiza la aprobación y el rechazo de solicitudes ingresadas por los empleados.
Métodos de la clase Jefe:

Método encargado de cambiar el estado de una solicitud
a "Rechazada" o "Aprobada". Con el fin de que posteriormente
el SP Masivo debite o no las vacaciones a los empleados

Clase Administrador:
Esta clase es la encargada de albergar los métodos ejecutados por el administrador de la BD, es decir todos aquellos métodos de consulta (de débitos, créditos, costos, procesos Masivos) y el método de ingreso manual de movimientos..
Métodos de la clase Administrador:

Método encargado de realizar el ingreso de movimientos de manera
manual

Método encargado de filtrar la lista de los empleados,
esto por medio de la similitud del nombre que haya
sido consultado

Método encargado de realizar la consulta de todos los empleados
que recibieron un débito o crédito de vacaciones en una
fecha determinada

Métodos utilizados tanto para tomar como setear 
el valor de las respuestas que han de 
devolver los SP ejecutados

Tiempo Invertido: 7 horas

SP de Simulacion de Débitos por Concepto de Disfrute de Vacaciones

El día de hoy se lleva a cabo la programación de la simulación del Job encargado de Debitar días de vacaciones (SaldoVacaciones del empleado) por concepto de disfrute.

Para ello se construye un script que itera desde una fecha inicial (fecha más antigua de la fecha de contratación de empleados) a una fecha final (fecha máxima en fecha final de solicitudes aprobadas) y para fecha en la iteración se invoca el proceso masivo para realizar débitos por vacaciones disfrutadas.

Para esto fue necesario realizar una función previa, la cual se encarga de generar un nuevo correo, con el fin de respaldar la acción de débito de vacaciones hecha sobre un empleado. La misma se muestra a continuación:

Función para la creación de
un nuevo correo

Posterior a esto se codificó el debido SP para realizar el débito de vacaciones, el cual luce de la siguiente manera:

SP encargado de Debitar
Vacaciones

Tiempo Invertido en este avance:
2 horas

SP de Simulacion de Créditos por Concepto de Mes Cumplido

Se lleva a cabo el SP para la simulación de un Job que día a día le acredita días de vacaciones a los empleados que están cumpliendo un mes.

Para el mismo se requirió de una función que verifique si la fecha de contratación del empleado y la fecha del proceso indican que el empleado esta cumpliendo un mes más de trabajo.

El código para la función se presenta ahora:





Luego para el procemiento de actualizacion masiva se utilizo como base el codigo que el profesor facilito en clases, aún así se debieron realizar cambios para adaptarlo al modelo de bases respectivo.
Se presenta a continuacion su codigo:

[SimulacionCreditoVacaciones]

@fechaProceso DATETIME

AS
BEGIN
    SET NOCOUNT ON;
        BEGIN TRY
            
            DECLARE @MovsTempTable TABLE
            (
            ID INT IDENTITY(1,1) PRIMARY KEY,
            IDEmpleado INT,
            Email VARCHAR(50),
            SaldoVacaciones INT,
            TextoEmail VARCHAR(500)
            )
            
            DECLARE @QEmpleados INT
            
            INSERT INTO @MovsTempTable(IDEmpleado, Email, SaldoVacaciones)
            SELECT E.ID, E.Email, E.SaldoVacaciones
            FROM Empleados E
            WHERE (dbo.CumpleMes( @fechaProceso, E.FechaContrat) = 1)
             
            UPDATE @MovsTempTable
            SET TextoEmail = 'Se ha agregado un dia a su saldo de vacaciones por cumplir mes de trabajo.'
            
            SET @QEmpleados = (SELECT COUNT(1) FROM @MovsTempTable)
            
            SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
            BEGIN TRAN transac

INSERT ProcesosMasivos(Fecha)
VALUES (@fechaProceso)
DECLARE @IDprocesoMasivo INT = (SELECT MAX(ID) FROM ProcesosMasivos)

INSERT Emails(Texto)
SELECT M.TextoEmail
FROM @MovsTempTable M
ORDER BY M.ID

DECLARE @lastID INT = (SELECT MAX(ID) FROM @MovsTempTable)

INSERT Movimientos(FK_Empleado, FK_TipoMov, FK_Email, Fecha, Monto, FK_Proceso)
SELECT M.IDEmpleado, 2, @lastID - @QEmpleados + M.ID, @fechaProceso, 1, @IDprocesoMasivo
FROM @MovsTempTable M
ORDER BY M.ID

UPDATE Empleados
SET SaldoVacaciones = SaldoVacaciones + 1
WHERE ID IN (SELECT M.IDEmpleado FROM @MovsTempTable M)

COMMIT TRAN transac
        END TRY        
        BEGIN CATCH
RETURN -1
IF @@TRANCOUNT > 0
ROLLBACK
            ROLLBACK TRAN transac            
        END CATCH
        RETURN 1
END

Tiempo estimado de la tarea: 2 horas.
Tiempo de investigacion sobre funciones y manejo de fechas: 2 horas.
Pruebas y solucion de errores: 1 hora.
Total 5 horas.

Actualizacion de procedimientos almacenados

Se actualizaron algunos procedimientos almacenados que tenian fallos. Y se agregaron nuevos procedimientos necesarios para el sistema.

Procedimientos Actualizados:

• ProbarLogin (Se incluyó el manejo para la tabla de administradores que no estaba en un principio).
• CambiarEstadoSolicitud (Se simplifico con respecto a la vesion original).
• InsertMovManual ( Se depuró y agrego codigo necesario para su correcto funcionamiento, pues al principio tenia exceso de codigo y generaba algunos errores.

Procedimientos nuevos:

• GetEmpleadosCumpleMes
• Se encarga de obtener un filtro de los empleados que estan cumpliendo un mes mas desde que entraron a trabajar, y recibe como parametro principal la fecha a consultar.
• GetProcesosMasivos
• Devuelve todos los procesos masivos que se han ejecutado.
• GetEmpleadosFiltrados
• Similar a GetAllEmpleados, pero utiliza un filtro para devolver unicamente los empleados con parentezco en el nombre que es el parametro principal que recibe el SP.
• SelectCostosXEmpleados
• Desde una fecha de inicio a una fecha de fin se encarga de devolver el costo de las vacaciones que disfrutaron los empleados durante ese tiempo.
• SimulacionCreditoVacaciones
• Existe una entrada del blog dedicada unicamente a este proceso masivo.

Tiempo de realizacion de estas tareas: 8 horas total.

Desgloce: Escritura de los procedimientos: 3 horas.

Codificar llamadas desde la capa logica: 2 horas

Depuracion de errores: 3 horas.

Modificaciones al diseño de la Base de Datos

Durante el desarrollo del proyecto se ha presentado situaciones que no preevieron desde el inicio del diseño de la Base de Datos, es por este motivo que nos hemos visto obligado realizar algunos cambios en la estructura de Datos que se maneja para este proyecto. Entre esos cambios encontramos la creación de nuevas tablas en la BD, así como nuevos campos en algunas tablas ya existentes.
Dichos casos son los siguientes:

La tabla de TipoPuesto: 

La tabla de TipoPuesto está asociada a la  tabla Empleados, para determinar el tipo de cargo que tiene cada empleado, así como su salario, ya que este determina cuanto dinero le va a costar a la empresa otorgarle vacaciones.

La Tabla Administradores

La Tabla Administradores posee un "Foreing Key" de un empleado con el rol de administrador, con el fin de seleccionar el tipo de acceso que se le otorga a este tipo de empleados en la plataforma en linea.

La Tabla ProcesosMasivos 

La Tabla ProcesosMasivos almacena el registro de todos los procesos masivos que se llevan a cabo diariamente, con una fecha del día de ejecución y un estado del proceso que indica si se ejecutó correctamente. Esta tabla está relacionada a la tabla Movimientos ya que cada movimiento está relacionado a un proceso masivo.

Algunas Tablas existentes tuvieron algunas modificaciones debido a la agregación de nuevas tablas en el diseño de la BD, tal como se muestra a continuación:

La Tabla Movimientos

A la Tabla Movimientos se le agregó un "Foreing Key" del proceso Masivo que lo "invocó", ya que un moviento puede ser ejecutado por un proceso masivo o por un Empleado Administrador, en el caso de que un empleado administrador ejecute el movimiento, implica que el "FK_Proceso" sea NULL.

La Tabla Empleados

A la Tabla Empleados se le agregó el campo de "FK_TipoPuesto" ya que cada empleado tiene un tipo de ocupación y este define el salario que este recibe, además de su salario se calcula el costo que puedan tener las vacaciones que este individuo disfrute. Este Nuevo campo claramente debe estar relacionado con la Tabla TipoPuesto.

Tiempo Invertido:  30 minutos