Portales clientes‑proveedores y tus sistemas

En tu día a día, la falta de integración entre el portal de clientes y los sistemas que ya utilizas genera retrabajo, errores y pérdida de tiempo. En este artículo verás paso a paso cómo conectar esos portales con tu ERP, tu contabilidad y los medios de pago sin romper la arquitectura existente.

Con qué se tiene que hablar

Antes de diseñar cualquier nuevo portal, haz un inventario de los sistemas que ya están operando en tu empresa:

• ERP o sistema de gestión: ya sea un módulo de compras, ventas o inventario que haya sido desarrollado a medida o adquirido comercialmente.
• Contabilidad y facturación: software que lleva los libros y genera los asientos.
• Plataformas de mensajería y CRM: WhatsApp Business, HubSpot, Zoho, etc.
• Herramientas de reporting: Power BI, Tableau o soluciones locales.

Estos sistemas no se van a tirar; al contrario, el portal debe consumir sus datos mediante APIs o web services. El primer paso es validar que cada aplicación cuente con una capa de integración: endpoints REST, SOAP o, en su defecto, acceso a base de datos mediante vistas protegidas. Si alguna herramienta solo exporta archivos CSV, planifica una rutina de importación automática que se ejecute cada 15 min para evitar desfasajes.

SUNAT y facturación electrónica

En Perú, la normativa de SUNAT obliga a que toda factura electrónica sea enviada en tiempo real o, como máximo, dentro de los 48 horas posteriores a la emisión. Los portales deben cumplir con estos requisitos para que tus clientes y proveedores vean documentos válidos.

1. Formato UBL 2.1: la mayoría de los sistemas de facturación a medida ya generan XML conforme a este estándar. El portal debe incluir un módulo que tome ese XML y lo envíe a la API de SUNAT.
2. Certificado digital: cada empresa necesita su certificado .pfx para firmar los documentos. El proceso de carga y renovación del certificado debe estar automatizado; de lo contrario, el portal fallará cada vez que expire.
3. Respuesta de SUNAT: la API devuelve un código de aceptación o rechazo. Implementa una lógica de reintento en caso de error transitorio (p.ej., 5 xx) y registra el estado en tu base de datos para que el cliente pueda consultar el historial.
4. Errores típicos:
   • RUC incorrecto en el XML.
   • Timestamp fuera de rango.
   • Firma digital mal configurada.

Corrigiendo estos puntos, el portal se vuelve una extensión natural de tu proceso de facturación, sin necesidad de duplicar información.

Cobros y bancos

Los métodos de pago locales como Yape, Plin, Niubiz e Izipay ofrecen APIs públicas, pero su integración varía mucho. Aquí tienes la forma práctica de conectarlos al portal:

• Yape y Plin: ambas plataformas usan webhooks. Configura un endpoint seguro (HTTPS, certificado válido) que reciba la notificación de pago y actualice el estado del pedido en tu ERP. El tiempo de confirmación suele ser de 1‑3 segundos.
• Niubiz: dispone de un gateway REST que permite iniciar la transacción y recibir el token de autorización. La integración típica lleva 2 semanas de desarrollo, incluyendo pruebas de conciliación.
• Izipay: combina webhook y polling. Se recomienda usar el webhook para la confirmación inmediata y el polling como respaldo cada 5 min.

Para evitar sorpresas, define en el contrato con el proveedor de la API los SLA de disponibilidad (mínimo 99,5 % mensual) y los códigos de error que deberás manejar. Cuando el banco cambia su versión de API, tu portal debe poder adaptarse sin romper la experiencia del usuario; por eso, mantén una capa de abstracción que traduzca los cambios internos.

Qué pedirle al proveedor

Si el portal va a consumir servicios externos, la claridad en la documentación es clave. Pregunta por:

• Especificación de endpoints: URL, método HTTP, parámetros obligatorios y opcionales.
• Formato de respuesta: JSON, XML o ambos. Asegúrate de que los nombres de campos coincidan con los que usa tu ERP.
• Versionado: ¿Cómo anuncian una nueva versión? Idealmente con al menos 30 días de antelación.
• Límites de consumo: número máximo de llamadas por segundo. Si el portal espera picos de 200 req/s, el proveedor debe ofrecer un plan que lo soporte.
• Mecanismo de autenticación: token JWT, OAuth 2.0 o API‑Key. Implementa la renovación automática del token para que el portal no se quede sin acceso.
• Pruebas de sandbox: un entorno de pruebas idéntico al productivo permite validar la integración antes del go‑live.

Cuando el proveedor cambie su API, tu arquitectura debe permitir actualizar solo la capa de adaptador, sin tocar la lógica de negocio del portal. Esa separación reduce el riesgo de interrupciones y acelera los despliegues.

Conclusión

Quien ha llegado hasta aquí entiende que la integración no es un proyecto aparte, sino una extensión natural de los sistemas que ya usas. Identificar los componentes existentes, cumplir con los requisitos de SUNAT, conectar los medios de pago locales y exigir una documentación robusta al proveedor son los pasos concretos que garantizan que tu portal de clientes y proveedores funcione como una sola pieza. Con una planificación realista –entre 4 y 6 semanas para la mayor parte de las integraciones‑ tu empresa podrá ofrecer una experiencia digital fluida sin sacrificar la infraestructura ya probada.

Una integración bien diseñada convierte al portal en una ventana única a todos tus sistemas internos.