Revisión modelo de datos CORE gestión contractual

[edwargl7]

Se requiere realizar la revisión cruzada del modelo de datos propuesto en la Issue #100 y el modelo de datos del sistema actual, para garantizar que se cumpla con el soporte del modelo de datos requerido para la migración y ejecución de la nueva versión.

Tablas:

• contrato
• contra_arrendamiento
• contrato_cancelado
• contrato_cps
• contrato_liquidado
• contrato_suscrito
• contrato_disponibilidad
• registro_presupuestal_disponibilidad
• contrato_estado
• estado_contrato
• contrato_general
• item_contrato
• orden
• servicio_contrato
• supervisor_contrato
• estudio_documento_previo
• lugar_ejecucion

Sub Tareas

• [x] Revisión tipos de datos.
• [x] Campos faltantes en el modelo propuesto.
• [x] Tipos de datos diferentes entre el modelo propuesto y modelo actual.

Criterios de aceptación

• [x] Documentación de la revisión de la Issue.

Requerimientos

No aplica

Lineamientos Modelos de datos

1. Lineamientos modelos de datos relacional
2. Lineamientos Modelos de Datos en Mongo

Definition of Ready - DoR

• [x] Está refinada y estimada en puntos de historia por el equipo.
• [x] Incluye la descripción y criterios de aceptación, con el detalle funcional y especificaciones técnicas, de forma entendible por cualquier miembro del equipo.
• [x] No tiene bloqueos que impidan su ejecución.
• [x] Las dependencias están identificadas y resueltas.
• [x] Puede ser probada dentro del Sprint.

Definition of Done - DoD - Desarrollo

• [x] Criterios de aceptación cumplidos.
• [x] Documentación de issue realizada.
• [x] Aprobada por SM/Líder técnico.

[edwargl7]

[edwargl7]

Se realiza reunión con el equipo DBA para consulta sobre manejo de información presupuestal si mantenerla en una misma tabla/colección o especializar la tabla, y por el manejo requerido en el que en la mayoría de casos de los flujos siempre es requerida la información presupuestal y el tipo de relación es uno a uno. Se sugiere mantener todos estos datos dentro del mismo similar al modelo de datos de ARGO actual.

[Lau2ri]

Se comenzará con la revisión de las tablas que se mantienen "iguales" entre los dos modelos de datos y posteriormente se seguirá con las tablas que fueron removidas o "reubicadas" en otras tablas en el nuevo modelo.

Revisión de las tablas:

contrato_arrendamiento:

• se añade la llave foránea con contrato_general
• se mantienen todos los demás los campos originales con sus tipos de datos
• se agregan los campos obligatorios por lineamientos

contrato_estado:

• se cambia el nombre de la tabla a _estado_contrato_
• se añade la llave foránea con contrato_general
• se agregan los campos obligatorios por lineamientos
• cambio de tipo de dato de usuario de string a number (usuario_id)
• se añade un campo de motivo, se mantiene la fecha de registro con el nombre de fecha_ejecucion_estado y mantiene la relacion con estado y con contrato_general

estado_contrato:

• se cambia el nombre de la tabla a estado
• se mantiene su campo nombre, se agrega campo de descripción y se remueve la fecha de registro
• de los campos obligatorios por lineamientos solo se tiene el booleano de activo, no se añaden fecha_creacion ni fecha_modificacion

item_contrato:

• se añade el campo de direccion
• se mantienen todos los demás campos originales con sus respectivos tipos de datos
• se añade la llave foránea con contrato_general además de tener el campo numero_contrato
• se remueve el campo vigencia, que vendría heredado del contrato_general que ya tiene una vigencia
• se agregan los campos obligatorios por lineamientos

supervisor_contrato:

• se remueve la redundancia quitando el campo cargo y dejando únicamente cargo_id
• se remueven los campos documento y estado
• se mantienen todos los demás campos originales con sus respectivos tipos de datos
• se añade la llave foránea con contrato_general
• se agregan los campos obligatorios por lineamientos

lugar_ejecucion:

• se mantienen todos los campos originales con sus tipos de datos
• se agregan además los campos pais_id, municipio_id para mayor especificación
• se añade la llave foránea con contrato_general
• se agregan los campos obligatorios por lineamientos

[Lau2ri]

Revisión de las tablas faltantes:

contrato_general:

Todas las siguientes tablas fueron unificadas en la tabla de contrato_general:

• contrato

  • El campo vigencia se mantiene
  • El campo estado_registro cambia a estado siendo una llave foránea de la tabla estado, por lo que considero que debería llamarse _estadoid
  • El campo perfil se mantendría en el campo _perfil_contratistaid, sólo que cambia su tipo de dato de string a number
  • Los campos relacionados con el número y vigencia del convenio estarían registrados en la nueva tabla convenio

• contrato_cps

  • Los campos numero_contrato y perfil se mantienen solo que con nombres diferentes, siendo ahora id y _perfil_contratistaid, el campo vigencia se mantiene igual

• orden

  • Por medio del campo _tipo_compromisoid se identificaría si el contrato es de orden o de otro tipo
  • Se mantienen los campos de estado y poliza con el nombre de _aplicapoliza

• registro_presupuestal_disponibilidad

  • Se transformó en el campo _sujeto_rp_hasta finpresupuesto
  • Sus campos se mantienen en la tabla de _registro_presupuestal_

Las siguientes tablas se transformaron en estados de un contrato en la nueva tabla estado:

• contrato_cancelado
• contrato_liquidado
• contrato_suscrito

La últimas tablas:

No se encuentran registradas en el modelo de manera directa, habría que analizar si no se están teniendo en cuenta por alguna decisión o si se encuentran registradas en las tablas pero no de manera directa o evidente:

• contrato_disponibilidad
• servicio_contrato
• estudio_documento_previo

[edwargl7]

La tabla de estudio_documento_previo dado que es solo un campo en el modelo actual se agrupa con el campo de fecha_suscripcion_estudio en el modelo propuesto.

La tabla contrato_disponibilidad se renombra con la colección cdp.

Pendiente revisar el uso de la tabla servicio contrato.

[Lau2ri]

Revisión de tipos de datos diferentres entre modelos

Tablas:

contrato_general

• forma_pago: number -> string
• perfil_contratista_id: se repite 2 veces
• datos de solicitante se ubican en una tabla nueva solicitante
• tipo_compromiso: number -> string
• clausulas_contractuales se ubica en una colección de tablas aparte
• usuario ya no se encuentra

De todos las siguientes tabablas el cambio principal es que el tipo de dato de vigencia cambia de number a string:

• contrato
• contrato_cps
• orden
• registro_presupuestal_disponibilidad

contra_arrendamiento

• se mantiene todo igual

  contrato_disponibilidad

• se mantiene todo igual

  contrato_estado

• usuario: string -> number

  estado_contrato

• se mantiene todo igual

  item_contrato

• estado: bool -> string

  supervisor_contrato

• cargo_id: number -> string
• tipo: number -> string
• documento ya no se encuentra

  lugar_ejecucion

• se mantiene todo igual

[edwargl7]

Muy buena revisión y documentación de las diferencias encontradas. Es bastante útil para la etapa de migración.

contrato_arrendamiento:

• En el modelo nuevo se puede remover de la colección contrato_arrendamiento la relación numero_contrato y vigencia utilizada en el modelo actual como foránea compuesta.

item_contrato:

• Se puede remover los campos estado y numero_contrato. Estado es reemplazado por activo y numero_contrato es reemplazado por contrato_general.

contrato_general:

• El campo estado de la colección contrato_general se podría remover pero es necesario establecer como se va a identificar el estado actual del contrato, si ese campo en el modelo propuesto va a ser usado con ese fin puede mantenerse.
• Confirmar los datos almacenados en el campo perfil del modelo actual (tabla contrato).

Los cambios identificados se aprueban para la actualización del modelo propuesto. Revisar tablas que requieren datos adicionales de migración de usuario (abogado) en la migración y la adición de los usuarios aprobadores (ordenador, contratista) que a su vez hacen parte del proceso de firma del mismo.

Es bueno almacenar el resultado esta Issue en un documento que permita un apoyo en la etapa de migración.