--- title: "Análisis de NAV con IA | Business Central | NAVtoBC.de" description: "Analizar Navision con IA: entender el código C/AL, el esquema SQL y los procesos de negocio. Planificar la migración a Business Central y AL." url: https://navtobc.de/es language: es --- ANÁLISIS DE NAVISION CON IA # Entender Navision. Preparar la migración a Business Central. Analizamos Navision y Microsoft Dynamics NAV con inteligencia artificial (IA) y análisis automatizado del código C/AL. Nuestra larga experiencia con Navision une el conocimiento de procesos acumulado en su empresa con un escenario objetivo claro para Business Central. [Solicitar análisis inicial sin compromiso](https://navtobc.de/es/kontakt) [Descubrir los resultados](https://navtobc.de/es/beispiel-ergebnisse) Primero, el estándar de Business Central. Dar preferencia a los módulos certificados. Desarrollar a medida solo de forma selectiva. NAVtoBC.de Análisis y planificación de la migración SU BASE PARA DECIDIR ## Del conocimiento a la perspectiva. DEMO 01 / PRIORIDAD **Estándar de Business Central** Aprovechar sus funciones 02 / EXTENSIÓN **Módulos certificados** Sustituir el código a medida 03 / BRECHA JUSTIFICADA **A medida, con criterio** Desarrollar lo necesario **Las relaciones se mantienen** Valores sustitutos coherentes **Cliente** P-7Q4X9 **Pedido** P-7Q4X9 **Factura** P-7Q4X9 **Cada recomendación, trazable.** Con fuentes, estado de verificación y decisiones pendientes. **Conocimiento acumulado. Un plan claro.** Analizar · documentar · priorizar Formato de resultados ilustrativo con datos sintéticos. RESULTADOS QUE LE HACEN AVANZAR ## Cuatro resultados. Una dirección clara. No se trata de trasladar el código sin más. Usted recibe una base documentada para tomar decisiones, con fuentes, estado de verificación y puntos abiertos. 01 / INVENTARIO ### Inventario técnico Entender las personalizaciones, interfaces y dependencias. Mapa de objetos y grafos de referencias 02 / PROCESOS ### Procesos de negocio documentados Revisar flujos, reglas y excepciones con sus departamentos funcionales. Mapa de procesos y reglas en JSON 03 / CONOCIMIENTO ### Base de conocimiento estructurada Preservar el conocimiento acumulado del sistema, con su origen y estado de verificación. Artículos de conocimiento y referencias a las fuentes 04 / ESCENARIO OBJETIVO ### Propuesta de migración priorizada para Business Central Sopesar el estándar, los módulos certificados y el desarrollo necesario. Matriz de decisión y hoja de ruta LOS RESULTADOS DEL ANÁLISIS EN VÍDEO ### Cuatro resultados. Una dirección clara. 1:30 min · Full HD · Con sonido ![Los cuatro resultados del análisis de NAVtoBC](https://navtobc.de/film/ergebnisse-v1/es/poster.webp) [Los cuatro resultados del análisis de NAVtoBC](https://navtobc.de/film/ergebnisse-v1/es/index.m3u8) Inventario técnico, procesos de negocio, base de conocimiento y propuesta de migración: los cuatro resultados en 90 segundos. Reproducción en 1080p a 30 fotogramas por segundo. ¿POR QUÉ AHORA? ### Claridad desde el principio. Una migración bien planificada. ¿Qué personalizaciones siguen siendo necesarias? ¿Qué interfaces deben mantenerse? ¿Y qué reglas de negocio se esconden en el código C/AL acumulado durante años? **Las personas clave con el conocimiento han dejado la empresa.** Recuperamos ese conocimiento: - mediante el análisis del código fuente - mediante talleres con los departamentos funcionales Un análisis temprano hace comprensibles estas relaciones antes de que usted fije el presupuesto, el calendario y la implantación. Así podrá evaluar los requisitos con fundamento junto con sus departamentos funcionales y su partner de implantación. El conocimiento obtenido le ayuda ya hoy en la resolución de errores, la documentación y la evolución de su sistema NAV actual. [Solicitar análisis inicial sin compromiso](https://navtobc.de/es/kontakt) ¿Qué plazos de soporte se aplican a su sistema? [Ver las versiones de NAV y sus periodos de soporte](https://navtobc.de/es/nav-versionen) LOS 3 RIESGOS PRINCIPALES ## Por qué algunos proyectos fracasan. Una migración cambia algo más que el software. Afecta a procesos consolidados, a responsabilidades y al conocimiento de su personal. Por eso, estos tres riesgos deben ponerse sobre la mesa desde el principio. 1. ### La obsesión por el 1:1 Quien pretende reproducir uno a uno en Business Central un entorno de Navision muy modificado y desarrollado a lo largo de los años, arrastra también la complejidad heredada. Eso puede desbordar el calendario y el presupuesto. #### Qué ayuda Separar los requisitos de negocio del código existente. Revisar primero el estándar de Business Central y los módulos adecuados; después, planificar el desarrollo a medida necesario. 2. ### Análisis previo insuficiente Sin un análisis del código y de los procesos, se arrastran funciones especiales costosas que ya no se utilizan o que el estándar actual cubre desde hace tiempo. Al mismo tiempo, pueden pasarse por alto dependencias importantes. #### Qué ayuda Contrastar el código, las interfaces y el uso real con los departamentos funcionales. Decidir de forma justificada para cada personalización: mantener, sustituir o retirar. 3. ### Gestión del cambio insuficiente Si los departamentos funcionales se implican solo poco antes de la puesta en marcha, a menudo se mantienen las antiguas formas de trabajar. Los nuevos procesos están implementados técnicamente, pero aún no han llegado al día a día. #### Qué ayuda Implicar pronto a los departamentos funcionales, designar responsables y reservar tiempo para la formación. Probar los nuevos procesos conjuntamente con casos de negocio realistas. ### No todas las personalizaciones tienen que migrarse. Pero toda regla crítica para el negocio debe entenderse. La IA hace más accesible el conocimiento acumulado del sistema. Los departamentos funcionales aportan por qué se necesita una regla. Juntos construyen una base sólida para tomar decisiones. [Aclarar a tiempo los riesgos de la migración](https://navtobc.de/es/kontakt?thema=nav-analyse) DEL OBJETO INDIVIDUAL AL SISTEMA COMPLETO ## Análisis detallado de Navision con IA. **Comprender su sistema. Detectar relaciones. Hacer que el conocimiento sea útil de forma duradera.** Analizamos su **sistema Navision, Dynamics NAV o MS Dynamics NAV** hasta el nivel de objeto. El análisis automatizado del código C/AL, el análisis del esquema y la inteligencia artificial (**IA**) unen código fuente, datos e interfaces en una base de conocimiento trazable. **Análisis automático de C/AL con una herramienta de análisis propia. Se evalúan exportaciones de objetos en TXT.** Los archivos FOB nativos no se procesan directamente. Los resultados constituyen la base de sus decisiones de migración. El código a medida necesario se reescribe en AL; no se convierte automáticamente. ![Análisis detallado de Navision con IA.](https://navtobc.de/film/analyseumfang-v1/es/poster.webp) [Análisis detallado de Navision con IA.](https://navtobc.de/film/analyseumfang-v1/es/index.m3u8) NAVtoBC.de · VÍDEO EN ALEMÁN ### Análisis detallado de Navision con IA. El alcance del análisis, explicado en vídeo. ### Todos los componentes a la vista El análisis abarca los tipos de objeto de su sistema NAV: - Codeunit - Dataport - Form - MenuSuite - Page - Report - Table - XMLPort **Datos SQL, seudonimizados si así lo desea.** También se incluyen los datos existentes. Así pueden examinarse no solo funciones individuales, sino también sus dependencias y flujos de datos. ### Documentar los resultados por objeto Los resultados del análisis se **registran individualmente para cada objeto, se almacenan de forma estructurada y se hacen consultables**. Las funciones, las reglas de negocio y las relaciones siguen siendo localizables. A partir del código fuente acumulado surge una base de conocimiento para el análisis de errores y las decisiones de migración. ### Incluir interfaces y sistemas de terceros Su NAV no termina en su propia base de datos. Por eso incluimos **interfaces externas y herramientas de terceros**, por ejemplo **sistemas EDI y conexiones con tiendas online**. Dentro del alcance de análisis acordado, también pueden leerse y examinarse otras bases de datos SQL relacionadas con Navision. Así se hacen trazables los flujos de datos más allá de los límites de cada sistema. [Importaciones, exportaciones y flujos de datos en detalle](https://navtobc.de/es/schnittstellen) ### Trazabilidad de cada paso del análisis Todos los pasos del análisis se **registran en detalle, incluidas las transcripciones**. Los resultados se asignan a los objetos examinados y a los pasos de análisis documentados. Así queda claro **qué se ha examinado, qué relaciones se han detectado y en qué se basa cada conclusión**. MIRANDO HACIA DELANTE ### Su escenario objetivo: Business Central Del sistema NAV acumulado durante años a una base claramente documentada para su migración. [![Ejemplo de página de inicio de Business Central con navegación, tareas e indicadores clave.](https://navtobc.de/business-central-beispiel.png) Abrir vista de ejemplo](https://navtobc.de/business-central-beispiel.png) **Vista de ejemplo de Microsoft Dynamics 365 Business Central.** La imagen ilustra la interfaz de destino; no muestra ningún resultado de nuestro análisis de NAV. 1. **Entender Navision** Objetos, datos e interfaces 2. **Preservar el conocimiento** Estructurado y consultable 3. **Preparar Business Central** Primero el estándar, ampliar con criterio COMPRENDER LOS FLUJOS DE DATOS. PREPARAR LAS INTERFACES CON PRECISIÓN. ### Interfaces y sistemas conectados. **Analizar de forma estructurada el intercambio de datos en Navision. Evaluarlo con fundamento gracias a la IA.** Las soluciones EDI, los sistemas de BI, las tiendas online y los procesos propios de importación y exportación forman parte con frecuencia del entorno NAV acumulado durante años. **Analizamos estas conexiones y hacemos trazables los flujos de datos, las asignaciones de campos y las dependencias funcionales.** De ahí surgen propuestas concretas para su migración a Business Central. #### Sistemas incluidos en el análisis Flujos de datos EDI e informes de BI relacionados con su sistema Navision. ![Lobster](https://navtobc.de/images/lobster-logo.svg) Flujos de datos EDI ![Qlik](https://navtobc.de/images/qlik-logo.svg) Informes de BI ![Análisis con IA de las interfaces de Navision.](https://navtobc.de/film/schnittstellen-v1/es/poster.webp) [Análisis con IA de las interfaces de Navision.](https://navtobc.de/film/schnittstellen-v1/es/index.m3u8) NAVtoBC.de · VÍDEO EN ALEMÁN #### Análisis con IA de las interfaces de Navision. Flujos de datos y sistemas conectados, en vídeo. #### Intercambio de datos en Navision Registrar fuentes de datos, destinos, formatos y puntos de transferencia. El análisis muestra qué información fluye entre Navision y los sistemas conectados. #### Importación de datos en Navision Examinar los procesos de importación de productos, precios, clientes, existencias y datos transaccionales: origen, estructura, cumplimentación de campos y lógica de validación existente. #### Transferencia de datos en Navision Comprender las vías técnicas de transferencia, los triggers y el orden de procesamiento. Las fuentes de error y las dependencias se documentan como base para introducir mejoras. #### Exportación de datos en Navision Analizar la lógica de exportación, los contenidos, los formatos de destino y los destinatarios. El significado funcional de los datos sigue siendo visible para los sistemas conectados, los informes y el procesamiento posterior. #### Exportación de datos para tiendas online Revisar la transferencia de datos de productos, precios, existencias y pedidos. Las reglas y dependencias existentes se preparan para el futuro escenario objetivo en Business Central. #### Importación de datos de productos Incluir datos de proveedores, catálogos y sistemas previos. Se examinan sistemáticamente los campos obligatorios, las variantes, las unidades, los precios y las reglas de validación propias. #### Análisis de los campos para la conciliación en la importación **Comprender los campos clave, la lógica de asignación y la detección de duplicados.** Revisamos cómo se identifican y concilian los registros y qué reglas de negocio se necesitan para Business Central. #### Incluir los sistemas conectados **Sistemas EDI:** por ejemplo, Lobster EDI, Anvaigo EDI Connect (antes Anveo), SEEBURGER BIS, ecosio y Softzoll. **Análisis e informes:** por ejemplo, Qlik, Microsoft Power BI y Jet Reports. Dentro del alcance de análisis acordado, examinamos las conexiones y las bases de datos SQL asociadas relacionadas con Navision. DEMO ESQUEMÁTICA #### Intercambio de datos en torno a Navision Conexiones, flujos de datos y puntos de partida para el análisis, a modo de ejemplo. EDI **Lobster EDI** Documentos, datos maestros e información de estado BI **Qlik** Informes, análisis y provisión de datos **Navision / Dynamics NAV** C/AL · SQL · lógica de negocio IMPORTACIÓN **Datos de productos** Datos maestros, variantes, unidades y precios TIENDA **Tiendas online** Productos, precios, existencias y pedidos EN ESTO SE CENTRA EL ANÁLISIS **Exportación de datos** Contenidos, formatos de destino y destinatarios **Conciliación en la importación** Asignación de campos, claves y detección de duplicados **Representación ilustrativa, no un proyecto de cliente.** Las flechas muestran direcciones de datos a modo de ejemplo, no flujos de datos medidos en tiempo real. Las interfaces y asignaciones de campos reales se revisan en cada proyecto. Los nombres de productos sirven de orientación; no se afirma ninguna asociación con los proveedores mencionados. **Flujos de datos de la demo en formato texto** - Lobster EDI ↔ Navision: intercambio de documentos, datos maestros e información de estado. - Navision → Qlik: provisión de datos para informes y análisis. - Fuentes externas de productos → Navision: importación con asignación de campos y validación. - Navision ↔ tiendas online: exportación de productos, precios y existencias; retorno de pedidos. - La exportación de datos y la conciliación en la importación son áreas de análisis, no sistemas externos adicionales. NAVISION Y POWER BI #### Sus informes de Power BI, preparados para Business Central. Muchos sistemas Navision suministran indicadores a Microsoft Power BI. Cómo llegan allí los datos depende de la versión de NAV. Y de ello depende lo que ocurre con sus informes en la migración. - **Servicios web OData, desde NAV 2013:** NAV publica páginas y consultas como servicio web y Power BI las lee como fuente OData. NAV calcula por sí mismo los FlowFields y los permisos. - **Acceso SQL directo, también con NAV 2009 R2:** Power BI lee las tablas de cada empresa directamente desde la base de datos. Allí los FlowFields no existen como columnas y los permisos de NAV no se aplican. - **Power BI en el área de trabajo (Role Center), desde NAV 2017:** los informes aparecen directamente en el cliente de NAV. En Business Central online, la vía admitida hacia Power BI pasa por páginas y consultas de API; allí no existe acceso directo a la base de datos. Para finanzas y ventas, Microsoft ofrece aplicaciones de plantilla ya preparadas. Por ello, los informes basados en tablas de NAV o en páginas de NAV publicadas deben conectarse de nuevo. **El análisis de NAVtoBC registra qué tablas, campos y servicios web utilizan hoy sus informes de Power BI** y muestra qué debe volver a conectarse en Business Central. Así podrá planificar la adaptación de sus informes antes de que empiece la migración. Fuentes: [Microsoft: Power BI con Dynamics NAV](https://learn.microsoft.com/es-es/dynamics-nav-app/across-how-use-financials-data-source-powerbi) · [Microsoft: Obtener datos de Business Central](https://learn.microsoft.com/es-es/dynamics365/business-central/dev-itpro/developer/devenv-extract-data) SU RESULTADO #### Sin cajas negras en los flujos de datos. Recibirá un mapa documentado de interfaces, asignaciones de campos trazables y **propuestas basadas en IA** para la implantación posterior: mantener las conexiones necesarias, simplificarlas o sustituirlas de forma selectiva. **Business Central online, evaluado por separado:** según Microsoft, allí no es posible el acceso directo a archivos en el servidor. Por ello, las interfaces basadas en archivos, como los archivos CSV en carpetas de intercambio, necesitan una nueva vía mediante servicios web, API o una carga de archivos en el navegador. **Primero, el estándar de Business Central; después, los módulos ISV adecuados.** Los requisitos específicos necesarios se implementan de nuevo en AL. Las propuestas y los puntos abiertos se acuerdan con sus departamentos funcionales, su TI interna y el partner que usted elija. [Solicitar análisis de interfaces](https://navtobc.de/es/kontakt?thema=schnittstellen) HACER VISIBLE EL PROCESAMIENTO ### Sus flujos de datos. Su lógica de negocio. Trazables en un grafo. **La base de datos de grafos visualiza las relaciones dentro de su NAV.** Muestra cómo se procesan los datos, qué funciones interactúan entre sí y qué lógica de negocio se aplica en cada caso. Los objetos vinculados, las cadenas de llamadas y los flujos de datos hacen trazable el procesamiento en su sistema Navision, incluidas las interfaces y los sistemas conectados examinados. La base son las fuentes analizadas y los resultados documentados. ### Cinco evaluaciones a partir del grafo. Cada ruta, con evidencia. Cada objeto de su NAV se convierte en un nodo: tablas, Forms, Reports, Codeunits, Dataports y MenuSuites. Cada llamada, cada referencia a una tabla y cada entrada de menú se convierte en una arista. Así la red puede consultarse, no solo observarse. **Alcanzabilidad con evidencia** A partir de anclas acordadas con los departamentos funcionales (entradas de MenuSuite, informes, colas de proyectos), el grafo determina para cada objeto si es alcanzable y por qué ruta. Resultado por objeto: alcanzable sí/no, distancia al ancla y la cadena a través de la cual se alcanza. **Dependencias por tabla** ¿Qué objetos leen o escriben en una tabla? Una consulta sobre «Sales Header» muestra todos los Forms, Reports y Codeunits que dependen de ella: la base para evaluar el impacto de un cambio o de la transición a BC. **Dependencias externas: .NET, COM, DLL** El grafo registra para cada objeto dónde C/AL va más allá de NAV: variables y llamadas DotNet (análisis DotNet), CREATEAUTOMATION, objetos COM, Automation Server y dependencias de DLL. En Business Central, la interoperabilidad con .NET solo está disponible on-premises, no online. Las llamadas COM y de automatización no pueden trasladarse sin cambios a AL. Por eso, cada referencia figura en el resultado como un hallazgo propio junto con el objeto afectado: la base para planificar su sustitución en AL. **Objetos sin alcanzabilidad demostrada** Los objetos sin ruta desde un ancla se recopilan y se señalan como pendientes de revisión, no como lista de eliminación. Solo la revisión funcional decide su retirada. **Lagunas en la exportación** Los objetos referenciados que faltan en la exportación, los objetos no compilados y las llamadas no resueltas se registran como hallazgos propios. Así queda visible lo que el análisis no cubre. La base son exportaciones de objetos depuradas, no una conexión a la base de datos. El grafo muestra las relaciones estáticas dentro de la exportación. Las llamadas dinámicas, los objetos que faltan y los límites del parser se marcan como tales; no se presentan como analizados con certeza. Ficha del objeto a partir del grafo DATOS SINTÉTICOS **Crear devolución** *:Form* *:Objeto* **Identificador** FRM-50710 **Alcanzable** sí · distancia al ancla 1 **Alcanzado a través de** MenuSuite → Registro de devoluciones → FRM-50710 **Utiliza** Tabla 36 «Sales Header» (lectura, escritura) **Externo** ninguna dependencia de .NET, COM o DLL **Estado** Exportación del 02/03/2018 · compilado · en la exportación EVIDENCIA POR OBJETO **alcanzable, distancia 1 desde MenuSuite: ruta con fuente por cada arista** Representación de ejemplo con nombres de objetos ficticios y fijos. Sin análisis en tiempo real ni conexión con una base de datos de grafos. CONOCIMIENTO QUE AYUDA EN EL DÍA A DÍA ### Su ventaja inmediata: una resolución de errores más rápida, ya antes de la migración. El análisis no solo sienta las bases para su migración a Business Central. **También aporta una ventaja inmediata en su sistema NAV actual:** los errores pueden acotarse con mayor rapidez y precisión gracias al conocimiento documentado del sistema. Los resultados de objetos consultables, las reglas de negocio documentadas y los flujos de datos visualizados muestran cómo se relacionan las funciones y los procesos. En lugar de volver a investigar estas relaciones en cada incidencia, usted recurre a la base de conocimiento ya elaborada. **Así, una búsqueda de horas puede convertirse en una delimitación precisa en pocos minutos: una ventaja adicional para su operación diaria, incluso antes de dar el paso a Business Central.** *La duración real depende del tipo de error y del alcance del análisis documentado.* [Hablar del alcance del análisis](https://navtobc.de/es/kontakt) LAS PARTICULARIDADES DE C/AL ## Poco código. Mucho efecto. En Navision, la lógica de negocio no reside solo en las funciones. También las propiedades de los campos, los triggers, los filtros y el contexto de ejecución determinan lo que ocurre realmente. Quien analiza C/AL de forma automatizada debe leer estas relaciones en conjunto. Estas son las particularidades esenciales para un análisis y una planificación de la migración bien fundamentados. SITUAR C/AL CORRECTAMENTE ### De Navision a Business Central 14. **C/AL significa Client/server Application Language.** El lenguaje se utilizó en Navision y Dynamics NAV y seguía disponible en Business Central 14 (Spring 2019, on-premises). A partir de Business Central 15, C/AL fue sustituido por AL. NUESTRA BASE DE ANÁLISIS ### Exportaciones de objetos en TXT. Leemos los **objetos de NAV exportados como TXT**, con su código C/AL y sus propiedades. **Los archivos FOB nativos no se procesan directamente.** Si solo se dispone de archivos FOB, los objetos se importan primero en un entorno de desarrollo de NAV adecuado y se exportan desde allí como TXT. Para ello se necesitan una versión compatible y la licencia de desarrollador correspondiente. No basta con cambiar la extensión del archivo. UNA PEQUEÑA DIFERENCIA CON CONSECUENCIAS ### ¿Asignar o validar? Ambas líneas establecen un valor en el búfer del registro. `VALIDATE` ejecuta además la validación del campo, incluido `OnValidate`. Este trigger puede modificar otros campos, desencadenar lógica de negocio e incluso realizar cambios en la base de datos. Asignación directa ``` Customer.Name := 'Beispiel'; ``` Con validación del campo ``` Customer.VALIDATE(Name, 'Beispiel'); ``` ### Lo que va unido en el análisis. Despliegue los temas y descubra los detalles técnicos. ****Lenguaje y valores** Sintaxis Pascal, Code, opciones y tipos de datos funcionales** - **Sintaxis de inspiración Pascal:** `BEGIN … END`, `:=` para las asignaciones y `//` y `{ … }` para los comentarios. Los identificadores y las palabras clave no distinguen entre mayúsculas y minúsculas. Las variables se declaran de forma global en el objeto o de forma local en funciones y triggers. Los parámetros `VAR` pueden modificar el valor en el código que realiza la llamada. - **Code es un tipo de datos propio:** convierte el texto a mayúsculas y elimina los espacios iniciales y finales. La longitud definida de `Code` y `Text` forma parte de la evaluación. Las cadenas y los arrays se direccionan a partir de la posición 1. - **Las opciones tienen un orden:** `OptionString` define los miembros; sus valores numéricos empiezan en 0. Hay que distinguir entre nombre, posición y etiqueta traducida. Una conversión a enums de AL debe tener en cuenta los valores existentes. AL sigue admitiendo también `Option`; el cambio a enums no es obligatorio de forma automática. - **Valores funcionales, no simples números:** `0D`, las fechas de cierre, `WORKDATE` y las fórmulas de fecha tienen un significado propio. Las reglas de redondeo y las conversiones dependientes del idioma con `FORMAT` y `EVALUATE` pueden influir en los resultados y en las interfaces. **Para el análisis:** valores que se ven iguales pueden tratarse técnicamente de forma distinta. Por eso, el tipo de datos, la longitud, el idioma y el paso de parámetros forman parte del hallazgo. ****Objetos y metadatos** Tipo más ID, números de campo y propiedades** - **Objetos en lugar de archivos fuente individuales:** según la versión de NAV, incluyen Table, Page, Report, Codeunit, Query, XMLport y MenuSuite; las generaciones anteriores conocen también Form y Dataport. Lo que identifica de forma única es la combinación de **tipo de objeto e ID**. El rango 50000–99999 está previsto tradicionalmente para las personalizaciones de cliente; los rangos de partners y su uso dependen también de la licencia. - **Las propiedades contienen lógica de negocio:** `TableRelation`, `CalcFormula`, `SourceTableView`, `RunObject` y `RunPageLink` generan relaciones, filtros y llamadas fuera del propio código C/AL. Los números de campo, las claves, los DataItems de los Reports y las estructuras de XMLport también forman parte del modelo. - **Los identificadores no son etiquetas:** `CaptionML` y `OptionCaptionML` proporcionan textos de presentación multilingües, por ejemplo en alemán e inglés. No sustituyen la identidad de los objetos ni la de los campos. Hay que conservar el idioma y la codificación de caracteres de la exportación en TXT. **Para el análisis:** una exportación completa de objetos contiene más conocimiento que unas cuantas funciones copiadas sueltas. Los metadatos forman parte del programa. ****Triggers y lógica de negocio** VALIDATE, RunTrigger y acciones derivadas ocultas** - **Triggers y funciones:** C/AL ofrece funciones globales y locales. Junto a ellas están los triggers de tabla como `OnInsert`, `OnModify`, `OnDelete` y `OnRename`, los triggers de campo como `OnValidate` y `OnLookup`, así como los triggers de Page y de Report. El orden y el contexto de llamada son decisivos. - **Un parámetro cambia el flujo:** en `INSERT`, `MODIFY` y `DELETE`, `RunTrigger` controla si se ejecuta el trigger de tabla correspondiente. Si no se indica, es `FALSE`. `MODIFY(TRUE)` ejecuta `OnModify`, pero no valida automáticamente cada campo. Las operaciones masivas deben considerarse por separado. - **Comprobar, transferir y validar no es lo mismo:** `TESTFIELD` comprueba el valor de un campo. `TRANSFERFIELDS` asigna valores según el número de campo y no ejecuta los triggers `OnValidate`. Una asignación directa a un campo también omite esta validación. - **Contexto implícito:** `Rec`, `xRec` y `WITH` determinan a qué se refiere una expresión. Las variables locales y globales tienen ámbitos distintos. Las variables globales pueden conservar su estado dentro de una instancia de objeto; las codeunits `SingleInstance` comparten su instancia dentro de una sesión. **Para el análisis:** El nombre de una función no basta para explicar el flujo. También hay que reconstruir los parámetros que activan los triggers, el contexto de las variables y las acciones posteriores que se desencadenan. ****Estado del registro y cálculos** Filtros, FlowFields, datos temporales y empresas** - **Los registros recuerdan algo más que valores de campo:** Los filtros, los grupos de filtros, las claves y el registro actual influyen en los accesos. `SETRANGE`, `SETFILTER`, `FILTERGROUP`, `RESET`, `FINDSET`, `FINDFIRST` y `NEXT` deben leerse en su contexto. `GET` utiliza la clave principal e ignora los filtros habituales; los filtros de seguridad deben tenerse en cuenta por separado. - **FlowField no es lo mismo que FlowFilter:** Un FlowField no guarda su resultado calculado de forma permanente en la tabla. `CalcFormula` describe el cálculo, por ejemplo una suma o una búsqueda (lookup). `CALCFIELDS` calcula el valor; según cómo esté integrado, también lo hace la propia interfaz de usuario. Un FlowFilter aporta condiciones de filtro para estos cálculos y no calcula por sí mismo ningún resultado. - **Misma tabla, otro contexto:** Las variables de registro temporales procesan los datos en memoria. `CHANGECOMPANY` cambia la empresa a la que se accede; los triggers se siguen ejecutando en el contexto de la empresa actual. `DataPerCompany` distingue entre tablas específicas de cada empresa y tablas compartidas. **Para el análisis:** El nombre de la tabla y el valor del campo no bastan. Los filtros, la definición del cálculo, el estado temporal y la empresa determinan lo que realmente expresa un dato. ****Dependencias dinámicas y eventos** RecordRef, FieldRef, llamadas y suscriptores** - **Reutilización sin modelo de clases:** C/AL no ofrece espacios de nombres en el lenguaje ni definiciones de interfaz nativas. Tampoco forma parte del lenguaje un modelo de clases propio con herencia. Las codeunits proporcionan funciones globales; `CODEUNIT.RUN` inicia su trigger `OnRun`. Las referencias pueden resolverse mediante nombres, subtipos de objeto declarados o números. - **Algunos destinos solo se conocen en tiempo de ejecución:** `RecordRef`, `FieldRef`, `Variant` y los ID de objeto pasados como variables permiten un procesamiento genérico. También las tablas de configuración pueden determinar qué código se llama realmente. - **Los eventos ya forman parte de C/AL:** Desde NAV 2016, los publicadores y suscriptores pueden crear relaciones de llamada adicionales. El análisis debe tener en cuenta estos enlaces; una búsqueda de llamadas directas a funciones no los recoge por completo. **Para el análisis:** Las dependencias demostrables de forma estática y las relaciones que solo pueden resolverse con la configuración o con conocimiento del tiempo de ejecución se indican por separado. ****Transacciones y SQL** COMMIT, gestión de errores, claves y bloqueos** - **Las transacciones son en parte implícitas:** C/AL abre y cierra automáticamente las transacciones de base de datos. `COMMIT` establece un límite explícito. Un error posterior no revierte los cambios ya confirmados. - **La gestión de errores forma parte de la lógica:** Los valores devueltos por las funciones de base de datos, el valor booleano devuelto por `CODEUNIT.RUN` cuando se evalúa y `TryFunction` modifican el flujo de errores y de transacciones. Los cambios en la base de datos realizados dentro de una TryFunction no se revierten automáticamente cuando se captura un error; las escrituras permitidas dependen de la versión y de la configuración del servidor. - **C/AL influye en SQL sin mostrar SQL:** `SETCURRENTKEY`, los filtros, `LOCKTABLE`, `FINDSET`, las claves y los agregados SIFT afectan a los accesos y al comportamiento de bloqueo. Establecer una clave no garantiza un plan de ejecución SQL concreto. Los patrones llamativos ofrecen puntos de partida; su rendimiento real se mide. **Para el análisis:** La coherencia de los datos y el rendimiento solo pueden evaluarse teniendo en cuenta los límites de las transacciones, las rutas de error y el funcionamiento concreto de la base de datos. ****Historial y comparación con el estándar** Formato TXT, Version List, versiones de país y personalizaciones** - **Un formato de exportación propio y documentado:** C/SIDE gestiona los objetos en la base de datos y los exporta como FOB o TXT. El TXT contiene el código fuente y metadatos como Version List, fecha, hora y la marca Modified. Estas exportaciones pueden gestionarse con Git; no obstante, los metadatos técnicos pueden llenar las comparaciones de cambios adicionales. La propia Microsoft ofrece herramientas de comparación y conversión. - **Las personalizaciones pueden estar dentro del estándar:** En los proyectos clásicos de NAV, el código de Microsoft se modificaba a menudo directamente. La `Version List` es un indicio, no una prueba completa de los cambios. La clasificación resulta fiable al compararla con la versión de partida sin modificar que corresponda y con la documentación del proyecto disponible. - **La base correcta es decisiva:** La versión de NAV, la compilación (build) o actualización acumulativa, la versión de país y las soluciones de partners deben encajar entre sí. Las localizaciones alemana, austriaca o suiza pueden contener otros objetos estándar y otras reglas de negocio. **Para el análisis:** Solo la versión de comparación adecuada muestra qué lógica pertenece al estándar, a la localización, a un add-on o a una personalización individual. ****Ejecución, permisos e integraciones** Generaciones de cliente, permisos y puntos de entrada externos** - **La generación de NAV cambia el entorno:** El Classic Client, el RoleTailored Client desde NAV 2009, Forms y Pages, así como Dataports y XMLports, corresponden a distintas etapas de desarrollo. La interoperabilidad .NET se introdujo ya con **NAV 2009 R2**. Automation/COM, los componentes .NET y la ejecución en cliente o en servidor deben analizarse en función de la versión. - **Los permisos solo se ven en parte en la exportación:** La propiedad de objeto `Permissions` forma parte del código fuente. Además, hay que registrar los conjuntos de permisos asignados, los permisos de usuario, los filtros de seguridad y el alcance de la licencia. Los permisos indirectos pueden determinar a través de qué proceso se permite modificar los datos. - **El uso también empieza fuera del código:** Las colas de proyectos, los servicios web publicados, las rutas de archivo, los componentes externos y los sistemas SQL o EDI y tiendas online conectados pueden iniciar o controlar procesos. `GUIALLOWED` y las funciones dependientes del cliente son relevantes para las ejecuciones en segundo plano. Por eso, la ausencia de llamadas estáticas no demuestra que algo no se utilice. **Para el análisis:** La exportación TXT se complementa con la configuración autorizada, el conocimiento de las interfaces y pruebas de uso adecuadas. Las dependencias abiertas se aclaran de forma específica con TI y los departamentos funcionales. LO QUE USTED OBTIENE ### Comprender las reglas de negocio. Planificar la migración con fundamento. Un análisis sólido conecta el código C/AL, los metadatos de los objetos y el funcionamiento real. Así, las reglas, las dependencias y las preguntas abiertas resultan trazables, como base para el estándar de Business Central, los módulos adecuados y un desarrollo AL específico. [Solicitar análisis de C/AL](https://navtobc.de/es/kontakt?thema=nav-analyse) **Fuentes especializadas y contexto** Comprobado el 09/10/2026 a partir de la documentación de Microsoft. Este resumen reúne las particularidades esenciales para el análisis; los detalles dependen de la versión de NAV, del estado de los objetos y del entorno de operación. - [C/AL hasta Business Central 14 y exportaciones de objetos TXT](https://learn.microsoft.com/es-es/dynamics365/business-central/dev-itpro/developer/devenv-txt2al-tool) - [FOB/TXT: exportar e importar objetos](https://learn.microsoft.com/es-es/dynamics365/business-central/dev-itpro/cside/cside-import-objects) - [Interoperabilidad .NET en NAV 2009 R2](https://www.microsoft.com/en-us/dynamics-365/blog/no-audience/2010/10/27/net-interoperability-in-nav-2009-r2/) - [Eventos en C/AL desde NAV 2016](https://www.microsoft.com/en-us/dynamics-365/blog/business-leader/2015/10/15/integration-events-in-microsoft-dynamics-nav-2016/) - [Funciones, variables y VALIDATE en C/AL](https://www.microsoft.com/en-us/dynamics-365/blog/no-audience/2012/12/03/writing-unit-tests-in-cal/) - [FlowFields en NAV 2018](https://learn.microsoft.com/es-es/previous-versions/dynamicsnav-2018-developer/FlowFields) - [Objetos TXT, metadatos y comparación con el estándar](https://learn.microsoft.com/es-es/dynamics365/business-central/dev-itpro/upgrade/comparing-and-merging-application-object-source-files) - [TryFunctions y gestión de errores en C/AL](https://www.microsoft.com/en-us/dynamics-365/blog/business-leader/2015/10/28/nav-design-pattern-tryfunction-net-exception-handling-in-cal/) - [SingleInstance, fecha de trabajo y efectos secundarios](https://www.microsoft.com/en-us/dynamics-365/blog/it-professional/2015/10/19/test-isolation-in-the-application-test-automation-suite/) - [Comparación de lenguajes: las opciones también existen en AL](https://learn.microsoft.com/es-es/dynamics365/business-central/dev-itpro/developer/methods-auto/option/option-data-type) - [CHANGECOMPANY y contexto de los triggers (referencia de AL)](https://learn.microsoft.com/es-es/dynamics365/business-central/dev-itpro/developer/methods-auto/record/record-changecompany-method) - [Permissions y permisos indirectos (referencia de AL)](https://learn.microsoft.com/es-es/dynamics365/business-central/dev-itpro/developer/properties/devenv-permissions-property) [Así combinamos el análisis de código y la IA](https://navtobc.de/es/methoden) VERSIÓN DE PARTIDA Y ARQUITECTURA OBJETIVO ## Su versión de NAV. El camino hacia Business Central. Desde Microsoft Navision 4.0 hasta Microsoft Dynamics NAV 2018: aclaramos la versión, las fuentes disponibles y las personalizaciones. A partir de ahí elaboramos su plan individual de análisis y migración. ![De Navision a Business Central.](https://navtobc.de/film/business-central-v1/es/poster.webp) [De Navision a Business Central.](https://navtobc.de/film/business-central-v1/es/index.m3u8) NAVtoBC.de · VÍDEO EN ALEMÁN ### De Navision a Business Central. Plazos de soporte, actualización técnica o reimplantación, y qué hay que volver a evaluar antes de la transición: el vídeo explicativo en seis minutos. EL SOPORTE DE MICROSOFT DE UN VISTAZO Estado actual: 05/11/2026. Rojo: expirado · Verde: soporte extendido. **Fechas de fin del soporte por familia de productos.** Para algunas versiones originales y service packs más antiguos rigen en parte fechas anteriores. Las encontrará directamente en la fila correspondiente, en «Fin del soporte por versión». Navision y Dynamics NAV antes de Business Central, a partir de la versión 4.0 | Generación de producto | Versiones y lanzamientos | Soporte estándar hasta | Soporte extendido hasta | Estado actual | Fuente | | --- | --- | --- | --- | --- | --- | | Microsoft Navision / Dynamics NAV 4.0 | 4.0 · 4.0 SP1 · 4.0 SP2 · 4.0 SP3 **Fin del soporte por versión** 4.0 (versión original) 12/01/2010; 4.0 SP1 10/07/2007; 4.0 SP2 08/01/2008; 4.0 SP3 12/01/2010 | 12.01.2010 | No indicado\* | × Expirado | [Microsoft](https://learn.microsoft.com/es-es/lifecycle/products/dynamics-nav-40) | | Microsoft Dynamics NAV 5.0 | 5.0 · 5.0 SP1 **Fin del soporte por versión** 5.0 (versión original) 13/04/2010; 5.0 SP1 11/04/2017 | 10.04.2012 | 11.04.2017 | × Expirado | [Microsoft](https://learn.microsoft.com/es-es/lifecycle/products/dynamics-nav-50) | | Microsoft Dynamics NAV 2009 | NAV 2009 · NAV 2009 SP1 · NAV 2009 R2 **Fin del soporte por versión** NAV 2009 (versión original) 11/10/2011; NAV 2009 SP1 14/01/2020; NAV 2009 R2 14/01/2020 | 13.01.2015 | 14.01.2020 | × Expirado | [Microsoft](https://learn.microsoft.com/es-es/lifecycle/products/dynamics-nav-2009) | | Microsoft Dynamics NAV 2013 | NAV 2013 | 09.01.2018 | 10.01.2023 | × Expirado | [Microsoft](https://learn.microsoft.com/es-es/lifecycle/products/dynamics-nav-2013) | | Microsoft Dynamics NAV 2013 R2 | NAV 2013 R2 | 09.01.2018 | 10.01.2023 | × Expirado | [Microsoft](https://learn.microsoft.com/es-es/lifecycle/products/dynamics-nav-2013-r2) | | Microsoft Dynamics NAV 2015 | NAV 2015 | 14.01.2020 | 14.01.2025 | × Expirado | [Microsoft](https://learn.microsoft.com/es-es/lifecycle/products/dynamics-nav-2015) | | Microsoft Dynamics NAV 2016 | NAV 2016 | 13.04.2021 | 14.04.2026 | × Expirado | [Microsoft](https://learn.microsoft.com/es-es/lifecycle/products/dynamics-nav-2016) | | Microsoft Dynamics NAV 2017 | NAV 2017 | 11.01.2022 | 11.01.2027 | ✓ Soporte extendido | [Microsoft](https://learn.microsoft.com/es-es/lifecycle/products/dynamics-nav-2017) | | Microsoft Dynamics NAV 2018 | NAV 2018 | 10.01.2023 | 11.01.2028 | ✓ Soporte extendido | [Microsoft](https://learn.microsoft.com/es-es/lifecycle/products/dynamics-nav-2018) | **Sin fecha de desconexión automática:** El fin del soporte designa el final de la fase de soporte de Microsoft correspondiente, no el final automático del uso del software. Para recibir soporte se requiere el nivel de actualización o de service pack admitido en cada caso. Los contratos individuales con partners no forman parte de este resumen. **\* Versión 4.0:** Microsoft indica el 12/01/2010 como fin del soporte estándar, pero no una fecha de fin propia para el soporte extendido. Fuentes consultadas el 24/09/2026 . Días naturales según Microsoft Lifecycle (hora del Pacífico), sin conversión a la fecha alemana. Fuentes adicionales: [NAV 2009 R2](https://learn.microsoft.com/es-es/lifecycle/products/dynamics-nav-2009-r2) · [Directiva de Microsoft sobre soporte y service packs](https://learn.microsoft.com/es-es/lifecycle/policies/fixed). Este resumen recoge las versiones principales, así como los service packs y versiones R2 indicados. Las versiones de país, las actualizaciones acumulativas, los módulos sectoriales y las personalizaciones individuales se registran por separado en el análisis inicial. La mención de una versión no constituye una promesa general de migración directa automatizada. DE C/AL A AL ### Comprender C/AL. Planificar con precisión el camino hacia AL. No todas las personalizaciones tienen que convertirse en una extensión AL. Primero revisamos el estándar de Business Central, después los módulos ISV certificados adecuados y solo entonces el desarrollo a medida necesario. 01 / CÓDIGO FUENTE ### Análisis del código C/AL El código fuente C/AL y las exportaciones de objetos TXT de C/SIDE se examinan en busca de funciones, reglas de negocio, llamadas y dependencias. El análisis de código automatizado aporta las evidencias para la evaluación asistida por IA. **Resultado: lógica de NAV documentada.** 02 / MODELO DE DATOS ### Análisis del esquema y SQL Las tablas, los campos, las claves y las relaciones entre datos se analizan junto con las integraciones EDI, con tiendas online y de otro tipo. Los datos SQL complementan el análisis del esquema en el alcance acordado, seudonimizados si así lo desea. **Resultado: flujos de datos trazables.** 03 / ESCENARIO OBJETIVO ### ¿Estándar, ISV o extensión AL? Asignamos cada requisito necesario al estándar de Business Central, a un módulo ISV adecuado o a una extensión AL a medida debidamente justificada. La implementación técnica se acuerda por separado. **Resultado: una propuesta de migración fundamentada.** NAV 2009 R2 Y SP1 ### ¿Actualización técnica o reimplantación? Según Microsoft, una actualización técnica desde NAV 2009 R2 o SP1 pasa por NAV 2013 o 2015, NAV 2018 y Business Central 14 hasta llegar a la versión actual. Por eso, muchas empresas implantan Business Central desde cero. En ese caso, normalmente se transfieren los datos maestros, la configuración, los movimientos pendientes y los saldos de apertura. El historial contable se archiva de forma legible para cumplir los plazos de conservación. El análisis de brechas (fit-gap) determina qué personalizaciones siguen siendo necesarias. El código a medida necesario se reescribe en AL. **Aquí entra en juego el análisis de NAVtoBC:** Muestra qué lógica, datos e interfaces contiene el sistema desarrollado a lo largo de los años y de qué dependen. Fuente: [Microsoft: migrar Dynamics NAV a Business Central](https://learn.microsoft.com/es-es/dynamics365/business-central/dev-itpro/administration/migrate-nav) **¿No está claro a qué versión corresponde su sistema?** Aclaramos junto con usted el estado real de los objetos, de la aplicación y de la base de datos. [Consultar su versión de NAV](https://navtobc.de/es/kontakt) Contexto técnico: [Microsoft: programación en AL](https://learn.microsoft.com/es-es/dynamics365/business-central/dev-itpro/developer/devenv-programming-in-al) CASO DE REFERENCIA REAL ## 480.000 líneas de C/AL. Casi 1.000 codeunits. **Conocimiento para la operación diaria.** En este proyecto de cliente se incluyeron en el análisis el código fuente de Navision, la base de datos SQL de Navision y todas las demás bases de datos SQL conectadas. Los datos se analizaron de forma seudonimizada. CÓDIGO C/AL **480.000 líneas** CODEUNITS **Casi 1.000** SISTEMA **NAV 2009 R2** VOLUMEN DE DATOS **aprox. 1,5 TB** ANTIGÜEDAD DEL SISTEMA **20 años** SECTOR **Comercio mayorista y B2C** PROYECTO DE REFERENCIA ### Comprender el sistema. Decidir con fundamento. El código fuente, la lógica de negocio, las funciones y los flujos de datos se registraron, estructuraron y contrastaron sistemáticamente con el estándar de Business Central y con módulos ISV adecuados. EL CONOCIMIENTO ADQUIRIDO, EN USO ### Encontrar errores. Documentar el conocimiento. Preparar cambios. 01 ### Apoyar la búsqueda de errores. Analizar relaciones con IA y acotar las posibles causas de los errores. 02 ### Crear documentación. Documentar de forma específica áreas concretas, por ejemplo, los flujos de datos EDI. 03 ### Preparar cambios. Desarrollar propuestas concretas para Navision, por ejemplo, para dar soporte a ZUGFeRD. TESTIMONIO DE CLIENTE ### Hoy, este conocimiento nos ayuda de forma muy práctica. > «En nuestro sistema Navision se analizaron 480.000 líneas de código C/AL de casi 1.000 codeunits. Además de nuestra base de datos SQL de Navision, también se incluyeron todas las demás bases de datos SQL conectadas. Los datos se analizaron de forma seudonimizada. > > Hoy aprovechamos el conocimiento adquirido de forma muy práctica: la IA nos ayuda a buscar errores y a entender las relaciones dentro del sistema. Podemos generar documentación de áreas concretas con solo pulsar un botón, por ejemplo, sobre nuestros flujos de datos EDI. > > Además, recibimos propuestas concretas de cambios y ampliaciones en Navision, por ejemplo, para dar soporte a ZUGFeRD. Así, el análisis ya nos ayuda en la operación diaria y, al mismo tiempo, crea una base sólida para el desarrollo futuro de nuestro sistema.» Testimonio de cliente de un proyecto de análisis de NAV RESULTADO **Una base de conocimiento estructurada, relaciones visualizadas y una propuesta de migración trazable para Business Central.** [Solicitar un proyecto de análisis similar](https://navtobc.de/es/kontakt?thema=nav-analyse) ESTÁNDAR ANTES QUE SOLUCIONES A MEDIDA ## Primero, el estándar de Business Central. Menos código a medida. No todas las personalizaciones de NAV acumuladas a lo largo de los años tienen que migrarse. Revisamos cada requisito necesario en este orden, junto con sus departamentos funcionales. ![Primero, el estándar de Business Central.](https://navtobc.de/film/standard-zuerst-v1/es/poster.webp) [Primero, el estándar de Business Central.](https://navtobc.de/film/standard-zuerst-v1/es/index.m3u8) NAVtoBC.de · VÍDEO EN ALEMÁN ### Primero, el estándar de Business Central. Código a medida sustituido por un módulo ISV. 1. 01 PRIMERO ### Usar el estándar. Las funciones y la configuración de Business Central tienen prioridad. Analizamos cómo pueden alinearse sus procesos con el estándar sin renunciar a los requisitos de negocio necesarios. **Se da preferencia al estándar de Business Central.** 2. 02 DESPUÉS ### Módulos certificados. Si el estándar no es suficiente, evaluamos módulos sectoriales y funcionales certificados que encajen. En la medida de lo posible, las programaciones a medida se sustituyen por estas extensiones. **Módulos adecuados antes que nueva programación.** 3. 03 SOLO SI ES NECESARIO ### Desarrollar de forma selectiva. El desarrollo a medida se reserva para requisitos necesarios para el negocio que no cubren ni el estándar ni los módulos adecuados. Las brechas restantes se documentan y se justifican. **Cada desarrollo propio, con su justificación.** **Cómo seleccionamos los módulos** Evaluamos la idoneidad funcional, las integraciones, los costes de licencia y mantenimiento, el soporte del fabricante y la compatibilidad con la versión objetivo, el país y el modelo de operación. Las acreditaciones de certificación o validación se comprueban para el módulo concreto y la versión correspondiente. Una validación de Marketplace no es una garantía general para su proceso de negocio. La idoneidad se evalúa por separado en el proyecto. [Microsoft: validación técnica de apps](https://learn.microsoft.com/es-es/dynamics365/business-central/dev-itpro/developer/devenv-checklist-submission) CASO PRÁCTICO / INTEGRACIÓN CON AMAZON ### Código a medida sustituido por un módulo ISV. **Comprender la lógica de negocio acumulada. Sustituir de forma selectiva las interfaces a medida.** Una integración con Amazon desarrollada a medida en Navision contenía lógica C/AL propia para procesar la información de pedidos y envíos. El código fuente tiene en cuenta, entre otras cosas, las líneas ya enviadas, las asignaciones existentes a pedidos de Navision y los distintos centros logísticos (Fulfillment Centers). **En este ejemplo, la programación a medida existente se sustituyó por un módulo ISV para la integración con Amazon.** DE LA PERSONALIZACIÓN A LA SOLUCIÓN MODULAR ANTES **Integración con Amazon a medida** Lógica C/AL propia en Navision SUSTITUCIÓN **Módulo ISV para Amazon** Programación a medida existente sustituida Conservar la lógica de negocio – **no trasladar el código a medida sin revisarlo.** Para planificar la migración, lo decisivo es conocer las reglas de negocio existentes y comprobar su cobertura en la nueva solución. Lo que debe conservarse no es el antiguo código del programa sin cambios, sino la función necesaria desde el punto de vista del negocio. **Nuestro análisis asistido por IA apoya la preparación de su migración de Navision a Business Central:** Hace comprensibles la lógica de negocio, las dependencias y las interfaces. Así se puede decidir con fundamento qué cubre el estándar, dónde encaja un módulo ISV adecuado y qué desarrollo AL a medida sigue siendo realmente necesario. **Ver el código fuente C/AL y las reglas de negocio detectadas** **Extracto de código fuente C/AL facilitado por el responsable de este sitio.** El extracto no se ha modificado y termina en mitad de una sección de procesamiento. No es un programa completo ni ejecutable. C/AL · Extracto de la antigua integración con Amazon ``` CLEAR(l_HoldOpen); l_SalesLineAmazon.RESET; l_SalesLineAmazon.SETRANGE("Amazon Document Type",p_SalesHeaderAmazon."Amazon Document Type"); l_SalesLineAmazon.SETRANGE("Amazon-Order-Id",p_SalesHeaderAmazon."Amazon-Order-Id"); l_SalesLineAmazon.SETFILTER("Navision Order No.",'=%1',''); l_SalesLineAmazon.SETFILTER("Quantity-Shipped",'>%1',0); // AKT#032 IF NOT l_SalesLineAmazon.FIND('-') THEN BEGIN EXIT; END ELSE BEGIN // AKT#038 BEG l_FulfillmentCenterId := l_SalesLineAmazon."Fulfillment-Center-Id"; IF l_FulfillmentCenterId<>'' THEN BEGIN p_SalesHeaderAmazon."Fulfillment-Center-Id" := l_FulfillmentCenterId; p_SalesHeaderAmazon."Shipment-Date" := l_SalesLineAmazon."Shipment-Date" END; REPEAT IF l_FulfillmentCenterId <> l_SalesLineAmazon."Fulfillment-Center-Id" THEN l_HoldOpen := TRUE; UNTIL l_SalesLineAmazon.NEXT=0; // AKT#038 END END; // Funktion für Navision Auftragserstellung CLEAR(WarningMessageOrder); CLEAR(ShippingCost); IF (p_SalesHeaderAmazon."Order No." = '') AND (p_SalesHeaderAmazon."Amazon-Order-Id" <>'') THEN BEGIN //(p_SalesHeaderAmazon."Error Message"='') THEN BEGIN //Fehlerprüfung?? ``` #### Qué se puede deducir de este extracto **01 / Acotar el pedido correspondiente** Las líneas se filtran por tipo de documento de Amazon y número de pedido de Amazon. **02 / Seleccionar las líneas de envío aún no asignadas** El número de pedido de Navision debe estar vacío y la cantidad enviada debe ser mayor que cero. Si no se encuentra ninguna línea adecuada, esta llamada a la función finaliza con `EXIT`. **03 / Transferir la información de envío** Si el ID del centro logístico (Fulfillment Center ID) de la primera línea encontrada está informado, ese ID y la fecha de envío se transfieren a la variable de cabecera del documento. El extracto no muestra que este cambio se guarde. **04 / Detectar centros logísticos distintos** Si alguna de las líneas encontradas difiere del ID de centro determinado en primer lugar, `l_HoldOpen` se establece en `TRUE`. **05 / Preparar el procesamiento posterior del pedido** La sección siguiente presupone un número de pedido vacío y un número de pedido de Amazon existente en la cabecera. La comprobación del mensaje de error que figura a continuación está comentada y, por tanto, no está activa. **Límites del extracto:** La creación del pedido propiamente dicha, el efecto posterior de `l_HoldOpen` y el proceso completo de pedidos y envíos no se incluyen aquí. La sustitución realizada es una información práctica del responsable de este sitio; el código por sí solo no demuestra ni la cobertura funcional del módulo ni una puesta en producción (go-live) de Business Central ya completada. ¿Cuáles de sus personalizaciones de NAV pueden sustituirse de forma razonable? [Evaluar el potencial de sus personalizaciones de NAV](https://navtobc.de/es/kontakt?thema=standard-module) **Su resultado:** Una matriz de decisión para cada personalización: sustituir por el estándar, evaluar un módulo certificado o desarrollar a medida de forma justificada. Los requisitos aún no aclarados siguen estando visibles. JUNTOS HACIA BUSINESS CENTRAL ## Su partner de implantación sigue a su lado. Nosotros complementamos el análisis. **Colaboración en lugar de cambio de partner: para una migración a Business Central eficiente y ágil.** Apoyamos a su actual partner de implantación de Navision y a su TI interna con datos de análisis preparados, reglas de negocio documentadas y una base sólida para la toma de decisiones. **No se trata de sustituir a su partner actual, sino de complementar de forma específica el know-how de este y el conocimiento de sus propios empleados.** Trabajamos con los partners que usted elija, sin depender de ningún partner de implantación concreto. La migración técnica puede seguir a cargo de su partner actual, de su departamento de desarrollo interno o de ambos conjuntamente. 01 / PARTNER ### Para su partner de implantación de Navision **Más transparencia para la planificación y la implementación.** Su partner conoce su empresa y acompaña su solución. Nosotros complementamos ese conocimiento con un análisis sistemático del código C/AL, los objetos, los flujos de datos y las interfaces. Los resultados estructurados ayudan a evaluar las personalizaciones, detectar dependencias y preparar de forma específica la migración a Business Central: **aprovechar las funciones estándar, utilizar módulos ISV adecuados y reimplementar en AL solo el desarrollo a medida necesario.** 02 / TI INTERNA ### Para su TI interna **Preservar el conocimiento acumulado. Aliviar la carga de su equipo.** También apoyamos directamente a su departamento interno de Navision en la preparación de la migración. La documentación de objetos con búsqueda, las reglas de negocio extraídas y una base de datos de grafos hacen comprensibles las relaciones y facilitan la coordinación entre TI, departamentos funcionales y partners de implantación. **El conocimiento de sus empleados sigue siendo decisivo. Nuestro análisis lo complementa con una base estructurada y verificable.** 03 / INDEPENDIENTE ### También sin la participación de un partner de implantación **El análisis puede realizarse de forma independiente.** También puede encargar el análisis de Navision al margen de un proyecto de migración y sin la colaboración activa de un partner externo. Acordamos directamente con usted los accesos y las fuentes de análisis necesarios. A continuación, los resultados quedan a su disposición para la operación diaria, su planificación interna y la colaboración con el partner que usted elija. ### Tres preguntas para la conversación con su partner de implantación 1. **¿Qué datos transferimos y cómo se asignan?** Muchas tablas estándar, como Cliente, Producto o Cabecera venta, siguen existiendo. Lo decisivo son los campos propios, los valores de opción y las series numéricas. 2. **¿Qué personalizaciones se desarrollarán de nuevo en AL y con qué esfuerzo?** El conversor Txt2Al de Microsoft solo existió con Business Central 14. No procesa los Forms ni los Dataports de NAV 2009 R2. 3. **¿Cómo transferimos dimensiones como el centro de coste y el objeto de coste?** Hoy en día, los movimientos remiten a sus dimensiones a través de un conjunto de dimensiones. En una reimplantación cuentan sobre todo las dimensiones predeterminadas, los movimientos pendientes y el código que procesa dimensiones. **El análisis de NAVtoBC aporta la base para las tres preguntas:** Tablas y campos con pruebas de uso, personalizaciones con sus dependencias y los puntos en los que el código lee o escribe dimensiones. **Su ventaja:** Todos los implicados trabajan con una base de conocimiento común y trazable, en lugar de tener que reconstruir una y otra vez las mismas relaciones. [Hablar sobre la colaboración](https://navtobc.de/es/kontakt) VER LOS RESULTADOS EN LUGAR DE SOLO LEER SOBRE ELLOS ## Del conocimiento de los procesos al escenario objetivo en Business Central. Un ejemplo completo y coherente: cliente, pedido y factura. Alterne entre Análisis, Procesos, Saber y Roadmap. Ejemplo ilustrativo con datos sintéticos, no un proyecto de cliente. NAV → Business Central EJEMPLO SINTÉTICO RESULTADO DE EJEMPLO ## La visión global. De un vistazo. EJEMPLO DE ANÁLISIS SINTÉTICO .txt`// Valores sustitutos coherentesCliente.Nombre: "P-7Q4X9"Cliente.ID: "K-7Q4X9"Pedido.Cliente: "K-7Q4X9"Factura.Cliente: "K-7Q4X9"` **Comprender las relaciones** El mismo cliente en pedido y factura Fuente: datos de ejemplo sintéticos Revisión funcional Solo artefactos de análisis validados con valores sustitutos coherentes TRAZABLE DE PRINCIPIO A FIN ### Mismo cliente. Documentos vinculados. Decisiones verificables. 1. **Detectar la relación** «P-7Q4X9» sigue vinculado al pedido y a la factura a través del identificador de cliente K-7Q4X9. 2. **Documentar el conocimiento** El artículo de conocimiento recoge la relación junto con el campo de origen y el estado de verificación funcional. 3. **Evaluar el escenario objetivo para Business Central** Comprobar primero la cobertura del estándar. Solo los requisitos restantes llevan a la evaluación de módulos o al desarrollo a medida. [Ver la seudonimización en el ejemplo](https://navtobc.de/es/pseudonymisierung) **Ver un ejemplo de matriz de decisión** Formato de decisión sintético; no es una recomendación verificada de módulos ni para clientes. | Requisito del ejemplo | Vía de evaluación | Siguiente paso | Estado | | --- | --- | --- | --- | | Asignar cliente y documentos | Primero, el estándar de Business Central | Contrastar el flujo y la configuración desde el punto de vista funcional | Revisión del estándar pendiente | | Requisito sectorial adicional | Módulo certificado, si el estándar no basta | Evaluar idoneidad, evidencias, integración y costes | Revisión de módulos pendiente | | Regla especial restante | Desarrollo a medida solo si se confirma una brecha | Documentar la necesidad y las alternativas | Ningún desarrollo validado | DEL RESULTADO DEL ANÁLISIS AL PORTAL DE CONOCIMIENTO ## Su conocimiento de NAV.En diálogo directo. Haga preguntas sobre su sistema Navision con la misma facilidad que en una interfaz de chat inspirada en ChatGPT. El portal web pone a su disposición el conocimiento documentado por la IA: reglas de negocio, flujos, interfaces y relaciones técnicas pasan a ser accesibles a través del diálogo. En segundo plano, una IA conectada por API procesa sus consultas e incorpora la base de conocimiento recopilada en local. Si es necesario, el portal también puede incorporar datos actuales de la base de datos de Navision y de otros recursos a través de interfaces validadas de solo lectura. [Abrir la vista del portal a tamaño completo](https://navtobc.de/images/nav-wissensportal.png) UN VISTAZO AL PORTAL DE CONOCIMIENTO Análisis de proyecto NAV [![Portal de conocimiento «Análisis de proyecto NAV»: campo de chat para preguntas sobre el proyecto y accesos directos a la visión general, las relaciones y los puntos abiertos.](https://navtobc.de/images/nav-wissensportal.png)](https://navtobc.de/images/nav-wissensportal.png) Utilice los resultados del análisis y las fuentes de datos validadas a través de una interfaz de chat común. **Inicio de sesión con usuarios locales** El acceso se realiza mediante cuentas de usuario locales. Así, el uso queda asociado a un usuario autenticado. **Permisos asignados con precisión** La gestión de permisos determina qué información y recursos validados puede consultar cada usuario. **Acceso exclusivamente de lectura** Las fuentes de datos conectadas solo se leen. El portal no modifica datos de NAV ni otros datos de origen. **Registro de consultas** Todas las consultas quedan registradas. De este modo, el uso del portal sigue siendo trazable. Acordamos con usted qué fuentes de conocimiento, fuentes de datos en tiempo real y permisos se integran en su proyecto. [Descubra el portal de conocimiento](https://navtobc.de/es/kontakt?thema=wissensportal) EXPERIENCIA Y METODOLOGÍA ## Muchos años de experiencia con Navision. Aprovechada de forma sistemática con IA. Combinamos el conocimiento práctico de Navision con el análisis automatizado de código y la evaluación asistida por IA. El resultado son relaciones documentadas y propuestas concretas para su sistema actual y para el camino hacia Business Central. Navision Dynamics NAV MS Dynamics NAV Business Central EL ENFOQUE NAVtoBC ## Primero entender. Después cambiar con criterio. Años de personalizaciones no tienen por qué ser un obstáculo. Lo decisivo es identificar qué lógica necesita realmente su negocio hoy. 01 Análisis con IA ### Entender el NAV existente. Analizar con un parser propio de C/AL las exportaciones de objetos TXT validadas: registrar la lógica a medida, las llamadas, las referencias y las interfaces con referencia a la fuente. SU RESULTADO **Inventario técnico** 02 Procesos de negocio ### Derivar los flujos a partir de la lógica. Extraer de las fuentes hipótesis de procesos y reglas de negocio, documentarlas como conjunto de reglas JSON y como grafos, y validarlas funcionalmente. SU RESULTADO **Mapa de procesos documentado** 03 Base de conocimiento ### Conocimiento aprovechable a largo plazo. Registrar los hallazgos de forma estructurada: con referencia a la fuente, contexto funcional y un estado de verificación trazable. SU RESULTADO **Su base de conocimiento central** 04 Propuesta de migración para Business Central ### Preparar el camino adecuado. Dar preferencia al estándar de Business Central, evaluar módulos certificados e incluir solo el desarrollo a medida necesario en una hoja de ruta priorizada. SU RESULTADO **Plan de migración fundamentado** La IA apoya el análisis. Los departamentos funcionales validan los resultados y deciden sobre los procesos objetivo. ALCANCE CLARO DEL SERVICIO ## Una base clara. Un siguiente paso acordado. Nuestra oferta, tal como se describe aquí, comprende el análisis de su sistema NAV, la documentación de su conocimiento de procesos y una propuesta de migración fundamentada para Business Central. **La implantación, las pruebas y la puesta en marcha se acuerdan por separado.** Los resultados sirven de base para su equipo interno, su partner actual o una implantación acordada posteriormente. [Hablar del alcance de su proyecto](https://navtobc.de/es/kontakt) LA PROTECCIÓN DE DATOS EMPIEZA ANTES DEL ANÁLISIS ## Importa su conocimiento de procesos. No sus datos sensibles. El análisis requiere acceso SQL, pero no directamente por parte de la IA. Un servidor de seudonimización intermedio accede a la base de datos de forma controlada y sustituye los valores identificativos sobre la marcha («on the fly») antes de que los resultados validados pasen al análisis. SU CÓDIGO FUENTE SIGUE SIENDO SU CONOCIMIENTO ### Su código fuente no se utiliza para entrenar modelos de IA. Es un requisito previo para cualquier análisis: solo se utilizan modelos de operación en los que está excluido el uso de su código fuente con fines de entrenamiento. En los servicios en la nube, esto se verifica a partir de las condiciones y configuraciones acordadas; en local, el análisis se realiza sin utilizar su código fuente para entrenar modelos. 01 / ACCESO SQL CONTROLADO ### Acceso SQL con protección intermedia. El servidor de seudonimización intermedio recibe el acceso SQL acordado. Procesa los datos, las estadísticas de uso y los indicadores de volumen de datos antes de transmitirlos. Ni las credenciales SQL ni las copias de seguridad de la base de datos llegan a la IA o al sitio web. Las exportaciones de objetos y metadatos complementan el análisis. 02 / SOBRE LA MARCHA ### Sustituir valores. No borrarlos. Durante la lectura, los valores identificativos se sustituyen por valores sustitutos coherentes de forma permanente. El cliente de ejemplo «Müller» recibe el seudónimo «P-7Q4X9», también en consultas posteriores del mismo conjunto de datos de análisis. Se conservan los registros y las relaciones necesarias desde el punto de vista funcional. 03 / TRAZABLE ### Las relaciones se mantienen. Unas reglas de sustitución acordadas garantizan la correspondencia entre clientes, pedidos y facturas. Tras la verificación y la validación, los resultados se analizan en local o con una IA en la nube acordada. Las reglas de negocio se derivan del código y de las relaciones del sistema. EN SU ENTORNO **NAV / SQL y exportaciones de objetos TXT** → **Servidor de protección: sustituir valores** → **Verificar y validar** ANÁLISIS: LOCAL O EN LA NUBE **Análisis asistido por IA** → **Conocimiento y hoja de ruta de Business Central** El entorno de análisis puede estar completamente en local. En la operación en la nube, solo salen de su entorno los artefactos validados para ello, con valores sustitutos coherentes. Sin cambio automático de local a la nube. Sin acceso SQL directo por parte de la IA [Acordar la protección de datos de su proyecto](https://navtobc.de/es/kontakt?thema=datenschutz) SUSTITUIR DATOS. CONSERVAR LAS RELACIONES. ## Müller se convierte en P-7Q4X9. La relación se mantiene. Antes del procesamiento por la IA, los valores identificativos se sustituyen por seudónimos persistentes. Un mismo cliente, asignado de forma unívoca, recibe el mismo valor sustituto dentro del conjunto de datos de análisis acordado, también en consultas posteriores. Clientes distintos con el mismo apellido reciben seudónimos diferentes. Las relaciones entre clientes, pedidos y facturas siguen siendo trazables. Así se pueden analizar procesos de negocio, dependencias y reglas del programa sin necesidad de los nombres originales. La seudonimización afecta a los datos de análisis; los datos productivos de NAV no se modifican. La correspondencia con los valores originales se almacena por separado y con acceso protegido, y no se transmite a la IA. Para el responsable del tratamiento, los datos siguen siendo datos personales. [Seudonimización: art. 4, punto 5, del RGPD ↗](https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX%3A32016R0679) La seudonimización con un ejemplo DATOS SINTÉTICOS **Nombre** P-7Q4X9 **N.º de cliente** K-7Q4X9 **Correo electrónico** p-7q4x9@example.invalid **Cliente en el pedido** P-7Q4X9 · K-7Q4X9 **Cliente en la factura** P-7Q4X9 · K-7Q4X9 MISMO CLIENTE. MISMO VALOR SUSTITUTO. **P-7Q4X9 sigue siendo P-7Q4X9, en el pedido y en la factura.** SU INFRAESTRUCTURA. SU ESTRATEGIA DE IA. ## IA en la nube o IA local. Usted decide. ChatGPT, Claude y cualquier otra IA en la nube son posibles opciones de operación. O bien utilice diversos modelos locales: en su hardware o en hardware que le prestamos para el proyecto. Acordamos con usted la conexión concreta. IA EN LA NUBE ### ChatGPT, Claude. Y su IA en la nube. No está vinculado a ningún proveedor concreto. ChatGPT, Claude y otras IA en la nube apoyan los pasos de análisis validados. Acordamos el proveedor, el modelo y las interfaces disponibles en función de cada proyecto. ChatGPT · OpenAI Claude · Anthropic Otras IA en la nube **Detalles del modelo de operación** **Flujo de datos** Antes del procesamiento por la IA, sustituir de forma coherente los valores identificativos, verificarlos y validarlos. **Integración** Conectar el proveedor elegido mediante interfaces adecuadas, configuradas por separado. **Coordinación** Revisar previamente las condiciones contractuales, el tratamiento de datos y la conservación. [Hablar de IA en la nube](https://navtobc.de/es/kontakt) IA LOCAL ### Su hardware. O el nuestro, en préstamo. Diversos modelos de IA locales se ejecutan en su propio hardware. Como alternativa, le proporcionamos hardware adecuado en préstamo para el proyecto. La elección del modelo y el equipamiento dependen de sus tareas de análisis. Su hardware Hardware en préstamo Diversos modelos **Detalles del modelo de operación** **Flujo de datos** También en local: valores sustitutos coherentes y validación antes del procesamiento por la IA. **Operación** Análisis local en hardware propio o prestado, dentro de su entorno. **Delimitación** Sin reenvío automático a servicios en la nube. Controlar las conexiones salientes. [Hablar de IA local](https://navtobc.de/es/kontakt) COMBINABLE OPCIONALMENTE ### Local y en la nube. Combinados con criterio. Algunas tareas de IA en local, otras en la nube, con validación propia para cada paso de procesamiento. **Sin fallback automático a la nube.** Los mismos criterios de calidad se aplican a todos los modelos de operación. [Definir el modelo de operación](https://navtobc.de/es/kontakt) Los modelos y las integraciones concretos se acuerdan en el proyecto. El modelo de operación de IA es independiente de si Business Central se utilizará después online o en local. OTROS ANÁLISIS CON IA ### Analizar Active Directory con IA. En KI4AD.de encontrará más información sobre el análisis de su Active Directory asistido por IA. [Visitar KI4AD.de](https://ki4ad.de/) TÉCNICAS Y MÉTODOS ASISTIDOS POR IA ## Análisis profundo de C/AL. Resultados trazables. Parser propio, apoyo específico de la IA y cadenas de verificación vinculantes: nuestro enfoque de análisis combina hallazgos técnicos con comprensión funcional. ### Nota sobre la fiabilidad del análisis **La IA comete errores.** En ningún análisis se puede garantizar la exhaustividad ni la ausencia de errores, tampoco en un trabajo puramente manual. El objetivo es una **base de trabajo suficientemente fundamentada para su migración**. Por eso hacemos visibles las incertidumbres y los puntos abiertos, y revisamos los resultados junto con sus departamentos funcionales. EL PROCESO DE ANÁLISIS EN VÍDEO 3D ### Del flujo de datos al análisis con IA. 60 segundos ![Vídeo 3D sobre datos, interfaces y análisis con IA](https://navtobc.de/es/film/datenfluss-v1.webp) [Vídeo 3D sobre datos, interfaces y análisis con IA](https://navtobc.de/es/film/navtobc-datenfluss-v1.mp4) Conectar interfaces, estructurar el sistema NAV existente, validar datos y analizar y contrastar los hallazgos mediante IA. Una representación esquemática con datos de ejemplo, sin sonido. [Abrir el reproductor 3D interactivo](https://navtobc.de/es/film/index.html) [Descargar el vídeo en MP4](https://navtobc.de/es/film/navtobc-datenfluss-v1.mp4) **Las cinco escenas del vídeo en texto** 1. **00:00 · Interfaces.** Los datos de EDI, la tienda online, SQL y C/AL fluyen hacia el sistema NAV. 2. **00:12 · Procesamiento en NAV.** El código fuente, las tablas y las referencias se registran de forma estructurada. 3. **00:24 · Validación de datos.** Los valores sustitutos coherentes mantienen las relaciones entre la información validada. 4. **00:34 · Análisis con IA.** Roles separados analizan y verifican evidencias, contradicciones y preguntas abiertas. 5. **00:48 · Resultados.** Las reglas de negocio, la base de conocimiento y el escenario objetivo de BC se vuelven trazables, con fuentes y estado de verificación. **Métodos en detalle 8 métodos de análisis y verificación** 01 ENTENDER EL CÓDIGO ### Análisis estático de código C/AL Un parser propio de C/AL registra las llamadas y referencias en el código fuente de Navision facilitado. A partir de ahí se genera un grafo de llamadas y referencias con precisión de función y línea, que sirve de base para la clasificación asistida por IA. **Método en detalle** Cada hallazgo remite al objeto, la función y la línea de la exportación validada. Las llamadas dinámicas no resolubles, los objetos que faltan y los límites del parser se marcan de forma visible, en lugar de presentarse como analizados con certeza. 02 DETERMINAR LA RELEVANCIA ### Alcanzabilidad desde la lista de anclas Análisis de alcanzabilidad a partir de una lista de anclas acordada con los departamentos funcionales, en lugar de ir descartando de forma iterativa. Las dependencias se siguen desde puntos de entrada conocidos. **Método en detalle** La lista de anclas incluye, por ejemplo, informes ejecutados, colas de proyectos y llamadas externas. «No alcanzable desde las anclas registradas» no significa automáticamente «sin uso». Las rutas poco claras siguen sujetas a revisión. 03 ACREDITAR EL USO ### Evidencia de uso por tabla Las estadísticas de acceso SQL y los indicadores agregados de volumen de datos complementan el análisis de código. El servidor de seudonimización intermedio proporciona los resultados validados, actualizados a diario si la recopilación y el procesamiento son diarios. **Método en detalle** Se registran el momento de la recopilación, el período de observación y los indicios de reinicios de las estadísticas. El acceso SQL se realiza a través del servidor intermedio; la IA solo recibe resultados validados. La ausencia de accesos no demuestra que no haya uso; el volumen de datos y el contexto funcional se evalúan por separado. En una reimplantación, la evidencia de uso muestra qué tablas y datos son candidatos al traspaso. Las versiones antiguas de NAV exportan el texto con el juego de caracteres de MS-DOS; por eso, los caracteres especiales, como las diéresis, se comprueban antes del traspaso. 04 CONTRASTAR LOS RESULTADOS ### Cadenas de verificación multiagente Roles de agente separados para el análisis, la verificación cruzada y la consolidación. Las afirmaciones se vinculan a las fuentes; las contradicciones y las preguntas abiertas siguen siendo trazables. [![Claude Code muestra una cadena de verificación en curso con tres agentes de IA trabajando en paralelo y las fases Verify y Critique.](https://navtobc.de/claude-code-pruefkette.png) Abrir el ejemplo a tamaño completo](https://navtobc.de/claude-code-pruefkette.png) **Ejemplo de Claude Code.** Tres agentes de IA revisan en paralelo un inventario de herramientas. A continuación está prevista una verificación cruzada crítica. **Método en detalle** La verificación cruzada evalúa las evidencias, la cobertura y las explicaciones alternativas. La coincidencia entre varios agentes no es, por sí sola, una prueba de corrección. Siguen siendo necesarias las validaciones funcionales y las barreras de control técnicas. 05 VERIFICAR LA CALIDAD ### Autopruebas, pruebas de mutación, sumas de control Las autopruebas comprueban los resultados esperados. Las pruebas de mutación modifican casos de prueba de forma deliberada. Las sumas de control asignan los hallazgos de forma inequívoca a las versiones verificadas de los artefactos. **Método en detalle** Las pruebas de mutación comprueban si se detectan errores introducidos a propósito. Las sumas de control sirven para cotejar versiones e integridad; no demuestran la corrección funcional ni la protección de los datos personales. Las verificaciones fallidas bloquean la validación de los resultados. 06 APRENDER DE LOS ERRORES ### Proceso vinculante de aprendizaje de errores Cada error confirmado da lugar a un análisis de causas, una prueba de regresión y una regla versionada. Las reglas ancladas mecánicamente se verifican de forma automatizada, no se quedan en una simple nota. **Método en detalle** Un caso de error solo se cierra tras una demostración reproducible, la corrección y una prueba de regresión superada. Las barreras de control impiden la validación si se infringen reglas. Se documentan la versión de las reglas y la responsabilidad. 07 MEJORAR PUNTOS DÉBILES ### Tablas SQL, CU y ports Los puntos débiles detectados en tablas SQL, Codeunits (CU) y Dataports/XMLports se traducen en propuestas de mejora concretas, con hallazgo, prioridad y paso de verificación. **Método en detalle** Por ejemplo, se examinan patrones de acceso llamativos, lógica redundante y validaciones de importación insuficientes. Las suposiciones sobre el rendimiento siguen siendo hipótesis hasta que se miden. Los cambios en el sistema productivo no se realizan automáticamente. 08 PRESERVAR EL CONOCIMIENTO DE NEGOCIO ### Extracción de reglas de negocio Reglas de negocio como conjunto de reglas JSON legible por máquina y como grafos: con condiciones, acciones, dependencias, referencias a las fuentes y estado de verificación funcional. **Método en detalle** Las reglas reciben ID estables y referencias a la función y la línea de la exportación validada. Las reglas confirmadas se incorporan a la base de conocimiento y al análisis de brechas (fit-gap) para Business Central. La información que falta y los supuestos no acreditados quedan señalados. ### Preguntas en profundidad **¿Cómo se obtiene una evidencia de uso actualizada a diario? +** El servidor intermedio lee las estadísticas de acceso SQL y los indicadores de volumen de datos acordados. Antes de transmitirlos, los valores identificativos se sustituyen por valores sustitutos coherentes. La actualización diaria requiere una recopilación diaria y un procesamiento correcto; se indican la fecha de los datos y la ventana de observación. Los contadores de uso de SQL pueden ponerse a cero, por ejemplo, tras un reinicio del servidor. Por eso, la ausencia de señales de acceso no demuestra que no haya uso; y los datos existentes, por sí solos, tampoco demuestran un proceso de negocio activo. **¿Por qué analizan la alcanzabilidad desde una lista de anclas?+** Empezamos en puntos de entrada acordados con los departamentos funcionales y, desde ahí, seguimos las relaciones de llamada y referencia. Esto sustituye el descarte puramente iterativo de objetos aparentemente sin uso. Las listas de anclas incompletas, las llamadas dinámicas y las exportaciones que faltan se marcan expresamente como límites. El análisis no elimina objetos ni sustituye la decisión funcional de retirarlos. **¿Qué reglas de negocio recibimos como JSON y grafos?+** El resultado previsto contiene, para cada regla de negocio extraída, un ID, condiciones, acciones, dependencias y referencias a la fuente (objeto, función y línea). Un grafo de reglas muestra las relaciones. El estado de verificación y los supuestos abiertos se conservan; solo la confirmación funcional convierte un borrador de regla en una base de conocimiento validada. **¿Qué significa un proceso de aprendizaje de errores anclado mecánicamente?+** Los errores confirmados se documentan como casos reproducibles y se aseguran mediante pruebas de regresión y reglas de verificación versionadas. Estas reglas se controlan de forma automatizada y pueden bloquear una validación. Para ello no basta con una simple indicación adicional a un agente de IA. **¿Cómo se integran Claude y ChatGPT en procesos automatizados?+** El uso de ChatGPT y una integración a través de la API de OpenAI deben considerarse por separado. Para las cadenas de verificación automatizadas se configura, en cada proyecto, una conexión a través de la API de OpenAI o de la API de Claude. Una suscripción a ChatGPT no sustituye la facturación independiente de la API. [OpenAI: ChatGPT y la API, por separado ↗](https://help.openai.com/en/articles/8156019-how-can-i-move-my-chatgpt-subscription-to-the-api) · [Anthropic: API de Claude ↗](https://platform.claude.com/docs/en/api/overview) NUESTRO COMPROMISO DE CALIDAD Cada afirmación, con su evidencia. **Cada incertidumbre, a la vista.** El análisis determinista de código y la IA se complementan. Lo que las fuentes no acreditan se señala como abierto y se aclara con sus departamentos funcionales. [Hablar del análisis](https://navtobc.de/es/kontakt) Los métodos combinan hallazgos técnicos con revisión funcional y documentación trazable. CONVIENE SABER ## Las preguntas importantes. Antes del primer paso. No todas las personalizaciones tienen que migrarse. Pero cada regla crítica para el negocio merece atención. [Hablar de su situación](https://navtobc.de/es/kontakt) **¿Se analiza C/AL automáticamente?** **Sí.** Nuestra herramienta de análisis propia analiza automáticamente el código fuente C/AL de su sistema Navision o Dynamics NAV. Los resultados se documentan de forma estructurada por objeto y se almacenan de modo que puedan consultarse mediante búsqueda. **¿Disponen de una herramienta de análisis propia?** **Sí.** Utilizamos una herramienta de análisis propia para el análisis automatizado de NAV. **¿Se analizan directamente los FOB de NAV?** **No.** Nuestra herramienta de análisis lee exportaciones de objetos TXT con código C/AL y propiedades de objetos. Si los objetos están en formato FOB, primero se importan en un entorno de desarrollo de NAV adecuado y allí se exportan como TXT con la licencia de desarrollador necesaria. Los archivos FOB nativos no se procesan directamente. [Particularidades de C/AL y base del análisis en detalle →](https://navtobc.de/es/cal-besonderheiten) **¿Existe una transformación automática a código AL?** **No.** El código C/AL existente no se convierte automáticamente en código AL. Primero evaluamos el estándar de Business Central y los módulos ISV adecuados. Solo el desarrollo a medida que siga siendo necesario se **reescribe en AL** a partir de la lógica de negocio requerida, en lugar de trasladar el código antiguo uno a uno. **¿Qué versiones de destino de Business Central se admiten?** **Todas las versiones de destino de Business Central a partir de 2025.** La versión de destino concreta se define para cada proyecto de migración. **¿Cómo ayuda la IA en la migración de NAV?** IA significa inteligencia artificial. Combinamos el análisis de código C/AL de su sistema Navision o Dynamics NAV con una evaluación asistida por IA. Usted recibe reglas de negocio documentadas, una base de conocimiento con búsqueda y una propuesta de migración para Business Central. El análisis es la base de la migración técnica; las validaciones funcionales corresponden a sus departamentos funcionales. Si lo desea, acordamos después la implantación por separado, o bien la asume su partner. **¿Qué significa pasar de C/AL a AL en la migración?** C/AL describe la lógica de programa existente de muchas personalizaciones de NAV; AL se utiliza para las extensiones de Business Central. En una migración de C/AL a AL, comprobamos primero si el estándar de Business Central ya cubre el requisito o si hay disponibles módulos ISV certificados adecuados. Solo las brechas justificadas se planifican como extensiones AL a medida, sin limitarse a trasladar uno a uno el código antiguo. **¿Es imprescindible migrar a la nube?** No. El escenario objetivo para Business Central (online u on-premises) se define con independencia del modelo de operación de IA. Para una migración a la nube examinamos en particular las interfaces, las estructuras de datos y las extensiones. El análisis de NAV puede realizarse con IA en la nube o con modelos de IA locales en su hardware o en hardware prestado por nosotros. La vía de implantación concreta se acuerda en el proyecto. **¿Necesita el análisis acceso a nuestra base de datos SQL? +** Sí. El acceso SQL necesario se realiza a través de un servidor de seudonimización intermedio con permisos acordados. Este sustituye los valores identificativos antes de que los resultados validados lleguen a la IA. Ni la IA ni este sitio web reciben acceso directo a la base de datos, credenciales SQL ni copias de seguridad de la base de datos. Como complemento, pueden facilitarse exportaciones de objetos y metadatos. **¿Puede realizarse el análisis con IA en la nube o íntegramente en local? +** Sí. Como opción de operación son posibles ChatGPT, Claude y cualquier otra IA en la nube; las interfaces adecuadas, las condiciones contractuales y las validaciones de datos se acuerdan previamente. Como alternativa, utilizamos diversos modelos locales en su hardware o en hardware que le prestamos. También es posible una combinación acordada expresamente. En todas las variantes, la sustitución de los valores identificativos y la validación se realizan antes del procesamiento por la IA. **¿Qué hardware necesitamos para la IA local? +** Diversos modelos locales pueden encargarse del análisis, la extracción de reglas y la verificación cruzada. Se ejecutan en su hardware actual o en hardware que le prestamos para el proyecto. El equipamiento, la duración del préstamo y las licencias de los modelos se acuerdan en función de las tareas de análisis. En una operación puramente local, también los embeddings, la base de conocimiento, los registros y los servicios auxiliares permanecen en local. Las funciones en la nube y las rutas de conmutación automática a la nube no se activan sin consultarle. **¿Puede la IA identificar automáticamente todos los procesos de negocio?+** El análisis debe derivar hipótesis de procesos y reglas de negocio a partir de los artefactos disponibles. Los pasos manuales, las excepciones no documentadas y los procesos que transcurren fuera de NAV deben completarse en talleres. Los resultados permanecen marcados como borrador hasta que los departamentos funcionales los confirman. **¿Se trasladan las personalizaciones tal cual a Business Central?** No. Damos prioridad al estándar de Business Central. Si no es suficiente, la programación a medida debe sustituirse, siempre que sea posible, por módulos certificados adecuados. Solo los requisitos necesarios que, de forma demostrable, sigan sin cubrirse justifican un desarrollo a medida. Las decisiones, las alternativas y las verificaciones pendientes se documentan. **¿Es el análisis ya la migración técnica?** El análisis proporciona la base para tomar decisiones. La implantación técnica, la migración de datos, las pruebas de migración y la puesta en producción se acuerdan por separado: con su equipo interno, con su partner actual o en el marco de una implantación que se acuerde posteriormente. **¿Seguirán funcionando nuestros informes de Power BI después de la migración?** No sin cambios, si acceden directamente a tablas de NAV o a páginas de NAV publicadas. Business Central pone los datos a disposición de Power BI a través de páginas y consultas de API; en Business Central online es la única vía admitida. Para finanzas y ventas existen aplicaciones de plantilla ya preparadas. Identificamos qué orígenes de datos utilizan sus informes y le mostramos qué debe conectarse de nuevo. **¿Qué información es útil para la primera reunión?** Su versión de NAV, los departamentos funcionales más importantes, las personalizaciones conocidas y su objetivo para Business Central. A continuación, aclaramos juntos las fuentes para el análisis y el modelo de operación de IA adecuado. EL PRIMER PASO ES LA CLARIDAD ## ¿Qué esconde su NAV? Cuéntenos su situación de partida. Juntos aclaramos qué análisis tiene sentido para su migración. PRÓXIMOS PASOS **01** Comentar la situación de partida y el escenario objetivo **02** Acordar el acceso SQL y la protección de datos **03** Definir el enfoque del análisis y el modelo de operación de IA ANÁLISIS INICIAL SIN COMPROMISO ### Análisis inicial sin compromiso Bastan unos pocos datos clave para una primera estimación del esfuerzo y del enfoque. \* Campo obligatorio COSTES Y PLAZOS #### ¿Cuánto cuesta y cuánto tiempo lleva? Los costes y la duración dependen de la versión de NAV, el grado de personalización, las interfaces, el volumen de datos y el escenario objetivo. Tras un breve análisis inicial, recibirá un marco de costes concreto y una estimación de plazos realista, antes de acordar cualquier paso adicional. NAVtoBC.de no tiene ninguna relación con NAVTOBC.com.