Italo Giurizzato Junior

Boa tarde Guto, Muito obrigado pela colaboração e informação. Vou passar para o pessoal analisar essa questão da assinatura.

Boa tarde Fabio, Eles quebraram o XSD? Antes era apenas um arquivo nfse.xsd agora é um para cada serviço. Isso faz com que o arquivo INI do provedor seja alterado.

Boa tarde Paulo, Se não me falha a memória ele separa pelo CNPJ do emitente do CT-e .

Bom dia Amarildo, Se no TXT existe a sessão [infRespTec] com os campos preenchidos, como consta no seu, no XML vai ser gerado o grupo. O que pode ter ocorrido é que você utilizou uma versão do monitor que ainda não estava preparado para gerar. Acredito que as ultimas versões vão gerar o grupo, independente da UF.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Douglas, Muito obrigado pelo retorno, vou fazer a alteração aqui e enviar para o repositório. Vou fechar também o tópico, favor criar um novo tópico para novas duvidas.

Boa tarde Douglas, A sua aplicação esta usando o arquivo ISSDSF.ini que se encontra dentro da pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI

Boa tarde Rocha, Como na documentação da ABRASF não consta um modelo de DANFSE acabou sendo adotando um layout utilizado por diversas prefeituras que por sinal não existe impressão de condigo de barras e muito menos QR-Code. Portanto o componente responsável pela impressão do DANFSE hoje disponível não imprime o QR-Code.

Boa tarde Tulio, A aplicação esta usando o arquivo Recife.ini que esta na pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI

Boa tarde Naiara, Experimenta remover do campo Discriminação os caracteres "{" e "}".

Boa tarde Carlos, Vamos pegar como exemplo outra cidade que utiliza o mesmo provedor: [2504009] Nome=Campina Grande UF=PB Provedor=ISSIntel NomeURL_H=campinagrande-pb NomeURL_P=campinagrande-pb Note que é o nome da cidade-uf Então deve ser: NomeURL_H=guanambi-ba NomeURL_P=guanambi-ba Use o programa exemplo para realizar os testes. Fico no aguardo de um retorno.

Boa tarde Francisco, Fico no aguardo do teste de cancelamento para que possamos encerrar esse tópico.

Boa tarde Claudney, Favor não incluir como postagem conteúdo de arquivos, procure sempre anexar os mesmos. O grande problema é que se remover o atributo versão, o webservice entende que o XML esta na versão 1.00 sendo que não esta. E ai como resolver esse problema? Para mim, existe um erro no webservice deles.

Favor atualizar os fontes e façam novos testes.

Bom dia Wagner, Da forma que você implementou esta errada. Se após o envio ocorre o erro de timeout, você não pode deixar o usuário enviar novamente e sim consultar. Porque tem que ser dessa forma, pelo simples fato de você não saber que o erro ocorreu no envio ou no retorno. Ao consultar se retornar o protocolo, fica claro que o erro ocorreu no retorno. Se retornar que o CT-e não consta na base de dados, fica claro que o erro ocorreu no envio, ai sim, você libera para que o usuário possa enviar novamente. Se retornar rejeições, fica claro que o erro ocorreu no retorno, mas o CT-e não foi autorizado, ai sim, você libera para que o usuário possa fazer as devidas correções e enviar novamente.

Bom dia Claudney, Você esta comparando a estrutura do TDadosGNRE com a estrutura do TLote_GNRE, assim não dá. Note que dentro do grupo <guias> temos o grupo <TDadosGNRE>. O TDadosGNRE podemos ver como sendo uma Guia e o TLote_GNRE é o Lote de Guias. Dentro de TLote_GNRE temos o grupo <Guias> e dentro deste podemos ter de 1 até 100 TDadosGNRE.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Fernando, Muito obrigado pela colaboração, assim que possível vou analisar a sua contribuição.

Boa tarde, Se você se refere a cidade Feliz/RS, ela já consta na nossa lista, veja: No arquivo Cidades.ini temos: [4308102] Nome=Feliz UF=RS Provedor=Pronim Isso significa que essa cidade se utiliza do provedor Pronim. Favor usar o programa exemplo do componente para realizar os testes.

Boa tarde a todos, Estão usando o arquivo infisc.ini que se encontra na pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI ?

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

Boa tarde Claudnei, Esse problema esta sendo discutido nesse outro tópico: Vou fechar este para não ficarmos com dois tópicos tratando sobre o mesmo assunto.

Boa tarde Wagner, Se o XML foi gerado, assinado, validado e enviado, me responda qual é a necessidade de gerar novamente o XML caso ocorre algum erro de conexão? Só devemos gerar novamente caso o conhecimento seja rejeitado pela SEFAZ, ai sim, você gera o XML novamente com as devidas correções, caso contrario não. O conhecimento foi enviado, ocorreu erro de timeout por exemplo, qual é o procedimento? 1. Carregar o XML através do LoadFromFile; 2. Executar o método Consultar; Se o conhecimento realmente foi enviado para a SEFAZ e esta processou com sucesso, ao consultar será retornado o protocolo de autorização e o mesmo será incluído no XML, deixando-o completo, ou seja, assinado e protocolado. Agora se ocorreu algum problema, será retornado a rejeição, neste caso conforme já descrito acima, devemos corrigir a informação errada, gerar novamente o XML e enviar. E temos o caso de ao consultar retornar que o conhecimento não existe na base de dados, neste caso, devemos simplesmente enviar novamente.

Boa tarde, Lembre-se que a NFS-e é uma ZORRA com todas as letras, pois tem provedor que é preciso assinar somente o RPS, outros somente o Lote, outros devemos assinar tanto o RPS quanto o Lote e tem aqueles que não precisa assinar nada. Mesmo não precisando assinar nada, temos a questão do acesso ao webservice, com certeza tem provedor que se faz necessário ter o certificado e outros não. Com certeza absoluta é possível emitir NFS-e sem ter certificado digital, desde que seja via SITE e não via webservice.

Bom dia, Muito obrigado pela colaboração. Vou aguardar para enviar a implementação completa.