--- audiencia: usuario screen_key: tesoreria/bancos aliases: [tesoreria, tesorería, bancos, banco, caja chica, fondo fijo, billetera, cuenta corriente, cuenta ahorro, transferencia, conciliacion, conciliación, extracto, cheque, cheques, cartera, posicion de caja, cash flow, flujo de caja, diferencia de cambio, multimoneda, multi moneda, configuracion de tesoreria incompleta, regla de tesoreria, reglas automaticas, PAGO_PROVEEDOR, mapeo contable vs tesoreria, no impacta tesoreria, orden de pago no aparece en caja] titulo: Tesorería y Bancos --- # Tesorería y Bancos — Guía para el Usuario Esta guía cubre el módulo **Tesorería y Bancos**: manejo de cuentas bancarias, cajas chicas, billeteras virtuales y cuentas en moneda extranjera; movimientos manuales; transferencias entre cuentas (mismo / distinta moneda); ciclo de cheques propios y de terceros; conciliación bancaria (CSV y PDF con IA); reportes de posición de caja y flujo; y cómo cada operación impacta la contabilidad. --- ## ¿Dónde encuentro esto en el menú? - **Tesorería y Bancos** (módulo propio en el menú lateral): tabs internas - **Cuentas y Saldos** — dashboard de cuentas activas con saldos en vivo. - **Movimientos** — vista Global / vista Extracto. - **Cheques** — recibidos y emitidos. - **Transferencias** — entre cuentas propias. - **Reportes** — posición, flujo real / proyectado, extracto, cartera de cheques. - **Conciliación** — importación de extractos (CSV o PDF con IA) y cruce con movimientos. - **Configuración → Tesorería y Bancos**: - **Cuentas de Tesorería** (ABM) - **Categorías de Movimiento** (base del sistema + propias de la empresa) - **Bancos** (catálogo del sistema + propios) - **Parámetros de Tesorería** (umbral aprobación, días alerta cheques, etc.) - **Reglas Automáticas** (cuenta por defecto + modo automático/manual por operación) --- ## Conceptos generales ### Estados de un movimiento ``` BORRADOR ──▶ CONFIRMADO ──▶ ANULADO ``` - **BORRADOR**: registrado, NO afecta saldo, NO genera asiento. Editable. - **CONFIRMADO**: impacta `saldo_actual` de la cuenta + dispara asiento contable automático (si la empresa tiene Contabilidad activa y hay cuentas mapeadas). - **ANULADO**: genera asiento de reversión, revierte el saldo. Requiere motivo obligatorio. ### Estados de un cheque | Estado | Cuándo | |--------|--------| | **EN_CARTERA** | Cheque al día recibido o por emitir, listo para depositar / pagar. | | **DIFERIDO** | Cheque posfechado (fecha de vencimiento > hoy). Transita a EN_CARTERA cuando llega la fecha. | | **DEPOSITADO** (tercero) | Llevado al banco, pendiente de acreditación. | | **ACREDITADO** (tercero) | Banco confirmó el cobro. | | **DEBITADO** (propio) | El banco debitó el cheque propio emitido. | | **RECHAZADO** | El banco rechazó (sin fondos, firma, etc.). | | **ANULADO** | Anulado antes de utilizar. | ### Permisos del módulo (`TESORERIA`) Códigos reales (2 niveles, por submódulo — no existe un permiso único `TES_VER` / `TES_CONFIG` genérico): | Submódulo | Códigos | Para qué | |-----------|---------|----------| | Cuentas Bancarias | `TES_CTA_CUENTA_BANCARIA_VER` / `_CREAR` / `_EDITAR` / `_ELIMINAR` | Ver / ABM de cuentas y saldos. | | Movimientos | `TES_MOV_MOVIMIENTO_VER` / `_CREAR` / `_APROBAR` / `_ANULAR` / `_ELIMINAR` | Ver, crear, aprobar (umbral) y anular movimientos manuales. | | Transferencias | `TES_TRF_TRANSFERENCIA_VER` / `_CREAR` / `_ANULAR` | Transferencias entre cuentas propias. | | Cheques | `TES_CHQ_CHEQUE_VER` / `_CREAR` / `_EDITAR` / `_DEPOSITAR` / `_ANULAR` / `_ELIMINAR` | Emitir / recibir / depositar / anular cheques. | | Reportes | `TES_REP_FLUJO_CAJA_VER` / `_LIBRO_CAJA_VER` / `_LIBRO_BANCO_VER` / `_REPORTE_EXPORTAR` | Reportes de tesorería. | | Conciliación Bancaria | `TES_CONC_CONCILIACION_VER` / `_PROCESAR` | Ver y ejecutar conciliación bancaria. | | Configuración (Cuentas, Categorías, Parámetros, Reglas Automáticas, Bancard) | módulo `ADMINISTRACION`, submódulos `ADM_TESORERIA_CFG` / `ADM_BANCOS` / `ADM_REGLAS_AUTO` / `ADM_BANCARD_VPOS` | Acceso a las pantallas de Configuración → Tesorería y Bancos (no usa permisos `TES_*`, sino módulo/submódulo de Administración). | --- ## Configuración del módulo (paso obligatorio antes de operar) ### A) Cuentas de Tesorería (ABM) Cada cuenta del mundo real (banco, caja, billetera) se carga acá. Campos: | Campo | Notas | |-------|-------| | **Nombre** | Descriptivo: "BNF CTA CTE Principal". | | **Tipo** | `BANCO_CC` (Cta. Corriente), `BANCO_CA` (Caja Ahorro), `CAJA_CHICA`, `FONDO_FIJO`, `BILLETERA`, `MONEDA_EXT`. | | **Moneda** | PYG, USD, BRL, etc. **El saldo se guarda y se muestra siempre en la moneda propia de la cuenta.** | | **Saldo inicial** | Saldo al dar de alta. Después no se edita, se mueve por movimientos. | | **Banco** | Selector contra catálogo `bancos`. Solo si tipo es BANCO_*. | | **Nro. de cuenta** / **CBU/IBAN** | Para identificación bancaria real. | | **Cuenta contable** | FK a `cont_plan_cuentas`. **Sin esto no se genera asiento.** | | **Saldo mínimo de alerta** | Si el saldo baja de este monto, la tarjeta se pone en rojo. | | **Activa** | Las inactivas no aparecen en el dashboard pero sí en Configuración. | > Las cuentas no se borran. Se **desactivan** con el switch para conservar el histórico. ### B) Categorías de Movimiento Dos tipos: - **Categorías del sistema (intocables)**: `DEP_BANCARIO`, `RETIRO_EFECTIVO`, `TRANSFERENCIA_PROPIA`, `GASTO_BANCARIO`, `INTERES_BANCARIO`, `PAGO_IMPUESTO`, `REPOSICION_CAJA_CHICA`, `INGRESO_OTRO`, `EGRESO_OTRO`. Vienen marcadas con chip "Sistema". No se editan ni se borran. - **Categorías propias de la empresa**: ABM libre. Cada una con tipo (ingreso / egreso), cuenta contable destino y flag "requiere comprobante". > A cada categoría del sistema **hay que mapearle una cuenta contable propia** desde el ícono 🔗 (link) de la tabla. Sin ese mapeo, el asiento sale "sin cuenta" y queda incompleto. ### C) Bancos Catálogo seedeado con los principales bancos de Paraguay (`empresa_id IS NULL` = sistema). Las empresas pueden agregar los suyos si falta alguno. ### D) Parámetros de Tesorería | Parámetro | Default | Uso | |-----------|---------|-----| | **Umbral de aprobación** | 0 (desactivado) | Movimientos ≥ umbral requieren `TES_MOV_MOVIMIENTO_APROBAR`. | | **Días alerta cheques por vencer** | 7 | Cheques con vencimiento ≤ N días aparecen con badge naranja. | | **Moneda base de reportes** | PYG | Moneda usada en el consolidado donde aplique. | | **Formato CSV extracto** | (configurable por banco) | Para conciliación CSV. | ### E) Reglas Automáticas > **Tesorería ≠ Mapeo Contable — son dos configuraciones separadas.** Es una confusión frecuente. Cuando una Orden de Pago (u otra operación) se ejecuta, se disparan **dos cosas independientes**: > 1. **Asiento contable** (libro mayor): usa el **Mapeo de Cuentas** de *Contabilidad → Mapeo* (conceptos → cuentas del plan `cont_plan_cuentas`). Decide, por ejemplo, DEBE Proveedores / HABER Caja General **a nivel contable**. > 2. **Movimiento de tesorería** (caja/banco real, flujo de caja, conciliación): usa las **Reglas de Tesorería** de acá, que apuntan a una **cuenta de tesorería** (`tes_cuentas`: una caja chica, fondo fijo o cuenta bancaria física con su propio saldo y conciliación). > > Una **cuenta de tesorería no es** una cuenta contable: es un objeto propio del módulo Tesorería (puede estar *vinculada* a una cuenta contable vía `cuenta_contable_id`, pero se administra aparte). Por eso, **tener mapeada "Caja General" en Contabilidad NO alcanza** para que la Tesorería sepa de qué caja/banco físico salió la plata — hace falta además la regla de Tesorería. Si aparece el aviso "Configuración de Tesorería incompleta" aunque el asiento contable haya salido bien, es exactamente por esto: el asiento se generó (mapeo contable OK) pero falta la regla de Tesorería. Se configura **una sola vez** y todas las operaciones futuras la usan. Por tipo de operación predefinida (cobro depositado, pago a proveedor, cheque propio, gasto caja chica, etc.) se configura: - **Cuenta de tesorería por defecto** (origen o destino). - **Modo**: - `AUTOMÁTICO` — el sistema confirma sin preguntar. - `PIDE CONFIRMACIÓN` — abre modal para que el usuario revise / corrija. - `MANUAL` — siempre lo hace el usuario. | Operación | Código interno | Cuenta default sugerida | Modo | |-----------|----------------|-------------------------|------| | Cobro depositado (CxC) | `COBRO_CLIENTE` | Banco PYG | Automático | | **Pago a proveedor (CxP)** | **`PAGO_PROVEEDOR`** | Banco PYG o Caja General | Pide confirmación | | Pago con cheque propio | `CHEQUE_PROPIO` | Banco PYG | Pide confirmación | | Recepción de cheque cliente | `CHEQUE_CLIENTE` | Cheques en Cartera | Automático | | Gasto caja chica | `GASTO_CAJA_CHICA` | Fondo Fijo / Caja Chica | Manual | | Transferencia entre cuentas | `TRANSFERENCIA_INTERNA` | (usuario elige) | Manual | | Liquidación de comisiones | `LIQUIDACION_COMISIONES` | Banco PYG | Pide confirmación | > **Importante**: si falta la regla `PAGO_PROVEEDOR`, cuando se ejecute una Orden de Pago aparece en la UI de Compras el diálogo **"Configuración de Tesorería incompleta"**. La OP igual queda **pagada y contabilizada** (asiento CONFIRMADO + CxP en 0), pero **no impacta Tesorería** — no aparece en Caja del Día, ni en Flujo de Caja, ni en Conciliación Bancaria. Ver sección **"Puentes automáticos"** más abajo. --- ## Dashboard: Cuentas y Saldos - Una **tarjeta por cuenta activa**: nombre, tipo, moneda, **saldo actual en la moneda propia** (sin conversión cruzada), variación del día. - Borde rojo + badge si saldo < `saldo_minimo_alerta`. - Botones rápidos por tarjeta: `+ Ingreso`, `+ Egreso`, `Ver movimientos`. - Barra de totales al pie **separada por moneda** (PYG | USD | BRL …). El sistema **NO** consolida todas las monedas en una sola — eso evita distorsión por TC. - Panel de alertas global: cheques por vencer, saldos bajo mínimo. --- ## Movimientos manuales ### Alta de movimiento Desde una tarjeta (`+ Ingreso` / `+ Egreso`) o desde el tab Movimientos. Campos: - **Cuenta** (filtra disponibles por moneda al elegir categoría). - **Fecha** (default hoy). - **Tipo**: `INGRESO`, `EGRESO`. - **Monto** (en la moneda de la cuenta, con formato). - **Categoría** (más de una si el movimiento se prorratea). - **Descripción / glosa**. - **Comprobante adjunto** (JPG/PNG/PDF — obligatorio si la categoría lo exige). Botones: `Guardar como borrador` o `Guardar y Confirmar`. ### Aprobación por umbral Si `monto ≥ umbral_aprobación` configurado, el movimiento queda en BORRADOR aunque el usuario haya pedido "Confirmar": pasa a CONFIRMADO solo cuando un usuario con `TES_MOV_MOVIMIENTO_APROBAR` lo aprueba. ### Anulación - Solo con `TES_MOV_MOVIMIENTO_ANULAR`. - **Motivo obligatorio** (texto libre). - Revierte el saldo en una sola `$transaction`. - Si tenía asiento → genera asiento espejo de reversión (vía `revertirDocumento`). - El movimiento queda visible con chip "Anulado" + motivo. ### Vistas del tab Movimientos | Vista | Para qué sirve | |-------|----------------| | **Global** | Todas las cuentas, todos los movimientos. Columna "Cuenta" visible. Filtros amplios. | | **Extracto** | Una cuenta a la vez, ordenado cronológico, **saldo acumulado línea a línea** (igual a un estado de cuenta bancario). | Filtros disponibles en ambas vistas: rango de fechas, tipo, categoría, estado, monto desde/hasta, usuario que registró, "tiene comprobante adjunto". Exportable a Excel y PDF (mediante msv-kude, mismo motor que Contabilidad). --- ## Cuentas en moneda extranjera (USD, BRL, etc.) ### Reglas básicas - El saldo y los movimientos se guardan **en la moneda propia** de la cuenta. Una cuenta USD muestra `USD 1.200,00`, no su equivalente en Gs. - El **dashboard NO convierte** USD a PYG en los totales. La barra de totales agrupa por moneda. - Para **mover dinero entre PYG y USD** se usa la **transferencia multi-moneda** (sección siguiente), nunca dos movimientos sueltos: así el sistema reconoce ambos lados y captura la diferencia de cambio. ### Limitación conocida — asiento contable de movimientos no-PYG El servicio `integrarMovimientoTesoreria` hoy toma el monto directamente sin convertirlo a PYG. Un ingreso de USD 500 en una cuenta USD genera el asiento como si fueran Gs. 500 — distorsión contable real. **Workaround actual**: a las cuentas no-PYG **no asignarles `cuenta_contable_id`**. El movimiento se registra correctamente en Tesorería, pero el asiento no se dispara. La integración contable de cuentas extranjeras se rediseña en una fase futura (ver `plan-tesoreria-bancos.md` — "Rediseño multi-moneda"). --- ## Transferencias entre cuentas propias Tab dedicada en el módulo. Estado: ``` CONFIRMADO ──▶ ANULADO ``` (Sin paso intermedio EN_TRANSITO en la versión actual — está planificado para acreditaciones interbancarias diferidas.) Al crear una transferencia se generan **2 movimientos vinculados por `transferencia_id` (UUID compartido)**: - `origen_tipo = TRANSFERENCIA_ORIGEN` → EGRESO en cuenta origen. - `origen_tipo = TRANSFERENCIA_DESTINO` → INGRESO en cuenta destino. Ambos nacen en `CONFIRMADO`. La anulación pone ambos en `ANULADO` y revierte los saldos en una sola transacción. ### Transferencia mismo-moneda Asiento de 2 patas: ``` DEBE Cuenta destino … monto HABER Cuenta origen … monto ``` ### Transferencia multi-moneda (ej. PYG → USD) Cuando origen y destino tienen monedas distintas, el formulario pide **ambos montos**: ``` Cuenta origen (PYG) Saldo: Gs. 5.000.000 Monto que sale: Gs. 3.000.000 Cuenta destino (USD) Saldo: USD 1.200,00 Monto que llega: USD 396,83 TC efectivo (banco): Gs. 7.561 (calculado = origen / destino) TC referencia sistema: Gs. 7.850 (desde cont_tipo_cambio para esa fecha) Diferencia de cambio: Gs. 114.877 PERDIDA ``` #### Asiento de 3 patas (cuando hay TC en sistema) ``` HABER Cuenta origen (PYG) … 3.000.000 (monto_origen) DEBE Cuenta destino (USD valorizada) … 2.975.625 (396,83 × TC_sistema) DEBE Diferencia de Cambio Perdida … 24.375 (residuo) ``` Si el TC efectivo fue **mejor** que el del sistema → HABER en `Diferencia de Cambio Ganada` (`4.2.1.02`). Si fue **peor** → DEBE en `Diferencia de Cambio Perdida` (`6.3.1.03`). #### Asiento de 2 patas (sin TC en sistema para esa fecha) ``` HABER Cuenta origen (PYG) … 3.000.000 DEBE Cuenta destino (valorizada al TC efectivo) … 3.000.000 ``` Glosa automática: _"Transferencia multi-moneda — TC referencia no disponible para esta fecha"_. #### Reglas del formulario - Saldo disponible de cada cuenta visible junto al selector. - `monto_origen > saldo_disponible` → aviso inline en rojo (no esperar al submit). - Si la diferencia de cambio supera el 0,5 % del monto → se resalta en naranja. - El campo `TC` aparece automáticamente al detectar monedas distintas. - **Backend rechaza** si monedas difieren y no hay `tipo_cambio` o es 0. --- ## Cheques ### Cheques recibidos de terceros ``` [Recepción] │ ├─ fecha_venc ≤ hoy ──▶ EN_CARTERA ──▶ DEPOSITADO ──▶ ACREDITADO │ └─▶ RECHAZADO └─ fecha_venc > hoy ──▶ DIFERIDO ──(llega la fecha)──▶ EN_CARTERA ``` ### Cheques propios emitidos ``` EN_CARTERA ──▶ DEBITADO (el banco descontó) ──▶ RECHAZADO (sin fondos / firma) ──▶ ANULADO (anulado antes de uso) ``` ### Origen del cheque en el ERP 1. **Recepción directa** (Tesorería → pestaña Cheques → botón «Registrar cheque») — flujo legacy, asiento al depositar. 2. **Como medio de pago en Recibo Multi-Factura** (Cobros) — flujo moderno: el wizard crea la fila en `tes_cheques` + el movimiento en Tesorería + el asiento del recibo en una sola transacción. 3. **Emisión propia para pagar a proveedor** (Compras → Orden de Pago) — `tipo=EMITIDO`. ### Cómo cargar un cheque del cliente (al día o diferido) — paso a paso **Ruta principal (recomendada — flujo moderno):** **Menú principal › Cobranzas › Recibos** (tab **Listado**) → botón **"Nuevo recibo multi"**. 1. Seleccionar el **cliente** y las facturas pendientes a cobrar. 2. En **medios de pago**, agregar línea **Cheque**. 3. Completar: - **Banco emisor** (4-20 caracteres). - **Número de cheque** (8 caracteres). - **Fecha de emisión**. - **Fecha de pago / vencimiento**: - Si la fecha es **hoy o anterior** → el cheque entra **al día** con estado `EN_CARTERA` (listo para depositar). - Si la fecha es **futura** → el cheque entra **diferido** con estado `DIFERIDO` (no se puede depositar hasta el vencimiento; al llegar la fecha pasa solo a `EN_CARTERA`). - **Librador** (firmante). 4. Confirmar el recibo. **Eventos que dispara la confirmación del recibo (todo en una sola transacción):** - Crea la fila en `tes_cheques` con el estado correcto (`EN_CARTERA` o `DIFERIDO`). - Crea el **movimiento de ingreso** en la cuenta de tesorería "Cheques en Cartera" → el saldo de tesorería sube de inmediato (sí, también con cheque diferido — es convención contable PY). - Genera el **asiento contable**: DEBE Cheques en Cartera (1.1.1.06) / HABER Clientes (CxC). - Cancela el **saldo pendiente** de las facturas seleccionadas (también con cheque diferido). - Si la factura estaba con cobrador asignado, marca la **cobranza** como saldada. **Ruta alternativa (legacy):** **Menú principal › Tesorería › Cheques** → botón **"Registrar cheque"**. Mismos campos pero el asiento se genera al depositar, no al recibir. Hoy se prefiere el flujo de Cobros. **Dónde verificar que salió bien:** - **Tesorería › Cheques** → debe aparecer en el listado con su estado (`EN_CARTERA` o `DIFERIDO`). - **Tesorería › Cuentas y Saldos › Cheques en Cartera** → el saldo aumentó por el importe del cheque. - **Contabilidad › Asientos** → asiento del recibo con la pata Cheques en Cartera. - Si era diferido, esperá al vencimiento — un job pasa automáticamente los `DIFERIDO` vencidos a `EN_CARTERA`. **Errores y validaciones típicas:** - "No se puede depositar un cheque diferido antes de su fecha de vencimiento" — esperar a la fecha o usar el flujo de adelanto si está habilitado. - "Fecha de vencimiento obligatoria si querés que el cheque sea diferido" — sin fecha futura entra como `EN_CARTERA` aunque la intención sea diferida. - "Banco emisor inválido" — debe estar en el catálogo de bancos (cargado en Configuración → Tesorería y Bancos → Bancos). ### Asientos contables del ciclo | Evento | DEBE | HABER | |--------|------|-------| | Cheque tercero recibido | Cheques en Cartera (1.1.1.06) | CxC Cliente | | Cheque tercero depositado | Cheques Depositados en Tránsito (1.1.1.07) | Cheques en Cartera | | Cheque tercero acreditado | Banco | Cheques Depositados en Tránsito | | Cheque tercero rechazado | CxC Cliente | Banco + gasto de rechazo | | Cheque propio emitido | Proveedores | Cheques a Pagar (2.1.1.04) | | Cheque propio debitado | Cheques a Pagar | Banco | | Cheque propio rechazado | Banco (reversión) | Cheques a Pagar → Proveedor | ### Consideraciones operativas críticas - **Cheques diferidos suben el saldo de tesorería de inmediato** al confirmarse el recibo multi (convención contable PY: el documento se reconoce al recibirse). Esto **distorsiona la "caja líquida"** del dashboard: para la caja real, mirar la **cartera de cheques** y restar mentalmente los `DIFERIDO`. Hay propuesta v2 de tarjeta separada "Cheques diferidos por cobrar". - **CxC del cliente se cancela al confirmarse el recibo**, no al cobrarse el cheque. Cliente con cheques largos figura "sin deuda". Para morosidad real: cruzar `factura_cab.saldo_pendiente` con `tes_cheques DIFERIDO` del mismo cliente. - **Rechazo de cheque no revierte automáticamente la CxC ni el recibo** (limitación actual). Workaround: anular el recibo multi desde Cobros (revierte facturas + saldo tesorería + asiento) y luego marcar el cheque rechazado. Pendiente: automatizar. - **Anular un recibo multi cuyo cheque ya salió de cartera** (DEPOSITADO, ACREDITADO, RECHAZADO, DEBITADO) está **bloqueado**: el sistema obliga a reversar primero el cheque desde Tesorería. El mensaje lista cuáles cheques bloquean. - **`fecha_vencimiento` en el wizard de Recibo Multi**: hoy no es obligatoria si `medio=CHEQUE`. Si se omite, el cheque entra como EN_CARTERA aunque la intención sea diferida. Pendiente volverla required. ### Alertas - Cheques con vencimiento ≤ `días_alerta_cheques_por_vencer` (default 7) → badge en la fila + banner en el tab. --- ## Asientos contables — tabla maestra | Evento | DEBE | HABER | |--------|------|-------| | Depósito en cuenta bancaria | Banco (destino) | Caja General / CxC | | Pago a proveedor por transferencia | Proveedores | Banco (origen) | | Gasto con caja chica | Cuenta gasto (de la categoría) | Fondo Fijo / Caja Chica | | Reposición fondo fijo | Fondo Fijo | Banco | | Comisión / gasto bancario | Comisiones Bancarias (6.3.1.02) | Banco | | Interés cobrado por banco | Banco | Intereses Bancarios | | Transferencia entre cuentas propias (mismo-moneda) | Cuenta destino | Cuenta origen | | Transferencia multi-moneda (con TC sistema) | Cuenta destino + Diferencia (perdida o ganada) | Cuenta origen | | Cheque tercero recibido / depositado / acreditado / rechazado | Ver sección Cheques | — | | Cheque propio emitido / debitado / rechazado | Ver sección Cheques | — | | Diferencia de cambio positiva | Banco (moneda local) | Diferencia de Cambio Ganada (4.2.1.02) | | Diferencia de cambio negativa | Diferencia de Cambio Perdida (6.3.1.03) | Banco (moneda local) | > Si la cuenta de tesorería o la categoría no tienen `cuenta_contable_id`, o si la empresa no tiene módulo Contabilidad → el asiento se **omite en silencio** (no rompe la operación). --- ## Puentes automáticos desde otros módulos (Compras, Cobranzas, RRHH) Cuando se registra un cobro, un pago a proveedor, una liquidación de comisiones o cualquier operación de otro módulo que impacte plata, Tesorería tiene que **espejar** el movimiento para mantener el saldo real de cuentas actualizado en vivo. Esos espejos se generan automáticamente **si existe la regla configurada**. ### Cómo funciona la cadena para "Pago a proveedor" 1. Usuario emite una Orden de Pago desde **Compras → Orden de Pago** (tab del módulo Compras), o se genera automáticamente al confirmar una compra en **Compras → Facturas** si la compra tiene generación de CxP automática habilitada. 2. Backend guarda la OP como PAGADO / APLICADO, actualiza CxP a saldo 0 (o parcial) y anula las cuotas pagadas. 3. Backend genera el **asiento contable** (`DEBE cuenta pasivo del proveedor / HABER cuenta de caja o banco del medio de pago`). 4. Backend decide a qué cuenta de Tesorería impactar siguiendo esta **cascada de prioridad**: 1. **Cuenta bancaria cargada en el modal del medio de pago** (por ej. al elegir Transferencia el usuario carga la cuenta origen). Si existe y está activa, se usa esa. **Gana siempre**. 2. **Regla `tes_reglas` específica por medio de pago** (ej. `PAGO_PROVEEDOR + Transferencia → BNF principal`). Se aplica cuando el modal quedó vacío o el medio no pide cuenta explícita. 3. **Regla `tes_reglas` default** (`PAGO_PROVEEDOR` sin medio_pago_id) — fallback global. 4. **Si no hay ninguna** → la API responde con `tesoreria_warning` y la UI muestra el diálogo _"Configuración de Tesorería incompleta"_. Cuando el sistema resuelve la cuenta (cualquier nivel de la cascada), crea `tes_movimientos` (EGRESO, CONFIRMADO) + `origen_tipo='ORDEN_PAGO_PROVEEDOR'`. La cuenta operativa refleja el egreso en vivo. ### Relación entre modal del medio y reglas — cuál usar Ambas capas se complementan y **no compiten**: | Capa | Alcance | Cuándo se aplica | Uso típico | |---|---|---|---| | Modal "Datos del medio" | Pago concreto | Si el medio pide cuenta y el usuario la carga | Transferencias/Depósitos por un banco específico | | Regla por medio de pago | Toda la empresa, filtrado por medio | Default cuando el modal está vacío | Todas las transferencias van por BNF, todos los cheques por Itaú | | Regla default | Toda la empresa | Fallback global | Efectivo/Giro → Caja General | Ejemplo canónico de configuración: ``` tes_reglas: - tipo_operacion=PAGO_PROVEEDOR, medio_pago=Transferencia → cuenta_id= - tipo_operacion=PAGO_PROVEEDOR, medio_pago=Cheque propio → cuenta_id= - tipo_operacion=PAGO_PROVEEDOR, medio_pago=NULL (default) → cuenta_id= ``` Con eso configurado, el usuario NO tiene que cargar la cuenta bancaria en el modal salvo que quiera desviar un pago puntual de la default (por ej. una transferencia que excepcionalmente sale del Itaú en vez del BNF). ### Reglas obligatorias por módulo activo Si la empresa tiene módulo activo, mínimamente configurar la regla correspondiente: | Módulo activo | Regla obligatoria | |---|---| | COMPRAS (Órdenes de Pago) | `PAGO_PROVEEDOR` | | COBRANZAS (Recibos multi-factura) | `COBRO_CLIENTE` | | Cobranzas con cheques de clientes | `CHEQUE_CLIENTE` | | RRHH (Liquidaciones) | `LIQUIDACION_SUELDOS` | | COMISIONES | `LIQUIDACION_COMISIONES` | Sin la regla, la operación se completa **contablemente** pero la cartera operativa de Tesorería queda desincronizada — Caja del Día no refleja el egreso, la Conciliación Bancaria no ve el pago, el Flujo de Caja queda desactualizado. ### Qué hago si ya se me escaparon OPs sin regla configurada 1. Configurá la regla en **Configuración → Tesorería y Bancos → Reglas Automáticas** apuntando a la cuenta correcta. 2. Las **próximas OPs** ya se registran en Tesorería automáticamente. 3. Para las OPs viejas: **anulá** la OP (revierte contabilidad + reabre CxP) y **volvé a emitirla**. Como ahora existe la regla, se genera el `tes_movimientos`. 4. Alternativa manual (no recomendada, sin trazabilidad): crear el movimiento en Tesorería a mano por el mismo monto. ### Reversión al anular la OP Cuando anulás una OP: - CxP vuelve a su saldo original. - Asiento contable se revierte automáticamente (contra-asiento). - `tes_movimientos` de esa OP se marca `ANULADO` y el saldo de la cuenta bancaria/caja se recompone. - Los cheques emitidos por esa OP se validan: si están `EN_CARTERA`/`DIFERIDO` se pueden anular; si ya fueron acreditados/rechazados por el banco, la anulación se bloquea hasta reversarlos desde Tesorería. --- ## Conciliación bancaria Cruzar lo que registró el sistema con lo que figura en el extracto del banco. ### Flujo 1. **Importar extracto** del banco para una cuenta y un período. 2. El sistema hace **auto-match** entre cada línea del extracto y los movimientos del ERP: - Mismo monto. - Crédito ↔ INGRESO / Débito ↔ EGRESO. - Fecha ±2 días. 3. Las líneas auto-matcheadas quedan **CONCILIADAS**. Las demás, **PENDIENTES**. 4. El usuario puede: - **Conciliar manualmente**: elegir el movimiento del ERP desde un Autocomplete con búsqueda en tiempo real. - **Desconciliar**: deshacer una conciliación si fue equivocada. 5. El estado del extracto va: `PENDIENTE` → `PARCIAL` → `CONCILIADO` según el avance. ### Formatos de importación #### CSV genérico - Parser configurable (separadores `;` / `,`, fechas `DD/MM/YYYY` o ISO, mapeo de columnas por nombre). - Parsers específicos por banco (Continental, Sudameris, BNF, Itaú) están planificados. #### PDF con IA ✨ - El usuario sube el **PDF tal como lo descarga del banco**, sin tocar. - El sistema usa **IA (Anthropic / OpenAI según `ai_empresa_config`)** para extraer: - Banco detectado. - Período. - Lista de transacciones (fecha, comprobante, concepto, importe, tipo CRÉDITO/DÉBITO). - Saldo inicial y final (si aparecen). - Preview con la tabla detectada antes de confirmar. - Auto-match inmediato al confirmar. - Badge `✨ IA` diferenciador en la lista de extractos. - **Si no hay API key configurada** → la opción IA aparece deshabilitada con candado y se redirige a configurar en `IA Dashboard`. El CSV manual sigue disponible. ### Pendientes conocidos de conciliación - **Marcar línea "sin correspondencia"** para cerrar líneas sin movimiento (comisiones automáticas, etc.) — todavía no. - **Crear movimiento directamente desde la línea sin match** — planificado. - **Reporte de diferencias** (líneas sin conciliar + movimientos no aparecidos en el extracto) — planificado. - **Preview editable** del PDF antes de confirmar (corregir un importe que la IA leyó mal) — planificado. --- ## Reportes Todos exportan a Excel y, donde dice, a PDF vía `msv-kude` (mismo motor que Contabilidad). | Reporte | Qué muestra | Cuándo se usa | |---------|-------------|---------------| | **Posición de caja** | Saldo actual de todas las cuentas, agrupado por moneda y tipo | Snapshot diario, cierre de jornada. | | **Extracto de cuenta** | Una cuenta, movimientos cronológicos con saldo acumulado línea a línea | Reemplaza imprimir desde el home banking. | | **Flujo de caja real** | Ingresos vs egresos confirmados por período, desglosado por categoría | Análisis de qué entró y qué salió en el mes. | | **Flujo de caja proyectado** | Real + CxC vencidas/pendientes + Órdenes de Pago a proveedor | Ver si llegan los fondos para los pagos del mes. | | **Movimientos por categoría** | Totales por categoría en un período | Detectar dónde se concentran los gastos. | | **Cartera de cheques** | Todos los cheques activos, separados Propios / Terceros, por estado | Saber qué cheques hay que cobrar / pagar. | | **Cheques por vencer** | Cheques con vencimiento ≤ N días (configurable) | Gestión de cobranza / pagos próximos. | | **Rendición de caja chica** | Detalle de gastos del fondo fijo para aprobar reposición | Al pedir reposición. | | **Conciliación bancaria** | Diferencias sistema ↔ extracto importado | Cierre mensual. | --- ## Validaciones del backend (mensajes que pueden aparecer) ### Cuentas - **"Banco es obligatorio para cuentas de tipo BANCO_*"**. - **"Moneda no encontrada"** / **"Moneda inactiva"**. - **"Cuenta contable no pertenece a la empresa"**. - **"No se puede desactivar una cuenta con saldo distinto de 0"** (en algunas versiones; revisar). ### Movimientos - **"El monto debe ser mayor a cero"**. - **"La cuenta seleccionada está inactiva"**. - **"La categoría no corresponde al tipo de movimiento"** (ej. categoría de ingreso en un egreso). - **"La suma de las categorías no coincide con el monto del movimiento"**. - **"Saldo insuficiente en la cuenta origen"** (para egresos / transferencias). - **"Se requiere comprobante adjunto para esta categoría"**. - **"El movimiento supera el umbral configurado — requiere aprobación"**. - **"Solo el usuario con permiso TES_MOV_MOVIMIENTO_APROBAR puede confirmar este movimiento"**. - **"Motivo de anulación obligatorio"**. - **"No se puede anular un movimiento ya anulado"**. - **"No se puede editar un movimiento confirmado"** (hay que anularlo y crear uno nuevo). ### Transferencias - **"Cuenta origen y destino deben ser distintas"**. - **"Las cuentas tienen monedas distintas — tipo_cambio es obligatorio"**. - **"Saldo insuficiente en la cuenta origen"**. - **"No se puede anular: la transferencia ya está anulada"**. ### Cheques - **"Número de cheque obligatorio"** / **"Banco emisor obligatorio para cheques de tercero"**. - **"No se puede depositar un cheque diferido antes de su fecha de vencimiento"**. - **"El cheque ya está en estado X — no se puede pasar a Y"**. - **"No se puede anular el recibo multi: hay cheques fuera de cartera. Reverse primero: {lista}"**. ### Conciliación - **"Empresa sin API key configurada para IA — usá CSV o configurá Anthropic/OpenAI en IA Dashboard"**. - **"El PDF no pudo ser leído"** / **"La IA no devolvió un JSON válido tras el reintento"**. - **"El extracto ya existe para este período y cuenta"**. --- ## Lo que NO se puede hacer - Editar un movimiento confirmado (hay que anularlo + crear uno nuevo). - Borrar una cuenta de tesorería con histórico (solo desactivar). - Tener un movimiento de USD que afecte un asiento en PYG correctamente — workaround: no mapear cuenta contable a cuentas no-PYG hasta el rediseño multi-moneda. - Consolidar saldos de distintas monedas en una sola línea del dashboard (es por diseño — evita distorsión). - Anular un recibo multi cuyos cheques ya salieron de cartera sin revertirlos primero. - Depositar un cheque diferido antes de su fecha. - Editar categorías del sistema (sólo mapearles cuenta contable propia). - Importar el mismo extracto dos veces para la misma cuenta y período. --- ## Problemas frecuentes - **"Confirmé un movimiento pero no aparece el asiento"**: la cuenta de tesorería o la categoría no tienen `cuenta_contable_id` mapeada, o la empresa no tiene módulo Contabilidad activo. Revisar Configuración → Tesorería y Bancos → Categorías (ícono 🔗) y la cuenta. - **"El dashboard suma todo en Gs. y queda inflado"**: no debería — la barra de totales separa por moneda. Si ves un consolidado raro, hay una cuenta USD con cuenta contable mapeada y movimientos viejos generaron asientos con valores sin convertir. - **"Hice una transferencia PYG → USD y la diferencia de cambio me dio absurda"**: el TC de referencia (`cont_tipo_cambio`) para esa fecha está mal cargado o falta. Cargarlo en Contabilidad → Tipo de Cambio. - **"No puedo anular el recibo multi"**: el sistema lista qué cheques bloquean. Ir a Cheques, revertirlos al estado anterior, y reintentar. - **"Mi cliente figura sin deuda pero todavía no me pagaron"**: tiene cheques DIFERIDOS no vencidos. Cruzar con Cartera de Cheques. - **"Ya mapeé Caja General en Contabilidad, ¿por qué sigue pidiendo configurar Tesorería al pagar?"**: porque son **dos cosas distintas**. El Mapeo Contable resuelve el **asiento** (y por eso el asiento sí salió); la **Regla de Tesorería** resuelve de qué **caja/banco físico** sale la plata (para Caja del Día, Flujo de Caja y Conciliación). No se reemplazan entre sí. Solución: crear la regla en **Configuración → Tesorería y Bancos → Reglas Automáticas** (`PAGO_PROVEEDOR`) apuntando a la cuenta de tesorería que corresponda. Es un setup de una sola vez. Ver "Reglas Automáticas" arriba. - **"La orden de pago quedó pagada y contabilizada pero no aparece en Caja/Flujo"**: falta la regla de Tesorería `PAGO_PROVEEDOR` (o está inactiva / sin cuenta). El pago contable está bien; solo falta el movimiento de tesorería. Configurar la regla y, para las OP ya hechas, registrar el movimiento manualmente o reejecutar el puente si la UI lo ofrece. - **"La IA leyó mal un importe del PDF"**: hoy no hay preview editable. Workaround: importar el CSV manual de ese mismo extracto, o conciliar manualmente la línea desviada. Edición pre-confirmación está planificada. - **"Sube el saldo al confirmar el recibo multi con cheque diferido — distorsiona mi caja"**: comportamiento esperado. Para "caja líquida real" usar el reporte de Cartera y restar los DIFERIDO. --- ## Limitaciones actuales - **Multi-moneda**: movimientos en cuentas no-PYG generan asientos sin conversión a Gs. → workaround: no mapear cuenta contable a esas cuentas. Rediseño en plan. - **Modo EN_TRANSITO** para transferencias interbancarias diferidas (1-2 días hábiles): aún no implementado. - **Reversa automática de CxC al rechazar cheque de tercero**: aún manual. - **`fecha_vencimiento` no obligatoria** en wizard de Recibo Multi cuando `medio=CHEQUE`: pendiente. - **Exportación PDF** de reportes de tesorería (posición, flujo, extracto, cartera): pendiente (Excel sí está). - **Parsers CSV por banco** específicos (Continental, Sudameris, BNF, Itaú): genéricos funcionan, los específicos están planificados. - **Conciliación**: marcar línea "sin correspondencia", crear movimiento desde la línea, reporte de diferencias, preview editable del PDF — todo planificado. --- ## Documentos relacionados - `guia-cobros-finanzas.md` — Recibos Multi, Órdenes de Pago, cheques como medio de pago. - `guia-apertura-cierre-caja.md` — Caja del Día (POS) vs Tesorería (fondos formales). Son módulos **separados**. - `guia-compras.md` — Pago a proveedores que mueve Tesorería + Bancos. - `guia-facturacion.md` — Cobros de factura que disparan ingreso en Tesorería. - `plan-tesoreria-bancos.md` — diseño técnico completo, decisiones de arquitectura y fases. - `plan-prueba-usuario-tesoreria.md` — guion de pruebas paso a paso (cuentas, movimientos, transferencias, cheques, multimoneda, conciliación). - `plan-contabilidad.md` — plan de cuentas, tipos de cambio, asientos. - `plan-ayuda-ia.md` — configuración global de API keys IA usada por la conciliación PDF.