NFCom - Modelo 62 - Rejeição: Grupo de informações da fatura deve ser informada para tipo de faturamento normal

[WINDEL]

Estou emitindo uma NFCom modelo 62 e está retornando o seguindo erro no momento do envio: 'Rejeição: Grupo de informações da fatura deve informada para tipo de faturamento normal'

No grupo 078 do manual da NFCom existe a seguinte validação:

Para emissão de NFCom normal, é obrigatório o preenchimento do gfat, salvo se a tag indPrePago for marcada como true.

Tenho duas duvidas referentes a esse tópico

- Qual seria a finalidade do indicador Pre-Pago? 

- Quando não for sinalizado o indicador Pre-Pago, no grupo gFat eu preciso preencher as informações de um boleto já com o o código de barras informado (Conforme o Manual)? E para os casos onde o pagamento seria via PIX ou dinheiro? 

Segundo o manual, todos esses itens devem ser preenchidos para o gfat quando não for pre-pago

[Italo Giurizzato Junior]

Boa tarde @WINDEL,

No meu entendimento tanto a mensagem de rejeição quanto a regra G78 deixa claro que para o tipo de faturamento (tpPag) igual a normal o grupo gFat devera constar no XML.

A não ser que foi informado o indPrePago ou o IndCessaoMeiosRede

O que vem a ser o indPrePago?

Indicador de serviço pré-pago: informar a tag somente se a nota for referente a um serviço exclusivamente pré-pago (exemplo: contas de celular pré-pago).

O que vem a ser o indCessaoMeiosRede?

Indicador de Sessão de Meios de Rede: essa tag dispensa geração do grupo Fatura. Apenas para notas dos tipos Normal e Substituição com tipo de faturamento normal.

(infelizmente essa outra tag tanto o manual quanto os schemas deixam a desejar em dar uma explicação mais detalhada do seu objetivo.

[WINDEL]

Obrigado pelo retorno @Italo Giurizzato Junior

Sim, infelizmente não existe muita explicação no manual. 

O que estou achando muito estranho é o grupo faturamento (gFat) requisitar que já exista um boleto gerado já com o código de barras e outras informações de banco no momento do envio da Nota.

E pelo que vi é só o boleto mesmo para faturamento, outras formas de pagamento como PIX, dinheiro e cartão não estão previstas.

Vocês receberam alguma informação extra sobre quando é necessário gerar as informações de faturamento? Pois, acho estranho já no momento do envio da nota possuir o boleto (título) gerado. Por exemplo, na NFe essa parte geralmente é realizada após a aprovação da nota.

[Diego Foliene]

Boa tarde!

1 hour ago, WINDEL said:

Vocês receberam alguma informação extra sobre quando é necessário gerar as informações de faturamento? Pois, acho estranho já no momento do envio da nota possuir o boleto (título) gerado. Por exemplo, na NFe essa parte geralmente é realizada após a aprovação da nota.

Não temos.

Nossa fonte de informações são os MOCs disponibilizados no Portal da Nota Fiscal Fatura de Serviço de Comunicação Eletrônica - SVRS.

Mas como citou, realmente é algo que passa a impressão de que precisa ser melhor detalhado.

O documento é "recente", vale a pena abrir um fale conosco junto a Sefaz para questionar como fazer nas situações que citou.

 

[WINDEL]

Certo!

Aproveitando queria apenas tirar mais uma duvida. No momento da aprovação da NFe, através dessa propriedade (ACBrNFe.WebServices.Retorno.Recibo) é retornado um número de recibo. É um número similar a esse formato: 436000016923056

Para a NFCom, existe a propriedade similar ((ACBrNFeCOM.WebServices.Enviar.Recibo), porém não tem conteúdo nenhum na propriedade e também verifiquei nos xmls de retorno e em nenhum momento possui algo similar ao recibo.

Sabem se na NFCom, não é utilizado esse recibo?

[Italo Giurizzato Junior]

Bom dia @WINDEL,

No Manual Visão Geral versão 1.00a na página 9 temos:

Como você pode ver o modo de envio da NFCom é unitário e síncrono, portanto no retorno do envio já temos o resultado do processamento, logo não existe o Recibo.

O Recibo só existe se o modo de envio é assíncrono como é o caso da NF-e.

Outra coisa, veja abaixo a estrutura completa do grupo <gFat>

Observe que o código de barras sempre vai ser necessário, mas ele não é de um boleto e sim desse documento. 

Como é o caso da fatura de energia elétrica ou a fatura de internet, esses documentos de cobrança possuem um código de barras, mas não se refere a um boleto previamente emitido.

Opcionalmente podemos informar os campos referente ao débito automático, quando o tomador solicita a inclusão dessa fatura a essa modalidade de pagamento junto ao banco e também opcionalmente poderemos ter a URL referente ao QR-Code do PIX.

De posse da fatura do NFCom o tomador poderá pagar em dinheiro ou com cartão em uma agencia bancária ou nos Correios.

[WINDEL]

Obrigado @Italo Giurizzato Junior

Tenho apenas mais uma duvida se puder me ajudar sobre a parte de tributação CST. Verifiquei nos fontes que existem as seguintes opções:   TCSTIcms = (cst00, cst20, cst40, cst41, cst51, cst90, cstICMSSN);

Essa última opção CSTICMSSN, significa que seria do simples nacional? Então caso o regime de tributação da empresa for do simples nacional, não é necessário informar o código cst? Ou não teria relação com isso?

 

[Italo Giurizzato Junior]

Bom dia @WINDEL,

Se a empresa for Simples Nacional o CST é o: cstICMSSN.

[WINDEL]

Olá.

Atualizei os fontes do ACBr e ao enviar uma nota de comunicação, está me retornando esse erro. Há uma semana atrás isso não estava ocorrendo nos meus testes.

Alguém tem ideia do que pode ser esse problema no momento do envio da Nota de Comunicação?

Segue em anexo o XML gerado.

Falha na validação dos dados da nota: 20

 --> 1866 - Element '{http://www.portalfiscal.inf.br/nfcom}det', attribute 'indNFComAntPapelFatCentral': The attribute 'indNFComAntPapelFatCentral' is not allowed.

 

43240793146140000153620010000000201051861696-NFCom.xml

[WINDEL]

Realizei a atualização dos schemas e agora está ocorrendo esse erro de rejeição. Achei que poderia ser erro de nota duplicada, mas esse número que estou emitindo (nota 20), não fiz a submissão ainda.

<?xml version="1.0" encoding="UTF-8"?>
<retNFCom versao="1.00">
    <tpAmb>2</tpAmb>
    <cUF>43</cUF>
    <verAplic>RS20240708154540</verAplic>
    <cStat>698</cStat>
    <xMotivo>Rejeição: indicador de nota anterior em </xMotivo>
</retNFCom>

[Italo Giurizzato Junior]

Boa tarde @WINDEL,

Na sua aplicação, mais precisamente na procedure que alimenta o componente ao detalhar o produto e serviço faça conforme o exemplo abaixo:

    with Det.New do
    begin
      nItem := 1;
      chNFComAnt := '';
      nItemAnt := 0;
      indNFComAntPapelFatCentral := tiNao;  // Incluir esta linha
      (...)
    end;

 

[WINDEL]

Bom dia @Italo Giurizzato Junior

Obrigado pelo retorno, adicionando essa linha funcionou a aprovação da nota.

Agora falta só mais um ajuste para ser feito para o cancelamento da nota através do carregamento do xml. Isso vocês conseguem simular no exemplo demo com o xml que estou enviando em anexo.

Passos para simular:

- Abrir o Aplicativo demo e clicar no botão cancelamento com xml

Selecionar esse xml que enviei em anexo.

Ocorrerá esse erro: Valor String inválido para TIndicador.

Esse erro ocorre quando roda o seguinte comando: ACBrNFCom.NotasFiscais.LoadFromFile("arquivo xml")

Com os xml antigos funciona, mas com os novos recém gerados, ocorre o erro.

Podem dar uma verificada nesse erro, por gentileza?

 

43240793146140000153620010000000221018858600-NFCom.xml

[Italo Giurizzato Junior]

Bom dia @WINDEL,

Já inclui na minha lista de tarefas. TK-5724

[WINDEL]

Obrigado @Italo Giurizzato Junior

Quando vocês solucionarem, pode me dar um retorno?

[Italo Giurizzato Junior]

Boa tarde @WINDEL,

Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.

[WINDEL]

Olá @Italo Giurizzato Junior

Fiz a atualização e instalação e funcionou o cancelamento da nota via carregamento de XML. 

 

[Italo Giurizzato Junior]

Obrigado por reportar.

Fechando. Para novas dúvidas, criar um novo tópico.