Astrogildo82

Eu tive um problema parecido na minha aplicação, mas com um ambiente um pouco diferente: Delphi 2010 + Postgresql + Zeos + Windows 7. No meu caso, para aumentar o mistério, o acesso ao banco dos dados estava lento somente quando o ponteiro do mouse estava sobre a aplicação - se eu colocava o mouse na barra de tarefas do windows, a velocidade ficava normal. E isso acontecia indiferentemente com o banco de dados sendo acessado na maquina local ou em um servidor na rede. Como não encontrei nenhum relato de algo parecido nas minhas pesquisas na net, acabei resolvendo o caso usando uma "POG": fiz uma função que desativa o mouse durante os processos que demandam muitos acessos de banco na minha aplicação. Edson, você poderia testar se o teu caso é o mesmo? É só posicionar o mouse na barra de tarefas durante uma dessas lentidões - se for o mesmo problema, a diferença será bem perceptível.

Me expressei mal, não quis me referir a quantidade de elementos do conjunto. Mas o operador "in" não consegue tratar os elementos inteiros maiores que 255, talvez o delphi trate os numeros byte (0..255) como sendo um tipo enumerado que é subconjunto dos inteiros. Vai dar erro se vc tentar compilar esse codigo, porque um dos elementos é maior do que a faixa dos byte: if 1 in [1,301] then showmessage('OK'); Vai dar erro também se tiver um número negativo no conjunto, mas vai dar certo se vc fizer: if 1 in [1,255] then showmessage('OK'); Um modo "gambi" para resolver o problema das NFe confirmadas é: FNotasFiscais.Items[j].Confirmada := (AInfProt.Items[i].cStat in [100,110,205,150]) or (AInfProt.Items[i].cStat = 301) or (AInfProt.Items[i].cStat = 302); Desculpa Darlana, não havia visto a sua resposta ainda, mas é isso ai.

Na verdade isso é uma limitação do operador "IN" - ele que aceita no máximo 255 conjuntos.

Eu nem havia atentado ao fato de que poderia usar esses métodos para alterar os dados da forma que eu preciso. Obrigado!

Obrigado pelo seu empenho em me ajudar, Juliomar, mas falei com o cliente aqui e ele é meio linha-dura com relação em publicar os dados da empresa e da sua movimentação de entradas e saidas (fazer o que.... tenho que resolver de outro jeito então). Mas uma dúvida: nesse seu teste, você gerou os registros C170 para as NFe de emissão própria? Porque como já falei antes, isso não é o normal fazer, somente em um caso de exportação de dados por exemplo e somente ai que vai dar erro de validação.

Sim, foi a primeira coisa que pensei que fosse a causa do validador estar dando a msg de inconsistencia, mas ele dá erro mesmo informando que é COD_SIT = 06.

Bom dia Juliomar, é isso que eu quis dizer: não haverá mesmo necessidade de se gerar o registro C170 para NFe de emissão própria - apenas como no meu caso, se usar o componente para exportar os dados para um outro sistema contábil que usa o padrão do SPED, pois nesse processo há a necessidade de se enviar os dados dos itens da NFe. Como no processo normal de gerar o arquivo final para o SPED os registros C170 não podem ser gerados mesmo, essa minha alteração que eu pedi, não vai gerar nenhum efeito colateral. Estou pedindo apenas uma pequena alteração que vai me permitir fazer uma exportação para um outro sistema como já tem para o Contmatic. Caso voce tenha duvida se criar registros C170 com o campo QTD vazio o deixa fora do padrão, gere um arquivo incluindo os registros C170 das NFe próprias com esse campo preenchido com 0 (padrao atual) e depois com ele vazio (alterando a unit como mostrei acima). Ambos os arquivos irão dar erro na validação de que os registros C170 não deveriam estar lá, mas o arquivo com QTD= 0 irá dar o erro adicional de que ele deveria estar preenchido com valor maior que 0, o que não vai acontecer no outro arquivo, com a QTD vazia.

Boa tarde Juliomar. Você poderia incluir essa também?

Bom dia e Feliz 2014! Segue a unit solicitada com a alteração. ACBrEFDBloco_C_Class.zip

Boa noite a todos. Foi necessário emitir algumas NFs Complementar de ICMS em um cliente, onde ele informou 0 na quantidade dos itens - procedimento normal que deu certo com as NFe validadas e autorizadas como nos demais casos anteriores. O problema é que como se tratava de complemento de NF modelo 1, na hora de gerar o SPED, aparecem os registros C170 dessas NFe Complementares e na validação desse arquivo, dá o erro de que o campo QTD desses registros devem ser maior que 0. Dando uma pesquisada no manual da EFD, descobri que se o campo QTD não estiver preenchido ('||') ao invés de ('|0,00000|') como está hoje, essa validação não ocorre. Eu fiz um teste trocando a linha 1574 do arquivo ACBrEFDBloco_C_Class.pas de LFILL(QTD, 0, 4, False, '0', '#0.00000') + para LFILL(QTD, 0, 4, True, '0', '#0.00000') + O resultado deu certo e poderia ser o suficiente para resolver o meu problema, mas existe uma outra situação onde preciso gerar os registros C170 mesmo os de NFe de emissão própria para exportar para um sistema contábil. Então isso irá acontecer toda vez que for feita uma NFe Complementar nesses outros clientes. Diante disso pergunto se é possível fazer essa alteração conforme acima em definitivo, pois no meu ponto de vista não poderia haver uma situação onde se precise gerar os registros C170 com a QTD zerada, até mesmo pq a validação não permitiria isso.

Olha, não acredito que seja esse o problema, por dois motivos: 1) uso o CCleaner também em várias máquinas de meus clientes e nunca aconteceu isso em nenhum deles; 2) o CCleaner remove chaves do registro do windows e não uma informação dentro do token ou do cartão de certificado. Ele poderia eliminar indevidamente uma chave que tivesse alguma relação com esses dispositivos, mas dai eles apenas não seriam mais reconhecidos pela maquina em questão e funcionariam em outra maquina ou até mesmo na própria máquina apos a reinstalação dos drivers. Me corrijam se minha lógica está errada.

Na verdade ele terá de colocar "acbrnfe.notasfiscais.Clear;" na linha anterior a "with acbrnfe.notasfiscais.add.nfe do begin" ...

Boa tarde a todos. Testei a alteração do Italo em SC (que usa o SVRS) e está OK. Era uma das funcionalidades que eu aguardava ansiosamente por causa da denegação de NFe que estava acontecendo em alguns clientes. Alguém sabe se esse Webservice também tem limite de consumo ou posso sempre consultar o CNPJ do destinatário antes de emitir qualquer NFe?

Oi Kamila, eu testei a importação desse XML e está lendo as informações da tag IPI normalmente, exceto o 1º item pelo fato dele não ter IPI mesmo. Na tua rotina não está trazendo essas informações de nenhum item? Caso não esteja, os fontes estão atualizados conforme essas instruções:

A inicialização da variável na linha 209 é necessária mesmo em outras situações onde essa função é chamada. Eu já havia dado uma solução em que é só adicionar isso daqui antes da linha 225: if (copy(nfe.infNFe.ID, 1, 3) <> 'NFe') then NFe.infNFe.ID := 'NFe'+NFe.infNFe.ID; Experimente fazer isso e teste com o XML que você tem e ai reporte o resultado aqui - eu também tive o mesmo problema e funcionou certinho, bem como com o XML desse tópico do Daniel-FC. Essa alteração acabou caindo no esquecimento.

Bom dia Jorge. Só por curiosidade, você está fazendo essas consultas dentro de um laço de repetição até que o indCont seja igual a 0, usando o ultNSU resultante da consulta anterior? Por exemplo: na primeira consulta, vc usa ultNSU = 0, na segunda 7457866225 (supondo que a resposta acima foi resultado da primeira consulta), na terceira ultNSU = ultNSU resultante da 2ª consulta e assim por diante, até que o indCont seja igual a 0. Pergunto isso porque uso essa lógica desde que o webservice foi liberado pela Receita e, apesar de sofrer os mesmos problemas de desempenho relatados pelos colegas, meus clientes sempre conseguiram obter a lista de NFe destinadas para eles. Claro que no meu caso é via componente, mas acredito que no monitor seja o mesmo processo - peço desculpas se dei um pitaco fora, mas estou tentando ajudar apenas.

Você está preenchendo a tag <indPag> de forma incorreta: 0 – pagamento à vista; 1 – pagamento à prazo; 2 – outros.

Na minha maquina também...

É como o Italo falou: seus fontes não estão atualizados, provavelmente por que vc ainda está baixando do repositório antigo. Veja isso:

Não uso o acbrnfemonitor, mas pelo que a mensagem diz, faltam 2 dígitos no nProt - são 15 dígitos e não 13.

Boa tarde Fabrício, inicialmente quero agradeçer a tua ajuda. Fiz alguns testes aqui com a tua dica e consegui montar o XML da correção que eu precisava, apenas tive que fazer alguns tratamentos da string que recebe o evento, para que ficasse igual ao xml original: Str:= StringReplace(str, '<evento xmlns="http://www.portalfiscal.inf.br/nfe" versao="1.00">', '<evento versao="1.00">', [rfReplaceAll]); Str:= StringReplace(str, '<retEvento versao="1.00" xmlns="http://www.portalfiscal.inf.br/nfe">', '<retEvento versao="1.00">', [rfReplaceAll]); Str:= StringReplace(str, '</SignatureValue>',#13#10'</SignatureValue>', [rfReplaceAll]); Acredito que dessa forma funciona com 1 evento apenas - não testei ainda com uma NFe com mais eventos registrados, mas num primeiro momento resolveu o que eu precisava aqui. Volto a reforçar a sugestão de alguém com mais experiência no componente tentar colocar esse xml dos eventos no retorno da consulta, na propriedade ACBrNFe.WebServices.Consulta.procEventoNFe.itens.RetEventoNFe.retEvento.itens[0].RetInfEvento.XML, da mesma forma que ocorre com ACBrNFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.XML no retorno da homologação do evento propriamente dito.

Eu também me deparei com essa situação agora. Veja bem Régis, não é o retorno do evento que não traz o XML, mas sim o retorno da consulta da NFe que não esta trazendo os XMLs dos eventos. Exemplificando: houve queda de comunicação durante a emissão de uma Carta de correção, sendo que a mesma chegou a ser homologada na Receita mas apenas a máquina do cliente não recebeu o retorno. A solução é consultar a NFe pelo componente, cujo retorno agora traz junto as informações da carta de correção que eu não consegui pegar no momento de sua homologação: nProt, xStat, nSeqEvento, etc. Todos os campos estão preenchidos, menos o NFe.WebServices.Consulta.procEventoNFe.itens.RetEventoNFe.retEvento.itens[0].RetInfEvento.XML. Ressaltando de novo: é o retorno da Consulta da NFe.

Na verdade estava me referindo a tag dentro do XML que vc anexou. Ali está: <emit> <xNome>0510631900010</xNome> No Fonte parece que está certo, só talvez você deva depurar o que está vindo no campo IBT_EmitenteRAZAO_SOCIAL.Value naquela linha que você questionou no post anterior.

Bom dia. Tem um monte de erros na estrutura desse XML, só para citar alguns: Está aparecendo o CNPJ do emitente no lugar do nome; No Destinatário foi colocado SP no campo de INSCRIÇAO NO SUFRAMA; o campo IEST (Inscrição Tributária do Substituto Tributário) esta preenchido com a Inscrição do emitente - Até onde sei, não poderia ser assim, mas confirme isso; O Campo CSON não está preenchido corretamente, (tem que ser csosn101, csosn102, csosn103...); etc Pelo que vi, a maior parte desses erros deve estar no cadastro na sua base de dados. Isso dai eu achei só de olhar por cima do XML, mas o certo é você corrigir esses campos que citei e ai ir eliminando os demais erros procurando no manual de Integração da NFe o que vai em cada campo desses, pois lá tem uma explicação do que deve ser preenchido em cada um deles.

Régys, desculpa a minha chatice mas na revisão 5407 que você subiu ontem, faltou apenas o tratamento do "&" dentro da exportação do XML. Se você quiser fazer isso, um jeito simples seria trocar a linha 500 da ACBrIBPTax.pas por: '<descricao>' + StringReplace(Itens[i].Descricao, '&', '&amp;', [rfReplaceAll]) + '</descricao>' + Verifique que sem isso o XML fica fora do padrão e não é visualizado corretamente.