Boa tarde,
Pessoal no ambiente de homologação estamos validando a transmissão de nota fiscal eletrônica e o sistema apresentou rejeição 853. Alguém passou por esse problema e como resolveu?
3 curtidas
Também estou com o mesmo problema.
2 curtidas
Por gentileza, Conte-nos mais detalhes de forma analitica sobre o que exatamente estão realizando, notas que estão validando, tipos das notas, se já consultaram o manual da sefaz, se os códigos fontes que geram o xml estão atualizados.
É um CT-e (Conhecimento de Transporte Eletrônico) que voce esta tentando validar ?
O tipo da Emissão é FS-DA (tpEmis=5) ou EPEC (tpEmis=4) ?
1 curtida
Tipo de nota de saída normal, mod 55, o tipo de pagamento é depósito a vista. tpEmis=1. Estou em ambiente de homologação.
Rejeição 853: Dados de cobrança não devem ser informados para pagamento a vista.
1 curtida
@gabrielle.sales Verifique as seguintes configurações : 01 se você está configurando um pagamento ‘à vista’ no Protheus. Se o pagamento é ‘à vista’, não é necessário preencher os campos relacionados à cobrança (como vencimento, número de parcelas, etc.). Essa informação é irrelevante, pois o pagamento é imediato e não há parcelas ou prazos a serem considerados;
02 Nas notas fiscais que indicam pagamento à vista, os campos relacionados à cobrança, como o QR Code, são opcionais ou não são necessários;
03 Como estão configurados campos de QR Code (especialmente o ‘sign’ ) estão sendo informados
1 curtida
@claudinei.nascimento Bom dia. Tudo bem ? Estou tendo o mesmo problema também no ambiente de homologação. Não temos o campo de QR Code e verifiquei o que você falou na primeira opção e mesmo assim o erro persiste, poderia me ajudar?
2 curtidas
@ViniciusJosee Sim! Claro que ajudo.
01 Copie aqui o xml que esta sendo gerado pelo erp protheus.
02 Qual é o conteúdo do campo duplicata na tabela nf de saída ‘F2_DUPL’ ?
1 curtida
Bom dia, o campo de saída ‘F2_DUPL’ está preenchido com o numero da nota.
Pela condição de pagamento informado( a vista ) no pedido de venda esse campo deveria estar em branco. Me corrija se eu estiver errado.
2 curtidas
Sim! Voce esta correto! O campo F2_DUPL deve estar vazio na condição de pagamento à vista.
Esta é uma das premissas.
Configure seu sistema para que este campo seja preenchido somente quando a condição de pagamento tiver que gerar parcelas de fato.
1 curtida
Boa tarde.
@claudinei.nascimento estou acompanhando esse caso e fiquei com uma duvida, faz um tempo que não implanto o sigafat, qdo vc diz que deve-se parametrizar o sistema para nao enviar a condição de pagamento a vista, onde tem essa configuração?
1 curtida
Sempre que a condição de pagamento tem no E4_COND o valor ZERO, o sistema gera um título no SE1 com a data de vencimento igual ao da emissão , até para o financeiro poder registrar o recebimento.
Na produção não estamos tendo este problema.
1 curtida
Prezados, boa tarde. Este problema ocorre somente quando NFs são transmitidas em ambiente de Homologação da SEFAZ, ou seja, quando configurado como Produção, o mesmo não ocorre. Alguém tem a solução contorno efetiva. Estamos testando várias notas que precisam ser transmitidas em ambiente do homologação usando a condição de pagamento à vista com E4_COND = 1 ou 0, grava o campo F2_DUPL que gera a rejeição.
Alguém com alguma solução de contorno ou explicação para o problema supradescrito?
@claudinei.nascimento - Você fez esse comentário: “Configure seu sistema para que este campo seja preenchido somente quando a condição de pagamento tiver que gerar parcelas de fato.”
Pergunto: como fazer este tipo de configuração?
Obrigado.
Postando a solução aqui pessoal. Essa validação está prevista na NT 2025.001 e refere-se aos dados da cobrança do XML que já está no ambiente de Homologação da SEFAZ. Quando o pagamento é a vista (TAG - indPag=0), não devem ser enviados os dados de cobrança. Esta validação irá entrar em produção a partir de 01/09/2025.
Documentação:
https://tdn.totvs.com/pages/releaseview.action?pageId=969576447
2 curtidas
Já esta com o pacote aplicado… mas vou conferir agora…, pois estavamos com a rejeição 852, já resolvida… e a condição de pagamento é 5dd …
muito obrigado
1 curtida
Realmente tinham colocado um outro RPO sem o pacote aplicado… reapliquei e tyudo funcionou. Muito obrigado
1 curtida
Olá, bom dia!
Estou com o mesmo problema… Apliquei o acumulado do backoffice no Protheus, mas não resolveu. Obs: Ambiente de produção!
1 curtida
Pessoal, bom dia!
Consegui resolver aqui da seguinte forma:
Atualizei o backoffice do protheus
Atualizei os documentos eletronicos (https://centraldeatendimento.totvs.com/hc/pt-br/articles/360043005493-Cross-Segmentos-Backoffice-Protheus-Doc-Eletrônicos-Documentos-Eletrônicos-NFe-Rdmake-NFESEFAZ-DANFE-MDFe-MDe)
Atualizei meu rdmake “nfesefaz.prw”.
Quem tiver um ambiente grande e complexo e nao tem tempo de fazer o diff no nfesefaz.prw, é possível resolver a rejeição 853 adicionando uma validação no fonte.
Só deixar montar o quando o indpag for diferente de “0”
3 curtidas
Após aplicação dos paths da TOTVS aqui funcionou! Path para o Protheus e Path do TSS
1 curtida