Astrogildo82

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.

É quase a mesma coisa que eu fiz um pouco acima, apenas com algumas diferenças como sequencia do campo nos arquivos de destino, uso do IFTHEN (numa só linha de comando). O problema é que você fez com base numa revisão anterior - ai já foram feitas alterações depois disso. E outra coisa: eu não testei com a tua unit aqui, mas quando você exporta em XML, você consegue abrir esse arquivo com identação certinha no Internet Explorer? Pergunto isso porque eu observei que você não faz o tratamento do "&", que se estiver no meio do XML, o arquivo não é exibido alinhado. Compara com o meu XML gerado. IBPTaxXML.zip IBPTaxXML.zip

Quanto a mudança de URL do Sourceforge, voce pode ver nesse tópico do link que voce citou, eu postei um comentário lá, dai eu estou ciente disso e já conferi o mesmo. Atualizei mais uma vez agora a pouco e na Revisão 5398 que voce upou no SVN as 10:27:07 não consta nas funções de EXportação o campo descrição, somente na IMportação (carga do componente com os dados do CSV baixado). Faça um merge no meu arquivo por favor e verifique as seguintes procedures: TACBrIBPTax.Exportar TACBrIBPTax.ExportarTXT TACBrIBPTax.ExportarDSV TACBrIBPTax.ExportarXML TACBrIBPTax.ExportarHTML Bem como a function: TACBrIBPTax.Procurar Por favor, não deixe que o stress que eu estou percebendo que vc está sofrendo aqui no fórum nos últimos tempos lhe vença. rsrsrs

Segue a inclusão do campo descrição na função de procura e nas exportações. Exemplo.zip ACBrIBPTax.pas

Régys, boa tarde. Eu dei uma olhada na ultima revisão que você acabou de subir e achei legal o esquema do evento de erro de importação, mas com isso os NCMs que possuem ';' na descrição são simplesmente invalidados por excesso de campos na linha. Você não quer mesclar isso com a alteração que eu tinha feito no meu anexo acima? Pois assim essas linhas são corrigidas e não ficam faltando no resultado da importação do componente. Acredito que não haja ninguém que va vender uma baleia como o primeiro registro refugado, mas poderá haver NCMs realmente importantes que fiquem de fora. Além disso eu também já tinha incluído o campo descrição nas rotinas de exportação.