NAVtoBC.de Solicitar análisis inicial

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 compromisoDescubrir los resultados

Primero, el estándar de Business Central. Dar preferencia a los módulos certificados.
Desarrollar a medida solo de forma selectiva.

Análisis y planificación de la migración
SU BASE PARA DECIDIR

Del conocimiento a la perspectiva.

DEMO
01 / PRIORIDADEstándar de Business CentralAprovechar sus funciones
02 / EXTENSIÓNMódulos
certificadosSustituir el código a medida
03 / BRECHA JUSTIFICADAA medida,
con criterioDesarrollar lo necesario
Las relaciones se mantienenValores sustitutos coherentes
ClienteP-7Q4X9
PedidoP-7Q4X9
FacturaP-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
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.

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.

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.

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

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.

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.

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.

EDILobster EDIDocumentos, datos maestros
e información de estado
BIQlikInformes, análisis
y provisión de datos
Navision / Dynamics NAVC/AL · SQL · lógica de negocio
IMPORTACIÓNDatos de productosDatos maestros, variantes,
unidades y precios
TIENDATiendas onlineProductos, precios, existencias
y pedidos
EN ESTO SE CENTRA EL ANÁLISIS
Exportación de datosContenidos, formatos de destino
y destinatarios
Conciliación en la importaciónAsignació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.

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

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

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.

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 valoresSintaxis 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 metadatosTipo 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 negocioVALIDATE, 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álculosFiltros, 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 eventosRecordRef, 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 SQLCOMMIT, 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ándarFormato 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 integracionesGeneraciones 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
Fuentes especializadas y contexto

Comprobado el 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.

Así combinamos el análisis de código y la IA

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/AL480.000 líneas
CODEUNITSCasi 1.000
SISTEMANAV 2009 R2
VOLUMEN DE DATOSaprox. 1,5 TB
ANTIGÜEDAD DEL SISTEMA20 años
SECTORComercio 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

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.

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

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.

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

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

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.

EJEMPLO SINTÉTICO

RESULTADO DE EJEMPLO

La visión global. De un vistazo.

EJEMPLO DE ANÁLISIS SINTÉTICO .txt// Valores sustitutos coherentes
Cliente.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éticosRevisió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
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 ejemploVía de evaluaciónSiguiente pasoEstado
Asignar cliente y documentosPrimero, el estándar de Business CentralContrastar el flujo y la configuración desde el punto de vista funcionalRevisión del estándar pendiente
Requisito sectorial adicionalMódulo certificado, si el estándar no bastaEvaluar idoneidad, evidencias, integración y costesRevisión de módulos pendiente
Regla especial restanteDesarrollo a medida solo si se confirma una brechaDocumentar la necesidad y las alternativasNingú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
UN VISTAZO AL PORTAL DE CONOCIMIENTOAná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.
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

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.

NavisionDynamics NAVMS Dynamics NAVBusiness 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 RESULTADOInventario 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 RESULTADOMapa 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 RESULTADOSu 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 RESULTADOPlan 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

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.

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

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 ↗
La seudonimización con un ejemploDATOS 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.

Datos de ejemplo fijos: sin borrado ni cambio del valor sustituto. Esta demo no procesa datos reales ni transmite nada.

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 · OpenAIClaude · AnthropicOtras 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
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 hardwareHardware en préstamoDiversos 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
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

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.

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.

Métodos en detalle8 métodos de análisis y verificación
01ENTENDER 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.

02DETERMINAR 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.

03ACREDITAR 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.

04CONTRASTAR 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. Abrir el ejemplo a tamaño completo
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.

05VERIFICAR 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.

06APRENDER 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.

07MEJORAR 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.

08PRESERVAR 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 ↗ · Anthropic: API de Claude ↗

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

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
¿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 →

¿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.

Comprobando el estado del envío.
01Contacto
VERIFICACIÓN DEL CORREO ELECTRÓNICOPara la verificación, enviamos un código de confirmación de un solo uso a la dirección de correo electrónico indicada.
02Proyecto y escenario objetivo
Mínimo 20 caracteres.0 / 5.000

Sus datos se utilizarán exclusivamente para tramitar su solicitud. Encontrará información sobre el tratamiento en la Política de privacidad. Sin suscripción a ningún boletín.

NAVtoBC.de no tiene ninguna relación con NAVTOBC.com.