O desenvolvimento SAP Business One tem má fama junto de muitos gestores: orçamentos que derrapam, módulos que ninguém sabe manter, atualizações adiadas porque "pode estragar tudo". Quase sempre, o problema não é o produto, é a ordem pela qual se decide. Personalizar bem é, antes de mais, saber o que não programar.
Esta página explica as camadas de personalização do SAP Business One, quando passar de uma para a seguinte, o que isso implica para as atualizações e como avaliar quem vai escrever o código. Se ainda está a definir o âmbito global do projeto, comece pela página sobre a implementação do SAP Business One.
As quatro camadas de personalização
Pense na personalização como uma escada. Cada degrau custa mais a construir e mais a manter do que o anterior; só se sobe quando o degrau de baixo não chega.
| Camada | O que é | Quem a faz | Risco nas atualizações |
|---|---|---|---|
| Parametrização | Configuração standard: séries, regras, autorizações, layouts | Consultor funcional | Muito baixo |
| Ferramentas de utilizador | Campos, tabelas, objetos e valores próprios; consultas, alertas, workflows | Consultor funcional avançado | Baixo |
| Extensões existentes | Soluções de terceiros já testadas e mantidas | Integrador + editor da extensão | Depende do editor |
| Desenvolvimento específico | Add-on ou serviço escrito para o seu caso | Programador | A gerir ativamente |
Primeiro degrau: parametrizar e usar as ferramentas de utilizador
O curso de implementação da SAP apresenta como ferramentas de personalização do SAP Business One os campos (UDF), tabelas (UDT), objetos (UDO) e valores (UDV) definidos pelo utilizador, bem como as consultas SQL, os alertas e os workflows de aprovação. É aqui que se resolve a maior parte dos pedidos que, à primeira vista, parecem exigir programação.
Alguns exemplos típicos de uma PME portuguesa:
- acrescentar ao parceiro de negócio um campo para o número de alvará, a região comercial ou a condição especial de entrega;
- criar uma tabela própria para registar as visitas técnicas ou as garantias concedidas;
- configurar um workflow de aprovação para compras acima de um limite definido pela administração;
- receber um alerta quando uma encomenda de cliente fica por confirmar;
- extrair, com uma consulta, a lista de clientes sem movimento para a equipa comercial.
Estas peças vivem dentro do produto, são visíveis para quem o administra e acompanham a base de dados nas atualizações. É também aqui que se discutem os módulos do SAP Business One realmente necessários: muitos "desenvolvimentos" desaparecem quando o módulo certo está ativo e bem parametrizado.
Segundo degrau: extensões e soluções de parceiros
Antes de encomendar código, procure se alguém já resolveu o problema. A SAP indica que o SAP Business One é distribuído através de 850 parceiros e que existem mais de 500 extensões sectoriais e por país. Mesmo que nem todas se apliquem ao mercado português, o ecossistema é suficientemente amplo para que uma necessidade comum, como a gestão de contratos, a assinatura de documentos ou a leitura de código de barras em armazém, já tenha resposta.
Comprar uma extensão tem vantagens claras: o editor mantém-na, testa-a nas novas versões e distribui correções. Em contrapartida, passa a depender de um terceiro. Pergunte sempre:
- quem presta o suporte e em que língua;
- como é tratada a compatibilidade em cada nova versão do SAP Business One;
- o que acontece à extensão se o editor deixar de a vender.
Para sectores específicos, veja também o que existe na página sobre o SAP Business One por sector.
Terceiro degrau: o desenvolvimento específico
Quando nenhuma das camadas anteriores serve, justifica-se um módulo sob medida. É o caso de um cálculo de comissões que depende de regras próprias, de um portal para clientes ou de uma automatização que cruza o ERP com uma máquina de produção.
Com que ferramentas se desenvolve
As licenças de utilizador do SAP Business One incluem automaticamente, sem pedido separado, o Software Development Kit (versão de implementação), os SDK Tools, os SAP AddOns, a licença de compatibilidade para add-ons e o Workflow, cada um com 99 999 utilizadores. Na prática, o direito de desenvolver não é um custo adicional de licenciamento; o custo está no trabalho de quem escreve, testa e mantém.
Existem três portas de entrada principais:
- o SDK e a DI API, para extensões que correm junto do cliente SAP Business One;
- o Service Layer, uma API de extensão REST baseada em HTTP e OData, com troca de dados em JSON, que aceita OData v3 em /b1s/v1/$metadata e OData v4 em /b1s/v2/$metadata;
- o Integration Framework, que a SAP descreve como parte integrante do produto, utilizável no local e na cloud, como ambiente de desenvolvimento e execução de cenários de integração: painéis, aplicações móveis, serviços web, aplicações SAP e não SAP.
O Service Layer funciona em SUSE Linux Enterprise e em Microsoft Windows, usa o servidor Apache como distribuidor de carga, pode ser instalado em modo integrado ou distribuído e partilha com a DI API as mesmas definições de objetos, graças ao componente DI Core. Suporta autenticação Basic e OAuth, o que o torna adequado a aplicações web e móveis. Como a escolha da porta de entrada condiciona o alojamento, convém ler também a página sobre o SAP Business One na cloud.
A SAP posiciona ainda o núcleo do produto como concebido para ser estendido, com inteligência artificial, aprendizagem automática e os serviços cloud da SAP Business Technology Platform. Isto é um indicador de rumo: o desenvolvimento moderno privilegia APIs e serviços ao lado do ERP, em vez de alterações no interior do ERP.
Integrações: o desenvolvimento mais frequente
Na prática, grande parte do código sob medida em SAP Business One não está dentro do ERP, está entre o ERP e outras ferramentas: loja online, plataforma de transportes, sistema de produção, ferramentas de BI. A SAP refere, entre as integrações de escritório, a exportação para Microsoft 365 OneDrive (Excel, Word), a colaboração com Microsoft Teams e a integração com Outlook 365. Para ligações mais específicas, consulte a página sobre as integrações do SAP Business One.
O que a personalização muda nas atualizações
A regra de ouro é simples: quanto mais perto do standard, mais fácil é atualizar. Cada camada acima do parametrizado acrescenta uma lista de verificação a cumprir em cada nova versão.
- Campos, tabelas e objetos próprios são mecanismos oficiais; a sua manutenção é leve.
- Extensões de terceiros dependem do calendário do editor. Atualizar o ERP sem confirmar a compatibilidade da extensão é a causa clássica de paragens.
- Código específico exige um ambiente de teste, uma bateria de casos e alguém com competência para corrigir. Se essa pessoa sair da empresa ou do integrador, o risco passa para si.
- Alterações diretas à base de dados estão fora das interfaces previstas e são o tipo de atalho que mais compromete uma migração futura.
Para planear o ciclo de vida, vale a pena consultar as versões e edições do SAP Business One e, se pensa mudar de plataforma ou de versão, a página sobre a migração do SAP Business One.
Particularidades em Portugal
Em Portugal, há zonas onde personalizar exige redobrado cuidado. O software de faturação tem de ser certificado pela AT; a numeração dos documentos, o ATCUD, o código QR e o ficheiro SAF-T (PT) são elementos que o ERP deve gerar de forma coerente e íntegra. Alterar documentos de venda, séries ou o circuito de anulação de documentos sem consultar o contabilista certificado pode criar não conformidades difíceis de detetar até à primeira inspeção ou ao primeiro envio de ficheiro.
Para clarificar o que cabe ao ERP e o que cabe ao cliente, leia os guias sobre o SAF-T (PT) em ERP e sobre o software de faturação certificado. Em caso de dúvida, o princípio é manter o comportamento standard de tudo o que seja documento fiscal e personalizar à volta, não por dentro. A página sobre o SAP Business One em Portugal reúne o enquadramento local.
Boas práticas: standard, documentação e testes
Três hábitos separam os projetos bem-sucedidos dos que se tornam uma dívida técnica.
1. Ficar no standard sempre que possível
Antes de aprovar um desenvolvimento, pergunte: "Se eu mudasse o processo, em vez do software, perdia alguma coisa importante?" Muitas vezes, a resposta é não. Um processo adaptado ao ERP é mais barato, mais rápido de formar e mais fácil de atualizar.
2. Documentar cada desenvolvimento
Um módulo sem documentação é uma caixa negra. Exija, para cada desenvolvimento:
- a necessidade de negócio que resolve e quem a pediu;
- o desenho técnico: que interface usa, que tabelas toca, que dependências tem;
- o código-fonte, entregue e arrumado num repositório a que a sua empresa tem acesso;
- as instruções de instalação e de reversão.
3. Testar antes de produzir
Cada desenvolvimento deve ser validado num ambiente separado, com casos de teste escritos e aprovados por quem usa o processo. Repita os testes sempre que o ERP ou uma extensão for atualizado. A formação dos utilizadores-chave também conta; veja a página sobre a formação em SAP Business One.
Como avaliar um programador ou um integrador de SAP Business One
Escolher quem desenvolve é tão decisivo como escolher o que se desenvolve. Um bom profissional explica mais vezes "isto não precisa de código" do que o contrário. Use esta grelha nas reuniões:
| Pergunta | Boa resposta | Sinal de alerta |
|---|---|---|
| Que interface vai usar? | SDK, Service Layer ou Integration Framework, com justificação | "Vamos ao SQL diretamente" |
| E se existir uma extensão? | Compara, propõe, deixa decidir | Ignora o que já existe |
| Como trata as atualizações? | Plano de testes e ambiente separado | "Isso resolve-se depois" |
| O que entrega no final? | Código-fonte, documentação, reversão | Só o executável |
| Quem assegura a manutenção? | Contrato claro, com prazos de resposta acordados | Depende de uma só pessoa |
| Conhece o contexto português? | Fala de SAF-T (PT), ATCUD e certificação sem hesitar | Trata a faturação como pormenor |
Peça ainda uma descrição de um caso parecido com o seu, sem nomes de clientes, e verifique se o interlocutor sabe explicar os limites da solução. Para uma visão mais completa, leia o guia sobre como escolher um integrador de ERP e a página dedicada à escolha do parceiro SAP Business One.
Se o seu projeto já tem personalizações herdadas e ninguém as domina, um diagnóstico do projeto SAP Business One ajuda a decidir o que manter, simplificar ou substituir.
Em resumo
O desenvolvimento SAP Business One serve para dar ao ERP aquilo que o seu negócio tem de único, não para replicar o que o produto já faz. Parametrize primeiro, use campos, tabelas, consultas, alertas e workflows, procure extensões antes de encomendar código e, quando programar, faça-o pelas interfaces oficiais, com documentação e testes. Se quiser comparar propostas de integradores com experiência neste tipo de projeto, descreva o seu caso no pedido gratuito acima e receba o contacto de profissionais adequados à sua realidade.
Perguntas frequentes
Quando é que se justifica um desenvolvimento específico no SAP Business One?
Quando o processo em causa diferencia o negócio e não pode ser coberto por parametrização, campos e tabelas próprios, consultas, alertas ou workflows de aprovação. Se uma extensão já existente cobre a necessidade, quase sempre compensa mais do que construir de raiz. O desenvolvimento deve ser a última etapa, não a primeira.
Que linguagem e ferramentas se usam para criar um módulo sob medida?
As extensões podem ser construídas sobre o Software Development Kit, a DI API ou o Service Layer, uma API REST baseada em HTTP e OData com troca de dados em JSON. O Service Layer suporta autenticação Basic e OAuth, o que facilita aplicações web e móveis. A escolha depende de a extensão correr dentro do cliente, num servidor ou noutra aplicação.
Uma personalização pode bloquear a atualização para uma nova versão?
Pode, se for feita fora dos mecanismos previstos, por exemplo com alterações diretas à base de dados. Campos, tabelas e objetos definidos pelo utilizador, bem como extensões que usam as interfaces oficiais, são concebidos para acompanhar a evolução do produto. Antes de qualquer atualização, convém testar cada extensão num ambiente separado.
Em Portugal, posso alterar os documentos de venda do SAP Business One?
Pode ajustar o layout e acrescentar informação, mas qualquer mudança que toque na numeração, no ATCUD, no código QR ou no ficheiro SAF-T (PT) deve ser validada com o contabilista certificado e com a certificação do software de faturação em uso. Na dúvida, mantenha o comportamento standard do documento fiscal.
Como avalio um programador ou um integrador de SAP Business One?
Peça a descrição de um projeto semelhante ao seu, a forma como documentam e testam, e como tratam as atualizações. Verifique se usam as interfaces oficiais, se entregam o código-fonte e a documentação e se explicam o que ficará a cargo do cliente. Compare propostas com o mesmo caderno de encargos.
Fontes
- SAP Learning — Implementing SAP Business One
- SAP Help Portal — Licence Guide SAP Business One
- SAP Help Portal — Working with SAP Business One Service Layer
- SAP Learning — Leveraging the SAP Business One Service Layer
- SAP Help Portal — Integration Framework for SAP Business One
- SAP News — Global success of SAP Business One
- SAP Learning — Introducing SAP Business One
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.