Italo Giurizzato Junior

Bom dia Marcelo, Mesmo configurando essas 3 propriedades o erro continua?

Bom dia Diogo, Então podemos incluir o DBSeller na galeria dos provedores funcionando 100% no Trunk2.

Bom dia Fernando, Se a prefeitura diz que os RPS recepcionados ficam na fila aguardando o processamento e o tempo de espera chega a 5 minutos, quem tem que resolver isso é o provedor e não nós.

Bom dia Márcio, Muito obrigado pela colaboração, já esta disponível.

Bom dia icozera, Com UseCertificado = 0 você obteve os erros mencionados. E se colocar UseCertificado = 1 ?

Bom dia Leandro, Pelo que entendi o ConsultarLote ficou resolvido, correto? No ConsultarNFSe mesmo passando os demais dados o XML de consulta não foi gerado com as TAGs opcionais em "branco", correto? E no ConsultarNFSePorRps o problema esta na TAG: Competência. Nesta última consulta o XML do RPS esta sendo carregado para por ser realizado a consulta?

Boa tarde Juliomar, Já inclui as URLs que o Hudson postou e já esta no repositório. Não sei se já foi divulgado as URLs de produção. Hudson, caso você consiga as URLs de produção por favor inclua da mesma forma que incluiu as de homologação e assim que possível for enviar uma nota em ambiente de produção, envie e nos de um retorno anexando o arquivo ACBrNFeServicos.INI por favor. Desta forma poderemos analisar e enviar para o repositório.

Boa tarde Diogo, Maravilha, estamos caminhando, vamos ver se consigamos fechar com chave de ouro. Por favor atualize mais uma vez e realize novos testes.

Marcelo, Você configurou os dados do Emitente? Vide o programa exemplo.

Boa tarde Icozeira, Bom agora o problema é outro? Pois antes se tratava de Requisição não enviada, agora é Identificado não está no estado correto. Nesse novo teste após a atualização dos fontes qual é o valor de SSLLib? Tentou mudar?

Boa tarde Leandro, Qual a mensagem de RPS já cancelado sendo que você acabou de enviar e agora esta apenas consultando, você concorda que isso é um absurdo sendo assim o Web Services do provedor esta com problemas. É preciso entrar em contato com eles e expor o problema. Com relação as outras consultas é interessante que você configure o componente para salvar os arquivos Soap. Configuracoes.WebServices.Salvar := True; Desta forma teremos o retorno sem nenhum tratamento feito pelo componente, desta forma é possível descobrir onde esta o problema. No caso do erro de conversão é importante "debugar" para saber a linha exata que ocorre esse erro, pois datas, dependendo do provedor, podemos ter a data de emissão, data de competência, data de recebimento. Precisamos saber em qual delas o problema esta ocorrendo.

Boa tarde Hudson, Com essas URLs funcionou? A nota foi validada, enviada para SEFAZ e esta retornou que a mesma foi autorizada? Se sim, você essas mesmas URLs para o ambiente de produção?

Boa tarde Marcelo, Vamos então as duas opções: ACBrNFe.NotasFiscais.Items[ x ].NFe.procNFe.cStat ===> desta forma eu tenho a absoluta certeza que o cStat que estou lendo se refere a nota que se encontra na posição X da lita de notas carregadas no componente. ACBrNFe.WebServices.Retorno.NFeRetorno.ProtNFe.Items[ x ].cStat ===> desta forma eu estou lendo o cStat da nota retornada e que se encontra na posição X da lista de retorno. Para quem sempre envia lotes contendo apenas 1 nota pode utilizar qualquer uma das duas formas que não vai ter problemas. Por outro lado para que costuma enviar lote contendo uma ou mais notas (limite máximo de 50) vai ter problemas, principalmente se alguma dessas notas for rejeitada pela SEFAZ. Vamos a um exemplo: Lote de envio com 3 notas: 0 - Nota de numero 1000 1 - Nota de numero 1001 2 - Nota de numero 1002 Vamos supor que a nota de numero 1001 (índice 1 na lista) foi rejeitada pela SEFAZ, no retorno teremos: 0 - Nota de numero 1001 => Rejeitada 1 - Nota de numero 1000 => Autorizada 2 - Nota de numero 1002 => Autorizada Note que a nota que foi rejeitada na lista de retorno ela aparece em primeiro lugar, depois vem as autorizadas. Concluímos que: ACBrNFe.WebServices.Retorno.NFeRetorno.ProtNFe.Items[ x ].cStat ===> para x = 1 estamos pegando o status da nota de numero 1000 e não a de 1001. E ao atualizar o banco de dados você vai acabar marcando a nota de numero 1000 como sendo rejeitada e a de numero 1001 como autorizada, sendo que na verdade é o contrario. Você concorda que a melhor forma de ler o status de uma nota é a primeira opção?

Boa tarde Marcelo, O componente esta configurado para realizar a consulta do lote após o envio?

Bom dia Larry, No caso da NFS-e a validação é sempre por lote, não existe a validação individual do RPS. E a validação é feita de forma automática pelo pelos métodos de envio: Enviar, Gerar e EnviarSincrono. Foi feito desta forma pois temos provedores que não disponibilizaram os seus schemas para realizar a validação.

Bom dia Marcos, O emitente da NFS-e é o próprio prestador, sendo assim você deve configurar os dados do emitente. Vide o programa exemplo.

Bom dia Almeida, Pela mensagem de erro diz que a TAG PedidoConsultaLote não era esperado. Precisamos recorrer ao manual para saber se o nome da TAG esta correto, ou se a posição que a mesma foi incluída no XML esta correto.

Bom dia Marcelo, Favor atualizar todos os fontes de todas as pastas.

Bom dia Diogo, Muito obrigado pela colaboração. Favor atualizar os seus fontes em especial os arquivos INI pois eles estão desatualizados.

Bom dia Marciano, Muito obrigado pela colaboração. Favor atualizar todos os fontes de todas as pastas. Criei o provedor Pronimv2, criei um arquivo INI para o mesmo dentro da pasta: ArqINI. Agora é preciso alterar o arquivo Cidades.INI incluindo ou alterando as cidades que vão passar usar a versão 2 desse provedor. No arquivo Pronim.INI apagar as URLs de produção e homologação das cidades que migraram para versão 2. No arquivo Pronimv2.INI apagar as URLs de produção e homologação e fazer as devidas correções das cidades que migraram para a versão 2, bem como incluir as das cidades novas. Feito esses ajustes começar os testes.

Bom dia Diogo, Favor atualizar os fontes e testar novamente.

Bom dia Eduardo, Esta estranho, pois o método GerarXML esta sim implementado. Como o XML já esta gerado, altere a sua rotina: ACBrNFSe1.NotasFiscais.LoadFromFile(Format('%s\%s',[getpath, qyRps.FieldByName('ARQUIVO').AsString]), False); Isso faz com que o XML não seja gerado novamente.

Bom dia Adilson, Os fontes enviados ontem a noite e hoje de manhã para o repositório tem como objetivo resolver o problema que você estava tendo. Os novos estão diferente dos que enviei pois o Daniel fez uma analise sobre o problema e propôs uma outra alternativa. Por favor atualize os fontes e refaça os testes.

Bom dia a todos, Só tem uma questão nisso, lembrem-se que a chave é composta por um código de 8 dígitos e que a pedido da SEFAZ tem que ser um numero aleatório. Muitos ignoram essa recomendação e acabam colocando o mesmo numero da nota. Se a aplicação do Douglas gera o código conforme a SEFAZ pede, ou seja, um numero aleatório e não armazenou esse numero junto com os demais dados do CT-e, ai pode esquecer. Outra coisa em vez de gerar o CT-e e tentar enviar novamente, vejo que é mais fácil gerar novamente e assinar, depois consultar. Se a chave desse novo XML for exatamente igual ao que foi enviado, ao realizar a consulta a SEFAZ vai retornar o protocolo de autorização e por fim teremos o XML assinado e protocolado. Por outro lado se a chave não for igual a SEFAZ vai retornar que o CT-e não existe na base de dados.

Bom dia Marcelo, Eu prefiro da outra forma.