Índice do artigofaltam 10 min de leitura
O SAP Business One emite nota fiscal brasileira há anos. A nota que a empresa recebe é outro problema, e a documentação pública do produto não descreve nenhum componente que vá buscá-la na fonte oficial.
Quem descobre isso costuma partir para o caminho mais curto. Quando o Business One roda sobre Microsoft SQL Server, o banco é um motor que o time de desenvolvimento conhece, a tabela de nota de entrada está ali, visível, e gravar diretamente é a decisão mais barata do primeiro mês e a mais cara do segundo ano.
Quem vai orçar essa integração precisa de duas respostas antes de qualquer estimativa: o que a localização brasileira já cobre e por qual interface a SAP se compromete a manter o que for escrito. A documentação pública responde as duas.
Resumo do artigo
- O Business One já traz pronta a nota fiscal que a empresa emite. Para a nota que ela recebe, a documentação pública não descreve nenhum componente do produto que vá buscá-la na fonte oficial: alguém precisa atravessar essa fronteira, e isso é escopo de projeto, não configuração.
- A SAP tem o componente que faz essa busca, com um processo dedicado de distribuição de documentos. As páginas de cenários e de integração dele listam apenas os ERPs corporativos da casa como sistemas de origem.
- Gravar direto no banco não é bloqueado pelo produto, e é exatamente por isso que é arriscado: a SAP classifica como risco de corrupção de dados, declara que não terá suporte e encerra com "Use at your own risk".
- Desde uma atualização de 2026, a via oficial de integração avisa sozinha quando um objeto de negócio do ERP é criado ou alterado, em vez de exigir consulta periódica. Isso muda o desenho do projeto, e não substitui a captura na fonte oficial.
O banco é SQL Server, e isso não autoriza escrever nele
O Service Layer, que é a via de integração por HTTP do produto, roda sobre Microsoft SQL Server desde o Business One 10.0 PL01, segundo o histórico de revisões do manual do próprio componente. Isso resolve uma pergunta de infraestrutura e não resolve nenhuma pergunta de arquitetura.
A paridade de recursos não chegou toda no PL01: a exposição automática de views SQL customizadas sobre SQL Server é documentada a partir do PL02, e o controlador de configuração chegou no PL00 para a versão HANA e no PL02 para a de SQL Server. Assumir equivalência entre os dois motores por causa de uma linha de suporte é premissa que aparece no meio da implantação.
Ter o banco em um motor familiar é como ter a chave do prédio: mostra que dá para entrar, não que aquela é a entrada. A diferença entre as duas portas aparece quando alguém aplica um patch. A suportada é contrato; a lateral é conveniência que ninguém prometeu manter.
A SAP não bloqueia a escrita em tabela de sistema, e isso é pior
A documentação do SDK, no objeto Recordset, diz que operações de manipulação de dados são "acceptable" apenas para tabelas de usuário. Sobre tabelas de sistema, ela não proíbe: classifica como risco alto de corrupção de dados, declara que não terá suporte e encerra com "Use at your own risk."
A distinção muda o momento em que o problema aparece. O que a SAP realmente bloqueia são ações de definição de estrutura, ou seja criar, remover, alterar e truncar tabela, e o motivo é declarado: ao atualizar o produto, a aplicação ignora tabelas de usuário que não tenham sido criadas pelos objetos de metadados apropriados. Já a escrita em tabela de sistema roda. Ela funciona no dia em que alguém escreve e cobra a conta no dia da atualização de versão.
Um detalhe do mesmo objeto joga a favor: antes de executar a consulta, ele valida a permissão do usuário, a mesma que vale dentro do Business One, e bloqueia quando ela não existe. A recomendação explícita da página é usar os objetos de integração apropriados para os demais objetos de negócio.
O que a localização brasileira do Business One cobre
A localização Brasil existe e é completa para o vocabulário fiscal do país: CFOP, CST, numeração de nota fiscal, CNAE, inscrição estadual por filial, tipos e códigos de tributo, retenção na fonte, classificação de item, determinação de código tributário, abas próprias nos documentos de compra e venda, SPED Fiscal e ferramentas de apuração.
| Área | O que a documentação pública descreve |
|---|---|
| Cadastro fiscal | CNAE, inscrição estadual por filial, CNPJ, tipos, categorias e códigos de tributo, retenção na fonte |
| Classificação de item | Códigos e grupos de serviço, grupos de material, NCM e DNF |
| Documentos | Sequências de numeração de nota fiscal por tipo de documento, abas de nota fiscal e de não nota fiscal em compras e vendas |
| Apuração e relatórios | SPED Fiscal, ferramenta de apuração, relatórios fiscais e de estoque |
| Documento eletrônico | Um tópico de faturamento eletrônico que remete a notas de suporte, e um monitor de documentos eletrônicos |
Fonte: deliverable "Localization for Brazil" do SAP Business One 10.0, no SAP Help Portal, consultado em 08/09/2026.
O que falta não é o vocabulário fiscal brasileiro. É a porta de entrada: o componente que vai até a fonte oficial e traz o documento que a empresa recebeu.
A SAP tem o componente de captura, e ele é documentado para outros ERPs
A SAP tem um produto que faz exatamente essa captura no Brasil. Ele se chama SAP Document and Reporting Compliance, inbound invoicing option for Brazil, lista entre as funções o download de NF-e pela funcionalidade de reconhecimento do destinatário junto à SEFAZ, e tem um processo dedicado de Distribuição de DF-e. As páginas de cenários de negócio suportados e de integração desse produto listam como sistemas de origem apenas SAP S/4HANA e SAP ERP.
Do lado do Business One, uma varredura no índice oficial do portal de ajuda, em inglês e em português, por SEFAZ, DF-e, NFS-e, manifestação do destinatário, nota fiscal de entrada e download de XML, não retorna nenhum componente de recepção. As notas de suporte que a própria SAP cita para NF-e no Brasil exigem login, e ficaram fora desta leitura.
A própria localização Brasil documenta campos acrescentados para padronizar a leitura por add-on externo, em cadastro de itens, dados da empresa, parceiro de negócios e documentos de nota fiscal: é a SAP desenhando para um terceiro ler. Na direção oposta, o protocolo Peppol não está disponível nas localizações que incluem o Brasil, e a integração da extração de informações de documento com o assistente de importação vale em todas as localizações exceto Brasil, Argentina, Costa Rica e Guatemala.
Quatro armadilhas que parecem captura e não são
Quem procura no produto encontra quatro nomes que parecem resolver o problema. Nenhum deles fala com a SEFAZ.
- Authorization to Retrieve NFe from SEFAZExiste esse campo no cadastro de parceiro de negócios e, desde o FP 2608, também no cadastro de funcionário. Parece captura e não é: é o dado de autorização gravado na nota que a empresa emite, o equivalente à tag de terceiro autorizado.
- Electronic Document Import WizardExiste e processa documentos eletrônicos recebidos. Os protocolos dele são extração de informações de documento, Peppol, um formato genérico e upload manual. Exige o serviço de documentos eletrônicos, e os dois protocolos relevantes estão excluídos da localização Brasil.
- Extração de PDFFunciona no Brasil pelo cenário original: alguém copia o arquivo para uma pasta e o sistema processa, gerando rascunho de fatura de fornecedor. Lê PDF e imagem, é vendido separadamente, e não descobre nada na fonte oficial. Alguém precisa já ter o arquivo.
- Importação genérica de XMLO guia geral de documentos eletrônicos descreve importação com identificação do parceiro por CNPJ, mas a própria introdução avisa que, para localizações com funcionalidade customizada, a solução genérica pode não se aplicar, e lista o Brasil entre elas.Verificar na versão
A fronteira entre a fonte oficial e o ERP precisa ser atravessada por alguém: um add-on de parceiro, uma aplicação própria ou um provedor fiscal com conector. Essa é a decisão de arquitetura, e ela vem antes de qualquer discussão sobre linguagem.
Service Layer para integrar de fora, DI API para rodar dentro
São duas as vias suportadas: o Service Layer, que expõe os objetos de negócio por HTTP, e a DI API, que roda junto do ambiente, em Windows. A escolha não é estética: ela decide onde o componente roda, quem mantém a compatibilidade de versão e o que acontece quando a operação é interrompida no meio.
| Interface | Quando serve | O que verificar antes |
|---|---|---|
| Service Layer | Integração feita de fora do servidor, com objetos de negócio expostos por HTTP | Versão, instalação, metadados, autenticação, licença e rota de rede |
| DI API | Componente que roda junto do ambiente, em Windows, com acesso a objetos que a camada HTTP não exponha | Runtime, compatibilidade de versões, conta técnica e implantação do agente |
| SQL direto em tabela de sistema | Não é atalho suportado, pela razão da seção anterior | Confirmar com o parceiro qual objeto suportado cobre o caso antes de considerar essa via |
Fontes: referência da API do Service Layer do SAP Business One 10.0 e documentação do SDK, objeto Recordset, consultadas em 08/09/2026.
Service Layer: OData v4, a rota que muda e o que ele não faz
A partir do Feature Package 2405, o OData versão 3 está depreciado e o versão 4 é o protocolo principal do Service Layer. Depreciado não é removido: a documentação diz que o v3 continua suportado por compatibilidade e recomenda a transição. O que muda é o prefixo da rota, e não só a biblioteca.
Os objetos relevantes para um fluxo de entrada estão expostos como conjuntos próprios: faturas de compra, descritas na documentação como "a request for payment", pedidos de compra e tipos de condição de pagamento. A tradução dessa descrição é útil na conversa com o financeiro: o objeto que o integrador cria é um pedido de pagamento, não um pagamento.
O que ele entrega
- Objetos de negócio por HTTP, sem componente instalado na máquina de quem integra
- Metadados compartilhados com a DI API, o que facilita migrar de add-on para API
- Consulta SQL flexível sobre os dois motores de banco desde o FP 2011, com normalização de diferenças de sintaxe entre eles
- Webhooks a partir do FP 2602
O que ele não faz
- Não mantém transação de usuário cruzando requisições, então a idempotência é da sua aplicação
- Não suporta execução de SQL direto pelo objeto de recordset
- Não suporta importação e exportação por XML
- Objetos definidos pelo usuário recém-criados só ficam acessíveis depois de reiniciar o serviço
O limite com maior consequência operacional é a ausência de transação atravessando requisições: um tempo limite estourado depois de a gravação ter acontecido deixa a aplicação sem saber se gravou. A resposta certa é consultar por referência externa e reconciliar, nunca reenviar.
Webhooks desde o FP 2602 mudam o desenho da integração
A partir do Feature Package 2602, o Service Layer suporta webhooks, ou seja avisa sozinho quando um objeto de negócio é criado ou alterado. Para quem desenhou a integração antes disso, a mudança é estrutural: o que era consulta periódica passa a poder ser notificação.
Isso conversa com uma restrição de infraestrutura comum: expor o banco ou o Service Layer para fora da rede é uma conversa difícil com TI, e nem sempre necessária. Um agente instalado no ambiente autorizado inicia conexões de saída, recebe tarefas, executa pela interface suportada e devolve recibos.
Continua havendo trabalho de rede, certificado, atualização e monitoramento do agente. O que some é a exigência de abrir porta de entrada.
Duas restrições de implantação estão documentadas e decidem onde o componente pode ficar: a instalação remota do Service Layer não é suportada, e o serviço roda sobre Apache HTTP Server, em modo integrado ou distribuído com balanceador.
Lançar não é aprovar, e aprovar não é pagar
Essa separação costuma ser tratada como detalhe até o primeiro incidente. Consultar a situação fiscal de uma nota não atesta que a mercadoria chegou, que ela corresponde ao pedido, nem que o pagamento está autorizado.
Duas regras seguem do desenho. A aplicação consulta as condições de pagamento cadastradas e prepara uma proposta de vencimentos, e não substitui cadastro bancário por dado extraído do documento. E a extração automática, inclusive por modelo de linguagem, cabe até a conciliação: a autorização de pagamento fica fora, com permissão, alçada e trilha próprias.
A razão de segurança é concreta: o leiaute da NF-e tem um campo de informações complementares que aceita até 5.000 caracteres preenchidos pelo emitente, e ele viaja dentro do arquivo assinado. A assinatura prova quem escreveu, não que o conteúdo é inofensivo. Conteúdo de documento é dado, nunca instrução de sistema.
Isso não é um problema de SAP
Troque o nome do ERP e a estrutura do problema continua igual: muda a interface suportada, a política de suporte do fornecedor e o nome do objeto de negócio. Não muda a sequência que separa um projeto que entra em produção de um que vira discussão de escopo.
- Descubra qual interface é suportada na versão e no patch instalados, e não na versão mais recente do produto
- Peça uma resposta crua da interface, com dado real de homologação, antes de estimar prazo
- Faça um ensaio pequeno e independente da captura: ler cadastro, preparar um documento permitido, verificar referência e reversão
- Separe o que é bloqueado pelo fornecedor do que é apenas não suportado, e registre a diferença por escrito
- Trate tempo limite depois de gravação como reconciliação obrigatória, nunca como reenvio
Nenhum dos cinco passos depende de qual ERP está do outro lado, e é por isso que eles sobrevivem à troca de fornecedor.
Se o ensaio falhar por licença, rede ou localização, o problema é de integração com o ERP, e não da API fiscal. Descobrir isso na primeira semana custa uma conversa; no terceiro mês, custa o cronograma.
Precisa lançar documento fiscal no ERP sem perder suporte?
Solicite um orçamento e comece pelo ensaio em base de homologação, antes de comprometer a arquitetura.
Perguntas frequentes
A documentação do SDK não bloqueia isso, e é justamente esse o problema. Ela diz que operações de escrita são aceitáveis apenas em tabelas de usuário, classifica a escrita em tabelas de sistema como risco alto de corrupção de dados, declara que não terá suporte e encerra com 'Use at your own risk.' Não é uma barreira técnica, é uma renúncia de suporte.
Roda nos dois. O suporte ao Microsoft SQL Server está registrado no histórico do manual do Service Layer a partir do Business One 10.0 PL01. Vale notar que a paridade de recursos não veio toda no PL01: parte chegou no PL02.
Tem, e ele se chama SAP Document and Reporting Compliance, inbound invoicing option for Brazil, com job dedicado de Distribuição DF-e. As páginas de cenários e de integração desse produto listam como sistemas de origem apenas SAP S/4HANA e SAP ERP. O Business One não aparece nelas.
A DI API é uma interface de objetos baseada em COM, executada em Windows, com dependência de runtime e de versão. O Service Layer é uma API HTTP sobre OData, com objetos de negócio equivalentes, e é o caminho mais natural para integração feita de fora do servidor. As duas compartilham a maior parte dos metadados.
Não mantém transação de usuário cruzando requisiç ões, não suporta execução de SQL direto pelo objeto de recordset, não suporta importação e exportação por XML, e objetos definidos pelo usuário recém-criados só ficam acessíveis depois que o serviço é reiniciado. A instalação remota do Service Layer também não é suportada. A consulta SQL flexível do Service Layer, disponível desde o FP 2011, é outra coisa.
O padrão vale para qualquer ERP. Muda o nome da interface e a política de suporte do fornecedor. O que não muda é a sequência: descobrir qual interface é suportada na sua versão, provar um lançamento pequeno em base de homologação e só então prometer prazo.
Fontes e método
Este artigo é baseado em leitura direta da documentação pública da SAP no portal de ajuda, feita em 8 de setembro de 2026. As fontes primárias são a referência da API do Service Layer do SAP Business One 10.0; o manual "Working with SAP Business One Service Layer", versão 1.29 de 27 de julho de 2026; a documentação do SDK, objeto Recordset; o deliverable "Localization for Brazil" do Business One 10.0; e as páginas de cenários de negócio suportados e de integração do SAP Document and Reporting Compliance, inbound invoicing option for Brazil. O Feature Package mais recente referenciado nessas páginas é o 10.0 2608.
Nenhum ambiente foi instalado ou testado para este artigo, e nenhum add-on de parceiro foi avaliado. O texto descreve o que a documentação pública consultada contém, e onde ela é silenciosa isso está dito no corpo, com o motivo.
