Configuración Flexible de Tipos de Comprobantes de Facturación Electrónica

Módulo: Ventas Tipo: Process Estado: Planificado Fecha: 2026-01-07 Última Actualización: 2026-01-07 - Añadida determinación automática de letra y soporte para letras extendidas (ALEY, 49)

Descripción

Problema de Negocio

Actualmente, el sistema de facturación electrónica utiliza códigos de tipos de comprobantes (códigos ARCA/AFIP) que están definidos de manera fija en el código del sistema. Por ejemplo:

Factura A siempre usa código 1
Factura B siempre usa código 6
Nota de Crédito A siempre usa código 3

Esta rigidez genera los siguientes problemas de negocio:

Falta de flexibilidad regulatoria: Cuando AFIP introduce nuevos códigos especiales (como el código 51 para "Factura A sujeta a retenciones"), el sistema no puede utilizarlos sin modificaciones en el código fuente.
Imposibilidad de adaptación por empresa: Cada empresa tiene diferentes obligaciones fiscales y situaciones tributarias. Algunas empresas necesitan usar códigos especiales (51, 52, 53 para comprobantes sujetos a retenciones), mientras que otras usan los códigos estándar (1, 2, 3). El sistema actual no permite esta flexibilidad.
Dependencia de desarrolladores: Cuando una empresa necesita cambiar el tipo de código que utiliza (por ejemplo, pasar de Factura A código 1 a Factura A código 51), requiere modificaciones en el código y un nuevo despliegue, lo cual es costoso y lento.
Incumplimiento potencial: Las empresas que están sujetas a régimen especiales de retención no pueden facturar con los códigos correctos que exige AFIP, arriesgando sanciones.

Solución Propuesta

Implementar un mecanismo de configuración flexible que permita al sistema determinar dinámicamente qué código ARCA usar para cada tipo de comprobante, combinando:

Validación dinámica con AFIP para determinar letras fiscalmente válidas
Configuración flexible en tabla formul con soporte para letras extendidas (A, ALEY, B, C, 49)
Selección inteligente mediante intersección: auto-selección si hay una opción, selector si hay múltiples opciones válidas

Cómo funciona:

Determinación Automática de Letra:

El sistema consulta a AFIP qué letras son válidas para el cliente seleccionado
Cruza las letras válidas de AFIP con las configuraciones disponibles en formul para ese tipo de comprobante
Si hay una sola coincidencia: usa automáticamente esa letra (transparente para el usuario)
Si hay múltiples coincidencias: muestra selector para que el usuario elija (ej: "A" o "ALEY")
Si no hay coincidencias: error "No hay configuración válida para este tipo de cliente"

Soporte para Letras Extendidas:

El campo tipo (letra) ahora soporta hasta 5 caracteres
Permite configurar letras especiales más allá de A, B, C:
- ALEY: Comprobantes A con leyenda especial (ej: Ley 27.541)
- 49: Factura de Crédito Electrónico MiPyME (Bienes Usados)
Cada letra especial requiere configuración explícita y selección manual del usuario

Configuración Flexible:

Los administradores pueden configurar múltiples variantes del mismo tipo de comprobante (ej: dos "Factura A" con códigos diferentes)
Cuando un usuario crea una factura con letra calculada/elegida, el sistema consulta la tabla formul
Si hay una sola opción: el sistema usa automáticamente ese código (comportamiento transparente)
Si hay múltiples opciones: el sistema muestra un selector para que el usuario elija cuál usar (ej: "Factura A estándar código 1" vs "Factura A sujeta a retención código 51")
Los administradores pueden crear, modificar, activar/desactivar o eliminar tipos de comprobante según las necesidades de la empresa
Sin validación de duplicidad: se permite tener múltiples configuraciones con el mismo nombre y letra, diferenciadas por descripción y código

Valor de Negocio

Cumplimiento regulatorio:

Las empresas pueden utilizar los códigos especiales que AFIP exige según su situación fiscal
Reducción del riesgo de sanciones por uso de códigos incorrectos
Adaptación inmediata a nuevas normativas de AFIP

Flexibilidad operativa:

Cada empresa configura los códigos según sus necesidades tributarias
Cambios de configuración sin esperar despliegues de sistemas
Autonomía operativa: los administradores controlan la configuración, no los desarrolladores

Mantenibilidad:

Cuando AFIP introduce nuevos códigos, solo se modifica la configuración, no el código del sistema
Menor costo de mantenimiento y actualización
Implementación más rápida de cambios normativos

Eficiencia:

Reducción de tiempos de adaptación ante cambios regulatorios
Menor dependencia del equipo de desarrollo para ajustes de configuración
Capacidad de prueba y reversión rápida de cambios

Reducción de Errores (NUEVO):

Validación automática contra AFIP elimina errores de selección de letra incorrecta
Solo se muestran opciones válidas según reglas fiscales de AFIP para ese cliente específico
Si hay una sola opción válida, se selecciona automáticamente (sin intervención del usuario)
Si hay múltiples opciones válidas, el usuario elige entre las permitidas por AFIP

Contexto del Sistema

Esta funcionalidad afecta el módulo de Facturación Electrónica dentro del sistema de Ventas. El cambio principal es en el proceso de determinación del código de comprobante que se envía al servicio web de ARCA (AFIP).

Estado actual: Código fijo definido en constantes del sistema, sin validación previa contra AFIP Estado deseado: Código dinámico consultado desde configuración en tabla formul, validado automáticamente contra reglas de AFIP para cada cliente

Proceso de Negocio

Flujo de Selección Flexible de Código de Comprobante

mermaid

flowchart TD
    A[Usuario crea factura electrónica]
    B[Usuario selecciona tipo: Factura]
    C[Usuario selecciona cliente]
    D[Sistema consulta a AFIP: letras válidas para ese cliente]
    E[AFIP retorna letras permitidas: ej. A, ALEY]
    F[Sistema consulta formul: configuraciones activas para Factura]
    G[formul retorna configuraciones: ej. Factura A, Factura B]
    H[Sistema hace intersección: letras AFIP ∩ letras formul]
    I{¿Cuántas coincidencias?}
    J{¿0 coincidencias?}
    K[Error: No hay configuración válida para este cliente]
    L{¿1 coincidencia?}
    M[Usar letra/código automáticamente]
    N{¿Múltiples coincidencias?}
    O[Mostrar selector al usuario con opciones válidas]
    P[Usuario selecciona entre opciones válidas]
    Q[Ejemplo: Usuario selecciona entre letra A o ALEY]
    R{¿Letra tiene múltiples códigos en formul?}
    S[Usar código único directamente]
    T[Mostrar selector de variantes del mismo tipo]
    U[Usuario selecciona variante]
    V[Usar código seleccionado]
    W[Enviar comprobante a ARCA con código]
    X[ARCA valida y retorna CAE]
    Y[Guardar factura con letra y código usado]

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F
    F --> G
    G --> H
    H --> I
    I --> J
    J -->|SÍ| K
    I --> L
    L -->|SÍ| M
    I --> N
    N -->|SÍ| O
    O --> P
    P --> Q
    Q --> R
    M --> R
    R -->|NO| S
    R -->|SÍ| T
    T --> U
    U --> V
    S --> W
    V --> W
    W --> X
    X --> Y

    style A fill:#e1f5ff
    style D fill:#fff3cd
    style H fill:#ffe6cc
    style K fill:#f8d7da
    style M fill:#d4edda
    style O fill:#fff3cd
    style T fill:#fff3cd
    style S fill:#d4edda
    style V fill:#d4edda
    style X fill:#d4edda

Gestión de Tipos de Comprobante (ABM)

La configuración de tipos de comprobante (tabla formul) se gestiona mediante un ABM dedicado que permite a los administradores:

Crear nuevos tipos desde el catálogo ARCA
Modificar configuraciones existentes
Desactivar tipos cuando ya no se necesiten

Referencia completa: Ver ABM de Tipos de Comprobante para la documentación detallada del proceso de administración.

Frontend (Perspectiva de Usuario)

Vistas

1. Gestión de Tipos de Comprobante

La configuración de tipos de comprobante se realiza en una vista administrativa separada, documentada en detalle en ABM de Tipos de Comprobante.

Esta configuración es independiente del proceso de facturación y permite a los administradores gestionar el catálogo de tipos disponibles para cada empresa.

2. Vista de Creación de Factura (Con selector opcional)

Propósito: Permitir al usuario seleccionar la variante específica de comprobante cuando existen múltiples opciones configuradas para el tipo y letra calculada.

Comportamiento:

Paso previo: Determinación automática de letra

Usuario selecciona tipo de comprobante (Factura, Nota de Crédito, Nota de Débito)
Sistema calcula automáticamente la letra según condiciones fiscales:
- Condición IVA emisor (empresa): Responsable Inscripto, Monotributista, Exento, etc.
- Condición IVA receptor (cliente): Responsable Inscripto, Consumidor Final, Exento, etc.
- Regla de cálculo:
  - RI (emisor) + RI (receptor) = Letra A
  - RI (emisor) + Consumidor Final (receptor) = Letra B
  - RI (emisor) + Exento (receptor) = Letra C
  - (Otras combinaciones según normativa AFIP)

Caso 1: Una sola opción configurada (comportamiento automático)

Usuario selecciona tipo: "Factura"
Sistema calcula letra: "A" (según condiciones IVA)
Sistema busca configuraciones activas para tipo_comprobante="factura" AND letra="A"
Sistema encuentra solo 1 configuración activa
Sistema usa automáticamente ese código ARCA (transparente para el usuario)
El proceso continúa igual que siempre

Caso 2: Múltiples opciones configuradas (con selector)

Usuario selecciona tipo: "Factura"
Sistema calcula letra: "A" (según condiciones IVA)
Sistema busca configuraciones activas para tipo_comprobante="factura" AND letra="A"
Sistema encuentra 2 o más configuraciones activas (ej: código 1 y código 51)
Sistema muestra selector: "¿Qué tipo de Factura A desea emitir?"
Opciones mostradas con descripción clara:
- [ ] Factura A estándar
- [ ] Factura A sujeta a retención
Usuario selecciona la opción deseada obligatoriamente
Sistema usa el código ARCA de la opción seleccionada
El resto del proceso continúa normalmente

Caso 3: Ninguna opción configurada

Usuario selecciona tipo: "Factura"
Sistema calcula letra: "A"
Sistema no encuentra configuraciones activas para Factura A
Error: "No hay tipos de Factura A configurados para esta empresa. Contacte al administrador."

Nota importante: La letra NUNCA es seleccionada manualmente por el usuario. Es siempre calculada automáticamente por el sistema según las condiciones fiscales.

Interacciones del Usuario

Acción	Actor	Descripción	Resultado Esperado
Gestionar tipos de comprobante	Administrador	Ver, crear, modificar y desactivar tipos (Ver ABM de Tipos de Comprobante)	Configuración de catálogo de tipos disponibles para la empresa
Crear factura (una sola opción)	Usuario de ventas	Selecciona Factura A, solo hay 1 configuración activa	Sistema usa automáticamente ese código (transparente), registra en ARCA, obtiene CAE
Crear factura (múltiples opciones)	Usuario de ventas	Selecciona Factura A, hay 2+ configuraciones activas	Sistema muestra selector "¿Qué tipo de Factura A desea emitir?", usuario selecciona opción, sistema usa código elegido
Seleccionar tipo de comprobante	Usuario de ventas	Elige entre "Factura A estándar" o "Factura A sujeta a retención" en el selector	Sistema usa el código ARCA correspondiente a la opción seleccionada
Validar configuración	Sistema	Al guardar cambios, valida que código sea numérico y dentro de rangos AFIP	Si válido: guarda; Si inválido: muestra error claro al administrador

Permisos

Los permisos de negocio necesarios para las operaciones son:

Permiso	Descripción	Operaciones Permitidas
`VENTAS_BASES_COMPROBANTES`	Ver configuración de tipos de comprobante	Consultar listado de tipos de comprobantes y acceso al ABM

Estados de UI

Estados en Gestión de Tipos de Comprobante

La gestión de tipos de comprobante (ABM) tiene sus propios estados de UI documentados en detalle en ABM de Tipos de Comprobante, incluyendo:

Estados de listado y filtrado
Estados de formularios (crear/modificar)
Estados de validación
Estados de éxito y error
Manejo de integración con API ARCA

Estados en Facturación (Transparente)

Durante Creación de Factura:

Usuario selecciona tipo como siempre
Sistema consulta formul en segundo plano (no visible)
Si falta configuración: Error claro "El tipo de comprobante Factura A no está configurado para esta empresa. Contacte al administrador."
Si configuración OK: Proceso continúa normalmente, código se usa internamente

Backend (Perspectiva de Datos de Negocio)

Entidades de Negocio

Entidad Principal: Tipo de Comprobante (formul)

Representa la configuración de cada tipo de comprobante que la empresa puede emitir electrónicamente.

Identificación:

Cada configuración se identifica por un ID único (puede haber múltiples configuraciones para el mismo tipo de comprobante y letra)
NO hay unicidad en la combinación tipo_comprobante + letra
Ejemplo: Puede haber dos configuraciones de "factura" + "A" (una código 1, otra código 51)
Diferenciación: Por código ARCA y descripción

Alcance:

Configuración por empresa/sucursal (multi-tenant)
Cada empresa tiene su propia configuración independiente
Una empresa puede tener múltiples variantes del mismo tipo y letra

Datos Necesarios

Para Configuración de Formul

Dato	Descripción de Negocio	Uso
Tipo de Comprobante	Agrupador categórico del comprobante	"factura", "nota-credito", "nota-debito", "ticket", "recibo". Agrupa comprobantes por naturaleza fiscal. Permite filtrar y organizar en UI.
Código ARCA	Código numérico oficial que AFIP asigna a cada tipo de comprobante	Este es el valor dinámico que se envía a ARCA al registrar comprobantes. Puede ser 1, 51, 52, etc.
Nombre/Descripción	Descripción clara y específica de este comprobante	Ej: "Factura A estándar", "Factura A sujeta a retención", "Nota de Crédito A por devolución". Se muestra al usuario en selector cuando hay múltiples opciones.
Letra/Clase	Letra o clase que indica la categoría fiscal (soporta hasta 5 caracteres)	Valores estándar: "A" (Responsable Inscripto), "B" (Consumidor Final), "C" (Exento/Monotributista), "X" (Otros). Valores extendidos: "ALEY" (Comprobantes A con leyenda especial - Ley 27.541 o similar), "49" (Factura de Crédito Electrónico MiPyME - Bienes Usados). Las clases especiales (ALEY, 49) requieren configuración explícita y selección manual del usuario.
Template de reporte	Código del template PDF asociado	Ej: "FA1" para Factura A estándar, "FA51" para Factura A con retenciones. Define diseño del comprobante impreso.
Numerador	Número correlativo actual para ese tipo	Próximo número de comprobante a emitir. Se incrementa automáticamente por cada configuración.
Abreviatura	Forma corta para mostrar en listados	Ej: "Fac.", "NC.", "ND.", "Tkt.", "Rec.". Para uso en interfaces compactas.
Estado	Indica si el tipo está activo o inactivo	"Activo" (disponible para facturación), "Inactivo" (oculto, no se puede usar para nuevos comprobantes).

Para Proceso de Facturación

Datos de entrada (del usuario):

Tipo de comprobante seleccionado (factura, nota-credito, nota-debito, etc.)
Datos del cliente (CUIT, razón social, condición IVA, etc.)
Ítems del comprobante (productos/servicios)
Si hay múltiples opciones para el tipo+letra calculada: selección específica del usuario entre las variantes disponibles

Datos calculados por el sistema:

Letra del comprobante (A, B, C, X) - Calculada automáticamente según:
- Condición IVA del emisor (empresa)
- Condición IVA del receptor (cliente)
- Reglas fiscales de AFIP

Datos de consulta (desde formul):

Query de negocio: "Dame todas las configuraciones activas donde tipo_comprobante = [factura] AND letra = [letra_calculada]"
Respuesta:
- Si 0 resultados: Error "Tipo de comprobante no configurado"
- Si 1 resultado: Usar automáticamente ese código ARCA (transparente)
- Si múltiples resultados: Mostrar selector al usuario con descripción de cada opción, usuario elige, usar código de opción elegida

Datos de salida (hacia ARCA):

Código ARCA del comprobante (obtenido de formul)
Punto de venta
Número de comprobante
Datos fiscales del cliente
Importes y tributos

Relaciones de Negocio

mermaid

erDiagram
    TIPO_COMPROBANTE ||--o{ FACTURA : "define código para"
    TIPO_COMPROBANTE ||--o{ NOTA_CREDITO : "define código para"
    TIPO_COMPROBANTE ||--o{ NOTA_DEBITO : "define código para"

    TIPO_COMPROBANTE {
        entero id "ID único"
        texto tipo_comprobante "Agrupador: factura, nota-credito, ticket, etc"
        entero codigo "Código ARCA dinámico"
        texto descripcion "Descripción específica"
        texto letra "A/B/C/X"
        texto reporte "Template PDF"
        entero numerador "Número correlativo"
        texto abreviatura "Forma corta"
        booleano activo "Activo o inactivo"
    }

    FACTURA {
        entero id_tipo_comprobante "Código usado al emitir"
        texto nrocae "CAE de AFIP"
        fecha fevtocae "Vencimiento CAE"
    }

    NOTA_CREDITO {
        entero id_tipo_comprobante "Código usado al emitir"
        texto nrocae "CAE de AFIP"
    }

    NOTA_DEBITO {
        entero id_tipo_comprobante "Código usado al emitir"
        texto nrocae "CAE de AFIP"
    }

Relaciones explicadas:

Tipo de Comprobante → Facturas/Notas: Una configuración de tipo de comprobante puede usarse para emitir múltiples comprobantes. Cada factura/nota almacena el código que fue usado al momento de su emisión.
Múltiples Configuraciones del Mismo Tipo: Una empresa puede tener varias configuraciones del mismo tipo_comprobante y letra. Por ejemplo:
- Configuración 1: tipo_comprobante="factura", letra="A", codigo=1, descripcion="Factura A estándar"
- Configuración 2: tipo_comprobante="factura", letra="A", codigo=51, descripcion="Factura A sujeta a retención"
- Ambas coexisten y el usuario elige cuál usar al facturar
Configuración por Empresa: Cada empresa/sucursal tiene su propio conjunto de tipos de comprobante configurados. Empresa A puede tener dos variantes de Factura A (código 1 y 51), mientras Empresa B puede tener solo una (código 1).
Inmutabilidad Histórica: Una vez emitido un comprobante con un código específico, ese código queda registrado permanentemente en ese comprobante, aunque las configuraciones en formul cambien posteriormente.

Validaciones de Negocio

Validación	Condición	Comportamiento Esperado	Fundamento de Negocio
Código ARCA válido	El código debe existir en la normativa de AFIP	Error: "El código ingresado no es válido según AFIP"	Solo códigos oficiales de AFIP pueden ser registrados ante ARCA
Tipo de comprobante válido	El tipo_comprobante debe ser uno de los valores permitidos	Error: "El tipo de comprobante debe ser: factura, nota-credito, nota-debito, ticket o recibo"	Solo tipos reconocidos pueden ser gestionados
Letra/Clase válida	La letra o clase debe ser un valor reconocido (A, B, C, X, ALEY, 49, etc.) y no exceder 5 caracteres	Error: "La letra/clase del comprobante debe ser un valor válido (A, B, C, X, ALEY, 49)"	AFIP reconoce categorías fiscales estándar y especiales; el campo soporta hasta 5 caracteres para clases extendidas
Código numérico positivo	El código debe ser número entero positivo	Error: "El código debe ser un número mayor a 0"	Los códigos ARCA son siempre números positivos
Descripción requerida	La descripción debe estar presente y no vacía	Error: "La descripción es obligatoria"	Necesaria para diferenciar configuraciones del mismo tipo+letra
Aceptación por ARCA	Al enviar comprobante, ARCA debe aceptar el código	Error de AFIP: devolver mensaje de rechazo exacto	AFIP es la autoridad final de validación
No eliminar tipos con comprobantes	No se pueden eliminar configuraciones que tienen comprobantes emitidos	Prevenir eliminación, solo desactivación permitida	Integridad referencial y auditoría
Selección obligatoria	Si hay múltiples opciones, el usuario DEBE seleccionar una	Error: "Debe seleccionar el tipo de factura a emitir"	Evitar ambigüedad en la facturación

Reglas de Negocio

RN-001: Resolución Dinámica de Código con Cálculo de Letra y Selector Condicional

Descripción: El sistema debe calcular automáticamente la letra del comprobante según condiciones fiscales, luego resolver el código ARCA consultando las configuraciones activas almacenadas en la tabla formul. Si hay múltiples configuraciones para el tipo y letra calculada, el usuario debe seleccionar cuál usar.

Condición de aplicación: Cada vez que un usuario crea un comprobante electrónico (factura, nota de crédito, nota de débito).

Flujo de aplicación:

Usuario selecciona tipo de comprobante (factura, nota-credito, nota-debito, etc.)
Usuario selecciona cliente (con su condición IVA ya registrada)
Sistema calcula automáticamente la letra del comprobante según:
- Condición IVA del emisor (empresa): ej. Responsable Inscripto
- Condición IVA del receptor (cliente): ej. Responsable Inscripto, Consumidor Final, Exento
- Reglas de cálculo:
  - RI (emisor) + RI (receptor) = Letra A
  - RI (emisor) + Consumidor Final (receptor) = Letra B
  - RI (emisor) + Exento (receptor) = Letra C
  - Monotributista (emisor) + cualquiera = Letra C (o según normativa)
  - Otras combinaciones según normativa AFIP vigente
Sistema consulta formul: buscar TODAS las configuraciones activas donde tipo_comprobante = tipo seleccionado AND letra = letra calculada
Sistema evalúa resultados:
- Si 0 resultados: Error "No hay configuraciones activas para [tipo] [letra] en esta empresa. Contacte al administrador."
- Si 1 resultado: Usar automáticamente ese código ARCA (transparente para el usuario)
- Si 2+ resultados: Mostrar selector con descripción de cada opción, usuario DEBE elegir una
Si hubo selector: Usuario selecciona opción deseada (ej: "Factura A estándar" vs "Factura A sujeta a retención")
Sistema procede con el código ARCA dinámico obtenido (no con código fijo)

Fundamento de negocio: Permite que cada empresa use los códigos que necesita según su situación fiscal, con flexibilidad para tener múltiples variantes del mismo tipo cuando es necesario.

Ejemplo 1 (una sola opción):

Empresa A tiene configurado: tipo_comprobante="factura", letra="A", codigo=1, descripcion="Factura A"
Usuario selecciona Factura A → Sistema usa automáticamente código 1 (sin mostrar selector)

Ejemplo 2 (múltiples opciones):

Empresa B tiene configuradas DOS variantes:
- Opción 1: tipo_comprobante="factura", letra="A", codigo=1, descripcion="Factura A estándar"
- Opción 2: tipo_comprobante="factura", letra="A", codigo=51, descripcion="Factura A sujeta a retención"
Usuario selecciona Factura A → Sistema muestra selector: "¿Qué tipo de Factura A desea emitir?"
Usuario elige "Factura A sujeta a retención" → Sistema usa código 51

RN-002: Cambios con Efecto Inmediato

Descripción: Los cambios realizados en la configuración de formul deben aplicarse inmediatamente en los comprobantes que se emitan a partir de ese momento. Los comprobantes históricos NO se modifican.

Condición de aplicación: Cuando un administrador modifica un registro en formul.

Comportamiento esperado:

Para comprobantes creados ANTES del cambio:

Mantienen el código ARCA con el que fueron emitidos originalmente
No se modifican retroactivamente
Su CAE y datos fiscales permanecen intactos

Para comprobantes creados DESPUÉS del cambio:

Usan el nuevo código ARCA configurado
Se registran ante ARCA con el código actualizado
Obtienen CAE correspondiente al nuevo código

Fundamento de negocio:

Integridad histórica: Los comprobantes emitidos son documentos fiscales oficiales que no deben alterarse después de su emisión
Flexibilidad operativa: Los cambios de configuración deben aplicarse de inmediato para adaptarse a nuevas necesidades regulatorias

Ejemplo:

Lunes: Empresa configura Factura A = código 1
Lunes: Se emiten facturas 001 a 010 con código 1
Martes: Administrador cambia configuración a Factura A = código 51
Martes: Se emiten facturas 011 a 020 con código 51
Resultado: Facturas 001-010 mantienen código 1 en base de datos, facturas 011-020 tienen código 51

RN-003: Validación Final por AFIP

Descripción: El código ARCA configurado debe ser validado y aceptado por AFIP al momento de registrar el comprobante. AFIP es la autoridad final de validación.

Condición de aplicación: Durante el proceso de autorización del comprobante electrónico con ARCA.

Comportamiento esperado:

Si ARCA acepta el código:

Se obtiene el CAE (Código de Autorización Electrónica)
Se obtiene la fecha de vencimiento del CAE
El comprobante se guarda con estado "Autorizado"
Usuario recibe confirmación exitosa

Si ARCA rechaza el código:

Se registra el error devuelto por AFIP
El comprobante NO se guarda
Usuario recibe mensaje de error claro: "AFIP rechazó el comprobante: [mensaje de AFIP]"
Administrador debe revisar la configuración en formul

Fundamento de negocio:

AFIP es la entidad reguladora y tiene la última palabra sobre qué códigos son válidos
Un código puede ser numéricamente correcto pero no estar autorizado para esa empresa específica
La validación en el sistema es preventiva, pero la validación de AFIP es definitiva

Ejemplo de rechazo:

Empresa configura Factura A = código 51 (sujeta a retenciones)
Empresa NO está inscrita en régimen de retenciones ante AFIP
Al emitir factura, ARCA rechaza: "Empresa no autorizada para código 51"
Sistema muestra error, administrador debe cambiar configuración a código 1

RN-004: Alcance por Empresa (Multi-Tenant)

Descripción: Cada empresa/sucursal tiene su propia configuración de tipos de comprobante de manera independiente. Los cambios en una empresa NO afectan a otras empresas.

Condición de aplicación: En un sistema multi-tenant con aislamiento por esquema (schema).

Comportamiento esperado:

Cada empresa tiene su tabla formul en su propio esquema de base de datos
La configuración de Empresa A es completamente independiente de Empresa B
Los administradores solo ven y modifican la configuración de su propia empresa
El sistema utiliza el esquema correcto según el contexto de la sesión del usuario

Fundamento de negocio:

Cada empresa tiene diferentes obligaciones fiscales y situaciones tributarias
Una empresa puede necesitar códigos especiales (51, 52, 53) mientras otra usa códigos estándar (1, 2, 3)
Las empresas deben tener autonomía para configurar sus tipos sin interferir con otras

Ejemplo:

Empresa A (Mayorista sujeto a retenciones):
- Factura A = código 51
- Nota de Crédito A = código 53
Empresa B (Minorista sin retenciones):
- Factura A = código 1
- Nota de Crédito A = código 3
Ambas empresas facturan correctamente según su configuración sin conflictos

RN-005: Gestión de Tipos de Comprobantes (ABM)

Descripción: Los usuarios administradores pueden gestionar completamente las configuraciones de tipos de comprobante mediante el ABM dedicado. Este proceso es independiente y está documentado en detalle en el recurso correspondiente.

Referencia: Ver ABM de Tipos de Comprobante para la documentación completa de:

Creación de tipos desde catálogo ARCA
Modificación de configuraciones
Desactivación y reactivación
Reglas de validación y unicidad
Casos de uso detallados

Importante sobre Códigos y Letras:

Cada código ARCA tiene asignada una letra fiscal específica. No pueden existir dos tipos con la misma combinación de categoría + letra.

Ejemplo:

Código ARCA 1: "Factura A" → letra A (categoría: factura)
Código ARCA 51: "Factura A con retenciones" → letra ALEY (categoría: factura)

Aunque ambos se denominan "Factura A", tienen letras fiscales diferentes (A vs ALEY), por lo que pueden coexistir sin conflicto. El proceso de determinación automática selecciona el código correcto según las condiciones fiscales del emisor y receptor.

Fundamento de negocio:

Flexibilidad total: Cada empresa configura los tipos que necesite según su situación fiscal
Múltiples letras: Pueden coexistir códigos 1 (letra A) y 51 (letra ALEY) para la misma categoría
Integridad: La combinación tipo_comprobante + letra debe ser única
Autonomía: Administradores gestionan sin depender de desarrollo

RN-006: Soporte de Códigos Especiales

Descripción: El sistema debe permitir la configuración y uso de códigos especiales de AFIP (51, 52, 53 y otros) que corresponden a comprobantes con características particulares, como los sujetos a retenciones. Estos códigos tienen asignadas letras fiscales específicas (generalmente ALEY).

Condición de aplicación: Cuando una empresa tiene obligaciones fiscales especiales que requieren el uso de códigos no estándar.

Códigos especiales más comunes:

Código 51: Factura con leyenda especial (letra ALEY) - sujeta a retención de ganancias o IVA
Código 52: Nota de Débito con leyenda especial (letra ALEY) - sujeta a retención
Código 53: Nota de Crédito con leyenda especial (letra ALEY) - sujeta a retención

Importante: Estos códigos tienen letra fiscal ALEY, NO letra A. Pueden coexistir con códigos estándar:

Código 1 (letra A): "Factura A"
Código 51 (letra ALEY): "Factura A con retenciones"

Flujo de uso:

Administrador identifica que la empresa debe usar códigos especiales para ciertos casos (según normativa AFIP y asesor contable)
Administrador gestiona la configuración mediante el ABM de Tipos de Comprobante
Crea nueva configuración con código ARCA 51 (letra ALEY) para "Factura A sujeta a retención"
Ahora la empresa tiene DOS opciones disponibles:
- Código 1 (letra A): Factura A estándar
- Código 51 (letra ALEY): Factura A sujeta a retención
Al facturar, si ambas letras son válidas según AFIP, el usuario ve selector y elige según corresponda
Si elige opción código 51, ARCA valida y autoriza comprobante con ese código

Fundamento de negocio:

Cumplimiento regulatorio: Empresas agentes de retención DEBEN usar códigos especiales según normativa AFIP
Diferenciación fiscal: Los códigos especiales identifican comprobantes con tratamiento fiscal especial
Trazabilidad: AFIP puede distinguir y fiscalizar comprobantes sujetos a regímenes especiales
Flexibilidad: El sistema se adapta a la situación fiscal particular de cada empresa

Ejemplo de uso real:

Empresa mayorista es agente de retención de ganancias
Cuando factura a ciertos clientes, debe emitir comprobante sujeto a retención
Administrador configura en el ABM: código ARCA 51 (letra ALEY, categoría factura)
Usuario de ventas factura normalmente (sin cambios en su proceso)
Sistema determina automáticamente que debe usar letra ALEY según condiciones fiscales
Sistema selecciona código 51 de formul (única configuración de factura + ALEY)
Sistema envía a ARCA con código 51
ARCA reconoce el código 51 y autoriza correctamente
El PDF generado incluye leyenda "Comprobante sujeto a retención" según template configurado

RN-007: Determinación Automática de Letra/Clase mediante Validación AFIP

Descripción: El sistema debe determinar qué letras/clases de comprobante son válidas para un cliente específico consultando a AFIP y cruzando esa información con las configuraciones disponibles en formul. Si hay una sola opción válida, se selecciona automáticamente. Si hay múltiples opciones válidas, el usuario elige entre ellas.

Condición de aplicación: Cada vez que un usuario inicia la creación de un comprobante electrónico después de seleccionar el cliente.

Lógica de Determinación por Consulta e Intersección:

El sistema NO utiliza una matriz fija de cálculo. En su lugar, realiza un proceso dinámico de validación:

Consulta a AFIP: El sistema consulta a AFIP qué letras de comprobante son válidas para la condición de IVA del cliente seleccionado
- Endpoint: GetCondicionIvaReceptor($claseComprobante) de AFIP API
- Retorna: Lista de letras permitidas por AFIP para ese tipo de cliente (ej: [A, ALEY] para Responsable Inscripto)
Consulta a formul: El sistema consulta qué configuraciones están disponibles en formul para el tipo de comprobante seleccionado
- Query: WHERE tipo_comprobante=X AND activo=true
- Retorna: Lista de letras configuradas localmente (ej: [A, ALEY, B] disponibles en la empresa)
Intersección: El sistema calcula la intersección entre letras válidas de AFIP y letras configuradas en formul
- Fórmula: opciones_válidas = letras_AFIP ∩ letras_formul
- Resultado: Solo las letras que están TANTO en AFIP COMO en formul
Presentación al usuario:
- Si intersección = 0: Error "No hay configuración válida para este tipo de cliente"
- Si intersección = 1: Selección automática de esa única letra (transparente para el usuario)
- Si intersección > 1: Mostrar selector para que usuario elija entre opciones válidas

Ejemplo de intersección:

Caso	Letras AFIP	Letras formul	Intersección	Resultado
1	[A, ALEY]	[A, B, C]	[A]	Auto-selecciona A
2	[A, ALEY]	[A, ALEY, B]	[A, ALEY]	Usuario elige entre A o ALEY
3	[B]	[A, B, C]	[B]	Auto-selecciona B
4	[A]	[B, C]	[]	Error: sin configuración válida

Clases Especiales:

ALEY: Comprobantes A con leyenda por ley especial (ej: Ley 27.541 - Solidaridad Social)
- AFIP puede retornar ALEY como válida para ciertos tipos de cliente (Responsables Inscriptos)
- Si formul tiene configurada letra ALEY, aparecerá como opción junto con A
- Usuario elige según normativa aplicable a su caso
- Requiere que el administrador haya configurado previamente la clase ALEY en formul
49: Factura de Crédito Electrónico MiPyME para Bienes Usados
- AFIP puede retornar 49 como válida para operaciones especiales de bienes usados
- Solo aparece como opción si está configurada en formul
- Usuario selecciona cuando aplica este caso especial
- Requiere configuración previa por el administrador

Flujo de Determinación Completo:

Usuario selecciona tipo de comprobante (factura, nota-crédito, nota-débito)
Usuario selecciona cliente/receptor
Sistema obtiene condición IVA del cliente (de los datos del cliente)
Sistema consulta a AFIP: GetCondicionIvaReceptor() → obtiene letras válidas según AFIP para esa condición IVA
Sistema consulta formul: WHERE tipo_comprobante=X AND activo=true → obtiene letras configuradas en la empresa
Sistema calcula intersección: letras_válidas = letras_AFIP ∩ letras_formul
Sistema evalúa el resultado de la intersección:
- Si 0 coincidencias: Muestra error "No hay configuración válida para este tipo de cliente. Contacte al administrador."
- Si 1 coincidencia: Selecciona automáticamente esa letra (paso transparente, usuario no interviene)
- Si múltiples coincidencias: Muestra selector con las opciones válidas
Si usuario debe elegir (múltiples opciones), sistema presenta selector: "Seleccione tipo de comprobante: [A] [ALEY]"
Usuario selecciona la letra deseada (ej: ALEY en lugar de A)
Sistema consulta formul con la letra seleccionada: WHERE tipo_comprobante=X AND tipo=Y AND activo=true
Si 1 resultado: usa ese código ARCA automáticamente
Si múltiples resultados: muestra selector con las variantes disponibles (ej: código 1 vs código 51)
Si 0 resultados: error interno (no debería ocurrir, ya que la letra vino de formul)

Registro en Auditoría:

Sistema registra qué letras retornó AFIP para el cliente
Sistema registra qué letras estaban disponibles en formul
Sistema registra la intersección calculada
Si usuario eligió entre múltiples opciones, se registra la opción seleccionada
Información queda disponible para auditoría y troubleshooting

Fundamento de negocio:

Reducción de errores: La validación automática contra AFIP elimina errores humanos en la selección de tipo de comprobante
Cumplimiento normativo: Garantiza que solo se presenten opciones válidas según normativa AFIP para cada tipo de cliente
Flexibilidad: Permite múltiples configuraciones (A y ALEY) cuando ambas son válidas, dejando al usuario elegir según su caso
Trazabilidad: El registro de consultas y selecciones permite auditar el proceso de facturación

Ejemplo 1 (selección automática - una sola opción válida):

Empresa factura a cliente Responsable Inscripto
formul tiene configurado: Factura A, Factura B
AFIP retorna válidas para ese cliente: A
Intersección: [A]
Sistema auto-selecciona letra A (transparente para el usuario)
Usuario continúa con el proceso sin intervención

Ejemplo 2 (usuario elige entre múltiples opciones válidas):

Empresa factura a cliente Responsable Inscripto
formul tiene configurado: Factura A, Factura ALEY, Factura B
AFIP retorna válidas para ese cliente: A, ALEY
Intersección: [A, ALEY]
Sistema muestra selector: "Seleccione tipo: [A] [ALEY]"
Usuario elige ALEY porque aplica Ley 27.541
Sistema registra selección en auditoría
Sistema consulta formul para Factura ALEY y procede

Ejemplo 3 (error - sin configuración válida):

Empresa factura a cliente Consumidor Final
formul tiene configurado: Factura A solamente
AFIP retorna válidas para ese cliente: B
Intersección: [] (vacía)
Sistema muestra error: "No hay configuración válida para este tipo de cliente. Debe configurar Factura B en formul."
Usuario contacta al administrador para que configure Factura B

Casos de Uso

CU-001: Empresa Configura Código Especial para Retenciones

Código: CU-001 Nombre: Configurar código especial para comprobantes sujetos a retenciones Actor Principal: Administrador del Sistema Otros Actores: Sistema de configuración, AFIP (indirectamente)

Precondiciones:

Usuario tiene permiso VENTAS_CONFIG_FORMUL_WRITE
Empresa requiere usar Factura A código 51 según normativa AFIP (es agente de retención)
Existe registro en formul para Factura A (actualmente con código 1)

Flujo Principal:

Administrador accede al módulo de configuración del sistema
Administrador selecciona opción "Configuración de Tipos de Comprobante"
Sistema muestra listado de tipos configurados actualmente:
- Factura A - Código 1
- Factura B - Código 6
- Factura C - Código 11
- Nota de Crédito A - Código 3
- (etc.)
Administrador identifica la fila "Factura A - Código 1"
Administrador hace clic en botón "Editar"
Sistema muestra formulario de edición con campos:
- Código ARCA: [1]
- Nombre: [FACTURA]
- Tipo/Letra: [A] (no editable)
- Descripción: [FACTURA A]
- Template Reporte: [FA1]
Administrador modifica campo "Código ARCA" de 1 a 51
Administrador modifica campo "Descripción" de "FACTURA A" a "FACTURA A SUJETA A RETENCIÓN"
Administrador modifica campo "Template Reporte" de "FA1" a "FA51"
Administrador hace clic en botón "Guardar"
Sistema valida que código 51 es numérico y válido según normativa AFIP
Sistema valida que no existe otro tipo con código 51 para esta empresa
Sistema guarda los cambios en la tabla formul
Sistema registra auditoría: campo modificado, valor anterior, valor nuevo, usuario, fecha/hora
Sistema cierra formulario de edición
Sistema actualiza listado mostrando:
- Factura A - Código 51 (resaltado como modificado recientemente)
Sistema muestra mensaje de confirmación: "Configuración actualizada correctamente. A partir de ahora, las Facturas A se emitirán con código 51."

Postcondiciones:

Registro en formul actualizado: Factura A tiene código 51
Todas las Facturas A que se emitan de ahora en adelante usarán código 51 automáticamente
Facturas A emitidas anteriormente (con código 1) permanecen sin cambios
Cambio queda registrado en auditoría del sistema
Administrador recibe confirmación visual del cambio

Flujos Alternativos:

FA-001: Código inválido

En paso 11, si el código ingresado no es válido (ej: código 999 que no existe en normativa):
- Sistema muestra error: "El código 999 no es válido según normativa AFIP"
- Formulario permanece abierto para corrección
- Administrador puede corregir o cancelar

FA-002: Código duplicado

En paso 12, si ya existe otro tipo con ese código (ej: se intenta poner código 6 que ya tiene Factura B):
- Sistema muestra error: "Ya existe un tipo de comprobante configurado con código 6 (Factura B)"
- Formulario permanece abierto para corrección

FA-003: Cancelación

En cualquier momento antes del paso 10:
- Administrador hace clic en "Cancelar"
- Sistema descarta cambios sin guardar
- Sistema cierra formulario
- Configuración permanece sin cambios

Requisitos Especiales:

La validación de código AFIP debe ser rápida (menos de 2 segundos)
El mensaje de confirmación debe ser claro sobre el efecto del cambio (afecta solo facturas futuras)
El cambio debe ser transaccional (todo o nada)

CU-002: Usuario Crea Factura con Código Configurado

Código: CU-002 Nombre: Crear factura electrónica usando código configurado dinámicamente Actor Principal: Usuario de Ventas Otros Actores: Sistema de facturación, ARCA (AFIP), Cliente

Precondiciones:

Usuario tiene permiso VENTAS_FACTURACION_CREATE
Formul está configurado con Factura A = código 51 (según CU-001)
Existe cliente cargado en el sistema
Hay productos/servicios disponibles para facturar

Flujo Principal:

Usuario accede al módulo de Ventas
Usuario selecciona opción "Crear Factura Electrónica"
Sistema muestra formulario de nueva factura
Usuario selecciona tipo de comprobante: "Factura"
Usuario selecciona cliente (ej: "Distribuidora San Juan S.A." - CUIT 30-12345678-9, Responsable Inscripto)

5A. Sistema consulta letras válidas a AFIP:

Sistema obtiene condición IVA del cliente receptor (del registro del cliente: Responsable Inscripto)
Sistema consulta a AFIP: GetCondicionIvaReceptor() para esa condición IVA
AFIP retorna: Letras válidas para ese cliente = [A, ALEY]
Sistema registra en log: "AFIP retornó letras válidas: A, ALEY para cliente CUIT 30-12345678-9"

5B. Sistema consulta configuraciones disponibles en formul:

Sistema consulta formul: WHERE tipo_comprobante='factura' AND activo=true
formul retorna: Letras configuradas = [A, B]
Sistema registra en log: "formul tiene configurado: A, B"

5C. Sistema calcula intersección y presenta opciones:

Sistema calcula: letras_válidas = letras_AFIP ∩ letras_formul
Intersección: [A, ALEY] ∩ [A, B] = [A]
Sistema evalúa resultado:
- Solo 1 coincidencia (A): Sistema auto-selecciona letra A (transparente para el usuario, continúa en paso 6)
- Múltiples coincidencias: Mostraría selector "Seleccione: [opciones]" (ver FA-006)
- 0 coincidencias: Error "No hay configuración válida" (ver FA-007)

Sistema carga datos fiscales del cliente (condición IVA, domicilio fiscal, etc.)
Usuario agrega ítems al comprobante:
- Producto A: cantidad 10, precio unitario $1000
- Producto B: cantidad 5, precio unitario $500
Sistema calcula subtotales, IVA, e importe total automáticamente
Usuario verifica datos y hace clic en "Emitir Factura Electrónica"
Sistema confirma: "¿Confirma la emisión de la factura?"
Usuario confirma
Sistema prepara datos para ARCA con código obtenido en paso 5C (ej: código 51):
- Tipo de comprobante: 51
- Punto de venta: 0001
- Número: 00000123 (próximo número disponible)
- Cliente: CUIT 30-12345678-9
- Importe: $12,500
- IVA: $2,625
- Total: $15,125
Sistema envía solicitud de autorización a servicio web de ARCA
ARCA valida que código 51 es válido para esta empresa y comprobante
ARCA autoriza y devuelve:
- CAE: 68123456789012
- Fecha vencimiento CAE: 2026-01-16
Sistema guarda factura en base de datos:
- id_tipo_comprobante = 51 (código usado)
- nrocomp = 123
- nrocae = 68123456789012
- fevtocae = 2026-01-16
- Estado: AUTORIZADA
Sistema genera PDF de la factura usando template "FA51" (configurado en formul)
Sistema actualiza numerador en formul (próximo número será 124)
Sistema muestra confirmación a usuario:
- "Factura A N° 0001-00000123 emitida correctamente"
- CAE: 68123456789012
- Vencimiento: 16/01/2026
Sistema ofrece opciones:
- Imprimir / Descargar PDF
- Enviar por email al cliente
- Ver comprobante
- Crear nuevo comprobante

Postcondiciones:

Factura creada y autorizada por AFIP con código 51
CAE obtenido y almacenado
Comprobante fiscalmente válido
PDF generado con template correcto (incluye leyenda de retención)
Numerador incrementado
Usuario recibe confirmación y acceso al comprobante
Letra del comprobante fue determinada automáticamente mediante consulta a AFIP e intersección con formul
Registro en auditoría incluye: letras retornadas por AFIP, letras disponibles en formul, intersección calculada, letra seleccionada (automática o manual si hubo múltiples opciones)

Flujos Alternativos:

FA-001: Tipo no configurado

En paso 13-14, si NO existe configuración en formul para Factura A:
- Sistema muestra error: "El tipo de comprobante Factura A no está configurado para esta empresa. Contacte al administrador del sistema."
- Factura no se crea
- Usuario puede cancelar o intentar con otro tipo

FA-002: Rechazo de ARCA

En paso 17-18, si ARCA rechaza el comprobante (ej: empresa no autorizada para código 51):
- Sistema recibe mensaje de error de AFIP
- Sistema muestra error al usuario: "AFIP rechazó el comprobante: [mensaje de AFIP]. Contacte al administrador."
- Factura NO se guarda en base de datos
- Usuario puede:
  - Intentar nuevamente (si fue error transitorio)
  - Cancelar operación
  - Contactar soporte/administrador

FA-003: Error de conexión con ARCA

En paso 16, si hay error de conexión con servicio de AFIP:
- Sistema muestra error: "No se pudo conectar con el servicio de AFIP. Intente nuevamente en unos momentos."
- Factura NO se guarda
- Usuario puede reintentar o usar modo de contingencia (si está habilitado)

FA-004: Cancelación

En cualquier momento antes del paso 11:
- Usuario hace clic en "Cancelar"
- Sistema descarta datos ingresados (con confirmación)
- No se crea factura ni se consulta ARCA

FA-006: Múltiples opciones válidas - Usuario debe elegir (desde paso 5C)

En paso 5C, si la intersección retorna múltiples letras:
- Ejemplo: AFIP retorna [A, ALEY], formul tiene [A, ALEY], intersección = [A, ALEY]
- Sistema muestra selector: "Seleccione tipo de factura para este cliente:"
  - [ ] Factura A
  - [ ] Factura A con Ley 27.541 (ALEY)
- Usuario selecciona la opción aplicable a su caso (ej: ALEY porque la ley aplica)
- Sistema registra en auditoría: letras válidas disponibles, letra seleccionada por usuario
- Sistema continúa con paso 6 usando la letra seleccionada
- Si letra seleccionada tiene múltiples códigos en formul, muestra selector de variantes

FA-007: Sin opciones válidas - Error de configuración (desde paso 5C)

En paso 5C, si la intersección está vacía:
- Ejemplo: AFIP retorna [B], formul tiene [A, C], intersección = []
- Sistema muestra error: "No hay configuración válida para este tipo de cliente (Consumidor Final). El sistema requiere Factura B pero solo está configurado Factura A y C. Contacte al administrador para configurar Factura B."
- Sistema registra en log: letras AFIP, letras formul, intersección vacía
- Factura no se crea
- Usuario puede:
  - Contactar al administrador para que configure el tipo faltante
  - Cancelar el proceso
  - Seleccionar otro cliente

Requisitos Especiales:

La consulta a AFIP (paso 5A) debe ejecutarse en menos de 500ms
La consulta a formul (paso 5B) debe ser instantánea (menos de 50ms)
El cálculo de intersección (paso 5C) debe ser instantáneo (menos de 10ms)
El usuario NO debe ver ni necesitar saber qué código ARCA se está usando internamente
La experiencia de usuario debe ser fluida, con selección automática cuando hay una sola opción
El PDF generado debe corresponder al template configurado (FA51 incluye leyenda de retenciones)
Si hay múltiples opciones válidas, el selector debe presentar descripciones claras de cada una

Nota Importante: Este caso de uso demuestra la validación dinámica con AFIP de la solución: el sistema consulta a AFIP qué tipos son válidos para cada cliente, cruza con las configuraciones locales, y presenta solo opciones fiscalmente correctas. La flexibilidad está tanto en la determinación dinámica como en la configuración administrativa (CU-001).

CU-003: Sistema Usa Formul en Lugar de Constante

Código: CU-003 Nombre: Determinación dinámica de código ARCA desde configuración Actor Principal: Sistema Otros Actores: Tabla formul (configuración)

Precondiciones:

Proceso de facturación en ejecución
Tipo de comprobante seleccionado por el usuario
Letra de comprobante calculada automáticamente por el sistema
Empresa tiene configuración en formul

Flujo Principal:

Sistema recibe solicitud de creación de comprobante con parámetros:
- Tipo de comprobante: factura
- Cliente con condición IVA definida
- Datos del cliente
- Ítems y montos
Sistema calcula letra del comprobante según condiciones IVA:
- Emisor (empresa): Responsable Inscripto
- Receptor (cliente): Responsable Inscripto
- Letra calculada: A (RI + RI = A)
Sistema identifica que necesita determinar el código ARCA a usar
Sistema construye consulta a tabla formul:
- Condición: tipo_comprobante = 'factura'
- Condición: letra = 'A' (calculada en paso 2)
- Filtro: esquema/empresa actual (multi-tenant)
- Filtro: activo = true
Sistema ejecuta consulta en base de datos
Sistema obtiene resultado: código = 51
Sistema valida que el código obtenido es numérico y mayor a 0
Sistema asigna el código 51 al comprobante en proceso
Sistema continúa el flujo normal de facturación con código 51:
- Calcula importes
- Obtiene numeración
- Prepara solicitud para ARCA con código 51
- Envía a ARCA
- Recibe CAE
- Guarda comprobante con id_tipo_comprobante = 51
Sistema completa el proceso de facturación exitosamente

Postcondiciones:

Código ARCA usado proviene de formul, NO de constante hardcodeada
El comprobante se procesa con el código configurado por la empresa
Proceso de negocio independiente del código específico usado

Flujos Alternativos:

FA-001: No existe configuración

En paso 4-5, si la consulta NO retorna resultados:
- Sistema lanza excepción de negocio: "TipoComprobanteNoConfigurado"
- Sistema retorna error al usuario: "Tipo de comprobante no configurado"
- Proceso de facturación se detiene
- No se envía nada a ARCA

FA-002: Configuración inválida

En paso 6, si el código obtenido no es válido (NULL, negativo, no numérico):
- Sistema lanza excepción: "ConfiguracionInvalida"
- Sistema registra error en log para revisión del administrador
- Sistema retorna error genérico al usuario
- Proceso se detiene

FA-003: Múltiples resultados (selector de variantes)

En paso 5-6, si la consulta retorna más de un resultado (ej: código 1 y código 51 para Factura A):
- Sistema muestra selector al usuario: "¿Qué tipo de Factura A desea emitir?"
- Opciones: "Factura A estándar" y "Factura A sujeta a retención"
- Usuario DEBE seleccionar una opción
- Sistema continúa con el código de la opción seleccionada
- Este es el comportamiento esperado cuando hay múltiples configuraciones del mismo tipo y letra

Requisitos Especiales:

La consulta a formul debe ser eficiente (< 50ms), considerando índice en (nombre, tipo)
El proceso debe ser atómico: si falla la consulta, no se procesa el comprobante
El código obtenido debe usarse en TODAS las partes del flujo (ARCA, base de datos, PDF)
El sistema NO debe tener fallback a constantes hardcodeadas (evitar comportamiento inconsistente)

Comparación con Comportamiento Anterior:

ANTES (Hardcodeado):

Usuario selecciona "Factura"
Usuario selecciona cliente RI
  ↓
Sistema determina: debe ser Factura A
Sistema busca en TipoComprobante.php: FACTURA_A = 1
  ↓
Sistema usa código 1 (siempre)
  ↓
Registra con código 1

AHORA (Dinámico):

Usuario selecciona "Factura"
Usuario selecciona cliente RI
  ↓
Sistema calcula letra automáticamente: A (RI + RI)
Sistema consulta formul: WHERE tipo_comprobante='factura' AND letra='A'
  ↓
Sistema obtiene código(s) configurado(s):
  - Si 1 resultado: usa ese código
  - Si múltiples: muestra selector al usuario
  ↓
Sistema usa código elegido/obtenido
  ↓
Registra con código configurado

Beneficio de negocio: Este caso de uso representa el corazón del cambio técnico que habilita toda la flexibilidad de negocio: el sistema deja de depender de valores fijos y pasa a consultar configuración. Esto permite que cada empresa use los códigos que necesita sin cambios en el código del sistema.

CU-004: Cambio de Configuración No Afecta Facturas Históricas

Código: CU-004 Nombre: Preservación de integridad histórica ante cambios de configuración Actor Principal: Administrador del Sistema Otros Actores: Sistema de configuración, Sistema de facturación, Comprobantes históricos

Precondiciones:

Existen facturas A emitidas anteriormente con código 1
Usuario tiene permiso de modificación de configuración
Sistema tiene auditoría habilitada

Flujo Principal:

FASE 1: Estado Inicial (Lunes)

Empresa tiene en formul: Factura A = código 1
Durante la semana, usuarios emiten facturas:
- Factura 001: Factura A, código 1, CAE 68111111111111, fecha 2026-01-02
- Factura 002: Factura A, código 1, CAE 68111111111112, fecha 2026-01-03
- Factura 003: Factura A, código 1, CAE 68111111111113, fecha 2026-01-04
- (Total: 10 facturas A con código 1)
Todas las facturas están en base de datos con id_tipo_comprobante = 1
Todas tienen sus respectivos CAE y están fiscalmente válidas

FASE 2: Cambio de Configuración (Viernes)

Administrador accede a configuración de formul
Administrador modifica Factura A: cambia código de 1 a 51
Razón del cambio: Empresa ahora es agente de retención y debe usar código 51
Sistema guarda cambio en formul
Sistema registra en auditoría:
- Tabla: formul
- Registro: Factura A
- Campo: codigo
- Valor anterior: 1
- Valor nuevo: 51
- Usuario: admin@empresa.com
- Fecha/hora: 2026-01-05 14:30:00

FASE 3: Emisión Posterior (Lunes siguiente)

Usuarios continúan emitiendo facturas:
- Factura 011: Factura A, código 51, CAE 68222222222221, fecha 2026-01-08
- Factura 012: Factura A, código 51, CAE 68222222222222, fecha 2026-01-09
- (etc.)
Las nuevas facturas se guardan con id_tipo_comprobante = 51
ARCA las autoriza correctamente con código 51

FASE 4: Verificación de Integridad Histórica

Administrador consulta facturas históricas (001-010)
Sistema muestra que facturas 001-010 tienen:
- id_tipo_comprobante = 1 (SIN CAMBIOS)
- CAE original (SIN CAMBIOS)
- Fecha de emisión original
- Importes originales
Los reportes históricos de esas facturas siguen mostrando código 1
Las facturas siguen siendo fiscalmente válidas con código 1
Administrador consulta nuevas facturas (011 en adelante)
Sistema muestra que facturas 011+ tienen:
- id_tipo_comprobante = 51 (CÓDIGO NUEVO)
- CAE correspondiente a código 51
Los reportes de estas facturas muestran código 51 y leyenda de retenciones

Postcondiciones:

Facturas emitidas ANTES del cambio mantienen código 1 y su integridad fiscal
Facturas emitidas DESPUÉS del cambio usan código 51 correctamente
NO hay actualización retroactiva de datos históricos
Integridad referencial preservada
Auditoría completa del cambio de configuración disponible
Ambos grupos de facturas son fiscalmente válidos con sus respectivos códigos

Flujos Alternativos:

FA-001: Intento de modificación retroactiva (NO debe permitirse)

Si alguien intenta cambiar el código de facturas históricas:
- Sistema rechaza operación: "No se pueden modificar comprobantes autorizados"
- Facturas históricas permanecen inmutables

FA-002: Reversión de configuración

Si administrador revierte configuración (código 51 → 1 nuevamente):
- Facturas 001-010: siguen con código 1 (sin cambios)
- Facturas 011-020: siguen con código 51 (sin cambios)
- Facturas 021+: usarán código 1 nuevamente
- Comportamiento consistente: cada factura conserva el código con el que fue emitida

FA-003: Consulta de auditoría

Administrador consulta historial de cambios:
- Sistema muestra timeline:
  - 2026-01-01: Factura A = código 1 (configuración inicial)
  - 2026-01-05 14:30: Cambio a código 51 por usuario admin@empresa.com
  - 2026-01-10 09:15: Cambio a código 1 por usuario admin@empresa.com (si revirtió)
- Permite correlacionar qué facturas se emitieron bajo qué configuración

Requisitos Especiales:

Los comprobantes históricos deben ser inmutables (NO se actualiza su código)
Los reportes deben mostrar el código con el que fue emitido cada comprobante
La auditoría debe permitir rastrear qué configuración estaba vigente en cada fecha
El sistema debe soportar convivencia de comprobantes con diferentes códigos

Análisis de Impacto:

Aspecto	Facturas Históricas (001-010)	Facturas Nuevas (011+)
Código ARCA	1 (sin cambios)	51 (nuevo)
CAE	Original (válido con código 1)	Nuevo (válido con código 51)
PDF generado	Template FA1 (usado en emisión)	Template FA51 (según config)
Validez fiscal	Válido ✅	Válido ✅
Registro en base	id_tipo_comprobante=1	id_tipo_comprobante=51
Auditoría	Indica emisión con código 1	Indica emisión con código 51

Beneficio de negocio: Este caso de uso asegura que el sistema tiene memoria histórica correcta. Las empresas pueden cambiar su configuración según evoluciona su situación fiscal, sin comprometer la validez de comprobantes ya emitidos. Esto es crítico para auditorías fiscales, donde cada comprobante debe mantener los datos con los que fue autorizado originalmente por AFIP.

CU-005: Configurar Tipos de Comprobante con Nuevas Clases

Código: CU-005 Nombre: Configurar tipos de comprobante con clases extendidas (ALEY, 49) Actor Principal: Administrador del Sistema

Descripción:

Este caso de uso cubre la gestión de tipos de comprobante con letras especiales como ALEY y 49. El proceso completo de ABM (Alta, Baja, Modificación) está documentado en detalle en el recurso dedicado.

Referencia: Ver ABM de Tipos de Comprobante para:

Flujo completo de creación desde catálogo ARCA
Validaciones de unicidad (tipo_comprobante + letra)
Configuración de campos (código, letra, abreviatura, categoría)
Casos de uso detallados con flujos principales y alternativos
Reglas de negocio específicas del ABM

Resumen del flujo:

Administrador accede al ABM de Tipos de Comprobante
Crea nueva configuración con letra especial (ej: ALEY, código 201)
Sistema valida unicidad y reglas de negocio
Nueva configuración queda disponible para facturación
Cuando AFIP retorne esa letra como válida para un cliente, aparecerá como opción en el selector

Flujo Alternativo FA-003: Configurar clase 49 (Bienes Usados)

Administrador sigue mismo flujo pero selecciona:
- Tipo de comprobante: "factura"
- Letra/Clase: "49"
- Código ARCA: 49 (código específico para MiPyME Bienes Usados)
- Descripción: "Factura de Crédito Electrónico MiPyME - Bienes Usados"
- Template: "F49"
Sistema valida y guarda de la misma manera
Administrador ahora puede emitir facturas para operaciones de bienes usados

Requisitos Especiales:

El campo letra/clase debe aceptar valores de hasta 5 caracteres (para soportar ALEY, etc.)
Debe existir documentación de ayuda para el administrador explicando cuándo usar cada clase especial
El sistema debe advertir claramente que las clases especiales (ALEY, 49) requieren selección manual del usuario al facturar
La validación de código ARCA debe ser flexible para permitir códigos futuros de AFIP

Nota Importante: Las clases especiales como ALEY y 49 aparecen como opciones solo cuando:

AFIP las retorna como válidas para la condición IVA del cliente seleccionado
Están configuradas en formul para la empresa

Si ambas condiciones se cumplen y hay múltiples opciones (ej: A y ALEY), el sistema presenta un selector para que el usuario elija la más apropiada. Esto es intencional, ya que estas clases corresponden a situaciones fiscales especiales que el usuario debe conocer y decidir explícitamente según su caso particular.

Consideraciones

Seguridad

Control de Acceso:

Solo usuarios con rol de Administrador del Sistema pueden modificar la configuración de formul
Los usuarios operativos de ventas NO pueden ver ni modificar formul
El permiso VENTAS_CONFIG_FORMUL_WRITE debe ser restrictivo y otorgarse solo a personal de confianza
Las consultas a formul durante facturación son de solo lectura (no representan riesgo de seguridad)

Validación de Entrada:

Todo código ARCA ingresado debe validarse como numérico positivo
La validación debe ser en frontend (experiencia de usuario) y backend (seguridad)
No permitir inyección de valores SQL en campos de configuración
Limitar longitud de campos de texto (descripción, reporte) para prevenir ataques

Auditoría de Configuración:

Registrar TODOS los cambios en formul:
- ¿Quién? (usuario que realizó el cambio)
- ¿Cuándo? (fecha y hora exacta)
- ¿Qué? (campo modificado)
- ¿Cómo? (valor anterior → valor nuevo)
Los registros de auditoría deben ser inmutables (no editables ni eliminables)
Retención de auditoría: mínimo 10 años (requisito fiscal)

Prevención de Errores Críticos:

Implementar confirmación explícita antes de guardar cambios críticos
Mensaje de advertencia: "Este cambio afectará todas las facturas emitidas a partir de ahora. ¿Está seguro?"
Validar con AFIP antes de guardar (si es posible) para prevenir configuraciones inválidas

Separación de Ambientes:

La configuración de formul en ambiente de prueba debe ser independiente de producción
Los cambios en prueba NO deben afectar producción
Documentar claramente en qué ambiente se está trabajando

Auditoría

Registro de Cambios en Formul:

Cada modificación debe generar un registro de auditoría con:

Campo	Descripción	Ejemplo
ID de auditoría	Identificador único	12345
Fecha/hora	Timestamp del cambio	2026-01-05 14:30:15
Usuario	Quién realizó el cambio	admin@empresa.com
Tabla	Tabla modificada	formul
Registro ID	Identificador del registro	Factura A (nombre='FACTURA', tipo='A')
Campo modificado	Qué campo cambió	codigo
Valor anterior	Valor antes del cambio	1
Valor nuevo	Valor después del cambio	51
IP del usuario	Desde dónde se hizo	192.168.1.100
Razón del cambio	Nota del admin (opcional)	"Empresa ahora agente de retención"

Rastreabilidad de Comprobantes:

Cada factura/nota emitida debe poder rastrearse hasta la configuración que estaba vigente:

Al consultar Factura 123:
- Se muestra: id_tipo_comprobante = 51
- Se puede consultar: "¿Qué configuración estaba vigente el 08/01/2026?"
- Respuesta: Factura A tenía código 51 (cambiado el 05/01/2026 por admin@empresa.com)

Análisis y Reportes de Auditoría:

Deben poder responderse preguntas como:

¿Cuántas facturas se emitieron con código 51 en enero?
¿Cuándo se cambió la configuración de Factura A?
¿Quién autorizó el cambio a código 51?
¿Qué comprobantes fueron emitidos bajo cada configuración?

Retención de Información:

Registros de auditoría: mínimo 10 años (obligación fiscal)
Comprobantes emitidos: permanente (documento fiscal oficial)
Configuración histórica: necesaria para reconstruir contexto de cada comprobante

Rendimiento

Impacto de la Consulta a Formul:

Por cada factura:

1 consulta SELECT a tabla formul
Tiempo esperado: < 50 ms
Overhead agregado: mínimo

Optimizaciones:

Índices de base de datos:

Crear índice en formul sobre (nombre, tipo) para búsquedas rápidas
Índice debe ser único por empresa (multi-tenant)
Mejora: consulta de 200ms → 10ms

Caché en memoria (opcional para alto volumen):

Si la empresa emite > 1000 facturas/día, considerar caché
Al inicio de cada sesión, cargar configuración de formul en memoria
TTL del caché: 5 minutos (para reflejar cambios administrativos)
Invalidación: al guardar cambios en formul, limpiar caché

Sin caché (recomendado inicial):

Consulta en tiempo real por cada factura
Garantiza siempre datos actualizados (RN-002: efecto inmediato)
Suficiente para volúmenes normales (< 500 facturas/día)

Benchmark Esperado:

Operación	Sin optimización	Con índice	Con caché
Consulta formul	200 ms	10 ms	< 1 ms
Impacto en facturación	+5% tiempo	+0.5% tiempo	+0.1% tiempo
Complejidad	Baja	Baja	Media

Recomendación: Comenzar con índice de base de datos. Evaluar caché solo si el volumen de facturación lo justifica.

Monitoreo:

Registrar tiempo de consulta a formul en logs de performance
Alertar si consultas superan 100ms (indica necesidad de optimización)

Migración

Estado de Datos Existentes:

El sistema ya tiene la tabla formul con datos sembrados por migraciones. Los comprobantes históricos tienen códigos hardcodeados en id_tipo_comprobante.

Estrategia de Migración:

Fase 1: Coexistencia (transición)

El sistema nuevo consulta formul para nuevos comprobantes
Los comprobantes históricos mantienen sus códigos originales
NO se modifican datos históricos

Fase 2: Ajuste de configuración inicial

Cada empresa debe revisar su configuración en formul
Por defecto, formul tiene códigos estándar (1, 6, 11, etc.)
Empresas que necesiten códigos especiales deben configurarlos

Fase 3: Validación

Emitir comprobantes de prueba en ambiente de test
Verificar que ARCA acepta los códigos configurados
Confirmar que PDFs se generan con templates correctos

NO se requiere:

❌ Actualizar comprobantes históricos (mantienen código original)
❌ Migrar datos de constantes a formul (formul ya existe)
❌ Cambiar estructura de tablas (son compatibles)

Rollback:

Si es necesario volver al sistema anterior (hardcodeado):
- El código anterior puede usarse como fallback
- Los datos en formul NO se pierden
- Posible estrategia: feature flag para activar/desactivar modo dinámico

Compatibilidad con AFIP

Validación por ARCA:

AFIP (a través de ARCA) es la autoridad final de validación de códigos. El sistema puede validar sintácticamente (código numérico, positivo), pero AFIP valida semánticamente (¿este código es válido para esta empresa en este contexto?).

Escenarios de Validación:

Código sintácticamente válido pero semánticamente inválido:

Empresa configura código 51 (Factura A sujeta a retención)
Empresa NO está inscrita como agente de retención ante AFIP
Al enviar a ARCA: rechazo
Mensaje de AFIP: "Empresa no autorizada para código 51"
Acción: Administrador debe cambiar configuración a código 1

Código válido para la empresa:

Empresa está inscrita como agente de retención
Empresa configura código 51
Al enviar a ARCA: autorización exitosa
CAE obtenido correctamente

Manejo de Errores de AFIP:

Cuando ARCA rechaza un código:

Sistema recibe mensaje de error específico de AFIP
Sistema registra error en logs con todos los detalles
Sistema muestra al usuario mensaje claro: "AFIP rechazó el comprobante: [mensaje de AFIP]"
Sistema sugiere: "Verifique la configuración de tipos de comprobante con el administrador"
Comprobante NO se guarda en base de datos
Usuario puede contactar al administrador para corregir configuración

Documentación de Códigos Válidos:

El sistema debe incluir documentación para administradores sobre:

Lista de códigos AFIP más comunes (1-14 estándar, 51-53 especiales, etc.)
Requisitos de cada código (qué obligaciones fiscales implican)
Cómo verificar si la empresa está autorizada para usar códigos especiales
Contacto: Asesor contable / AFIP para consultas

Actualizaciones de Normativa:

Cuando AFIP introduce nuevos códigos:

Se crea migración del sistema que agrega el nuevo código a formul
Se documenta el nuevo código y sus requisitos
Se notifica a empresas que puedan necesitarlo
Empresas configuran el nuevo código si aplica a su situación

Recomendación: Incluir en la interfaz de configuración un enlace a la documentación oficial de AFIP sobre códigos de comprobantes.

Dependencias

Recursos Relacionados

ABM de Tipos de Comprobante:

Dependencia: Este proceso consume los tipos de comprobante configurados mediante el ABM
Relación: La configuración de tipos disponibles (tabla formul) debe realizarse previamente utilizando el recurso de gestión de tipos de comprobante
Impacto: Los tipos de comprobante con sus códigos ARCA, letras y categorías configuradas son la base para la determinación automática de comprobantes
Requisito: Debe existir al menos un tipo configurado y activo por cada letra (A, B, C, ALEY) que la empresa planee utilizar

Funcionalidades Relacionadas

Facturación Electrónica (Módulo Ventas):

Dependencia: Esta funcionalidad es el núcleo del proceso de facturación
Relación: La configuración flexible afecta directamente cómo se crean las facturas
Impacto: Todos los flujos de facturación (Factura, Nota de Crédito, Nota de Débito) usan el mecanismo dinámico

Integración con ARCA WebService:

Dependencia: Servicio externo de AFIP para autorización de comprobantes
Relación: El código configurado en formul es el que se envía a ARCA
Impacto: ARCA debe aceptar los códigos configurados; si rechaza, el proceso falla
Riesgo: Configuración incorrecta puede causar rechazo masivo de comprobantes

Generación de Reportes PDF:

Dependencia: Sistema de generación de comprobantes en PDF
Relación: El campo reporte en formul define qué template usar (FA1, FA51, etc.)
Impacto: Cambiar el código implica potencialmente cambiar el template PDF
Requisito: Cada código especial debería tener su template correspondiente (ej: código 51 → template con leyenda de retenciones)

Numeración de Comprobantes:

Dependencia: Sistema de numeración correlativa por tipo
Relación: El campo nrofac en formul almacena el próximo número a usar
Impacto: Cada tipo configurado tiene su propio numerador independiente
Nota: Cambiar el código NO reinicia el numerador (se mantiene continuidad)

Módulos Externos

AFIP/ARCA WebService:

Tipo: Servicio externo gubernamental
Propósito: Autorización y validación de comprobantes electrónicos
Dependencia crítica: Sin ARCA, no se pueden emitir comprobantes electrónicos válidos
Validaciones:
- Validación del código de comprobante (¿este código existe?)
- Validación de autorización de la empresa (¿esta empresa puede usar este código?)
- Emisión de CAE (Código de Autorización Electrónica)
Manejo de errores: Fundamental manejar correctamente los mensajes de error de AFIP para informar al administrador

Sistema de Permisos:

Propósito: Control de acceso a funcionalidades
Permisos necesarios:
- VENTAS_CONFIG_FORMUL_VIEW - Ver configuración
- VENTAS_CONFIG_FORMUL_WRITE - Modificar configuración
- VENTAS_FACTURACION_CREATE - Crear comprobantes
Dependencia: Sin permisos adecuados, usuarios no pueden acceder a configuración

Sistema de Auditoría:

Propósito: Registro de todas las operaciones críticas
Registros generados:
- Cambios en formul (campo, valor anterior, valor nuevo, usuario, timestamp)
- Emisión de comprobantes (qué código se usó, bajo qué configuración)
Requisito regulatorio: Obligatorio mantener auditoría por 10 años

Sistema Multi-Tenant (Esquemas PostgreSQL):

Propósito: Aislamiento de datos por empresa
Impacto: Cada empresa tiene su tabla formul en su esquema
Dependencia: La consulta a formul debe respetar el esquema de la sesión actual
Riesgo: Error en aislamiento podría causar que Empresa A use configuración de Empresa B

Consulta de Condiciones IVA desde AFIP

Propósito: El sistema necesita obtener de AFIP las condiciones de IVA válidas para cada clase de comprobante. Esto permite validar dinámicamente qué letras son fiscalmente correctas para cada tipo de cliente y presentar solo opciones válidas al usuario.

Fuente de datos:

La API de AFIP (afip-api) expone funcionalidad para consultar condiciones de IVA válidas por clase de comprobante
Este servicio consulta directamente al servicio web de AFIP
La lógica de negocio y consumo de esta funcionalidad se documenta en la especificación de afip-api

Información obtenida: Para cada clase de comprobante (A, ALEY, B, C, 49), AFIP proporciona:

Lista de condiciones de IVA válidas para receptores
Identificador de condición (ej: 1 = Responsable Inscripto, 5 = Consumidor Final, 6 = Monotributo)
Descripción de la condición
Compatibilidad con la clase consultada

Uso en el proceso de facturación:

Al configurar formul: Validar que las letras/clases configuradas existen y son reconocidas por AFIP
Al facturar: Consultar a AFIP qué letras son válidas para la condición IVA del cliente seleccionado
Al presentar opciones: Calcular intersección entre letras válidas de AFIP y letras configuradas en formul
Antes de enviar a AFIP: Validación final de compatibilidad entre clase elegida y condiciones IVA

Casos de uso específicos:

Determinación automática (RN-007): Sistema consulta AFIP para obtener letras válidas según condición IVA del cliente
Intersección con formul: Sistema cruza letras AFIP con configuraciones activas en formul para obtener opciones válidas
Configuración de clases especiales (CU-005): Al crear configuración ALEY o 49, opcionalmente se consulta AFIP para validar reconocimiento

Importante: Esta funcionalidad permite la validación dinámica de letras. El sistema obtiene de AFIP las combinaciones emisor-receptor válidas y las cruza con las configuraciones locales para presentar solo opciones fiscalmente correctas.

Tablas del Sistema

Tabla formul (Configuración de tipos):

Propósito: Almacenar configuración de tipos de comprobante por empresa
Campos clave:
- codigo - Código ARCA dinámico
- nombre - Nombre del comprobante (FACTURA, NOTA_DE_CREDITO, etc.)
- tipo - Letra (A, B, C, X)
- reporte - Template PDF
- nrofac - Numerador
Nivel: Por empresa/sucursal (multi-tenant)

Tabla factura (Facturas emitidas):

Propósito: Almacenar facturas autorizadas
Campo relevante: id_tipo_comprobante - Almacena el código ARCA usado al emitir
Relación: Cada factura guarda el código que fue enviado a ARCA
Inmutabilidad: Una vez emitida, el código NO cambia aunque formul cambie

Tabla credito (Notas de Crédito):

Propósito: Almacenar notas de crédito autorizadas
Campo relevante: id_tipo_comprobante
Relación: Mismo comportamiento que facturas

Tabla debito (Notas de Débito):

Propósito: Almacenar notas de débito autorizadas
Campo relevante: id_tipo_comprobante
Relación: Mismo comportamiento que facturas

Constantes TipoComprobante.php (Código actual):

Propósito: Define códigos hardcodeados (código actual a deprecar/usar como fallback)
Estado: Actualmente en uso, será reemplazado por consultas a formul
Estrategia:
- Opción A: Deprecar completamente, usar solo formul
- Opción B: Mantener como fallback si formul no tiene configuración (más seguro durante transición)

Criterios de Aceptación

AC-001: El sistema debe consultar la tabla formul para obtener todas las configuraciones activas de un tipo de comprobante y letra calculada, en lugar de usar los valores definidos en TipoComprobante.php.

Verificación:

Crear una factura: usuario selecciona "Factura" y cliente Responsable Inscripto
Sistema calcula automáticamente letra: A (RI + RI)
En logs del sistema o mediante debugging, confirmar que se ejecuta query: SELECT * FROM formul WHERE tipo_comprobante='factura' AND letra='A' AND activo=true
Confirmar que NO se usa el valor hardcodeado de TipoComprobante.php
Confirmar que la letra 'A' NO fue seleccionada por el usuario sino calculada por el sistema
Si hay 1 resultado: usa ese código automáticamente
Si hay múltiples resultados: muestra selector al usuario

AC-002: Un administrador con permisos adecuados puede modificar el código ARCA de un tipo de comprobante existente en la tabla formul.

Verificación:

Usuario con rol Administrador accede a configuración de formul
Selecciona "Factura A" (código actual: 1)
Cambia código a 51
Guarda cambios
Verificar en base de datos: registro de Factura A tiene codigo=51

AC-003: Los cambios realizados en la tabla formul se reflejan inmediatamente en las facturas que se emitan a partir de ese momento.

Verificación:

Configuración inicial: Factura A = código 1
Emitir Factura 001 → verificar id_tipo_comprobante=1
Cambiar configuración: Factura A = código 51
Emitir Factura 002 (inmediatamente después) → verificar id_tipo_comprobante=51
Tiempo entre cambio y efecto: 0 segundos (inmediato, sin necesidad de reinicio)

AC-004: Las facturas emitidas con anterioridad NO son afectadas por cambios posteriores en la configuración de formul.

Verificación:

Configuración: Factura A = código 1
Emitir Facturas 001-010 → todas con id_tipo_comprobante=1
Cambiar configuración: Factura A = código 51
Verificar Facturas 001-010 en base de datos → todas siguen con id_tipo_comprobante=1 (sin cambios)
Consultar PDF de Factura 005 → debe mostrar código 1, no código 51

AC-005: El sistema permite crear nuevas configuraciones con códigos especiales de AFIP (51, 52, 53) para comprobantes sujetos a retenciones u otros regímenes especiales.

Verificación:

Administrador crea NUEVA configuración: tipo_comprobante="factura", letra="A", codigo=51, descripcion="Factura A sujeta a retención"
Nueva configuración queda disponible junto con la configuración existente (código 1)
Usuario emite Factura A → sistema muestra selector con ambas opciones
Usuario selecciona "Factura A sujeta a retención"
Sistema envía a ARCA con código 51
ARCA autoriza (o rechaza con mensaje claro, pero el intento se hace con código 51)
Factura guardada tiene id_tipo_comprobante=51

AC-006: Si la tabla formul no tiene configuración para un tipo y letra específicos, el sistema muestra un mensaje de error claro indicando que el tipo de comprobante no está configurado para esa empresa.

Verificación:

Eliminar (o no sembrar) configuración de Factura C en formul
Intentar crear Factura C
Sistema debe mostrar error: "El tipo de comprobante Factura C no está configurado para esta empresa. Contacte al administrador."
Factura NO se crea
NO se envía solicitud a ARCA

AC-007: Cada empresa/sucursal tiene su propia configuración de tipos de comprobante en formul, independiente de otras empresas.

Verificación:

Empresa A (esquema suc0001): Factura A = código 51
Empresa B (esquema suc0002): Factura A = código 1
Usuario de Empresa A emite Factura A → usa código 51
Usuario de Empresa B emite Factura A → usa código 1
Verificar que cada empresa usa su configuración sin interferencia

AC-008: Los códigos especiales configurados en formul son enviados correctamente a ARCA y, si la empresa está autorizada, son aceptados por el servicio web de AFIP.

Verificación:

Configurar Factura A = código 51
Emitir Factura A
Verificar en logs de integración con ARCA que el campo CbteTipo enviado es 51 (no 1)
Si empresa está autorizada: ARCA devuelve CAE exitosamente
Si empresa NO está autorizada: ARCA devuelve error específico (pero el código 51 fue enviado correctamente)

AC-009: Un administrador puede gestionar tipos de comprobante mediante el ABM dedicado, creando múltiples configuraciones con diferentes letras según los códigos ARCA.

Verificación:

El sistema debe cumplir con todos los criterios de aceptación definidos en ABM de Tipos de Comprobante
Cada código ARCA tiene una letra específica asignada (código 1 = letra A, código 51 = letra ALEY)
La combinación tipo_comprobante + letra debe ser única
Al facturar con múltiples letras válidas según AFIP, aparece selector con las opciones configuradas

AC-010: Los tipos de comprobante pueden desactivarse pero no eliminarse físicamente si tienen comprobantes emitidos.

Referencia: Ver reglas de desactivación en ABM de Tipos de Comprobante - CU-003

Verificación:

Crear configuración: tipo_comprobante="factura", letra="A", codigo=51
NO emitir ningún comprobante con esta configuración
Intentar eliminar → debe permitir eliminación (soft delete)
Emitir una Factura A con código 51
Intentar eliminar la configuración → debe mostrar error: "No se puede eliminar, tiene comprobantes asociados. Puede desactivarla."
Desactivar la configuración → debe permitir desactivación
Verificar que configuración desactivada NO aparece en selector de facturación
Verificar que comprobantes históricos mantienen integridad referencial

AC-011: El sistema valida que el código ARCA ingresado por el administrador sea un número entero positivo y, idealmente, que esté dentro del rango de códigos válidos según normativa AFIP.

Verificación:

Intentar ingresar código "ABC" → error: "El código debe ser numérico"
Intentar ingresar código "-5" → error: "El código debe ser positivo"
Intentar ingresar código "0" → error: "El código debe ser mayor a 0"
Ingresar código "51" (válido) → aceptado
(Opcional) Ingresar código "9999" (inexistente en AFIP) → advertencia: "Este código puede no ser válido según normativa AFIP"

AC-012: Todos los cambios realizados en la tabla formul quedan registrados en el sistema de auditoría, indicando qué usuario realizó qué cambio y cuándo.

Verificación:

Administrador cambia Factura A de código 1 a código 51
Consultar tabla de auditoría:
- Registro encontrado: tabla=formul, campo=codigo, valor_anterior=1, valor_nuevo=51, usuario=admin@empresa.com, fecha_hora=2026-01-05 14:30:00
Verificar que el registro es inmutable (no puede editarse ni borrarse)

AC-013: Cuando hay una sola configuración para un tipo y letra calculada, el usuario NO ve cambios en la interfaz. Cuando hay múltiples configuraciones, aparece un selector obligatorio.

Verificación (una sola opción - transparente):

Configurar solo: Factura A código 1
Usuario selecciona "Factura" y cliente Responsable Inscripto
Sistema calcula letra: A (RI + RI)
Sistema usa automáticamente código 1 sin mostrar selector
Usuario NO ve código ARCA en ningún momento
Usuario NO seleccionó letra manualmente

Verificación (múltiples opciones - con selector):

Configurar: Factura A código 1 y Factura A código 51
Usuario selecciona "Factura" y cliente Responsable Inscripto
Sistema calcula letra: A (RI + RI)
Sistema muestra selector: "¿Qué tipo de Factura A desea emitir?"
Opciones: "Factura A estándar" y "Factura A sujeta a retención"
Usuario DEBE seleccionar obligatoriamente una opción
Usuario NO ve código ARCA (51), solo ve descripción clara

AC-014: Los reportes PDF generados utilizan el template correcto según el campo reporte configurado en formul para cada tipo de comprobante.

Verificación:

Configurar Factura A: codigo=1, reporte=FA1
Emitir Factura 001 → PDF generado usa template FA1 (diseño estándar)
Cambiar configuración: codigo=51, reporte=FA51
Emitir Factura 002 → PDF generado usa template FA51 (incluye leyenda "Sujeta a retención")
Consultar PDF de Factura 001 (histórica) → sigue usando FA1 (no cambia a FA51)

AC-015: El sistema incluye un campo tipo_comprobante que agrupa los comprobantes por categoría (factura, nota-credito, nota-debito, ticket, recibo).

Verificación:

Al crear configuración, debe existir campo "Tipo de Comprobante" con valores: factura, nota-credito, nota-debito, ticket, recibo
En el listado de configuraciones, debe poder filtrarse por tipo de comprobante
El agrupamiento visual debe organizar las configuraciones por tipo de comprobante
Query de búsqueda debe usar WHERE tipo_comprobante='factura' (no nombre='FACTURA')

AC-016: El sistema exige que la descripción sea obligatoria al crear o editar una configuración, ya que es necesaria para diferenciar múltiples variantes.

Verificación:

Intentar crear configuración sin descripción → error: "La descripción es obligatoria"
Intentar guardar configuración con descripción vacía → error: "La descripción es obligatoria"
Crear configuración con descripción "Factura A estándar" → se guarda correctamente
La descripción debe mostrarse en el selector cuando hay múltiples opciones

AC-017: El sistema permite crear múltiples configuraciones con el mismo tipo_comprobante y letra, diferenciadas por descripción y código.

Verificación:

Crear configuración 1: tipo_comprobante="factura", letra="A", codigo=1, descripcion="Factura A estándar"
Crear configuración 2: tipo_comprobante="factura", letra="A", codigo=51, descripcion="Factura A sujeta a retención"
Ambas configuraciones deben existir simultáneamente en la base de datos
NO debe haber error de "combinación duplicada"
Al facturar, debe aparecer selector con ambas opciones claramente diferenciadas por su descripción

AC-018: Un administrador puede desactivar configuraciones de tipos de comprobante sin eliminarlas.

Verificación:

Configurar: Factura A código 51
Emitir comprobantes con código 51
Desactivar la configuración
Verificar que NO aparece en selector de facturación (solo configuraciones activas)
Verificar que comprobantes históricos con código 51 mantienen integridad
Verificar que en listado de configuración aparece como "Inactiva"
Verificar que puede reactivarse posteriormente

AC-019: El sistema determina las letras/clases válidas consultando a AFIP y cruzándolas con las configuraciones en formul. Si hay una sola opción válida, se selecciona automáticamente. Si hay múltiples opciones válidas, el usuario elige.

Verificación:

Usuario selecciona tipo "Factura" y cliente "Distribuidora ABC S.A." (Responsable Inscripto)
Sistema consulta AFIP: retorna letras válidas [A, ALEY] para Responsable Inscripto
Sistema consulta formul: configuraciones activas [A, B] para tipo factura
Sistema calcula intersección: [A, ALEY] ∩ [A, B] = [A]
Como hay una sola coincidencia, sistema auto-selecciona letra A (transparente para el usuario)
Usuario continúa el proceso sin necesidad de intervenir
Comprobante se emite con letra A

Verificación alternativa (múltiples opciones):

formul tiene configurado: [A, ALEY, B]
AFIP retorna válidas: [A, ALEY]
Intersección: [A, ALEY]
Sistema muestra selector: "Seleccione tipo: [Factura A] [Factura ALEY]"
Usuario elige ALEY
Sistema registra selección en auditoría
Comprobante se emite con letra ALEY seleccionada por usuario

AC-020: El campo tipo (letra/clase) en formul soporta valores extendidos más allá de A, B, C, incluyendo ALEY y 49.

Verificación:

Administrador crea configuración con letra/clase="ALEY", codigo=201
Sistema acepta y guarda correctamente (campo soporta hasta 5 caracteres)
Configuración queda disponible para intersección con letras válidas de AFIP al facturar
Sistema valida que longitud no exceda 5 caracteres
Intentar crear configuración con clase de 6+ caracteres genera error de validación

AC-021: El sistema permite configurar múltiples códigos ARCA especiales (51, 52, 53, 201, 49, etc.) asociados a diferentes letras/clases.

Verificación:

Administrador configura: tipo_comprobante="factura", tipo="A", codigo=51, descripcion="Factura A con retenciones"
Administrador configura: tipo_comprobante="factura", tipo="ALEY", codigo=201, descripcion="Factura A Ley 27.541"
Administrador configura: tipo_comprobante="factura", tipo="49", codigo=49, descripcion="Factura MiPyME Bienes Usados"
Todas las configuraciones coexisten en formul sin conflicto
Cuando AFIP retorne cualquiera de estas letras como válidas para un cliente, aparecerán en la intersección y el usuario podrá seleccionarlas

AC-022: El sistema registra en auditoría el proceso de determinación de letra: consultas a AFIP, configuraciones en formul, intersección calculada, y selección del usuario (cuando aplica).

Verificación - Selección automática (1 opción):

Usuario selecciona cliente Responsable Inscripto
Sistema consulta AFIP: retorna [A, ALEY]
Sistema consulta formul: retorna [A, B]
Intersección: [A]
Sistema auto-selecciona A
En registro de auditoría aparece:
- "Consulta AFIP para CUIT 30-12345678-9: letras válidas [A, ALEY]"
- "Configuraciones formul disponibles: [A, B]"
- "Intersección calculada: [A]"
- "Auto-selección: A (única opción válida)"
Comprobante se emite con letra A

Verificación - Selección manual (múltiples opciones):

formul tiene configurado: [A, ALEY, B]
AFIP retorna válidas: [A, ALEY]
Intersección: [A, ALEY]
Sistema muestra selector, usuario elige ALEY
En registro de auditoría aparece:
- "Consulta AFIP: letras válidas [A, ALEY]"
- "Configuraciones formul: [A, ALEY, B]"
- "Intersección: [A, ALEY]"
- "Usuario seleccionó: ALEY (entre opciones: A, ALEY) - usuario@empresa.com, fecha/hora"
Comprobante se emite con letra ALEY seleccionada por usuario

AC-023: La configuración de formul valida que no existan duplicados exactos (mismo tipo_comprobante + tipo + codigo).

Verificación:

Administrador intenta crear: tipo_comprobante="factura", tipo="A", codigo=1
Ya existe esa combinación exacta en formul
Sistema rechaza con error: "Ya existe una configuración de Factura A con código 1"
Administrador puede crear variantes diferentes:
- tipo_comprobante="factura", tipo="A", codigo=51 (diferente código - permitido)
- tipo_comprobante="factura", tipo="ALEY", codigo=1 (diferente tipo - permitido)
- tipo_comprobante="nota-credito", tipo="A", codigo=1 (diferente tipo_comprobante - permitido)

Notas Adicionales

Alcance de esta Documentación

Este documento describe exclusivamente los requisitos de negocio de la funcionalidad de configuración flexible de tipos de comprobantes. NO incluye:

Detalles de implementación técnica (nombres de clases, métodos, servicios)
Estructura de API REST (endpoints, DTOs, request/response)
Diseño de base de datos (tipos de datos SQL, índices, foreign keys)
Arquitectura de código (patrones de diseño, capas, dependencias)

Esos aspectos serán definidos durante la fase de desarrollo técnico, respetando los requisitos de negocio aquí documentados.

Próximos Pasos

Una vez aprobado este documento de requisitos de negocio:

Validación con stakeholders:
- Presentar a gerencia y equipo contable
- Confirmar que cubre las necesidades regulatorias
- Aprobar formalmente el alcance
Diseño técnico:
- Equipo de desarrollo crea documento de diseño técnico
- Define arquitectura, servicios, modelos, APIs
- Estima esfuerzo de desarrollo
Desarrollo:
- Implementación siguiendo metodología TDD (Test-Driven Development)
- Desarrollo en ambiente de prueba
- Testing con ambiente de homologación de AFIP
Pruebas de aceptación:
- Validar cada criterio de aceptación (AC-001 a AC-023)
- Pruebas con usuarios finales (administradores y usuarios de ventas)
- Pruebas de integración con ARCA (ambiente de prueba de AFIP)
Despliegue:
- Migración a producción
- Capacitación a administradores sobre configuración de formul
- Documentación de usuario final
Monitoreo:
- Seguimiento de emisión de comprobantes con nuevos códigos
- Revisión de logs de auditoría
- Validación de aceptación por ARCA

Referencias Normativas

AFIP (Administración Federal de Ingresos Públicos):

Resolución General 2485/2008 - Factura electrónica
Resolución General 2904/2010 - Ampliación de régimen de factura electrónica
Resolución General 4290/2018 - Comprobantes electrónicos originales
Códigos de comprobantes: [Consultar en portal oficial de AFIP]

Consultas Recomendadas:

Portal AFIP: afip.gob.ar
Servicio ARCA: Documentación técnica de WebServices
Asesor contable de la empresa para casos específicos

Compatibilidad hacia Atrás

Principio fundamental: La funcionalidad de determinación automática de letra y soporte de clases extendidas es aditiva y no rompe la funcionalidad existente.

Garantías de compatibilidad:

Empresas sin configuración de clases especiales:
- Continúan funcionando exactamente igual que antes
- El sistema calcula la letra automáticamente (A, B, C) según condiciones IVA
- Si solo existe una configuración por tipo+letra, se usa automáticamente (transparente)
- NO se requiere ninguna acción del administrador
Configuraciones existentes de formul:
- Las configuraciones existentes con letras A, B, C, X siguen funcionando sin cambios
- El campo tipo (letra) que antes almacenaba 1 carácter, ahora soporta hasta 5
- No hay impacto en datos existentes
Comprobantes históricos:
- Todos los comprobantes emitidos anteriormente mantienen su integridad
- Los códigos ARCA almacenados no cambian
- Los reportes históricos siguen funcionando correctamente
Flujo de facturación existente:
- El flujo de facturación se mantiene igual para el usuario operativo
- La determinación automática de letra es transparente (ya estaba implícita en el sistema)
- El selector de variantes solo aparece cuando hay múltiples opciones configuradas

Escenarios de migración cero-impacto:

Empresa con configuración básica (Factura A código 1, Factura B código 6, etc.) → funciona igual
Empresa con códigos especiales (51, 52, 53) ya configurados → funciona igual
Empresa que solo tiene una letra configurada por tipo → auto-selección transparente, sin cambios en UX

Migración Gradual de Tipos Existentes

Estrategia de adopción progresiva:

Las empresas pueden adoptar las nuevas funcionalidades de forma gradual, sin interrupciones:

Fase 1: Sin cambios (inmediata)

El sistema continúa funcionando con la configuración actual
La validación con AFIP funciona en segundo plano
Si empresa solo tiene una letra por tipo, auto-selección transparente (sin cambios en UX)

Fase 2: Habilitación de clases especiales (cuando se necesite)

Cuando una empresa necesite ALEY o 49, el administrador crea la configuración en formul
El administrador puede crear la configuración sin afectar operaciones existentes
Cuando AFIP retorne esa clase como válida para un cliente, aparecerá en el selector junto con las otras opciones válidas

Fase 3: Entrenamiento y uso regular (opcional)

Capacitación a usuarios sobre cuándo elegir cada clase especial (cuando haya múltiples opciones)
Documentación de casos de uso específicos de la empresa (ej: cuándo usar ALEY vs A)
Monitoreo de auditoría para validar uso correcto

Recomendaciones para la migración:

No realizar cambios masivos: Agregar clases especiales una a una según se necesiten
Probar en ambiente de desarrollo: Antes de crear configuración en producción, validar en ambiente de prueba
Comunicar a usuarios: Si agregan múltiples clases, informar que verán selector para elegir entre opciones válidas
Monitorear selecciones: Revisar auditoría para detectar patrones de uso y validar que usuarios eligen correctamente
Documentar casos de empresa: Crear guía interna de cuándo usar cada clase especial

Rollback:

Si una empresa tiene problemas con la nueva funcionalidad, puede desactivar las clases especiales configuradas
El sistema vuelve al comportamiento anterior (solo A, B, C)
No se pierden datos ni comprobantes emitidos

Glosario de Términos

AFIP: Administración Federal de Ingresos Públicos (ente recaudador de Argentina)
ARCA: Sistema de AFIP para autorización de comprobantes electrónicos
CAE: Código de Autorización Electrónica (emitido por AFIP al autorizar un comprobante)
CUIT: Clave Única de Identificación Tributaria
Código ARCA: Código numérico que identifica el tipo de comprobante ante AFIP (ej: 1=Factura A, 51=Factura A sujeta a retención, 201=Factura ALEY)
Formul: Tabla de configuración que almacena los tipos de comprobante por empresa
Multi-tenant: Arquitectura donde múltiples empresas (tenants) usan el mismo sistema con datos aislados
Schema: Esquema de base de datos que aísla los datos de cada empresa en PostgreSQL
Intersección: Resultado de cruzar las letras válidas retornadas por AFIP con las letras configuradas en formul. Solo las letras presentes en ambos conjuntos son opciones válidas para el usuario
Letra/Clase: Categoría fiscal del comprobante. Puede ser estándar (A, B, C, X) o extendida (ALEY, 49)
ALEY: Clase de comprobante A con leyenda especial por normativa vigente (ej: Ley 27.541)
49: Clase especial para Factura de Crédito Electrónico MiPyME - Bienes Usados

FIN DEL DOCUMENTO

Este documento de requisitos de negocio es la base para el desarrollo de la funcionalidad de configuración flexible de tipos de comprobantes de facturación electrónica. Todos los desarrollos técnicos deben alinearse con los requisitos aquí especificados.

Retenciones

Ganancias

Retenciones

Configuración Flexible de Tipos de Comprobantes de Facturación Electrónica ​

Descripción ​

Problema de Negocio ​

Solución Propuesta ​

Valor de Negocio ​

Contexto del Sistema ​

Proceso de Negocio ​

Flujo de Selección Flexible de Código de Comprobante ​

Gestión de Tipos de Comprobante (ABM) ​

Frontend (Perspectiva de Usuario) ​

Vistas ​

1. Gestión de Tipos de Comprobante ​

2. Vista de Creación de Factura (Con selector opcional) ​

Interacciones del Usuario ​

Permisos ​

Estados de UI ​

Estados en Gestión de Tipos de Comprobante ​

Estados en Facturación (Transparente) ​

Backend (Perspectiva de Datos de Negocio) ​

Entidades de Negocio ​

Entidad Principal: Tipo de Comprobante (formul) ​

Datos Necesarios ​

Para Configuración de Formul ​

Para Proceso de Facturación ​

Relaciones de Negocio ​

Validaciones de Negocio ​

Reglas de Negocio ​

RN-001: Resolución Dinámica de Código con Cálculo de Letra y Selector Condicional ​

RN-002: Cambios con Efecto Inmediato ​

RN-003: Validación Final por AFIP ​

RN-004: Alcance por Empresa (Multi-Tenant) ​

RN-005: Gestión de Tipos de Comprobantes (ABM) ​

RN-006: Soporte de Códigos Especiales ​

RN-007: Determinación Automática de Letra/Clase mediante Validación AFIP ​

Casos de Uso ​

CU-001: Empresa Configura Código Especial para Retenciones ​

CU-002: Usuario Crea Factura con Código Configurado ​

CU-003: Sistema Usa Formul en Lugar de Constante ​

CU-004: Cambio de Configuración No Afecta Facturas Históricas ​

CU-005: Configurar Tipos de Comprobante con Nuevas Clases ​

Consideraciones ​

Seguridad ​

Auditoría ​

Rendimiento ​

Migración ​

Compatibilidad con AFIP ​

Dependencias ​

Recursos Relacionados ​

Funcionalidades Relacionadas ​

Módulos Externos ​

Consulta de Condiciones IVA desde AFIP ​

Tablas del Sistema ​

Criterios de Aceptación ​

Notas Adicionales ​

Alcance de esta Documentación ​

Próximos Pasos ​

Referencias Normativas ​

Compatibilidad hacia Atrás ​

Migración Gradual de Tipos Existentes ​

Glosario de Términos ​

Configuración Flexible de Tipos de Comprobantes de Facturación Electrónica

Descripción

Problema de Negocio

Solución Propuesta

Valor de Negocio

Contexto del Sistema

Proceso de Negocio

Flujo de Selección Flexible de Código de Comprobante

Gestión de Tipos de Comprobante (ABM)

Frontend (Perspectiva de Usuario)

Vistas

1. Gestión de Tipos de Comprobante

2. Vista de Creación de Factura (Con selector opcional)

Interacciones del Usuario

Permisos

Estados de UI

Estados en Gestión de Tipos de Comprobante

Estados en Facturación (Transparente)

Backend (Perspectiva de Datos de Negocio)

Entidades de Negocio

Entidad Principal: Tipo de Comprobante (formul)

Datos Necesarios

Para Configuración de Formul

Para Proceso de Facturación

Relaciones de Negocio

Validaciones de Negocio

Reglas de Negocio

RN-001: Resolución Dinámica de Código con Cálculo de Letra y Selector Condicional

RN-002: Cambios con Efecto Inmediato

RN-003: Validación Final por AFIP

RN-004: Alcance por Empresa (Multi-Tenant)

RN-005: Gestión de Tipos de Comprobantes (ABM)

RN-006: Soporte de Códigos Especiales

RN-007: Determinación Automática de Letra/Clase mediante Validación AFIP

Casos de Uso

CU-001: Empresa Configura Código Especial para Retenciones

CU-002: Usuario Crea Factura con Código Configurado

CU-003: Sistema Usa Formul en Lugar de Constante

CU-004: Cambio de Configuración No Afecta Facturas Históricas

CU-005: Configurar Tipos de Comprobante con Nuevas Clases

Consideraciones

Seguridad

Auditoría

Rendimiento

Migración

Compatibilidad con AFIP

Dependencias

Recursos Relacionados

Funcionalidades Relacionadas

Módulos Externos

Consulta de Condiciones IVA desde AFIP

Tablas del Sistema

Criterios de Aceptación

Notas Adicionales

Alcance de esta Documentación

Próximos Pasos

Referencias Normativas

Compatibilidad hacia Atrás

Migración Gradual de Tipos Existentes

Glosario de Términos