O desenvolvimento em Business Central tem uma particularidade que muda a conversa com o fornecedor: a Microsoft desenhou o produto para ser estendido sem se tocar no código de base. Quem decide personalizar o ERP não está, por isso, a escolher entre «standard» e «à medida». Está a escolher um degrau numa escada, e quanto mais baixo for o degrau, mais barata e mais duradoura é a solução.
Esta página explica essa escada, o que cada degrau implica na prática para uma empresa portuguesa e como avaliar quem vai escrever o código. Para o enquadramento geral do produto, veja a página do Microsoft Dynamics 365 Business Central e os módulos disponíveis.
Os três níveis de personalização do Business Central
A personalização do Business Central divide-se, de forma útil, em três níveis. Cada um tem um custo de manutenção diferente.
| Nível | O que é | Quem o faz | Risco nas atualizações |
|---|---|---|---|
| Parametrização | Configuração do que o standard já oferece | Consultor funcional, por vezes o próprio utilizador-chave | Muito baixo |
| Extensão existente | Aplicação instalada do Microsoft Marketplace | Consultor, com validação do fornecedor da aplicação | Baixo a moderado, depende do editor |
| Desenvolvimento específico | Extensão própria escrita em AL | Programador Business Central | Moderado: exige testes a cada versão |
A regra de ouro é simples: só se desce um nível quando o anterior falhou de forma demonstrável.
Parametrização: o que se resolve sem uma linha de código
Antes de falar em módulo sobre medida, convém esgotar o que o próprio sistema permite. A parametrização inclui, entre outros, as séries de numeração, as dimensões analíticas, os perfis de utilizador, as vistas e os fluxos de aprovação. Em muitas PME portuguesas, uma boa parte dos pedidos de «desenvolvimento» são, afinal, configurações mal exploradas.
O Designer, integrado no cliente web, vai um pouco mais longe: permite desenhar páginas por arrastar e largar, reorganizar ou acrescentar campos e pré-visualizar o resultado, tudo sem sair da interface. Para um diretor financeiro que quer ver certos campos no topo de uma ficha de cliente, é muitas vezes suficiente.
Perguntas a fazer antes de aceitar um orçamento de programação:
- O que se pretende já foi tentado só com configuração, perfis e o Designer?
- O pedido nasce de um processo real ou de um hábito do sistema anterior?
- A necessidade é recorrente ou resolve-se com um relatório?
Extensões existentes: o Marketplace antes do código
No Business Central em linha, o sistema é alargado através de aplicações (extensões) instaladas a partir do Microsoft Marketplace. Há também páginas «Connectivity Apps» e «Banking Apps», disponíveis desde a 2022 release wave 2, que propõem aplicações de ligação a serviços externos, como a importação de movimentos bancários.
Um exemplo concreto é o conector Shopify, que sincroniza produtos, inventário, clientes, encomendas, expedições, transações e pagamentos entre a loja e o ERP, suporta várias lojas e pode ser automatizado em segundo plano através da fila de trabalhos (job queue), com registo detalhado para diagnóstico. Quem tem uma operação de comércio eletrónico deve começar por aqui, antes de pedir um desenvolvimento. Veja também a nossa página sobre integrações e conectores.
Aplicações de localização e contexto português
A Microsoft fornece diretamente a localização do Business Central num conjunto de países; para os restantes, a localização chega através de aplicações desenvolvidas por parceiros e disponíveis no Marketplace. Em Portugal, onde o cumprimento do SAF-T (PT), do ATCUD e do código QR depende de um software de faturação certificado pela AT, é indispensável pedir ao integrador que diga qual a aplicação ou a localização que cobre essas obrigações, quem a mantém e como é atualizada. Este ponto fica antes de qualquer desenvolvimento adicional; encontra mais pormenor em Business Central em Portugal.
Desenvolvimento específico em AL: ferramentas e limites
Quando nem a configuração nem o Marketplace chegam, escreve-se uma extensão própria. A linguagem é o AL, utilizada no Visual Studio Code. Com ela acrescentam-se ou modificam-se tabelas, páginas, codeunits e relatórios sem tocar no código de base; o resultado é compilado num ficheiro .app, que se instala como qualquer outra aplicação.
Ambientes de teste e depuração
Os ambientes de teste (sandbox) são pensados para o desenvolvimento: o ponto de depuração está aberto por omissão e a publicação faz-se a partir do Visual Studio Code. Um pormenor que surpreende equipas pouco experientes: as chamadas HTTP de saída das extensões ficam bloqueadas nesse ambiente até serem autorizadas, extensão a extensão. Um programador que conheça o produto sabe-o e planeia-o.
APIs e integrações com sistemas externos
O Business Central expõe uma API REST (v2.0) para ligar o ERP a soluções de terceiros, e as APIs estão ativas por omissão em linha. Há dois limites a conhecer:
- Não é possível acrescentar campos a uma API standard. É necessário copiar o código AL e criar uma API personalizada.
- Os limites de chamadas OData V4 aplicam-se por utilizador: 5 pedidos simultâneos, 100 ligações e uma janela deslizante de 6 000 pedidos em 5 minutos. Acima disso, o serviço responde com o código HTTP 429.
A Microsoft recomenda a API ou o OData em vez do SOAP, que está destinado a ser depreciado. Quem herdou integrações baseadas em SOAP deve tratá-las como dívida técnica.
Um ambiente Business Central pode ainda ser ligado a um ambiente Power Platform do mesmo tipo (produção ou testes). Essa ligação é exclusiva e serve de destino por omissão para integrações com a Power Platform e outros produtos Dynamics 365. Convém decidi-lo cedo, porque condiciona a arquitetura.
Impacto nas atualizações: o que realmente se parte
Uma extensão bem escrita não impede a atualização do standard, mas não a torna automática. O que costuma falhar é:
- uma extensão que depende de um comportamento interno do standard que mudou;
- uma aplicação de terceiros cujo editor ainda não publicou a versão compatível;
- uma integração que usa um ponto de acesso entretanto depreciado.
Por isso, cada atualização deve passar primeiro por um ambiente de teste, com os cenários críticos de faturação, stocks e fecho contabilístico repetidos antes de chegar à produção. Quanto maior o número de extensões, maior o trabalho de validação: é um argumento direto para ficar perto do standard. Detalhes sobre cadência e opções em versões e edições e em suporte e manutenção.
Boas práticas para personalizar sem criar dívida técnica
Ficar o mais perto possível do standard
Cada desenvolvimento é um compromisso de manutenção. Antes de aprovar um pedido, escreva a necessidade de negócio em duas frases e pergunte: o que acontece se não a fizermos? Se a resposta for «perde-se um clique», provavelmente não vale a pena.
Documentar o que se desenvolve
Cada extensão deve ter uma ficha com o objetivo, o responsável do lado da empresa, os objetos tocados, as dependências e os testes associados. Sem esta documentação, a saída de um programador deixa a empresa refém de um código que ninguém sabe explicar.
Testar em sandbox, sempre
Nada se publica em produção sem passar por um ambiente de teste com dados representativos. É também o sítio onde os utilizadores-chave validam o resultado antes do arranque. Um contabilista certificado deve participar na validação de tudo o que toca em IVA, faturação ou saídas fiscais.
Pensar na propriedade do código
O contrato deve dizer quem detém o código-fonte, onde fica guardado e o que acontece se a relação com o integrador terminar. Esta cláusula custa pouco a negociar no início e muito a resolver mais tarde.
Como avaliar um programador ou um integrador Business Central
Quem desenvolve para o seu ERP condiciona a sua operação durante anos. Estes são os sinais que importam:
| Critério | O que pedir | Sinal de alerta |
|---|---|---|
| Método | Explicação de como separa configuração, aplicação e código | Propõe código para tudo |
| Ambientes | Descrição do circuito de testes até à produção | Trabalha diretamente em produção |
| Documentação | Exemplo de ficha de extensão | «Está no código» |
| Atualizações | Processo de validação a cada versão | Não sabe responder |
| Localização portuguesa | Quem cobre SAF-T (PT), ATCUD e código QR | Resposta vaga ou «trata-se depois» |
| Propriedade | Cláusula sobre o código-fonte | Código retido pelo prestador |
Peça também referências de projetos comparáveis ao seu, com a mesma complexidade de processos, e verifique se a equipa que vai trabalhar é a que lhe foi apresentada. Para um método mais completo, consulte o guia como escolher um integrador ERP e a página dedicada a escolher um parceiro Business Central.
Quando o desenvolvimento se justifica
Há situações em que programar é a decisão certa:
- um processo diferenciador do seu negócio, que não existe no standard nem em nenhuma aplicação;
- uma integração com um sistema específico do setor, sem conector disponível;
- um relatório ou documento com regras de negócio que a configuração não alcança;
- uma automatização repetitiva que liberta tempo a equipas pequenas.
Em todos estes casos, o desenvolvimento deve ser pequeno, bem delimitado e documentado, em vez de uma grande camada que reescreva o ERP.
Próximo passo
Se tem uma lista de adaptações e não sabe quais são necessárias, o primeiro passo é separá-las: o que se resolve com configuração, o que existe no Marketplace e o que exige código. O serviço gratuito da Integrador ERP liga-o a um integrador adequado ao seu projeto; o trabalho de parametrização e desenvolvimento é depois realizado por esse integrador, não por nós.
Perguntas frequentes
Posso adaptar o Business Central sem programar?
Sim, em grande parte. A parametrização cobre séries, dimensões, fluxos de aprovação, vistas e relatórios, e o Designer integrado no cliente permite reorganizar ou acrescentar campos numa página por arrastar e largar. Só quando o processo não cabe nestas ferramentas se justifica uma extensão em AL.
O que é uma extensão em AL e porque é que não parte as atualizações?
É um conjunto de objetos (tabelas, páginas, codeunits, relatórios) escritos em AL no Visual Studio Code e compilados num ficheiro .app. Como acrescenta ou modifica comportamento sem alterar o código de base da Microsoft, o standard pode ser atualizado em separado. A extensão continua a precisar de testes a cada versão.
Posso acrescentar um campo a uma API standard do Business Central?
Não diretamente. A Microsoft indica que não é possível juntar campos a uma API standard: é preciso copiar o código AL correspondente e criar uma API personalizada. Convém pedir ao programador que explique essa opção antes de prometer um campo extra a um sistema externo.
Uma extensão do Marketplace ou um desenvolvimento à medida?
Comece pelo Marketplace: se uma aplicação já cobre o essencial do processo, evita código a manter. O desenvolvimento à medida justifica-se quando o processo é diferenciador ou quando nenhuma aplicação encaixa.
Como sei se um programador de Business Central é fiável?
Peça-lhe que mostre como trabalha num ambiente de testes, como documenta cada extensão, como valida uma atualização antes de a passar a produção e quem fica com o código-fonte. Um bom profissional prefere dizer que o standard resolve a necessidade a vender código desnecessário.
Fontes
- Microsoft Learn — Visão geral do desenvolvimento em Business Central
- Microsoft Learn — Extensões e aplicações em Business Central
- Microsoft Learn — Referência da API v2.0
- Microsoft Learn — Limites operacionais online
- Microsoft Learn — Ambientes no centro de administração
- Microsoft Learn — Localizações do Business Central
Os nomes de software mencionados são marcas dos respetivos editores, citadas a título meramente informativo. Este site é independente e não é afiliado a nenhum editor.