Painel de líderes

Depois de muita conversa interna e requisição de uma parte dos usuários ACBr, resolvemos estender o suporte ao Delphi 7 até Janeiro de 2017. Por que? Nossa principal motivação foi porque muita gente está pensando que quando chegasse o fim de agosto a compatibilidade com o Delphi 7 será simplesmente removida e seus aplicativos vão parar de funcionar. Infelizmente, algumas pessoas estão usando isso com um oportunismo, fazendo "terrorismo" nos usuários do projeto ACBr. Queremos que entendam que não é fácil manter a compatibilidade do projeto em tantas versões diferentes. E não estamos recebendo muita ajuda nessa área. É difícil manter compatibilidade com versões UNICODE quando nós mesmos não usamos. Mas então em janeiro meu aplicativo Delphi 7 deixará de funcionar com o ACBr? Não!!!! Seu aplicativo vai continuar funcionando. Isso é mentira, falácia, balela, uma grande prosopopéia para acalentar bovinos (conversa pra boi dormir). Então o ACBr não vai mais enviar alterações e correções de acordo com a legislação? Claro que vamos continuar enviando alterações e correções. Então não entendi... Pois é... Isso é o que a gente está tentando esclarecer... Deixa eu tentar... Como é o processo atualmente: Sempre que antes de enviar uma correção, alteração ou inclusão de nova característica, precisamos avaliar se vai funcionar no Delphi 7. Mas a maioria de nós não utiliza mais o Delphi 7. Então depois fazemos a correção, testamos na versão que utilizamos. Daí precisamos, por exemplo disparar uma máquina virtual, esperar ela carregar, copiar o novo código para a VM, fazer os testes no Delphi 7, voltar a máquina normal e só depois enviar ao SVN. Como queremos que seja o processo após janeiro de 2017: Fazemos a correção que precisamos, testamos nas versões que suportamos, e enviamos ao SVN. Mas e o Delphi 7? Os componentes até essa data vão continuar funcionando no seu Delphi 7. Mas a partir dessa data você deverá ter cautela para atualizar via SVN. Eventualmente, sem intenção, uma quebra de compatibilidade pode acontecer. Neste caso você sempre terá a opção de voltar para uma revisão que esteja funcionando. Mas se preferir poderá fazer algo: Corrigir você mesmo o problema; Encontrar algum voluntário para corrigir; Atualizar para uma IDE suportada; Quais as IDE suportadas? Lazarus ou Delphi 2009 ou posterior.

Crie um ProjetcGroup na mesma ordem que é mostrado no ACBrInstall_Trunk, e vai compilando que vc consegue, a limitação somente é por que o Starter não tem o exe para compilação via linha de comando, isso até poderia ser resolvido da mesma forma que o GetIt faz, mas não sei se vale a pena no momento. Mesma coisa ira acontecer com JEDI se usar ele, e todos os pacotes que dependam de compilação via linha de comando. Se compilar tudo pela IDE do Delphi irá conseguir instalar todos.

Valeu Fabiano, vou testar aqui. Vi outra diferença aqui e quero comentar, de repente ajuda mais alguém aí com o Zeoslib na migração. Um dos meus projetos tinha algumas tabelas com campos que o Zeos sugeria como READONLY, creio que pelo fato de serem campos dinâmicos como os campos "tipo" e "serial" abaixo: No Delphi 7 com Zeoslib 6.6.2-RC, sempre atribui valores para esses campos e o ZQuery aceitava de boa, mesmo estando marcados como ReadOnly. Agora no Delphi 2010 com o Zeoslib 7.1.4-stable ele dá erro, dizendo que o campo não pode ser modificado. Na verdade esse erro é o certo, dado o campo ReadOnly como True, mas na versão antiga do Delphi/Zeoslib ele aceitava. Outra diferença que eu vi também foi em uma tabela que eu tenho um campo chamado "to", referente ao estado de Tocantins. Mesmo se tratando de uma palavra reservada na versão antiga do Delphi/Zeoslib ele aceitava, agora dá erro no ZUpdateSQL, tive que mudar para outro nome. A princípio é isso, observando novas necessidades informo aos amigos.

Vagner como solicitado, esta ai o exemplo do acbr boleto compilado. Acrescentei so a escolha do banco nada mais. Do resto é o exemplo do componente ok. Boleto.rar

Correção o laudo vale por 24 meses

Bom dia André, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Olá amigos, Estou focado no provedor de SP. Desculpem o volume das mensagens. Na unit pnfsEnvLoteRpsResposta.pas tem o método LerXml_proSP, que faz a leitura do retorno, na ACBrNFSeWebServices.pas temos o método TNFSeEnviarLoteRPS.TratarResposta, neste método o Result verifica se a propriedade Protocolo esta prenchida, caso contrário o result é False provocando uma exceção. impedindo que o processo da consulta continue. Result := (RetEnvLote.InfRec.Protocolo <> ''); No provedor SP não ha uso de protocolo, neste caso o que temos é sempre uma exceção. Pensando nisso minha sugestão é que no método LerXml_proSP, façamos uma pequena alteração considerando o NumeroLote como protocolo no caso de sucesso FInfRec.FSucesso := Leitor.rCampo(tcStr, 'Sucesso'); if (leitor.rExtrai(3, 'InformacoesLote') <> '') then begin if FInfRec.FSucesso = 'true' then FInfRec.Protocolo:=Leitor.rCampo(tcStr, 'NumeroLote'); Abraços pnfsEnvLoteRpsResposta.pas

Boa tarde Bruno, Foi feita uma alteração para que o componente possa ler o retorno logo após o envio, todos os seus fontes estão atualizados? De uma olha na function: LerXML_proSP que esta na unit pnfsEnvLoteRpsResposta.pas

Apliquei uma possível correção no SVN... Favor atualizar e testar...

Olá Italo, obrigado mais uma vez pela ajuda. Em meus testes ainda com openssl acontece assim na rotina abaixo, sendo que infElement = RPS infNode <> nil { find infElement node } infNode := xmlDocGetRootElement(doc); while (infNode <> nil) and (infNode.name <> InfElement) do infNode := infNode.children; 1º) infNode.name=PedidoEnvioLoteRPS e infNode.children=Cabecalho //próximo nó 2º) infNode.name=Cabecalho e infNode.children=CPFCNPJRemetente //próximo nó 3º) infNode.name=CPFCNPJRemetente e infNode.children=CNPJ //próximo nó 4º) infNode.name=CNPJ e infNode.children=text /// aqui ele para o laço e retorna o infNode como nil provocando a mensagem "Falha ao localizar o nó Raiz" O meu XML contem as seguintes informações neste trecho <?xml version="1.0" encoding="UTF-8"?> <PedidoEnvioLoteRPS xmlns="http://www.prefeitura.sp.gov.br/nfe"> <Cabecalho Versao="1" xmlns=""> <CPFCNPJRemetente> <CNPJ>23183669000161</CNPJ> </CPFCNPJRemetente> <transacao>true</transacao> <dtInicio>2016-06-24</dtInicio> <dtFim>2016-06-24</dtFim> <QtdRPS>1</QtdRPS> <ValorTotalServicos>1685.50</ValorTotalServicos> <ValorTotalDeducoes>0</ValorTotalDeducoes> </Cabecalho> <RPS xmlns=""> <Assinatura>................ Acredito que este seja um ponto inicial para tentarmos solucionar o problema. O teste acima foi feito em ambiente Linux e Windows usando Lazarus com OpenSSL Em relação a CAPICOM somente no Windows A primeira coisa que ocorreu foi que ao apontar para pasta de Schemas "acbr\Exemplos\ACBrDFe\ACBrNFSe\Schemas\" mesmo reconhecendo que a prefeitura era SP, precisei apontar para pasta "acbr\Exemplos\ACBrDFe\ACBrNFSe\Schemas\SP" para que os xsds fossem encontrados. Imaginei que o ACBr faria isso de forma dinâmica. Se o ACBr não fizer e, eu quiser que seja assim, acredito que a codificação abaixo resolva tomando como base o exemplo do pacote. ACBrNFSe1.Configuracoes.Arquivos.PathSchemas := edtSchemas.Text+'/'+ACBrNFSe1.Configuracoes.Geral.xProvedor; Este sintoma não acontece quando usei o OpenSSL. Agora, pra finalizar, com a CAPICOM foi sem surpresas, a nota foi transmitida com sucesso. Deste ponto em diante estou um pouco perdido, não sei que caminho tomar para ajudar numa solução, mas se puder me ajudar com outras dicas, fico a disposição para ajudar a solucionar o problema. Abraços,

veja senão está reclamando a falta do jedi.inc em alguma pasta!

Faça o seguinte: Baixe os 3 repositórios: 1. JCL: https://github.com/project-jedi/jcl/trunk/jcl 2. JVCL: https://github.com/project-jedi/jvcl/trunk/jvcl 3. JEDI: https://github.com/project-jedi/jedi/trunk (este repositório possui arquivos .inc que são necessários para compilar a JCL corretamente) Após baixar copie os arquivo do passo 3 para: <jcl>\source\include\jedi Execute o arquivo "Install.bat" que está na raiz do repositório JCL baixado, tudo normal sem nada diferente, siga o que ele indicar, talvez na aba 64 bits falte o diretóri, mas basta criar ele conforme ele informa. Execute o arquivo "install.bat" que está na raiz do repositório JVCL baixado, também tudo normal conforme indicado pelo instalador. Se seguir este passo-a-passo não tem erro, tudo funcionará normalmente.

esses casos se chama Backup! simples fácil e prático! ou HD Externo, ou e-mail, ou conta no gdrive, onedrive, dropbox!