Documentación del Sistema

Appearance

Campo Manual en Comprobantes de Venta ​

Modulo: Ventas Tipo: Resource Estado: Implementado Fecha Creacion: 2025-12-23 Fecha Implementacion: 2025-12-29

Descripcion ​

Problema que resuelve ​

En el sistema de ventas, los comprobantes pueden originarse de dos formas diferentes:

  1. Generacion automatica: Comprobantes emitidos desde el sistema hacia ARCA (facturacion electronica), donde el sistema controla todo el proceso de emision.

  2. Registracion manual: Comprobantes que fueron emitidos fuera del sistema (por ejemplo, desde el portal de ARCA directamente) y luego se registran manualmente en el sistema para mantener la coherencia contable y de stock.

Actualmente no existe una forma clara de distinguir entre estos dos tipos de comprobantes una vez registrados en el sistema. Esta falta de distincion genera los siguientes problemas:

  • Dificultad para identificar comprobantes manuales: No se puede filtrar o buscar rapidamente los comprobantes que fueron registrados manualmente
  • Confusion en procesos de baja: No es evidente cuales comprobantes pueden ser candidatos para baja manual
  • Reportes imprecisos: No se puede generar reportes separados por origen del comprobante
  • Auditoria limitada: No se puede rastrear facilmente cuantos comprobantes fueron registrados manualmente en un periodo

Solucion propuesta ​

Se agrega un nuevo atributo manual a las entidades de comprobantes de venta (Factura, Nota de Credito, Nota de Debito). Este atributo es un indicador booleano que marca si el comprobante fue registrado manualmente o generado automaticamente por el sistema.

El campo:

  • Se establece automaticamente en true cuando el comprobante se carga a traves del proceso de registracion manual
  • Se establece en false (valor por defecto) cuando el comprobante se genera a traves del proceso normal de facturacion electronica
  • Es de solo lectura una vez establecido (no se puede modificar posteriormente)
  • Permite filtrar y consultar comprobantes por su origen

Valor de negocio ​

  • Trazabilidad de origen: Permite conocer el origen de cada comprobante de forma inequivoca
  • Facilitacion de procesos: El proceso de baja de comprobantes manuales puede filtrar directamente por este campo
  • Reportes diferenciados: Se pueden generar estadisticas y reportes separados por tipo de origen
  • Control operativo: Permite a supervisores monitorear el volumen de registraciones manuales vs automaticas
  • Auditoria mejorada: Facilita el seguimiento y control de comprobantes ingresados manualmente

Entidades Afectadas ​

El campo manual se agrega a las siguientes entidades de comprobantes de venta:

Factura ​

La entidad principal de facturacion.

DatoDescripcion
Campomanual
TipoBooleano (verdadero/falso)
Valor por defectoFalso
ObligatorioSi (no puede ser nulo)
ModificableNo (se establece al momento de la creacion)

Nota de Credito ​

Comprobante de credito a favor del cliente.

DatoDescripcion
Campomanual
TipoBooleano (verdadero/falso)
Valor por defectoFalso
ObligatorioSi (no puede ser nulo)
ModificableNo (se establece al momento de la creacion)

Nota de Debito ​

Comprobante de debito contra el cliente.

DatoDescripcion
Campomanual
TipoBooleano (verdadero/falso)
Valor por defectoFalso
ObligatorioSi (no puede ser nulo)
ModificableNo (se establece al momento de la creacion)

Reglas de Negocio ​

RN-001: Valor por defecto ​

Descripcion: El campo manual tiene como valor por defecto falso, indicando que por defecto los comprobantes se consideran generados automaticamente.

Condicion: Se crea un nuevo comprobante sin especificar el valor del campo.

Accion: El sistema asigna automaticamente el valor falso.

Fundamento: La mayoria de los comprobantes se generan a traves del proceso normal de facturacion electronica, por lo que el valor por defecto refleja el caso mas comun.

RN-002: Establecimiento en registracion manual ​

Descripcion: Cuando un comprobante se registra a traves del proceso de registracion manual, el campo manual debe establecerse en verdadero.

Condicion: El usuario registra un comprobante utilizando la funcionalidad de registracion manual de ventas.

Accion: El sistema establece automaticamente el campo manual en verdadero.

Fundamento: Permite identificar de forma automatica todos los comprobantes que ingresaron al sistema a traves del proceso de registracion manual.

RN-003: Establecimiento en facturacion electronica ​

Descripcion: Cuando un comprobante se genera a traves del proceso de facturacion electronica (emision normal), el campo manual debe establecerse en falso.

Condicion: El sistema genera y emite un comprobante a traves del proceso de facturacion electronica hacia ARCA.

Accion: El sistema establece el campo manual en falso (o lo deja con su valor por defecto).

Fundamento: Estos comprobantes fueron generados y controlados completamente por el sistema, a diferencia de los registrados manualmente.

RN-004: Inmutabilidad del campo ​

Descripcion: Una vez establecido el valor del campo manual, este no puede ser modificado.

Condicion: El comprobante ya fue creado y tiene un valor asignado en el campo manual.

Accion:

  • Si se intenta modificar el campo: el sistema rechaza la operacion
  • El campo no debe estar disponible para edicion en ninguna interfaz

Fundamento: El origen de un comprobante es un dato historico que no debe alterarse, ya que afectaria la integridad de los registros y la trazabilidad.

RN-005: Uso en consultas y filtros ​

Descripcion: El campo manual puede utilizarse como criterio de filtrado en consultas de comprobantes.

Condicion: El usuario o el sistema necesita consultar comprobantes por su origen.

Accion: El sistema permite filtrar por:

  • Solo comprobantes manuales (manual = verdadero)
  • Solo comprobantes automaticos (manual = falso)
  • Todos los comprobantes (sin filtro por origen)

Fundamento: Permite segmentar las consultas segun las necesidades del usuario o proceso.

Casos de Uso ​

CU-001: Registracion manual de comprobante ​

Actor: Usuario de Ventas

Objetivo: Registrar un comprobante emitido fuera del sistema

Precondiciones:

  • Usuario autenticado con permiso de registracion manual
  • Datos del comprobante disponibles

Flujo principal:

  1. El usuario accede al modulo de registracion manual de ventas
  2. El usuario ingresa los datos del comprobante (tipo, numero, cliente, items, etc.)
  3. El usuario confirma el registro
  4. El sistema crea el comprobante con el campo manual = verdadero
  5. El sistema muestra mensaje de exito

Postcondiciones:

  • El comprobante queda registrado con el indicador de origen manual activado
  • El comprobante aparece en consultas filtradas por comprobantes manuales

CU-002: Emision de comprobante electronico ​

Actor: Sistema / Usuario de Ventas

Objetivo: Emitir un comprobante a traves del proceso de facturacion electronica

Precondiciones:

  • Usuario autenticado con permiso de facturacion
  • Conexion con ARCA disponible

Flujo principal:

  1. El usuario o proceso inicia la emision de un comprobante
  2. El sistema genera el comprobante y lo envia a ARCA
  3. ARCA retorna el CAE (codigo de autorizacion electronica)
  4. El sistema crea el comprobante con el campo manual = falso
  5. El sistema muestra/retorna el comprobante autorizado

Postcondiciones:

  • El comprobante queda registrado con el indicador de origen automatico
  • El comprobante NO aparece en consultas filtradas por comprobantes manuales

CU-003: Consulta de comprobantes manuales ​

Actor: Usuario de Ventas / Administrador

Objetivo: Obtener listado de comprobantes registrados manualmente

Precondiciones:

  • Usuario autenticado con permiso de consulta de comprobantes

Flujo principal:

  1. El usuario accede a la consulta de comprobantes
  2. El usuario aplica el filtro "Solo manuales" o equivalente
  3. El sistema retorna unicamente los comprobantes con manual = verdadero
  4. El usuario visualiza los resultados

Postcondiciones:

  • El usuario obtiene el listado filtrado por origen manual

CU-004: Busqueda para baja de comprobantes manuales ​

Actor: Usuario de Ventas / Administrador

Objetivo: Buscar comprobantes manuales candidatos para dar de baja

Precondiciones:

  • Usuario autenticado con permiso de baja de comprobantes
  • Existen comprobantes registrados manualmente

Flujo principal:

  1. El usuario accede al proceso de baja de comprobantes manuales
  2. El usuario solicita ver todos los comprobantes manuales (sin buscar por numero especifico)
  3. El sistema consulta todos los comprobantes con manual = verdadero
  4. El sistema muestra el listado de comprobantes manuales disponibles para baja
  5. El usuario selecciona el comprobante deseado

Postcondiciones:

  • El usuario puede proceder con el proceso de baja del comprobante seleccionado

Relaciones con otras funcionalidades ​

Registracion Manual de Ventas ​

El proceso de registracion manual es el principal consumidor de este campo, ya que es el encargado de establecer manual = verdadero al crear los comprobantes.

Relacion: El campo manual se establece durante la creacion del comprobante en este proceso.

Baja de Comprobantes Manuales ​

El proceso de baja utiliza este campo para:

  • Identificar rapidamente los comprobantes elegibles para baja (solo los manuales)
  • Ofrecer una opcion de busqueda que muestre todos los comprobantes manuales

Relacion: El campo manual se usa como criterio de filtrado en la busqueda.

Reportes de Ventas ​

Los reportes pueden segmentarse por origen del comprobante, permitiendo analisis diferenciados.

Relacion: El campo manual se usa como criterio de agrupacion o filtrado en reportes.

Auditoria ​

El campo contribuye a la trazabilidad al indicar como ingreso el comprobante al sistema.

Relacion: El campo manual se incluye en la informacion de auditoria del comprobante.

Diagrama de Entidades ​

mermaid
erDiagram
    FACTURA {
        int id
        string numero
        date fecha
        decimal total
        boolean manual "Indicador de origen"
    }
    CREDITO {
        int id
        string numero
        date fecha
        decimal total
        boolean manual "Indicador de origen"
    }
    DEBITO {
        int id
        string numero
        date fecha
        decimal total
        boolean manual "Indicador de origen"
    }

    FACTURA ||--o{ CREDITO : "puede tener"
    FACTURA ||--o{ DEBITO : "puede tener"

Consideraciones ​

Migracion de datos existentes ​

Para los comprobantes existentes en el sistema (creados antes de la implementacion de este campo):

  • Comprobantes sin CAE: Se deben analizar y potencialmente marcar como manuales
  • Comprobantes con CAE: Se consideran automaticos (generados por el sistema)
  • Criterio alternativo: Evaluar si existe otro atributo que permita determinar el origen

Integridad de datos ​

  • El campo no debe permitir valores nulos para evitar ambiguedades
  • El valor por defecto asegura que todos los comprobantes tengan un valor valido
  • La inmutabilidad del campo garantiza la consistencia historica

Impacto en consultas existentes ​

  • Las consultas existentes no se ven afectadas (el filtro por manual es opcional)
  • Se deben crear nuevas opciones de filtrado donde sea relevante
  • Los indices deben considerar este campo para consultas frecuentes

Criterios de Aceptacion ​

La funcionalidad se considera completa cuando:

  • [x] AC-001: El campo manual existe en las entidades factura, credito y debito
  • [x] AC-002: El campo tiene valor por defecto falso
  • [x] AC-003: El campo no permite valores nulos
  • [x] AC-004: Al registrar un comprobante manualmente, el campo se establece en verdadero automaticamente
  • [x] AC-005: Al emitir un comprobante electronico, el campo se establece en falso
  • [x] AC-006: El campo no es modificable despues de la creacion del comprobante (implementado mediante arquitectura - no hay endpoints de actualizacion)
  • [x] AC-007: Se puede filtrar comprobantes por el valor del campo manual
  • [x] AC-008: El proceso de baja de comprobantes manuales puede usar este campo para buscar comprobantes

Historial de cambios ​

FechaVersionAutorDescripcion
2025-12-231.0SistemaCreacion del documento de requerimientos
2025-12-291.1SistemaImplementacion completa del requerimiento. Se agregaron: migraciones de base de datos (factura, credito, debito), campo en DTOs, mapeo en modelos, logica en servicios para establecer automaticamente el valor, capacidad de filtrado en consultas getAll(), y suite completa de tests unitarios.