Un portal de proveedores conectado al ERP es una web privada donde cada proveedor ve sus pedidos, confirma fechas, sube albaranes y facturas y mantiene vigente su documentación, contra los datos que ya viven en tu ERP. Saca el correo del circuito y deja traza. Lo montamos en el desarrollo de portales conectados al ERP.
Hoy ese circuito se sostiene con mensajes. Compras manda el pedido en PDF, el proveedor contesta una fecha en el cuerpo del correo, el albarán llega escaneado y la factura por otro hilo. Cuando algo no cuadra, alguien rebusca en una bandeja de hace tres semanas y pregunta por teléfono.
Al terminar sabrás qué parte abres primero y qué blindar antes del primer acceso. El mismo planteamiento mirando al otro lado está en el portal de clientes que mira al otro extremo.
Qué es un portal de proveedores conectado al ERP
Es una aplicación web con usuarios externos donde cada proveedor opera solo sobre sus propios registros: pedidos, confirmaciones de fecha, albaranes, facturas y documentos de empresa. El ERP sigue siendo el sistema de registro, y el portal lee y escribe contra él por integración, sin copia paralela que acabe desviándose.
El aislamiento entre proveedores es la pieza crítica
Un portal de proveedores es multiinquilino desde el primer día. Dos empresas que compiten entran por la misma URL, y un filtro mal puesto deja ver precios y volúmenes del otro. OWASP sitúa el control de acceso roto como primer riesgo de su Top 10 y da dos indicaciones que aplican tal cual: denegar por defecto salvo en recursos públicos, y que el modelo imponga la propiedad del registro en vez de aceptar que el usuario lea cualquiera, según el control de acceso roto del Top 10 de OWASP.
Ese filtro no puede vivir en la interfaz ni depender de un identificador que viaja en la URL. Va en la base de datos, donde ninguna pantalla nueva puede olvidarlo.
El ciclo pedido, confirmación, albarán, entrega y factura
El portal gana valor cuando cubre el ciclo entero. El proveedor recibe el pedido, confirma o propone otra fecha, genera el albarán contra las líneas de ese pedido, marca la entrega y emite la factura. Cada paso referencia el anterior, así que la factura nace atada a un pedido y a un albarán concretos.
Ese encadenamiento permite cotejar sin trabajo manual: el cotejo a tres bandas compara lo pedido, lo recibido y lo facturado en cantidad, precio y referencia, y solo levanta la mano cuando hay diferencia. La parte de pedidos la trata el software de gestión de pedidos a medida, y la documental la automatización de presupuestos, contratos y facturas en web.
Alta del proveedor y documentos con fecha de caducidad
- Datos fiscales: los valida compras una vez y el proveedor no los reescribe sin pasar por revisión.
- Certificados y seguros: cada documento lleva su caducidad en el modelo de datos, no en un recordatorio de calendario.
- Cuentas bancarias: cambio con doble verificación, porque es el campo que persigue el fraude del correo.
- Contactos y roles: el proveedor gestiona sus usuarios, con un responsable que responde de ellos.
- Estado: activo, bloqueado o pendiente de documentación, y el bloqueo impide emitirle pedidos.
Quien administra eso desde dentro necesita su vista, como la de el panel desde el que compras revisa lo pendiente.
Quién manda sobre cada dato
La regla que evita la mayoría de los conflictos es sencilla: cada dato tiene un dueño y los demás sistemas lo copian. El maestro de proveedores y el pedido mandan desde el ERP. La confirmación de fecha, el albarán y los documentos nacen en el portal y suben. El estado de pago vuelve del ERP al portal y el proveedor deja de llamar para preguntarlo.
Cómo viaja ese ida y vuelta decide el resto: cuándo conviene una cola de mensajes y cuándo una llamada directa cambia el portal un martes a las nueve. Si el ERP no se toca, la vía es el middleware que evita reescribirlo.
CodeZone Pro Tip: pon el filtro por proveedor en políticas de fila de la base de datos, no en la consulta de cada pantalla, para que una vista nueva no pueda filtrar datos de otro proveedor aunque el programador olvide el WHERE.
-- El portal autentica, fija el id del proveedor en una variable de
-- sesion y trabaja con un rol sin privilegios de propietario.
ALTER TABLE pedido_compra ENABLE ROW LEVEL SECURITY;
ALTER TABLE pedido_compra FORCE ROW LEVEL SECURITY;
-- Sin politica no se ve ninguna fila: Postgres deniega por defecto.
CREATE POLICY pedido_propio ON pedido_compra
FOR SELECT TO portal_proveedor
USING (proveedor_id = current_setting('app.proveedor_id')::bigint);
-- Las lineas llevan los precios, asi que repiten la regla por su
-- cuenta: un join mal escrito no basta para sacarlas.
ALTER TABLE pedido_compra_linea ENABLE ROW LEVEL SECURITY;
CREATE POLICY linea_propia ON pedido_compra_linea
FOR SELECT TO portal_proveedor
USING (EXISTS (
SELECT 1 FROM pedido_compra p
WHERE p.id = pedido_compra_linea.pedido_id
AND p.proveedor_id = current_setting('app.proveedor_id')::bigint
));
-- WITH CHECK valida la fila que se escribe: el albaran solo entra
-- si el proveedor que lo sube es el del pedido que referencia.
ALTER TABLE albaran ENABLE ROW LEVEL SECURITY;
CREATE POLICY albaran_alta ON albaran
FOR INSERT TO portal_proveedor
WITH CHECK (proveedor_id = current_setting('app.proveedor_id')::bigint);Con el filtro ahí abajo, el aislamiento deja de depender de la disciplina del equipo: la propia OWASP recuerda que el permiso se valida en cada petición, venga de donde venga, en su guía de autorización. Añadir una pantalla nueva ya no abre un agujero.
Lo que Cuesta Abrir un Portal Sin Aislar los Datos
El fallo caro de un portal de proveedores no es que se caiga, es que enseñe. Un proveedor que ve el precio de su competidor cambia su próxima oferta y te deja un incidente que hay que explicar y documentar.
Empieza acotado: pedidos y confirmación de fecha, con dos o tres proveedores. Cuando eso corre, abres albaranes y después facturas. El encaje con lo que ya tienes se decide igual que en cómo se conectan los sistemas de una empresa en Madrid, y la parte comercial del mismo tablero la cubre la extranet con tarifas por cliente. Las aprobaciones que ocurren antes de que exista el pedido van en la cadena que valida cada compra.
Si el circuito con tus proveedores hoy vive en el correo, revisamos por dónde conviene empezar.
