Italo Giurizzato Junior

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.

Bom dia Guto, Muito obrigado pela colaboração, já enviei para o repositório. Um detalhe importante, os seus fontes estão desatualizados.

Bom dia Gumercino, Favor anexar a unit alterada para que possamos analisar.

Boa tarde Gumercino, Estranho, estou com os fontes atualizados e não estou tendo esse problema. Você atualizou todos os fontes de todas as pastas? Reinstalou os componentes?

Boa tarde João, Favor anexar as units alteradas para que possamos analisar.

Boa tarde Anderson, O nome do responsável técnico tem vogal acentuada? Se sim, deixe sem o acento. Outra coisa, quem esta gerando o grupo do Responsável Técnico é o próprio componente, correto? Não é você que esta inserindo depois do XML ter sido gerado e assinado?

Boa tarde Antônio, Verifique se o ícone da unit em questão não tem uma bolinha vermelha. Caso afirmativo, exclua o arquivo e baixe novamente.

Boa tarde Gumercino, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde João, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde, Obrigado pela colaboração, ainda hoje estarei enviando para o repositório.