Italo Giurizzato Junior

Boa tarde Walter, Primeiramente temos que entender o que vem a ser esse erro. Duplicidade com diferença de chave de acesso, significa que já existe na SEFAZ a respectiva nota, mas a chave é diferente. A chave é composta por variais informações e uma delas é chamada de Código da Nota Fiscal - cNF. A SEFAZ recomenta que o cNF seja um numero aleatório, sendo assim muitos atribuem o valor zero a cNF, o ACBr ao detectar que o valor de cNF é zero gera automaticamente um numero aleatório que como dito vai fazer parte da chave. Se no seu arquivo ini referente a nota não contem a linha com o campo cNF ou se o seu valor é zero vai ocorrer o que foi exposto acima. Se ocorrer um erro e o seu cliente enviar novamente a nota usando o mesmo arquivo ini um novo XML será gerado e consequentemente com uma nova chave. Se o erro não ocorreu no envio e sim no retorno a SEFAZ vai rejeitar essa segunda tentativa de envio acusando duplicidade com diferença de chave. Quando ocorre erro a primeira coisa a se fazer não é tentar enviar novamente e sim realizar uma consulta. Se o erro foi no envio a SEFAZ vai retornar uma mensagem informando que a nota não consta na base de dados, ai sim você envia novamente, por outro lado se o erro ocorreu no retorno, a SEFAZ vai retornar o protocolo de autorização e o XML será atualizado ou será retornado a rejeição e o motivo da mesma.

Boa tarde Rodrigo, Eu não tenho nenhum cliente nessa cidade que emite NFS-e, logo se ninguém me avisar que a respectiva cidade mudou de provedor, como é que vou ficar sabendo? Vamos lá, você tem a força, faça a alteração no arquivo Cidades.ini e se necessário no arquivo INI do novo provedor. Faça os testes e estando tudo OK por favor anexe os arquivos alterados para que possamos avaliar e estando tudo certo vamos enviar para o repositório. Desde já agradeço a sua colaboração.

Bom dia Reinando, Você deve ter baixando o XML diretamente do site da SEFAZ, correto? Se sim, esse é o grande problema. Infelizmente não temos como obrigar a SEFAZ fazer o dever de casa.

Bom dia Anderson, A consulta só pode ser realizada depois que você envia o evento de fechamento, note que no XML de consulta (*-ped-sit.xml) devemos informar o numero do protocolo de fechamento.

Bom dia, Até onde sei o Estado do Ceara ainda não disponibilizou as URLs de homologação e produção da NFC-e versão 4.00 E segundo a Nota Técnica 2016/002 versão 1.60 você pode continuar emitindo a NFC-e na versão 3.10 até final de setembro.

Bom dia Mendonça, Fiz uma alteração que acredito que vai resolver o problema. Favor atualizar os fontes e faça novos testes.

Bom dia Mauricio, Desde já muito obrigado pela colaboração, vamos analisar e caso esteja tudo OK vamos enviar para o repositório.

Bom dia Carlos, Favor anexar o XML da nota para que possamos lhe ajudar. Mas acredito que o problema é que você esteja alimentando o campo vBCFPC e ou vBCFCPST.

Luciano, Esse MDF-e foi emitido no ambiente de homologação?

Boa tarde José, Qual é o valor que consta na tag <CRT> dessa nota 1329?

João, O problema ocorre na validação do webservice, pode ser que eles mudaram os schemas de validação e nós ainda temos os antigos.

Boa tarde Luciano, É gerado o XML de pedido de evento? Se sim, favor anexar, bem como o de retorno.

Boa tarde Ivan, Desculpe, mas se você não tiver em mãos a Nota Técnica 2016/002 versão 1.60 só vai ficar chutando a bora para fora do campo. Note que os demais colegas colocaram em suas respostas imagens de páginas do Manual. A versão 6.0 do Manual da NF-e bem como a Nota Técnica que mencionei estão disponíveis no Portal Nacional da NF-e.

Boa tarde João, Note que o RPS foi gerado, o Lote foi gerado, assinado, validado e enviado. A mensagem de erro esta presente no retorno, sendo assim é o validador do Webservice que esta com problemas. Ou esqueceram de incluir o campo Discriminacao ou ele esta com a grafia errada no Webservice. Favor entrar em contato com eles e solicitar a correção.

Boa tarde, Quais são as cidades atendidas por esse provedor? Você tem documentação do mesmo? XMLs exemplos? URLs de homologação e produção? Schemas para validar o lote antes do envio?

Boa tarde Rauber, O programa exemplo esta configurado para usar os schemas da pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\Schemas\Publica ?

Boa tarde Raylan, O componente não gera o XML da NFS-e, apenas o XML do RPS e o envia para o provedor, este por sua vez processa e se tudo estiver OK gera e retorna o XML da NFS-e. É assim que todos os provedores procedem, o EL não faz isso?

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

Boa tarde Rafael, No caso de Concordia/SC basta acrescentar a cidade no arquivo Cidades.ini da mesma forma que as demais. E iniciar os testes usando o programa exemplo. Já esses provedor contratado pela cidade Nonoai/RS favor solicitar um XML de exemplo completo que é enviado contendo o RPS. O arquivo de schema nfse,xsl esta estranho pois contem "3D" em varias definições dos tipos. exemplo: <xsd:simpleType name=3D"tsNumeroNfse"> <xsd:restriction base=3D"xsd:nonNegativeInteger"> <xsd:totalDigits value=3D"15" /> </xsd:restriction> </xsd:simpleType> Nunca vi isso antes.

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

Boa tarde Anderson, Faça um teste usando o programa exemplo, pois acabei de fazer e não ocorreu esse erro.

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

Boa tarde Luciano, Faça um novo teste, colocando todos os parâmetros entre aspas, não apenas a chave e a data.

Boa tarde Fábio, Favor atualizar os fontes e faça novos testes.

Boa tarde Hernandes, Segundo a Nota Técnica 2018/002 isso esta previsto para o modal aéreo e faz referencia ao CT-e e não a NF-e. Portanto acredito que o que você deseja fazer não seja possível, apesar de não ter encontrado nenhuma regra de validação que rejeita um segundo MDF-e fazendo referencia a mesma chave da NF-e informada em outro MDF-e.