Volver a la arquitectura

Servicios externos

Conexiones con terceros

De las tres integraciones que necesitaría un negocio así, hoy hay una simulada (SUNAT) y ninguna real. Pagos y envíos se registran a mano en la intranet, sin llamar a ninguna API externa.

SUNAT (comprobantes electrónicos) — simulado

Al registrar un comprobante, el backend encola la tarea emitir_comprobante_sunat (Celery). Esa tarea construye un JSON tipo UBL con el detalle del pedido, pero no llama a ningún servicio de SUNAT real: genera un XML/CDR de relleno, marca los eventos generado→enviado→aceptado en secuencia, y da por buena la emisión siempre. Es un stub declarado explícitamente así en el propio código (comentario TODO: enviar a SUNAT y recibir el CDR — cliente real, p. ej. greenter/SUNAT SOAP). Hoy ninguna boleta o factura emitida desde este sistema es legalmente válida.

Pagos — sin pasarela

No hay ninguna pasarela de pago conectada (ni tarjetas, ni Yape/Plin por API). El modelo Pago registra método, monto y estado, pero es registro manual: alguien del equipo anota que un cliente pagó (con su comprobante/voucher como referencia) y, aparte, confirma el pago desde Facturación. No hay token de tarjeta, no hay webhook de confirmación, no hay integración PCI que gestionar porque no se procesa ninguna tarjeta.

Envíos — sin courier conectado

envio_cliente.courier y tracking son texto libre: quien despacha escribe "Olva Courier" y el código a mano. No hay API de ninguna empresa de courier, no se generan guías automáticamente, no hay webhooks de cambio de estado.

Correo — solo un caso, vía SMTP simple

El único correo que el sistema envía es el aviso de "tu cuenta ha sido aprobada" (equipo), usando send_mail de Django contra el SMTP configurado por variables de entorno (con fallback a la consola si no hay SMTP). No hay confirmaciones de compra, avisos de envío, ni SendGrid/SES — ni falta un servicio dedicado para ese único caso.

Qué implicaría conectar cada una de verdad

SUNAT real: un cliente (p. ej. greenter, o el SDK de un OSE/PSE) que firme el XML con certificado digital y llame al servicio SOAP/REST de SUNAT, sustituyendo el contenido de emitir_comprobante_sunat.
Pasarela de pagos: requiere cumplimiento PCI (o delegarlo en el proveedor vía tokenización), credenciales de comercio, y un webhook que reciba la confirmación asíncrona.
Courier: credenciales de API del courier elegido, generación de guía al confirmar el envío, y un webhook o polling para actualizar estado automáticamente.

Esta es la brecha más importante entre "lo que parece un ERP completo" y "lo que hay construido": el flujo de venta funciona de punta a punta dentro del sistema, pero la parte que toca al mundo exterior (facturar de verdad, cobrar de verdad, despachar con seguimiento real) todavía es manual o simulada. Detalle de la tarea SUNAT en Tareas automáticas.