ABM de Tipos de Comprobantes

Módulo: Ventas Tipo: Resource Estado: Planificado Fecha: 2026-01-07

---

Descripción

Problema de Negocio

Actualmente, el sistema requiere intervención técnica cada vez que se necesita agregar o modificar un tipo de comprobante de ARCA/AFIP. Esto genera:

1. Rigidez operativa: No se pueden adaptar rápidamente a cambios en las normativas de AFIP
2. Dependencia técnica: Cada modificación requiere desarrollo y deployment
3. Riesgo de errores: Intervenciones manuales en base de datos sin validación
4. Falta de trazabilidad: No hay registro de quién y cuándo se modificó la configuración

Solución Propuesta

Implementar un ABM (Alta, Baja, Modificación) completo para la gestión de tipos de comprobantes que permita a usuarios administradores:

• Listar todos los tipos de comprobantes configurados en el sistema
• Crear nuevos tipos consultando directamente la API de ARCA para obtener información actualizada
• Modificar configuraciones de tipos existentes
• Desactivar tipos que ya no se utilizan (sin eliminarlos de la base de datos)

La solución integra directamente con la API de ARCA para:

• Obtener el catálogo oficial de tipos de comprobantes
• Filtrar automáticamente los tipos ya registrados
• Autocompletar código y nombre oficial desde ARCA
• Mantener sincronización con las normativas vigentes

Importante sobre Códigos ARCA y Letras:

• El código ARCA es único y es el verdadero identificador del tipo de comprobante
• Cada código ARCA tiene asignada una letra específica
• Múltiples códigos ARCA pueden compartir la misma categoría y 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)
• Código ARCA 201: "Factura de Crédito Electrónica MiPyMEs A" → letra A (categoría: factura)

El código ARCA es el único identificador que importa. Pueden coexistir múltiples tipos con la misma categoría y letra porque cada uno tiene un código ARCA diferente y representa un caso de uso fiscal específico. El proceso de facturación electrónica flexible permite al usuario seleccionar el código correcto según el contexto fiscal.

Valor de Negocio

• Autonomía operativa: Administradores pueden gestionar tipos sin depender de desarrollo
• Cumplimiento normativo: Fácil adaptación a cambios en normativas de AFIP
• Reducción de costos: Menos tiempo de desarrollo y deployment para cambios de configuración
• Consistencia: Datos siempre sincronizados con ARCA
• Flexibilidad: Adaptación por empresa según sus necesidades específicas

---

Frontend (Perspectiva de Usuario)

Vistas

1. Listado de Tipos de Comprobantes

   • Tabla con todos los tipos configurados (activos e inactivos)
   • Columnas: código ARCA, nombre, letra, abreviatura, categoría, estado
   • Panel de filtros para búsqueda rápida
   • Botón para crear nuevo tipo
   • Acciones por fila: modificar, desactivar/activar

2. Formulario de Alta de Tipo de Comprobante

   • Selector de tipo desde catálogo de ARCA (solo tipos no registrados)
   • Campo código (autocompletado, solo lectura)
   • Campo nombre (autocompletado, solo lectura, truncado si excede 100 caracteres)
   • Selector de letra: A, B, C, ALEY
   • Campo abreviatura (máximo 10 caracteres)
   • Selector de categoría: Factura, Nota de Crédito, Nota de Débito, Recibo, Liquidación
   • Botones: Guardar, Cancelar

3. Formulario de Modificación de Tipo de Comprobante

   • Campo código (solo lectura, no editable)
   • Campo nombre (solo lectura, no editable)
   • Selector de letra: A, B, C, ALEY (editable)
   • Campo abreviatura (editable)
   • Selector de categoría (editable)
   • Botones: Guardar cambios, Cancelar

4. Modal de Confirmación de Desactivación

   • Mensaje de confirmación con nombre del tipo
   • Advertencia si tiene comprobantes asociados (bloquea desactivación)
   • Botones: Confirmar, Cancelar

Interacciones del Usuario

Consulta y Búsqueda:

• Ver listado completo de tipos de comprobantes
• Filtrar por letra del comprobante (A, B, C, ALEY, todas)
• Filtrar por categoría (factura, nota-crédito, nota-débito, recibo, liquidación, todas)
• Filtrar por estado (activos, inactivos, todos)
• Ordenar por cualquier columna

Operaciones de Alta:

• Acceder al formulario de creación
• Consultar catálogo de ARCA actualizado
• Seleccionar un tipo de comprobante no registrado del catálogo
• Ver código y nombre autocompletados desde ARCA
• Seleccionar letra del comprobante
• Ingresar abreviatura personalizada
• Seleccionar categoría del comprobante
• Guardar nuevo tipo de comprobante

Operaciones de Modificación:

• Seleccionar un tipo existente para editar
• Modificar letra del comprobante
• Modificar abreviatura
• Modificar categoría
• Guardar cambios realizados

Operaciones de Desactivación:

• Seleccionar un tipo para desactivar
• Ver confirmación con validación de uso
• Confirmar desactivación
• Reactivar un tipo previamente desactivado

Permisos

Estructura de Acceso en Sidebar:

• Ruta de navegación: Ventas → Bases → Tipos de comprobantes
• Nivel jerárquico: Opción dentro de la sección Bases del módulo Ventas

Permiso a Crear:

El nuevo permiso a definir en el sistema de permisos:

[
    'id' => 44,
    'codigo' => 'VENTAS_BASES_TIPOS-COMPROBANTES',
    'nombre' => 'Tipos de comprobantes',
    'descripcion' => 'Acceso al listado, alta, modificación y desactivación de tipos de comprobantes',
    'nivel' => 3,
    'id_padre' => 2  // VENTAS_BASES
]

Estructura Jerárquica:

• Nivel 1: VENTAS (Módulo Ventas)
• Nivel 2: VENTAS_BASES (Sección Bases)
• Nivel 3: VENTAS_BASES_TIPOS-COMPROBANTES (Opción Tipos de comprobantes) ← NUEVO

Capacidades Incluidas en este Permiso:

• Visualizar listado de tipos de comprobantes
• Crear nuevos tipos desde catálogo ARCA
• Modificar tipos existentes (letra, abreviatura, categoría)
• Desactivar y reactivar tipos

Nota: Este permiso es único y agrupa todas las operaciones ABM. Solo usuarios con rol de Administrador del sistema deberían tenerlo asignado.

Estados de UI

El usuario debe recibir retroalimentación clara en los siguientes estados:

Estados de Carga:

• Cargando listado de tipos de comprobantes
• Consultando catálogo de ARCA
• Guardando nuevo tipo
• Guardando modificaciones
• Procesando desactivación

Estados de Error:

• Error al cargar listado
• Error de conexión con API de ARCA
• Error al guardar (con mensaje específico de validación)
• Error al desactivar tipo con comprobantes asociados
• Error de red o timeout

Estados de Éxito:

• Tipo creado exitosamente
• Tipo modificado exitosamente
• Tipo desactivado exitosamente
• Tipo reactivado exitosamente

Estados Vacíos:

• Listado sin resultados (cuando no hay tipos configurados)
• Catálogo de ARCA sin tipos disponibles (todos ya registrados)
• Sin resultados de búsqueda (con filtros aplicados)

Estados de Validación:

• Campos obligatorios sin completar
• Código ARCA duplicado
• Nombre excede 100 caracteres (mostrar truncamiento)

---

Backend (Perspectiva de Datos de Negocio)

Entidades de Negocio

Tipo de Comprobante (entidad principal del ABM)

Representa cada tipo de comprobante que el sistema puede generar, con información oficial de ARCA más configuraciones específicas de la empresa.

Datos Necesarios

Cada Tipo de Comprobante debe almacenar:

1. Código ARCA (numérico, 1-99)

   • Código oficial de AFIP/ARCA
   • Único en el sistema
   • Proviene del catálogo de ARCA
   • No modificable una vez registrado

2. Nombre descriptivo (texto, máximo 100 caracteres)

   • Descripción oficial del tipo según ARCA
   • Ejemplo: "Factura A", "Nota de Crédito B"
   • Proviene del catálogo de ARCA
   • No modificable una vez registrado
   • Se trunca automáticamente si excede 100 caracteres

3. Letra del comprobante (texto, valores: A, B, C, ALEY)

   • Determina el régimen fiscal del comprobante
   • A: Régimen general (entre responsables inscriptos)
   • B: Régimen simplificado (para consumidores finales)
   • C: Operaciones exentas o no gravadas
   • ALEY: Régimen especial por ley
   • Configurable por el usuario (no viene de ARCA)

4. Abreviatura (texto, máximo 10 caracteres)

   • Forma corta para mostrar en listados
   • Ejemplos: "Fac.", "NC.", "ND.", "Rec."
   • Configurable por el usuario

5. Categoría del comprobante (texto, valores predefinidos)

   • Agrupa tipos por su función de negocio
   • Valores: factura, nota-credito, nota-debito, recibo, liquidacion
   • Determina el comportamiento en el sistema (suma/resta, afecta stock, etc.)

6. Estado activo/inactivo (booleano)

   • Indica si el tipo está disponible para usar
   • Permite desactivar sin eliminar (soft delete)
   • Tipos inactivos no aparecen en selectores de usuario

Relaciones de Negocio

Tipo de Comprobante se relaciona con:

1. Comprobantes de Venta

   • Un tipo de comprobante puede ser usado en múltiples facturas, notas de crédito, etc.
   • No se puede desactivar un tipo si existen comprobantes activos que lo utilizan

2. Condiciones de IVA

   • La letra del comprobante determina qué combinaciones de condiciones IVA son válidas
   • Ejemplo: Factura A solo válida entre Responsables Inscriptos

3. Proceso de Facturación Electrónica

   • El código ARCA se envía a AFIP al autorizar comprobantes electrónicos
   • La letra determina qué validaciones aplica AFIP

4. Numeración de Comprobantes

   • Cada tipo tiene su propia secuencia de numeración
   • La numeración no se pierde al desactivar/reactivar

Validaciones de Negocio

Al crear un tipo de comprobante:

1. Código ARCA debe ser único

   • No pueden existir dos tipos con el mismo código
   • El sistema debe validar contra tipos existentes (activos e inactivos)

2. Código debe existir en catálogo de ARCA

   • Solo se permiten códigos oficiales de AFIP
   • Debe obtenerse desde la API de ARCA

3. Nombre debe truncarse a 100 caracteres

   • Si el nombre oficial de ARCA excede 100 caracteres, truncar automáticamente
   • No mostrar error, aplicar truncamiento transparente

4. Letra debe ser valor válido

   • Solo se aceptan: A, B, C, ALEY
   • Validación contra lista predefinida

5. Categoría debe ser valor válido

   • Solo se aceptan: factura, nota-credito, nota-debito, recibo, liquidacion
   • Validación contra lista predefinida

6. Letra debe ser compatible con el régimen fiscal de la empresa

   • Responsables Inscriptos (código IVA = 1): Solo letras A, B o ALEY
   • Exentos y Monotributistas (códigos IVA = 4 o 6): Solo letra C
   • La validación se realiza automáticamente al crear el tipo
   • El catálogo ARCA se filtra automáticamente según el régimen fiscal

7. Todos los campos son obligatorios

   • Código, nombre, letra, abreviatura y categoría deben estar completos

Al modificar un tipo de comprobante:

1. Código y nombre no son editables

   • Solo se pueden modificar: letra, abreviatura, categoría
   • Código y nombre vienen de ARCA y no deben cambiar

2. Cambio de letra debe ser compatible con el régimen fiscal ✨ NUEVA

   • La letra modificada debe cumplir las restricciones del régimen fiscal de la empresa
   • RI: Solo A, B o ALEY; Exento/Mono: Solo C

3. Cambio de letra no debe romper comprobantes existentes

   • Advertir al usuario si hay comprobantes con el tipo que se está modificando

Al desactivar un tipo de comprobante:

1. No permitir si tiene comprobantes asociados activos

   • Validar que no existan facturas, notas, recibos pendientes con este tipo
   • Mostrar cantidad de comprobantes que impiden la desactivación

2. Desactivar es reversible

   • No eliminar el registro de la base de datos
   • Marcar como inactivo con flag booleano
   • Permitir reactivar posteriormente

---

Reglas de Negocio

RN-001: Consulta y Filtrado desde ARCA

Al crear un nuevo tipo de comprobante:

1. El sistema consulta la API de ARCA para obtener el catálogo oficial de tipos de comprobantes
2. Filtra automáticamente los tipos ya registrados en Formul (por código)
3. Solo muestra al usuario tipos no registrados disponibles para agregar
4. Si todos los tipos ya están registrados, mostrar mensaje informativo

Nota: Revisar configuración y documentación de la API de ARCA/AFIP para detalles de integración y conexión.

Justificación: Evita duplicados y asegura que solo se registren tipos oficiales de ARCA.

RN-002: Autocompletado de Código y Nombre

Al seleccionar un tipo de comprobante del catálogo de ARCA:

1. El código ARCA se autocompleta y se muestra como solo lectura
2. El nombre oficial se autocompleta y se muestra como solo lectura
3. Estos campos no pueden ser modificados manualmente por el usuario
4. Permanecen como solo lectura durante toda la vida del registro

Justificación: Garantiza consistencia con datos oficiales de ARCA y evita errores de tipeo.

RN-003: Truncamiento Automático de Nombres

Si el nombre oficial de ARCA excede 100 caracteres:

1. El sistema trunca automáticamente a 100 caracteres
2. El truncamiento es transparente, sin mostrar error
3. Se preserva la mayor cantidad de información posible
4. El nombre truncado es el que se almacena y muestra en todo el sistema

Justificación: Límite de base de datos, mantiene compatibilidad con schema existente.

RN-004: Letra de Comprobante Manual

La letra del comprobante (A, B, C, ALEY):

1. No proviene de ARCA (ARCA solo envía código y nombre)
2. Debe ser seleccionada manualmente por el usuario
3. Es un dato de configuración específico de la empresa
4. Puede modificarse posteriormente si es necesario

Justificación: La letra depende del uso que la empresa dará al tipo, no es información de ARCA.

RN-005: Restricción de Desactivación por Uso

No se puede desactivar un tipo de comprobante si:

1. Existen comprobantes activos (facturas, notas, recibos) que lo utilizan
2. Hay transacciones pendientes que referencian el tipo
3. El sistema debe validar estas condiciones antes de permitir la desactivación
4. Mostrar mensaje específico indicando la cantidad de comprobantes que impiden la acción

Justificación: Evita inconsistencias y errores en comprobantes existentes.

RN-006: Soft Delete con Flag Activo

La desactivación de tipos de comprobantes:

1. No elimina el registro de la base de datos
2. Marca el campo activo como false
3. Los tipos inactivos no aparecen en selectores de usuario
4. Pueden reactivarse cambiando el flag a true
5. Se mantiene el histórico completo en el sistema

Justificación: Preserva integridad referencial y permite reactivación sin pérdida de datos.

---

Casos de Uso

CU-001: Crear Tipo de Comprobante desde ARCA

Actor: Administrador del sistema

Precondiciones:

• Usuario tiene permisos de "Crear tipos de comprobantes"
• API de ARCA está disponible y respondiendo

Flujo Principal:

1. Usuario accede a la vista de tipos de comprobantes
2. Usuario hace clic en el botón "Crear nuevo tipo"
3. Sistema muestra el formulario de alta
4. Sistema consulta la API de ARCA para obtener tipos de comprobantes
5. Sistema obtiene el catálogo completo de tipos disponibles en ARCA
6. Sistema consulta los tipos ya registrados en Formul
7. Sistema filtra el catálogo de ARCA removiendo los códigos ya existentes
8. Sistema muestra selector con tipos disponibles (no registrados)
9. Usuario selecciona un tipo del selector
10. Sistema autocompleta el campo "Código" con el código del tipo seleccionado (solo lectura)
11. Sistema autocompleta el campo "Nombre" con el nombre del tipo seleccionado (solo lectura)
12. Si el nombre excede 100 caracteres, sistema lo trunca automáticamente
13. Usuario selecciona la letra del comprobante (A, B, C o ALEY)
14. Usuario ingresa la abreviatura (máximo 10 caracteres)
15. Usuario selecciona la categoría (factura, nota-credito, nota-debito, recibo, liquidacion)
16. Usuario hace clic en "Guardar"
17. Sistema valida todos los datos ingresados
18. Sistema verifica que el código ARCA no esté duplicado (el código es único en el sistema)
19. Sistema guarda el nuevo tipo de comprobante con estado activo = true
20. Sistema muestra mensaje de éxito
21. Sistema retorna al listado mostrando el nuevo tipo

Postcondiciones:

• Nuevo tipo de comprobante registrado en Formul
• Tipo disponible para usar en generación de comprobantes de venta

Flujos Alternativos:

4a. Error de conexión con API de ARCA

• 4a.1. Sistema no puede conectarse a la API de ARCA
• 4a.2. Sistema muestra mensaje: "No se pudo conectar con ARCA. Verifique la conexión e intente nuevamente"
• 4a.3. Sistema muestra botón "Reintentar"
• 4a.4. Usuario hace clic en "Reintentar" → Volver al paso 4
• Nota: Revisar configuración y estado de la API de ARCA/AFIP

7a. Todos los tipos de ARCA ya están registrados

• 7a.1. El filtrado resulta en lista vacía (no hay tipos nuevos)
• 7a.2. Sistema muestra mensaje: "Todos los tipos de comprobante de ARCA ya están registrados en el sistema"
• 7a.3. Sistema deshabilita el selector de tipos
• 7a.4. Usuario puede cancelar y volver al listado

17a. Validación de código duplicado falla

• 17a.1. Ya existe un tipo con el mismo código ARCA (activo o inactivo)
• 17a.2. Sistema muestra error: "El código [X] ya está registrado"
• 17a.3. Usuario debe cancelar y verificar el listado

17b. Validación de campos obligatorios falla

• 17b.1. Falta completar letra, abreviatura o categoría
• 17b.2. Sistema muestra errores específicos por campo
• 17b.3. Usuario completa los campos faltantes → Volver al paso 16

En cualquier momento:

X.1. Usuario cancela la operación

• X.1.1. Usuario hace clic en "Cancelar"
• X.1.2. Sistema descarta los datos ingresados
• X.1.3. Sistema retorna al listado sin guardar

---

CU-002: Modificar Tipo de Comprobante

Actor: Administrador del sistema

Precondiciones:

• Usuario tiene permisos de "Modificar tipos de comprobantes"
• Tipo de comprobante existe en Formul

Flujo Principal:

1. Usuario accede al listado de tipos de comprobantes
2. Usuario identifica el tipo que desea modificar
3. Usuario hace clic en el botón "Modificar" de la fila correspondiente
4. Sistema muestra el formulario de edición con los datos actuales
5. Sistema muestra código y nombre como solo lectura (no editables)
6. Sistema permite editar: letra, abreviatura y categoría
7. Usuario modifica uno o más campos editables
8. Usuario hace clic en "Guardar cambios"
9. Sistema valida los nuevos valores
10. Sistema guarda las modificaciones
11. Sistema muestra mensaje de éxito
12. Sistema retorna al listado mostrando los datos actualizados

Postcondiciones:

• Tipo de comprobante actualizado
• Cambios reflejados inmediatamente en el sistema

Flujos Alternativos:

7a. Usuario intenta modificar código o nombre

• 7a.1. Sistema previene la edición (campos deshabilitados)
• 7a.2. Solo permite editar letra, abreviatura y categoría

En cualquier momento:

X.1. Usuario cancela la modificación

• X.1.1. Usuario hace clic en "Cancelar"
• X.1.2. Sistema descarta los cambios no guardados
• X.1.3. Sistema retorna al listado sin aplicar modificaciones

---

CU-003: Desactivar Tipo de Comprobante

Actor: Administrador del sistema

Precondiciones:

• Usuario tiene permisos de "Desactivar tipos de comprobantes"
• Tipo de comprobante existe y está activo
• Tipo NO tiene comprobantes asociados activos

Flujo Principal:

1. Usuario accede al listado de tipos de comprobantes
2. Usuario identifica el tipo que desea desactivar
3. Usuario hace clic en el botón "Desactivar" de la fila correspondiente
4. Sistema valida que el tipo no tenga comprobantes asociados activos
5. Sistema muestra modal de confirmación con:
   • Nombre del tipo a desactivar
   • Advertencia de que no estará disponible para nuevos comprobantes
   • Aclaración de que puede reactivarse posteriormente
6. Usuario lee la advertencia
7. Usuario hace clic en "Confirmar desactivación"
8. Sistema marca el registro con activo = false (soft delete)
9. Sistema muestra mensaje de éxito: "Tipo desactivado correctamente"
10. Sistema actualiza el listado mostrando el tipo como inactivo
11. Sistema cierra el modal

Postcondiciones:

• Tipo de comprobante marcado como inactivo
• Tipo no aparece en selectores de usuario para nuevos comprobantes
• Comprobantes existentes que usaban este tipo mantienen su integridad

Flujos Alternativos:

4a. Tipo tiene comprobantes asociados activos

• 4a.1. Sistema detecta facturas, notas o recibos activos usando este tipo
• 4a.2. Sistema muestra modal con error:
  • Mensaje: "No se puede desactivar este tipo de comprobante"
  • Razón: "Existen [X] comprobantes activos que lo utilizan"
  • Detalle: "Elimine o anule los comprobantes primero"
• 4a.3. Sistema muestra solo botón "Cerrar" (no permite confirmar)
• 4a.4. Usuario cierra el modal
• 4a.5. Tipo permanece activo

7a. Usuario cancela la desactivación

• 7a.1. Usuario hace clic en "Cancelar" en el modal
• 7a.2. Sistema cierra el modal sin realizar cambios
• 7a.3. Tipo permanece activo

Flujo de Reactivación (escenario adicional):

Cuando el tipo está inactivo:

1. Usuario hace clic en "Activar" en un tipo inactivo
2. Sistema cambia activo = true
3. Sistema muestra mensaje: "Tipo reactivado correctamente"
4. Tipo vuelve a estar disponible en selectores

---

CU-004: Listar y Filtrar Tipos de Comprobantes

Actor: Administrador del sistema

Precondiciones:

• Usuario tiene permisos de "Visualizar tipos de comprobantes"

Flujo Principal:

1. Usuario accede a la sección "Tipos de Comprobantes"
2. Sistema carga y muestra listado completo de tipos
3. Sistema muestra para cada tipo:
   • Código ARCA
   • Nombre
   • Letra (A/B/C/ALEY)
   • Abreviatura
   • Categoría (factura/nota-crédito/etc)
   • Estado (Activo/Inactivo)
   • Acciones (Modificar, Desactivar/Activar)
4. Sistema muestra panel de filtros con opciones:
   • Filtro por letra
   • Filtro por categoría
   • Filtro por estado
5. Usuario selecciona uno o más filtros
6. Sistema aplica filtros en tiempo real
7. Sistema actualiza el listado mostrando solo registros que cumplen los criterios
8. Sistema muestra cantidad de resultados
9. Usuario puede limpiar filtros para ver listado completo nuevamente

Postcondiciones:

• Usuario visualiza los tipos de comprobantes configurados
• Puede identificar rápidamente tipos por sus características
• Puede acceder a operaciones de modificación o desactivación

Flujos Alternativos:

2a. No hay tipos de comprobantes registrados

• 2a.1. Sistema muestra mensaje: "No hay tipos de comprobantes registrados"
• 2a.2. Sistema muestra botón "Crear primer tipo"
• 2a.3. Usuario puede crear el primer tipo → Ver CU-001

7a. Filtros no devuelven resultados

• 7a.1. Ningún tipo cumple con los criterios de filtrado
• 7a.2. Sistema muestra mensaje: "No se encontraron tipos con los filtros aplicados"
• 7a.3. Sistema sugiere limpiar filtros o ajustar criterios
• 7a.4. Usuario puede modificar filtros o limpiarlos

Opciones de Filtrado Detalladas:

Por Letra:

• Todas
• Solo A
• Solo B
• Solo C
• Solo ALEY

Por Categoría:

• Todas
• Factura
• Nota de Crédito
• Nota de Débito
• Recibo
• Liquidación

Por Estado:

• Todos
• Solo activos
• Solo inactivos

Ordenamiento:

• Por código (ascendente/descendente)
• Por nombre (alfabético A-Z / Z-A)
• Por letra
• Por categoría
• Por estado

---

Consideraciones

Seguridad

1. Control de Acceso:

   • Solo usuarios con rol de Administrador pueden acceder al ABM
   • Validar permisos específicos para cada operación (visualizar, crear, modificar, desactivar)
   • Registrar en logs de seguridad todas las operaciones realizadas

2. Protección de Datos Críticos:

   • Código y nombre provenientes de ARCA no deben ser editables
   • Prevenir inyección de código en campos de texto libre
   • Validar que los valores de enums (letra, categoría) provengan de listas predefinidas

3. Autenticación y Sesión:

   • Validar sesión activa antes de cada operación
   • Timeout de sesión debe aplicarse durante formularios largos
   • Revalidar permisos en cada acción (no solo en acceso a vista)

Rendimiento

1. Caché de Catálogo ARCA:

   • El listado de tipos de ARCA se cachea con TTL de 6 meses
   • Considerar botón de "Actualizar desde ARCA" para refrescar manualmente
   • Manejo de caché expirado: consultar ARCA automáticamente
   • Fallback a caché antiguo si ARCA no responde

2. Consultas al Listado:

   • Esperar listados con máximo 100-200 tipos de comprobantes
   • Filtros deben aplicarse en frontend (no requieren consulta al servidor)
   • Paginación solo necesaria si el listado supera 200 registros
   • Ordenamiento puede realizarse en frontend

3. Validaciones:

   • Validación de abreviatura única debe ser eficiente (índice en base de datos)
   • Validación de comprobantes asociados puede ser costosa: mostrar indicador de carga
   • Considerar caché de validaciones frecuentes

4. Tiempos de Respuesta Esperados:

   • Carga de listado: < 1 segundo
   • Consulta a ARCA (primera vez): 2-3 segundos
   • Consulta a ARCA (desde caché): < 500ms
   • Guardar nuevo tipo: < 1 segundo
   • Validación de desactivación: < 2 segundos (depende de cantidad de comprobantes)

Integración

1. Dependencia con API de ARCA:

   • Disponibilidad crítica para operación de alta de tipos
   • Manejo de errores: timeout, conexión rechazada, respuesta inválida
   • Considerar modo offline: mostrar últimos tipos cacheados con advertencia
   • Nota: Consultar documentación de la API de ARCA/AFIP para configuración y endpoints

2. Sincronización con ARCA:

   • No se realiza sincronización automática bidireccional
   • Formul mantiene su propia configuración basada en ARCA
   • Si ARCA depreca un código, Formul lo mantiene como inactivo
   • Responsabilidad del administrador mantener catálogo actualizado

3. Impacto en Otros Módulos:

   • Módulo de Ventas: consume tipos para generar facturas/notas/recibos
   • Proceso de Facturación Electrónica: usa código ARCA para enviar a AFIP
   • Reportes: agrupa por letra y categoría
   • Contabilidad: puede usar abreviatura en asientos

---

Dependencias

Dependencias de Negocio

1. Proceso de Facturación Electrónica Flexible

   • Documento: facturacion-electronica-flexible-process.md
   • Consume los tipos configurados en este ABM
   • Usa la combinación código + letra para determinar comprobante correcto
   • Dependencia bidireccional: el proceso requiere tipos configurados previamente

2. Módulo de Ventas

   • Usa tipos de comprobante para generar facturas, notas y recibos
   • Requiere que existan tipos activos configurados
   • Valida permisos según letra y categoría del comprobante

3. Condiciones de IVA

   • La letra del comprobante determina qué condiciones IVA son válidas
   • Integración: Responsable Inscripto → Facturas A/ALEY
   • Integración: Consumidor Final → Facturas B
   • Integración: Operaciones exentas → Facturas C

4. Sistema de Numeración

   • Cada tipo de comprobante mantiene su propia secuencia de numeración
   • La desactivación/reactivación no afecta el contador

Servicios Externos

1. AFIP/ARCA
   • Proveedor oficial del catálogo de tipos de comprobantes
   • Autoridad regulatoria que define códigos y nombres
   • Actualizaciones periódicas con nuevos tipos o depreciaciones

---

Criterios de Aceptación

Listado y Visualización

AC-001: El sistema debe mostrar un listado completo de tipos de comprobantes con las siguientes columnas visibles:

• Código ARCA (numérico)
• Nombre del tipo
• Letra del comprobante (A/B/C/ALEY)
• Abreviatura
• Categoría (factura/nota-crédito/nota-débito/recibo/liquidación)
• Estado (Activo/Inactivo)
• Acciones disponibles

AC-002: El usuario debe poder filtrar el listado por letra del comprobante, mostrando solo tipos que coincidan con: A, B, C, ALEY, o todas.

AC-003: El usuario debe poder filtrar el listado por categoría, mostrando solo tipos de: factura, nota-crédito, nota-débito, recibo, liquidación, o todas.

AC-004: El usuario debe poder filtrar el listado por estado, mostrando: solo activos, solo inactivos, o todos.

AC-005: Los filtros deben poder combinarse (letra + categoría + estado) para búsquedas más específicas.

Operación de Alta

AC-006: Al crear un nuevo tipo, el sistema debe consultar la API de ARCA para obtener el catálogo de tipos de comprobantes y mostrar solo los tipos que NO estén registrados en Formul (filtrado por código).

AC-007: Al seleccionar un tipo del catálogo de ARCA, el sistema debe autocompletar automáticamente:

• Campo "Código" con el código ARCA (solo lectura, no editable)
• Campo "Nombre" con el nombre oficial (solo lectura, no editable)

AC-008: Si el nombre proveniente de ARCA excede 100 caracteres, el sistema debe truncarlo automáticamente sin mostrar error al usuario.

AC-009: El sistema debe validar que el código ARCA no esté duplicado (ni en tipos activos ni inactivos).

AC-010: El sistema debe requerir que todos los campos estén completos antes de permitir guardar: código, nombre, letra, abreviatura, categoría.

AC-011: El selector de letra debe ofrecer únicamente las opciones: A, B, C, ALEY.

AC-012: El selector de categoría debe ofrecer únicamente las opciones: factura, nota-credito, nota-debito, recibo, liquidacion.

AC-013: Al guardar exitosamente, el sistema debe mostrar mensaje de confirmación y actualizar el listado mostrando el nuevo tipo como activo.

Operación de Modificación

AC-014: Al editar un tipo existente, el sistema NO debe permitir modificar:

• Código ARCA (solo lectura)
• Nombre (solo lectura)

AC-015: Al editar un tipo existente, el sistema SÍ debe permitir modificar:

• Letra del comprobante
• Abreviatura
• Categoría

AC-016: Al guardar modificaciones exitosamente, el sistema debe mostrar mensaje de confirmación y actualizar el listado con los nuevos valores.

Operación de Desactivación

AC-017: El sistema debe validar que el tipo NO tenga comprobantes asociados activos antes de permitir la desactivación.

AC-018: Si el tipo tiene comprobantes asociados, el sistema debe mostrar un mensaje de error específico indicando:

• Cantidad de comprobantes que impiden la desactivación
• Instrucción de eliminar o anular esos comprobantes primero

AC-019: Si el tipo no tiene comprobantes asociados, el sistema debe mostrar un modal de confirmación antes de desactivar.

AC-020: Al confirmar la desactivación, el sistema debe marcar el tipo como inactivo (soft delete, flag activo = false) sin eliminar el registro de la base de datos.

AC-021: Los tipos desactivados NO deben aparecer en selectores para crear nuevos comprobantes.

AC-022: El sistema debe permitir reactivar tipos previamente desactivados, cambiando su estado a activo nuevamente.

Seguridad y Permisos

AC-023: Solo usuarios con rol de Administrador deben poder acceder al ABM de tipos de comprobantes.

AC-024: El sistema debe validar el permiso VENTAS_BASES_TIPOS-COMPROBANTES para todas las operaciones del ABM (visualizar, crear, modificar, desactivar, reactivar).

Integración con ARCA

AC-025: Si hay error de conexión con ARCA al consultar el catálogo, el sistema debe:

• Mostrar mensaje de error claro
• Ofrecer opción de "Reintentar"
• No permitir continuar con la creación hasta obtener datos de ARCA

AC-026: Si todos los tipos de ARCA ya están registrados en Formul, el sistema debe mostrar mensaje informativo: "Todos los tipos de comprobante de ARCA ya están registrados en el sistema".

AC-027: El sistema debe usar el caché de tipos de ARCA (TTL 6 meses) para mejorar rendimiento en consultas frecuentes.

---

Notas Adicionales

Migración de Datos Existentes

Si ya existen tipos de comprobantes registrados manualmente en formul, considerar:

1. Validación de Consistencia:

   • Verificar que todos los códigos coincidan con catálogo oficial de ARCA
   • Identificar tipos con configuraciones inconsistentes
   • Reportar tipos con abreviaturas duplicadas en misma categoría

2. Limpieza de Datos:

   • Truncar nombres que excedan 100 caracteres
   • Normalizar valores de letra (A/B/C/ALEY)
   • Normalizar valores de categoría a los enums definidos
   • Marcar como inactivos tipos obsoletos o depreciados por AFIP

Extensibilidad Futura

El diseño de este ABM debe considerar posibles extensiones:

1. Nuevas Letras de Comprobante:

   • Actualmente: A, B, C, ALEY
   • Futuro cercano: 49 (tickets biométricos)
   • Futuro: X (exportación), E (electrónicos especiales)
   • El enum de letra debe ser fácilmente extensible

2. Nuevas Categorías:

   • Actualmente: factura, nota-credito, nota-debito, recibo, liquidacion
   • Futuro: remito, presupuesto, orden-compra
   • El enum de categoría debe permitir crecimiento

3. Configuraciones Adicionales:

   • Futura posibilidad de agregar: punto de venta asociado, formato de impresión, configuración de stock
   • El diseño debe permitir agregar campos sin romper funcionalidad existente

---

Integración con Informes

Contexto

Con la ampliación del rango de códigos ARCA (de 1-99 a 1-9999) para soportar el catálogo completo de AFIP, los tipos de comprobante ahora incluyen:

• Nombre completo que identifica específicamente cada tipo (ej: "Factura A", "Factura de Crédito Electrónica MiPyMEs A")
• Abreviatura para visualización compacta (ej: "FA", "FCE A")

Cambios Requeridos en Informes

Todos los informes que utilicen la tabla de tipos de comprobantes como relación deben refactorizarse para:

RN-INF-001: Uso Directo del Campo Nombre

Descripción: Los informes deben mostrar el nombre del tipo de comprobante tal como está almacenado en la tabla, sin concatenaciones ni modificaciones.

Situación Actual (Incorrecto):

• Se concatena nombre + letra: "Factura" + " " + "A" → "Factura A"
• Se construye el nombre dinámicamente combinando campos

Requerimiento (Correcto):

• Utilizar directamente el campo nombre de la tabla tipos_comprobante
• El nombre ya incluye la letra cuando corresponde (ej: "Factura A", "Nota de Crédito B")
• No realizar concatenaciones ni transformaciones del nombre

Impacto:

• Todos los informes que muestren nombres de tipos de comprobante
• Listados, reportes detallados, exportaciones

---

RN-INF-002: Uso Directo del Campo Abreviatura

Descripción: Los informes deben mostrar la abreviatura del tipo de comprobante tal como está almacenada en la tabla, sin concatenaciones ni modificaciones.

Situación Actual (Incorrecto):

• Se concatena abreviatura + letra: "Fac." + " " + "A" → "Fac. A"
• Se construye la abreviatura dinámicamente

Requerimiento (Correcto):

• Utilizar directamente el campo abbr de la tabla tipos_comprobante
• La abreviatura ya incluye la letra cuando corresponde (ej: "FA", "NCB")
• No realizar concatenaciones ni transformaciones de la abreviatura

Impacto:

• Listados compactos (subdiarios, planillas de caja, listados de comprobantes)
• Columnas con espacio limitado
• Exportaciones resumidas

---

Alcance de la Refactorización

Los siguientes informes deben actualizarse:

Informe	Campo Afectado	Acción Requerida
Subdiario de Ventas	Abreviatura	Usar campo abbr directo, sin concatenar letra
Histórico de Ventas	Nombre	Usar campo nombre directo, sin concatenar letra
Libro IVA	Nombre/Abreviatura	Usar campos directos de la tabla
Planilla de Caja	Abreviatura	Usar campo abbr directo
Listados de Comprobantes	Nombre/Abreviatura	Usar campos directos según contexto
Reportes Gerenciales	Nombre	Usar campo nombre directo

Criterios de Aceptación

AC-INF-001: Ningún informe concatena el nombre del tipo de comprobante con la letra. Se usa el campo nombre tal cual está en la base de datos.

AC-INF-002: Ningún informe concatena la abreviatura del tipo de comprobante con la letra. Se usa el campo abbr tal cual está en la base de datos.

AC-INF-003: Los informes mantienen consistencia: si el tipo se llama "Factura A" en la tabla, así aparece en todos los informes (no "Factura" ni "Factura + A" dinámicamente).

---

Documentación Relacionada:

• Proceso de facturación: facturacion-electronica-flexible-process.md