NFSe trunk2 thema.ini

[Cristiane - Afirmação]

Vou fazer os testes! Obrigada.

[Cristiane - Afirmação]

Italo,

Fiquei a tarde toda fazendo testes, os mais variados, com várias combinações.

Se eu marcar

  ACBrNFSe.Configuracoes.Geral.ConsultaLoteAposEnvio := True;

Mesmo eu alterando

  ACBrNFSe.Configuracoes.WebServices.AguardarConsultaRet := 5;
  ACBrNFSe.Configuracoes.WebServices.AjustaAguardaConsultaRet := True;
  ACBrNFSe.Configuracoes.WebServices.Tentativas := 300;

(estes números foram alterados para mais e para menos)

Parece que não faz diferença alguma. Volta imediatamente com lote não processado como excessão, não gera o RPS nem nada.

Se eu consultar o protocolo depois com

ACBRNFSe.ConsultarSituacao( Protocolo );

Só vem a Situacao, beleza, demora até 5 minutos para eu obter o retorno.

Até aí OK, mas como eu pegaria o XML definitivo e o código de validação que antes estava em

ACBrNFSe.NotasFiscais.Items[0].NFSe.CodigoVerificacao

Eu tenho emissão em lote, que antes eu fazia, pegando o retorno imediatamente, agora não consigo mais.
Já estou sem saber o que fazer...

[Italo Giurizzato Junior]

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

[Cristiane - Afirmação]

Bom dia, Italo!

Acrescentei a linha 

ACBrNFSe.Configuracoes.WebServices.IntervaloTentativas := 30000; // 30 segundos

Aí começou realmente a esperar o tempo e veio o retorno corretamente!
Se baixar para 10000 já não vem (tempo da prefeitura).

Ainda assim vou implementar o retorno, se tudo der errado, pelo consulta manual, conforme orientação que você me passou.

Foi de grande valor a sua ajuda! Muito obrigada...

[Cristiane - Afirmação]

Tudo funcionando com a Thema. Testes feitos para a prefeitura de Passo Fundo / RS.

Alguém já tem o ISSNET.ini configurado para a prefeitura de Novo Hamburgo?

[Italo Giurizzato Junior]

Boa noite Cristiane,

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

[Cristiane - Afirmação]

Atualizei o Cidades.ini e o ISSNet.ini e agora está tudo 100% com Novo Hamburgo. Em produção, já!

Agora vamos para Ibirubá/RS, com Digifred...

[WINDEL]

Bom dia,

Pra mim está demorando em torno de 5 minutos para retornar true na FConsSitLoteRPS após o envio, para vocês também demora tanto tempo assim? 

É que com apenas os 30 segundos retorna false, dai coloquei um loop e fica no loop até retornar true, mas demora 5 minutos pelo menos.

Alguma ideia de solução? estou usando a função Enviar.

Editado 23 Fevereiro, 2016 por DIOGOWAR

[WINDEL]

Deve ser algo no componente ou na minha configuração, pois com o Trunk "anterior" a nota era aprovada muito rápido =(

 

[Italo Giurizzato Junior]

Bom dia Diogo,

Acredito ser na sua aplicação ou na configuração do componente ou até mesmo no provedor, pois em meus testes com o provedor Ginfes, após o envio do RPS tenho o XML da NFS-e salva em disco em menos de 15 segundos.

[WINDEL]

Está me retornando:

---------------------------
Erro
---------------------------
Erro ao enviar Esse RPS foi enviado para a nossa base de dados, mas ainda não foi processado
Salvo arquivo \\pendencia\Bancos\NFSe\Lajeado\Pend 16442\xml\1344_erro.xml
---------------------------
OK   
---------------------------

 

Vou tentar mexer em algumas propriedades para ver se descubro o problema. =(
 

Editado 23 Fevereiro, 2016 por DIOGOWAR

[Italo Giurizzato Junior]

Diogo,

Essa mensagem é um retorno do provedor?

Se sim a mensagem esta clara eles recebem o RPS mas ainda ele não foi processado.

Isso pode ser um problema temporário do provedor ou significa que agora mais empresas estão utilizando o Web Services para emitir as notas e o mesmo não esta conseguindo dar conta de tantas solicitações.

[WINDEL]

Sim, é uma mensagem do provedor, mas aí se eu coloco um loop, e fico consultando a cada x tempo, vai demorar uns 4 a 5 minutos e vai aprova a nota.

Mas tem algo estranho aí, por que olha o teste que eu fiz...

Usando o trunk "normal" enviei o RPS e logo em seguida foi no portal do provedor consultar e o RPS já tinha sido convertido em nota, não demorou nem 15 segundos.

E usando o trunk 2 enviei o RPS e logo em seguida foi no portal do provedor consultar e o RPS NÃO tinha sido convertido em nota, fiquei clicando em pesquisar pra atualizar a pagina a cada pouco, e demorou 4 minutos para ser transformado em nota.

Alguma ideia ? =(

 

 

 

 

[Tailon Edson]

8 minutos atrás, DIOGOWAR disse:

Sim, é uma mensagem do provedor, mas aí se eu coloco um loop, e fico consultando a cada x tempo, vai demorar uns 4 a 5 minutos e vai aprova a nota.

Mas tem algo estranho aí, por que olha o teste que eu fiz...

Usando o trunk "normal" enviei o RPS e logo em seguida foi no portal do provedor consultar e o RPS já tinha sido convertido em nota, não demorou nem 15 segundos.

E usando o trunk 2 enviei o RPS e logo em seguida foi no portal do provedor consultar e o RPS NÃO tinha sido convertido em nota, fiquei clicando em pesquisar pra atualizar a pagina a cada pouco, e demorou 4 minutos para ser transformado em nota.

Alguma ideia ? =(

 

 

 

 

Tenho exatamente o mesmo problema, mas com o provedor thema, se utilizo o trunk a nota processa rapidinho, mas com os fontes do trunk2  leva de 4-6 minutos por nota.

Editado 23 Fevereiro, 2016 por Tailon Edson

[Cristiane - Afirmação]

Eu também estou notando esta demora, tanto com Thema quanto com ISSNET. Quando utilizava o Trunk, era tápido, com o Trunk2 ficou mais lento.

Em relação a Ibirubá/RS, com Digifred, o Digifred.ini ainda não está com a configuração completa, né?

Quando envio uma nota, retorna:

"Arquivo em desacordo com o XML Schema.

Envie um arquivo dentro do Schema do arquivo XML de entrada. O arquivo deve estar em uma das versões de XML Schema especificadas para o serviço."

[Italo Giurizzato Junior]

Boa tarde a todos,

O componente ACBrNFSe não interfere na velocidade que o provedor processa as notas recebidas, só faltava essa, tenha paciência.

O componente apenas estabelece uma conexão com o provedor para enviar e obter o retorno.

Como já disse mil vezes, quem fez a migração do componente ACBrNFSe para o Trunk2 foi eu.

Consegui com um colega do fórum um certificado de uma empresa cuja cidade é atendida pelo provedor Ginfes.

Testei todos os métodos, sempre usando o programa exemplo.

Nunca entrei no site do provedor para saber se nota tinha sido processada ou não.

Com o componente configurado para Consultar o lote após o envio e usando o método Enviar e menos de 15 segundos o XML da NFS-e estava salvo no disco.

Já disse também que o tempo pode variar de provedor para provedor e mesmo sendo o mesmo provedor pode variar de cidade para cidade.

Não é o caso do Ginfes, mas existem provedores que alem do método Enviar disponibiliza o método Gerar.

O Gerar é mais rápido, primeiro por aceitar somente um RPS, segundo que o retorno do envio através desse método já é o XML da NFS-e ou a lista de erros.

Já o método Enviar nos retorna apenas o protocolo que acusa o recebimento do lote pelo provedor.

Em seguida se faz necessário consultar a situação desse lote, essa consulta o provedor simplesmente nos retorna a situação informado uma das 4 situações: Lote não recebido, Lote em processamento, Lote Processado com erro, Lote Processado com Sucesso.

A rotina que realiza essa consulta é capaz de repetir a consulta por varias vezes enquanto a resposta for Lote em processamento.

O componente dispões de 3 propriedades para configurar essa consulta, podemos definir o tempo que ele vai esperar para realizar a primeira consulta, o tempo entre uma consulta e outra e numero de tentativas.

Se o retorno for Lote processado com erro ou com sucesso o próximo passo é consultar do lote, teremos como resposta a lista de erros caso tenha sido processado com erro, ou o XML das notas caso tenha sido processado com sucesso.

Repito mais uma vez quando configuramos o componente para consultar o lote apos o envio, se utilizarmos o método Enviar essas duas consultas são executadas automaticamente e na sequencia correta.

[Cristiane - Afirmação]

E em relação a Ibirubá/RS, com Digifred, o Digifred.ini ainda não está com a configuração completa, né?

Quando envio uma nota, retorna:

"Arquivo em desacordo com o XML Schema.

Envie um arquivo dentro do Schema do arquivo XML de entrada. O arquivo deve estar em uma das versões de XML Schema especificadas para o serviço."

 

[Italo Giurizzato Junior]

Boa tarde Cristiane,

Configure o componente para salvar os arquivos soap.

Anexe o arquivo de envio para que possamos analisar.

[Cristiane - Afirmação]

Segue o arquivo gerado para Digifred de Ibirubá/RS.

O componente foi alimentado com a Razão Social da empresa emitente, mas não aparece.

O retorno diz que está fora do layout.

1-env-lot.xml

1-rec.xml

[Italo Giurizzato Junior]

Bom dia Cristiane,

Será que o problema não seja esse?

<Competencia>sabado12</Competencia>

 

Na TAG Competencia normalmente informamos uma data e não um texto.

[Cristiane - Afirmação]

Pois é... Deveria estar formatando YYYYMM, mas deve ser uma data ('dd/mm/yyyy')?

[Cristiane - Afirmação]

Tentei com data ou com ano/mês, mas sempre retorna o mesmo erro.

1-env-lot_comanomes.xml

1-env-lot_comdata.xml

1-rec.xml

[Italo Giurizzato Junior]

Boa tarde Cristiane,

Informe a competência da seguinte forma:

2016-02 ou 2016-02-24

[Cristiane - Afirmação]

Mesmo assim, apresenta a mesma mensagem...

1-env-lot.xml

[Italo Giurizzato Junior]

Cristiane,

No meu controle tenho que o provedor Digifred foi testado e esta funcionando todas as suas funcionalidades.

Sendo assim, favor enviar esse XML ao provedor para que ele possa mostrar exatamente onde esta o erro.