FacturaSend — middleware fiscal para emisión de Documento Electrónico Paraguay
El FacturaSend es el intermediario técnico que conecta el Quaza al SET/SIFEN.
Qué es FacturaSend
El FacturaSend es el intermediario técnico entre Quaza y la SET (Subsecretaría de Estado de Tributación - Paraguay). Cuando emite una factura electrónica en Paraguay, Quaza envía los datos a FacturaSend, que firma digitalmente, transmite a la SET y devuelve el XML aprobado.
FacturaSend está para Paraguay como SEFAZ Virtual está para Brasil — middleware fiscal.
Cómo funciona la integración
Quaza ↔ FacturaSend ↔ SET. Quaza envía JSON, FacturaSend convierte a XML/SET, transmite, devuelve respuesta + CDC.
| Etapa |
Quién hace |
| Cliente compra |
Quaza registra contrato |
| Genera factura |
Quaza |
| Envía JSON |
Quaza → FacturaSend |
| Firma + transmite |
FacturaSend |
| Valida + autoriza/rechaza |
SET |
| Devuelve resultado |
SET → FacturaSend → Quaza |
| Guarda CDC + libera PDF |
Quaza |
Glosario
| Término |
Significado |
| FacturaSend |
Intermediario fiscal para Paraguay. |
| SET |
Subsecretaría de Estado de Tributación. |
| SIFEN |
Sistema Integrado de Facturación Electrónica Nacional. |
| CDC |
Código de Control — equivalente a la clave de acceso NFe. |
| DE |
Documento Electrónico. |
| RUC |
Registro Único de Contribuyentes. |
| KuDE |
Representación visual del DE. |
| Token CSC |
Credencial de autenticación. |
| Timbrado |
Número de autorización de emisión. |
Flujo de envío
FACTURA ELECTRÓNICA PARAGUAY — FLUJO
─────────────────────────────────────
1. Quaza monta JSON de la factura
│
▼
2. POST → FacturaSend API (REST)
│
▼
3. FacturaSend: valida + firma XML + envía a la SET
│
▼
4. SET responde
┌────────┴────────┐
▼ ▼
Aprobado Rechazado
(CDC + XML) (motivo)
│ │
▼ ▼
5. Quaza guarda CDC Quaza marca error
│ │
▼ ▼
6. Genera KuDE PDF Operador corrige
7. Envía al cliente y reemite
Documentos soportados
- Factura electrónica (modelo 01)
- Autofactura (modelo 02)
- Nota de crédito (modelo 05)
- Nota de débito (modelo 06)
- Nota de remisión (modelo 07)
- Comprobante de retención (modelo 04)
Trampas frecuentes
1. Token CSC expirado.
2. RUC del cliente equivocado.
3. Numeración de timbrado agotando.
4. KuDE no enviado al cliente.
5. Cancelamiento fuera del plazo. SET acepta CDC dentro de 48h.
Preguntas frecuentes
¿Quaza emite directo en SET sin FacturaSend?
No — FacturaSend es obligatorio.
¿Costo de FacturaSend?
Por documento o plan mensual.
¿Puedo emitir teste antes de producción?
Sí — modo teste no consume timbrado.
¿Multi-empresa funciona?
Sí — cada una con token CSC aislado.
¿Documento rechazado: cómo ver motivo?
FacturaSend retorna código de error + descripción.
Ambientes y testes
FacturaSend opera en dos ambientes claramente separados:
| Ambiente |
Para qué |
Consecuencias |
| Sandbox / Teste |
Validar integración, probar errores |
No consume timbrado. SET no recibe. |
| Producción |
Emisiones reales |
Consume timbrado real. SET archiva. |
Antes de migrar a producción: (1) emitir 5-10 DEs de teste exitosos, (2) validar XML, (3) verificar KuDE renderizado, (4) testar cancelamiento de CDC.
Cada ambiente tiene token CSC propio. NUNCA mezcle.
Buenas prácticas operacionales
Esta sección reúne hábitos que proveedores experimentados adoptan para evitar problemas recurrentes en este módulo. Aplicación consistente hace diferencia grande en el largo plazo — diferencia entre operación caótica y operación previsible.
Revisión periódica
Reserve 30 minutos por semana para revisar el estado del módulo: lo que corrió, lo que falló, lo que quedó pendiente. Anomalía detectada temprano cuesta 10× menos que descubierta tarde.
Documentación de procedimientos
Cree checklists internos para operaciones recurrentes — apertura/cierre del mes, procesamiento en lote, corrección de inconsistencias. No dependa de quien "sabe de memoria" — funcionario puede salir, enfermar, tener día malo.
Backup antes de operaciones masivas
Cualquier cambio que afecte 100+ registros debe ser precedido de backup o export. Restaurar una alteración masiva equivocada es caro; prevenir es simple.
Comunicación con cliente
Cambios que impactan al cliente (precio, cobranza, regla) deben comunicarse con antelación. Cliente sorprendido reclama; cliente avisado entiende.
Indicadores acompañados
Defina 2-3 indicadores que miden la salud del módulo. Acompañe semanalmente. Cuando alguno sale del rango esperado, investigue antes de volverse problema visible.
Checklist operacional
Use este checklist como referencia rápida para garantizar que el módulo está siendo operado correctamente:
-
Configuración inicial validada — todos los campos obligatorios completados, permisos atribuidos, integraciones testadas
-
Equipo entrenado — al menos dos operadores saben operar; redundancia previene paralización
-
Procedimiento documentado — paso a paso de operaciones recurrentes disponible en lugar accesible
-
Backups al día — backup automático corriendo, último restore testado en los últimos 90 días
-
Monitoreo activo — alertas configuradas para fallas críticas, logs siendo revisados semanalmente
-
Plan de contingencia — si el módulo cae, equipo sabe cómo operar manualmente hasta volver
-
Auditoría periódica — revisión mensual de inconsistencias; trimestral de eficiencia operacional
-
Documentación de cambios — alteraciones relevantes registradas (fecha, autor, motivo, impacto)
Indicadores típicos a acompañar
Cada proveedor define sus propios KPIs, pero algunos son casi universales para este tipo de operación:
- Volumen mensual procesado (registros, transacciones, eventos)
- Tasa de error (% de operaciones que fallaron)
- Tiempo medio de respuesta/procesamiento
- Cobertura (% de la cartera atendida por el módulo)
- Satisfacción operacional (feedback del equipo que usa)
Compare valores actuales con media de los últimos 3 meses. Variación mayor que 20% en cualquier dirección merece investigación — puede ser mejora sostenible o degradación silenciosa.
Documentos relacionados