Page Scripting en Business Central: actualiza tu ERP sin poner a prueba la suerte

Un pedido que se crea correctamente, pero no conserva la dimensión de proyecto. Un albarán que se registra, pero genera un efecto distinto en inventario. Una factura que parece correcta hasta que llega a contabilidad. Para el comité de dirección son incidentes operativos; para el equipo de Business Central son, muchas veces, combinaciones de extensiones, permisos, datos y pasos funcionales que no se probaron como una secuencia completa.

La actualización de un ERP no se limita a instalar software. También hay que demostrar que los procesos de negocio siguen comportándose como deberían, incluso cuando conviven funcionalidades estándar, aplicaciones de terceros, personalizaciones, integraciones y roles específicos. Un ensayo manual puede funcionar mientras el equipo es pequeño, el negocio es sencillo y una persona recuerda cada caso de uso. A medida que aumenta la complejidad, ese método se vuelve frágil.

Page Scripting nace para reducir esa dependencia de la memoria. Permite registrar interacciones realizadas por un usuario en el cliente web de Business Central, reproducirlas más adelante y añadir comprobaciones de valores. La novedad para finales de 2026 es importante: Microsoft incluye su disponibilidad general en Business Central 29, dentro de la segunda ola de versiones de 2026. Ya no hablamos únicamente de una herramienta experimental de su primera presentación en 2024.

No convierte una empresa en un laboratorio de testing de la noche a la mañana. Lo que hace es ofrecer una base más repetible para una pregunta esencial: «¿Podemos desplegar este cambio sin comprometer lo que la gente necesita hacer mañana?» Y esa pregunta tiene una respuesta más útil cuando se apoya en evidencia que cuando depende de un «en principio funciona».

Page Scripting es una herramienta integrada en el cliente web de Microsoft Dynamics 365 Business Central que registra operaciones de interfaz: abrir una ficha, seleccionar una acción, rellenar un campo, navegar por páginas o consultar el resultado de un proceso. La grabación se transforma en una secuencia de pasos que puede reproducirse y evaluarse, con avisos sobre las operaciones ejecutadas correctamente o las que fallan.

Microsoft la introdujo en 2024 y fue ampliando su alcance. En la versión 29.0, publicada en octubre de 2026, la documentación oficial la recoge con estado de disponibilidad general. Eso no significa que todos los clientes tengan idénticas capacidades en cualquier versión antigua: las posibilidades concretas dependen de la versión, el entorno, los permisos y las funciones incorporadas en cada actualización. Antes de planificar un proyecto hay que verificar la versión desplegada y sus requisitos.

El uso principal es la prueba funcional y las pruebas de aceptación de usuario, conocidas como UAT. En vez de pedir a una persona que repita manualmente un itinerario de doce pasos cada vez que cambie una extensión, se registra una secuencia y se comprueba su resultado. La automatización puede ahorrar repetición, pero no sustituye el juicio de quien conoce el negocio ni determina por sí sola si el proceso estaba bien diseñado.

Conviene añadir una diferencia: Page Scripting no es un sistema general de automatización de tareas de negocio. Reproducir una compra de prueba para validar una actualización es distinto de utilizar una automatización para procesar todas las compras reales. Para esa segunda necesidad existen otras herramientas y patrones arquitectónicos. Confundir pruebas con ejecución productiva es una fuente frecuente de riesgos.

El punto de entrada se encuentra en el menú de configuración de Business Central. Un usuario autorizado abre Page Scripting, inicia una grabación y ejecuta el proceso como lo haría habitualmente. La herramienta recoge los pasos de interacción y ofrece controles para detener, continuar, revisar, reordenar y corregir determinadas operaciones capturadas.

Al terminar, se reproduce la secuencia. Esto permite observar si los pasos siguen siendo válidos. Pero hay un detalle decisivo: lograr que todos los clics se ejecuten no basta para acreditar que el resultado de negocio es correcto. Por ejemplo, crear una factura sin errores de interfaz no demuestra por sí solo que la cuenta, la dimensión y el importe sean los esperados. Por eso conviene incorporar comprobaciones explícitas allí donde el proceso tiene consecuencias económicas u operativas.

Las grabaciones pueden guardarse en formato YAML, abrirse de nuevo y compartirse. También es posible trabajar con parámetros para evitar valores fijos, de modo que la misma lógica sirva en diferentes escenarios. Microsoft documenta opciones para incluir otras grabaciones y reutilizar recorridos, una característica útil cuando los procesos comparten pasos comunes como iniciar sesión, seleccionar sociedad, localizar cliente o crear un documento.

El resultado no debería ser una colección desordenada de archivos con nombres improvisados. Es preferible un pequeño catálogo que indique el proceso, la persona responsable, las condiciones de partida, el resultado esperado, la última ejecución y el cambio para el que se utilizó la prueba. Eso convierte la grabación en un activo del proyecto y no en un recurso que se abandona tras la primera demostración.

Imagina que el responsable de compras reproduce una secuencia de aprobación y recibe una confirmación visual. Hasta aquí, la aplicación ha ejecutado determinadas acciones. La prueba de negocio empieza al comprobar si el importe es correcto, si la dimensión financiera corresponde al centro de coste, si el usuario tenía autorización y si la contabilización deja los datos en el estado esperado. Sin esas comprobaciones, la grabación demuestra actividad, no calidad.

Page Scripting permite incorporar validaciones de valores, condiciones, parámetros y comprobaciones sobre mensajes o errores. También posibilita repetir el recorrido con datos controlados. La combinación permite transformar un conjunto de acciones en un escenario de aceptación útil para Finanzas, Operaciones y Sistemas. El escenario, sin embargo, debe ser diseñado por las personas que conocen el proceso y sus riesgos.

Las pruebas de aceptación de usuario reciben un nombre técnico, UAT, pero resuelven una necesidad muy poco abstracta: que quienes realmente compran, venden, facturan y cierran el mes puedan comprobar que el sistema sigue haciendo lo que necesitan. Un desarrollo puede pasar pruebas de código y aun así fallar en una operación normal si las condiciones reales del negocio no estaban representadas.

Una buena prueba de aceptación comienza con una historia concreta. «Si un cliente solicita un producto con un descuento autorizado y un plazo pactado, la venta debe registrarse con la dimensión correcta, impactar de forma adecuada en las existencias y conservar los importes previstos». Hay que definir qué datos se utilizarán, qué permisos debe tener el usuario, cuál es el resultado esperado y qué evidencias hay que revisar.

Page Scripting permite registrar el recorrido y repetirlo. Su valor es más alto cuando se combina con datos de prueba que representen casos habituales y excepcionales. No es suficiente comprobar la operación más feliz; hay que incluir pedidos sin existencias, clientes bloqueados, límites de crédito, documentos parcialmente servidos, monedas distintas y otras condiciones relevantes según el sector.

La aceptación exige también interpretar el resultado: una prueba puede fallar porque el script quedó obsoleto después de un cambio deliberado de interfaz. Otro fallo, en cambio, puede descubrir un cambio no previsto en la lógica de negocio. El equipo necesita distinguir ambos casos para evitar que el informe de errores se llene de falsos positivos o, peor aún, se ignoren fallos reales.

No tiene sentido grabar toda la aplicación desde el primer día. Es mejor empezar por unos pocos circuitos que detienen la empresa si fallan. Elegirlos exige hablar con los dueños del proceso, revisar las incidencias de actualizaciones anteriores y localizar personalizaciones especialmente sensibles. Si un cambio afecta a facturación, cobros o inventario, esas pruebas deben tener prioridad sobre operaciones que apenas se utilizan.

Estos ocho escenarios representan una base útil para una empresa mediana con Business Central. No todos tendrán sentido en todos los sectores y algunos requerirán adaptar el conjunto de datos, las extensiones y las autorizaciones. La prioridad debe definirse por criticidad, frecuencia y consecuencias del error.

Business Central online recibe actualizaciones periódicas. Algunas incorporan mejoras visibles; otras introducen cambios en componentes que interactúan con extensiones, configuraciones o flujos personalizados. El equipo de IT puede programar determinadas actualizaciones dentro de las ventanas permitidas, pero esa flexibilidad solo aporta valor si existe un plan de comprobación y una decisión clara sobre la salida a producción.

La práctica recomendable consiste en utilizar primero un entorno de pruebas representativo. Se preparan datos y aplicaciones, se ejecutan los scripts críticos, se revisan los fallos y se repite la validación después de corregir los problemas. Cuando la actualización afecta a campos, acciones o interfaces del cliente, puede ser necesario ajustar las grabaciones. El objetivo no es mantener las pruebas inmutables: es mantenerlas fiables.

En entornos regulados o con cierres mensuales críticos, la planificación debe incluir fechas de negocio. No tiene sentido programar una validación a última hora cuando el equipo financiero está cerrando el trimestre. También se necesita un criterio de aceptación formal: qué fallos bloquean, cuáles permiten continuar con mitigaciones y quién tiene la autoridad de tomar esa decisión.

La versión 29 introduce novedades para el desarrollo y las pruebas, pero cada empresa debe evaluar su combinación concreta de extensiones y procesos. La existencia de Page Scripting no elimina la necesidad de revisar integraciones externas ni de ejecutar pruebas de extremo a extremo fuera del cliente web cuando el circuito atraviesa otros sistemas.

En muchas implantaciones de Business Central, el valor del ERP no reside únicamente en los procesos estándar. Conviven aplicaciones verticales, desarrollos AL, campos adicionales, aprobaciones, informes, reglas de cálculo y conexiones con otras plataformas. Todo ello puede funcionar durante años, pero cada actualización vuelve a plantear la misma pregunta: qué se mantiene, qué ha cambiado y dónde están las dependencias menos evidentes.

Las pruebas de interfaz ayudan a detectar cómo repercute un cambio en la experiencia real de usuario. Un botón que ya no ejecuta la acción esperada, una validación de campo diferente o un flujo de contabilización interrumpido pueden aflorar durante la reproducción. Sin embargo, esta herramienta no sustituye las pruebas unitarias AL ni las validaciones de API, bases de datos, servicios externos o rendimiento. Cada nivel de prueba tiene un cometido diferente.

La combinación eficaz utiliza pruebas AL para validar lógica y componentes; Page Scripting para reproducir recorridos de usuario; y pruebas específicas de integración para confirmar la comunicación con sistemas externos. Una compañía logística, por ejemplo, puede necesitar verificar una tarifa en Business Central y también su intercambio con un TMS. El primer paso puede cubrirse desde el cliente; el segundo requiere pruebas adicionales.

En proyectos sectoriales como IB Building 365 o IB Logistic 365, esta distinción es especialmente relevante: el proceso no termina en la ficha del ERP, sino en un resultado operativo que puede atravesar departamentos y plataformas.

Una grabación resulta útil una vez. Una biblioteca mantenida genera valor durante años. El formato YAML permite conservar, revisar y compartir scripts, y abre la puerta a integrarlos en formas de trabajo más sistemáticas. Para ello no basta con guardar archivos: hay que nombrarlos, clasificarlos, versionarlos y explicar las condiciones para reproducirlos.

La parametrización ayuda a evitar que una prueba dependa siempre del mismo cliente, la misma fecha o el mismo número de documento. Microsoft documenta variables y expresiones para definir entradas al reproducir una secuencia, así como la posibilidad de incluir grabaciones dentro de otras. Un conjunto modular facilita mantener un paso común sin tener que regrabar todos los circuitos.

Los equipos deben tratar también la sensibilidad de los datos de los scripts. Un archivo que contiene valores de pruebas no debe convertirse en un repositorio de credenciales, información personal o importes reales copiados sin control. Es preferible utilizar entornos y conjuntos de datos adecuados, revisar lo que se comparte y proteger los repositorios según las políticas corporativas.

Un catálogo razonable puede contener pruebas de alta de pedido, facturación, compras, existencias, cobro y cierre, con sus variantes por sociedad o rol. El objetivo es cubrir los caminos que permiten operar a diario. Añadir cuarenta scripts irrelevantes es menos útil que mantener diez bien definidos y ejecutados en cada actualización.

Una función especialmente útil es copiar el valor de un campo y reutilizarlo en pasos o comprobaciones posteriores. Por ejemplo, si durante la prueba se crea un pedido, puede guardarse su número para localizarlo después sin depender de un identificador escrito a mano. Esta posibilidad reduce dependencias de datos rígidos y permite construir verificaciones más reproducibles.

Las condiciones permiten que determinados pasos solo se ejecuten si se cumple una regla. Así puede comprobarse si una lista está vacía antes de dar de alta un registro de prueba o si un campo contiene un estado específico antes de continuar. Eso ayuda a evitar grabaciones excesivamente rígidas y a representar situaciones con pequeñas variaciones de datos.

La validación de valores es incluso más importante. Si el objetivo consiste en comprobar un descuento, una dimensión o un estado documental, no basta con completar el proceso: el test debe contrastar el valor obtenido con el esperado. Microsoft permite incorporar comprobaciones, incluyendo expresiones documentadas, para añadir aserciones a la reproducción.

Estas capacidades deben utilizarse con moderación y buen criterio. Las condiciones excesivamente complejas pueden transformar una prueba comprensible en una pieza difícil de mantener. Si un proceso tiene muchas variantes, puede ser preferible dividirlo en pruebas especializadas y conservar una secuencia común. La meta es obtener resultados interpretables y repetibles, no impresionar con scripts intrincados.

Microsoft documenta un mecanismo de ejecución de grabaciones mediante el paquete bc-replay, que puede utilizarse con PowerShell y Playwright. Su objetivo es abrir la posibilidad de reproducir pruebas guardadas fuera de una sesión manual y generar resultados que el equipo pueda revisar. Esto interesa especialmente a organizaciones que desarrollan extensiones con frecuencia o tienen distintos entornos de implantación.

No significa que una grabación se convierta automáticamente en una canalización corporativa lista para producción. Hacen falta condiciones técnicas: autenticación, entorno accesible, datos, control de credenciales, versión compatible, preparación del navegador y una gestión rigurosa de los fallos. Las grabaciones mal diseñadas se vuelven inestables cuando se ejecutan de forma desatendida.

El primer objetivo debe ser conseguir una prueba estable y útil ejecutada bajo supervisión. Cuando el equipo domine el mantenimiento de scripts, se puede decidir qué casos tiene sentido integrar en el ciclo de entrega. La automatización avanzada tiene un coste de construcción y operación que hay que justificar contra el número de veces que se repite la prueba y el riesgo que ayuda a controlar.

Conviene distinguir la ejecución de una secuencia funcional de una evaluación completa del comportamiento del ERP. Una canalización puede indicar qué paso falló y conservar un resultado técnico; no sustituye una revisión humana de cambios contables, de permisos, de integraciones complejas ni de cuestiones de cumplimiento que requieran criterio especializado.

En una empresa industrial, la dependencia entre pedido de venta, disponibilidad de materiales, orden de producción y salida de almacén hace que un cambio aparentemente menor tenga impacto en varios departamentos. La prueba debería representar un producto, una cantidad, un coste o una condición de entrega y verificar que los resultados de cada etapa son coherentes. No basta con comprobar que se pudo guardar el pedido.

En distribución y logística, una modificación en tarifas, descuentos, ubicaciones o reglas de preparación puede degradar márgenes y plazos. Page Scripting puede ayudar a repetir las operaciones del cliente web que participan en el circuito, pero deben complementarse con verificaciones de almacén avanzado y sistemas externos cuando intervienen WMS, transportistas o integraciones EDI.

En construcción, los procesos de imputación de compras, subcontratación, proyectos y costes requieren trazabilidad de dimensiones y contratos. Una prueba bien diseñada debe revisar que el documento acabe asociado a la obra o centro de coste correcto. En estos escenarios, el daño de un error no siempre se descubre el mismo día: puede aparecer durante el seguimiento económico del proyecto.

La misma tecnología puede probar flujos diferentes, pero sus resultados solo son valiosos cuando existe una persona que conoce las reglas del negocio. Por eso una biblioteca de pruebas sectoriales no debería diseñarse únicamente desde desarrollo. Deben participar operaciones, finanzas y responsables de las soluciones verticales.

Uno de los errores más comunes en los proyectos ERP es ejecutar pruebas sin acordar previamente qué hacer con los resultados. Si se descubren doce incidencias el día anterior al despliegue y no existe una clasificación de criticidad, la decisión se convierte en una negociación improvisada. Page Scripting mejora la repetibilidad de las comprobaciones, pero no define el criterio de riesgo de la empresa.

Es necesario diferenciar entre incidentes bloqueantes y problemas tolerables temporalmente. Si un proceso contable genera un resultado incorrecto, una aprobación queda desprotegida o se altera la trazabilidad de inventario, el riesgo puede justificar detener el cambio. Si un texto cambió de posición en una pantalla secundaria, quizá baste con actualizar el script o documentar la diferencia.

También debe existir un responsable de aceptar el riesgo. El equipo técnico identifica la causa y propone correcciones; el dueño del proceso decide si el resultado de negocio es aceptable; la dirección de IT coordina el despliegue. Sin ese reparto, las pruebas se convierten en una actividad que produce informes, pero no mejora las decisiones.

Los resultados deberían guardarse junto con la versión probada, el entorno y las extensiones incluidas. Es más fácil analizar una incidencia si se conoce qué cambió desde la última ejecución satisfactoria. Esa trazabilidad resulta especialmente importante cuando varias empresas o países comparten una instancia y las pruebas pueden comportarse de forma diferente según configuración y permisos.

La herramienta utiliza conjuntos de permisos específicos. Microsoft documenta PAGESCRIPTING – REC para grabar y PAGESCRIPTING – PLAY para reproducir. Este detalle ayuda a separar funciones: no todas las personas que pueden ejecutar una prueba necesitan modificar o diseñar sus grabaciones.

Los permisos de Page Scripting se suman al modelo de autorización del propio ERP. La grabación de una acción no debería convertirse en una forma de eludir restricciones ni de elevar privilegios. Si una persona no tiene autorización para aprobar una operación, las pruebas deben reflejar esa separación, y el entorno no debe utilizar cuentas excesivamente privilegiadas solo para evitar errores de configuración.

Hay otra cuestión práctica: reproducir una secuencia puede volver a ejecutar acciones que modifican datos. Microsoft indica que retroceder en los pasos de reproducción no deshace automáticamente las modificaciones anteriores. Una prueba de contabilización realizada sin precauciones puede generar documentos, asientos u otros cambios no deseados. Por esa razón, el enfoque por defecto debe ser un entorno de pruebas y datos preparados.

El acceso al catálogo de grabaciones también requiere gobierno. Puede revelar nombres de clientes, estructuras comerciales o reglas internas. La documentación técnica debe conservarse donde corresponda y con el nivel de acceso adecuado, especialmente cuando participan proveedores externos o diferentes filiales.

No es una herramienta de automatización HTML. Microsoft explica que captura las interacciones reconocidas por Business Central, particularmente las relacionadas con acciones AL; no está diseñada para automatizar cualquier contenido incrustado ni cualquier página externa. Los control add-ins, ciertos informes embebidos o herramientas ajenas al cliente web requieren mecanismos diferentes.

Tampoco sustituye las pruebas de estrés o de carga. Reproducir un recorrido de usuario no demuestra por sí solo cómo responderá el sistema con cientos de sesiones concurrentes, grandes volúmenes de transacciones o un servicio externo saturado. Esas necesidades requieren otras técnicas y herramientas de validación.

No es una solución completa de formación, aunque las grabaciones puedan servir para explicar o reconstruir procesos. Para capacitar equipos también hacen falta materiales, criterios operativos, prácticas supervisadas y ayuda contextual. Y tampoco reemplaza las pruebas sobre APIs, servicios externos, seguridad, recuperación, rendimiento ni calidad de datos, todas ellas fundamentales en un ERP integrado.

Por último, una prueba repetida no garantiza que un proceso sea bueno. Si la operativa original contenía aprobaciones débiles, errores de diseño o pasos innecesarios, Page Scripting puede reproducirlos perfectamente. La calidad del proceso y la calidad de la automatización son decisiones distintas. Antes de automatizar la comprobación conviene asegurarse de que realmente estamos comprobando lo correcto.

La justificación económica no debería apoyarse en una promesa de ahorro genérica. Para evaluar Page Scripting conviene comparar el esfuerzo de ejecutar manualmente determinados casos con el tiempo necesario para construir, revisar y mantener sus grabaciones. También hay que medir los errores detectados antes de producción y las incidencias que siguen apareciendo después de cada actualización.

Una organización que repite frecuentemente las mismas pruebas puede recuperar antes la inversión en el catálogo. Otra que modifica poco sus procesos quizá obtenga más valor de cinco pruebas críticas que de una iniciativa de automatización extensa. La ecuación depende de la frecuencia de cambios, del coste de los errores y de la complejidad de mantener grabaciones, no únicamente del número de scripts almacenados.

Son útiles indicadores como porcentaje de procesos críticos cubiertos, horas de ejecución por ciclo, proporción de pruebas que requieren retoques, fallos bloqueantes detectados antes del despliegue y número de incidentes productivos relacionados con cambios. Ninguno debe interpretarse de forma aislada. Un aumento de errores detectados durante pruebas puede ser positivo si significa que se están descubriendo antes de afectar a los usuarios.

La prioridad comercial para un proyecto con Ayesa no es vender «automatización de pruebas» como una licencia o un paquete abstracto. Es ayudar al cliente a reducir incertidumbre en la modernización de Business Central, proteger operaciones y ganar autonomía para adoptar nuevas versiones con un riesgo controlado.

La primera fase es seleccionar procesos críticos y reconstruir su definición de aceptación. No hace falta comenzar con una herramienta: hace falta acordar qué significa que un pedido, una factura o una conciliación funcionen correctamente. Sin este trabajo previo, una grabación puede reproducir pasos que ya eran incorrectos.

La segunda fase consiste en capturar unos pocos recorridos representativos, revisarlos con usuarios clave y añadir validaciones de valores. La tercera, en ejecutarlos después de un cambio real: una extensión actualizada, una configuración modificada o una nueva versión de Business Central. Así se comprueba si el método aporta resultados útiles o genera demasiado mantenimiento.

Solo entonces tiene sentido ampliar el catálogo y valorar su ejecución automatizada. En esta fase se definen responsables, repositorios, versiones y criterios de riesgo. La automatización debería extenderse a los casos donde evita más repetición, no a cualquier operación que sea técnicamente posible grabar.

La cuarta fase transforma la práctica en una rutina de gobierno: antes de desplegar, se ejecutan pruebas, se revisan desviaciones y se registra la aceptación. A partir de ahí, el catálogo crece cuando el negocio añade procesos críticos o aparecen incidencias nuevas, y se depura cuando las grabaciones pierden utilidad. Esta disciplina es mucho más valiosa que multiplicar scripts sin una estrategia de mantenimiento.

Las empresas que aún trabajan con Dynamics NAV o mantienen implantaciones muy personalizadas suelen afrontar una cuestión previa a la elección de plataforma: ¿cómo sabemos que no perderemos capacidades críticas al modernizar? Page Scripting no resuelve por sí solo una migración de NAV, pero ilustra el tipo de disciplina de pruebas que debería acompañar cualquier proyecto de transformación.

En Business Central, reducir el riesgo de actualización permite avanzar con menos dependencia de procedimientos informales. Esto ayuda a adoptar cambios de producto, mejorar extensiones y desplegar nuevas capacidades sin dejar todas las comprobaciones para la última semana. También facilita una conversación más madura sobre calidad con el partner que mantiene el ERP.

Si la empresa está evaluando su arquitectura, conviene revisar la página de modernización de ERP con Microsoft. Para conocer el producto y sus posibilidades, puede consultar Dynamics 365 Business Central. Y si necesita analizar cómo evolucionar desde un sistema anterior, la guía de migración de NAV a Business Central aborda decisiones que van más allá de la herramienta de pruebas.

Una organización puede tener una gran implantación y, al mismo tiempo, depender demasiado del conocimiento de unas pocas personas para comprobarla. La transformación no consiste solo en cambiar de ERP o activar funcionalidades nuevas. También consiste en que las decisiones de evolución sean verificables, repetibles y menos vulnerables a la rotación del equipo.

No basta con conocer dónde está el botón de Page Scripting. Para construir una biblioteca útil hay que entender la implantación, los procesos del cliente, sus extensiones, las reglas de seguridad y los cambios que se van a introducir. También debe existir capacidad para identificar problemas, corregirlos y volver a verificar la solución antes del despliegue.

Un partner con experiencia en Business Central puede ayudar a priorizar los casos de prueba, preparar entornos seguros, documentar escenarios, ajustar las grabaciones a las nuevas versiones y definir criterios de aceptación con negocio. La medida de éxito no será cuántos archivos YAML entregue, sino cuántos procesos críticos quedan mejor protegidos y cuánto se reduce la incertidumbre ante cada cambio.

El trabajo debe coordinarse con responsables de IT y usuarios clave. A menudo los procesos más arriesgados no son los más visibles para desarrollo: hay acuerdos comerciales complejos, contabilidad de proyectos, excepciones de facturación y reglas de aprobación que solo conocen determinadas áreas. Involucrarlas desde el principio evita diseñar pruebas correctas desde el punto de vista técnico, pero irrelevantes para la continuidad operativa.

Ayesa combina consultoría ERP, conocimiento funcional, soluciones sectoriales y capacidades de integración dentro del ecosistema Microsoft. Puede evaluarse esa capacidad y las credenciales publicadas en Ayesa como partner Microsoft. La propuesta no consiste en prometer que nunca existirán fallos: consiste en reducir su probabilidad, identificarlos antes y saber cómo actuar cuando aparecen.

Un diagnóstico útil debería identificar cuántos procesos críticos dependen de pruebas manuales; qué incidencias se repiten después de actualizar; cómo se validan hoy las extensiones; quién acepta los cambios en compras, ventas y finanzas; qué permisos están definidos; y qué entornos pueden utilizarse sin riesgo para los datos operativos.

También debe comprobarse el calendario real de actualizaciones, la antigüedad de las personalizaciones, la existencia de aplicaciones de terceros y los límites de las integraciones externas. El valor de Page Scripting crece cuando se integra en un plan coherente de validación, no cuando se incorpora como una herramienta aislada que nadie mantiene.

Por último, hay que decidir qué incidentes justifican bloquear una actualización y cómo se conservan las evidencias. Una organización que nunca ha formalizado su criterio de aceptación puede comenzar con unos pocos casos. Lo importante es que esos primeros recorridos representen resultados de negocio verificables, y no una lista interminable de acciones de interfaz.

La próxima actualización no debería convertirse en una semana de incertidumbre.

Una revisión del entorno y sus procesos críticos permite decidir dónde empezar a probar, qué personalizaciones requieren atención y cómo preparar una validación que tenga sentido para el negocio.

Evaluar continuidad y calidad del ERP

La guía de Microsoft Learn sobre Page Scripting para pruebas de aceptación documenta el registro, la reproducción, las validaciones, los parámetros, los permisos y los límites. La página oficial de novedades de Business Central 29.0 recoge el paso a disponibilidad general. Para los equipos técnicos, Microsoft también ofrece la documentación de ejecución de scripts en canalizaciones.

Para ampliar la visión de negocio, Directions EMEA 2026 resume las novedades que Microsoft presentó en París, mientras que cambiar de partner Dynamics 365 explica cómo planificar una transición cuando el principal problema no es el ERP, sino la falta de control sobre evolutivos, soporte y continuidad.

La decisión importante no es si una empresa puede grabar sus procesos: es si sabe cuáles debe comprobar antes de cada cambio y si dispone de la disciplina para utilizar esa evidencia. La herramienta abre esa posibilidad; el método, el criterio funcional y el gobierno del proyecto determinan el resultado.