--- audiencia: usuario screen_key: compras titulo: Compras aliases: [compra, compras, factura compra, nota credito compra, requisicion, requisición, orden de compra, recepcion, recepción, lote, lotes, cxp, cuentas por pagar, marangatu compras] --- # Compras — Guía para el Usuario Esta guía cubre el módulo **Compras**: alta de facturas recibidas de proveedores, gastos, recepciones y órdenes de compra, manejo de lotes y vencimientos, generación automática de cuentas a pagar, y la integración con Marangatu para importar lo que figura en el portal SET. --- ## ¿Dónde encuentro esto en el menú? - **Compras**: pantalla principal con varias solapas según la configuración de la empresa. - **Compras → Orden de Pago**: para emitir el pago al proveedor. *(Antes estaba en Finanzas; se movió a Compras.)* - **Compras → Cuentas a Pagar**: control de saldos pendientes. *(Antes estaba en Finanzas; se movió a Compras.)* - **Reportes → Libro IVA Compras**: insumo para declarar IVA Crédito al SET. - **Reportes → Resumen de Compras**: totales por proveedor / período. - **Reportes → Cuentas por Pagar**: aging de la deuda con proveedores (reporte distinto de la solapa homónima). Las solapas dentro de Compras se muestran condicionalmente según la configuración `config_compras` de la empresa **y** los permisos del usuario: | Solapa | Visible si… | |--------|-------------| | Requisiciones | `habilitar_requisicion_compra = true` | | Órdenes de compra | `habilitar_orden_compra = true` | | Recepciones | `habilitar_recepcion_compra = true` | | **Facturas** | siempre | | Gastos | submódulo **Gastos** (`TES_GASTOS`) habilitado | | Tipos de gasto | submódulo **Gastos** (`TES_GASTOS`) habilitado | | **Cuentas a Pagar** | `generar_cxp_automatico = false` **y** permiso `CMP_CXP_CUENTA_PAGAR_VER` | | **Orden de Pago** | `habilitar_orden_pago = true` **y** permiso `CMP_OP_ORDEN_PAGO_VER` | | Marangatu | bot Marangatu activo | > **Nota sobre "Cuentas a Pagar" y "Orden de Pago"**: hasta versiones anteriores vivían en **Finanzas**; se movieron a **Compras**, que es donde corresponden conceptualmente. La regla de visibilidad se preservó igual que en Finanzas. Ver el detalle en *"Generar CxP automáticamente / Orden de Pago"* más abajo. --- ## Conceptos generales ### Flujo completo (cuando está todo habilitado) ``` Requisición → Orden de Compra → Recepción → Factura → Pago ``` Cada paso es opcional según la configuración: una empresa simple puede ir directo a **Factura → Pago**; una empresa con control estricto pasa por los cuatro pasos. ### Estados de una factura de compra - **importado**: la trajo el bot de Marangatu, todavía no se aplicó. Oculta del listado normal. - **pendiente**: confirmada, queda saldo pendiente de pago (crédito sin pagar). - **parcial**: pagada parcialmente. - **pagada**: cancelada al 100% (contado o crédito ya saldado). - **rechazado**: la rechazaron desde Marangatu (queda en auditoría). - **anulada**: anulada, todas las reversiones aplicadas. ### Numeración SET del proveedor Toda factura de compra de un **proveedor local** requiere: - **Timbrado del proveedor**: 8 dígitos. - **Establecimiento**: 3 dígitos (`001`). - **Punto de expedición**: 3 dígitos (`001`). - **Número de factura**: 7 dígitos (`0000123`). Si la compra se importó desde Marangatu, estos datos vienen del XML. Para **proveedores del exterior** (`tipo_entidad = PROVEEDOR_EXTERIOR`) esas reglas no aplican: la factura del proveedor no tiene timbrado paraguayo. El sistema acepta el invoice tal cual (ej. `INV-2026-00123`, `A-0001`) y sólo pide el número/invoice para trazabilidad interna. Ver la sección "Tipos de tercero" más abajo. --- ## Tipos de tercero — Local, Exterior y Acreedor vario Cada proveedor del catálogo se clasifica en uno de tres tipos. Esa clasificación: - Define **a qué cuenta contable de pasivo se acredita** cuando se registra una compra/gasto (con posibilidad de override manual por proveedor). - Habilita o bloquea flujos operativos (OC, Recepción, Importación). - Relaja las validaciones fiscales cuando el tercero no está bajo régimen SET Paraguay. ### Los tres tipos | Tipo | Uso típico | Cuenta contable por defecto | |------|------------|-----------------------------| | **Proveedor local** | Empresas con RUC paraguayo, facturas timbradas, IVA crédito. | Concepto `PROVEEDORES` (ej. `2.1.1.01`). | | **Proveedor del exterior** | Proveedor no residente. Invoice sin timbrado ni IVA crédito local; se usa en importaciones. | Concepto `PROVEEDORES_EXTERIOR` (ej. `2.1.1.06`). | | **Acreedor vario** | Alquileres, honorarios profesionales, entes públicos, financieras. | Concepto `ACREEDORES_VARIOS` (ej. `2.1.1.07`). | > Los códigos de cuenta son sugeridos por el seed. El contador puede re-mapear los conceptos desde **Contabilidad → Mapeo de Cuentas** sin tocar código. ### Dónde se elige En el alta/edición del proveedor (**Contactos → Proveedores → Formulario** — el CRUD de proveedores vive en el módulo Contactos, no en Compras), sección **"Clasificación contable"**: - **Tipo de entidad**: los tres opciones anteriores. - **Cuenta contable (override)**: opcional. Si se define, tiene prioridad sobre el mapeo del concepto (útil cuando un proveedor concreto va a una cuenta específica). - Si el tipo es **Proveedor del exterior**, se muestran adicionalmente **SWIFT** y **Banco corresponsal** para pagos internacionales. ### Qué cambia en cada flujo | Escenario | Local | Exterior | Acreedor vario | |-----------|-------|----------|----------------| | Alta de compra (`/compras`) | Timbrado 8 dig + estab/pto 3 dig obligatorios | Invoice text libre (30 car), sólo `numero_factura` obligatorio | **Bloqueado**: mensaje "no puede usarse en compras. Registrá como Gasto". | | Orden de compra | Habilitado | Habilitado | **Bloqueado**. | | Recepción | Habilitado | Habilitado | **Bloqueado**. | | Embarque / Importación | Habilitado | Habilitado (uso típico) | **Bloqueado**. | | Gasto | Habilitado (documento fiscal obligatorio si se declara deducible) | Habilitado — texto libre, `deducible=false` automático | Habilitado (flujo natural). | | Libro IVA Compras | Aparece | No aparece (sin IVA crédito local) | Sólo si el gasto es deducible. | ### Cargar una compra del exterior (documento aduanero / importación) para que entre al stock Esta es una pregunta frecuente: *"tengo un documento aduanero de una compra del extranjero, ¿cómo la cargo para que entre a mi stock?"*. **No** hay un "tipo de comprobante: documento aduanero" en el alta de compra — esa opción **no existe**. El camino depende de **qué** importaste: **A) Mercadería / productos en general (lo más común)** → se carga como una **compra directa normal** y el stock entra igual: 1. `Compras → pestaña Facturas → botón «Nueva compra»`. 2. En **Proveedor**, elegí el proveedor del exterior (registrado en `Contactos → Proveedores` con tipo **Proveedor del exterior**: invoice sin timbrado ni IVA crédito local, con SWIFT/banco corresponsal para el pago). 3. Elegí el **Depósito Inventario** donde debe entrar la mercadería (campo del formulario). 4. Cargá los **ítems** (productos que ya existan en tu catálogo) con cantidades y costos. El número/invoice del exterior va en **Número Factura** (texto libre). 5. Al guardar, con **"Afectar stock" activo** (por defecto en compra directa), **el stock entra automáticamente** al depósito elegido. Si "Afectar stock" está en OFF, el stock recién entra al confirmar la **Recepción**. > El **despacho aduanero formal** como documento aparte (con prorrateo de fletes, seguros, tributos, ISC y recálculo de costo) **solo existe en el módulo Importaciones**, y en v1 está activo **únicamente para el perfil AUTOS** (ver punto B). Para mercadería general de consumo ese perfil todavía no está habilitado: los costos de nacionalización se suman manualmente al costo de los ítems de la compra (o como gasto asociado). **B) Autos importados (Corea / Japón)** → van por el módulo **Importaciones** (perfil AUTOS): se arma el embarque, se cargan los componentes de costo (FOB, flete, seguro, tributos del despacho), se **confirma el despacho aduanero** (genera el asiento) y al **"Liberar al depósito"** el sistema crea un producto por cada chasis con su costo real. Ver `guia-importaciones.md`. **Dónde verificar el ingreso de stock:** `Reportes → Inventario → Movimientos de Stock`, filtrando por depósito y producto. > Recordá: cargar la compra **siempre suma** stock; la política de stock (Estricto/Libre) aplica solo al **vender**, no al comprar. ### Reclasificar un tercero Desde el listado de proveedores (o desde el reporte de clasificación) hay una acción **"Reclasificar"**: 1. Elegís el nuevo tipo. 2. Opcionalmente ajustás el override de cuenta. 3. Cargás un **motivo** (queda en auditoría). Reglas y advertencias: - Si el destino es **Acreedor vario** y el tercero tiene OC o embarques activos, el sistema **rechaza** la reclasificación (hay que cerrar/cancelar esos documentos primero). - **Los saldos y asientos existentes NO se migran a la cuenta nueva**. La cuenta pasivo quedó congelada en cada cuenta por pagar al momento de contabilizar la compra/gasto/importación — la Orden de Pago debita esa misma cuenta. Solo los documentos **nuevos** usan la cuenta destino. - El sistema muestra este warning en toast al reclasificar. ### Reporte "Clasificación de terceros" **Ruta**: Reportes → Administrativos y Financieros → **Clasificación de terceros** (`/reportes/compras/clasificacion-terceros`). Muestra por tercero: tipo, cuenta efectiva (override o por concepto), origen de la cuenta (`OVERRIDE` / `CONCEPTO_*`), CxP abiertas y saldo agregado. Filtros por tipo, estado y búsqueda por razón social/RUC/documento. Botón "Reclasificar" en cada fila. Útil para el contador cuando necesita ordenar la cartera antes del cierre. --- ## Configuraciones del módulo y casos de uso El comportamiento de Compras cambia bastante según dos lugares de configuración: 1. **Configuración → Facturación → Configuración de Compras** (global por empresa, `config_compras`; el ítem vive bajo la categoría "Facturación" del menú de Configuración, no bajo "Compras"). 2. **Configuración → Puntos de Venta → Sucursales y Cajas → [sucursal] → Config. → Control de Stock / Configuración ERP** (por sucursal / caja). Cada toggle define qué solapas aparecen, qué pasos son obligatorios y cómo se mueve el stock. ### 1) Configuración global de Compras #### Modo de operación Tres modos posibles que definen el grado de control sobre el proceso de compra: | Modo | Comportamiento | Caso de uso | |------|----------------|-------------| | **Directo** | Compra directa sin requisición ni OC. Solo Factura → Pago. | Comercio minorista, kiosco, ferretería chica: el dueño compra cuando quiere. | | **Requisición opcional** | Se puede usar requisición pero no es obligatoria. | Empresa mediana en transición: algunos sectores piden, otros no. | | **Requisición obligatoria** | Toda compra arranca con requisición aprobada. | Empresa con control interno fuerte, compras por aprobación de jefatura. | > Si esta configuración choca con otras (ej. modo "Directo" pero "Requisición obligatoria" prendida), el sistema muestra el aviso **"Configuración mixta detectada"** y prioriza el modo más restrictivo. #### Habilitar requisición de compra - **ON**: aparece la solapa **Requisiciones** y se puede pedir desde sectores internos. - **OFF**: solapa oculta. Solo OC / Factura directa. #### Niveles de aprobación de requisiciones Define qué perfiles aprueban requisiciones según monto y origen. Ejemplos típicos: - Hasta Gs. 1.000.000 → aprueba Jefe de Sector. - Más de Gs. 1.000.000 → aprueba Gerencia. - Compras de capital (activo fijo) → siempre aprueba Dirección. Una requisición no pasa a OC sin todos los niveles aprobados. #### Modo de flujo de compra Independiente del modo de operación, define si el flujo formal (OC + Recepción) es: | Valor | Comportamiento | |-------|----------------| | **Directo** | La factura entra sin pasar por OC ni recepción. El stock se mueve al cargar la factura. | | **Opcional** | Se puede usar OC + Recepción pero no se obliga. | | **Obligatorio** | Toda factura debe estar precedida por OC + Recepción confirmadas. | > Requiere que **Habilitar OC** y **Habilitar Recepción** estén en ON para usarse en modo Opcional u Obligatorio. #### Afectar stock en compra directa - **ON (default)**: al cargar la factura, el stock entra al depósito (ítems con `afecta_stock = true`). - **OFF**: la factura **no mueve stock**. El stock recién entra cuando se confirma la **Recepción**. Casos de uso: - **ON**: comercio que no separa "factura llega" de "mercadería llega" — son el mismo evento. - **OFF**: importadores, mayoristas con mercadería en tránsito, empresas donde la factura llega antes de que llegue el camión. > Si esto está en OFF y el flujo de compra es **Directo**, hay riesgo de descalce: el sistema avisa "Configuración mixta detectada" en la pantalla. #### Documentos formales ##### Habilitar orden de compra - **ON**: aparece la solapa **Órdenes de Compra**. Permite reservar / comprometer con el proveedor antes de recibir. - **OFF**: solapa oculta. No se pueden encadenar requisición → OC. ##### Habilitar recepción de compra - **ON**: aparece la solapa **Recepciones**. Permite registrar la llegada física antes (o sin) factura. - **OFF**: solapa oculta. La entrada de stock ocurre al cargar la factura. ##### Matching 3 vías estricto Cuando está prendido, el sistema **valida coherencia entre Orden de Compra ↔ Recepción ↔ Factura**: - Mismos ítems. - Cantidades de factura ≤ cantidades recepcionadas ≤ cantidades pedidas. - Precios y total de la factura coinciden con la OC (con tolerancia configurable). Si algún cruce falla, el sistema bloquea la confirmación de la factura. | Estado | Caso de uso | |--------|-------------| | **ON** | Industrias y mayoristas con auditoría interna o externa: nada se paga sin estar respaldado por OC + Recepción coherentes. | | **OFF** | Comercios donde una factura puede tener pequeños desvíos respecto a la OC (bonificaciones, ajustes de precio) y se quiere flexibilidad. | > Matching 3 vías requiere obligatoriamente **Habilitar OC + Habilitar Recepción** en ON. #### Compras a crédito con cuotas obligatorias (`compras_credito_requiere_cuotas`) > **Corrección**: este flag **no es parte de la configuración global de Compras** (`config_compras`) — no existe un campo así a nivel empresa. Vive únicamente en la **configuración por sucursal** (ver sección 2, "Crédito con cuotas obligatorias"). Se documenta acá porque afecta el mismo flujo de alta de factura a crédito. - **OFF** (en la sucursal donde se registra la compra): el sistema genera **una sola cuota** con vencimiento = emisión + plazo de crédito. - **ON**: el usuario debe cargar a mano cada cuota (fecha + monto) y la suma debe coincidir con el total. Caso de uso ON: empresas con planes de pago heterogéneos al proveedor (3x con primera cuota distinta, pagos quincenales, etc.). #### Generar CxP automáticamente / Orden de Pago automática - **`generar_cxp_automatico`**: si está en ON, toda factura confirmada crea su registro en CxP (default ON). - No existe un flag separado "orden de pago automática": con `generar_cxp_automatico` en ON, una factura **contado** genera la Orden de Pago automáticamente al confirmar (un solo click ahorrado) — salvo que `incluir_contado_en_orden_pago` esté en ON, en cuyo caso el contado queda como CxP pendiente para pagar manualmente (ver más abajo). Para crédito, la orden de pago siempre es manual. - **`habilitar_orden_pago`**: habilita el flujo de Orden de Pago para la empresa (default ON). ##### Impacto en las solapas de Compras Estos flags no solo cambian el flujo: también **deciden qué solapas de saldos/pagos se muestran** dentro de Compras. - **Solapa "Cuentas a Pagar"** — vista de control de los saldos por pagar (dashboard + listado de `cuentas_pagar` con vencimientos y estado). Se muestra cuando: - `generar_cxp_automatico = false`, **y** - el usuario tiene el permiso `CMP_CXP_CUENTA_PAGAR_VER`. Con `generar_cxp_automatico = true` la solapa **se oculta**. Ojo con la consecuencia: es justamente cuando la generación automática está activada que se crean las CxP al confirmar cada compra — o sea, hay cuentas por pagar reales pero esta vista queda oculta. En ese escenario las cuentas por pagar se **pagan desde la solapa "Orden de Pago"**, y el aging/saldos se consulta en **Reportes → Cuentas por Pagar**. Si necesitás la solapa de control visible, poné `generar_cxp_automatico = false` en Configuración → Facturación → Configuración de Compras. - **Solapa "Orden de Pago"** — emisión del pago al proveedor contra las CxP pendientes. Se muestra cuando: - `habilitar_orden_pago = true`, **y** - el usuario tiene el permiso `CMP_OP_ORDEN_PAGO_VER`. > Ambas solapas se movieron desde **Finanzas** a **Compras** conservando exactamente estas reglas de visibilidad. #### Incluir contado en orden de pago (`incluir_contado_en_orden_pago`) Flag **por empresa** (default **OFF**). Sirve para empresas que quieren **centralizar todos los pagos en la orden de pago**, incluso los de contado. - **OFF (default)**: comportamiento de siempre. Una compra/gasto de **contado** se paga en el momento (se cargan los pagos en el alta) y queda **pagada**; su asiento acredita **Caja/Banco**. - **ON**: una compra/gasto de **contado** **no se paga al registrarse**. Se comporta como un crédito: - Queda como **cuenta por pagar pendiente** (no exige cargar pagos en el alta; en compras el formulario oculta la sección "Pagos" y avisa que se abonará por orden de pago). - Aparece en el selector de la **orden de pago** (junto con las de crédito), donde se abona. - **Contablemente** el asiento acredita **Proveedores** (nace el pasivo), **no** Caja. El pago real lo asienta la **orden de pago** al ejecutarse (DEBE Proveedores / HABER Caja o Banco). Así el pago se registra una sola vez y el asiento cuadra. - No afecta a **anticipos de viático** (esos siguen sin generar CxP). > Es el espejo, del lado de compras/gastos, del "cobro en ruta / cobro diferido" de ventas (una factura contado que no se cobra al emitir queda como cuenta por cobrar). --- ### 2) Configuración por sucursal — Control de Stock Cada sucursal / caja tiene su propia configuración en **Configuración → Puntos de Venta → Sucursales y Cajas → [sucursal] → Config. → Control de Stock / Configuración ERP**. Esto es importante porque una misma empresa puede tener: - Un local retail con stock estricto. - Un depósito mayorista que tolera negativos transitorios. - Una sucursal de servicios sin stock real. #### Política de stock | Valor | Comportamiento | Caso de uso | |-------|----------------|-------------| | **Estricto** | No deja vender por debajo del stock disponible. Bloquea cualquier salida que dejaría negativo. | Retail / POS, farmacia, kiosco. | | **Advertencia** | Avisa pero permite vender. Queda flag en el movimiento. | Mayoristas con mercadería en tránsito, ferreterías. | | **Libre** | No controla stock. | Servicios, profesionales, gastronomía con receta no inventariada. | > Aplica al vender, no al comprar. Comprar siempre suma stock. #### Reserva de stock en Órdenes de Venta - **ON**: cuando se carga una Orden de Venta, el sistema **reserva** el stock (resta del disponible aunque no haya factura aún). Al facturar, libera la reserva y mueve el stock real. - **OFF**: la Orden de Venta no toca el stock disponible hasta que se factura. Caso de uso ON: empresa con sobreventa frecuente (varios pedidos para el mismo producto) que necesita "apartar" stock por pedido. #### Maneja lotes (per-sucursal) - **ON**: los productos que tengan `maneja_lote = true` requieren cargar lote + vencimiento al comprar / recibir. Las salidas consumen lotes vía FIFO. - **OFF**: el stock se maneja sin lote (saldo único por depósito). Caso de uso ON: farmacia, agro, alimentos. Caso OFF: ferretería, librería. #### Método de costeo - **FIFO** (default y único soportado hoy): consume primero el lote más viejo. - Otros métodos (PEPS por costo promedio, LIFO) están planificados pero no implementados. #### Días alerta vencimiento - Default: **30 días**. - Productos con vencimiento ≤ N días aparecen en alertas / dashboard de "Por vencer". #### Alertar lotes vencidos - **ON**: los lotes vencidos aparecen marcados en rojo en Movimientos de Stock + alerta al vender. - **OFF**: no se alerta. Se siguen consumiendo en FIFO normalmente. > Importante: aún con la alerta apagada, el lote vencido **sí se consume**. La alerta es solo visual. #### Crédito con cuotas obligatorias (per-sucursal) Este es el único flag real para `compras_credito_requiere_cuotas` — vive exclusivamente acá, por sucursal (no existe un equivalente global en Configuración → Facturación → Configuración de Compras). Si una sucursal tiene este flag en ON, la carga de **compra a crédito** en esa sucursal exige cuotas detalladas; otra sucursal de la misma empresa puede tenerlo en OFF. --- ### 3) Combinaciones recomendadas por tipo de negocio | Tipo de empresa | Modo de operación | Flujo de compra | Afecta stock directo | OC | Recepción | Matching 3v | Política stock | Lotes | |-----------------|-------------------|-----------------|----------------------|----|-----------|-------------|----------------|-------| | Kiosco / minimarket | Directo | Directo | ON | OFF | OFF | OFF | Estricto | OFF | | Farmacia | Directo | Directo | ON | OFF | OFF | OFF | Estricto | **ON** | | Ferretería con depósito | Req. opcional | Opcional | ON | ON | ON | OFF | Advertencia | OFF | | Mayorista importador | Req. obligatoria | Obligatorio | **OFF** | ON | ON | ON | Advertencia | ON/OFF | | Industria con auditoría | Req. obligatoria | Obligatorio | OFF | ON | ON | **ON** | Estricto | ON | | Servicios / consultoría | Directo | Directo | OFF | OFF | OFF | OFF | Libre | OFF | > Estos perfiles son sugerencias. Cada empresa puede ajustar el detalle. ### 4) Avisos de configuración mixta El sistema detecta varias combinaciones inconsistentes y muestra el banner **"Configuración mixta detectada"**: - Modo de operación **Directo** + Requisición obligatoria en ON. - Flujo de compra **Obligatorio** + Habilitar OC o Habilitar Recepción en OFF. - Matching 3 vías estricto en ON + OC u Recepción en OFF. - Afectar stock en compra directa en OFF + Habilitar Recepción en OFF (no hay forma de que entre el stock). En todos los casos, el sistema prioriza la opción **más restrictiva** hasta que se corrige la configuración. --- ## Solapa: Facturas (de compra) Listado de facturas recibidas. Excluye automáticamente las que están en `importado` o `rechazado` (esas viven en la solapa Marangatu). ### Columnas - Número de factura (formato `EST-PEX-NRO`). - Proveedor. - Fecha de emisión. - Estado (badge). - Moneda y total. ### Filtros - Rango de fechas (preset semana / mes / año). - Proveedor, sucursal, depósito, producto. - Búsqueda libre. - Estado. ### Acciones - 👁️ **Ver detalle**. - ✏️ **Editar** (si no está anulada). - ❌ **Anular** (reversa stock, CxP y asientos). - 📄 **Ver PDF**. ### Alta de factura — Cabecera **Obligatorios**: - **Proveedor**. - **Fecha de emisión** (por defecto hoy). - **Timbrado**, **establecimiento**, **punto de expedición**, **número de factura** del comprobante físico / electrónico. - **Depósito** y **sucursal**. - **Condición de operación**: contado o crédito. - **Moneda** del comprobante. Si no es PYG, aparece el campo **Cotización**, que se auto-completa con la tasa vigente (Contabilidad → Tipo de Cambio si el módulo está activo; en caso contrario, Configuración → Facturación → Monedas → Cotizaciones). El campo es editable — sobreescribí si la operación real usó otra tasa. Ver sección **"Cotización y multi-moneda"** más abajo dentro de "Pago al proveedor" para el detalle del patrón. **Si es crédito**: aparece el campo `plazo_credito` (default 30 días). ### Alta de factura — Ítems Cada ítem trae: - **Producto** (puede dejarse sin producto y solo con descripción para gastos / servicios). - **Descripción**. - **Cantidad** y **precio unitario**. - **% IVA**: 0 / 5 / 10. - **¿Afecta stock?** marcado por defecto si el producto maneja inventario. - Si el producto **maneja lote**: **número de lote** (auto-generado si vacío, formato `LYYYYMMDD-NNN`), **fecha de fabricación** y **fecha de vencimiento**. > El sistema usa la convención de Paraguay: el **precio unitario incluye IVA**. El IVA se extrae al guardar: `IVA = subtotal − (subtotal / (1 + tasa/100))`. ### Subtotales que calcula el sistema - `total_gravado_10`, `total_gravado_5`, `total_exento`. - `total_iva_10`, `total_iva_5`, `total_iva`. - `total` (suma con IVA incluido). ### Cuotas si es crédito La sucursal donde se registra la compra tiene una configuración llamada **`compras_credito_requiere_cuotas`** (es per-sucursal, no hay equivalente a nivel empresa): - **Desactivado**: el sistema genera **una sola cuota** con vencimiento = fecha emisión + plazo de crédito. - **Activado**: el usuario debe cargar manualmente las cuotas (cantidad, fecha de vencimiento y monto de cada una). La suma debe coincidir con el total. ### Pagos al contado Si la condición es contado, se cargan los pagos en el mismo formulario (medio de pago, monto, moneda, cotización). La factura queda directamente en estado **pagada**. > **Excepción**: si la empresa tiene activo **"Incluir contado en orden de pago"** (`incluir_contado_en_orden_pago`), el contado **no** carga pagos en el alta: queda como **cuenta por pagar pendiente** y se abona desde una orden de pago. Ver la sección de configuración más arriba. --- ## Solapa: Gastos Para registrar facturas que **no son de mercadería**: alquiler, servicios, combustible, viáticos, honorarios, etc. El flujo completo de gastos —tipos de gasto, formas de pago, anticipos personales, asientos contables y el ciclo de viáticos— está documentado en **`guia-gastos.md`**. ### Diferencias con una factura de compra | Aspecto | Compra | Gasto | |---------|--------|-------| | Afecta stock | Sí (si el ítem lo marca) | No | | IVA Crédito | Sí | Sí (si deducible) | | Cuenta contable destino | Mercaderías | Cuenta del tipo de gasto | | Tipo de gasto | — | Obligatorio por ítem | | Formas de pago | Contado / Crédito | Contado / Crédito / Transferencia / Anticipo personal | ### Alta de gasto — resumen Cabecera igual a la de compra (proveedor, timbrado, establecimiento, punto, número, fecha). En cada ítem se elige: - **Tipo de gasto** (catálogo configurable desde la solapa "Tipos de gasto"). - Descripción, cantidad, precio unitario con IVA incluido, % IVA. - La forma de pago **Anticipo personal** se usa cuando el empleado ya recibió un adelanto y está rindiendo facturas — el asiento acredita la cuenta `1.01.03.03.04 — ANTICIPO PARA VIÁTICOS` en vez de caja o banco. Ver flujo detallado en `guia-gastos.md`. ### Solapa "Tipos de gasto" CRUD del catálogo. Cada tipo define: - **Descripción** (obligatoria). - **% IVA** por defecto (0 / 5 / 10). - **Deducible**: si está ON, el IVA Crédito se separa en el asiento. Si OFF, el total con IVA va todo a la cuenta de gasto. - **Cuenta contable destino** (si Contabilidad está activa): qué cuenta se debita al registrar el gasto. Si no se configura, usa el fallback "Gastos Generales" (`6.1.2.99`). --- ## Solapa: Requisiciones Pedido interno previo a la compra. Sirve para que un sector solicite mercadería al área de Compras. - Estados: borrador → enviada → aprobada → ejecutada. - Una vez aprobada se puede convertir en **Orden de Compra**. - Configurable como obligatoria por empresa (`requisicion_obligatoria`). --- ## Solapa: Órdenes de Compra Compromiso formal con el proveedor antes de recibir la mercadería. - Se genera a partir de una requisición o directamente. - Estados: borrador → aprobada → en recepción → completada / cancelada. - Una OC puede tener **varias recepciones** parciales hasta completarse. ### Reglas - No se puede editar una OC cancelada o completada. - No se puede cancelar una OC con recepciones aplicadas. --- ## Solapa: Recepciones Registro físico de la mercadería que llega del proveedor. Se vincula a una **Orden de Compra**. - La cantidad recepcionada se descuenta del pendiente de la OC. - Se pueden hacer **recepciones parciales** sucesivas hasta cubrir la OC. - La cantidad recepcionada debe ser > 0 en cada línea. - No se puede recepcionar una OC cancelada o ya completada. - Una vez recepcionada, los ítems pueden facturarse cuando llega la factura del proveedor. --- ## Solapa: Marangatu Bot que importa al ERP las facturas que el SET tiene registradas como recibidas. Detalle completo del bot en `plan-marangatu-importacion.md`. ### Flujo de Compras Marangatu 1. **Captura**: bot consulta el SET del período y trae las facturas recibidas. 2. **Importar**: cada factura queda como `importado` (oculta de Facturas, no afecta stock ni CxP). 3. **Ajustar antes de confirmar** (opcional): - Cambiar la **condición de pago** si el XML la trae mal (ver abajo). - Cambiar la **vinculación de productos** de cualquier ítem — la vinculación automática es solo una sugerencia. 4. **Confirmar / Rechazar** (con confirmación previa): - Confirmar contado → aplica stock + crea pago → estado `pagada`. - Confirmar crédito → aplica stock + genera CxP con cuotas → estado `pendiente`. - Rechazar → queda como `rechazado` (auditoría, sin impacto). Reimportar el mismo período no duplica registros. ### Cambiar la condición de pago El chip **"Contado" / "Crédito"** del listado es **clickeable**. Se abre un diálogo que permite reemplazar la condición leída del XML por una del catálogo del ERP (**Configuración → Facturación → Métodos de Pago**, sección "Condiciones de Pago": Contado, 30 días, 6 cuotas, etc.). - El diálogo muestra la condición **detectada del XML** como referencia. - El select propone las condiciones del catálogo (`descripción — X cuota(s) · Yd`), filtradas por `activo = true`. - Al elegir una, aparece un preview con la condición que se va a aplicar. - Al confirmar, se actualiza `compra_cab.plazo_credito` y se reescribe el JSON de `observaciones.pago_info` — cuando después se "Confirme" la compra, las **cuotas se regeneran** en base a la nueva condición (no la del XML). - El id del catálogo elegido queda en el evento de auditoría para trazabilidad, aunque `compra_cab` no tiene FK directa a `condiciones_pago`. Cuándo usarlo: el XML de SET a veces trae la condición mal (ej. una factura de servicios recurrentes que llega como "contado" pero la empresa la paga a 30 días). ### Vincular / cambiar / desvincular productos El sistema intenta vincular automáticamente cada ítem del XML con un producto ERP por código y por descripción. **Esta vinculación es solo una sugerencia** y siempre se puede modificar antes de Confirmar. Ambos chips de la columna "Producto ERP" son **clickeables**: - **Ítem sin vincular** (chip amarillo "Vincular") → abre el diálogo de búsqueda para elegir el producto. - **Ítem ya vinculado** (chip verde con nombre) → abre el mismo diálogo en modo edición, mostrando el producto actual en un Alert y permitiendo: - Buscar otro producto para reemplazar la vinculación (botón "Cambiar vinculación"). - **Desvincular** el ítem (botón warning) — queda como sin producto ERP. Cuando el producto vinculado maneja inventario (`maneja_inventario = true`), al Confirmar la compra se aplicará el stock. Si no lo maneja, el ítem se registra contable/fiscalmente pero no mueve inventario. ### Confirmación antes de "Confirmar" y "Rechazar" Ambos botones ahora piden **confirmación previa** en un diálogo con contexto claro: **Confirmar**: - Muestra proveedor + comprobante + fecha. - Lista lo que va a hacer: registrar factura por X Gs., aplicar Contado/Crédito, cuántos ítems tienen producto vinculado, cuántos actualizarán stock, y si se generarán cuotas o asiento contable. - Advertencia final: "Esta acción no se puede deshacer desde este panel. Para revertir habrá que anular la factura desde el módulo Compras". - Botones **Cancelar** / **Sí, confirmar**. **Rechazar**: - Confirma que la compra pasará a estado `rechazado` sin afectar stock ni costos. - Se mantiene en el historial para auditoría. ### Auditoría de acciones en Marangatu Todas las acciones sobre una compra importada quedan registradas en `AuditService` con detalle: | Acción | Cuando ocurre | `entity_id` | Contexto (`new_value`) | |--------|---------------|-------------|-------------------------| | `MAR_ITEM_VINCULAR` | Se vincula un ítem a un producto ERP | `compra_det.id` | producto elegido (id + descripción + código + afecta_stock) + `old_value` con la vinculación previa + descripción/código del ítem del XML | | `MAR_ITEM_DESVINCULAR` | Se remueve la vinculación de un ítem | `compra_det.id` | igual que arriba con new_value en null | | `MAR_CONDICION_CAMBIAR` | Se cambia la condición de pago | `compra_cab.id` | es_credito, plazo_dias, cuotas, condicion_pago_id del catálogo elegido, comprobante · `old_value` con el `plazo_credito` original | | `MAR_COMPRA_CONFIRMAR` | Se confirma la compra | `compra_cab.id` | snapshot completo: comprobante, proveedor, total, es_credito, plazo, cuotas, depósito, items totales/con producto/afecta_stock | | `MAR_COMPRA_RECHAZAR` | Se rechaza la compra | `compra_cab.id` | comprobante, proveedor, total, motivo | Todos los eventos incluyen `user_id` (quien ejecutó la acción). Consultable desde la pantalla de Auditoría estándar del sistema filtrando por `entity_type = 'compra_cab'` o `'compra_det'`. --- ## Impacto en stock, costos, CxP y contabilidad ### Stock e inventario - Solo ítems con **`afecta_stock = true`** mueven inventario. - Al confirmar la compra: - Aumenta el stock disponible en `stock_deposito`. - Crea un movimiento de inventario tipo `compra` con cantidad positiva. - Si el producto maneja lote, crea un nuevo registro en `lotes_producto` con su costo y fecha de vencimiento. ### Costo y FIFO - Cada compra con producto que maneja lote genera **un lote** con su `costo_unitario`. - Al vender, el sistema consume los lotes en orden **FIFO**: primero el más viejo por fecha de fabricación, luego por fecha de creación. - El **`precio_costo` del producto** se actualiza al valor del precio unitario de la **última compra activa**. Si se anula una compra, se recalcula con la penúltima vigente. Detalle en `guia-inventario.md` y `plan-rentabilidad-compras-lotes-cxc.md`. ### Cuentas por Pagar (CxP) - Se genera un registro en `cuentas_pagar` (`origen_tipo = 'compra'`) con saldo igual al total. - Si `compras_credito_requiere_cuotas = false` (flag per-sucursal): una sola cuota con vencimiento calculado. - Si `true`: una cuota por cada cuota ingresada manualmente. - Cada cuota va a `cuentas_pagar_cuota` con estado `pendiente` / `parcial` / `pagada`. ### Contabilidad (si está habilitada) Asiento automático al confirmar la compra: ``` DEBE MERCADERÍAS (o cuenta del tipo de gasto) ………… total gravado DEBE IVA CRÉDITO 10% ………… iva 10% DEBE IVA CRÉDITO 5% ………… iva 5% HABER PROVEEDORES / CUENTAS POR PAGAR ………… total ``` Si la compra es **contado**, se agrega también el movimiento del pago (DEBE Proveedores / HABER Caja o Banco). > **Con "Incluir contado en orden de pago" activo**: la compra/gasto de contado **no** acredita Caja al registrarse — acredita **Proveedores** (igual que un crédito), porque queda pendiente. El movimiento de pago (DEBE Proveedores / HABER Caja o Banco) lo genera la **orden de pago** al ejecutarse. De esta forma el pago se asienta una sola vez. ### Pago al proveedor Se hace desde **Compras → Orden de Pago**: 1. Seleccionar el proveedor. Las CxP pendientes se cargan solas. 2. Tildar las cuotas a pagar. La moneda del formulario se **auto-alinea con la moneda de las cuentas seleccionadas** (si marcaste una CxP USD, la orden pasa a USD automáticamente). 3. Cargar medio de pago (efectivo, transferencia, cheque emitido). 4. Si es moneda extranjera: el campo **Cotización** se auto-completa con la tasa vigente (ver sección "Cotización y multi-moneda" más abajo). 5. Confirmar: reduce el saldo de CxP, registra movimiento en Tesorería / Bancos, genera asiento. Si `generar_cxp_automatico` está en ON (default) y la compra es contado, el sistema genera la orden de pago automáticamente al confirmar — excepto si `incluir_contado_en_orden_pago` está en ON, en cuyo caso el contado queda pendiente para pagarse manualmente por orden de pago. ### Validaciones al armar la orden - **No se pueden mezclar monedas en una misma OP**: si intentás tildar cuentas en distintas monedas (por ej. una en Gs. y otra en USD del mismo proveedor), aparece un banner rojo _"Monedas mezcladas: seleccionaste cuentas en PYG y USD…"_ y el botón **"Guardar orden"** queda deshabilitado. Emití **una orden por moneda**. - **Moneda del form desalineada**: si por alguna razón la moneda arriba del form no coincide con la de las cuentas tildadas, aparece un banner amarillo con el aviso. La UI la corrige sola al enviar, pero podés ajustarla manualmente antes. - **Backend defensivo**: aunque bypass del UI, el backend rechaza payloads con monedas mezcladas o cuando `moneda_id` del payload no coincide con la moneda de las CxPs. Nunca se cierra una CxP USD con un pago Gs., lo cual dejaría el asiento incoherente. ### Cotización y multi-moneda Cuando la OP es en moneda extranjera (o cuando la CxP subyacente lo es), la conversión a PYG para el asiento contable se hace con la **cotización cargada en el form**. La cotización se auto-carga por cascada: 1. **Si la empresa tiene módulo CONTABILIDAD activo** → última tasa registrada en `Contabilidad → Tipo de Cambio` para esa moneda ≤ la fecha de pago. 2. **Si no** → última cotización de `Configuración → Facturación → Monedas → Cotizaciones`. 3. **Si no hay ninguna** → se muestra `1` como fallback con un aviso naranja _"Sin cotización registrada — cargala y volvé a intentar"_. Debajo del campo aparece un helperText con la fuente y la fecha: _"Sugerido por Contabilidad al 18/04/2026"_ (verde), _"Sugerido por Facturación al 15/04/2026"_ (azul) o _"Cotización modificada manualmente"_ (gris) cuando el usuario sobreescribió. El campo **es editable**: si sabés que el pago real usó otra tasa (spread de tarjeta, negociación puntual), sobreescribí antes de guardar. El asiento contable va a usar exactamente esa tasa para multiplicar el monto USD y obtener PYG. ### Cómo se decide a qué cuenta de Tesorería impacta el pago Cuando ejecutás la OP, el sistema tiene que decidir a qué cuenta de Tesorería (banco, caja, fondo fijo) descontar el egreso. Sigue este orden de prioridad: 1. **Cuenta bancaria cargada en el modal del medio de pago** (por ej. al elegir Transferencia se abre el modal "Datos del medio de pago" pidiendo cuenta bancaria origen). Si cargás una cuenta ahí, **esa gana** — es específica de ese pago concreto y sobreescribe cualquier regla. 2. **Regla automática por medio de pago**: si el medio no pide cuenta explícita (Efectivo, Giro) o dejaste el modal vacío, busca en `Configuración → Tesorería y Bancos → Reglas Automáticas` una regla con `tipo_operacion=PAGO_PROVEEDOR + medio_pago=Transferencia` (o el que sea). 3. **Regla default**: si no hay regla específica del medio, busca una regla `PAGO_PROVEEDOR` sin medio (aplica a todo). 4. **Aviso**: si tampoco existe, aparece el diálogo _"Configuración de Tesorería incompleta"_. ### ¿Modal del medio vs. regla automática — cuál usar? Ambas capas cumplen roles distintos y **se complementan**: | Capa | Alcance | Cuándo la usás | Prioridad | |---|---|---|---| | **Modal del medio** (por-pago) | Este pago concreto | Cuando el pago va por una cuenta puntual (por ej. una transferencia se ordenó desde el Itaú aunque normalmente uses el BNF) | 1º — gana | | **Regla por medio de pago** | Toda la empresa, por medio | Default por medio (Transferencia→BNF, Cheque→Itaú, Tarjeta→BNF) | 2º | | **Regla default** | Toda la empresa | Fallback global (Efectivo/Giro → Caja General) | 3º | Ejemplo típico: configurás una regla `PAGO_PROVEEDOR + Transferencia → BNF principal` y otra `PAGO_PROVEEDOR default → Caja General`. A partir de ahí: - Cada OP con Transferencia usa BNF sin necesidad de completar nada más. - Cada OP con Efectivo/Giro usa Caja General. - Si un día pagás una Transferencia puntualmente desde el Itaú, la cambiás en el modal del medio y esa OP va por Itaú, sin tocar las reglas. ### Diálogo "Configuración de Tesorería incompleta" Cuando aparece este diálogo con el mensaje _"No existe una regla de Tesorería para Pago a proveedor…"_ significa que: - La orden quedó **pagada y contabilizada** (asiento CONFIRMADO + saldo CxP en 0). - Pero **no impactó Tesorería**: - El egreso **no aparece** en Caja del Día ni en Movimientos de Tesorería. - La Conciliación Bancaria no verá este pago. - Los reportes de Flujo de Caja quedan desactualizados. **Cómo resolverlo**: - Si el pago fue por Efectivo/Giro y usualmente sale por una caja fija → creá la regla default en `Configuración → Tesorería y Bancos → Reglas Automáticas`. - Si el pago era por Transferencia/Depósito y olvidaste cargar la cuenta en el modal → en la próxima OP asegurate de completarla ahí (gana sobre la regla). Alternativamente, creá también una regla `PAGO_PROVEEDOR + Transferencia → tu banco default` para no tener que cargar cuenta manualmente cada vez. El diálogo tiene un botón directo **"Ir a configurar"** que abre la pantalla de Reglas. A partir de que la regla existe, las próximas OPs generan el movimiento en Tesorería automáticamente. Para las OPs viejas ya emitidas sin regla: anulá y volvé a emitir (o registrá el movimiento a mano desde Tesorería). Ver la guía completa de tesorería en `guia-tesoreria-bancos.md` sección **"Puentes automáticos desde otros módulos"**. --- ## Notas de Crédito de Compra Sirven para devolver mercadería al proveedor o aplicar un descuento posterior a una factura ya cargada. ### Qué impacta - **Stock**: revierte la cantidad devuelta (sale del depósito). - **CxP**: reduce el saldo de la factura origen (FIFO por vencimiento). - **Estado de la compra**: se recalcula desde la CxP (NC total → *Pagada/saldada*; parcial → *Parcial*). - **IVA Crédito**: se reduce (aparece como resta en Libro IVA Compras y Liquidación de IVA). - **Contabilidad**: asiento inverso (DEBE Proveedores / HABER Mercaderías + IVA Crédito). - **Parciales**: soporta devolución parcial vía `compra_det.cantidad_acreditada_nc`. > **Guía dedicada**: para todas las validaciones, NC parciales, efectos al anular, contabilidad y reportes, ver **[`guia-nota-credito-compra.md`](guia-nota-credito-compra.md)**. --- ## Anulación de una compra ### Qué reversa 1. **Stock**: descuenta lo que sumó (crea movimiento tipo `anulacion`). 2. **Lotes**: deja los lotes consumidos como inválidos / sin disponibilidad. 3. **CxP**: cuotas pasan a anuladas, saldo en 0. 4. **Asientos**: reverso completo (DEBE y HABER invertidos). 5. **Pagos / Órdenes de Pago**: si había, también se anulan. 6. **`precio_costo` del producto**: se recalcula con la penúltima compra vigente. ### Restricciones - No se puede anular una compra ya anulada. - Si tiene recepciones parcialmente aplicadas (con matching 3-vías) se bloquea hasta revertir esas recepciones. - Si el período contable está cerrado, hay que reabrirlo o registrar el reverso manual. --- ## Validaciones del backend ### Compras - **"timbrado_proveedor es obligatorio"** / **"debe tener 8 dígitos"** (sólo proveedor local; exterior sólo controla largo ≤ 30). - **"establecimiento es obligatorio"** / **"debe tener 3 dígitos"** (sólo local). - **"punto_expedicion es obligatorio"** / **"debe tener 3 dígitos"** (sólo local). - **"Este tercero está clasificado como 'Acreedor vario' y no puede usarse en compras. Registrá la operación como Gasto."** - **"Proveedor no encontrado para la empresa"**. - **"Depósito no encontrado para la empresa"**. - **"Moneda no encontrada"** / **"Condición de operación no encontrada"**. - **"Cada ítem debe tener descripción"**. - **"Cantidad inválida para ítem {descripción}"** / **"Precio inválido para ítem {descripción}"**. - **"Ítem X: numero_lote supera máximo 50 caracteres"**. - **"Ítem X: fecha_fabricacion inválida"** / **"fecha_vencimiento inválida"**. - **"No se puede editar una compra anulada"** / **"No se puede contabilizar una compra anulada"**. - **"La compra requiere sucursal para generar numeración de orden de pago"**. ### Gastos - **"Proveedor requerido para registrar cuentas por pagar del gasto"**. - **"La configuración exige requisición obligatoria. Debés informar requisicion_id"**. - **"La descripción del tipo de gasto es obligatoria"** / **"El porcentaje de IVA debe ser 0, 5 o 10"**. - **"La requisición indicada no corresponde al origen gasto"** / **"debe estar aprobada para ejecutar gastos"**. - **"No se puede editar un gasto anulado"**. ### Recepciones y Órdenes de Compra - **"La empresa tiene deshabilitada la Recepción de Compra / Orden de Compra en Configuración de Compras"**. - **"No se puede reclasificar a Acreedor Vario: el tercero tiene N orden(es) de compra y M embarque(s) activos."** (al intentar reclasificar). - **"Este tercero está clasificado como 'Acreedor vario' y no puede usarse en órdenes de compra / embarques."** - **"Orden de compra no encontrada"** / **"requiere aprobación antes de registrar recepción"**. - **"No se puede recepcionar una orden cancelada"** / **"La orden de compra ya está completada"**. - **"La cantidad recepcionada debe ser mayor a cero en cada línea"**. - **"No se puede editar una recepción anulada"** / **"una orden de compra cancelada"** / **"completada"**. - **"La orden de compra debe tener al menos un ítem"**. - **"No se puede cancelar: la orden ya tiene recepciones aplicadas"**. ### Órdenes de Pago (multi-moneda) - **"Las cuentas por pagar seleccionadas tienen monedas distintas. Emití una orden de pago por moneda."** (al intentar mezclar PYG + USD en una misma OP). - **"La moneda de la orden de pago debe coincidir con la moneda de las cuentas por pagar seleccionadas."** (payload con `moneda_id` desalineado — bloqueado por seguridad). - **"No existe una regla de Tesorería para 'Pago a proveedor'. Configurá la cuenta en Configuración > Tesorería > Reglas."** (aviso, no error — la OP se guarda pero no impacta Tesorería). ### FIFO al vender - **"Stock por lotes insuficiente para producto {X} en depósito {Y}. Faltante: {Z}"**. --- ## Reportes de compras ### Libro IVA Compras - **Ruta**: Reportes → Fiscal e Impuestos → Libro IVA Compras. - Detalle de compras del mes con timbrado, gravado 10/5/exento e IVA Crédito. - Insumo para el Formulario 120 (ver `guia-facturacion.md` sección reportes fiscales). - **Exige acceso a toda la empresa**: no se recorta por sucursal, se bloquea. Un usuario asignado a una sucursal recibe un mensaje pidiéndole que se lo solicite a alguien sin restricción — un libro recortado haría declarar de menos. Lo mismo vale para la versión Marangatu. ### Resumen de Compras - **Ruta**: Reportes → Administrativos y Financieros → Resumen de Compras. - Totales por período y proveedor, con desglose por moneda y estado. ### Clasificación de terceros - **Ruta**: Reportes → Administrativos y Financieros → Clasificación de terceros. - Lista de proveedores/acreedores con tipo, cuenta contable efectiva (override o por concepto), CxP abiertas y saldo. Acceso directo a reclasificar. Ver sección "Tipos de tercero" para el detalle del flujo. ### Cuentas por Pagar - **Ruta**: Reportes → Administrativos y Financieros → Cuentas por Pagar. - Aging de la deuda con proveedores (0-30, 31-60, 61-90, 90+). - Ranking de proveedores por saldo pendiente. ### Rentabilidad - **Ruta**: Reportes → Ventas → Rentabilidad. - Aprovecha el dato de **costo por lote** capturado al vender. Cruza venta vs costo y muestra **margen %** por producto, cliente y sucursal. - Si la compra está mal cargada (precio costo distorsionado), la rentabilidad sale mal. Por eso es importante revisar el `precio_costo` y los lotes. ### Movimientos de Stock por compra - **Ruta**: Reportes → Inventario → Movimientos de Stock. - Filtrando por tipo `compra` se ven las entradas generadas, con lote y costo. ### Lo que aún no está - **Resumen Anual** y **Facturas Recurrentes** figuran como "Próximamente". --- ## Lo que NO se puede hacer - Cargar una factura de compra sin proveedor. - Cargar dos veces la misma factura del mismo proveedor con mismo timbrado + número (queda como duplicado). - Editar una compra anulada. - Anular una compra con recepciones pendientes de reversar. - Vender un producto sin stock disponible en lote (si maneja lote). - Forzar el precio de costo del producto en la ficha del producto si el módulo está bajo control FIFO — se actualiza desde compras. --- ## Qué ve cada usuario (alcance por sucursal) Un usuario **asignado a una o más sucursales** ve en Compras y Órdenes de Compra únicamente los documentos de esas sucursales. Uno **sin asignaciones** ve toda la empresa. Acá el filtro es directo: la compra y la orden de compra **guardan la sucursal** en el documento. No hay traducción por punto de establecimiento como en las facturas. Eso trae un caso a tener en cuenta: **una compra cargada sin sucursal no aparece para ningún usuario restringido**. Suele pasar con documentos migrados o cargados antes de que el campo fuera obligatorio. Se corrigen editando la compra, o pidiendo un backfill que les asigne la sucursal a partir de su depósito. El **Libro IVA de Compras** y su versión para Marangatu son la excepción: no se recortan, se **bloquean** para usuarios restringidos (ver abajo). Detalle completo en `guia-alcance-por-sucursal.md`. --- ## Problemas frecuentes - **"La compra no aparece en Facturas"**: está en estado `importado` (Marangatu) o `rechazado`. Ir a la solapa Marangatu para confirmar o rechazar. - **"El IVA Crédito no me cierra con el Libro IVA Compras"**: revisar que las compras tengan timbrado vigente y que estén confirmadas, no en estado `importado`. - **"Vendí un producto y no tiene costo en el reporte"**: el producto se vendió antes de tener un lote cargado. La rentabilidad de esa venta sale en 0 o sin costo. - **"No puedo recepcionar más"**: la OC ya está completada o cancelada. Crear una nueva OC. - **"Anulé la compra y el stock quedó negativo"**: la mercadería ya fue vendida. Hay que ajustar manualmente desde Inventario. - **"El sistema dice que hay stock insuficiente para vender, pero veo cantidad en el producto"**: el producto maneja lote y la cantidad disponible está en lotes específicos. Verificar lotes activos en Movimientos de Stock. - **"Cargué un gasto pero no aparece en Libro IVA Compras"**: solo aparecen ítems con % IVA > 0. Los gastos exentos no se listan en el libro IVA. - **"Un usuario no ve compras que sí existen"**: está asignado a una sucursal. Si las compras que faltan quedaron **sin sucursal cargada**, no las ve nadie restringido — hay que completárselas. Ver `guia-alcance-por-sucursal.md`. - **"No puede abrir el Libro IVA Compras"**: es correcto. Los libros fiscales exigen acceso a toda la empresa; se los tiene que sacar alguien sin restricción por sucursal. --- ## Limitaciones actuales - Marangatu Compras tiene cron automático cada 6 h; Marangatu Ventas todavía no. - El **matching 3-vías** (OC ↔ Recepción ↔ Factura) está implementado, pero no es obligatorio: lo activa la configuración por empresa. - **Facturas recurrentes** (alquileres, servicios mensuales) y **Resumen Anual** todavía no están disponibles (figuran como "Próximamente" en Reportes). - La **reversa de stock** al anular no recompone los lotes consumidos por ventas posteriores: si ya se vendió, hay que ajustar manualmente. - **Notas de Crédito de Compra**: cubren devolución **parcial y total**, con recálculo del estado de la compra, reversión FIFO de CxP y asiento inverso. Ver **[`guia-nota-credito-compra.md`](guia-nota-credito-compra.md)**. --- ## Documentos relacionados - `guia-alcance-por-sucursal.md` — qué compras y órdenes ve cada usuario según sus asignaciones. - `guia-nota-credito-compra.md` — **NC de compra** en detalle: validaciones, parciales, contabilidad, anulación y reportes. - `guia-gastos.md` — módulo Gastos completo: tipos, formas de pago, viáticos, anticipos, asientos. - `guia-facturacion.md` — Marangatu Compras / Ventas y el ciclo SIFEN. - `guia-inventario.md` — stock, FIFO, ajustes y lotes en profundidad. - `guia-cobros-finanzas.md` — Orden de Pago y movimiento en Tesorería al pagar. - `guia-contactos.md` — alta y manejo del proveedor. - `plan-marangatu-importacion.md` — diseño del bot de Marangatu y el flujo de dos fases. - `plan-prueba-usuario-compras-gastos.md` — escenarios de prueba (directo, mixto, requisición obligatoria). - `plan-rentabilidad-compras-lotes-cxc.md` — lote por compra, FIFO al vender, captura de costo, dashboard CxC y rentabilidad. - `plan-acreedores-proveedores-exterior.md` — modelo de `tipo_entidad`, cuenta pasivo congelada en CxP, reclasificación y reporte de clasificación de terceros. - `guia-conciliacion-contable.md` — si un lote de compras Marangatu importadas históricas no generaron asiento (ej. porque el módulo Contabilidad se activó después), la Conciliación Contable las detecta y permite regenerar los asientos en lote. - `guia-rubros.md` — el buscador de proveedores muestra los del rubro en el que estás trabajando, más los que no tienen rubro asignado.