Documentación del Sistema

Appearance

Normalización de Identificadores de Tipo de Comprobante ​

Módulo: Compras Tipo: Process Estado: Planificado Fecha: 2026-01-07

Descripción ​

Problema que resuelve ​

Actualmente, el sistema utiliza códigos de ARCA (códigos numéricos fiscales externos) como identificadores internos para relacionar documentos de compra con sus tipos de comprobante. Este enfoque genera los siguientes problemas de negocio:

  1. Falta de control interno: Los identificadores dependen de códigos externos (ARCA), limitando la flexibilidad del sistema
  2. Riesgo de inconsistencias: Sin validación automática, pueden existir documentos con tipos de comprobante inexistentes
  3. Datos huérfanos: Documentos pueden quedar sin un tipo de comprobante válido si se eliminan o modifican códigos
  4. Dificultad de auditoría: No hay forma de rastrear cambios en los tipos de comprobante asociados a documentos

Solución propuesta ​

Implementar un sistema de identificación interno que separe claramente:

  • Identificador interno del sistema: Único para cada tipo de comprobante, usado para todas las relaciones
  • Código ARCA: Código fiscal reutilizable, múltiples tipos pueden compartir el mismo código

Flexibilidad de negocio: El sistema permitirá que los usuarios creen tipos de comprobante personalizados que referencien a códigos ARCA estándar:

  • Ejemplo 1: "Factura A" y "Factura A Manual" pueden compartir el código ARCA 1
  • Ejemplo 2: "Detalle Bancario" puede referenciar al código ARCA 2 (Nota de Débito)
  • Ejemplo 3: "Servicios Públicos" puede referenciar al código ARCA 6 (Factura B)

Al reportar a AFIP, todos los tipos con el mismo código ARCA se agrupan bajo ese código fiscal.

Garantías del sistema:

  • Todos los documentos de compra tengan un tipo de comprobante válido
  • Los tipos de comprobante no puedan eliminarse si están en uso
  • Los usuarios puedan personalizar su catálogo de tipos
  • Múltiples tipos puedan compartir el mismo código ARCA
  • Los códigos ARCA se usen exclusivamente en reportes a AFIP (libro IVA)
  • Se pueda auditar completamente el uso de tipos de comprobante

Valor de negocio ​

  • Integridad de datos: Eliminación de documentos huérfanos o con tipos inválidos
  • Flexibilidad operativa: Usuarios pueden crear tipos personalizados según sus necesidades
  • Personalización: Cada empresa puede nombrar y organizar sus tipos de comprobante
  • Agrupación fiscal: Múltiples tipos internos se reportan bajo el mismo código ARCA
  • Trazabilidad: Control completo sobre tipos de comprobante en uso
  • Reducción de errores: Validación automática al crear documentos de compra
  • Mejora en auditoría: Rastreo de todos los tipos usados históricamente

Ejemplo práctico: Una empresa puede tener:

  • "Factura Proveedores Nacionales" → Código ARCA 1
  • "Factura Importación" → Código ARCA 1
  • "Detalle Bancario" → Código ARCA 2 (reporta como Nota de Débito)
  • "Cargo Servicios" → Código ARCA 2 (reporta como Nota de Débito)

Internamente son 4 tipos diferentes, pero en el libro IVA se agrupan en 2 códigos ARCA.

Contexto del sistema ​

Esta normalización afecta a:

  • Documentos de compra: Facturas, notas de crédito, notas de débito registradas
  • Cuenta corriente de proveedores: Movimientos asociados a comprobantes de compra
  • Libro IVA de compras: Reporte fiscal que utiliza códigos ARCA
  • Datos históricos: Todos los documentos existentes deben migrarse

Proceso de Negocio ​

Situación actual (problemática) ​

mermaid
flowchart LR
    A[Usuario registra<br/>comprobante de compra] --> B{Sistema valida<br/>código ARCA?}
    B -->|NO| C[Se guarda con<br/>código sin validar]
    C --> D[RIESGO: Código puede<br/>no existir en catálogo]
    D --> E[Documento huérfano<br/>o inconsistente]

Problemas identificados:

  1. No hay validación de que el código ARCA exista en el catálogo
  2. Pueden existir documentos con códigos incorrectos
  3. No hay control sobre eliminación de tipos de comprobante
  4. Dificulta identificar qué documentos usan cada tipo

Situación objetivo (normalizada) ​

mermaid
flowchart LR
    A[Usuario registra<br/>comprobante de compra] --> B[Sistema valida<br/>identificador interno]
    B -->|Existe| C[Se guarda con<br/>identificador validado]
    B -->|No existe| D[Sistema rechaza<br/>con mensaje de error]
    C --> E[Documento con<br/>tipo garantizado]
    E --> F[En reporte ARCA:<br/>se traduce a código fiscal]

Mejoras:

  1. Validación automática de tipo de comprobante al registrar documento
  2. Imposibilidad de crear documentos con tipos inválidos
  3. Control de eliminación (tipo en uso no se puede eliminar)
  4. Identificación rápida de documentos por tipo

Reglas de Negocio ​

RN-001: Separación de identificadores ​

Descripción: El sistema debe diferenciar claramente entre el identificador interno y el código fiscal (ARCA).

Aplicación:

  • Identificador interno: Se usa para relacionar documentos de compra, cuenta corriente y otros módulos
  • Código ARCA: Se usa únicamente en el reporte de libro IVA para AFIP

Fundamento: El identificador interno es controlado por el sistema, mientras que el código ARCA es impuesto externamente por AFIP y puede variar.

RN-002: Validación obligatoria al registrar comprobantes ​

Descripción: Todo documento de compra debe tener un tipo de comprobante válido antes de ser guardado.

Condición: Usuario intenta registrar una factura, nota de crédito o nota de débito de compra.

Acción:

  • El sistema verifica que el tipo de comprobante seleccionado existe en el catálogo
  • Si el tipo es válido: permite guardar el documento
  • Si el tipo no existe: rechaza la operación y muestra mensaje de error

Mensaje de error: "El tipo de comprobante seleccionado no es válido. Por favor, seleccione un tipo válido del catálogo."

Fundamento: Previene la creación de documentos huérfanos o con tipos inexistentes.

RN-003: Protección de tipos de comprobante en uso ​

Descripción: No se puede eliminar un tipo de comprobante si existen documentos que lo utilizan.

Condición: Usuario o administrador intenta eliminar un tipo de comprobante del catálogo.

Acción:

  • El sistema verifica si existen documentos de compra asociados a ese tipo
  • Si existen documentos: rechaza la eliminación y muestra la cantidad de documentos afectados
  • Si no existen documentos: permite la eliminación

Mensaje de error: "No se puede eliminar el tipo de comprobante '[nombre]'. Existen [cantidad] documentos de compra que lo utilizan."

Fundamento: Protege la integridad de datos históricos y evita documentos huérfanos.

RN-004: Traducción automática a código ARCA en reportes ​

Descripción: Al generar el libro IVA de compras, el sistema debe traducir automáticamente el identificador interno al código ARCA correspondiente.

Condición: Usuario solicita generar el libro IVA digital de compras para presentar a AFIP.

Acción:

  • El sistema obtiene el código ARCA de cada tipo de comprobante
  • Formatea el código con 3 dígitos (001, 006, 011, etc.)
  • Incluye el código en el archivo de texto plano según formato ARCA

Fundamento: AFIP requiere códigos específicos en el libro IVA, pero internamente el sistema usa sus propios identificadores.

RN-005: Independencia por sucursal (multi-tenant) ​

Descripción: Cada sucursal/caja tiene su propio catálogo de tipos de comprobante independiente.

Condición: Sistema multi-tenant con múltiples sucursales o cajas.

Acción:

  • Cada sucursal mantiene su propio catálogo de tipos de comprobante
  • Los identificadores internos pueden ser diferentes entre sucursales para el mismo código ARCA
  • Las validaciones se realizan contra el catálogo de la sucursal actual

Ejemplo:

  • Sucursal 001: "Factura A" tiene identificador interno 5, código ARCA 1
  • Sucursal 002: "Factura A" tiene identificador interno 7, código ARCA 1
  • Ambos son válidos en su respectivo contexto

Fundamento: Permite que cada sucursal personalice su catálogo sin afectar a otras.

RN-006: Migración de datos históricos ​

Descripción: Al implementar la normalización, todos los documentos históricos deben convertirse al nuevo sistema de identificación.

Condición: Activación del nuevo sistema de identificación.

Acción:

  • Identificar todos los documentos de compra existentes
  • Convertir código ARCA a identificador interno mediante tabla de correspondencia
  • Validar que todos los documentos quedaron correctamente migrados
  • No permitir documentos sin identificador interno válido

Validación post-migración:

  • Todos los documentos tienen identificador interno
  • Todos los identificadores internos existen en el catálogo
  • No hay pérdida de datos

Fundamento: Garantiza consistencia entre datos históricos y nuevos.

RN-007: Códigos ARCA no son únicos (clave para personalización) ​

Descripción: El código ARCA es reutilizable, permitiendo que los usuarios creen múltiples tipos de comprobante que referencien al mismo código fiscal.

Condición: Administrador o usuario con permisos crea un nuevo tipo de comprobante.

Acción:

  • El sistema permite múltiples tipos de comprobante con el mismo código ARCA
  • El identificador interno sí debe ser único (generado automáticamente por el sistema)
  • En el libro IVA, todos los tipos con el mismo código ARCA se agrupan y reportan bajo ese código
  • El usuario asigna un nombre descriptivo que refleja el propósito interno

Ejemplos de uso real:

  1. Facturaciones diferenciadas:

    • "Factura Proveedor Nacional" → código ARCA: 1
    • "Factura Importación" → código ARCA: 1
    • "Factura Manual" → código ARCA: 1
    • En libro IVA: Todas aparecen como código 001 (Factura A)

  2. Comprobantes bancarios:

    • "Detalle Bancario" → código ARCA: 2 (Nota de Débito)
    • "Cargo Bancario" → código ARCA: 2 (Nota de Débito)
    • En libro IVA: Ambos aparecen como código 002 (ND)

  3. Servicios públicos:

    • "Factura Luz" → código ARCA: 6 (Factura B)
    • "Factura Gas" → código ARCA: 6 (Factura B)
    • "Factura Agua" → código ARCA: 6 (Factura B)
    • En libro IVA: Todas aparecen como código 006 (Factura B)

Beneficio: Cada empresa puede organizar su catálogo según su operatoria, sin perder compatibilidad fiscal.

Fundamento: Permite flexibilidad operativa interna mientras se mantiene compatibilidad total con AFIP.

RN-008: Creación de tipos de comprobante personalizados ​

Descripción: Los usuarios con permisos pueden crear nuevos tipos de comprobante en su catálogo, asignando un código ARCA de referencia.

Condición: Administrador del catálogo necesita crear un tipo personalizado.

Acción:

  1. Usuario accede a la gestión de tipos de comprobante
  2. Usuario crea nuevo tipo con:
    • Nombre descriptivo (ej: "Detalle Bancario")
    • Código ARCA de referencia (ej: 2 = Nota de Débito)
    • Tipo de operación (Débito/Crédito)
  3. Sistema valida que el nombre no esté duplicado en el catálogo actual
  4. Sistema guarda el nuevo tipo con identificador único
  5. El nuevo tipo está disponible para usar en documentos de compra

Ejemplo de flujo:

Usuario crea:
  Nombre: "Detalle Bancario"
  Código ARCA: 2 (Nota de Débito)
  Tipo: Débito

Sistema genera:
  ID interno: 25 (único, generado automáticamente)

Al registrar documentos:
  Usuario selecciona "Detalle Bancario" (ID=25)

Al generar libro IVA:
  "Detalle Bancario" se reporta con código 002 (Nota de Débito)

Validaciones:

  • El nombre debe ser único dentro del catálogo de la sucursal
  • El código ARCA debe ser un código fiscal válido (1-13, etc.)
  • No se puede crear un tipo con identificador interno duplicado (el sistema lo genera)

Fundamento: Permite adaptar el sistema a las necesidades específicas de cada empresa sin perder trazabilidad ni compatibilidad fiscal.

Casos de Uso ​

CU-001: Creación de tipo de comprobante personalizado ​

Actor: Administrador del Sistema / Usuario con permisos de gestión de catálogos

Objetivo: Crear un tipo de comprobante personalizado que referencie a un código ARCA estándar

Precondiciones:

  • Usuario autenticado con permiso de gestión de catálogo de tipos
  • Conoce los códigos ARCA disponibles (1=Factura A, 2=ND, 6=Factura B, etc.)

Flujo principal:

  1. Administrador accede al módulo de gestión de tipos de comprobante
  2. Administrador selecciona "Crear nuevo tipo"
  3. Administrador completa el formulario:
    • Nombre: "Detalle Bancario"
    • Descripción: "Cargos y débitos bancarios"
    • Código ARCA de referencia: 2 (Nota de Débito)
    • Tipo de operación: Débito
  4. Sistema valida que "Detalle Bancario" no existe en el catálogo
  5. Sistema genera ID interno único (ej: 25)
  6. Sistema guarda el nuevo tipo
  7. Sistema muestra confirmación: "Tipo de comprobante 'Detalle Bancario' creado exitosamente"
  8. El nuevo tipo aparece disponible en los selectores de registro de compras

Postcondiciones:

  • Nuevo tipo disponible en el catálogo de la sucursal
  • Usuarios pueden seleccionar "Detalle Bancario" al registrar comprobantes
  • Al generar libro IVA, documentos de "Detalle Bancario" se reportarán con código 002
  • El tipo queda auditado con usuario creador y fecha

Flujo alternativo - Nombre duplicado:

  • En paso 4, sistema detecta que "Detalle Bancario" ya existe
  • Sistema muestra error: "Ya existe un tipo con el nombre 'Detalle Bancario'"
  • Usuario debe elegir otro nombre o modificar el existente

CU-002: Registro de comprobante con tipo personalizado ​

Actor: Usuario de Compras

Objetivo: Registrar un detalle bancario usando el tipo personalizado

Precondiciones:

  • Usuario autenticado con permiso de registro de compras
  • Existe el tipo "Detalle Bancario" en el catálogo (ID=25, código ARCA=2)

Flujo principal:

  1. Usuario accede al módulo de registro de compras
  2. Usuario selecciona tipo de comprobante: "Detalle Bancario"
  3. Usuario completa datos (proveedor=Banco, fecha, importe)
  4. Sistema valida que ID 25 existe en el catálogo
  5. Usuario confirma el registro
  6. Sistema guarda documento con tipo_comprobante=25
  7. Sistema muestra confirmación

Postcondiciones:

  • Documento guardado con referencia a ID 25 ("Detalle Bancario")
  • Al consultar, se muestra como "Detalle Bancario" (nombre interno)
  • Al generar libro IVA, se reportará con código 002 (Nota de Débito ARCA)

CU-003: Generación de libro IVA con tipos personalizados ​

Actor: Usuario de Contabilidad

Objetivo: Generar libro IVA donde múltiples tipos internos se agrupan por código ARCA

Precondiciones:

  • Existen documentos con tipos personalizados
  • Ejemplos en el sistema:
    • "Factura Nacional" (ID=5, código ARCA=1)
    • "Factura Importación" (ID=8, código ARCA=1)
    • "Nota de Débito" (ID=10, código ARCA=2)
    • "Detalle Bancario" (ID=25, código ARCA=2)

Flujo principal:

  1. Usuario solicita libro IVA del mes
  2. Sistema obtiene todos los documentos del período
  3. Sistema traduce cada ID interno a su código ARCA:
    • Documentos con ID 5 y 8 → código 001
    • Documentos con ID 10 y 25 → código 002
  4. Sistema genera archivo con códigos ARCA:
    Línea 1: ... 001 ... (Factura Nacional)
Línea 2: ... 001 ... (Factura Importación)
Línea 3: ... 002 ... (Nota de Débito)
Línea 4: ... 002 ... (Detalle Bancario)
  5. Usuario descarga archivo para AFIP

Postcondiciones:

  • Archivo generado con códigos ARCA correctos
  • AFIP agrupa automáticamente por código (001, 002, etc.)
  • La personalización interna es transparente para AFIP

Ventaja demostrada:

  • Internamente se diferencian 4 tipos de comprobante
  • Externamente se reportan 2 códigos ARCA
  • Mejor trazabilidad sin perder compatibilidad fiscal

CU-004: Registro de comprobante con validación exitosa ​

Actor: Usuario de Compras

Objetivo: Registrar una factura de compra con tipo de comprobante válido

Precondiciones:

  • Usuario autenticado con permiso de registro de compras
  • Existen tipos de comprobante en el catálogo de la sucursal actual

Flujo principal:

  1. Usuario accede al módulo de registro de compras
  2. Usuario completa datos del comprobante (proveedor, fecha, importe)
  3. Usuario selecciona tipo de comprobante del selector (ejemplo: "Factura A")
  4. Sistema valida que el tipo seleccionado existe en el catálogo
  5. Usuario confirma el registro
  6. Sistema guarda el documento con el identificador interno del tipo
  7. Sistema muestra mensaje: "Comprobante registrado exitosamente"

Postcondiciones:

  • Documento de compra guardado con tipo de comprobante válido
  • Movimiento de cuenta corriente generado (si aplica)
  • Auditoría registrada con el tipo de comprobante usado

CU-005: Intento de registro con tipo inválido (caso de error) ​

Actor: Usuario de Compras

Objetivo: Intentar registrar un comprobante con tipo inexistente

Precondiciones:

  • Usuario autenticado con permiso de registro de compras
  • Existe un error de datos o manipulación incorrecta del formulario

Flujo principal:

  1. Usuario accede al módulo de registro de compras
  2. Por algún error, se envía un identificador de tipo inválido
  3. Sistema valida el tipo de comprobante
  4. Sistema detecta que el tipo no existe en el catálogo
  5. Sistema rechaza la operación
  6. Sistema muestra mensaje de error: "El tipo de comprobante seleccionado no es válido"
  7. Usuario debe corregir el tipo antes de intentar nuevamente

Postcondiciones:

  • No se crea ningún documento
  • No se generan movimientos relacionados
  • Se registra el intento fallido en auditoría

Flujo alternativo - Solución:

  • Usuario selecciona un tipo válido del selector
  • Reintenta el registro con el tipo correcto

CU-006: Consulta diferenciada por tipo personalizado ​

Actor: Usuario de Compras / Analista

Objetivo: Filtrar documentos de un tipo personalizado específico

Precondiciones:

  • Existen documentos con diferentes tipos que comparten código ARCA
  • Ejemplos:
    • 50 "Factura Nacional" (ID=5, código ARCA=1)
    • 30 "Factura Importación" (ID=8, código ARCA=1)

Flujo principal:

  1. Usuario accede a consulta de comprobantes
  2. Usuario aplica filtro: Tipo = "Factura Importación"
  3. Sistema busca por ID interno 8
  4. Sistema retorna exactamente 30 documentos de "Factura Importación"
  5. Usuario obtiene reporte preciso

Postcondiciones:

  • El filtrado es exacto (solo "Factura Importación", no "Factura Nacional")
  • A pesar de compartir código ARCA 1, se diferencian internamente

Ventaja vs sistema anterior:

  • Antes (por código ARCA): Buscar código 1 retorna 80 documentos mezclados
  • Ahora (por ID interno): Buscar ID 8 retorna 30 documentos exactos

CU-007: Generación de libro IVA de compras ​

Actor: Usuario de Contabilidad / Administración

Objetivo: Generar el archivo de libro IVA digital para presentar a AFIP

Precondiciones:

  • Usuario autenticado con permiso de generación de reportes fiscales
  • Existen comprobantes de compra registrados en el período solicitado
  • Todos los comprobantes tienen tipo de comprobante válido

Flujo principal:

  1. Usuario accede al módulo de libro IVA de compras
  2. Usuario selecciona período (mes y año)
  3. Usuario solicita generar archivo digital
  4. Sistema obtiene todos los comprobantes del período
  5. Para cada comprobante, sistema traduce identificador interno a código ARCA
  6. Sistema formatea el código ARCA con 3 dígitos (001, 006, 011, etc.)
  7. Sistema genera archivo de texto plano según formato ARCA/AFIP
  8. Usuario descarga el archivo para presentar a AFIP

Postcondiciones:

  • Archivo generado con códigos ARCA correctos
  • El archivo es compatible con el validador de AFIP
  • Auditoría registra la generación del reporte

Resultado esperado del archivo:

Cada línea contiene:
- Fecha
- Tipo comprobante (3 dígitos): 001 (traducido desde identificador interno)
- Punto de venta
- Número
- ...otros campos...

CU-008: Intento de eliminar tipo de comprobante en uso ​

Actor: Administrador del Sistema

Objetivo: Intentar eliminar un tipo de comprobante que está siendo usado

Precondiciones:

  • Usuario con permiso de administración de catálogos
  • Existen documentos de compra con el tipo a eliminar

Flujo principal:

  1. Administrador accede al catálogo de tipos de comprobante
  2. Administrador selecciona un tipo para eliminar (ejemplo: "Factura B")
  3. Sistema verifica si existen documentos con ese tipo
  4. Sistema encuentra 150 documentos que usan ese tipo
  5. Sistema rechaza la eliminación
  6. Sistema muestra mensaje: "No se puede eliminar 'Factura B'. Existen 150 documentos de compra que lo utilizan."

Postcondiciones:

  • El tipo de comprobante permanece en el catálogo
  • No se afectan los documentos existentes

Flujo alternativo - Tipo sin uso:

  • Si no existen documentos con ese tipo
  • Sistema permite la eliminación
  • Sistema muestra confirmación antes de eliminar
  • Administrador confirma y el tipo es eliminado

CU-009: Modificación de tipo de comprobante personalizado ​

Actor: Administrador del Sistema

Objetivo: Cambiar el nombre o descripción de un tipo personalizado sin afectar documentos existentes

Precondiciones:

  • Existe tipo "Detalle Bancario" (ID=25, código ARCA=2)
  • Existen 100 documentos usando este tipo

Flujo principal:

  1. Administrador accede al catálogo de tipos
  2. Administrador selecciona "Detalle Bancario" para editar
  3. Administrador modifica nombre a "Cargo Bancario"
  4. Administrador mantiene código ARCA 2
  5. Sistema valida que el nuevo nombre no esté duplicado
  6. Sistema actualiza el tipo (ID 25 sigue siendo 25)
  7. Sistema muestra confirmación

Postcondiciones:

  • El tipo ahora se llama "Cargo Bancario"
  • Los 100 documentos existentes siguen referenciando al mismo ID (25)
  • Al consultarlos, ahora aparecen como "Cargo Bancario"
  • El código ARCA (2) no cambió, por lo que el libro IVA se mantiene igual
  • El cambio queda auditado

Restricción:

  • NO se puede cambiar el código ARCA si el tipo está en uso (impactaría libro IVA histórico)
  • Solo se permite cambiar nombre y descripción

CU-010: Consulta de documentos por tipo de comprobante ​

Actor: Usuario de Compras / Administrador

Objetivo: Obtener listado de todos los documentos de un tipo específico

Precondiciones:

  • Usuario con permiso de consulta de compras
  • Existen documentos de compra registrados

Flujo principal:

  1. Usuario accede al módulo de consulta de compras
  2. Usuario aplica filtro por tipo de comprobante (ejemplo: "Factura A")
  3. Sistema busca todos los documentos con ese identificador interno de tipo
  4. Sistema muestra listado con:
    • Número de comprobante
    • Proveedor
    • Fecha
    • Importe
    • Estado
  5. Usuario puede exportar, ver detalles o realizar otras acciones

Postcondiciones:

  • Usuario obtiene información precisa de documentos por tipo
  • El filtrado es rápido y exacto (usa identificador interno)

Ventaja del nuevo sistema:

  • Antes: Búsqueda por código ARCA (múltiples tipos con mismo código)
  • Ahora: Búsqueda por identificador único (resultado preciso)

Consideraciones ​

Seguridad ​

Control de acceso:

  • Solo usuarios autorizados pueden registrar comprobantes de compra
  • Solo administradores pueden gestionar el catálogo de tipos de comprobante
  • Las validaciones de tipo son obligatorias y no pueden omitirse

Auditoría:

  • Toda operación de registro de comprobante se audita con el tipo usado
  • Cambios en el catálogo de tipos se registran (creación, modificación, intento de eliminación)
  • La migración de datos históricos se registra completamente

Operación ​

Transparencia para el usuario:

  • El cambio es transparente en el uso diario
  • Los selectores de tipo de comprobante siguen mostrando los mismos nombres
  • Los reportes a AFIP continúan con los mismos códigos

Ventana de mantenimiento:

  • La migración de datos históricos requiere una ventana de mantenimiento
  • Durante la migración, no se pueden registrar nuevos comprobantes de compra
  • Tiempo estimado: depende del volumen de documentos (generalmente < 30 minutos)

Datos ​

Backup obligatorio:

  • Realizar backup completo antes de la migración
  • Mantener backup por al menos 90 días post-migración
  • Plan de rollback disponible en caso de problemas

Validación post-migración:

  • Verificar que todos los documentos fueron migrados
  • Comprobar que no existen documentos huérfanos
  • Validar generación de libro IVA con datos migrados

Dependencias ​

Funcionalidades relacionadas ​

  • Registro de comprobantes de compra: Funcionalidad principal que se mejora con esta normalización
  • Libro IVA de compras: Debe adaptarse para traducir identificadores a códigos ARCA
  • Cuenta corriente de proveedores: Usa tipos de comprobante en movimientos
  • Reportes de compras: Deben filtrar por identificador interno

Módulos del sistema ​

  • Compras: Módulo principal afectado
  • Cuenta Corriente: Movimientos de proveedores
  • Contabilidad: Generación de libro IVA

Sistemas externos ​

  • AFIP (ARCA): Destino final de los códigos fiscales en el libro IVA digital

Criterios de Aceptación ​

La normalización se considera completa cuando:

Validaciones de negocio:

  • [ ] AC-001: Al registrar un comprobante, el sistema valida que el tipo existe en el catálogo
  • [ ] AC-002: No es posible crear un documento con tipo de comprobante inválido
  • [ ] AC-003: El sistema rechaza con mensaje claro cuando el tipo no es válido
  • [ ] AC-004: No es posible eliminar un tipo de comprobante que está en uso
  • [ ] AC-005: El mensaje de error indica la cantidad de documentos que usan el tipo

Funcionalidad de reportes:

  • [ ] AC-006: El libro IVA de compras se genera correctamente con códigos ARCA
  • [ ] AC-007: Los códigos ARCA en el libro tienen formato de 3 dígitos (001, 006, etc.)
  • [ ] AC-008: El archivo generado es validado exitosamente por el sistema de AFIP

Migración de datos:

  • [ ] AC-009: Todos los documentos históricos tienen identificador interno válido
  • [ ] AC-010: No existen documentos huérfanos o con tipos inexistentes
  • [ ] AC-011: La cantidad de documentos pre-migración y post-migración coincide

Operación multi-tenant:

  • [ ] AC-012: Cada sucursal/caja valida contra su propio catálogo
  • [ ] AC-013: Una sucursal no puede usar tipos de comprobante de otra sucursal
  • [ ] AC-014: Las migraciones se ejecutan correctamente en todas las sucursales

Auditoría:

  • [ ] AC-015: Todas las operaciones de registro quedan auditadas con el tipo usado
  • [ ] AC-016: Los cambios en el catálogo quedan registrados en auditoría
  • [ ] AC-017: La migración de datos históricos queda completamente documentada

Transparencia:

  • [ ] AC-018: Los usuarios no perciben cambios en su operación diaria
  • [ ] AC-019: Los selectores de tipo de comprobante funcionan igual que antes
  • [ ] AC-020: Los reportes existentes siguen funcionando correctamente

Notas Adicionales ​

Impacto en usuarios ​

Usuarios finales (Compras):

  • Sin cambios en la interfaz de usuario
  • Validaciones automáticas mejoran la calidad de datos
  • Menor probabilidad de errores en registros

Administradores:

  • Nueva validación al intentar eliminar tipos de comprobante
  • Control mejorado sobre el catálogo
  • Facilidad para identificar tipos en uso

Contabilidad:

  • Generación de libro IVA sin cambios visibles
  • Mayor confianza en la integridad de los códigos reportados

Comunicación de la implementación ​

Antes de la implementación:

  1. Comunicar ventana de mantenimiento a todos los usuarios
  2. Explicar que habrá una pausa breve en registro de compras
  3. Solicitar que finalicen registros pendientes antes de la ventana

Durante la implementación:

  1. Ejecutar migración de datos en ventana programada
  2. Validar resultado de la migración
  3. Verificar generación de libro IVA con datos migrados

Después de la implementación:

  1. Comunicar finalización exitosa
  2. Monitorear primeros días de operación
  3. Estar disponible para consultas de usuarios

Próximos pasos ​

  1. Aprobación de negocio: Validar que las reglas de negocio son correctas
  2. Planificación técnica: Definir detalles de implementación (consultar documento técnico)
  3. Testing en staging: Validar migración con datos reales en ambiente de prueba
  4. Capacitación: Briefing a administradores sobre la nueva validación de eliminación
  5. Implementación en producción: Ejecutar en ventana de mantenimiento programada
  6. Monitoreo post-implementación: Seguimiento por 30 días

Documentación técnica de implementación: Para detalles técnicos sobre cómo implementar esta normalización, consultar: docs/backend/tipo-comprobante-implementacion-tecnica.md

Historial de Cambios ​

FechaVersiónAutorDescripción
2026-01-071.0SistemaCreación del documento de requerimientos de negocio
2026-01-072.0SistemaSeparación de reglas de negocio y detalles técnicos (técnicos movidos a docs/backend/)