Painel de líderes

Porque a minha aplicação, quando compilada no Trunk2 exige as DLLs do XMLSec ? O Trunk2, tem a habilidade de suportar OpenSSL (XMLSec) e CAPICOM, na mesma aplicação... e no ACBrNFe, existe a Classe TDFeSSL, que permite configurar qual será a biblioteca de SSL em Design ou Run-time Para isso, basta mudar a configuração usando comandos como abaixo: ACBrNFe1.Configuracoes.Geral.SSLLib := libOpenSSL; ACBrNFe1.Configuracoes.Geral.SSLLib := libCapicom; ACBrNFe1.Configuracoes.Geral.SSLLib := libCapicomDelphiSoap; // Mesmo que "libCapicom", mas usando a Indy Porém, para efetuar essa "magica", precisamos compilar todas as Units que dão suporte a CAPICOM e OpenSSL\XMLSec, e elas injetam a dependência de DLLs externas Porque eu usaria o suporte a OpenSSL ? O OpenSSL é ótimo para certificados do tipo A1... pois você não precisa instalar o certificado no Windows... basta apontar o caminho do arquivo PFX e a Senha: ACBrNFe1.Configuracoes.Certificados.ArquivoPFX := edtCaminho.Text; ACBrNFe1.Configuracoes.Certificados.Senha := edtSenha.Text; Porque remover o suporte a uma das bibliotecas de SSL ? A desvantagem, é que a sua aplicação agora ficou dependente de mais DLLs, e para alguns pode ser um problema, distribuir e instalar as mesmas Onde eu encontro as DLLs ? \ACBr\DLLs\OpenSSL \ACBr\DLLs\XMLSec Para onde eu copio essas DLLs ? Você deve copiar TODAS as DLLs das pastas acima indicadas (e não apenas algumas). Você pode copiar para a mesma pasta da sua aplicação .EXE ou para o "System" do Windows Observe que, essas DLLs são 32 bits, e portanto só funcionarão para aplicações compiladas com um compilador 32 bits (que é o padrão para Delphi e Lazarus)... Uma aplicação 32 bits roda em um S.O. 64 bits, mas o oposto não ocorre... Considerando que essa DLLs são 32 bits, então: Se o seu Windows for 32 bits, copie para a pasta: C:\Windows\System32 Se o seu Windows for 64 bits, copie para a pasta: C:\Windows\SysWOW64 Se você estiver instalando DLLs de 64 bits em um Windows 64 bits, então a pasta correta é: C:\Windows\System32 (vai entender... pergunte pra Microsoft) Como eu removo a dependência ? Nunca usou o OpenSSL ? Nunca deseja usar ? Então você pode remover o suporte do ACBr ao OpenSSL/XMLSec, e com isso, remover a dependência de sua aplicação das DLLs do XMLSec.. Edite o ACBr.inc... Observe que no inicio do mesmo, existem as linhas abaixo: {.$DEFINE DFE_SEM_OPENSSL} {.$DEFINE DFE_SEM_CAPICOM} Apenas remova o ".", se quiser ativar a remoção... {$DEFINE DFE_SEM_OPENSSL} Por que mesmo assim, a sua aplicação fica dependente das DLLs do OpenSSL (libeay32.dll, ssleay32.dll) ? O ACBr usa o OpenSSL para várias outras tarefas, como: criptografia e assinatura (ACBrEAD), comunicação segura (ACBrMail, ACBrHttp)... e outras... Então hoje, elas sempre serão necessárias... essa dependência já existia no "Trunk1"

Pior, muitos nem colaboram com a equipe, que com certeza tem custo para manter isto tudo no ar, e se acham no direito de cobrar.

Não é justo. Não é lícito. Não é aceitável. Quando você bombardeia este fórum com questionamentos relativos aos componentes da suíte ACBr, com certeza, você não conhece o mínimo necessário e aceitável que lhe dê embasamento para tal. Com toda certeza, você já recebeu algum benefício aqui, mesmo que seja na forma de resposta à sua dúvida imbecil, afinal, quem de nós “magros” conhecedores do “object pascal” não fez um questionamento, torpe? Eu mesmo, fiz muitos, e, por inúmeras vezes o erro estava tão perto de mim que, minha “ânsia” por solução transferia algo que não poderia defender-se uma culpa que só minha. · Vejo hoje, questionamentos como os que um dia fiz, e, para você que impugna um componente merecedor de todos os méritos dos quais faz jus, é prudente que leia a história desta suíte, especialmente destes baluartes que o criaram, em especial, Daniel Simões, André de Freiras Moraes, Isaque Pinheiro, entre outros, e, dentre os quais posso destacar, Ítalo, Juliomar, EMBarbosa, Rafael Dias, Regys Silveira e, não poderia faltar a musa moderadora Juliana Tamizou. · Para aqueles que são moderadores e que não mencionei, meu respeito, minha admiração. Para você que está chegando agora, calma, muita calma, aqui não tem nenhum empregado seu, aqui tem sim, colaboradores, pessoas como você, e, muito diferente de você, pessoas que despende muito do seu tempo para permitir que você consiga se destacar no seu segmento. Por favor, não me queira mal, eu já fui assim igual a você, que, ao ler um texto como este pense, “que babaca”, mas é isso mesmo, sou babaca, sou assim, sou ACBr. Antes de tecer suas críticas, pense no quando estes caras que fiz questão de frisar lhe permitiram auferir lucros e, nem por isso lhe cobram um centavo se quer. Pense nisso!

"Informamos que seu cedente está homologado e pode entrar em produção a partir desta data." OBS.: CRÍTICAS VISUAIS BOLETOS – SÓ AJUSTAR · A frase do campo referente ao "local de pagamento" deverá ser: "PAGÁVEL PREFERENCIALMENTE NAS COOPERATIVAS DE CRÉDITO DO SICREDI". É isso aí, foi homologado da forma que eu postei anteriormente, sem modificações no fonte do ACBr. Eles insistem até o fim para eu alterar esse "local de pagamento", vou alterar só para ficarem felizes. Obrigado a todos e espero que esse tópico ajude mais alguém.

Olá pessoal, novidades sobre este assunto. Conseguimos contato com a Bematech referente aos problemas que estão acontecendo com a MP4200. Nos retornaram email esclarecendo a situação conforme abaixo: "Nossa engenharia detectou um comportamento, diferente do habitual, no modelo do ECF MP-4200 TH FI II, e que em alguns casos pode ocorrer para o ECF MP-4200 TH FI na versão de firmware 01.00.02. No entanto, uma simples manutenção em um componente interno do ECF, soluciona este comportamento. As autorizadas estão sendo instruídas a realizar esta manutenção." E complementaram explicando que: " As impressoras possuem uma placa de comunicação com o fisco. Como não existe esta comunicação a placa fica tentando o contato e entra em loop, dando erro de comunicação.A manutenção a ser feita pelas assistência, é manualmente desativar esta placa. Segundo ele tem muitos softwares que não tem problema com isso, que tratam este "ocupado"." Qualquer outra novidade atualizo aqui. Abraço

Amigos, consegui descobrir o problema. No método rlVendaBeforePrint da Unit ACBrDANFECeFortesFr, quando se calcula o total de pixels da página, a codificação pega a altura (height) do subDetail ( com 80 pixels altura) que contem três rlBands dentro 1 rlBand para os itens (rlbDetItem) (com 24 pixels de altura) 1 rlBand para desconto no item (rlbDescItem) (com 24 pixels de altura) 1 rlBand para outros acréscimos no item (rlbOutroItem) (com 24 pixels de altura) acontece que na codificação sempre leva em consideração que a altura de cada item do DANFE-Ce é de 80 pixels e isso não é verdade. O item sempre vai ser impresso, mas o desconto e o acréscimo nem sempre. o fato de imprimir muitos itens faz com que o calculo do tamanho do relatorio fique furado. Abaixo envio a unit corrigida pra ser anexada no projeto. ACBrDANFCeFortesFr.pas

Agnaldo, em nome da equipe agradecemos suas palavras, as vezes não damos uma resposta da qual o usuário espera, pois as vezes esperamos deles pelo ao menos esforço no aprendizado, já que não exigimos conhecimentos para manutenção ou desenvolvimento dessa Suite (ACBr). Do nosso lado, como todos, não somos também "magos" do "object pascal", mas nos esforçamos muito para nosso próprio aprendizado, e conseguirmos o conhecimento para manter tal projeto, pois estudamos a linguagem, a ferramenta (Delphi, Lazarus), e ainda os enormes manuais e Leis para cada um dos componentes, para que os mesmos atenda dentro dos padrões estabelecidos, e para tirar nosso estresse, ainda ajudamos nas dúvidas e aqui no fórum. Então em nome do ACBr gostaríamos que pelo ao menos, víssemos nas perguntas, clareza nas dúvidas, e enxergarmos que ela aconteceu mas deixou transparecer que houve esforço de quem a está fazendo antes de posta-la, pois aqui não ensinamos Delphi, Lazarus, Leis, aqui desenvolvemos componentes e a ajudamos a usa-lo, e seus usuários deviam pelo ao menos conhecer e dominar sua ferramenta de trabalho.

Olá pessoal, Depois de um empolgante trabalho em conjunto entre a equipe do ACBr e do Fortes Report CE... Temos o orgulho de apresentar a nova versão do Fortes Report CE, trazendo os seguintes benefícios: Diversos bugs corrigidos Suporte a Lazarus Suporte a D7 a Tokyo 10.2.2 em um único Package Instalador automatizado (frceInstall.exe) O Fortes Report CE poderá ser baixado pelo SVN ou GIT, ou ainda, baixado pelo FRCEInstall.exe, usando a integração com o SVN Para baixar o Fortes Report CE por SVN, use o endereço: https://github.com/fortesinformatica/fortesreport-ce/trunk Para baixar o Fortes Report CE por GIT, use o endereço: https://github.com/fortesinformatica/fortesreport-ce.git Lembre-se que você precisará remover qualquer outra versão do Fortes Report que existir em sua máquina antes de instalar a nova versão... Isso implica em: Remover o Package da versão antiga do Delphi Remover os diretórios da versão antiga do Lib Path do Delphi Apagar os fontes e DCUs, e BPLs da versão antiga Todos os pacotes do ACBr, que fazem referencia ao Fortes Report, estão nesse momento, sendo alterados para fazer uso do novo nome de pacote adotado pelo Fortes Report CE Delphi: frce.dpk; Lazarus: frce.lpk

Necessidade: Foi necessário fazermos algumas alterações nas linhas de códigos do fonte do ACBr para que o Delphi XE5 pudesse compilá-lo em 64 bits. Deste modo é possível que o Delphi XE5 compile em 32 bits e 64 bits. ... \Fontes\ACBrCapicom\ACBrHTTPReqResp.pas Na linha 213: Antes Depois {$IFDEF WIN64}lCertContext: integer;{$ENDIF} Na linha 250: Antes CertContext.Get_CertContext(integer(PCertContext)); Depois {$IFDEF WIN32} CertContext.Get_CertContext(integer(PCertContext)); {$ELSE} lCertContext := integer(PCertContext); CertContext.Get_CertContext(lCertContext); PCertContext := Pointer(lCertContext); {$ENDIF} Na linha 256: Antes CertContext.Get_CertContext(integer(PCertContext)); Depois {$IFDEF WIN32} CertContext.Get_CertContext(integer(PCertContext)); {$ELSE} lCertContext := integer(PCertContext); CertContext.Get_CertContext(lCertContext); PCertContext := Pointer(lCertContext); {$ENDIF} ... \Fontes\ACBrCapicom\JwaWinBase.pas Nas linhas 6165 e 6165: Antes begin Result := PVOID(InterlockedExchange(LONG(Target), LONG(Value))); Depois {$IFDEF WIN64} var lTarget, lValue: integer; {$ENDIF} begin {$IFDEF WIN64} lTarget := LONG(Target); lValue := LONG(Value); Result := PVOID(InterlockedExchange(lTarget, lValue)); Target := PVOID(lTarget); Value := PVOID(lValue); {$ELSE} Result := PVOID(InterlockedExchange(LONG(Target), LONG(Value))); {$ENDIF} Nas linhas 6170 e 6171: Antes begin Result := PVOID(InterlockedCompareExchange(LONG(Destination), LONG(Exchange), LONG(Comperand))); Depois {$IFDEF WIN64} var lDestination, lExchange, lComperand: integer; {$ENDIF} begin {$IFDEF WIN64} lDestination := LONG(Destination); lExchange := LONG(Exchange); lComperand := LONG(Comperand); Result := PVOID(InterlockedCompareExchange(lDestination, lExchange, lComperand)); Destination := PVOID(lDestination); Exchange := PVOID(lExchange); Comperand := PVOID(lComperand); {$ELSE} Result := PVOID(InterlockedCompareExchange(LONG(Destination), LONG(Exchange), LONG(Comperand))); {$ENDIF} ... \Fontes\ACBrNFe2\ACBrNFeDANFEFRDM.pas Nas linhas 245 e 246: Antes iDelLen := PCardinal(Cardinal(ADelimiter) - SizeOf(Cardinal))^; iLen := PCardinal(Cardinal(AString) - SizeOf(Cardinal))^; Depois {$IFDEF WIN32} iDelLen := PCardinal(Cardinal(ADelimiter) - SizeOf(Cardinal))^; iLen := PCardinal(Cardinal(AString) - SizeOf(Cardinal))^; {$ELSE} iDelLen := PCardinal(int64(ADelimiter) - SizeOf(Cardinal))^; iLen := PCardinal(int64(AString) - SizeOf(Cardinal))^; {$ENDIF} Na linha 264: Antes for x := 1 to PCardinal(Cardinal(Step^) - SizeOf(Cardinal))^ do Depois {$IFDEF WIN32} for x := 1 to PCardinal(Cardinal(Step^) - SizeOf(Cardinal))^ do {$ELSE} for x := 1 to PCardinal(int64(Step^) - SizeOf(Cardinal))^ do {$ENDIF} Na linha 272: Antes Cardinal(Step) := Cardinal(Step) + SizeOf(Cardinal); Depois {$IFDEF WIN32} Cardinal(Step) := Cardinal(Step) + SizeOf(Cardinal); {$ELSE} int64(Step) := int64(Step) + SizeOf(Cardinal); {$ENDIF} ACBrHTTPReqResp.pas ACBrNFeDANFEFRDM.pas JwaWinBase.pas

Boa tarde, Configurado e enviado com sucesso para gmail e hotmail. Gmail tem que configurar no site para ativar "aplicativos menos seguros". E-mail e senha são particulares (aqueles ali não são válidos caso tentem utilizar). Servidor SMTP:. smtp.gmail.com porta:......... 25 usuario:....... [email protected] senha:......... xxxxxx SSL:........... Não (false) TLS:........... Sim (true) Servidor SMTP:. smtp.gmail.com porta:......... 465 usuario:....... [email protected] senha:......... xxxx SSL:........... Sim (True) TLS:........... Não (False) Servidor SMTP:. smtp.gmail.com porta:......... 587 usuario:....... [email protected] senha:......... xxxx SSL:........... Não (False) TLS:........... Sim (True) Hotmail (Não testei com SSL = true e TLS = true, ou, SSL = false e TLS = false) Servidor SMTP:. smtp.live.comporta:......... 587 ou 25 usuario:....... [email protected] senha:......... xxxx SSL:........... Não (False)TLS:........... Sim (True) Abraço.

Então Juliomar, isso eu já tinha feito... o problema é que eu estava cometendo um erro na declaração... era para eu ter declarado ACBrDevice, que é justamente onde se encontra os estados. Mesmo eu fazendo isso que você recomendou, não daria certo sem a declaração do ACBrDevice... sempre apareceria Undeclared Identified. Brigadão pelas dicas e disponibilidade.

Bom dia. A menos que o sistema dos bancos faça alguma validação ao receber boletos que foram registrados (coisa que acho pouco provável), ainda que essas informações constem na remessa as mesmas não afetarão o recebimento pelo caixa. A instrução de protesto vai depender da contratação deste serviço junto ao banco, porém os juros acredito que realmente vai depender da disposição do caixa. Att.

Bom dia Fernandes. Aqui optamos pelo Tanca e pelo Gertec. Com o Tanca, entre 15 aparelhos apenas 1 apresentou problema e foi trocado pela própria Tanca em mais ou menos 15 dias. Optamos pelo Gertec como uma segunda opção de revenda. Nenhum problema foi apresentado, mas o único detalhe é a necessidade de usar a fonte de alimentação do aparelho, pois em dependendo da CPU você vai se deparar com umas travadas por conta do hardware. Em nenhum dos dois aparelhos tivemos problemas com a ativação, etc. Fica ai as dicas.

Boa tarde Pedro, No Ide do Delphi basta pressionar control e clicar em cima da propriedade a qual quer mais detalhes: Ide.indFinal <-- Pressione control e clique em cima da propriedade indFinal. O Editor sera redirecionado para a seguinte linha: property indFinal: TpcnConsumidorFinal read FindFinal write FindFinal; Pressione control novamente e clique em cima do tipo "TpcnConsumidorFinal" Ele exibira a declaração do tipo , isto vale para todas as propriedades.

Realmente o problema estava vinculado a isso, lá no emulador do sefaz tem um arquivo que fica dentro da pasta SAT chamado configuracoes.xml. Quando instalei eu mudei a tag <nSerieSat> para 12345678 o que na verdade o padrão era 123456789, voltei o arquivo com as configurações originais e deu tudo certo. Obrigado pela ajuda!

Pessoal deixo aqui uma dica aos que chegarem neste tópico com relação a um comparativo que fiz entre a Elgin I9 e a Elgin VOX utilizando-se do componente ESCPOS ou POSPRINTER do novo trunk2, a Elgin I9 imprime os comandos corretos de forma ideal utilizando-se o modelo escepson e a Elgin Vox só imprime os caracterres e comandos corretos se for selecionado o modelo escelgin, ok? Fica ai a dica!

Bom dia pessoal. Acabei de implementar com sucesso, para o Trunk1, os seguintes métodos para o provedor CONAM. - Envio de Lote; - Consulta de Lote; - Cancelamento de NFS-e. Pretendo colaborar, logo que possível, para implementar no Trunk2. Caso necessite posso enviar os fontes dos métodos que alterei. Obrigado. Danny

Rodrigo, Esse XML que você postou não serve para imprimir o evento, tem que ser o procEventoCTe.xml Por favor não fique postando varias vezes o mesmo problema, veja a resposta que dei em seu outro post.

Bom dia. Estou seguindo os testes com NFSe no trunk2 aqui e estou enfrentando as seguintes situaçãoes: 1 - Criei o arquivo Digifred.ini e configurei ele conforme as informações que tenho do provedor e que eram usadas com sucesso no Trunk1. 2 - Ao executar o comando "ConsultarNFSeRPSEnvio" retornar erro "bad request" 3 - Ao executar o comando "EnviarLoteRPSEnvio" Ocorre o erro em anexo. Segue tb em anexo o arquivo Digifred.ini Vou continuar testando aqui para ver se encontro o problema. Se alguém souber do que se trata, fico agradecido se puderem me ajudar. DigiFred.ini

Segue ai o motivo da Falha no Shema da NT2015.002

Bom dia. Você registra esses boletos no banco através de um arquivo de remessa? Se não, para essas instruções serem respeitadas, vai depender da boa vontade do caixa de ler e cobrar no momento do pagamento, ou se o cliente pagar esse boleto via caixa eletrônico ou via internet, ele também pode ignorar essas informações. Espero ter ajudado, e caso esteja errado alguém me corrija, por favor. Obrigado.

Bom dia pessoal, não sei sé aqui mesmo que posto isso...Ontem o AVG bloqueou o ACBRNFEMONITOR em 05 clientes meus. Daí se alguém tiver o mesmo problema é só ir na quarentena e mandar recuperar que ele recupera e já adiciona na exceção. Não sei qual medida tomar mas vou mandar um e-mail para eles alertando do fato que o acbrnfemonitor.exe não é vírus nem suspeito. Rubens

A onde a impressão fica presa ? Que tipo de Impressão (PDF, direta, com preview, etc) ? Aparece algo no Spooler da Impressora ? Foque nisso... Tente nos fornecer informações precisas, de como reproduzir esse problema em nossa máquina de desenvolvimento... Provavelmente você precisará nos passar um passo a passo de como configurar o Monitor, para que fique nas mesmas condições de uso do seu... além de fornecer toda a sequencia de comandos, até o problema... PS: Notei que o seu comando de envio ao PLUS, está com a sintaxe errada... Todas as Strings devem estar entre Aspas duplas:

o csosn 900 é para poder destacar os impostos na nota, se não for destacar não precisa usá-lo.

Por favor seja paciente... Não adianta disparar 10 perguntas sobre o mesmo assunto.... Nove grávidas não parem um bebê em 1 mês... A maneira atual é a mais correta do ponto de vista jurídico ( antes estava errado mudar o XML ) No entanto houve quebra de compatibilidade e nem todos os programas estão preparados para usar (ler) o XML do evento... No momento, os "core developers" estão debatendo sobre esse assunto...

Estão falando sobre NFCe e você sobre o SAT, existem diferenças entre os dois casos. Poste o seu problema no local correto e logo terá alguma resposta.

www.djpdv.com.br

Olá, Estou usando o Fortes para gerar o DANFe, mas a logo não estava carregando, analisando os fontes vi que a logo só estava sendo carrega a partir de arquivos, mas estava passando o stream da imagem. Alterei o carregamento para ficar semelhando ao usado no ACBrDANFCeFortes. Também o campo unidade dos itens não tinha espaço suficiente para imprimir os 6 caracteres que podem ser passados para ele. Diminui o campo quantidade e aumentei o da unidade. Segue os fontes para que, se possível, essas alterações sejam incluídas no tronco do ACBr. Desde já, Obrigado ACBrNFeDANFeRLRetrato.dfm ACBrNFeDANFeRLRetrato.pas

Olá Rodrigo, Existe um tópico no fórum falando sobre a descontinuação do trunk. Estou utilizando o trunk2 e enviando NFCe sem problemas. Acredito que você terá de migrar para o trunk2 também. Abraço

Quando eu utilizo o certificado digital da empresa (com root certificado) me ocorre este mesmo erro. Quando crio um novo certificado com OpenSSL não me ocorre erro. Talvez utilizando outros parâmetros do Signtool resolva seu problema, veja no Google que tem vários questionamentos sobre isso. Se conseguir descobrir me avise.

No svn a alteração

Bom dia estarei providenciando a validação desse código e aviso quando estiver pronto mais uma informação ele foi implementado no trunk e está diferente do trunk2 mas farei a adição do código

Quando for simples nacional , manda 49 para qualquer produto. No caso do 99 , é para ser usado em empresas lucro real ou presumido , quando for o caso de produto: subtituição tribtário ( desde que não seja monofásico onde tem que mandar 04) , teria que mandar 05 , mas no sat como não esta ainda implementado ai manda-se o 99 em substituição ao 05 com aliquotas e base de calculo zerados ver instruções em anexo , nos itens 13 e 13.1 OrientaçõesLeiauteCF-e_v00.06-0 - AD.pdf

Experimente trocar a versão do xml. Você está usando o 0.03, coloque 0.05 já fiz isso e o erro continua. O estranho que o cupom de venda ele envia com sucesso e o teste fim a fim também funciona normalmente. Parece que a chave gerada está errada: CFe35151011111111111111591230000694848878 Deveria ter 44 caracteres sem contar o "CFe" A chave do envio já está assim.

Viu vamos novamente não adianta ficar postando se querem teimar em instalar a gente está mexendo e não está funcional! então ou baixam verem o erro e ficam de boa ou não marque no instalador ! entenderam?

Boa tarde Pedro, Você programa em Delphi? Se sim, deve estar usando o componente ACBrNFe, correto? Sendo assim você deve estudar o programa exemplo, nele você vai encontrar uma procedure responsável por alimentar o componente com os dados pertinentes a venda, entre outras coisas.

Sugerimos.. Melhor Indicamos a atualização de todos para o mesmo! o trunk2 está cada dia sendo melhorado e esta é uma das grandes melhorias promovidas! a quem achar bugs seja no delphi ou lazarus no FortesReport Community Edition pedimos que abra um issue no github do projeto e ela será avaliada seja pela equipe da fortes ou por que algum de nós !

Para Remover o Fortes4Lazarus e instalar o Fortes Report CE Package -> Install/UnInstall package Ache o Fortes4Lazarus clique nele e em: "Uninstall selection" Save and Exit Package -> Package Links Ache o Fortes4Lazarus Selecione o Fortes4Lazarus Clique em "Delete Selected" Package -> Open Package file Abra o arquivo "frce.lpk" Compile Use -> Install Reconstrua o Lazarus Os Pacotes do ACBr para Lazarus, que faziam usam do Fortes4Lazarus, já foram migrados para o Fortes Report CE (frce.lpk)