Italo Giurizzato Junior

Rejeição 681: RNTRC informado inexistente. Essa rejeição ocorre quando o modal é rodoviário e foi informado um RNTRC errado. Solução: Informar o numero do RNTRC correto, caso tenha duvidas entre em contato com a ANTT nos canais de atendimento para solucionar as pendências. As regras serão aplicadas aos RNTRC do transportador emitente do MDF-e e ao RNTRC do proprietário quando o veículo não pertencer ao emitente do MDF-e .

Olá pessoal, As validações da ANTT são aplicadas com base na integração entre os sistemas da agência e do ambiente autorizador do MDF-e, em caso de indisponibilidade do serviço de integração, as regras serão desabilitadas até a normalização. Em caso de rejeição, entre em contato com a ANTT nos canais de atendimento para solucionar as pendências. As regras serão aplicadas aos RNTRC do transportador emitente do MDF-e e ao RNTRC do proprietário quando o veículo não pertencer ao emitente do MDF-e O ambiente autorizador do MDF-e que o primeiro paragrafo se refere é a SVRS - SEFAZ-Virtual do Rio Grande do Sul. Só existe uma SEFAZ-Autorizadora, ou seja, responsável por recepcionar e autorizar o MDF-e. Logo todos os MDF-e (não importa a UF do emitente) são enviados para a SVRS.

Bom dia Adilson, Note que a mensagem de erro se refere a uma DLL, é bem provável que a versão da mesma seja antiga logo esta ocorrendo esse erro.

Bom dia a todos, Além de atualizar os fontes, reinstalou os componentes?

Bom dia Christiano, Veja o valor que você atribuiu a CRT. Este campo será obrigatoriamente preenchido com: 1 – Simples Nacional; 2 – Simples Nacional – excesso de sublimite de receita bruta; 3 – Regime Normal. Você informou o valor 1, logo ele vai gerar o grupo ICMSSN, para gerar o grupo ICMS00 o valor de CRT tem que ser 2 ou 3.

Bom dia Emmerson, A tag nova que você se refere é o grupo infMDFeSupl que contem a tag qrCodMDFe, cujo manual foi publicado abril/2019. Fiz as alterações necessárias no componente para que o mesmo gerasse o grupo e a tag conforme orientação contida no manual. Postei uma noticia no dia 14/06/2019 alertando que o ambiente de homologação já estava aceitando o XML com o grupo mencionado acima e que a data para o ambiente de produção passar a aceitar era 15/07/2019. As noticias não ficam na área SAC e sim na área aberta onde todos podem ler. Quem esta passando por problemas de QR-Code tanto em ambiente de homologação quanto de produção é porque não atualiza os componentes com frequência e só entra no fórum quando tem problema, se entra-se para saber se existe alguma noticia nova teria descoberto a novidade e se preparado para realizar os testes em ambiente de homologação e estaria pronto para quando fosse exigido em produção. Agora quanto ao numero do RNTRC consta no manual o seguinte (grifo meu): "As validações da ANTT são aplicadas com base na integração entre os sistemas da agência e do ambiente autorizador do MDF-e, em caso de indisponibilidade do serviço de integração, as regras serão desabilitadas até a normalização. Em caso de rejeição, entre em contato com a ANTT nos canais de atendimento para solucionar as pendências. As regras serão aplicadas aos RNTRC do transportador emitente do MDF-e e ao RNTRC do proprietário quando o veículo não pertencer ao emitente do MDF-e." O ambiente autorizador do MDF-e que se refere ao texto acima é a SVRS - SEFAZ-Virtual do Rio Grande do Sul.

Boa tarde a todos, Na verdade BigWings, quem decide se vai implementar ou não é a SEFAZ-Virtual do RS, pois ela é a única que recepciona todos os MDF-e de todas as UFs.

Boa tarde Luis, Por favor leia a noticia abaixo que publiquei a um mês.

Boa tarde André, O veiculo é do emitente do MDF-e? Se sim, porque você informou o proprietário? Agora se o veiculo não é do emitente do MDF-e, você não deve informar o RNTRC em infANTT, pois este RNTRC é do emitente.

Boa tarde a todos, Tenham em mente que se tratando de MDF-e só existe uma SEFAZ-Autorizadora, ou seja SVRS - SEFAZ-Virtual do RS. Não interessa de qual UF é o emitente do MDF-e, todos os MDF-e de todos os Estados brasileiros são enviados para a SVRS.

Boa tarde Asterix, Favor atualizar todos os fones de todas as pastas e reinstale a suíte ACBr. Depois faça novos testes.

Boa tarde Van, Existe sim essa rejeição, é que você esta vendo um manual antigo (versão 3.00) e não o novo (versão 3.00a). https://dfe-portal.svrs.rs.gov.br/Mdfe/Documentos

Boa tarde a todos, Favor atualizar os fontes, reinstalar os componentes e façam novos testes.

Boa tarde a todos, O componente ACBrCTe tem uma propriedade de configuração chamada: GerarInfCTeSupl que pode receber os seguintes valores: fgtNunca = não vai gerar no XML o grupo InfCTeSupl que contem a string do QR-Code; fgtSomenteProducao = só gera se o componente estiver configurado para o ambiente de Produção; fgtSomenteHomologacao = só gera se estiver configurado para o ambiente de Homologação fgtSempre = vai gerar no XML o grupo InfCTeSupl. O valor padrão é fgtNunca, mas a partir do dia 22/07/2019 para realizar testes no ambiente de homologação essa propriedade deve estar com o valor fgtSomenteHomologacao. E a partir do dia 26/08/2019 para o envio em ambiente de produção a propriedade devera esta com o valor fgtSomenteProducao ou fgtSempre. Quando se tornar obrigatório em ambos ambientes iremos remover essa propriedade de configuração do componente.

Boa tarde a todos, O componente ACBrMDFe tem uma propriedade de configuração chamada: GerarInfMDFeSupl que pode receber os seguintes valores: fgtNunca = não vai gerar no XML o grupo InfMDFeSupl que contem a string do QR-Code; fgtSomenteProducao = só gera se o componente estiver configurado para o ambiente de Produção; fgtSomenteHomologacao = só gera se estiver configurado para o ambiente de Homologação fgtSempre = vai gerar no XML o grupo InfMDFeSupl. Essa propriedade em breve vai deixar de existir, uma vez que a exigência em ambos os ambientes já foi ativada pela SEFAZ.

Bom dia João, Para um melhor entendimento sobre esse assunto assista o vídeo.

Marcelo, No meu entendimento é refazer por completo o DAMDFE deixando o mais parecido possível com o que consta no manual. Caso você não tenha os novos manuais, por favor acesse a nossa biblioteca através do link: http://svn.code.sf.net/p/acbr/code/tools/DFe/MDFe/Manuais/ Os mais atuais são os 3 que traz em seu nome a versão 3.00a

Marcelo, Se eu tiver mais de uma seguradora envolvida? O numero da apólice, é um só por seguradora, mas o numero da averbação podemos ter "N". Veja como vai ser a nova versão do DAMDFE a partir de outubro/2019

Boa tarde Adilson, A principio pode, desde que outras informações não sejam suprimidas e cujo o conteúdo do código de barras esteja presente no XML da NFS-e. Notei que ele é composto pela concatenação de 3 informações, sendo que a primeira é o numero da NFS-e, a segunda é o código de verificação e depois temos o que parece ser o CNPJ do emitente (segundo a imagem). A principio a maioria dos provedores se utilizam apenas o código de verificação para que o tomador possa checar se realmente a nota foi emitida. Vejo que esse código de barras é algo especifico de Catanduva/SP.

Boa tarde Gumercino, Essa sua alteração pode gerar efeito colateral em outros provedores. Favor atualizar os fontes e faça novos testes.

Boa tarde Marcelo, Você tem algum PDF de como estava antes e de como ficou agora? Se sim, poderia anexar os dois PDF?

Boa tarde João, Já passei para o pessoal analisar a sua alteração no que diz respeito a unit. Deste já muito obrigado pela colaboração. Uma pergunta: porque você ainda usa o XsXmlSeg em vez de XsLibXml2?

Bom dia, Tente este outro: https://dfe-portal.svrs.rs.gov.br/Mdfe

Bom dia Eliezer, Muito obrigado pela colaboração, já enviei para o repositório. Detalhe, os seus fontes estão desatualizados.

Bom dia, A única diferença que notei entre o XML de pedido de cancelamento gerado pelo componente e o de exemplo é que a tag <CodigoMunicipio> esta diferente. Gerada pelo componente o conteúdo é: 2611606 já o do exemplo o conteúdo é: 261160. Ou seja, o XML gerado pelo componente esta sendo informado o código IBGE completo do código do município, já no XML de exemplo esta faltando o ultimo digito que se não me falha a memória é um digito verificador. Como os webservices dos provedores costumam retornar mensagens de rejeição que não condiz com o problema, experimente informar o código do município se o ultimo digito.