ya que previamente se habia mencionado que el mid no proporcionaba todos lo datos para cada fila de la tabla de plan de adquisiciones , dicha falencia se ha cubierto y ahora se debe de integrar dicho complemento

• Validar que este repo se esté reportando en sonar.
• Colocar el badge de "code coverage" en el README.md (De no existir, crearlo de acuerdo a los lineamientos. Tomar como referencia alguno de otro repo equivalente)
• Ajustar el desarrollo para que se calcule el "code coverage" adecuadamente
• (Si aplica) Actualizar el .drone.yml

Empezar después de udistrital/plan_adquisiciones_mid#43

con la finalidad de poder proporcionar una versión en pdf del plan de adquisiciones se requiere revisar la librería pdfmaker , usando su editor web , realizar la plantilla de como quedaría la versión pdf del plan de adquisiciones. para finalizar la tarea se requiere:

• dar muestra el pdf resultante.
• subir al presente issue el código para armar la plantilla

en continuación al issue #35 se requiere que en la acción de la tabla se pueda consultar la versión del plan de adquisiciones y poderla mostrar a nivel de consulta y no de edición

Depende de #79

se requiere usar el api crud de plan de adquisiciones para los siguientes módulos de la aplicación

• lineamientos

• metas

• actividades

garantizando:

• transacciones

• manejo de errores

• paso de información entre los diferentes componentes

• acceso a la información

en la tabla donde se ve el resumen del plan de adquisición se requiere agregar un boton que cambie usando switch case, dicho boton tendra las siguientes funcionalidades:

• si el plan de adquisiciones no esta publicado el boton deber de tener el nombre de publicar, esto realizara una peticion al mid que se encargara de cambiar el estado del plan de adquisiciones y hacer una copia en mongo.

• cuando ya esta publicado el boton deberá de tener el nombre similar a publicar nueva version , donde el mid realizara una nueva copia del plan de adquisiciones en mongo

en base a los mockups creados para el subsistema del plan de adquisiciones en el issue #2 y usando el código base mencionado en el issue #1 se requiere crear la vista sin aun conectarse con el back el cual aun no existe, dicha vista debe ser un crud de los lineamientos. si hay datos que ya pueden consumirse de apis existentes esto es un punto a favor

realizar conexión con el back para poder ingresar cara registro (renglon) del plan de adquisiciones , validando que solo se puede hacer post si es la primera vez que se realiza el registro

se requiere crear vista de en la cual se permitan ver las versiones de un plan de adquisiciones, para ello se requiere

• en la tabla que muestra los planes de adquisición, añadir una tercera acción, la cual permitirá direccionar a una nueva vista para ver las versiones del plan .

• creaar una ruta adicional en la cual se permita ver la lista de versiones del plan de adquisiciones, esta lista tendrá una accion por cada fila, dicha acción servirá para ver la versión pero de momento esa función extra no se creara

Depende de #80

De los planes de adquisiciones activos (confirmar con Analista/HUs/mock-ups si adicionalmente deben de estar publicados, para cada caso), poder seleccionar

• 1. Crear/Definir un parámetro en configuracion_api para guardar el activo
• 2. Crear/Definir un parámetro en configuracion_api para guardar el que se va a usar con el Idexud
• (Cargar/Usar 1. y 2. de este Issue en 1. y 2. de udistrital/necesidades_cliente#257)
• 3. (Depende de 1.) Implementar el Select para el plan de adquisiciones activo
• 4. (Depende de 2.) Implementar el Select para el plan de adquisiciones que se va a usar con el Idexud

NOTA: Ni el 1. Ni el 2. dependen de #80, se pueden desarrollar de inmediato

Se requiere realizar una copia de un cliente ya existente en la organización y subir su código con las 3 ramas principales este repositorio, para ello se ha de tener en cuenta lo siguiente:

• se debe de informar de cual cliente se realizara la copia según la estructura del proyecto (ya qe entre varios proyectos existen variaciones"

• se deben de mantener en este repositorio las ramas principales , tal como están definidas en los lineamientos
  primero se debe de subir la rama master

• realizar limpieza de código de tal manera que no se mantenga código del aplicativo del cual se hizo la copia , con la finalidad de no mantener código basura.

Consideraciones / Referencias

• Inventario de Desarrollos
• Apuntes Brayan
• Sprint Review/Planning 8 nov - @AlexFBP colocar video!

Ajustes

Prioridad: A: Alta - M: Media - B: Baja

Gestión de Actividades

• (P:B) "El panel de Crear/Editar actividad se muestra por defecto, debería estar oculto y mostrarse solo con click en "Agregar nueva actividad""

Gestión de Metas

• (P:B) "el botón de Editar debería desbloquear los campos de la meta, y que después de desbloqueados, pase a llamarse "Guardar""
• (P:M) "No hay forma de borrar actividades y/o metas, o al menos de desactivarlas"
• (P:B) "Al editar una meta el botón de cancelar, si no se hizo nada, no hace nada, debería cerrar el modal"
• (P:B) "el panel de "Crear Meta" se muestra por defecto, mostrar solo con el botón de "Agregar Nueva Meta""

Creación y Edición de Datos básicos de un plan

• (P:M) "Si se edita cambiando la vigencia, bota error sin mensaje" (Confirmar, intentar repetir)

Detalle del Plan

• (P:B) Reordenar los pasos: Rubro, Metas, Actividades, Productos, Codificacion UNSPC (Arka) y Datos del Responsable
• (P:B) (Desarrollo por confirmar con Analista) "queda la duda con los productos, hay que seleccionar de Arka y Presupuesto..." Puede que solo sea necesario el Catálogo de Arka Cambiar nombre del que NO es Arka a BogData
• (P:NA) (Desarrollo por confirmar -en Necesidades- con Analista) "En la necesidad debería tomarse automáticamente del plan: La duración del contrato, el responsable del estudio, y las modalidades de selección/contratación" No necesariamente, mantener por aparte
• (P:M/B) "Al momento de asignar una fuente de financiamiento debería restringirse volver a seleccionar la misma fuente porque si se escoge nuevamente, se descarta la asignación anterior desde esa fuente. O al menos alertar que esto es lo que se sobreescribirá la asignación anterior de la misma fuente"
• (P:B) "Con 3-01 la actividad debería ocultarse, en vez de mostrar la rayita"
• (P:N/A) "Traer rubros con pre asignación inicial aprobada"
• (P:M) "El valor de la fuente de financiamiento está abierto, ojo!" - Ajustar para Inversion
• (P:M) (por confirmar si sí es así) En inversión (Rubros 3-03) se puede colocar cualquier valor para una actividad. Ajustar para que la suma de actividades sea menor o igual al rubro

Otros

• (P:M) Código y nombre en el select de fuentes (que sean un solo campo?, no tiene sentido mostrar el código aparte)
• (P:A) Problema al leer actividades en rubros de funcionamiento
• (P:A) Valor de la fuente igual o menor al del rubro

con base a la socializacion del plan de adquisiciones #54 se requiere presentar propuestas de los cambios a realizar

se requiere en el aplicativo de configuracion realizar el respectivo registro del menu para el aplicativo de plan de adquisiciones

se requiere consultar la procedencia de datos que se requieren de apis de terceros a usar en el aplicativo

Segun las revisiones del plan de adquisiciones presentadas por la analista, es necesario realizar los cambios respectivos:

Formato de Revision:
https://docs.google.com/spreadsheets/d/1cpo0TDaL_7vdN5dUNfFCfXN_hcpdQuaNAfqEJSofpjY/edit?ts=60343006#gid=0

Usar este Issue para documentar apartados de código que funcionan pero requieren un trabajo adicional

al finalizar el issue #13 se debe de crear un componente con sus respectivas acciones para la tabla en la cual se registraran los productos de arka

para cumplir esta tarea se necesita adicionalmente realizar el get de los registro del pal de adquisiciones. y realizar un get del registro (renglon) especifico.

validando que no es la primera vez que se crea el registro, el put se debe hacer sin importar que se actualice sea algo menor o no, el mid realiza las respectivas validaciones.

se requiere crear mockups web para plan de adquisiciones con el fin de definir detalles del desarrollo

se requiere realizar pruebas de funcionalidad al cliente en busca de posible bugs o fallos de la aplicación y listarlos en una tabla en el presente issue

ya que hay dudas sobre el uso de lineamientos o u implementación para el plan de adquisiciones, se quiere realizar la respectiva reunión y definir este tema

Consideraciones

De manera similar a udistrital/necesidades_cliente#242

Tareas

• Identificar los parámetros asociados al cliente de Plan de Adquisiciones
• Clasificarlos según si el cliente del Plan de Adquisiciones tiene dominio o no sobre los parámetros identificados

Fecha estimada maxima: 14/01/21

crear como un paso exra en el step , dicho paso no es obligatorio de diligenciar, en este paso se creara a manera de solo maquetacion la FICHA DE ESTADÍSTICAS BÁSICAS Y DE INVERSIÓN Y DE METODOLOGÍA GENERAL AJUSTADA

en base al issue #2 crear la vista y el formulario del registro del plan de adquicisiones

se requiere cargar plan de adquisiciones de la vigencia 2021 a la API de Plan de Adquisiciones con el fin de consumirse en el cliente de necesidades

re requiere realizar los procesos POST, PUT Y GET de la tabla de ficha estadísticas.

para el post y el put es lo normal de como se realizan peticiones.

para el get hay un pequeño cambio ya que un plan de adquisiciones puede tener muchas tabla , y cada tabla va anclada a un solo rubro, adicionalmente en varios"renglones" se puede compartir la misma tabla , si y solo si los renglones tienen el mismo rubro, por ende se recomienda usar la siguiente petición

http://localhost:8080/v1/Ficha_EB_IMGA/?query=PlanAdquisicionesId:{Id plan adquicisiones},Rubro:{rubro}

dicha vista es basada en el resumen de la tabla del pan de adquisiciones, esto con la finalidad de tener una vista iniciar para añadir cada registro del plan de adquisiciones

se requiere que al ingresar una fuente de financiamiento a una actividad, alli se colocara el valor asignado a la fuente y el cliente ya sea con un pipe u otra funcionalidad debera de calcular el porcentaje de ese valor sobre el porcentaje de la actividad. Es decir

• en la actividad se ingresa un valor de 100000
• y para una fuente fe financiamiento se le asigna 60000 el campo de porcentaje deberá parecer en 60% automaticamente.

adicionalmente se debera de validar que no se supere el 100%, es decir que el valor ingresado no sea mayor al 100% adicionalmente si ya se ingresaron otras fuentes que la suma de los valores asignados no supere el 100%

Consideraciones

• De la Revisión/problema mencionado en el Daily del 30 de Diciembre:
  • Pareciera que al momento de editar un rubro (con el fin de preparar una nueva versión, antes de) del plan de adquisiciones a los ID se les están sumando una constante

Tareas

(TODO: Por Definir)

tabla donde están todos los planes de adquisiciones , luego de ello para crear uno nuevo pida los datos básicos del plan y luego de ello si se proceda a su creación

se permite el crear datos de pruebas en el entorno montado con docker para realizar pruebas

se requiere creación de vista crud para actividades (sin conexión aun a base de datos

se requiere revisar los archivos de interface en los cuales se exportan interface tando de configuracion para las tablas y de datos de prueba.

se requiere:

• eliminar todos los datos de prueba que ya no se usen.
• cambiar el nombre de las configuraciones a un nombre mas explicito, ya no es valido decir que son de prueba ya que los módulos ya están listos, al cambiarlos en los archivos de interface es necesario cambiarlos donde son importados (se recomienda usar el buscador de visual studio code)