Una arquitectura de Microsoft orienta el diseño de la atención interna con Copilot Studio. Permisos, derivación y pruebas determinan qué conviene automatizar.
Business Central 29 combina controles sobre los diseños seleccionables con API para consultar la bandeja de informes, recuperar archivos y actualizar su marca de leído.
Microsoft clasifica como vista previa pública tres mejoras: varios impuestos especiales por artículo, retenciones en operaciones de empleados y series de autofacturas por proveedor. Su aplicación depende del proceso y la configuración.
BC29 incorpora instrucciones en pedidos de compra, configuración asistida y nuevas opciones de almacén para subcontratación, sobre capacidades ya disponibles en 28.3.
GitHub incorpora comparaciones voluntarias al panel de impacto de Copilot. Sus indicadores permiten situar la adopción y las tasas de integración de cambios entre participantes, con límites que conviene conocer antes de fijar objetivos.
Las políticas de OpenAI exigirán aprobación previa para dar a terceros acceso directo a sus modelos desde el 20 de noviembre de 2026. El texto distingue ese servicio de integrar modelos en una aplicación.
BC29 incorpora cambios en el modelo de datos de las extensiones y en los índices. Una evaluación útil debe comparar lecturas, escrituras y condiciones de ejecución.
BC29 incorpora el intercambio EDI en vista previa pública. Un piloto debe contrastar los pedidos, las respuestas comerciales y los requisitos de conexión.
Contraste realizado el 27/10/2026 con documentación pública de Microsoft y OpenPeppol. BC29 clasifica el intercambio EDI como vista previa pública. El vídeo se conserva como fuente de origen, pero no se ha podido inspeccionar su demostración ni una transcripción. El ejemplo y la matriz de pruebas son propuestas sintéticas de Nexo, sin resultados de implantación.
Microsoft incluye el intercambio de documentos EDI entre las novedades de E-Documents en Dynamics 365 Business Central 29.0. Las notas de BC29 lo clasifican como vista previa pública.
La ficha 573305 del roadmap describe intercambio de pedidos y envío de avisos de remesa mediante Peppol BIS 3, con posibilidad de ampliar formatos y documentos. Sitúa la vista previa en octubre de 2026 y el inicio previsto del despliegue en abril de 2027. Es un calendario de planificación: no acredita disponibilidad general actual ni acceso en cualquier entorno.
Del pedido a la respuesta comercial
El estándar Peppol BIS Ordering contempla que el comprador envíe un pedido y el vendedor responda. Distingue el acuse de recepción, la aceptación, el rechazo y la aceptación con cambios.
Esa distinción importa al diseñar las pruebas: recibir un pedido no equivale a aceptarlo. Las posibilidades del estándar tampoco demuestran que la vista previa de Business Central implemente todas sus variantes. El piloto debe comprobar qué mensajes y estados admite la combinación concreta de versión, formato y conector.
Un piloto con dos empresas ficticias
Ejemplo sintético: Compras Norte solicita 20 cajas a Suministros Sur. Ambas empresas, sus nombres y la operación son ficticios. El objetivo de prueba sería seguir la relación entre el pedido de compra del comprador, el pedido de venta del vendedor y la respuesta que recibe el primero.
Esta matriz propone comprobaciones; no describe pruebas ejecutadas ni garantiza comportamientos automáticos del producto.
Prueba
Qué comprobar
Responsable propuesto
Pedido válido
Cotejar las 20 cajas, referencias, unidad, precio y entrega en ambos extremos.
Compras y ventas
Aceptación
Vincular la respuesta con el pedido original y comprobar su efecto en el comprador.
Ventas y compras
Rechazo
Comprobar dónde aparece el motivo y quién decide corregir o cerrar la solicitud.
Ventas y compras
Dato incompleto
Introducir una referencia sin correspondencia y localizar la validación y su responsable.
Datos maestros e integración
Reenvío
Repetir el mismo envío en pruebas y comprobar el tratamiento de duplicados.
Soporte de integración
Qué exige la conexión
La guía de conexión con servicios externos requiere instalar E-Document Core y un conector. Enumera Avalara, B2BRouter, Continia, Logiq, Pagero, SignUp y ForNAV, y advierte de que se necesita un contrato con el proveedor y de que puede haber licencias o pagos adicionales. Es una lista general de E-Documents; no certifica por sí sola el soporte de pedidos y respuestas de BC29 con cada proveedor.
La configuración de E-Documents permite consultar los tipos de documento admitidos por el formato elegido. Para el piloto conviene dejar registrados el formato y el conector utilizados, los identificadores de ambas partes, las correspondencias de artículos y unidades, y las reglas de envío y revisión. La documentación general no constituye una matriz de compatibilidad EDI por proveedor y país.
Qué evidencia conservar y qué límites mantener
Microsoft documenta un registro del documento y otro de integración: el primero recoge creación y procesamiento; el segundo, comunicaciones y actualizaciones de estado con servicios externos. Ambos son puntos de partida para reconstruir una incidencia, según las preguntas frecuentes de E-Documents.
Como criterio de prueba, Nexo propone conservar los identificadores relacionados, los estados observados y la intervención necesaria para resolver cada excepción. El soporte de un formato de facturación local no demuestra cobertura del intercambio de pedidos ni cumplimiento de todos los requisitos de un país. Las fuentes consultadas tampoco aportan costes de implantación, tiempos de procesamiento o mejoras medidas para este piloto.
Lectura de Nexo
El interés funcional está en comprobar si el intercambio evita volver a introducir datos y permite conocer la situación comercial del pedido. Son beneficios potenciales que deben medirse. Un piloto útil necesita demostrar también cómo se reconoce un rechazo, cómo se corrige un dato y quién se hace cargo cuando el flujo se detiene.
Elaborado con asistencia de IA y revisado por Nexo Community. Las propuestas prácticas y la interpretación editorial se distinguen de los hechos documentados.