Astrogildo82

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.

Eu estava fazendo as alterações enquanto o tópico avançou aqui, mas nas minhas alterações eu contemplei a solução desse problema, bem como inclui a exportação do campo também. Para ver que esse registro da problema na hora de carregar os registros para o componente, verifiquem a quantidade de registros que ele carrega e comparem com as linhas abrindo o csv diretamente no excel por exemplo. Régys, dá um merge nesses meus arquivos: Exemplo.zip ACBrIBPTax.pas Exemplo.zip ACBrIBPTax.pas

Boa noite Ageu. Na verdade não é total.vTotTrib, mas sim Total.ICMSTot.vTotTrib.

Se as informações estão muito vagas no fórum é justamente por causa do pessoal estar abrindo tópicos repetidos e fugir do assunto principal do tópico. E a dificuldade de encontrar algo na pesquisa, com certeza é decorrente dessa filosofia de achar que ninguém é obrigado a saber de língua portugueSa.

Bom dia. Baseado no que estamos vendo ultimamente no fórum no que diz respeito ao pessoal não estar pesquisando direito antes de sair postando perguntas repetidas, vou dar uma de "Walter Mercado" e prever um monte de posts por conta dessa alteração, apesar disso estar nos anúncios do fórum. O bom seria se fosse possível emitir alguma mensagem na hora que tentassem atualizar pela URL antiga. Como acredito que isso não seja possível, talvez a melhor alternativa seria nos lembrarmos de mencionar esse tópico aqui nas respostas do tipo "Atualize o componente".

Boa tarde Régis, eu estou meio em dúvida nessa questão que voces abordaram agora de usar o valor da NF ou o dos produtos. A ideia nao seria mostrar quanto que o consumidor paga de impostos naquilo que ele está comprando? Se olharmos assim, teria que ser em relação ao valor que ele está pagando pelo que adquiriu, ou seja, o valor final da NF. Até mesmo porque no Cupom fiscal o calculo do percentual total também é feito com o valor final da compra, não é?

Só para constar: o Peterson já fez a implementação no Fortes, pelo que gostaria de agradece-lo!

Sem problemas! É que a solução que eu fiz parece ser meio tosca, não é? hehehe Mas na verdade o que acontece é que quando se gera uma NFe a primeira vez, o ID já vem Iniciando com as letras "NFe" e depois quando vc carrega um XML, ele vem sem essas 3 letras e nessa situação é gerado uma nova chave. O problema é que a parte da rotina que gera a chave sempre usa o CNPJ da tag <emit>, o que nessas NFe avulsas dá problema pq esses sistemas online da Sefaz geram a chave com o CNPJ da tag <avulsa>. Até citei naquele tópico que uma outra solução seria usar um parametro, mas na minha opiniao, do jeito que fiz é mais simples, pois o usuário do componente não precisa setar o parametro para que a chave seja carregada corretamente. Isto porque na verdade a chave é carregada corretamente do XML, mas no meio da função ela é gerada novamente, e ai, no caso das NFe avulsas com o CNPJ errado. Explicando assim fica um pouco complicado, mas se vc pegar o XML que o Daniel_FC anexou no outro tópico e debugar a importação dele, voce vai entender o que estou querendo dizer. Talvez seja interessante voce trocar uma ideia com o Italo a respeito disso, pois a alteração que ele fez usando o parametro para CTe, poderia ser feita do mesmo jeito.

Sim, isso mesmo - acredito que o Daniel Sonda tenha feito um pouco diferente, mas essa minha alteração já resolveu o problema para mim e para o Daniel_FC também.

Boa tarde Regys. Deve ser a mesma alteração que eu fiz mas que ainda não foi incorporada.

Cara, eu até cheguei a abrir as units do Danfe em Fortes, mas confesso que não me sinto a vontade em mexer neles, pois apenas uso o Fortes no meu sistema por conta do Danfe e de um outro componente, não tendo experiencia suficiente para ajudar nisso dai. Mas eu também ficaria muito grato se o mestre do DanfeRL, o Peterson, pudesse fazer essa implementação. Eu até iria virar corinthiano como ele. rsrsrs Claro que, brincadeiras a parte, está aberto a qualquer um fazer isso.

Na verdade a obrigatoriedade por enquanto é mesmo só para o segmento de combustiveis, para os demais setores é somente se quiserem fazer o Download.

Jorge, nessa NFe ainda não foi feito o que o Régis já falou: a Manifestação do Destinatário. Se voce consultar essa chave em http://www.nfe.fazenda.gov.br/portal/consultaCompleta.aspx?tipoConteudo=XbSeqxE8pl8= vai ver que não consta a manifestação nos eventos, somente a Autorização. Isso inclusive esta claro no motivo da rejeição que vc colocou acima.

Bom dia. Voce chegou a testar qual parte da rotina que está lenta? Experimente carregar esses mesmos 150 xml somente para o componente (comente todo o bloco "For" que está jogando os dados para o cdsXML). Poste aqui quanto tempo levará somente fazendo isso. E a propósito, a sua variável XMLValido sempre estará com o valor true - em nenhum momento ela recebe false. Por isso ele irá dar o LoadfromFile em todos os XMLS, mesmo os inválidos.

Boa tarde, no meu sistema, eu salvo os XMLs das NFe dentro do banco de dados usando o comando: NFe.NotasFiscais.Items[0].SaveToStream(SStream); E pelo que pude notar, esse comando não foi afetado por esse bug. Resultado: apaguei os arquivos xmls incorretos na pasta correspondente no disco e mandei restaurar eles através do que estava no banco de dados e ai só foi necessário reenviar por email para os clientes. Fica a dica para quem tambem grava os XMLs no banco de dados usando o comando acima, devendo cada um fazer essa restauração conforme a sua estrutura e banco usado.

Boa tarde Jorge. Realmente não vejo outra possível causa a não ser alguma falha na Sefaz, pois se o XML que voce mandou do fornecedor, está com a estrutura e principalmente a assinatura válida, então é o que todos falaram até agora aqui: não ha o que ser alterado no ACBR. Acredito que a única solução é voces ai de MG entrarem em contato com a Sefaz e relatarem esse problema, como o João Pedro já fez. Cheguei até a pensar se isso não foi uma "mirabolante" ideia da Sefaz/MG para diminuir os downloads de XML, mas a causa mais provável é que seja apenas um bug no mecanismo de geração/transferencia do XML, pois pelo que vi ate hoje, esse pessoal da Sefaz/MG na verdade é craque em criar bugs ... rsrs Independente disso, não tentem criar soluções que alterem o XML baixado do site para que fique no padrão e assim forçar a importação pelo ACBR, pois como o Kiko e o Markapollo falaram, esses XMLs já não são mais válidos para fins fiscais.

Jorge, tem como voce conseguir um ou ate mesmo os dois XMLs diretamente dos fornecedores desse teu cliente, sem ser via download do site da SEFAZ e disponibilizar aqui para nós também? Não sei se vc está se referindo aos 2 xmls que vc anexou num post anterior, mas caso sejam outros, dai pediria que vc providenciasse os mesmos via download da SEFAZ também, para que possamos comparar os dois tipos para ter uma ideia melhor do que esta acontecendo e assim tentar ajudar a encontrar a solução desse problema.

Bom, eles tambem são voluntarios nesse projeto e todos tem os seus trabalhos - dai pode demorar um pouco, mas uma hora eles fazem isso. Por isso que lhe sugeri para baixar o meu fonte alterado que, apesar de ainda nao avaliado e aprovado por eles, eu sei que funciona pq testei com o teu XML.

O Dangelo2010 apenas precisa de alguns esclarecimentos adicionais: 1) cdsItens é o dataset usado pelo componente apenas para imprimir o danfe, não tendo nenhuma relação com o tamanho obrigatório dos campos do XML (apenas precisa comportá-los); 2) quando vc procurou a linha que voce citou, talvez não tenha visto a definição do campo que tanto lhe preocupa: FieldDefs.Add('DESCRICAO',ftWideString,2000). Isto quer dizer que naquele campo da impressao cabem os 120 caracteres possiveis da descrição do produto no XML (xprod) e mais 1880 para as informações complementares. Diante disso pergunto: voce conseguiu fazer um teste em que esse espaço não é suficiente? Mas tem que ser um teste realista, com informações que alguem realmente possa chegar a precisar colocar nesse campo do danfe e não algo do tipo colocar 2100 caracteres aleatorios.

Bom, eu justamente fiz essa alteração no fonte em anexo no meu post anterior, onde consta que ninguem baixou ele ainda...mas dai pergunto porque voce ainda não baixou ele para sua pasta do ACBR e recompilou o teu projeto? Dai vai estar resolvido o problema. Não precisa esperar algum commiter subir isso pro SVN...

Bom dia, aqui também deu certo agora (delphi 2010). Obrigado Isaque!

Esse problema é por causa de ser uma NFe avulsa emitida usando o sistema da SEFAZ-RS que, nesses casos passa a ser o "Emitente" da NFe, dai porque seu CNPJ está na Chave 1 que o Kiko citou. Essa mudança para o CNPJ do emitente (fornecedor dos produtos/serviços) gerando essa Chave 2, acontece nesse trecho da pcnNFeW (linha 223/224): if (Trim(nfe.infNFe.ID) = '') or (not ValidarChave(nfe.infNFe.ID)) then nfe.infNFe.ID := chave Essa variável "chave" foi montada com o cnpj da tag <emit>, quando nesse caso deveria ser da tag <avulsa>. Um outro problema é essa função ValidarChave que precisa receber o ID começando com as letras "NFe", o que nao acontecia quando o XML é gerado por importação. Optei em adidionar essas letras no nfe.infNFe.ID, mas se voces acharem mais correto, há a possibilidade de se mudar a montagem da variavel "chave" atraves de uma condição para usar o CNPJ da tag <avulsa> quando esta existir. Mas isso é uma questão para os Masters do componente decidirem. rsrs Segue em anexo a unit alterada para avaliação e, em caso de aprovação, posterior subida ao SVN. pcnNFeW.pas pcnNFeW.pas

Boa noite, Acabei de testar e deu o mesmo resultado que o do Juliomar.

Italo, só pra constar: vc entendeu que o meu cliente (o emitente da NFe) que nao tem email, mas na verdade quis dizer que ele que tem alguns clientes (os destinatários) que não possuem email. No caso dos MEUS clientes, eu nem quero saber: se eles nao tem site próprio e nem email, eu mesmo crio uma conta para eles no Gmail e mando as NFe por lá. É lei e fim de papo! hehehe