Negocios / Deals de Crédito

Requisitos previos de acceso

• Permiso (módulo): viewCredits (acceso al listado). Aprobar/rechazar exige creditDealApprove / creditDealReject; cancelar usa creditDealReject.
• Licencia/Feature: CREDIT_INVESTMENTS habilitada en la licencia del tenant (Vault).
• Contenedor del menú: TOKENIZACIÓN → grupo Crédito Tokenizado

Qué es / cuándo usar

La pantalla de Negocios / Deals es el centro de la operación de crédito: cada deal es una operación de anticipación/cesión de cuentas por cobrar que reúne un originador (cedente), una o más cuentas por cobrar, un inversor (o pool de inversores en la modalidad fraccionada), el template de precios y la cascada de liquidación. Aquí es donde el operador hace seguimiento del ciclo de vida de la operación — desde borrador hasta liquidada — y ejecuta las decisiones de aprobación, rechazo y cancelación.

Use esta pantalla en el día a día para aprobar operaciones que pasaron la evaluación de riesgo, rechazar las que no deben continuar y cancelar operaciones ya en curso (con motivo registrado). La creación típica la realiza el originador en el Midas-Web; el BackOffice ofrece el botón Crear para casos manuales.

Requisitos previos

• Permiso: viewCredits para ver la lista; creditDealApprove/creditDealReject para las acciones (permiso doble — enum estático CPM en el backend + módulo dinámico en la BD que controla los *ngIf/*appHasPermission de los botones; ambos deben estar activos).
• Licencia/Feature: CREDIT_INVESTMENTS habilitada. Sin ella, el grupo Crédito Tokenizado ni siquiera aparece en el menú.
• Dependencias de otras pantallas: el originador y el inversor deben existir como Partes aprobadas; las Cuentas por cobrar deben estar registradas/aprobadas; idealmente ya existen Templates de Precios, Cascata (Waterfall) y Fuentes de Funding.

Paso a paso

1. Acceda al menú Crédito Tokenizado → Negocios / Deals.
2. Use la búsqueda para localizar por número de deal/originador/inversor.
3. Haga clic en una fila (o en el menú ⋮ → Visualizar) para abrir los detalles del deal.
4. Para operaciones en estado PENDING, use ⋮ → Aprobar o ⋮ → Rechazar.
5. Para operaciones ya en curso (no DRAFT/CANCELLED/SETTLED), use ⋮ → Cancelar y complete el motivo/tipo de cancelación en el diálogo.

Filtros y columnas

Columna	Qué muestra	Origen del dato
Número del Deal	Código identificador de la operación (dealNumber)	Deal.dealNumber
Originador	Cedente de la operación (ID/nombre, truncado a 8 chars en el listado)	Deal.originatorId (resuelto a nombre cuando disponible)
Inversor	Inversor titular; — si aún está en captación fraccionada	Deal.investorId
Estado	Etapa del ciclo: DRAFT, PENDING, APPROVED, FUNDED, DISBURSED, PARTIALLY_SETTLED, SETTLED, CANCELLED, FULLY_FUNDED, OPEN_FOR_INVESTMENT	Deal.status
Valor Bruto	Valor nominal de las cuentas por cobrar	Deal.grossAmount (BigNumber en el backend)
Valor Neto	Desembolso neto al originador (bruto − descuento − comisiones)	Deal.netDisbursement
Tokenización	Si la operación fue tokenizada y cuántas unidades emitidas	Deal.tokenizationStatus / tokenizedUnits
Creado en	Fecha/hora de creación	Deal.createdAt

La búsqueda filtra la lista; el estado no tiene desplegable propio en esta pantalla — use la búsqueda y la columna Estado para la triaje.

Acciones y modales

• Visualizar: abre los detalles completos del deal (credit-deals/view/:id), incluyendo cuentas por cobrar, precios, contrato, tokenización y pestañas relacionadas.
• Editar: disponible solo en DRAFT (credit-deals/edit/:id). Las operaciones ya enviadas no son editables desde el listado.
• Aprobar: ejecuta approveDeal(id) tras confirmación (bottom-sheet). Mueve el deal de PENDING a APPROVED, disparando la evaluación de las Políticas de ámbito DEAL. Solo aparece con creditDealApprove.
• Rechazar: ejecuta rejectDeal(id) tras confirmación. Termina la operación como rechazada. Solo aparece con creditDealReject.
• Cancelar: abre el diálogo de cancelación (motivo + tipo de cancelación), luego confirma vía bottom-sheet y llama a cancelDeal(id, userId, motivo, tipo). El userId del operador logueado se graba como responsable. Disponible para cualquier estado excepto DRAFT, CANCELLED y SETTLED.

Por ser decisiones financieras sensibles, aprobar/rechazar/cancelar pueden disparar step-up (re-autenticación contraseña + MFA, header X-Step-Up-Token, ventana de 5 min) según la configuración del entorno. Step-up no es aprobación 4-eyes — solo reconfirma la identidad del operador.

Reglas de negocio / consideraciones

Atención

• La aprobación dispara evaluación de riesgo. Al aprobar, las Políticas de ámbito DEAL son evaluadas; una política con acción REJECT reprobada puede bloquear la operación o forzar revisión.
• Editar solo en DRAFT. Una vez enviada, la operación no vuelve a ser editable desde el listado — corrija vía cancelación + nueva operación si es necesario.
• La cancelación exige motivo y tipo. El diálogo obliga a completar cancellationReason y cancellationType; esto alimenta el eventual flujo de reembolso (refundAmount/refundStatus).
• Modalidad fraccionada. En deals con targetAmount/raisedAmount, el inversor puede estar vacío hasta que la captación cierre (FULLY_FUNDED); la columna Inversor muestra — durante ese intervalo.

Irreversible

• La aprobación activa el flujo financiero aguas abajo (funding → desembolso → tokenización). No existe "desaprobar"; revertir exige cancelación con reembolso, que es un nuevo evento financiero auditado.

• Valores financieros: grossAmount, netDisbursement, discountAmount, feesAmount se tratan como BigNumber en el backend — la documentación y la UI los muestran formateados, pero nunca redondee al conciliar; verifique los decimales de la moneda del tenant.
• Estado APPROVED de los participantes: el desembolso al originador exige una Parte con estado aprobado; vea Partes.

Ejemplos

Escenario 1 — Aprobar una operación simple con inversor único

1. El originador creó el deal en el Midas-Web; llega como PENDING.
2. El operador lo localiza por búsqueda, abre Visualizar, revisa cuentas por cobrar y precios.
3. ⋮ → Aprobar → confirma. Las Políticas de DEAL se ejecutan; si pasan, el deal va a APPROVED y continúa hacia funding/desembolso.

Escenario 2 — Cancelar una operación ya desembolsada

1. El deal está en DISBURSED; se detectó fraude en la cuenta por cobrar.
2. ⋮ → Cancelar → completa el motivo "cuenta por cobrar inválida" y el tipo de cancelación.
3. Confirma; el sistema registra cancelledBy (operador), cancellationReason/cancellationType y prepara el reembolso (refundStatus). Considere abrir también una Recompra.

Escenario 3 — Operación fraccionada en captación

1. El deal está en OPEN_FOR_INVESTMENT con targetAmount definido; la columna Inversor muestra —.
2. Conforme los inversores aportan, raisedAmount crece; al alcanzar el objetivo el estado pasa a FULLY_FUNDED.
3. Solo entonces el flujo de desembolso queda habilitado.

Pantallas relacionadas

• Partes (deudor/cedente/inversor)
• Cuentas por cobrar
• Desembolsos
• Liquidaciones
• Recompras
• Tokenización de Crédito
• Crédito Tokenizado (índice del grupo)