---
title: "Particularidades do C/AL e análise de código | NAVtoBC.de"
description: "Entender o C/AL: triggers, FlowFields, objetos, transações e dependências dinâmicas. Análise com base em exportações de objetos em TXT."
url: https://navtobc.de/br/cal-besonderheiten
language: pt-BR
---

# Particularidades do C/AL e análise de código

AS PARTICULARIDADES DO C/AL

## Pouco código. Grande impacto.

No Navision, a lógica de negócio não está apenas nas funções. Propriedades de campos, triggers, filtros e o contexto de execução também determinam o que de fato acontece.

Quem analisa C/AL de forma automatizada precisa ler essas relações em conjunto. Estas são as principais particularidades para uma análise e um planejamento de migração bem fundamentados.

C/AL NO CONTEXTO CERTO

### Do Navision ao Business Central 14.

**C/AL significa Client/server Application Language.** A linguagem foi usada no Navision e no Dynamics NAV e ainda estava disponível no Business Central 14 (Spring 2019, on-premises). A partir do Business Central 15, o C/AL foi substituído pelo AL.

NOSSA BASE DE ANÁLISE

### Exportações de objetos em TXT.

Lemos os **objetos do NAV exportados como TXT**, com código C/AL e propriedades dos objetos. **Arquivos FOB nativos não são processados diretamente.**

Se houver apenas arquivos FOB, os objetos são primeiro importados em um ambiente de desenvolvimento NAV adequado e exportados ali como TXT. Para isso, são necessárias uma versão compatível e a licença de desenvolvedor exigida. Apenas renomear a extensão do arquivo não basta.

UMA PEQUENA DIFERENÇA COM CONSEQUÊNCIAS

### Atribuir ou validar?

As duas linhas definem um valor no buffer do registro. `VALIDATE` executa, além disso, a validação do campo, incluindo `OnValidate`. Esse trigger pode alterar outros campos, acionar lógica de negócio e até realizar alterações no banco de dados.

Atribuição direta

```
Customer.Name := 'Beispiel';
```

Com validação de campo

```
Customer.VALIDATE(Name, 'Beispiel');
```

### O que deve ser analisado em conjunto.

Expanda os temas e descubra os detalhes técnicos.

****Linguagem & valores** Sintaxe Pascal, Code, opções e tipos de dados de negócio**

- **Sintaxe inspirada em Pascal:** `BEGIN … END`, `:=` para atribuições, e `//` e `{ … }` para comentários. Identificadores e palavras-chave não diferenciam maiúsculas de minúsculas. Variáveis são declaradas globalmente no objeto ou localmente em funções e triggers. Parâmetros `VAR` podem alterar o valor no chamador.
- **Code é um tipo de dado próprio:** ele converte o texto em letras maiúsculas e remove espaços no início e no fim. O comprimento definido de `Code` e `Text` faz parte da análise. Strings e arrays são endereçados a partir da posição 1.
- **Opções têm uma ordem:** `OptionString` define os membros; seus valores numéricos começam em 0. É preciso distinguir nome, posição e legenda traduzida. Uma conversão para enums AL precisa considerar os valores existentes. O AL continua suportando `Option`; a mudança para enums não é automaticamente obrigatória.
- **Valores de negócio, não meros números:** `0D`, datas de fechamento, `WORKDATE` e fórmulas de data têm significado próprio. Regras de arredondamento e conversões dependentes de idioma com `FORMAT` e `EVALUATE` podem influenciar resultados e interfaces.

**Para a análise:** valores que parecem iguais podem ser tratados de forma tecnicamente diferente. Por isso, tipo de dado, comprimento, idioma e passagem de parâmetros fazem parte dos achados.

****Objetos & metadados** Tipo mais ID, números de campo e propriedades**

- **Objetos em vez de arquivos-fonte isolados:** dependendo da versão do NAV, fazem parte deles Table, Page, Report, Codeunit, Query, XMLport e MenuSuite; gerações mais antigas também têm Form e Dataport. A identificação única é a combinação de **tipo de objeto e ID**. A faixa 50000–99999 é tradicionalmente reservada a customizações de clientes; as faixas de parceiros e a possibilidade de uso também dependem da licença.
- **Propriedades carregam lógica de negócio:** `TableRelation`, `CalcFormula`, `SourceTableView`, `RunObject` e `RunPageLink` criam relações, filtros e chamadas fora do código C/AL propriamente dito. Números de campo, chaves, DataItems de relatórios e estruturas de XMLport também fazem parte do modelo.
- **Identificadores não são legendas:** `CaptionML` e `OptionCaptionML` fornecem exibições multilíngues, por exemplo em alemão e inglês. Elas não substituem a identidade de objetos nem de campos. O idioma e a codificação de caracteres da exportação TXT precisam ser preservados.

**Para a análise:** uma exportação completa de objetos contém mais conhecimento do que funções copiadas isoladamente. Os metadados são parte do programa.

****Triggers & lógica de negócio** VALIDATE, RunTrigger e ações subsequentes ocultas**

- **Triggers e funções:** o C/AL oferece funções globais e locais. Além delas, há triggers de tabela como `OnInsert`, `OnModify`, `OnDelete` e `OnRename`, triggers de campo como `OnValidate` e `OnLookup`, e também triggers de Page e de Report. A ordem e o contexto de chamada são decisivos.
- **Um parâmetro altera o fluxo:** em `INSERT`, `MODIFY` e `DELETE`, `RunTrigger` controla se o trigger de tabela correspondente é executado. Se não for informado, ele é `FALSE`. `MODIFY(TRUE)` executa `OnModify`, mas não valida automaticamente cada campo. Operações em massa precisam ser consideradas separadamente.
- **Verificar, transferir e validar são coisas diferentes:** `TESTFIELD` verifica o valor de um campo. `TRANSFERFIELDS` atribui valores pelo número do campo e não executa os triggers `OnValidate`. Uma atribuição direta ao campo também contorna essa validação.
- **Contexto implícito:** `Rec`, `xRec` e `WITH` determinam a que uma expressão se refere. Variáveis locais e globais têm escopos diferentes. Variáveis globais podem manter estado dentro de uma instância de objeto; Codeunits `SingleInstance` compartilham sua instância dentro de uma sessão.

**Para a análise:** o nome de uma função, por si só, não explica o fluxo. Também é preciso rastrear os parâmetros que ativam triggers, o contexto das variáveis e as ações subsequentes disparadas.

****Estado do registro & cálculos** Filtros, FlowFields, dados temporários e empresas**

- **Um Record guarda mais do que valores de campo:** filtros, grupos de filtros, chaves e o registro atual influenciam os acessos. `SETRANGE`, `SETFILTER`, `FILTERGROUP`, `RESET`, `FINDSET`, `FINDFIRST` e `NEXT` precisam ser lidos em conjunto. `GET` usa a chave primária e ignora filtros comuns; filtros de segurança devem ser considerados à parte.
- **FlowField não é FlowFilter:** um FlowField não armazena seu resultado calculado de forma permanente na tabela. `CalcFormula` descreve o cálculo, por exemplo uma soma ou um lookup. `CALCFIELDS` calcula o valor; dependendo de como o campo é usado, a própria interface também faz isso. Um FlowFilter fornece condições de filtro para esses cálculos e, por si só, não calcula nenhum resultado.
- **Mesma tabela, outro contexto:** variáveis Record temporárias processam dados em memória. `CHANGECOMPANY` altera a empresa do acesso aos dados; os triggers continuam sendo executados no contexto da empresa atual. `DataPerCompany` distingue tabelas por empresa e tabelas compartilhadas.

**Para a análise:** nome da tabela e valor do campo não bastam. Filtros, definição do cálculo, estado temporário e empresa determinam o que o dado de fato expressa.

****Dependências dinâmicas & eventos** RecordRef, FieldRef, chamadas e subscribers**

- **Reutilização sem modelo de classes:** o C/AL não oferece namespaces de linguagem nem definições nativas de interface. Um modelo de classes próprio com herança também não faz parte da linguagem. Codeunits disponibilizam funções globais; `CODEUNIT.RUN` inicia o respectivo trigger `OnRun`. Referências podem ser resolvidas por nome, por subtipos de objeto declarados ou por números.
- **Os destinos podem ser definidos só em tempo de execução:** `RecordRef`, `FieldRef`, `Variant` e IDs de objeto passados como variáveis permitem processamento genérico. Tabelas de configuração também podem determinar qual código é efetivamente chamado.
- **Eventos já fazem parte do C/AL:** desde o NAV 2016, publishers e subscribers podem criar relações de chamada adicionais. A análise precisa considerar essas vinculações; uma busca por chamadas diretas de função não as captura por completo.

**Para a análise:** dependências comprovadas estaticamente e relações que só podem ser resolvidas com a configuração ou com conhecimento do tempo de execução são apresentadas separadamente.

****Transações & SQL** COMMIT, tratamento de erros, chaves e bloqueios**

- **Transações são em parte implícitas:** o C/AL abre e encerra transações de banco de dados automaticamente. `COMMIT` define um limite explícito. Um erro posterior não desfaz alterações já confirmadas.
- **O tratamento de erros faz parte da lógica:** valores de retorno de funções de banco de dados, o valor de retorno Boolean avaliado de `CODEUNIT.RUN` e `TryFunction` alteram o fluxo de erros e de transações. Alterações no banco de dados dentro de uma TryFunction não são revertidas automaticamente quando um erro é capturado; as gravações permitidas dependem da versão e da configuração do servidor.
- **O C/AL influencia o SQL sem mostrá-lo:** `SETCURRENTKEY`, filtros, `LOCKTABLE`, `FINDSET`, chaves e agregados SIFT afetam os acessos e o comportamento de bloqueio. Uma chave definida não garante um plano de execução SQL específico. Padrões suspeitos indicam pontos de partida; o desempenho real é medido.

**Para a análise:** a consistência dos dados e o desempenho só podem ser avaliados considerando os limites de transação, os caminhos de erro e a operação concreta do banco de dados.

****Histórico & comparação com o padrão** Formato TXT, Version List, versões por país e customizações**

- **Um formato de exportação próprio e documentado:** o C/SIDE gerencia os objetos no banco de dados e os exporta como FOB ou TXT. O TXT contém o código-fonte e metadados como Version List, data, hora e o sinalizador Modified. Essas exportações podem ser versionadas com Git; no entanto, metadados técnicos podem encher as comparações de alterações adicionais. A própria Microsoft disponibiliza ferramentas de comparação e conversão.
- **Customizações podem estar dentro do padrão:** em projetos clássicos de NAV, o código da Microsoft era frequentemente alterado de forma direta. A `Version List` é um indício, não uma prova completa das alterações. A classificação só se torna confiável com a comparação com a versão original inalterada correspondente e com a documentação de projeto existente.
- **A base certa faz diferença:** versão do NAV, build ou atualização cumulativa, versão do país e soluções de parceiros precisam ser compatíveis entre si. Localizações alemãs, austríacas ou suíças podem conter outros objetos padrão e regras de negócio próprias.

**Para a análise:** só a versão de comparação adequada mostra qual lógica pertence ao padrão, à localização, a um add-on ou à customização individual.

****Execução, direitos & interfaces** Gerações de cliente, permissões e pontos de entrada externos**

- **A geração do NAV muda o ambiente:** Classic Client, RoleTailored Client a partir do NAV 2009, Forms e Pages, assim como Dataports e XMLports, pertencem a diferentes estágios de desenvolvimento. A interoperabilidade .NET já foi introduzida com o **NAV 2009 R2**. Automation/COM, componentes .NET e a execução no cliente ou no servidor precisam ser analisados conforme a versão.
- **As permissões só aparecem em parte na exportação:** a propriedade de objeto `Permissions` faz parte do código-fonte. Conjuntos de permissões (Permission Sets) atribuídos, direitos de usuário, filtros de segurança e o escopo da licença precisam ser levantados à parte. Permissões indiretas podem determinar por meio de qual fluxo os dados podem ser alterados.
- **O uso também começa fora do código:** filas de tarefas, web services publicados, caminhos de arquivo, componentes externos e sistemas SQL, EDI ou de e-commerce conectados podem iniciar ou controlar processos. `GUIALLOWED` e funções dependentes do cliente são relevantes para execuções em segundo plano. Por isso, a ausência de chamadas estáticas não prova que algo não seja usado.

**Para a análise:** a exportação TXT é complementada com a configuração liberada para análise, o conhecimento sobre as interfaces e evidências de uso adequadas. Dependências em aberto são esclarecidas de forma direcionada com a TI e as áreas de negócio.

O QUE VOCÊ GANHA COM ISSO

### Entender as regras de negócio. Planejar a migração com base sólida.

Uma análise confiável conecta o código C/AL, os metadados dos objetos e a operação real. Assim, regras, dependências e questões em aberto se tornam rastreáveis – como base para o padrão do Business Central, módulos adequados e desenvolvimento AL direcionado.

[Solicitar análise de C/AL](https://navtobc.de/br/kontakt?thema=nav-analyse)

**Fontes técnicas & contexto**

Verificado em 09/10/2026 com base na documentação da Microsoft. Esta visão geral reúne as principais particularidades para a análise; os detalhes dependem da versão do NAV, do estado dos objetos e do ambiente operacional.

- [C/AL até o Business Central 14 e exportações de objetos em TXT](https://learn.microsoft.com/pt-br/dynamics365/business-central/dev-itpro/developer/devenv-txt2al-tool)
- [FOB/TXT: exportar e importar objetos](https://learn.microsoft.com/pt-br/dynamics365/business-central/dev-itpro/cside/cside-import-objects)
- [Interoperabilidade .NET no NAV 2009 R2](https://www.microsoft.com/en-us/dynamics-365/blog/no-audience/2010/10/27/net-interoperability-in-nav-2009-r2/)
- [Eventos em C/AL desde o NAV 2016](https://www.microsoft.com/en-us/dynamics-365/blog/business-leader/2015/10/15/integration-events-in-microsoft-dynamics-nav-2016/)
- [Funções, variáveis e VALIDATE em C/AL](https://www.microsoft.com/en-us/dynamics-365/blog/no-audience/2012/12/03/writing-unit-tests-in-cal/)
- [FlowFields no NAV 2018](https://learn.microsoft.com/pt-br/previous-versions/dynamicsnav-2018-developer/FlowFields)
- [Objetos TXT, metadados e comparação com o padrão](https://learn.microsoft.com/pt-br/dynamics365/business-central/dev-itpro/upgrade/comparing-and-merging-application-object-source-files)
- [TryFunctions e tratamento de erros em 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, data de trabalho e efeitos colaterais](https://www.microsoft.com/en-us/dynamics-365/blog/it-professional/2015/10/19/test-isolation-in-the-application-test-automation-suite/)
- [Comparação de linguagens: opções também existem em AL](https://learn.microsoft.com/pt-br/dynamics365/business-central/dev-itpro/developer/methods-auto/option/option-data-type)
- [CHANGECOMPANY e contexto de triggers (referência AL)](https://learn.microsoft.com/pt-br/dynamics365/business-central/dev-itpro/developer/methods-auto/record/record-changecompany-method)
- [Permissions e permissões indiretas (referência AL)](https://learn.microsoft.com/pt-br/dynamics365/business-central/dev-itpro/developer/properties/devenv-permissions-property)

[Como combinamos análise de código e IA](https://navtobc.de/br/methoden)