NFe - Texto de substituição tributária do frete

[Former Member]

Boa tarde,

Precisamos imprimir o texto de substituição tributária do frete no DANFE e no XML no campo de informações adicionais.

Este texto possui o seguinte formato: "ICMS s/ serviços de transporte ISENTO, cfe. Artigo 7º, Inciso XLI, Anexo IX, do RICMS-GO, Decreto 4852/97. Valor do frete R$ 197,54. Base de cálculo R$ 197,54. Alíquota 0,00. Valor do ICMS R$ 0,00. "

Os valores que aparecem neste texto precisam ser retornados a partir do custo de frete.

Na impressão do DANFE, é uma implementação relativamente simples.

Porém, estamos com dificuldade de seguirmos o fluxo até o custo de frete no método fill_header para o XML.

Isto porque no momento em que é executado o fill_header, ainda não foi gravado na tabela VBFA a relação do billing (sendo criado) com a respectiva delivery.

Pensamos então em utilizar a VBFA da memória, exportando a IN_VBFA do fill_item e importando no fill_header. Porém, esta relação também não existe na memória.

Alguém teria alguma sugestão quanto a este problema?

Obrigado,

Rodrigo.

[henrique_pinto]

Veja se o decouple está ativado (call Rfc= 1, 2 ou 3), na J1BNFE.

Em estando, o commit de gravação dos objetos no banco deveriam acontecer antes do envio do XML (e, em consequência, da BAdI).

[Former Member]

Oi Henrique,

Atualmente não estamos com o decouple ativado.

Fiz um teste, ativando o decouple com a opção 3 e debuguei a fill_header após executar o batch J_BNFECALLRFC. Realmente, com o decouple ativado os dados já estão gravados na VBFA.

Andei pesquisando um pouco aqui no fórum sobre isto e cheguei a conclusão que utilizar o decouple pode resolver alguns problemas de sincronização e também e é uma solução recomendada para diversas outras situações.

Pelo que entendi, ao ativar o decouple com a opção 3, a única mudança será que o envio será feito quando o batch rodar ao invés de imediatamente ao salvar o billing. Existe algum outro impacto além deste? Como é uma alteração no modo como salva e envia a NF, causa um certo receio

Obrigado!

Rodrigo.

[henrique_pinto]

Olá Rodrigo,

você está certo, o decouple é algo que já deveria estar ativado em 100% dos clientes pois ele elimina o risco de diversos problemas de perda de dados/transação quando há algum dump em código Z. Existem casos de notas que nao existem no ERP mas que vao pro GRC, dependendo de como o código está, e gera imposto a ser pago porém não há track nenhum desse imposto no ERP.

Com certeza, também concordo que o impacto é considerável mas na visão da SAP os benefícios compensam os riscos. Aconselho planejar com sua equipe a ativação do decouple asap.

Quanto ao modo (1, 2 ou 3), na nota do Decouple existem mais detalhes, porém em resumo:

1. numeracao e envio manuais (via J1BNFE)
2. numeracao manual (via J1BNFE) e envio posterior automatico (via Job)
3. numeração e envio automáticos (via Job).

O processo que geraria menor impacto atual (sem necessidade de processo manual) seria de fato o '3'.