Documento ilustrativo
- Fase
- Revisión y aprobación de documentos de proveedores — fase 1
- Versión
- propuesta v1 · ejemplo
El portal recibe los documentos del proveedor y los guarda. A partir de ahí, la revisión ocurre fuera del sistema: el analista avisa por correo, el proveedor responde con el archivo corregido y el estado de cada expediente vive en una hoja de cálculo.
Alcance
- Los estados del expediente —enviado, en revisión, observado, aprobado— y quién mueve cada uno.
- La devolución con observación escrita, visible para el proveedor dentro del portal.
- La corrección y el reenvío, conservando el identificador y el historial del expediente.
- La aprobación, restringida al rol autorizado y comprobada en el servidor, no solo en la pantalla.
- El historial consultable: quién cambió el estado, cuándo y con qué observación.
Exclusiones
- El registro inicial del proveedor: ya existe y no se toca.
- La homologación como servicio ni los criterios de evaluación: los define el área de compras.
- Cambios en el ERP ni migración de datos históricos.
- Notificaciones por correo o WhatsApp al proveedor.
- Carga masiva de expedientes.
Dependencias
- API del portal con lectura y escritura de expedientes
- Sin ella el recorrido no puede apoyarse en el dato real, y la fase cambia de forma.
- Un ambiente de pruebas con datos que no sean de proveedores reales
- Las comprobaciones se ejecutan ahí antes de tocar producción.
- Un usuario técnico con los permisos del recorrido
- Se necesita para probar cada rol, incluido el que NO debe poder aprobar.
- La lista de roles vigente y quién valida la entrega
- Es lo que decide la tabla de permisos y quién firma la aceptación.
Criterios de aceptación
- Con el usuario del proveedor A se ven sus expedientes y ninguno del proveedor B.
- Un expediente observado puede corregirse y reenviarse conservando su identificador.
- El rol de analista no puede aprobar: la acción no está en pantalla y el servidor rechaza la petición si llega por otra vía.
- Reenviar el mismo formulario no crea un segundo expediente; sube el contador de envíos.
- El historial muestra quién cambió cada estado, cuándo y con qué observación.
Las ejecuta quien valide por parte del cliente, sobre el ambiente de pruebas y con la versión identificada en la entrega. No hace falta saber programar para repetirlas.
Riesgos
- La API del portal no expone el cambio de estado
- La fase se replantea: primero definir esa dependencia, después implementar. Se dice antes de firmar, no a mitad de camino.
- Los roles vigentes no coinciden con los que el área describe
- Se acuerda la tabla real antes de escribir código. Suele salir en la primera revisión.
- El ambiente de pruebas no está disponible
- Se pospone el inicio. No se prueba contra producción con datos de proveedores reales.
Entregables
- El código, en el repositorio que indique el contrato.
- Las cinco comprobaciones, escritas para repetirlas.
- El registro de decisiones tomadas durante la fase.
- Notas de instalación y la versión identificada.
- Los pendientes detectados que quedaron fuera del alcance.
El importe no aparece aquí porque depende de cuántos estados tenga el recorrido, cuántos roles intervengan y de qué exponga el sistema. Lo fijo es la forma: el precio se cierra sobre este mismo documento, con el alcance y las exclusiones ya escritos.