---
title: "Particularidades de C/AL y análisis de código | NAVtoBC.de"
description: "Entender C/AL: triggers, FlowFields, objetos, transacciones y dependencias dinámicas. Análisis basado en exportaciones de objetos en formato TXT."
url: https://navtobc.de/es/cal-besonderheiten
language: es
---

# Particularidades de C/AL y análisis de código

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)