Cezinha Anjos

Olá pessoal! Em primeiro lugar, peço desculpas por reviver um tópico tão velho. Ontem nós tivemos que atualizar o ACBr aqui na empresa e eu acompanhei um pouco do processo. Fazia tempo que eu não acompanhava, pois eu estou num time web já tem muito tempo. O que mais me chamou a atenção é o projeto ainda estar no svn nos dias de hoje. Vocês pensam em fazer essa migração? Existe algo no radar? Minhas impressões de 2012 ainda são válidas para os dias de hoje. Aliás, minhas convicções estão ainda mais fortes que o projeto ACBr só teria a ganhar. Um abraço Obs: antes que alguém me responda que eu posso usar git para acessar o svn: eu já sei. Faço isso desde 2011.

Show Elton... de certa forma é o que fazemos hoje. Nós temos 4 pessoas que normalmente mandam modificações para ACBr. Recentemente, uma delas, vem até comversando bastante com você. Ele se identifica como _asseinfo. É o Marcos. Na parte de CT-e e SPED a gente sempre tem o nosso código considerado. Você e o Isaac sempre nos dão atenção. Nós temos algumas sugestões de modificações para a NF-e e TEF. Uma da NF-e, inclusive, nós já colocamos o patch no forum faz um bom tempo, mas acredito que acabou se perdendo no tempo. Ela diz respeito ao uso do UTC na CC-e. Fizemos até uma implementação bem bacana que detecta o UTC automaticamente de acordo com a UF do emitente. Sugerimos outra evolução neste ponto para que a coisa toda fique ainda menos intrusiva, mas ainda não obtivemos uma resposta. viewtopic.php?f=6&t=4754&p=25749&hilit=utc#p25749 Como você vê nós reportamos e corrigimos o bug em fevereiro. Demos outra sugestão de correção em fevereiro mesmo, mas infelizmente não obtivemos um sinal verde se podemos implementar ou não - ou então se o nosso código será utilizado dessa forma mesmo. Foi só uma colocação a de ter um lugar centralizado para colocar esses patches. Não quero dar uma de metido no projeto. Gostaria apenas de ajudar com essa ideia. Um abraço e conte conosco.

Olá pessoal! Eu gostaria de saber qual é o caminho correto de enviar as contribuições feitas no código-fonte do projeto para que as mesmas sejam analisadas e possivelmente fundidas ao trunk. Aqui na empresa nós temos receio de contribuir com modificações, colocar em um tópico no fórum e o mesmo acabar ficando “esquecido” pelo pessoal do commit por falta de tempo para analisar. Seria muito bacana se o projeto tivesse uma área onde a gente pudesse enviar estas modificações e elas ficassem a disposição dos administradores para aprovação. Esta área poderia pedir, por exemplo, um título, uma descrição do que foi feito e permitir que um patch do SVN fosse enviado. Assim, a medida que sobrasse tempo, os administradores do projeto poderiam correr o olho na lista, selecionar o que for importante (ou conveniente) e possivelmente fundir ao trunk. O outro lado da história é que a pessoa que está contribuindo teria ao menos a tranquilidade de ver que seu trabalho não ficou perdido no tempo – e a todo momento poderia monitorar se o seu “pull request” foi aceito. Os que estão me lendo e que conhecem o github.com sabem bem do que eu estou falando. Um projeto hospedado lá possui um série de coisas bacanas como: • Poder visualizar o fonte direto no browser • Poder reportar os erros através de “issues” • Poder sugerir correções através de “pull request” • Wiki, gist (trechos de código), forks. O Github possuí mais uma cacetada de coisas bacanas que nem convém ficar falando aqui, pois creio que nem se cogita a hipótese de trocar o repo atual do projeto, mas acho que ao menos esse sistema de envio modificações seria muito bacana. Na minha opinião, eu acho que este tipo de coisa estimularia mais a contribuição, traria um processo formal para as modificações e tiraria uma carga do pessoal do commit de ficar vasculhando o fórum todo a procura de uma contribuição para fundir. Sem contar que seria possível medir qual é o tamanho da contribuição que a comunidade dá ao projeto. O que vocês acham?

Olá André! Podemos fazer a implementação proposta acima? Ou você gostaria de algo diferente? Nós podemos implementar... basta nos dar um toque que a gente implementa. Aguardo seu retorno para colocar a mão na massa.

Olá André... tive uma ideia: Se você quiser nós podemos criar duas propriedades: UTC: string -> o usuário informaria o UTC desejado. AutoDetectarUTC: Boolean -> o UTC seria detectado automaticamente. Se você der carta branca nós podemos fazer isso e mandar o fonte pra você. Só não vale commitar isso depois de outubro... hehehe. Aguardo suas considerações.

Olá André... continuando... não sei se essa info te ajuda: Aquele fonte do Alan faz o seguinte: de acordo com a UF ele já define o UTC. As as UFs regidas pelo horário de verão ele ajusta isso automaticamente no início e no fim do mesmo utilizando a regra do governo. Creio que a solução dele torna desnecessário tal propriedade. Espero que ajude.

Olá André... A gente criou uma fórmula... baseado na regra do governo... para calcular o horário de verão. Não sei se ajuda... mas já tá naquele fonte. Muito obrigado.

Olá Daniel! Fiquei muito feliz em saber que você leu o tópico. Nós entendemos muito bem o que é trabalhar em um projeto open source. Tanto é que nós não ficamos cobrando de ninguém soluções. Nós vimos os problemas, corrigimos e enviamos o código já pronto. Nós participamos também de outras iniciativas abertas. Eu sei que você não podem integrar tudo o que todo mundo manda. Senão a coisa toda acaba virando o “samba do crioulo doido”. O problema é que as coisas demoram muito no ACBr em geral. Se você quiser nossa equipe está a disposição para ser um dos revisores de código. Somos em seis desenvolvedores e eu posso designar alguém para ajudar. Ficaríamos gratos e até mesmo honrados em ajudar na iniciativa. Existem uma série de refatorações que nós já pensamos em propor, mas no fim das contas a gente acaba desistindo, pois não sabemos se o que iremos produzir alguém irá se interessar e fazer o merge. Nós já pensamos em até construir testes unitários para determinadas áreas, mas até onde isso seria trabalho jugado fora? Não sei se existe uma forma mais eficiente de resolver o problema. Se necessário for nós até podemos pagar o ACBrSAC para estes casos. A gente só precisa que alguém valide o nosso fonte e faça o merge. Eu acho que as pessoas não estão reclamando porque elas acabaram dando um “jeitinho” de resolver o problema por fora. Só pra você ter uma ideia, até este momento os arquivos foram baixados em torno de 18 vezes. Alguém com certeza também está usando a solução. Daniel: eu não quero que você me leve a mau e nem fique ofendido com minhas palavras. Só gostaria que você também desse uma olhadinha no problema com nossos olhos. A gente envia a sugestão e tem a sensação de ser sumariamente ignorado. Isso é ruim. Eu não quero ficar enchendo o seu saco com DMs ou coisa desse tipo. Acho que você delegou para os caras te ajudarem. Se o protocolo de solicitação for o descrito pelo markapollo... tudo bem... a gente posta a solução e depois fica mandando DM para o pessoal. Mas eu acho que isso não é certo. Bom... é isso aí... mais uma vez te peço desculpas, mas eu acho que não é certo eu deixar de expor minha opinião só porque corro o risco de ser cortado do fórum ou algo desse tipo. O projeto é muito bom – sou grato por não ter que gastar um real pra ter tudo isso... só que eu também gostaria de ajudar a evoluí-lo de alguma forma... e acho que negligenciar os problemas, ficar achar workarounds e não repassar isso pra comunidade seria uma visão muito egoísta da minha parte. Obs: acho que agora mesmo é que não teremos mais esta integração... hehehe

Puxa vida... agora que o horário de verão acabou... será que o pessoal irá integrar este código somente no verão que vem?

Olá?! Será que o pessoal já fez o merge da solução? Me parece que o fonte tá todo pronto... basta fundir. Muito obrigado

Olá?! Alguém sabe dizer se isso já foi feito o merge com o SNV? Já dá pra baixar? Muito obrigado

De fato... havia um erro no meu fonte: NFes.NotasFiscais.Items[0].NFe.Det.Items[indexItensDaNf].Imposto.IPI.cEnq := '999'; Isso estava fora do "if" Mais uma vez.. obrigado pela resposta.

Olá?! Vou revisar meu fonte então, pois parece que está correto. Muito obrigado pela agilidade na resposta.

Olá?! Eu acabei desistindo. Continuei assinando utilizando a DLL da Bematech. Um grande abraço.

Olá pessoal! Eu gostaria de saber como fazer para não gerar a tag de IPI no XML da NF-e. Atualmente eu consigo fazer isso com o II, mas com o IPI não. Lembrando que para os optantes pelo Simples Nacional tal tag não é obrigatória (não sei ao certo se ela nem deveria ser gerada). A nota técnica 2009.004, na qual instrui como preencher o XML para os optantes pelo Simples Nacional, não menciona nada sobre o IPI. Não encontrei também nenhuma nota técnica nova falando sobre o tal. O manual de integração também aponta tal tag como opcional (Página 107 no diagrama. Página 142 no campo 246 "Informar apenas quando o item for sujeito ao IPI"). Lembrando que o IPI não se aplica em optantes pelo Simples Nacional. Agradeço se alguém puder ajudar. Quero evitar motivos para ganhar uma multa acessória por informar algo indevido.

Infelizmente o problema é outro meu amigo. No meu aplicativo está tudo configurado e mesmo assim está dando pau. Não consegui fazer funcionar. Parece que ele falha ao tentar carregar a função PEM_read_bio_PrivateKey da DLL

Olá pessoal! Estou tentando utilizar o método AssinarArquivoComEAD do ACBrEAD, mas estou recebendo a exception "Erro ao ler a Chave". Os eventos OnGetChavePrivada e OnGetChavePublica estão devidamente configurados. Porém, o erro só acontece caso eu informe a chave privada no evento OnGetChavePrivada. Se este evento não for informado o componente não gera o erro. Segue abaixo o local onde gera o erro: procedure TACBrEAD.LerChave(Chave : AnsiString; Privada: Boolean) ; var A : pEVP_PKEY ; BioKey : pBIO ; begin InitOpenSSL ; if (sLineBreak <> #10) then Chave := StringReplace(Chave, sLineBreak, #10, [rfReplaceAll] ); LiberarChave ; BioKey := BIO_new_mem_buf( PChar(Chave), Length(Chave) + 1 ) ; try A := nil ; if Privada then fsKey := PEM_read_bio_PrivateKey( BioKey, {$IFDEF USE_libeay32}A{$ELSE}nil{$ENDIF}, nil, nil) else fsKey := PEM_read_bio_PUBKEY( BioKey, A, nil, nil) ; finally LiberarBIO( BioKey ); end ; if fsKey = nil then raise Exception.Create('Erro ao ler a Chave'); end ; Ao carregar a chave privada fsKey fica "nil" e acaba lançando a exception. Eu compilei o Demo e está com o mesmo pau do meu aplicativo. Uso Delphi XE. Alguém tem ideia do que está acontecendo?

Olá?! Desculpe... na realidade eu havia passado o número da linha do //NFeRetorno.Free;. Eu deveria ter passado o número da linha do que estava dentro do finally. No arquivo que eu enviei para o merge eu havia descomentado a segunda linha A versão que eu tenho aqui os dois //NFeRetorno.Free; estavam comentados. Talvez alguém já tenha encontrado o problema antes da gente. Obrigado pela ajuda e reafirmo que estamos a disposição caso necessitem alguma implementação.

Olá Sr. André! Tudo bem? Espero que sim... Conseguiu dar uma olhadinha no problema relatado? Eu vi que tem um outro tópico aberto do ACBrNFeMonitor no qual o mesmo gera um Access Violation em uma condição específica. Não sei se os problemas são correlacionados, mas me parecem estar. Há algo mais que você precise que eu possa fazer para aplicar a correção? Muito obrigado

Olá Elton! Fiz os seguintes testes: 1. Tentei cadastrar no PVA um fone com menos de 10 caracteres. Ele não permitiu. Parece que fones diferentes de 10 dígitos ele considera inválido. 2. Peguei um arquivo válido, mudei o fone dele na mão para ter menos de dez dígitos e tentei importar o PVA. A importação não passa. Diz que o fone é inválido. 3. Criei no PVA um registro com o fone em branco. Ele exporta em branco. 4. Criei no PVA um registro com fone somente com zeros. Ele exporta como zeros. Minha conclusão: Acho que o ACBr poderia tratar este campo como um texto (assim como está descrito no manual da EFD). Assim passamos a responsabilidade para o aplicativo usuário validar ou não o fone. Aguardo considerações e agradeço a atenção.

Olá?! Em primeiro lugar em agradeço por ter dado atenção ao meu post. Vamos lá as minhas considerações: Problema 1: O objeto abaixo é um descendente de TComponent. Para ele ser destruído automaticamente ele teria que ter um owner. Este owner é passado no construtor. Atualmente está sendo passado como nil. Por favor, veja abaixo a implementação da linha 1674 1674: ReqResp := THTTPReqResp.Create(nil); Particularmente, em ocasiões onde o objeto é usado somente em um método específico (como é o caso do método TNFeConsulta.Executar) eu prefiro criar sem o owner e eu mesmo controlar o ciclo de vida do objeto. Desta maneira eu consigo deixar o meu código mais legível, pois sei que o escopo daquele objeto é local. Vamos supor ainda que eu decida fazer algo como abaixo: 1674: ReqResp := THTTPReqResp.Create(self); Neste caso eu estaria atrelando a vida do meu objeto ao tempo de vida da instância de TNFeConsulta (não estou entrando aqui em detalhes do tipo... TNFeConsulta também deveria ser do tipo TComponent para permitir esse tipo de coisa). Se eu chamasse o método TNFeConsulta.Executar três vezes, por exemplo, eu teria três novos objetos desnecessários na memória até TNFeConsulta ser destruído. Eu poderia ainda sugerir uma refatoração maior, no qual evitaria esse tipo de coisa, mas por momento optei por sugerir apenas os .free pois imaginei que a aceitação seria mais fácil. Não quero e nem tenho direito em desmerecer o trabalho que foi feito até aqui. Pelo contrário, sou muito grato por poder usar uma suite de componentes tão boa e de graça. Por isso não fique brabo comigo Problema 2: Posso estar enganado, mas eu não vi nenhum ponto de saída do método que transporta para fora dele a referência do objeto NFeRetorno. Eu percebi que ele é usado apenas localmente. Se houvesse a necessidade de algum agente externo utilizar a referência de NFeRetorno eu sugeriria fazer uma inversão de controle para que o "utilizador" ficasse com a responsabilidade de criar e destruir o NFeRetorno. Mas honestamente eu não consegui encontrar isso no código. Portanto, acredito ser seguro aplicar o .free nele. As fugas que eu apontei foram detectadas utilizando o FastMM. Eu rodei diversas vezes nossos códigos e fui isolando cada uma. O FastMM não faz nada automático, mas ajuda bastante. Foi uma tarde dura de trabalho... hehehe. Eu não sei se consegui ser claro em minhas explicações, mas me coloco a disposição para detalhar ainda mais se for necessário. De ante-mão eu gostaria de parabenizar pelo projeto. Gostaria de poder contribuir com trabalho para o mesmo. Se precisarem fazer alguma refatoração eu me disponho. Conheço e aplico um pouquinho de orientação a objetos e padrões de projetos. Contem comigo se eu puder ser útil. Aguardo ansiosamente o retorno.

Olá Elton! Eu farei um experimento no PVA e depois coloco o resultado aqui. Acho que ele é a nossa melhor fonte de pesquisa. Muito obrigado

Olá pessoal! Eu encotrei uma fuga de memória na unit ACBrNFeWebServices. A mesma acontece aproximadamente na linha 1129, onde o objeto ReqResp nunca é liberado quando usa-se capicom. A correção seria: {$IFDEF ACBrNFeOpenSSL} HTTP.Free; {$ELSE} ReqResp.Free; {$ENDIF} Segue em anexo a unit corrigida caso achem interessante fazer o merge. Me parece que o método "Executar" é bastante utilizado. Agradeço se alguém puder checar. Muito obrigado e peço desculpas por algum transtorno. ================================== Olá pessoal! Eu encontrei diversas outras fugas em ACBrNFeWebServices.pas. Segue neste post a unit corrigida. O problema é basicamente o mesmo citado no post anterior. ACBrNFeWebServices.pas Peço atenção nas linhas (do arquivo original) 1703 e 1816. O 1703: NFeRetorno := TRetConsSitNFe.Create; 1816: //NFeRetorno.Free; Passei a linha para antes do try e descomentei a linha 1816. Acho que alguém já havia comentado por ter passado por algum problema. Acredito que a mudança de posição da linha 1703 deve resolver o problema. Agradeço se minhas considerações forem consideradas relevantes, pois acredito que estas fugas podem degradar o aplicativo. Muito obrigado

Olá Elton! Na realidade o problema está no fato do ACBrEFD estar preenchendo com zeros. Como você citou, no manual descreve um campo do tipo "C" com 10. Se você fizer um exemplo no PVA e exportá-lo para TXT você verá que o PVA não completa com zeros tal campo. Gostaria de salientar que o campo que você descreveu eu não olhei. Os testes que eu fiz foram com os campos Fone e Fax. Mas pela sua lógica faz todo o sentido Fone e Fax não serem preenchidos com zeros, pois o campo "Num" que você descreveu é do tipo "C" e o ACBrEFD não o exporta preenchido por zero (veja a comparação das linhas 393 e 396 na unit em questão). 389: Add( LFill('0005') + 390: LFill(FANTASIA) + 391: LFill(CEP, 8) + 392: LFill(ENDERECO) + 393: LFill(NUM) + 394: LFill(COMPL) + 395: LFill(BAIRRO) + 396: LFill(FONE, 10) + 397: LFill(FAX, 10) + 398: LFill(EMAIL) ) ; Obrigado por responder e continuo na torcida pelo merge. Um grande abraço.

Olá pessoal! Eu gerei um arquivo no PVA, fiz uma comparação com o ACBrEFD e encontrei uma pequena divergência no bloco 0. É que o fone e o fax o PVA trata como uma string e o ACBrEFD está tratando como um número. Desta forma o ACBrEFD está preenchendo com zeros. A mudança é bem simples. Basta tirar o parâmetro 10 de LFill (por exemplo LFill(FONE, 10)). Mudei em apenas 4 lugares. Tomei a liberdade de fazer a modificação e estou enviando o arquivo em anexo. Agradeço se alguém com autonomia para tal puder avaliar as mudanças e fazer um merge no SVN. ACBrEFDBloco_0_Class.pas