Un solo proceso de compras, desarrollado en cuatro bloques

Esta solicitud forma parte de la mejora del módulo de Compras y contratación para proyectos de CONSOF. El resultado conjunto debe permitir gestionar una operación desde la requisición hasta su cierre, conservando el vínculo entre solicitud, negociación, orden/contrato, ejecución, documentos, costos y pagos.

Los cuatro issues distribuyen el desarrollo del mismo proceso. Deben compartir registros y permitir continuar la operación entre pantallas con los datos ya capturados y las aprobaciones aplicables. Reutilizar los componentes existentes de presupuesto, costos/CxP, tesorería y logística.

La numeración no define una secuencia rígida: el control financiero comienza al confirmar el compromiso; la logística interviene durante la ejecución; anticipos y prepagos pueden preceder a la recepción y facturación.

Bloques: 1. Requisición y contratación #179 · 2. Documentos, costos y CxP #180 · 3. Compromisos y pagos #181 · 4. Logística y alquileres #182.

Alcance de este bloque: compromiso y proyección desde el acuerdo de compra, y programación, autorización, registro de pagos y saldos durante su ejecución. Utiliza las mismas obligaciones del #180 y los hechos operativos de #179/#182. El recorrido completo y su prueba conjunta están en #179.

Resultado que necesitamos

Que el ERP muestre las salidas previstas desde que se confirma una compra/contratación y permita programar, autorizar y registrar sus pagos. Debe utilizar los registros de compra, factura y recepción existentes, con saldos que se actualicen sin capturas duplicadas.

Adaptar CxP, registro de pagos y dashboard financiero; referencias de pantallas en #57/#58/#75. Configurar actualmente preparación/ejecución para Sirley y autorización para David mediante permisos de #94/#95.

1. Recibir los eventos que afectan dinero

Relacionar cada efecto con operación, línea/hito y documento. No sumar la totalidad del compromiso más la totalidad de su factura como dos salidas diferentes. Los pagos/prepagos ya realizados deben cubrir la parte correspondiente de esa proyección.

Un borrador de orden no crea compromiso; su confirmación sí. El acuerdo registrado por un usuario con facultad delegada debe aparecer en la proyección inmediatamente, sin esperar otro clic de autorización ni factura.

2. Pantalla de compromisos y proyección de caja

Mostrar por proyecto, tercero, operación y fecha:

• Total acordado, cambios, ejecutado, pendiente de ejecutar y documento de origen.
• Salidas estimadas por anticipo, corte, saldo, alquiler, flete y otros hitos.
• Obligaciones reconocidas, vencimientos, pagos aplicados y saldo.
• Anticipos/prepagos, retenidos, depósitos y restricciones, identificados por separado.
• Importe con fecha estimada cuando todavía no hay vencimiento definitivo; el usuario debe poder distinguir estimación y obligación confirmada.
• Caja prevista antes/después del pago propuesto y alertas de insuficiencia.

Consumir presupuesto/costos del #97 y proyecciones de ingresos existentes (#78/#80). No volver a pedir esos totales ni duplicar el ingreso al pasar oportunidad a proyecto. Presupuesto, compromiso, costo ejecutado y pagado deben ser columnas distintas; pagar no crea otro costo.

Permitir definir el marco de autorización financiera: periodo, proyectos, importes y condiciones admitidas. #179 debe consultar ese marco y solicitar revisión cuando la nueva fecha/importe lo exceda.

3. Calcular condiciones y vencimientos por operación

Al crear el acuerdo, traer una sugerencia del tercero y permitir elegir condición por hito. Guardar en la operación: importe/porcentaje, evento inicial, plazo, tipo de días, periodicidad, fecha resultante, evidencia y autorización. Cambiar el maestro después no modifica acuerdos existentes.

Configuración inicial

La regla de documento/autoridad del #179 se aplica aparte: exactamente $1M de transporte puede tener pago rápido y requerir orden. Recalcular facultad sobre el acuerdo completo, no permitir eludirla separando viajes.

Seleccionar el evento de inicio según documento/hito: recepción de factura electrónica conforme; entrega/prestación efectiva para cuentas de no obligados y supuestos no electrónicos configurados; solicitud con requisitos objetivos cumplidos o fecha pactada para anticipo; terminación para transporte inmediato; corte pactado para servicios recurrentes.

Conservar recepción original, ejecución, revisión, corrección/subsanación, vencimiento, programación y pago. Las aprobaciones internas no reinician el plazo. Cualquier ajuste de vencimiento debe registrar motivo, fundamento, fechas y autorización aplicable. Permitir parametrizar el límite legal aplicable por caso; no añadir plazos de revisión al final del plazo de pago.

Configurar calendario de días hábiles/no bancarios y zona local de negocio (#120). Si una obligación vence antes del siguiente miércoles, proponer el miércoles previo o pago extraordinario dentro del plazo. Si no hay caja, mostrar la alerta y el vencimiento original, sin ocultar atraso.

4. Bandeja de programación y autorización

• Listar obligación/hito, tercero, proyecto, saldo, fecha de vencimiento, tipo de desembolso, conformidades y restricciones.
• Permitir seleccionar una o varias obligaciones, proponer fecha/importe, pagar parcialmente y ver el efecto sobre caja.
• Enviar la propuesta al autorizador correspondiente; permitir aprobar, devolver con observación o rechazar, conservando usuario/fecha/importes.
• Mostrar estado Por programar, Propuesto, Autorizado, En ejecución, Pagado parcial, Pagado total o Fallido; mantener restricción de pago como dato separado con motivo/importe/hito.
• Traer las validaciones de #179/#180/#182. No pedir de nuevo aprobación técnica de un corte ya aceptado.
• Impedir sobreprogramar/sobrepagar el mismo saldo entre lotes o usuarios concurrentes.
• Mostrar beneficiario, cuenta/medio, importe y aplicaciones antes de autorizar. Si cambian datos relevantes después, pedir revisión de la autorización que quedó desactualizada.
• Usar documentos propios del anticipo/prepago; no exigirles factura de ejecución final para habilitar la solicitud.

Una autorización de compromiso puede incluir autorización de desembolso si así se registra explícitamente. El sistema debe distinguir ambos alcances y el hecho de pago.

Cupo para transportes pequeños

Permitir al autorizador crear un cupo con importe total, inicio/fin de vigencia, proyectos, conceptos y máximo de $1M por servicio. Mostrar usado, reservado y disponible.

Cuando un servicio recibido y soportado cumple esas condiciones, permitir ejecutarlo bajo la autorización del cupo. Validar saldo y vigencia; rechazar aplicación de anticipos, depósitos u otros conceptos no cubiertos. Sin cupo vigente/suficiente, enviar a autorización individual. No configurar un importe semanal fijo no indicado por el usuario autorizado.

5. Registrar un pago efectivo

Desde el pago autorizado, ofrecer la acción Registrar pago con datos precargados y estos datos reales: fecha, importe, medio/cuenta de salida, beneficiario, referencia, soporte y distribución entre obligaciones/conceptos.

Al confirmar:

1. Guardar el movimiento y su evidencia.
2. Aplicar el importe una sola vez al saldo de origen.
3. Actualizar CxP, caja, detalle de operación y vistas relacionadas.
4. Vincular/generar el comprobante y permitir su descarga o envío registrado.

Programar, autorizar, cargar un archivo sin confirmación o registrar una transferencia fallida no debe reducir deuda. El botón registra un pago realizado; esta entrega no conecta el ERP al banco para ordenar transferencias.

Admitir número abierto de pagos parciales, una factura con varios pagos y un pago aplicado a varias facturas. La suma de aplicaciones debe coincidir con el movimiento. Doble clic/reintentos no generan otro pago. Un registro previo de contado se cruza al llegar la factura; no se paga otra vez.

Permitir registrar pago realizado en contingencia con fecha original. Una corrección o devolución bancaria debe generar reversión trazable, conservar el movimiento original y reabrir únicamente el saldo afectado.

6. Controlar estos saldos de forma independiente

Traer datos y ajustes del #180, y devolución/periodos del #182. Una devolución física no prueba recuperación de depósito; pagar factura final no prueba devolución de equipo. Aplicar depósito a daño o reconocer saldo por devolver de un prepago requiere liquidación sustentada; no hacerlo automáticamente.

La liberación del retenido utiliza sus condiciones y fecha propias, no añade por defecto el plazo del saldo final. Mostrar qué requisito impide liberar y la acción pendiente.

Caja menor utiliza entregas y legalizaciones del #180: reposición, devolución o reembolso real deben conservar origen y responsable. No crear un segundo gasto al reponer un fondo.

7. Consultas y consistencia

• Acceso desde CxP al documento, acuerdo, cálculo, restricciones, autorizaciones, pagos y comprobantes.
• Filtros por proyecto/centro, tercero, fecha, vencimiento y estado; cada total indica qué incluye y permite abrir su detalle.
• Encabezado del nuevo pago, detalle de CxP y dashboard muestran el mismo saldo, distinguiendo pendiente por ejecutar, pendiente de factura y pendiente de pagar.
• Importes aprobados y etiquetas legibles; proveedores históricos visibles aunque su vínculo requiera regularización (#58/#75).
• Cierres financiero, técnico, documental y logístico separados; la acción pagar no marca cumplidos los demás.
• Mantener identificadores/documentos y conciliar saldos al migrar; reimportar histórico no debe generar otra deuda/pago.
• Restricción de acceso por función/proyecto; asignar rol operativo no concede acceso financiero general.

8. Pruebas de aceptación

Enlaces: Contratación #179, Contable #180, Logístico #182.

Continuidad: recoge integración/saldos/pagos de #57/#58 y componentes de #25/#31/#59/#75. Dependencias existentes: #94/#95, #97, #78/#80, #109, #120 y #155. #180 reconoce una obligación única y este bloque aplica sus pagos; no crear otra CxP.