Guia do consultor SD — Reforma Tributária no SAP

• Nada a configurar: é entrega técnica. Ao SD cabe confirmar que a Note está ativa antes de informar os tipos de imposto novos no NF Writer.
• Validar que os campos de grupo e de tipo de imposto respondem nas transações J1B1N/J1B2N antes de começar o desenho do pricing.

Note 3552901 (me.sap.com)

• Confirmar a 3552901 aplicada antes de qualquer parametrização — a sequência é obrigatória.
• Decidir se os tipos de imposto da LC 214 já existem no sistema: é essa decisão de escopo que define se o BC set precisa ser ativado pelo time técnico. Em paisagem que já recebeu entregas anteriores da Reforma, eles podem estar lá.
• Escolher a variação 1, 2 ou 3 de cada grupo conforme o uso — dedutível, não dedutível ou a pagar. Em vendas, a variação relevante é a "a pagar" (3), origem dos tipos CBS3, IB3S e IB3M usados no pricing.
• Informar as alíquotas dos grupos CBS*, IB*M, IB*S e IS0* no campo de alíquota de 4 casas decimais do NF Writer — nunca no campo antigo de 2 casas.
• Validar o conteúdo de customizing entregue pelo BC set nas views atingidas antes de levar a configuração para QAS e PRD.
• Homologar abrindo uma NF de saída manual no NF Writer e confirmando que os grupos e tipos novos aparecem na tabela de impostos do item.

Note 3552903 (me.sap.com)

• Conferir, sem recriar, o que os BC sets entregaram: tipos de condição em V/06, sequências de acesso em V/07 e chaves de conta em OV34.
• Decidir a tabela de condição: usar a 392 entregue (discrimina só por país, alíquota única) ou criar uma própria conforme a regra de negócio.
• Criar em VK11 ao menos um registro de condição por tipo, com percentual legal, validade e código de imposto — a SAP não entrega registro de condição.
• Ajustar o esquema RVABRA em V/08: Net Base Reference estatística depois de ICMI e antes de IBRX, novos impostos depois de IBRX com chave de conta e faixa entre K004 e a Net Base Reference.
• Fechar a contabilização junto com o FI: chaves de processamento MWC/MWD/MWE em OBCN, contas do Razão em FS00 e determinação de contas no view cluster VC_T030K via SM34. A decisão contábil é do FI; ao SD cabe informar o cenário de vendas e homologar o resultado.
• Atualizar em SM30 a view J_1BNFTXCONDV para mapear os impostos novos na Nota Fiscal.
• Adaptar as configurações se o esquema de preço do cliente divergir do RVABRA padrão — a SAP entrega apenas o padrão.
• Homologar VA01 → VL01N → VF01 conferindo CBS e IBS no item, no total e na aba de impostos da NF.
• Fronteira de escopo: os passos rotulados como atividade manual desta Note são, na prática, customizing de SD — tabela e sequência de acesso, tipo e registro de condição, esquema de preço e view de mapeamento. Ao time técnico sobram as instruções de correção e a ativação dos BC sets. Só os registros de condição e a contabilização são marcados como obrigatórios; os demais blocos são "confira, não recrie" — mas viram trabalho manual obrigatório se o BC set não ativar limpo.

Note 3556404 (me.sap.com)

• Confirmar a 3556404 implementada com todos os passos manuais feitos, exceto o ajuste do esquema de preço — é justamente o passo que muda aqui.
• Revisar, depois da ativação do BC set, os steps e as faixas do RVXBRA: no step 605 (CBS3) a faixa 320–590 entra no cálculo; no RVXBRA padrão, remover manualmente os steps 329 e 595.
• Ajustar o RVXBRA em V/08: Net Base Reference estatística entre ICMI e IBRX, novos impostos depois de IBRX com chave de conta e faixa entre K004 e a Net Base Reference.
• Atualizar o intervalo da linha IBRX para considerar a faixa entre ICMI e a linha imediatamente anterior à Net Base Reference, e o início da linha totalizadora de impostos para incluir as linhas dos tributos novos.
• Atualizar em SM30 a view J_1BNFTXCONDV para o RVXBRA (uso A, aplicação V), mapeando os tipos de imposto novos.
• Adaptar tudo se o esquema do cliente divergir do RVXBRA padrão.
• Homologar ordem de venda e fatura pelo RVXBRA conferindo base, valor e total da NF.
• Aplicabilidade: só interessa a quem fatura pelo RVXBRA. Quem usa apenas RVABRA para na 3556404; quem usa os dois precisa das duas, nesta ordem.

Note 3571837 (me.sap.com)

• Fluxo da Nota Fiscal: em SM30, na view J_1BDF_STAT_TAXV, cadastrar para cada imposto novo o tipo de NF, o tipo de item e o tipo de imposto correspondente — CBS3, IB3S e IB3M.
• Fluxo contábil: em V/08, no esquema em uso (RVABRA ou RVXBRA), marcar a coluna Statistical nos steps das condições de CBS e IBS.
• Decidir a abrangência: quais tipos de NF e tipos de item do seu cenário de vendas entram na marcação — a SAP entrega o mecanismo, não o conteúdo da view.
• Homologar emitindo a NF de um cenário representativo e confirmando que CBS e IBS aparecem na aba de impostos do item mas não somam ao total nem geram partida no Razão.
• O aviso VT632 ao gravar a V/08 pode ser confirmado com Continue: é comportamento esperado da marcação estatística.
• A homologação tem de ir até o XML: imposto marcado como estatístico continua gerando tag, e grupo de CBS/IBS enviado quando não deveria é rejeição na SEFAZ.

Note 3605442 (me.sap.com)

• Nada a configurar: é entrega técnica. Confirmar que está ativa antes de parametrizar a determinação da situação tributária (Note 3619306).
• Validar que o campo aparece e grava no item de VBAP, LIPS e VBRP ao longo de um fluxo VA01 → VL01N → VF01.

Note 3609635 (me.sap.com)

• Manter a situação tributária de CBS/IBS por categoria de item de venda na view J_1BSDICA — é ela que alimenta a determinação automática. A SAP entrega o mecanismo; o conteúdo da regra é decisão funcional sua.
• Mapear antes, e por escrito, quais categorias de item do seu cenário correspondem a cada código de situação tributária (CST / cClassTrib) — inclusive devoluções, remessas, bonificações e transferências.
• Opcional: configurar o Log de Itens Incompletos para gerar mensagens de validação da situação tributária — procedimentos em OVA2, atribuição aos tipos de documento de venda em VUA2 e grupos de status em OVA0.
• Homologar VA01 → VL01N → VF01 conferindo que a situação tributária é determinada no item, copia para remessa e fatura e chega à aba Taxes II com texto e alíquota nominal corretos.
• Escopo do que não vem aqui: os campos novos no layout de tela da Nota Fiscal chegam por Note separada. Se o campo não aparece na tela do NF Writer mas grava em VBAP/LIPS/VBRP, o comportamento é esperado nesta entrega.
• Efeitos colaterais registrados: a Note 3714277 (texto da situação tributária truncado ao criar a NF) e a 3631495 (situação tributária não gravada no documento de remessa). Planeje as duas junto — a 3631495 quebra a cadeia ordem → remessa → fatura.

Note 3619306 (me.sap.com)

• Pré-configuração obrigatória, antes de qualquer ativação de BC set: excluir no RVABRA os steps 590, 603, 604, 605 e 750.
• No RVXBRA, excluir os steps 590, 605, 606, 607 e 750.
• Depois da ativação dos BC sets pelo time técnico, reconfigurar em V/08 os impostos novos depois das linhas de offset, de preferência a partir do step 755, e recriar o antigo step 750 na posição 765.
• Adaptar ao esquema do cliente se ele divergir do padrão.
• Colocar a atividade no plano de cutover por sistema: como não há instrução de correção, o Note Analyzer não acusa pendência e a configuração não viaja sozinha no transporte.
• Homologar recalculando um documento representativo e conferindo que a base de CBS/IBS caiu para o preço líquido sem tributos embutidos.
• A ordem importa e não é intuitiva: as exclusões dos steps antigos são obrigatórias e vêm antes da ativação dos BC sets. Reposicionar sem excluir deixa condição duplicada no esquema e base calculada duas vezes.

Note 3633283 (me.sap.com)

• Nada a configurar: é entrega técnica. Confirmar que está ativa antes de homologar faturamento em moeda estrangeira.
• Validar, num fluxo VA01 → VF01 com moeda diferente da moeda da empresa, que CBS e IBS aparecem corretos tanto no imposto do item quanto no total da Nota Fiscal.
• Aplicabilidade: só interessa a quem tem ordens ou faturas em moeda diferente da moeda da empresa — exportação, contratos indexados, clientes internacionais. Em operação totalmente em BRL o defeito não se manifesta, e é por isso que escapa dos roteiros de teste padrão.

Note 3635352 (me.sap.com)

• Decidir se a extensibilidade é mesmo necessária: sem implementação da BAdI vale a determinação padrão pela view J_1BSDICA. Só siga adiante se houver cenário de saída que a regra por categoria de item não cobre.
• Especificar a regra de negócio que a BAdI vai aplicar — quais critérios (tipo de operação, material, cliente, destino, natureza da saída) levam a qual código de situação tributária. O critério é decisão funcional de SD; o código é do time técnico.
• Documentar a regra com exemplos de documento antes de passar para o ABAP, e definir o comportamento padrão quando nenhum critério casar.
• Homologar cada cenário coberto pela regra, conferindo a situação tributária gravada no item e o que chega à Nota Fiscal.
• Aplicabilidade: aplique as correções para ter a BAdI disponível, mas só implemente o método se a determinação padrão não resolver. BAdI implementada sem necessidade vira ponto de manutenção permanente em cada mudança de regra da transição até 2033.

Note 3641807 (me.sap.com)

• Incluir o campo no catálogo de campos de preço em SPRO: J_1B_TAX_SITUATION (S/4HANA 1709 a 2023) ou TAX_SITUATION (SAP ERP 6.0 EHP5 a EHP8).
• Criar a tabela de condição com uso A e aplicação V, numerada no namespace de cliente (501–999), com o campo de situação tributária selecionado, e gerar.
• Incluir o acesso novo em J1BTAX, nas sequências BCBS, IBSM e IBSS, apontando para a tabela criada, marcado como exclusivo, conferindo que o campo está atribuído à estrutura de documento KOMP.
• Criar em VK11 ao menos um registro de condição por tipo informando a situação tributária e a alíquota legal vigente.
• Decidir o desenho: quais situações tributárias têm alíquota própria (reduções, regimes diferenciados), qual combinação de chave usar e como conviver com o registro anterior, só por país.
• Homologar mudando a situação tributária de um item e confirmando que a reprecificação redetermina a alíquota.
• Atenção ao efeito colateral do desenho: a partir daqui o sistema redetermina a alíquota sempre que a situação tributária do item muda. Avalie o impacto sobre documentos abertos e ordens já precificadas antes de transportar para produção.
• A aplicação das instruções de correção precisa estar concluída antes do primeiro passo de configuração.

Note 3656316 (me.sap.com)

• Decidir se o CFOP é mesmo o critério certo: só faz sentido se a regra por categoria de item não distinguir os casos que o CFOP distingue.
• Montar a matriz de mapeamento CFOP → situação tributária de CBS/IBS, incluindo devoluções, remessas, transferências e operações sem valor comercial, e definir o comportamento padrão para CFOP não mapeado.
• Entregar essa matriz ao time técnico como especificação da implementação da BAdI — o critério é decisão funcional de SD; o código é do time técnico.
• Homologar por CFOP: emitir um documento de saída representativo de cada faixa mapeada e conferir a situação tributária no item e na Nota Fiscal.
• Se você precisar antecipar a solução à entrega padrão do release, a Note não instala pelo Note Assistant — a entrega é mudança de configuração. Trate isso no plano de cutover, porque o Note Analyzer não sinaliza pendência de configuração.

Note 3658291 (me.sap.com)

• Definir o escopo: quais das Notes de CRM listadas na nota central se aplicam ao cenário do cliente (vendas no CRM, lista de faturamento, motor de billing do CRM, integração com a Nota Fiscal do ECC) e em que ordem entram no plano.
• Manter os valores de situação tributária de CBS e IBS no ECC, na atividade de customizing J_1BTAX_SITNV.
• Manter os mesmos valores no CRM, na view CRMC_TAX_SITNV — a manutenção é manual e independente nos dois lados.
• Atribuir o campo novo de situação tributária na view CRMV_PROC_ITMCAT, por categoria de item — é esse passo que liga a determinação automática nos documentos de venda do CRM.
• Homologar o ciclo completo: documento de vendas no CRM → remessa e Nota Fiscal no ECC, conferindo se a situação tributária chegou íntegra ao lado do ECC.

Note 3686727 (me.sap.com)

• Decidir, com o time fiscal, se o log de itens incompletos passa a barrar Nota Fiscal com campos de redução ou de alíquota nominal de CBS/IBS em branco — a SAP marca essa configuração como opcional.
• Se sim, definir o procedimento de incompletude em OVA2.
• Atribuir o procedimento aos tipos de documento de vendas em VUA2.
• Definir os grupos de status em OVA0, escolhendo o que trava e o que só avisa.
• Homologar em J1B1N/J1B2N: alterar a situação tributária à mão e conferir que as reduções de CBS e IBS aparecem sozinhas nas abas Overview e Taxes II; mexer na alíquota efetiva na aba de impostos e conferir o recálculo da nominal.
• Conferir com o fiscal se as reduções trazidas automaticamente batem com a tabela de situação tributária mantida no projeto — a Note traz o mecanismo, não o conteúdo.

Note 3699942 (me.sap.com)

• Nada a configurar: é entrega técnica. Confirmar que está ativa antes de homologar qualquer integração ou carga que crie Nota Fiscal pela BAPI BAPI_J_1B_NF_CREATEFROMDATA — faturamento externo, sistemas satélites, cargas de migração.
• Validar que o texto legal da situação tributária de CBS/IBS aparece gravado na NF resultante e sai no XML e no DANFE, igual ao que sai pela criação padrão.

Note 3701047 (me.sap.com)

• Levantar com o fiscal quais cenários de saída precisam herdar a situação tributária do documento de referência: devolução, nota complementar, faturamento de pedido emitido antes da virada de alíquota, remessa referenciando ordem anterior.
• Escrever a regra que a BAdI vai aplicar — para cada combinação de categoria do documento de referência e data, qual situação tributária de CBS/IBS o sistema deve gravar. A especificação funcional é do SD.
• Verificar antes se a determinação padrão já resolve: a BAdI só deve ser usada onde a regra por categoria de item de venda não basta.
• Homologar o ciclo VA01 → VL01N → VF01 nos cenários de transição, conferindo a situação tributária gravada em VBAP, LIPS e VBRP e o valor que sai no XML.
• Testar especificamente o caso de virada: documento de referência emitido sob alíquota anterior, faturado depois — é para isso que os campos novos existem.

Note 3703142 (me.sap.com)

• Incluir o campo J_1B_TAX_SITUATION na tabela MASSVBAP do objeto BUS2032 pela transação MASSOBJ.
• Repetir a inclusão em cada sistema da rota: a configuração acompanha o transporte da Note, mas a SAP pede execução por sistema.
• Levantar a carteira de pedidos de venda abertos com situação tributária ausente ou incorreta e definir o critério de seleção do lote.
• Executar a correção em massa pela MASS, em ambiente de teste antes de produção, conferindo a gravação em VBAP.
• Definir com o fiscal a janela para rodar a carga: pedido corrigido em massa é reprocessado na próxima remessa ou faturamento, e o efeito aparece direto na NF.

Note 3711219 (me.sap.com)

• Nada a configurar: é entrega técnica. Confirmar que está ativa antes de aplicar a Note 3729968, que é a que efetivamente muda as BAPIs de filial.
• Validar que os objetos gerados respondem: os domínios J_1BCGCBRA e J_1BCGCCOM criados, a estrutura J_1BWFIELD ajustada e, em S/4HANA, a CDS view I_BR_BUSINESSPLACE ativa.

Note 3729967 (me.sap.com)

• Nada a configurar: é entrega técnica. Confirmar que está ativa antes de homologar qualquer interface, relatório ou app que leia dados de filial pelas BAPIs BAPI_BRANCH_GETDETAIL e BAPI_BRANCH_GETLIST.
• Validar que o CNPJ alfanumérico volta íntegro nesses retornos e na montagem do CGC pela J_1BBUILD_CGC — inclusive nos documentos de saída que carregam o CNPJ da filial emissora.

Note 3729968 (me.sap.com)

• Levantar com o fiscal quais itens do portfólio caem no regime monofásico de IBS/CBS — a decisão de enquadramento é funcional e antecede qualquer parametrização.
• Confirmar que os tipos de imposto monofásicos (Ad Rem) já estão disponíveis no NF Writer e com alíquota informada, antes de tentar homologar o XML.
• Especificar, para quem tiver implementação própria, quais campos monofásicos cada uma deve preencher: a BAdI J_1BNF_ADD_DATA e as BAPIs de Nota Fiscal não passam a preencher os campos novos sozinhas. Qual valor vai em qual campo é decisão do SD; a codificação é do time técnico.
• Homologar o XML gerado conferindo o grupo monofásico item a item, e o comportamento na J1B1N/J1B2N.
• Manter o cenário sob observação: revisar o enquadramento do monofásico conforme a NT 2025.002 v1.50 (vigente — homologação até 01/09/2026, produção em 03/11/2026).

Note 3734949 (me.sap.com)

• Liberar o campo de tipo de operação com ente governamental no controle de tela da Nota Fiscal, se o cenário for usado — a própria SAP indica esse ajuste e remete ao procedimento da Note 3600246.
• Levantar com o fiscal se a empresa presta serviço de transporte a Consórcio Público (tipo 5) ou ao Comitê Gestor do IBS (tipo 6) — se não presta, os valores novos ficam disponíveis mas sem uso.
• Definir em que cenários de transporte o tipo novo de referência de documento (tipo 3, documento fiscal eletrônico anterior) deve ser informado, e instruir a operação.
• Homologar a emissão do CT-e com os valores novos preenchidos, conferindo o XML resultante contra a NT 2025.001 v1.14.
• Conferir se as descrições dos valores novos aparecem em tela: em vários releases a documentação dos elementos de dados só chega pela via técnica, e o valor fica exibido sem texto.

Note 3736831 (me.sap.com)

• Nada a configurar: é entrega técnica. Confirmar que está ativa antes de aplicar a Note 3770912, que é a que trata a chave de acesso da NF-e de exportação.
• Validar depois, na homologação do processo de exportação, que a chave de acesso com CNPJ alfanumérico é gravada e lida corretamente nos documentos de exportação e nas BAPIs de Nota Fiscal.

Note 3770911 (me.sap.com)

• Conferir na V/08 o desenho atual dos procedimentos RVXBRE e RVXBRF antes de mexer: quais steps de offset existem e a partir de qual número as linhas novas entram.
• Inserir os steps de CBS e IBS nas duas procedures depois das linhas de offset, preferencialmente a partir do step 755.
• Revisar tipos de condição (V/06), sequências de acesso (V/07), registros de condição (VK11/VK12) e o flag estatístico dos steps de CBS/IBS, coerentes com o que já foi feito em RVABRA/RVXBRA para a fase de teste de 2026.
• Manter o mapeamento das condições na view J_1BNFTXCONDV para RVXBRE/RVXBRF, com uso A e aplicação V.
• Definir com o FI as chaves de processamento e a determinação de contas dos tipos de imposto novos — a decisão contábil é do FI; ao SD cabe informar o cenário e homologar.
• Adaptar o padrão onde a procedure do cliente diverge do que a SAP entrega: a Note só cobre o padrão, e o aviso é explícito.
• Homologar ordem de venda e fatura do cenário de entrega futura com CBS e IBS calculados, conferindo a NF resultante.

Note 3776373 (me.sap.com)

• Nada a configurar: é entrega técnica. Confirmar que está ativa antes de solicitar a Note 3600246.
• Validar, depois da 3600246 aplicada, que os campos de tipo de NF de débito e de crédito e os campos de crédito presumido respondem no NF Writer.

Note 3600094 (me.sap.com)

• Mapear, antes de tudo, quais dos 41 campos novos o seu cenário de saída realmente usa — crédito presumido, transferência de crédito, Zona Franca, compra governamental e devolução não são universais, e é o controle de tela que decide o que o usuário vê.
• Manter o controle de tela da Nota Fiscal nas views de cabeçalho J_1BNFW_SCGV, J_1BNFW_SCGAV, J_1BAEHV, J_1BAKH_MANV e J_1BAKHV e nas de item J_1BNFW_SCGITV, J_1BNFW_SCGAITV, J_1BAEITV, J_1BAKIT_MANV e J_1BAKITV: é isso que habilita a aba Taxes II e as subtelas de DF-e, compra governamental e crédito presumido, e define quais campos ficam obrigatórios, opcionais ou só de exibição.
• Definir com o FI o uso dos tipos de documento de Nota Fiscal C (crédito) e D (débito) e das funções de emissão de NF-e 5 e 6 — e, do lado de vendas, quais tipos de NF e categorias de item vão gerar cada um.
• Escolher os valores de tipo de NF de débito (01 a 07: transferência de crédito para cooperativas, cancelamento de crédito em saída imune ou isenta, débitos de fatura não processados na liquidação, multa e juros, transferência de crédito por sucessão, pagamento antecipado, perda de estoque) e de tipo de NF de crédito (01 multa e juros, 02 apropriação de crédito presumido de IBS sobre saldo devedor na ZFM) aplicáveis ao negócio.
• Nos cenários de venda para ente público, definir o tipo de ente governamental (01 União, 02 Estado, 03 Distrito Federal, 04 Município), o percentual de redução de alíquota (PREDUTOR) e o tipo de operação com o ente.
• Na Zona Franca, escolher a classificação de crédito presumido de IBS (00 sem crédito, 01 bens de consumo final 55%, 02 bens de capital 75%, 03 bens intermediários 90,25%, 04 bens de informática e outros 100%).
• Marcar o indicador de fornecimento de bem móvel usado (INDBEMMOVELUSADO) nos itens em que ele se aplica.
• Homologar emitindo uma NF de saída pelo fluxo VA01 → VL01N → VF01, abrindo o documento no NF Writer, conferindo a aba Taxes II preenchida no item e validando no XML os campos novos de J_1BNFDOC e J_1BNFLIN.
• Parte dos objetos citados no guia pode já existir no sistema, entregue pela correção automática da Note 3600094 ou pelo report correspondente — verifique antes de criar entrada duplicada.
• Efeitos colaterais conhecidos: a Note 3650551 (ajuda de pesquisa da situação tributária e mensagem de número aleatório) e a 3705683 (descrição faltando nos tipos de documento de crédito e débito). A KBA 3644054 trata do caso em que a aba Taxes II não aparece — normalmente controle de tela incompleto.

Note 3600246 (me.sap.com)

• Nada a configurar: é entrega técnica. Confirmar que está ativa antes de homologar o comportamento estatístico das Notes 3605442 e 3633283.
• Validar em uma NF de saída que o total do documento não muda quando CBS e IBS são calculados como estatísticos.

Note 3606019 (me.sap.com)

• Nada a configurar: é entrega técnica. Confirmar que está ativa antes de iniciar o cadastro das situações tributárias.
• Validar que a tabela J_1BTAX_SITN abre para manutenção com os campos de CST, cClassTrib, redução de alíquota de CBS e de IBS e texto de NF.

Note 3613901 (me.sap.com)

• Nada a configurar: é entrega técnica opcional que acompanha a 3613901. Confirmar que está ativa antes de treinar o usuário-chave na manutenção da situação tributária.
• Validar que a ajuda F1 dos campos de CST e cClassTrib apresenta a descrição correta.

Note 3617526 (me.sap.com)

• Nada a configurar: é entrega técnica. Confirmar que está ativa antes de iniciar a determinação da situação tributária (Notes 3624057 e 3619306).
• Validar que os campos de alíquota e de redução de CBS e IBS chegam ao XML da NF-e no item.

Note 3618181 (me.sap.com)

• Nada a configurar: é entrega técnica. Confirmar que está ativa antes de abrir a manutenção da view de categoria de item da Note 3619306.
• Validar que o tipo de texto 6 – CBS/IBS existe como opção de mensagem de item da Nota Fiscal.

Note 3624057 (me.sap.com)

• Garantir que os tipos de imposto de CBS e IBS estejam informados na aba de impostos da NF com a alíquota correta — a nominal recalculada deriva daí, não do registro de condição. Tipo de imposto vazio ou com alíquota antiga produz número errado.
• Definir com o negócio em que situações o usuário do NF Writer tem permissão para alterar a alíquota de redução à mão: o recálculo automático só dispara nessa alteração manual e com a nominal zerada.
• Revisar o cadastro de situação tributária (J_1BTAX_SITN) porque é dele que sai o texto gravado como mensagem de item 6 – CBS/IBS: texto errado no cadastro vira texto errado no XML de todas as NFs.
• Homologar no NF Writer: alterar a alíquota de redução em um item e conferir a nominal recalculada; alterar o CST do item e conferir que a mensagem de item foi regerada com o texto novo, sem duplicar a anterior.
• Conferir o resultado no XML da NF-e antes de liberar o cenário para os usuários.
• Esta Note e a 3699942 tratam do mesmo campo por caminhos diferentes — aqui o gatilho é a alteração manual no NF Writer; lá, a determinação automática a partir da situação tributária. Homologue as duas no mesmo cenário: é comum a equipe testar só uma e concluir que o campo "não calcula".
• Efeitos colaterais conhecidos: a Note 3714277 (texto da situação tributária truncado ao criar a NF) e a 3650406 (cancelamento de atualização no NF Writer).

Note 3632130 (me.sap.com)

• Fixar com o FI e com o negócio, cenário a cenário, se CBS e IBS entram como estatísticos ou como tributos efetivos — essa única decisão determina o conteúdo do valor do item e do total no XML e, portanto, se a NF é aceita ou rejeitada.
• Manter a decisão coerente entre a linha de imposto da NF e o esquema de preços: item que sai estatístico no pricing e não estatístico na linha de imposto produz total inconsistente.
• Homologar emitindo NF-e nos dois modos e conferindo no XML que a soma dos valores de item bate com o total, antes de subir o cenário para produção.
• Incluir no roteiro de teste de SEFAZ o caso da rejeição 1094: é a evidência de que a regra W60-10 está atendida.
• Esta Note é o par da 3606019, e a ordem importa: a 3606019 tira do total os valores estatísticos; a 3634646 coloca no total do item e da NF os que não são estatísticos. Aplicar só uma produz exatamente o sintoma que a outra corrige.

Note 3634646 (me.sap.com)

• Nada a configurar: é entrega técnica. Confirmar que está ativa antes de pedir a Note 3632130.
• Validar depois que as mensagens do NF Writer relativas a CBS/IBS aparecem com texto legível, em vez de código de mensagem sem descrição.

Note 3637775 (me.sap.com)

• Nada a configurar: é entrega técnica. Confirmar que está ativa antes de solicitar a 3641679 ao time técnico.
• Validar que os campos de valor de IBS respondem no item da NF antes de homologar qualquer cenário de crédito presumido.

Note 3641678 (me.sap.com)

• Levantar com o fiscal em quais cenários de saída o crédito presumido de IBS deve ser deduzido do vIBS — é a regra de negócio que a BAdI vai aplicar, e a definição é do SD.
• Especificar o critério de preenchimento do indicador de dedução (INDDEDUZCREDPRES) por combinação de material, cliente, CFOP ou tipo de operação, e entregar essa especificação ao ABAP em forma de regra fechada.
• Confirmar que o campo do crédito presumido de IBS (VCREDPRESIBS) está sendo alimentado no cenário antes de esperar dedução: sem valor de crédito presumido, o indicador não muda nada.
• Homologar VA01 → VL01N → VF01 em um cenário com crédito presumido e outro sem, comparando o valor de IBS exibido e transmitido com o cálculo manual.
• Validar o XML gerado: o campo do indicador só aparece se a transformação de XML tiver sido ajustada pelo time técnico — se ele sumir do XML, é passo manual pendente, não erro de customizing.
• O indicador não existe na tela da Nota Fiscal e não tem customizing: só a BAdI de dados adicionais (J_1BNF_ADD_DATA) o preenche.
• O vIBS não é persistido — ele é montado a cada leitura ou impressão. Divergências entre tela e XML se investigam na rotina de determinação de valores, não em tabela.

Note 3641679 (me.sap.com)

• Nada a configurar: é entrega técnica. Confirmar que está ativa antes de especificar a regra de alíquota nominal da Note 3651045.
• Validar que os três campos de alíquota aparecem na estrutura de item disponível ao time técnico.

Note 3651044 (me.sap.com)

• Decidir com o fiscal qual é a alíquota nominal de CBS, de IBS estadual e de IBS municipal aplicável a cada combinação de cenário (material, cliente, município de destino, tipo de operação) — é a definição de negócio que alimenta a BAdI, e ela é do SD.
• Distinguir explicitamente alíquota nominal de alíquota efetiva ou reduzida na especificação: os campos desta Note carregam a nominal; a redução e a efetiva continuam pelo caminho da situação tributária e dos registros de condição.
• Confirmar se, no cenário do cliente, a alíquota nominal já é determinada automaticamente pelo NF Writer — se sim, a BAdI é exceção, não regra.
• Homologar VA01 → VL01N → VF01 e conferir, no item da NF, se as três alíquotas nominais aparecem com o valor esperado e chegam ao XML e ao DANFE.
• Registrar em documento de projeto qual regra a BAdI aplica: como o campo não tem customizing, a rastreabilidade fiscal depende dessa documentação.

Note 3651045 (me.sap.com)

• Definir a regra de negócio da situação tributária de CBS/IBS para os cenários que não são cobertos pela determinação padrão do fluxo de vendas — quando usar a situação tributária interna e quando usar a de tributação regular.
• Levantar todas as integrações, cargas e sistemas satélites que criam Nota Fiscal por BAPI_J_1B_NF_CREATEFROMDATA: cada um passa a ter de informar a situação tributária, sob pena de gravar CST e cClassTrib divergentes da regra do projeto.
• Decidir se a integração vai enviar a situação tributária interna (TAXSITUATION, que sobrescreve os códigos) ou os códigos separados — informando a interna, ela vence.
• Alinhar com quem consome BAPI_J_1B_NF_READDATA que os dois campos novos passam a ser devolvidos, para que relatórios e conciliações externas leiam a situação tributária da mesma fonte que a NF.
• Homologar criando NF pela BAPI com a situação tributária interna preenchida, com a de tributação regular preenchida, e com ambas vazias — conferindo o que ficou gravado em cada caso.
• A sobrescrita é assimétrica: TAXSITUATION sobrescreve CST e CCLASSTRIB; TAXSITUATIONREG sobrescreve CSTREG e CCLASSTRIBREG. Com ambos vazios, os valores existentes são mantidos — e a validação só ocorre quando os campos são declarados, então integração que não os envia passa em silêncio com o dado antigo.
• Existe correção posterior referenciando esta entrega: a Note 3765493 trata da situação tributária interna não determinada ao criar a NF pela MIGO.

Note 3656534 (me.sap.com)

• Nada a configurar: é entrega técnica, pré-requisito da 3656316. Confirmar que está ativa antes de montar a tabela de condição e a sequência de acesso por situação tributária.
• Validar que o campo de situação tributária aparece disponível no catálogo de campos do pricing antes de criar o registro em VK11.
• Duas armadilhas de sequenciamento: a validade cobre também SAP_FIN, então em paisagem com esse componente separado confirme com o Basis que os dois foram atendidos, senão o campo aparece de um lado só; e as atividades manuais são condicionais ao nível de SAP_BASIS — em sistema mais recente elas simplesmente não se aplicam.

Note 3658304 (me.sap.com)

• Nada a configurar: é entrega técnica. Confirmar que está ativa antes de solicitar a 3666872 ao time técnico.
• Validar que os campos de NFS-e estão disponíveis nas estruturas da BAdI antes de desenhar o cenário de serviços.

Note 3666810 (me.sap.com)

• Mapear os cenários de venda de serviços que passarão a emitir NFS-e no leiaute nacional e, separadamente, os que emitem no leiaute de São Paulo — são dois leiautes distintos na mesma Note, e o desenho de tipos de NF precisa refletir isso.
• Definir a regra que a BAdI vai aplicar para preencher os campos do leiaute (categoria, código de tributação nacional e municipal, deduções e reduções, documentos referenciados) por combinação de material de serviço, cliente e município.
• Especificar o tratamento dos documentos referenciados de NFS-e (tabela J_1BNFSE_DOCREF): em quais operações há referência a documento anterior e qual chave é usada.
• Desenhar explicitamente os cenários de cancelamento e de substituição de NFS-e — a Note cobre os dois, e eles costumam ficar de fora do escopo funcional até a homologação.
• Revisar a classificação fiscal de serviço nos dados mestre (código NBS e códigos de tributação) e a determinação de tipo de NF de serviço no fluxo de faturamento.
• Homologar VA01 → VF01 com item de serviço, conferindo o XML gerado, o cancelamento, a substituição e o log de modificações da Nota Fiscal.
• O método correto da BAdI muda por plataforma: em S/4HANA e S/4HANA Cloud Private Edition é o de preenchimento de campos adicionais da Nota Fiscal; no ECC é o método específico posterior à J1B1N. Especificar o errado na demanda custa um ciclo inteiro de desenvolvimento.
• É a Note mais pesada desta compilação em volume de dependência: peça ao time técnico um plano de aplicação pelo Note Analyzer antes de prometer data de homologação de NFS-e.

Note 3666872 (me.sap.com)

• Nada a configurar: é entrega técnica, parte 1 da cadeia que termina na 3689409. Confirmar que está ativa antes de a cadeia 3681138 / 3689409 ser aplicada.
• Validar, quando a cadeia chegar, que os campos de crédito presumido e de ajuste de apuração aparecem no item da NF nos cenários de venda afetados.
• Dois campos ficam obsoletos nesta entrega: os códigos separados de classificação de crédito presumido de IBS e de CBS, substituídos por um código único. Implementação de BAdI, relatório Z ou integração que ainda leia os campos antigos precisa entrar no inventário de impacto antes da aplicação.
• Trate as três Notes da cadeia como um bloco: aplicar só a parte 1 não entrega nada visível e dá falsa sensação de progresso.

Note 3672604 (me.sap.com)

• Somente onde existe CRM: incluir na R3AC3, no objeto de download DNL_CUST_BRAZIL, as entradas J_1BTAX_SITN (sem tabela principal) e J_1BTAX_SITNT (tabela principal J_1BTAX_SITN), para que o customizing de situação tributária seja distribuído do ECC para o CRM.
• Somente onde existe CRM: revalidar a determinação da situação tributária na categoria de item do CRM e conferir que os valores replicados aparecem nas views de situação tributária do CRM.
• Em qualquer paisagem: revalidar o fluxo ordem → remessa depois da entrega, conferindo que a situação tributária chega ao item de remessa — as estruturas alteradas (BAPISDITM, BAPILEDLITEM) são as que sustentam esse repasse.
• Em qualquer paisagem: revalidar as integrações que criam ordem ou remessa por BAPI, porque as estruturas de interface ganharam campo novo — informar o campo é decisão sua, junto com o time de integração.
• Confirmar que a Note está ativa antes de solicitar a implementação da 3711219; caso contrário a MASS do objeto BUS2032 não recebe o campo.

Note 3677178 (me.sap.com)

• Não há customizing de SD: é entrega técnica de API. O que cabe ao SD é decidir o conteúdo funcional que vai trafegar por ela e homologar o resultado.
• Mapear, campo a campo, quais dos campos novos de item (código e classificação da situação tributária, alíquotas de IBS estadual e municipal e de CBS, valores efetivos e de diferimento) devem ser enviados pela integração e quais o próprio sistema determina — a decisão é funcional, não de código.
• Definir a origem de negócio dos campos de cabeçalho de tipo de NF de débito e de crédito e dos campos de ente governamental, tipo de operação com o ente e percentual de redução em compra governamental — são exatamente os campos que separam venda a ente público de venda comum.
• Definir o critério para bem móvel usado e para a chave de acesso e o número do item do documento fiscal referenciado, nos cenários de devolução, transferência e venda de ativo.
• Conferir, na NF criada por API, que os valores de CBS/IBS batem com o que o pricing de vendas calculou — divergência entre o que a API grava e o que o esquema de preços calcula é achado funcional, não técnico.
• Homologar o mesmo cenário pelas duas portas (NF criada por VF01 e NF criada pela API) e comparar campo a campo antes de liberar a integração.
• Esta Note e a 3702009 são a mesma API em duas versões da Nota Técnica: implementar só a 3680523 deixa a API defasada em relação ao leiaute que a SEFAZ vai validar.

Note 3680523 (me.sap.com)

• Nada a configurar: é entrega técnica de estruturas de dicionário. Confirmar que está ativa antes de a 3689409 ser implementada.
• Validar, nos testes da 3689409, que os campos novos chegam à BAdI de dados adicionais e às BAPIs de Nota Fiscal.

Note 3681138 (me.sap.com)

• Definir, por cenário de venda, quando informar a data prevista de entrega ou disponibilização (DPREVENTREGA) — é campo de cabeçalho e nasce de decisão logística e comercial, não do cálculo de imposto.
• Definir a regra da classificação para subcálculo de IBS na ZFM (TPCREDPRESIBSZFMPROD), escolhendo entre 00 sem crédito presumido, 01 bens de consumo final (55%) e 02 bens de capital (75%). Só se aplica a operações da Zona Franca de Manaus.
• Definir a regra da natureza da operação de doação (INDDOACAO): não aplicável ou doação. Cliente que faz doação ou brinde precisa mapear qual tipo de ordem e categoria de item carrega o indicador.
• Definir a origem do período de referência de apuração (COMPETAPURAJUSTECOMPET) e dos valores de ajuste de validação de IBS e de CBS — é o campo que liga a NF ao período de apuração, e a definição é conjunta com o FI.
• Definir a origem dos valores de estorno de crédito, da base de crédito presumido e do código de classificação de crédito presumido (CCREDPRES), que tem 13 valores oficiais fechados (entre eles aquisição de produtor rural não contribuinte, transportador autônomo pessoa física, reciclagem, revenda de bem móvel de não contribuinte, regime automotivo, Zona Franca de Manaus e Área de Livre Comércio). Escolher o código errado é erro fiscal, não erro de sistema.
• Definir a origem do período de apuração do crédito presumido de IBS na validação de débito em ZFM (COMPETAPURCREDPRESIBSZFM).
• Ajustar o controle de tela da Nota Fiscal para os campos, subtelas e para a aba Taxes II: a Note entrega parâmetros novos de controle de tela, e cabe ao SD definir o que fica obrigatório, opcional, só de exibição ou oculto em cada tipo de NF.
• Homologar VF01 → NF → XML conferindo que os campos preenchidos aparecem no arquivo da NF-e no leiaute da v1.31.
• Os códigos separados de classificação de crédito presumido de CBS e de IBS ficaram obsoletos e saíram da tela da NF; o sucessor é o código único. Customizing de controle de tela, variante, layout, BAdI própria, programa Z ou mapeamento de integração que ainda os referencie precisa ser revisto antes da implementação.
• Ordem obrigatória: 3672604 → 3681138 → 3689409. Pedir a 3689409 sem as duas anteriores só produz erro de implementação.

Note 3689409 (me.sap.com)

• Definir o critério de negócio que a BAdI vai aplicar ao NBM: em quais tipos de NF, CFOP, cenários de exportação ou importação e grupos de material o código deve ser sobrescrito, e qual valor entra em cada caso. A decisão é do SD com o fiscal; a implementação do método é do ABAP.
• Mapear a fonte do valor: se o NCM correto já está no dado mestre de material, a regra deve apenas confirmar; se depende do cenário, documentar a tabela de-para antes de pedir o código.
• Conferir na homologação que o NCM gravado no item da NF é o mesmo que sai no XML — divergência de NCM é rejeição na SEFAZ e reclassificação fiscal indevida.
• Incluir no roteiro de teste um item cujo NCM na BAdI difere do dado mestre, para provar que a regra está sendo aplicada e não silenciosamente ignorada.
• Sintoma que esta Note resolve: campo NBM presente na estrutura da BAdI mas não habilitado para entrada — o valor atribuído na implementação não chegava à NF.

Note 3698474 (me.sap.com)

• Não há customizing de SD: é entrega técnica de API. Ao SD cabe decidir o conteúdo funcional que trafega por ela e homologar.
• Definir a origem de negócio da data prevista de entrega no cabeçalho — mesma decisão do campo equivalente da 3689409, agora pelo lado da integração.
• Definir a regra dos campos de item de classificação de subcálculo de IBS na ZFM, natureza de doação e período de validação de IBS na ZFM.
• Definir a origem do período de ajuste de apuração e dos valores de ajuste e de estorno de crédito de IBS e CBS — junto com o FI, que é quem responde pelo período de apuração.
• Definir a base e a classificação do crédito presumido usando a mesma lista de 13 códigos oficiais da 3689409: API e tela precisam usar o mesmo critério, senão a NF criada por integração diverge da criada no faturamento.
• Homologar em paralelo: criar o mesmo cenário por VF01 e pela API e comparar os campos novos item a item, e depois no XML.
• Implementar a 3689409 sem a 3702009 deixa a paisagem com dois comportamentos para o mesmo leiaute: a NF do faturamento tem os campos da v1.31 e a NF da integração não.

Note 3702009 (me.sap.com)

• Nada a configurar: é entrega técnica de objetos de dicionário, base da 3710954.
• Confirmar com o time técnico que os objetos estão implementados e ativos em DEV, QAS e PRD antes de a 3710954 entrar: é ela que muda comportamento, e sem esta base não há o que testar.
• Reservar para a validação da 3710954 os cenários de saída: emissão de NF, exibição do parceiro na NF e preenchimento do cabeçalho a partir da filial.

Note 3710952 (me.sap.com)

• Não há customizing: é entrega de código. Ao SD cabe definir e executar a regressão dos cenários de saída depois que a Note estiver ativa.
• Retestar a emissão de Nota Fiscal com CNPJ alfanumérico no emitente (filial) e no destinatário, verificando que o número aparece íntegro na tela, na impressão e no arquivo.
• Conferir o arquivo da NF-e gerado: o CNPJ com letras precisa sair completo, sem truncamento nem conversão numérica — e a chave de acesso montada a partir dele precisa bater com a que a SEFAZ valida.
• Retestar a exibição do parceiro na NF e o preenchimento do cabeçalho a partir da filial.
• Retestar o upload de NFS-e e a verificação de CT-e e NF nos apps de Nota Fiscal do S/4.
• Homologar a listagem de fornecedores e parceiros com CNPJ alfanumérico antes de liberar o cenário de saída.
• Incluir no roteiro cenários mistos — parceiro com CNPJ numérico e parceiro com CNPJ alfanumérico na mesma remessa ou fatura —, que é onde a conversão costuma falhar.
• Efeitos colaterais conhecidos: a Note 3754258 (falha na criação da NF quando existe implementação própria da BAdI de dados adicionais, cenário comum em cliente de SD) e a 3757589 (erro de sintaxe na interface de chave de acesso da NFS-e).

Note 3710954 (me.sap.com)

• Nada a configurar: é entrega técnica de objetos de dicionário, base de toda a cadeia de filial e de Nota Fiscal.
• Confirmar com o time técnico que a Note está implementada e ativa em DEV, QAS e PRD antes de iniciar os testes da cadeia de filial (3729967 → 3729968) e dos objetos de NF (3710952 → 3710954).
• Não há customizing próprio: a validação funcional acontece nos cenários das Notes dependentes — sem esta base ativa, esses testes não valem.

Note 3745788 (me.sap.com)