Saltar al contenido principal

RF66: Usuario ingresa facturas

Descripción

Como usuario autenticado, quiero subir mis facturas electrónicas (CFDI) para que el sistema las analice y las considere en mi declaración anual.

El usuario sube el XML del CFDI (y opcionalmente el PDF). El archivo se guarda en S3 privado y dispara el análisis (RF64). Los datos fiscales son personales y se almacenan cifrados.

CampoValor
MóduloAccounting Module
ActorUsuario autenticado
EndpointPOST /accounting/invoices (sube CFDI)
PrecondicionesSesión activa; idealmente RFC registrado (RF13)
PrioridadBaja (post-MVP)
EtapaPor definirse
Requisitos relacionadosRF13, RF64, RF63, RF40

Reglas de negocio

  • RN-66.1 — Formato aceptado: XML CFDI (PDF opcional como adjunto). Tamaño máximo por archivo definido.
  • RN-66.2 — El XML se valida (estructura CFDI) antes de aceptarlo; los inválidos se rechazan con motivo.
  • RN-66.3 — Se deduplica por UUID/folio fiscal: una factura ya ingresada no se duplica.
  • RN-66.4 — Los archivos se guardan en S3 privado; los datos extraídos se cifran en reposo.
  • RN-66.5 — Al ingresar, se dispara el análisis (RF64).

Validaciones de entrada

CampoReglasMensaje de error
fileObligatorio. XML CFDI válido. ≤ tamaño máx."Sube un archivo XML (CFDI) válido."
pdfOpcional. PDF. ≤ tamaño máx."El PDF no es válido o excede el tamaño."
AuthorizationBearer válido."Sesión no válida." (401)

Se valida el tipo MIME real y el esquema del CFDI; no se aceptan archivos ejecutables ni payloads maliciosos (XXE deshabilitado en el parser XML).

Criterios de aceptación

Escenario 1: Ingreso de factura exitoso

Dado que subo un XML CFDI válido, Cuando lo ingreso, Entonces el sistema lo guarda en S3 privado, Y dispara el análisis (RF64), Y responde 201 Created.

Escenario 2: Archivo no es un CFDI válido

Dado que subo un XML que no cumple el esquema CFDI, Cuando lo ingreso, Entonces el sistema lo rechaza con 400 y el motivo.

Escenario 3: Factura duplicada (idempotencia)

Dado que subo un CFDI con un folio fiscal ya ingresado, Cuando lo ingreso, Entonces el sistema no lo duplica e informa que ya existe.

Escenario 4: Archivo malicioso (seguridad)

Dado que subo un XML con entidades externas (XXE) o un ejecutable disfrazado, Cuando el backend lo procesa, Entonces el parser rechaza/neutraliza el contenido (XXE deshabilitado) y no lo ejecuta.

Criterios no funcionales

  • Parser XML seguro (sin resolución de entidades externas).
  • Archivos en S3 privado; datos extraídos cifrados; comunicación TLS 1.2+.

Diagrama de secuencia