Italo Giurizzato Junior

Bom dia Alaran, Já postei por diversas vezes aqui no fórum a respeito dessa rejeição. Primeiramente você precisa garantir que os schemas que estão sendo usados para validar o XML antes do seu envio estão 100% atualizados. Para isso, basta usar os schemas que está disponível na pasta ...\Exemplos\ACBrDFe\Schemas\NFe Desta forma caso o XML seja gerado de forma errado ao validar o erro vai aparecer e o envio será abortado. Por outro lado se o envio ocorreu e a nota foi rejeitada com o motivo: falha no schema XML, isso significa que o problema é na SEFAZ. Ela não esta preparada ainda para receber o XML da nota segundo o layout que ela foi gerada. Ou o pessoal da SEFAZ fizeram alguma kaka e agora esta gerando essa rejeição.

Bom dia Hugo, O grande problema é que essa é a unica chamada ao Web Service que contem uma palavra acentuada: "NÃO". A SEFAZ-RS precisa levar um puxão de orelha e tirar o acento, ai resolve todos os problemas.

Boa noite Marco, O cancelamento é um evento como todos os outros, sendo assim todos eles se utilizam do mesmo schema de validação.

Boa noite Hugo, Você esta com todos os fontes atualizados?

Boa noite Jairo, Pela imagem consta que o lote foi processado com sucesso, sendo assim você deve utilizar o método ConsultarLotarRPS ou ConsultarNFSePorRPS, para obter o XML da NFS-e.

Boa noite Micheli, É necessário configurar o componente no tange as propriedades de quantidade de tentativas e tempo entre uma e outra, E essa configuração varia de um provedor para outro e mesmo sendo o mesmo provedor também pode variar de uma cidade para outra.

Boa noite Cristiane, Muito obrigado pelo retorno, quanto a Novo Hamburgo o arquivo ISSNet.INI esta preparado sim, basta iniciar os testes.

Bom dia, Até o momento o envio Síncrono só é aceito se a nota for modelo 65, ou seja NFC-e e neste caso o lote só pode conter uma nota. Tanto no modelo 55 e 65, caso o lote contenha 2 ou mais notas o envio obrigatoriamente tem que ser assíncrono.

Bom dia, Você não esta gerando o XML através do ACBr? Segundo a versão 6.0 do Manual da NF-e as TAGs do grupo ICMS51 (página 198), com exceção as TAGs: orig e CST as demais são opcionais, ou seja, só são geradas caso o valor seja diferente de zero. O problema é que dependendo da SEFAZ todas as TAGs desse grupo devem aparecer mesmo com o valor zero. Se esse é o seu caso, veja como fazer a alteração, exemplo: Linha 1276: Gerador.wCampo(tcDe2, 'N15', 'vBC ', 01, 15, 0, nfe.Det.Imposto.ICMS.vBC, DSC_VBC); mudar para: Gerador.wCampo(tcDe2, 'N15', 'vBC ', 01, 15, 1, nfe.Det.Imposto.ICMS.vBC, DSC_VBC); O "1" diz a procedure wCampo que a TAG vBC deve ser gerada mesmo que o valor seja zero.

Bom dia Rodrigo, Você esta usando os fontes do repositório Trunk2? Se sim, eles estão atualizados? Se sim, esse erro é impossível, a não ser que depois de gerar o XML você esteja atribuindo uma string vazia a propriedade ID.

Bom dia Micheli, O componente possui uma propriedade de configuração chamada: ConsultaLoteAposEnvio se atribuir o valor True ele realiza a consulta automaticamente.

Boa noite Valter, Com essa alteração, todas as funcionalidades do provedor estão funcionando?

Boa noite, Tem provedores que não estabelece uma conexão caso o CNPJ do certificado não esteja cadastrado no provedor.

Boa noite Micheli, Qual é o provedor?

Boa noite Cristiane, Através do método: function ConsultarLoteRps(ANumLote, AProtocolo: string): Boolean; ACBrNFSe.ConsultarLoteRps(.....); Você terá como retorno o XML da NFS-e. E com isso você vai obter o Codigo de verificação através da linha: ACBrNFSe.NotasFiscais.Items[0].NFSe.CodigoVerificacao

Boa noite Jairo, Abrindo os arquivos que você anexou, mais precismente 1-lista-nfse.xml temos: <Codigo>E86</Codigo> <Mensagem>Número do protocolo de recebimento do lote inexistente na base de dados</Mensagem> No arquivo 1-rec.xml temos o numero do protocolo retornado. Veja o numero do protocolo que você informou ao realizar a consulta no arquivo: 1-con-lot.xml

Boa noite Marcelo, Desculpe, revendo as Units o que você precisa é fazer com que a sua aplicação gere a chave da NFS-e e atribua a propriedade ChaveNFSe, ao alimentar o componente com os dados. Agora você precisa do manual da NFS-e do provedor Infisc para saber exatamente como montar essa chave. Quanto qual método usar, para realizar o envio, o arquivo INI do provedor lhe da uma pista, note que as seções [Gerar] e [RecSincrono] não tem o layout do envelope definido, sendo assim o único método a ser usado pelo provedor é o Enviar.

Boa noite, Mas comparando o DigestValue dos 2 XML que você anexou, eles são iguais e a assinatura me parece também serem iguais. Já o DigestValue que aparece na imagem não tem nada haver com os XML anexados.

Vinicius, Estamos caminhando, mas antes vamos fazer uma pausa para o almoço. Quando eu retornar, vou analisar os aquivos que você anexou. Quero agradece-lo pelos testes e retornos.

Neste caso, o problema pode ser na maquina dele, alteração de horário, fuso horário, antivírus, proxy, ...

Bom dia Lucio, Vamos ao motivo da rejeição (dividi em 3 linhas para ficar mais claro): 1 - Chave de Acesso: 51160205905789000143550010000014671081635252 2 - Codigo Numerico: 108163525 3 - Codigo Numerico na SEFAZ: 102084581 Note que na linha 2 é apresentado o código numérico que coincide com o que esta na chave (linha 1), mas na linha 3 deixa claro que essa mesma nota já foi enviada com um código numérico diferente. Sendo assim o problema não é na SEFAZ. E outra coisa, você ainda esta usando o ACBrNFeMonitor ??? Quando pretende mudar para o ACBrMonitor Plus ??? Quando não conseguir emitir mais nenhuma nota?

Bom dia, Se começou ontem e nada foi alterado na aplicação que o seu cliente usa, você concorda que o problema pode ser na SEFAZ? Já entrou em contato com o pessoal da SEFAZ?

Vinicius, Ainda na seção [Geral] mude o valor de VersaoSoap de 1.2 para 1.1 e realize um novo teste.

Cristiane, Você utiliza o método Enviar, com o componente configurado para consultar o lote após o envio quais são as ações que o componente executa? Vamos lista-las na ordem que são executadas: 1. Consultar a Situação do Lote - Esta consulta pode nos retornar 4 informações diferentes: 1 - Lote não recebido, 2 - Lote em processamento, 3 - Lote processado com erro e 4 - Lote processado com sucesso. 2. Consultar o Lote - Esta consulta só é realizada caso a situação seja 3 ou 4, se for 3 essa consulta nos retorna quais são os erros e se for 4 ela nos retorna o XML da NFS-e. O componente possui várias propriedades de configuração para determinar o tempo que o componente deve aguardar para consultar a situação do lote, a quantidade de tentativas de consulta, o tempo entre uma consulta e outra. A principio o tempo antes de consultar a situação é zero, ou seja assim que é retornado o protocolo acusando que o web service recebeu o lote, o componente já consulta a situação do mesmo. Caso a situação seja 2 - Lote em processamento, o componente aguarda 1 segundo e tenta novamente, podendo repetir esse processo 5 vezes. Com as configurações mencionadas você pode mudar esse comportamento do componente, fazendo com que a quantidade de tentativas sejam 10 por exemplo.

Bom dia Hélio, É muito comum o validador da SEFAZ-RS acusar que a assinatura é inválida. Se a nota foi enviada para a SEFAZ-Autorizadora e esta retornou o protocolo de uso, isso significa que esta tudo OK.