865 - Rejeicao: Total dos pagamentos menor que o valor total da nota

[Francisco IBS]

Bom Dia...

Estou realizando alguns testes na NFe 4.0 e ao tentar utilizar "tPag = 90= Sem pagamento" não informando assim valor dos pagamentos estava tendo o retorno:
865 - Rejeicao: Total dos pagamentos menor que o valor total da nota

A estrutura no XML fica assim:
<pag>
    <detPag>
        <tPag>90</tPag>
        <vPag>0.00</vPag>
    </detPag>
</pag>

Fiz uma alteração na "pcnNFeW" no procedimento "TNFeW.Gerarpag" alterando a programação de:
    Gerador.wCampo(tcStr, 'YA02', 'tPag', 02, 02, 1, FormaPagamentoToStr(nfe.pag.tPag), DSC_TPAG);
    Gerador.wCampo(tcDe2, 'YA03', 'vPag', 01, 15, 1, nfe.pag.vPag, DSC_VPAG);
    
Para:
    Gerador.wCampo(tcStr, 'YA02', 'tPag', 02, 02, 1, FormaPagamentoToStr(nfe.pag.tPag), DSC_TPAG);
    if (NFe.pag.tPag <> fpSemPagamento) then
      Gerador.wCampo(tcDe2, 'YA03', 'vPag', 01, 15, 1, nfe.pag.vPag, DSC_VPAG);    
      
Assim gerando um novo XML que validou.

Nova estrutura do XML ficou:
<pag>
    <detPag>
        <tPag>90</tPag>
    </detPag>
</pag>

Alteram no SVN?

pcnNFeW.pas

[guimaraesrodrigo]

Boa tarde Francisco. Tive o mesmo problema.

Resolvi com a linha    

if (NFe.pag.Items.tPag <> fpSemPagamento) then

Att,

[jairovianna]

Amigos,

continuo com o problema.

Guimaraes, pode esclarecer "NFe.pag.Items.tPag" , pois de acordo com o compilador, devo mencionar o numero de índice do 'items', tipo pag.items.[0].tPag porem mesmo fazendo isso

recebo a rejeição "O Campo forma de pagamento deve ser preenchido com a opção 'Sem pagamento'

Meu teste é com notas de devolução, e o código está assim :

if (eCfop.text='5202') or (eCfop.text='5411')  or (eCfop.text='6411') or (eCfop.text='6202') or (eCfop.text='6201') or (eCfop.text='5929')  or (eCfop.text='5202') or (eCfop.text='5411')  then
                  begin
                    Pag.add.tPag:=fpSemPagamento;

                   // Pag.add.vPag:=0; - Se habilito essa linha, a rejeição passa a ser a citada acima 865 - Rejeição : Total dos pagamentos menor que o valor total da nota

                 end
grato

 

[Francisco IBS]

19 minutos atrás, jairovianna disse:

Amigos,

continuo com o problema.

Guimaraes, pode esclarecer "NFe.pag.Items.tPag" , pois de acordo com o compilador, devo mencionar o numero de índice do 'items', tipo pag.items.[0].tPag porem mesmo fazendo isso

recebo a rejeição "O Campo forma de pagamento deve ser preenchido com a opção 'Sem pagamento'

Meu teste é com notas de devolução, e o código está assim :

if (eCfop.text='5202') or (eCfop.text='5411')  or (eCfop.text='6411') or (eCfop.text='6202') or (eCfop.text='6201') or (eCfop.text='5929')  or (eCfop.text='5202') or (eCfop.text='5411')  then
                  begin
                    Pag.add.tPag:=fpSemPagamento;

                   // Pag.add.vPag:=0; - Se habilito essa linha, a rejeição passa a ser a citada acima 865 - Rejeição : Total dos pagamentos menor que o valor total da nota

                 end
grato

 

Tarde Jairo, a questão é que vc precisa mudar a unit "pcnNFeW" no procedimento "TNFeW.Gerarpag".

Se observar o comentário do Guimaraes ele resolvou o problema da mesma forma que eu.

Pelo que deu a entender vc postou uma parte do código do seu sistema e o problema esta no tratamento que o componente estava fazendo, só ir na Unit e no procedimento, adicionar o if que irá resolver.

PS: A unit com a alteração esta em anexo, fiz o update no dia da postagem para ver se não estava com o fonte desatualizado.

[jairovianna]

Amigos,

desconsiderem meu post acima. O erro estava no meu codigo.

O correto é :

If Cfop de 'devolução' then

                    with Pag.Add do
                      begin
                        tPag:=fpSemPagamento;
                        vPag:=StrToFloat(eTotalNfe.Text);
                      end;

obrigado

[Dangelo Porto]

Estou com esse mesmo problema com venda normal. Para mim esta tudo normal

52171002464557000109550010000488761000488767-nfe.xml

Editado 19 Outubro, 2017 por Dangelo Porto

[RicardoVoigt]

5 minutos atrás, Dangelo Porto disse:

Estou com esse mesmo problema com venda normal. Para mim esta tudo normal

52171002464557000109550010000488761000488767-nfe.xml

Bom dia,

colando teu XML no validador do SEFAZ RS (https://www.sefaz.rs.gov.br/NFE/NFE-VAL.aspx) retornou os seguintes erros:

297 - [Simulacao] Rejeicao: Assinatura difere do calculado
778 - [Simulacao] Rejeicao: Informado NCM inexistente
872 - [Simulacao] Rejeicao: Informado Duplicata Mercantil como Forma de Pagamento e nao preenchido o Grupo Duplicata

Att

Ricardo

[Dangelo Porto]

Obrigado!

Já encontrei o erro o tPag  12=Vale Presente

[Francisco IBS]

1 hora atrás, Dangelo Porto disse:

Estou com esse mesmo problema com venda normal. Para mim esta tudo normal

52171002464557000109550010000488761000488767-nfe.xml

 

28 minutos atrás, Dangelo Porto disse:

Obrigado!

Já encontrei o erro o tPag  12=Vale Presente

Note que o problema que comentei é no caso de vc estar utilizando "tPag = 90= Sem pagamento", vc postou um xml com vários tipos e formas de pagamento, não tem nada haver com a situação reportada no tópico.

[Agnaldo Prates]

6 horas atrás, Dangelo Porto disse:

Estou com esse mesmo problema com venda normal. Para mim esta tudo normal

52171002464557000109550010000488761000488767-nfe.xml

Você informou um pagamento com duplicata parece que falta informar o grupo de duplicatas.

[danielgustavo]

Bom dia,

Estou com a mesma situação onde caso seja uma nota onde não tenha cobrança do destinatário, ou seja, com tPag = 90, está retornando "865 - Rejeicao: Total dos pagamentos menor que o valor total da nota". 

Se for passar vPag = 0.00 retorna este erro, e se não passar vPag retorna falha no schema, pois conforme o manual essa tag é obrigatória quando houver detPag.

Acredito que a SEFAZ tenha que incluir uma exceção na rejeição 865 para não validar caso haja tPag = 90, porém até então não consigo autorizar nenhum nota de bonificação, remessa e etc na versão 4.00.

[Francisco IBS]

40 minutos atrás, danielgustavo disse:

Bom dia,

Estou com a mesma situação onde caso seja uma nota onde não tenha cobrança do destinatário, ou seja, com tPag = 90, está retornando "865 - Rejeicao: Total dos pagamentos menor que o valor total da nota". 

Se for passar vPag = 0.00 retorna este erro, e se não passar vPag retorna falha no schema, pois conforme o manual essa tag é obrigatória quando houver detPag.

Acredito que a SEFAZ tenha que incluir uma exceção na rejeição 865 para não validar caso haja tPag = 90, porém até então não consigo autorizar nenhum nota de bonificação, remessa e etc na versão 4.00.

Bom Dia...

Você realizou a alteração que passei no inicio do post?

[danielgustavo]

4 horas atrás, Francisco IBS disse:

Bom Dia...

Você realizou a alteração que passei no inicio do post?

Boa tarde Francisco,

Na verdade eu estava alterando direto no XML gerado e validando através da SEFAZ RS: https://www.sefaz.rs.gov.br/nfe/NFE-VAL.aspx.

Tanto passando um XML com <vPag>0.00 ou sem essa tag não valida.

Em anexo meu XML. Você por acaso tem um XML que valida sem erros nessas condições de que o tPag = 90 e a finalidade da nota (finNFe) seja Normal?

 

Att

Daniel

42180183238832000178550010010000361190129246 (3).xml

[Francisco IBS]

Bom Dia...

Desculpe a demora, mas precisei testar novamente a rotina já que parou de funcionar, creio que alguma nota técnica ou atualização no WS possa ter corrigido a "falha" que deixava não enviar a tag "vPag", quando testei isso devíamos estar na "Nota Técnica 2016.002 - v1.30".

Não utilizando as finalidades 3 e 4(Ajuste e Devolução) parece que é obrigado informar o valor do pagamento que é o que da a entender na NT.

Não querendo incomodar mais @BigWings ou @Italo Jurisato Junior saberiam algo mais sobre isso?

Dou o exemplo de uma nota de transferência não "existe" valor de pagamento e a finalidade da NFe pra esse caso não se encaixa no 3 ou 4, como tratar isso? Sei que não é culpa do ACBr mais questiono já que isso já esta em produção, como estão fazendo com esses casos?

Transferencia.xml

[danielgustavo]

Bom dia,

Sem problemas, só questionei para ter certeza que não há uma saída, pois pelos meus teste não encontrei... já abri um questionamento na SEFAZ quanto a essa situação porém ainda não retornaram...

[Roberto.Godinho]

Boa tarde,

Tive problemas referente a isto também, no meu caso era remessa de faturamento antecipado, para "resolver o problema" temporariamente estou enviando tPag = 90 e valor = vNF, desta forma esta autorizando, o correto, usando a lógica, é que quando fosse tPag 90 fosse suprimido a tag ou aceitasse valor zerado.

[gabriel sousa]

Boa tarde, se o valor total da NF-e for diferente da soma dos pagamento teremos a rejeição 865.

 

Mas existem casos onde o financeiro é de fato diferente do valor da nota, como por exemplo:

1 - Embutir o valor do ICMS antecipado (indústria antecipa o pagamento do ICMS para o destinatário) para o cliente pagar junto com o boleto da compra

2 - Bonificação, no qual o item compõe o valor da nota mas o financeiro tem um desconto

3 - Retenção de impostos apenas no financeiro, como o FUNRURAL na compra

 

Eu imagino que a SEFAZ irá modificar a regra nesse ponto novamente já que houve nova prorrogação para 02/07/2018 e a NT 2016.002 já sofreu 8 alterações. 

Gostaria de saber se alguém deparou com uma situação semelhante?

[edvilson.chaves]

Olá a todos alguma novidade sobre esse assunto? Estou com o mesmo problema.

[RicardoVoigt]

18 horas atrás, edvilson.chaves disse:

Olá a todos alguma novidade sobre esse assunto? Estou com o mesmo problema.

Bom dia,

qual finNFe e tPag informados ? versão 4?

Att

Ricardo

[gabriel sousa]

Olá, os dados estão assim:

finNFe = 1 - Normal

Versão NF-e = 4.00

tPag = Informado, mas como citado acima, o valor do pagamento é diferente do total.

<vNF>1500.00</vNF>

<pag>
    <detPag>
        <tPag>02</tPag>
        <vPag>1000.00</vPag>
    </detPag>
</pag>

[RicardoVoigt]

oi @gabriel sousa Vou arriscar um palpite, tenta isso:

inclui aí mais um item  com tPag=90 (Sem pagamento) e vPag = 500

Ficaria assim:

<pag>
    <detPag>
        <tPag>02</tPag>
        <vPag>1000.00</vPag>
    </detPag>
    <detPag>
        <tPag>90</tPag>
        <vPag>500.00</vPag>
    </detPag>
</pag>

Att

Ricardo

[edvilson.chaves]

Bom dia!!!

Gostaria de entender bem essa pag de pagamento mas olhei no manual e lá não tem nada prático.

Entendi que essa tag <pag> substitui a tag <Cob> que eu uso na versão 3.10 para informar como o cara pagou a nota fiscal. Só que se o cara faz uma remessa tem que informar mesmo se o tipo do pagamento for 90 ??? e a Tag <cob> devo informar ela???

Desculpe, sou meio leigo nessa parte: o que entende-se por duplicata e fatura???

[gabriel sousa]

@RicardoVoigt A sua ideia é boa para casos em que o valor do financeiro é MENOR que a valor da nota. Mas existem casos em que o valor do financeiro é MAIOR que o valor da nota, como por exemplo aquele caso que citei:

1 - Embutir o valor do ICMS antecipado (indústria antecipa o pagamento do ICMS para o destinatário) para o cliente pagar junto com o boleto da compra

Nessa situação onde o financeiro é maior que o valor da nota não posso apenas retirar do valor recebido, temos que pensar em situações de várias parcelas etc...

Editado 4 Abril, 2018 por gabriel sousa

[RicardoVoigt]

10 minutos atrás, edvilson.chaves disse:

Entendi que essa tag <pag> substitui a tag <Cob> que eu uso na versão 3.10 para informar como o cara pagou a nota fiscal. Só que se o cara faz uma remessa tem que informar mesmo se o tipo do pagamento for 90 ??? e a Tag <cob> devo informar ela???

Pela regra da Nota tecnica 2016-002, da nova versão 4.00, vc só vai poder informar cobrança com duplicatas <dup>   em conjunto com pagamento por Duplicata mercantil (tpag = 14).

Att

Ricardo

[RicardoVoigt]

Em 04/04/2018 at 11:09, gabriel sousa disse:

Mas existem casos em que o valor do financeiro é MAIOR que o valor da nota,

Só fazendo um teste...

Relendo aqui a Nota Tecnica, vi que existem ambas validações, quando o somatório dos pagamentos for menor e quando for maior, veja páginas 56 e 57, código das mensagens 865 e 866. Porém, quando o pagamento for maior, será exigido o troco.

ACHO que não contempla esse caso q vc citou...

Att

Ricardo

Editado 5 Abril, 2018 por RicardoVoigt
relendo a nota tecnica...