html = r»’
Tu equipo de compras puede tener un buen ERP y seguir perdiendo horas respondiendo preguntas que el proveedor debería poder resolver solo.
Business Central puede gobernar proveedores, compras, pedidos, recepciones, facturas y pagos. Pero eso no significa que un proveedor externo deba trabajar dentro del ERP. Cuando no existe una capa de interacción externa, una parte de la relación acaba trasladándose al correo, al teléfono, a archivos adjuntos y a consultas manuales.
“¿Habéis recibido la factura?”, “¿falta algún documento?”, “¿cuándo se paga?”, “¿me podéis reenviar el pedido?”
Cada consulta puede parecer pequeña. El problema aparece cuando cientos de proveedores hacen preguntas similares durante todo el año y alguien de compras, administración o cuentas a pagar tiene que buscar la información, comprobarla y responder manualmente.
La organización termina utilizando personas como interfaz entre el proveedor y los sistemas corporativos.
Digitalizar compras no consiste únicamente en digitalizar al comprador.
También significa mejorar cómo proveedores, colaboradores y terceros participan en el proceso.
Cuatro síntomas de que la relación con proveedores sigue funcionando fuera del sistema.
No hace falta implantar un portal porque Power Pages exista. Tiene sentido cuando existe una fricción repetitiva, medible y suficientemente importante como para justificar una experiencia externa conectada.
Correo como bandeja de entrada del proceso
Facturas, certificados, altas, incidencias, cambios bancarios, documentación y preguntas llegan a buzones diferentes y requieren clasificación manual.
Consultas repetitivas
El proveedor pregunta por información que la empresa ya tiene en sus sistemas: pedidos, recepciones, incidencias, documentación o estados de proceso.
Datos reintroducidos
El proveedor rellena un documento, alguien recibe el archivo y otra persona vuelve a introducir parte de esa información en Business Central o en otra aplicación.
Falta de trazabilidad
Cuando una incidencia se gestiona por correos y llamadas es difícil saber qué se pidió, quién respondió, qué documentación falta y cuánto tiempo lleva abierto el proceso.
¿Qué debería poder hacer realmente un proveedor?
No se trata de replicar Business Central en una web. El portal debe seleccionar aquellas interacciones externas que aportan autoservicio, reducen carga administrativa y mantienen el proceso conectado con el back office.
Solicitar datos una vez y convertirlos en un proceso trazable.
Información fiscal, contactos, certificados, documentación legal, condiciones, homologaciones o cambios determinados pueden recogerse mediante formularios estructurados, validarse y someterse a aprobación antes de impactar en los sistemas internos.
Que el proveedor pueda consultar aquello que realmente necesita.
Un portal puede facilitar acceso controlado a información relacionada con pedidos, referencias, entregas o documentos asociados sin obligar al proveedor a solicitarla cada vez por correo.
Saber qué ha ocurrido sin perseguir a administración.
Cuando el escenario lo permita, el proveedor puede disponer de una experiencia para aportar información, identificar incidencias, consultar estados o conocer qué acción necesita realizar para que el proceso continúe.
Convertir una consulta en un proceso con propietario y estado.
En lugar de recibir un correo imposible de seguir, una solicitud puede crear un registro, aplicar validaciones, asignarse, activar una automatización y ofrecer posteriormente al proveedor información sobre su evolución.
El objetivo no es mostrar más datos. Es evitar interacciones que no aportan valor.
Un proveedor debería poder resolver de forma autónoma las consultas adecuadas y escalar a una persona únicamente cuando exista una excepción real. Eso reduce trabajo administrativo sin convertir la relación con proveedores en una experiencia impersonal.
¿Qué consultas y tareas externas consumen hoy tiempo interno sin necesitar realmente intervención humana?
Un buen portal no sustituye al ERP. Lo hace accesible de otra manera.
La experiencia externa: navegación, formularios, consultas, seguimiento y autoservicio.
La capa que permite organizar datos, relaciones, identidad de usuario externo, permisos y procesos de Power Platform.
El sistema donde continúan gobernándose proveedores, compras, pedidos, facturas, contabilidad y reglas transaccionales.
Orquesta validaciones, avisos, aprobaciones, tareas y pasos posteriores a una interacción.
La arquitectura debe limitar qué puede ver y hacer cada usuario externo, con permisos expresamente diseñados y probados.
¿Hay que copiar los datos de Business Central a otro sistema para enseñárselos al proveedor?
No necesariamente. Microsoft está desarrollando la integración entre Business Central y Power Pages mediante tablas virtuales de Dataverse. Este enfoque permite que determinados datos permanezcan en Business Central mientras se exponen a Power Platform sin necesidad de replicarlos físicamente en Dataverse.
Consultar Business Central desde Dataverse sin duplicar necesariamente el dato.
Microsoft documenta un complemento de tablas virtuales de Business Central que permite operaciones sobre datos de Business Central desde Dataverse y Power Platform. Los datos permanecen en Business Central y las tablas que se quieran utilizar deben habilitarse para ese escenario.
La integración específica debe evaluarse con criterio antes de convertirla en arquitectura estándar.
La arquitectura debe decidir caso por caso qué información se virtualiza, qué información conviene sincronizar y qué procesos necesitan otro patrón de integración. El punto de partida debe ser el proceso de negocio, no una funcionalidad técnica concreta.
La arquitectura no debería empezar preguntando “¿cómo conectamos Power Pages?”.
Primero hay que decidir qué necesita hacer el proveedor, qué dato es maestro, qué acciones puede ejecutar, qué información es sensible, qué reglas deben mantenerse en Business Central y qué nivel de consistencia necesita el proceso. Solo después tiene sentido seleccionar el mecanismo técnico de integración.
Un portal de proveedores es también un proyecto de seguridad, identidad y permisos.
Una experiencia externa puede abrir información corporativa a cientos o miles de usuarios. Por eso el diseño debe partir de una regla sencilla: cada proveedor debe ver únicamente aquello que le corresponde y poder ejecutar únicamente las acciones que el proceso permita.
Identidad
Definir quién es el usuario externo, cómo se autentica y con qué proveedor o cuenta empresarial está relacionado.
Permisos
Determinar páginas, tablas, registros y operaciones disponibles para cada rol, evitando confiar en que ocultar un elemento de navegación sea suficiente.
Trazabilidad
Registrar qué dato se aporta, qué acción se solicita, qué flujo se ejecuta y qué usuario interviene en cada etapa relevante.
Ciclo de vida
Desarrollo, pruebas, producción, cambios, soporte y evolución deben gestionarse como un servicio empresarial y no como una página que se publica una vez.
El valor empieza después de pulsar “Enviar”.
Un portal puede tener un diseño excelente y seguir sin resolver nada. Si un proveedor completa un formulario y después un empleado tiene que leerlo, interpretar la información, copiarla a otra aplicación y avisar manualmente al siguiente responsable, solo hemos digitalizado la entrada.
La interacción debe convertirse en una operación trazable: validar, identificar el registro relacionado, activar las reglas adecuadas, asignar responsabilidad, comunicar el resultado y permitir seguimiento.
Un ejemplo de recorrido
Power Pages no debería convertirse en un segundo Business Central.
Uno de los errores habituales al diseñar una experiencia externa es intentar reproducir demasiado back office. El portal debe simplificar la interacción con el proveedor, no duplicar toda la lógica interna.
El portal cobra sentido cuando forma parte de una arquitectura Business Central + Power Platform.
El ERP continúa gobernando aquello que pertenece al ERP. Power Platform aporta experiencias, automatización y extensiones alrededor del núcleo. El portal es una pieza dentro de ese modelo, no una aplicación desconectada.
Continúa por estas páginas estratégicas
No empieces diseñando pantallas. Empieza contando consultas, correos y tareas repetitivas.
La mejor primera versión de un portal suele ser bastante más pequeña de lo imaginado. Conviene seleccionar un conjunto concreto de interacciones con impacto elevado, comprobar la arquitectura y escalar después.
Identificar fricción
Contar preguntas repetitivas, correos, documentos, incidencias, tiempos de respuesta y tareas de reintroducción de datos.
Definir datos y permisos
Determinar qué consulta cada usuario, qué modifica, qué sistema gobierna el dato y qué información no debe salir del back office.
Diseñar el proceso completo
Pensar qué ocurre antes y después de la interacción: validación, aprobación, actualización, integración, comunicación y excepción.
Medir el impacto
Comparar llamadas evitadas, consultas resueltas, tiempos de ciclo, incidencias, automatizaciones ejecutadas y carga administrativa antes de ampliar el alcance.
Power Pages, proveedores y Business Central: las dudas que conviene resolver antes de empezar.
¿Se puede crear un portal de proveedores conectado a Business Central?
Sí, existen distintos patrones de integración dentro del ecosistema Microsoft. La arquitectura debe definir qué datos y procesos merece la pena exponer y cómo mantener seguridad, consistencia y trazabilidad.
¿El proveedor necesita entrar en Business Central?
No debería ser necesario para un escenario de autoservicio externo bien diseñado. La experiencia del proveedor puede construirse con Power Pages y conectarse con los sistemas internos mediante la arquitectura adecuada.
¿Hay que duplicar todos los datos del ERP?
No. La decisión depende del escenario. En algunos casos puede utilizarse virtualización o integración; en otros puede ser adecuado sincronizar determinados registros. Lo importante es no crear copias innecesarias que después haya que reconciliar.
¿Qué información debería mostrar un portal de proveedores?
Solo aquella necesaria para completar procesos externos: datos de proveedor, documentación, solicitudes, pedidos, entregas, incidencias, facturas u otros estados cuando el modelo funcional y los permisos lo permitan. No conviene reproducir todo el ERP.
¿Power Pages sustituye a Power Apps?
No. Tienen escenarios distintos. Power Pages está especialmente orientado a experiencias web externas. Power Apps encaja habitualmente en aplicaciones internas o experiencias operativas para usuarios de la organización.
¿Cuándo merece la pena plantear un portal?
Cuando existe un volumen relevante de usuarios externos, consultas repetitivas, documentos, reintroducción de datos, seguimiento manual o procesos que podrían ofrecer autoservicio manteniendo seguridad, trazabilidad e integración con los sistemas internos.
Profundiza desde el problema hacia la plataforma.
Este escenario forma parte de una arquitectura más amplia de Business Central, Power Platform y Dataverse. Estas páginas ayudan a entender cada capa sin mezclar sus responsabilidades.
Portales empresariales para clientes, proveedores, distribuidores, empleados y otros colectivos externos.
Explorar Power Pages →
Cómo extender el ERP con apps, automatización, datos y experiencias sin llenar el core de personalizaciones.
Ver casos de uso →
Arquitectura para automatizar procesos periféricos y mantener el ERP como sistema de referencia.
Explorar el hub →
ERP cloud para conectar finanzas, ventas, compras, proyectos, inventario, fabricación y operaciones.
Conocer Business Central →
¿Tus proveedores siguen necesitando llamar o escribir para saber qué está pasando?
Podemos analizar qué consultas, documentos y procesos merece la pena trasladar a una experiencia de autoservicio y cómo conectarla con Business Central, Dataverse y Power Platform sin crear otro silo.
»’
path = «/mnt/data/ayesa365_portal_proveedores_business_central_power_pages.html»
with open(path, «w», encoding=»utf-8″) as f:
f.write(html)
print(path)
Business Development Manager | PSELLER Microsoft en Ayesa | Miembro Unidad Transición Energética, Climática y Urbana en Tecnalia | Secretaria de la Junta Directiva del Cluster de la Construcción (Build INN)