Nfe Travando Nos Processos Da Sefaz (Gera, Valida Ou Assina) Quando A Muitos Itens.

[Rogério Teixeira_2055]

Estou tentando enviar uma nota com pelo menos 392 Itens e o sistema simplesmente trava em todos os processos da Nota seja ela em Gera, Valida, envia ou Consulta, em modo de debug ele demora muito mais envia, agora quando o programa esta publicado e executado ele simplesmente trava.

Queria saber o que poderia causar isso e se existe alguma solução sobre este caso.

Editado 16 Agosto, 2013 por Rogério Teixeira_2055

[André Ferreira de Moraes]

Vc tem algum XML com essa quantidade de itens para que possamos testar?

[Rogério Teixeira_2055]

Eu não tenho o xml e sim o txt igual ao processo da sefaz, poderia ser este ? se sim, eu posso enviar por email.

[André Ferreira de Moraes]

Pode ser, meu email é [email protected]

[Rogério Teixeira_2055]

ok, André. Estarei enviando hoje mesmo por e-mail e desde já agradeço a atenção prestada.

[André Ferreira de Moraes]

Rogério,

 

Como está o seu código para envio? Vc usa apenas o ACBrNFeMonitor ou o componente?

 

Testei seu arquivo e consegui enviar novamente, as únicas modificações que precisei fazer foi colocar o nome do município para o emitente e destinatário que estavam em branco.

[Rogério Teixeira_2055]

Olha vou testar colocando essas informações que você me passou, e ver o comportamento novamente.

Eu acho que não poderia ser isso que eu vou falar mais a IDE que a gente usa atualmente e o XE para a NFe, será que teria algum problema com essa IDE, estou testando em ambiente de teste em uma VM com o XP, não sei, mais complementando a informação teria algum problema relacionado a isso?

[EMBarbosa]

O componente não tem nenhum problema conhecido com o Delphi XE.

[André Ferreira de Moraes]

Eu fiz os testes usando Delphi 7 e Windows 7 64, tem q ver se fora da máquina virtual vc tbm tem a mesma lentidão.

[Rogério Teixeira_2055]

ok vou fazer este teste, é já te informo, lembrei de mais um lugar para verificar que seria o  OnStatusChange do componente ACBRNFe, por que tratamos alguns processos nesses evento.

[Rogério Teixeira_2055]

Bom Resumindo o problema e assim.

 

Quando o Lote de vários XML´s ou apenas um nos arquivos somando tem o tamanho do XML de Dados superior a 500 Kbytes será  Rejeitado (Código 214), o sistema faz esse tratamento só que não retornava uma mensagem de erro (estou ajustando isso),  pelo que eu vi esse processo de tamanho do XML não é uma verdade por que burlei este conceito de tamanho deixando qualquer lote a enviar e a Sefaz por outro lado aceitou o(s) arquivo(s) que tem 604 Kb Total, só que houve realmente uma demora no processo. Segue o log do nosso sistema aonde no momento de envio e recebimento dessa NFe foi marcado com HH:MM:SS

 

1.) 20/08/2013 As 17:02:35::  **Gerar**

     20/08/2013 As 17:03:06::  Fim  Processo de Gerar

2.) 20/08/2013 As 17:03:06::  **Assinar**

     20/08/2013 As 17:04:26:: Fim  Processo de Assinatura   

3.) 20/08/2013 As 17:04:26::  **Valida**

     20/08/2013 As 17:08:09::  Fim  Processo de Validação

5.) 20/08/2013 As 17:12:21::  **Enviar**

     20/08/2013 As 17:19:18::  Fim do Processo de Enviado

 

Se contar os Min. tenho um Total de 12Min a outras vezes chegamos a 15Min, que eu acho grande. O Total de demora do Nosso sistema nesse envio foi de 17 Min. Chegando a 18 Min. isso por que gravamos o XML no banco de Dados (e esse e um grande, hein) e fazemos uma serie de tratamento do tipo de Arquivo gerado, e com isso fazemos varias validações nossa. Bom eu vou fazer outro teste com arquivo que chega mais ou menos a 500Kb e ver o comportamento do sistema, se você tiver algum Txt que tiver este tamanho poderia me enviar por que estou procurando aqui com outros clientes que passaram por esse problema.

 

Outra coisa o emissor Gratuito da Sefaz enviou este arquivo com no máximo 2 Min Total de envio e recebimento da Sefaz, só que ele também não fez esse tratamento, mais enviou. O que eu coloco a diferença do Nosso sistema com o Emissor Gratuito e que realmente terá um pouco mais de demora nosso por que o Sistema além de grava este XML no Banco ele também tem as nossas validações e manutenção no arquivo.

 

Ok, Logo mais posto o resultado, mais adiantando e isso aí ate o momento.

[Rogério Teixeira_2055]

Outra coisa como eu falei no OnStatusChange tirei todos os processos de la e foi nisso que deu logo acima, ok.

[André Ferreira de Moraes]

Enviando pelo demo ocorre a mesma demora?

[Rogério Teixeira_2055]

Ocorre.

[Kiko Fernandes]

Bom Resumindo o problema e assim.

 

Quando o Lote de vários XML´s ou apenas um nos arquivos somando tem o tamanho do XML de Dados superior a 500 Kbytes será  Rejeitado (Código 214), o sistema faz esse tratamento só que não retornava uma mensagem de erro (estou ajustando isso),  pelo que eu vi esse processo de tamanho do XML não é uma verdade por que burlei este conceito de tamanho deixando qualquer lote a enviar e a Sefaz por outro lado aceitou o(s) arquivo(s) que tem 604 Kb Total,...

 

Rogério bom dia!

 

Meu comentário não tem a ver com a solução do teu problema, mas gostaria de aproveitar a oportunidade para comentar a respeito do tamanho do arquivo até mesmo para que fique registrado aqui como fonte de pesquisa para outras ocasiões.

O correto é sempre respeitar a orientação do manual de integração, mesmo que a SEFAZ aceite não significa que está correto. 

 

Veja o que diz o manual de integração versão 5.00 - (Pág. 27)

A mensagem será descartada se o tamanho exceder o limite previsto (500 KB). A aplicação do contribuinte não poderá permitir a geração de mensagem com tamanho superior a 500 KB. Caso isto ocorra, a conexão poderá ser interrompida sem mensagem de erro se o controle do tamanho da mensagem for implementado por configurações do ambiente de rede da SEFAZ (ex.: controle no firewall). No caso do controle de tamanho ser implementado por aplicativo teremos a devolução da mensagem de erro 214.

As unidades federadas que mantêm o Web Service disponível, mesmo quando o serviço estiver paralisado, deverão implementar as verificações 108 e 109. Estas validações poderão ser dispensadas se o Web Service não ficar disponível quando o serviço estiver paralisado.

 

Veja que no primeiro destaque eles responsabilizam o desenvolvedor:

"A aplicação do contribuinte não poderá permitir"  - (Com isto se vc permitiu é vc que está errado e não eles porque a SEFAZ aceitou)

"Caso isto ocorra, a conexão poderá ser interrompida sem mensagem de erro"  - Veja aqui que a afirmação diz "poderá" e na continuação diz "se o controle for implementado por config. do amb. de rede da SEFAZ". 

E por fim só no caso do controle ter sido implementado é que receberia a rejeição do código 214. 

 

Com isto quero só salientar que não temos uma certeza da rejeição, porém ficou para nós a obrigação: "A aplicação do contribuinte não poderá permitir" e este critério temos que obedecer.

[Rogério Teixeira_2055]

isso o nosso sistema faz, só que o problema e que não estava dando a mensagem para o usuário, aonde estou ajustando isso, o que eu achei estranho e que no emissor gratuito da Sefaz eu consegui enviar este arquivo, é como se o cliente não usa-se de algum sistema de envio e sim o emissor. e ele(cliente) poderia estar enviado arquivos indevido por uma das causas que seria o tamanho do arquivo.

[Rogério Teixeira_2055]

E ai começa aquele caso que o pessoal faz, "Se ele(Emissor Gratuito) faz por que o seu sistema não faz" e ai ate explicar que "A" não e "B", ja levamos muita "porrada".

[Italo Giurizzato Junior]

Boa tarde Rogério,

 

Concordo com você Kiko, é o que seu sempre digo, não basta ler, temos que interpretar o que esta escrito.

 

Interpretação precisa e clara, parabéns.

 

Só ficou faltando dizer que temos dois limitadores, um é a quantidade de notas inseridas no lote ( 50 no máximo ) e a outra já discutida é o tamanho do lote em 500 Kbytes.

 

Eu em particular resolvi limitar mais ainda, baixando para 40 notas no máximo em um lote.

 

Mesmo que o usuário registre 90 vendas e selecione todas para que sejam enviadas, a rotina envia somente as 40 primeiras, obrigando o usuário a disparar um segundo envio e depois um terceiro para completar as 90 notas.

 

Rogério, o que você tem que dizer para essas pessoas é que o seu sistema segue a legislação e as normas estabelecidas nos manuais e notas técnicas.

 

Outra coisa, você disse que a sua aplicação chegou a demorar quase 20 minutos, para enviar um lote, já o programa da SEFAZ foi 10 vezes mais rapido, gastando apenas 2 minutos.

 

Pois bem, você deixou claro que a sua aplicação realiza diversas validações, que por sinal o programa da SEFAZ não realiza, sendo assim quanto mais checagens forem feitas, mais tempo se leva.

 

Você não poderia aplicar essas validações em outros momentos?

 

Por exemplo, em vez de validar o código do municipio no momento do envio, porque não fazer essa validação ao cadastrar o cliente?

 

Será que você não esta validando uma informação que o componente já o faz?

Desta forma a sua aplicação estaria validando a mesma informação duas vezes, e isso demanda tempo.

 

São questões para serem analisadas.

 

Se eu consigo validar todos os dados do cliente no ato do seu cadastramento, não vejo motivo de validar esse dados ao enviar a nota.

 

Desta forma diminuo o tempo entre o clicar no botão Enviar e o DANFE impresso.

 

O que você acha?

[Rogério Teixeira_2055]

Então voltando ao caso as validações do sistema, fugimos um pouco do assunto, e assim o processo e rápido so que acontece que esse arquivo demora mesmo no nosso processo por que ele grande e gravamos isso no banco, são 390 Itens em uma unica NF, o que ocorre e que no momento de envio, nas funções do componente (Gerar, Assinar, Validar, Enviar) somente ai em uma arquivo Txt com esses itens o sistema teve uma demora de 12 a 15 Min. somente nesse processos, que para o cliente demorou muito. entendeu. Usei também o Demo para teste e aconteceu o mesmo problema, 12 a 15 Min.

[Kiko Fernandes]

Eu não uso o componente, apenas o Monitor com isto penso que vc poderia dar uma analisada nas sugestões que o Ítalo apresentou no post #18. 

O que eu poderia fazer é testar no monitor caso vc não tenha ele configurado. Para isto precisaria do XML se possível apenas gerado, sem a assinatura que ai eu faria os testes assinando, validando e enviando. 

[Italo Giurizzato Junior]

Rogério,

 

Uma coisa não ficou clara para mim, você utiliza o componente ou o ACBrNFeMonitor, uma vez que você diz: "somente ai em uma arquivo Txt"

 

Depois você diz que usou o programa Demo?

 

Eu desenvolvo em Delphi, utilizo o componente e não gero nenhum arquivo TXT os unicos arquivos que a minha aplicação gera são os XMLs das NF-e.

[Rogério Teixeira_2055]

Sim claro, estou verificando nesse momento, o que acontece e que geramos o txt igual a sefaz e atraves dele e que mandamos, preciso ver como gerar o xml acho que antes de assinar eu salvo, não e isso.

outra coisa o arquivo diminui e ficou 306 Kb e aconteceu a mesma demora.

Pergunto alguem ja mandou um arquivo com ou mais itens que isso ?

[Italo Giurizzato Junior]

Rogério,

 

Desculpa não entendi:

 

Sim claro, estou verificando nesse momento, o que acontece e que geramos o txt igual a sefaz e atraves dele e que mandamos, preciso ver como gerar o xml acho que antes de assinar eu salvo, não e isso.

 

Se você utiliza o componente, basta alimentar o mesmo com os dados da venda ou seja, que é o emitente, o destinatário, os itens, etc.

 

E ao executar o comando:

 

ACBrNFe.Enviar(nlote); onde nlote é uma variável que contem o numero do lote.

 

O XML é gerado, assinado, validado, enviado, protocolado e o DANFE é impresso.

 

Você gera o txt para que?

Onde ele é utilizado?

[Rogério Teixeira_2055]

então e um processo demorado que para gerar o xml usamos o emissor gratuito e exportamos o xml, isso, para teste do monitor ou ACBR Demo, ok. No nosso sistema utiliza um processo de Txt igual ao do Sefaz, por que no começo a gente usava o software da sefaz, e lemos campo por campo, chave por chave gravando nas tag´s do ACBRNFe. entendeu. Resumindo e assim faz a venda, e gera o txt (igual da Sefaz) outro sistema nosso le esse txt, popula as informações no ACBRNFe ai (Gera, Assina, Valida e Envia) a sefaz retorna a resposta com o XML e gravamos em nosso banco, isso em modo automatico ou manual, acho que resumindo e isso ai.

Editado 21 Agosto, 2013 por Rogério Teixeira_2055

[EMBarbosa]

Retificando: então e um processo demorado que para gerar o xml usamos o emissor gratuito "importando o txt"(nesse caso e "exportamos o xml")

Por favor utilize o botão editar nos seus posts. Ficar fazendo posts um atrás do outro é considerado flooding, e é