SAP Business One no Brasil: Nota Fiscal, NF-e e CNPJ

O SAP Business One funciona no Brasil sobre uma localização oficial da SAP, e ela é uma das localizações mais detalhadas que a SAP entrega: a Nota Fiscal fica dentro dos documentos normais de vendas e compras, um motor de impostos calcula ICMS, IPI, PIS, COFINS e ISS, e os arquivos do SPED saem do próprio sistema. O que a localização não faz sozinha é conversar com a SEFAZ. Esta página explica onde fica essa fronteira, quais tabelas guardam os dados brasileiros, o que mudou em 2026 com o CNPJ alfanumérico e a reforma tributária do IBS/CBS, e traz uma consulta SQL que encontra CNPJs e CPFs inválidos antes que a SEFAZ rejeite uma nota por causa deles.

Eu sou Zain Abbas, desenvolvedor SAP Business One com mais de 7 anos de trabalho em SAP B1 para empresas de 13 países. O Brasil não é um deles, e digo isso logo de início. Minhas integrações de fatura eletrônica são para Arábia Saudita, Equador, Guatemala, El Salvador e Panamá, todos países com modelo de autorização prévia, em que a autoridade fiscal autoriza cada documento antes que ele tenha validade. O Brasil inventou esse modelo com a NF-e, então as lições sobre qualidade de dados e add-ons valem aqui também. As regras brasileiras desta página vêm da documentação da SAP, da Receita Federal e do Portal Nacional da NF-e, com links no final.

O que a localização Brasil do SAP Business One cobre?

Você escolhe o Brasil como localização quando o banco de dados da empresa é criado, e isso não pode ser alterado depois. A ajuda Localization for Brazil da SAP para a release 10.0 cobre estas áreas:

Três fatos dessa documentação pesam mais do que o resto quando você planeja um projeto.

Primeiro, o tópico Electronic Invoicing para o Brasil é curto. Ele diz que a lei brasileira exige uma NF-e para toda movimentação de mercadorias ou serviços, mesmo quando isenta, e depois lista SAP Notes (1757955, 1922450, 1978114, 2004874, 2029968, 2980052, 3011261). Ele não descreve um conector com a SEFAZ, uma configuração de certificado nem um fluxo de status de autorização dentro do SAP Business One. Conferi em 11 de novembro de 2026.

Segundo, um tópico separado, Fields for External Add-On Reading, diz que a SAP adicionou campos ao cadastro de itens, ao cadastro de parceiros de negócios, aos detalhes da empresa e aos documentos de marketing de nota fiscal “to standardize the usage for external add-on reading” (ou seja, para padronizar a leitura por add-ons externos; SAP Note 1715284). É a própria SAP descrevendo a arquitetura: o SAP Business One é dono dos dados fiscais, um add-on é dono da transmissão.

Terceiro, o Electronic Document Monitor existe para o Brasil, mas a página da SAP sobre ele para o Brasil documenta só dois botões, Approve e Reject, para registrar o que o parceiro de negócios fez com um documento. O acompanhamento da autorização da SEFAZ, dos códigos de rejeição, dos eventos de cancelamento e da carta de correção (CC-e) é tarefa do add-on, normalmente guardado em campos definidos pelo usuário na OINV e nas tabelas irmãs.

Como uma NF-e sai do SAP Business One e chega à SEFAZ?

O add-on do parceiro muda de empresa para empresa; os passos não, porque as regras da NF-e no portal nacional os definem:

1. O usuário adiciona o documento de saída (nota fiscal de saída, entrega, devolução de mercadorias ou nota de crédito de fornecedor). O SAP Business One pega o próximo número de Nota Fiscal da sequência atribuída àquele tipo de documento e filial, e calcula os impostos pela determinação do código de imposto e pelo motor de impostos.
2. O add-on monta o XML no leiaute da NF-e (modelo 55; a NFC-e é o modelo 65): emitente e destinatário a partir dos detalhes da empresa e das identificações fiscais da INV12, itens com NCM, CFOP e CST da INV1, grupos de impostos para ICMS, IPI, PIS e COFINS a partir das linhas de imposto e, a partir de 2026, o grupo IBS/CBS. A chave de acesso de 44 caracteres contém o código do estado, o ano e o mês, o CNPJ do emitente, o modelo, a série e o número.
3. O add-on assina o XML com o certificado ICP-Brasil da empresa (arquivo A1 ou token A3) e o envia à SEFAZ do estado do emitente, ou a uma SEFAZ virtual nos estados que usam uma.
4. A SEFAZ autoriza ou rejeita. Só uma NF-e autorizada é um documento válido; a mercadoria pode circular com o DANFE impresso. Uma rejeição volta com um código numérico e uma mensagem, e a nota precisa ser corrigida e enviada de novo com o mesmo número.
5. O add-on grava de volta a chave de acesso, o número do protocolo e o status no documento, armazena o XML autorizado (o emitente precisa guardá-lo pelo prazo legal) e o envia por e-mail ao comprador.
6. Os eventos após a autorização também passam pelo add-on: cancelamento (em geral em até 24 horas após a autorização, depois disso só onde o estado permite), a carta de correção CC-e para erros que não alteram impostos, valores ou partes, e a inutilização para anular números não usados de uma sequência.

A entrada funciona no sentido inverso. A CRD7 tem uma coluna AToRetrNFe, “Authorization to Retrieve NFe from SEFAZ” (autorização para baixar NF-e da SEFAZ), e a SefazDate, a data da última atualização vinda da SEFAZ, o que mostra que a SAP espera que os dados do parceiro de negócios e os downloads de NF-e sejam sincronizados com a SEFAZ por algo fora do núcleo. Bons add-ons buscam o XML da NF-e do fornecedor pelo CNPJ da empresa e criam a partir dele um esboço de recebimento de mercadorias (goods receipt PO) ou de nota fiscal de entrada (A/P invoice).

O que vale dos meus projetos com modelo de autorização prévia no Equador, na Guatemala, em El Salvador e no Panamá:

• Uma única fonte de numeração. O número da Nota Fiscal precisa vir da sequência do SAP Business One, nunca do add-on. Se dois sistemas distribuem números, aparecem lacunas, e no Brasil cada lacuna exige um pedido de inutilização.
• Mapeie os códigos de imposto com o contador antes que alguém escreva XML. Um código de imposto do SAP é uma combinação de tipos de imposto e alíquotas; a NF-e quer CST por imposto, CFOP por linha, o dígito de origem do ICMS e, para o ICMS-ST, a base e a margem. Coloque lado a lado a visão do SAP e a visão do XML para cada cenário real (venda dentro do estado, venda para outro estado, venda a consumidor final em outro estado, devolução, remessa) e obtenha a aprovação.
• Corrija o cadastro antes do piloto. Um CNPJ errado, a falta de I.E. em um contribuinte, um item sem NCM ou uma linha sem CFOP geram cada um uma rejeição da SEFAZ, uma nota por vez, enquanto o caminhão espera. As consultas abaixo os encontram em minutos.

O que mudou em 2026: CNPJ alfanumérico e a reforma do IBS/CBS

Duas mudanças brasileiras deste ano chegam direto aos dados do SAP Business One.

CNPJ alfanumérico. A Instrução Normativa RFB 2.229, de 15 de outubro de 2024, introduziu CNPJs cujas 12 primeiras posições podem conter as letras de A a Z além de dígitos. A Receita Federal os atribui só a novas inscrições a partir de julho de 2026; os CNPJs existentes continuam válidos e inalterados. O cronograma da Receita mostra os sistemas do CNPJ entrando em produção em 27 de julho de 2026 e o primeiro CNPJ alfanumérico emitido em 31 de julho de 2026. Os dois dígitos verificadores continuam numéricos e ainda são calculados com módulo 11, mas cada caractere agora vale seu código ASCII menos 48, então de 0 a 9 mantêm seus valores e A vale 17. A própria página de ajuda Fiscal IDs da SAP já usa o exemplo 12.ABC.345/01DE-35, e esse exemplo passa na nova verificação: conferi com o algoritmo da consulta abaixo.

O que quebra na prática: campos definidos pelo usuário do tipo numérico, add-ons que removem tudo menos dígitos antes de enviar o XML, fórmulas do Crystal Reports que formatam o CNPJ com uma máscara só de dígitos, código de integração que converte o CNPJ em BIGINT e consultas de validação copiadas de posts de fórum de 2015. A chave de acesso de uma NF-e emitida por uma empresa com CNPJ alfanumérico também contém essas letras, então qualquer campo ou índice que guarde a chave de acesso como número também precisa mudar.

IBS e CBS. A Lei Complementar 214/2025 criou a CBS (federal) e o IBS (estados e municípios), com 2026 como ano de teste. A Nota Técnica 2025.002-RTC adiciona à NF-e e à NFC-e um grupo IBS/CBS com CST e códigos de classificação próprios. A regra da SEFAZ que rejeita uma nota sem esse grupo mudou entre versões da nota e foi adiada para produção nas versões mais recentes, enquanto a obrigação de informar continua; confira a versão atual no Portal Nacional da NF-e antes de se comprometer com uma data. Para o SAP Business One, isso é uma nova versão do add-on mais configuração: novos tipos de imposto ou campos definidos pelo usuário para os códigos IBS/CBS em itens e códigos de imposto, e uma decisão sobre se os valores do ano de teste são calculados pelo motor de impostos ou só preenchidos no XML pelo add-on. Pergunte ao fornecedor do seu add-on qual versão de NT a build atual suporta.

Como encontrar CNPJs e CPFs inválidos no SAP Business One?

A CRD7 guarda uma linha por parceiro de negócios, endereço e tipo de endereço (S para entrega, B para cobrança), com as colunas genéricas TaxId0 a TaxId14. Em um banco de dados do Brasil, a janela Fiscal IDs grava o CNPJ em TaxId0 e a Inscrição Estadual em TaxId1, como uma resposta na SAP Community já descrevia para a release 8.8. A coluna que guarda o CPF segue a ordem dos campos na janela; não presuma, meça. Esta primeira consulta mostra, por coluna, quantos valores parecem um CNPJ (14 caracteres) ou um CPF (11 dígitos):

-- SQL Server: which CRD7 column holds which Brazilian ID
SELECT 'TaxId0' AS Col, SUM(CASE WHEN LEN(X) = 14 THEN 1 ELSE 0 END) AS Len14, SUM(CASE WHEN LEN(X) = 11 THEN 1 ELSE 0 END) AS Len11
FROM (SELECT REPLACE(REPLACE(REPLACE(REPLACE(ISNULL(TaxId0, ''), '.', ''), '/', ''), '-', ''), ' ', '') AS X FROM CRD7) A
UNION ALL
SELECT 'TaxId4', SUM(CASE WHEN LEN(X) = 14 THEN 1 ELSE 0 END), SUM(CASE WHEN LEN(X) = 11 THEN 1 ELSE 0 END)
FROM (SELECT REPLACE(REPLACE(REPLACE(ISNULL(TaxId4, ''), '.', ''), '-', ''), ' ', '') AS X FROM CRD7) B;
-- Repeat the block for TaxId1..TaxId3 and TaxId5 if TaxId4 shows no 11-digit values.

A consulta principal então verifica todos os parceiros de negócios ativos. Ela aceita tanto o CNPJ numérico antigo quanto o novo alfanumérico, rejeita preenchimentos com dígitos repetidos como 00000000000000 e 11111111111, e descreve o problema em palavras. Troque F.TaxId4 se a primeira consulta colocou o CPF em outra coluna.

-- SQL Server: invalid CNPJ (numeric or alphanumeric) and CPF in BP fiscal IDs
WITH F AS (
    SELECT C.CardCode, C.CardName, C.CardType, F.Address, F.AddrType,
           UPPER(REPLACE(REPLACE(REPLACE(REPLACE(ISNULL(F.TaxId0, ''), '.', ''), '/', ''), '-', ''), ' ', '')) AS Cnpj,
           REPLACE(REPLACE(REPLACE(ISNULL(F.TaxId4, ''), '.', ''), '-', ''), ' ', '') AS Cpf
    FROM OCRD C
    JOIN CRD7 F ON F.CardCode = C.CardCode
    WHERE C.frozenFor = 'N'
), W AS (   -- position, weight for DV1, weight for DV2
    SELECT * FROM (VALUES (1,5,6),(2,4,5),(3,3,4),(4,2,3),(5,9,2),(6,8,9),(7,7,8),
                          (8,6,7),(9,5,6),(10,4,5),(11,3,4),(12,2,3),(13,0,2)) AS W(i, w1, w2)
), CN AS (
    SELECT F.CardCode, F.Address, F.AddrType,
           SUM((ASCII(SUBSTRING(F.Cnpj, W.i, 1)) - 48) * W.w1) % 11 AS R1,
           SUM((ASCII(SUBSTRING(F.Cnpj, W.i, 1)) - 48) * W.w2) % 11 AS R2
    FROM F CROSS JOIN W
    WHERE F.Cnpj LIKE REPLICATE('[0-9A-Z]', 12) + '[0-9][0-9]'
    GROUP BY F.CardCode, F.Address, F.AddrType
), P AS (   -- CPF positions 1..10 with weights for DV1 (10..2) and DV2 (11..2)
    SELECT * FROM (VALUES (1,10,11),(2,9,10),(3,8,9),(4,7,8),(5,6,7),(6,5,6),(7,4,5),
                          (8,3,4),(9,2,3),(10,0,2)) AS P(i, w1, w2)
), CP AS (
    SELECT F.CardCode, F.Address, F.AddrType,
           SUM(CAST(SUBSTRING(F.Cpf, P.i, 1) AS INT) * P.w1) * 10 % 11 % 10 AS D1,
           SUM(CAST(SUBSTRING(F.Cpf, P.i, 1) AS INT) * P.w2) * 10 % 11 % 10 AS D2
    FROM F CROSS JOIN P
    WHERE F.Cpf LIKE REPLICATE('[0-9]', 11)
    GROUP BY F.CardCode, F.Address, F.AddrType
)
SELECT F.CardCode, F.CardName, F.CardType, F.Address, F.AddrType, F.Cnpj, F.Cpf,
       CASE
         WHEN F.Cnpj = '' AND F.Cpf = '' THEN 'No CNPJ and no CPF'
         WHEN F.Cnpj <> '' AND CN.CardCode IS NULL THEN 'CNPJ has wrong length or characters'
         WHEN F.Cnpj <> '' AND F.Cnpj = REPLICATE(LEFT(F.Cnpj, 1), 14) THEN 'CNPJ is a repeated-digit filler'
         WHEN F.Cnpj <> '' AND (SUBSTRING(F.Cnpj, 13, 1) <> CAST(CASE WHEN CN.R1 < 2 THEN 0 ELSE 11 - CN.R1 END AS CHAR(1))
                            OR SUBSTRING(F.Cnpj, 14, 1) <> CAST(CASE WHEN CN.R2 < 2 THEN 0 ELSE 11 - CN.R2 END AS CHAR(1)))
              THEN 'CNPJ check digits wrong'
         WHEN F.Cpf <> '' AND CP.CardCode IS NULL THEN 'CPF has wrong length or characters'
         WHEN F.Cpf <> '' AND F.Cpf = REPLICATE(LEFT(F.Cpf, 1), 11) THEN 'CPF is a repeated-digit filler'
         WHEN F.Cpf <> '' AND (SUBSTRING(F.Cpf, 10, 1) <> CAST(CP.D1 AS CHAR(1))
                           OR SUBSTRING(F.Cpf, 11, 1) <> CAST(CP.D2 AS CHAR(1)))
              THEN 'CPF check digits wrong'
       END AS Problem
FROM F
LEFT JOIN CN ON CN.CardCode = F.CardCode AND CN.Address = F.Address AND CN.AddrType = F.AddrType
LEFT JOIN CP ON CP.CardCode = F.CardCode AND CP.Address = F.Address AND CP.AddrType = F.AddrType
WHERE NOT (F.Cnpj = '' AND F.Cpf = '' AND F.Address <> '')   -- empty extra address rows are normal
ORDER BY Problem DESC, F.CardCode;

Linhas com Problem = NULL estão corretas; filtre-as quando confiar na consulta. No query manager do SAP Business One, envolva-a como SELECT * FROM ( ... ) Q WHERE Q.Problem IS NOT NULL depois de transformar as CTEs em tabelas derivadas, porque o query manager não aceita um WITH no início em todas as versões.

A mesma lógica no SAP HANA, onde o LIKE não tem classes de caracteres e os nomes de colunas precisam de aspas:

-- SAP HANA: invalid CNPJ (numeric or alphanumeric) and CPF in BP fiscal IDs
WITH F AS (
    SELECT C."CardCode", C."CardName", C."CardType", F."Address", F."AddrType",
           UPPER(REPLACE_REGEXPR('[./ -]' IN IFNULL(F."TaxId0", '') WITH '')) AS "Cnpj",
           REPLACE_REGEXPR('[. -]' IN IFNULL(F."TaxId4", '') WITH '') AS "Cpf"
    FROM "OCRD" C
    JOIN "CRD7" F ON F."CardCode" = C."CardCode"
    WHERE C."frozenFor" = 'N'
), W AS (
    SELECT 1 AS "i", 5 AS "w1", 6 AS "w2" FROM DUMMY UNION ALL SELECT 2, 4, 5 FROM DUMMY UNION ALL
    SELECT 3, 3, 4 FROM DUMMY UNION ALL SELECT 4, 2, 3 FROM DUMMY UNION ALL SELECT 5, 9, 2 FROM DUMMY UNION ALL
    SELECT 6, 8, 9 FROM DUMMY UNION ALL SELECT 7, 7, 8 FROM DUMMY UNION ALL SELECT 8, 6, 7 FROM DUMMY UNION ALL
    SELECT 9, 5, 6 FROM DUMMY UNION ALL SELECT 10, 4, 5 FROM DUMMY UNION ALL SELECT 11, 3, 4 FROM DUMMY UNION ALL
    SELECT 12, 2, 3 FROM DUMMY UNION ALL SELECT 13, 0, 2 FROM DUMMY
), CN AS (
    SELECT F."CardCode", F."Address", F."AddrType",
           MOD(SUM((ASCII(SUBSTRING(F."Cnpj", W."i", 1)) - 48) * W."w1"), 11) AS "R1",
           MOD(SUM((ASCII(SUBSTRING(F."Cnpj", W."i", 1)) - 48) * W."w2"), 11) AS "R2"
    FROM F CROSS JOIN W
    WHERE F."Cnpj" LIKE_REGEXPR '^[0-9A-Z]{12}[0-9]{2}$'
    GROUP BY F."CardCode", F."Address", F."AddrType"
), P AS (
    SELECT 1 AS "i", 10 AS "w1", 11 AS "w2" FROM DUMMY UNION ALL SELECT 2, 9, 10 FROM DUMMY UNION ALL
    SELECT 3, 8, 9 FROM DUMMY UNION ALL SELECT 4, 7, 8 FROM DUMMY UNION ALL SELECT 5, 6, 7 FROM DUMMY UNION ALL
    SELECT 6, 5, 6 FROM DUMMY UNION ALL SELECT 7, 4, 5 FROM DUMMY UNION ALL SELECT 8, 3, 4 FROM DUMMY UNION ALL
    SELECT 9, 2, 3 FROM DUMMY UNION ALL SELECT 10, 0, 2 FROM DUMMY
), CP AS (
    SELECT F."CardCode", F."Address", F."AddrType",
           MOD(MOD(SUM(TO_INTEGER(SUBSTRING(F."Cpf", P."i", 1)) * P."w1") * 10, 11), 10) AS "D1",
           MOD(MOD(SUM(TO_INTEGER(SUBSTRING(F."Cpf", P."i", 1)) * P."w2") * 10, 11), 10) AS "D2"
    FROM F CROSS JOIN P
    WHERE F."Cpf" LIKE_REGEXPR '^[0-9]{11}$'
    GROUP BY F."CardCode", F."Address", F."AddrType"
)
SELECT F."CardCode", F."CardName", F."CardType", F."Address", F."AddrType", F."Cnpj", F."Cpf",
       CASE
         WHEN F."Cnpj" = '' AND F."Cpf" = '' THEN 'No CNPJ and no CPF'
         WHEN F."Cnpj" <> '' AND CN."CardCode" IS NULL THEN 'CNPJ has wrong length or characters'
         WHEN F."Cnpj" <> '' AND F."Cnpj" = RPAD('', 14, LEFT(F."Cnpj", 1)) THEN 'CNPJ is a repeated-digit filler'
         WHEN F."Cnpj" <> '' AND (SUBSTRING(F."Cnpj", 13, 1) <> TO_VARCHAR(CASE WHEN CN."R1" < 2 THEN 0 ELSE 11 - CN."R1" END)
                              OR SUBSTRING(F."Cnpj", 14, 1) <> TO_VARCHAR(CASE WHEN CN."R2" < 2 THEN 0 ELSE 11 - CN."R2" END))
              THEN 'CNPJ check digits wrong'
         WHEN F."Cpf" <> '' AND CP."CardCode" IS NULL THEN 'CPF has wrong length or characters'
         WHEN F."Cpf" <> '' AND F."Cpf" = RPAD('', 11, LEFT(F."Cpf", 1)) THEN 'CPF is a repeated-digit filler'
         WHEN F."Cpf" <> '' AND (SUBSTRING(F."Cpf", 10, 1) <> TO_VARCHAR(CP."D1")
                             OR SUBSTRING(F."Cpf", 11, 1) <> TO_VARCHAR(CP."D2"))
              THEN 'CPF check digits wrong'
       END AS "Problem"
FROM F
LEFT JOIN CN ON CN."CardCode" = F."CardCode" AND CN."Address" = F."Address" AND CN."AddrType" = F."AddrType"
LEFT JOIN CP ON CP."CardCode" = F."CardCode" AND CP."Address" = F."Address" AND CP."AddrType" = F."AddrType"
WHERE NOT (F."Cnpj" = '' AND F."Cpf" = '' AND F."Address" <> '')
ORDER BY "Problem" DESC, F."CardCode";

Uma observação sobre o dígito verificador. Para o DV1, multiplique os 12 primeiros caracteres por 5, 4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2; para o DV2, multiplique os 13 primeiros por 6, 5, 4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2. Calcule a soma módulo 11: resto 0 ou 1 dá 0; caso contrário, o dígito é 11 menos o resto. Com ASCII menos 48, um CNPJ numérico dá exatamente o mesmo resultado da regra antiga, e é por isso que uma consulta cobre os dois. Testei a aritmética com o exemplo da SAP 12ABC34501DE35, o clássico CNPJ de teste 11222333000181 e o CPF 16370927848 da ajuda da SAP, além de versões alteradas de cada um. Não a executei em um banco de dados brasileiro real, então rode-a primeiro em uma cópia e compare algumas linhas à mão.

Duas verificações mais curtas completam a revisão do cadastro antes de um go-live de NF-e:

-- SQL Server: items sold in the last 90 days without an NCM code, and A/R invoice lines without CFOP
SELECT DISTINCT I.ItemCode, I.ItemName, 'Item has no NCM code' AS Problem
FROM INV1 L JOIN OINV H ON H.DocEntry = L.DocEntry JOIN OITM I ON I.ItemCode = L.ItemCode
WHERE H.DocDate >= DATEADD(DAY, -90, GETDATE()) AND ISNULL(I.NCMCode, -1) = -1 AND I.ItemType = 'I'
UNION ALL
SELECT DISTINCT CAST(H.DocNum AS NVARCHAR(20)), L.ItemCode, 'Invoice line without CFOP'
FROM INV1 L JOIN OINV H ON H.DocEntry = L.DocEntry
WHERE H.DocDate >= DATEADD(DAY, -90, GETDATE()) AND ISNULL(L.CFOPCode, '') = '';

No HANA, troque DATEADD(DAY, -90, GETDATE()) por ADD_DAYS(CURRENT_DATE, -90), ISNULL por IFNULL, CAST(... AS NVARCHAR(20)) por TO_NVARCHAR(...), e coloque aspas em todos os nomes de tabelas e colunas.

O que perguntar antes de um projeto SAP Business One no Brasil?

Estas perguntas separam uma implantação brasileira tranquila de uma dolorosa, e nenhuma delas precisa de um brasileiro para responder à primeira rodada:

• Qual add-on de NF-e, e qual versão de NT a build atual suporta? Peça a versão que trata a Nota Técnica 2025.002-RTC e o CNPJ alfanumérico, e pergunte se ele também emite NFS-e (notas de serviço passam pelo padrão nacional da NFS-e ou pelo município) e CT-e, se você faz seu próprio transporte.
• Quem é dono das regras de determinação de código de imposto? As regras no SAP Business One decidem cada CFOP e CST. Elas precisam ser montadas com o seu contador, documentadas e testadas com casos reais por estado antes do go-live.
• Qual versão do SAP Business One e qual banco de dados? O arquivo ECD só é documentado para a versão SAP HANA. Se você está no SQL Server e pretende migrar, veja primeiro o que envolve uma migração de SQL para HANA.
• Onde ficam o status de autorização e o XML? Exija campos definidos pelo usuário nos documentos para chave de acesso, protocolo e status, para que relatórios, aprovações e integrações possam vê-los sem abrir o add-on.

Se você já usa o SAP Business One no Brasil, as consultas acima e uma revisão de como o seu add-on trata CNPJs alfanuméricos são uma verificação útil de um dia. Para o panorama mais amplo de como eu abordo a fatura eletrônica com modelo de autorização prévia, veja o hub de fatura eletrônica e os guias por país de Equador SRI (em inglês) e Guatemala FEL (em inglês), os dois mais próximos do modelo brasileiro no meu próprio trabalho. As tabelas usadas nesta página estão documentadas nas referências OCRD, OITM e INV1. Para trabalho de add-on ou integração em um sistema brasileiro, veja desenvolvimento de add-ons para SAP Business One (em inglês) e integração de fatura eletrônica; uma migração para HANA é tratada em migração de SQL para HANA (em inglês).

Sources

• SAP Help Portal: Localization for Brazil (SAP Business One 10.0)
• SAP Help Portal: Electronic Invoicing (Brasil)
• SAP Help Portal: Nota Fiscal: Brazil
• SAP Help Portal: janela Sequence for Nota Fiscal - Setup (Brasil)
• SAP Help Portal: Fiscal IDs: Brazil
• SAP Help Portal: campos para leitura por add-ons externos (SAP Note 1715284)
• SAP Help Portal: SPED Fiscal: Brazil
• SAP Help Portal: geração do arquivo ECD (SPED Contábil)
• SAP Business One SDK: tabela CRD7, identificações fiscais do cadastro de parceiros de negócios
• Receita Federal: CNPJ Alfanumérico (IN RFB 2.229/2024, cronograma, dígito verificador)
• Portal Nacional da NF-e: notas técnicas e leiaute (Nota Técnica 2025.002-RTC)

Related services

• Desenvolvimento para SAP Business One
• Integração de faturamento eletrônico