Painel de líderes

Se está se referindo a imagem que o Daniel postou você pode instalar o pacote "anchordockingdsgn", se eu não me engano, ele já vem com lazarus, basta acessar, no lazarus, Pacotes -> Instalar/Desinstalar e procurar esse pacote na lista "Disponíveis para Instalação".

Quer se concentrar e escrever aquele código fonte que parece um poema ? Então pegue seus fones de ouvido, ligue uma musica (instrumental), e se desligue do mundo externo... ... sou fã dessa banda (pouco conhecida), e que achei graças às sugestões do Spotify...

O inicio dessa música o fonte ficaria dessa forma: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;?

não me responsabilizo pelos meus fontes depois de ouvir isso ?

Isso mesmo...basta instalar esse Package e arrastar as janelas para compor a sua IDE... Aplicações comuns também podem usar esse recurso... http://wiki.freepascal.org/Anchor_Docking

Atualizei os fontes, testado e funcionando ok.

No Ubuntu após vários testes o que funcionou foi baixar e compilando diretamente do repositório o xmlsec1, no Fedora bastou instalar os pacotes diretamente dos repositórios e criar um link simbólico pois ao realizar o build do Lazarus ele não estava encontrando a lib xmlsec1, abaixo segue o passo a passo que utilizei baseado nas dicas do vídeo https://www.youtube.com/watch?v=wU8KRNMwUaw #UBUNTU 18.04 apt install libxml2-dev apt install libltdl-dev apt install libssl-dev wget http://www.aleksey.com/xmlsec/download/xmlsec1-1.2.27.tar.gz tar -zxvf xmlsec1-1.2.27.tar.gz cd xmlsec1-1.2.27 ./configure make make install #FEDORA 27/28 yum install libxml2-devel yum install libxslt-devel yum install libtool-ltdl-devel yum install openssl-devel yum install xmlsec1 ln -s /usr/lib64/libxmlsec1.so.1 /usr/lib64/libxmlsec1.so

A alteração realizada no arquivo Fontes/ACBrOpenSSL/libxmlsec.pas Alterada a linha: LIBXMLSEC_SO = 'libxmlsec.so'; para: LIBXMLSEC_SO = {$IFNDEF MSWINDOWS}'libxmlsec1'{$ELSE}'libxmlsec.so'{$ENDIF}; Esta alteração esta gerando o erro abaixo ao tentar gerar/assinar o xml da NFe: ERRO: "xmlSecNodeSignature" could not be loaded from the dynamic library libxmlsec1 Uma solução paliativa para contornar o problema foi criar um link simbólico com o nome libxmlsec1 sem a extensão .so ln -s /usr/lib64/libxmlsec1.so.1 /usr/lib64/libxmlsec1 https://github.com/GabrielF7/ACBrTrunk2/commit/c49df5f71c32474ae5caa9b5b32e4485eca5ba5a#diff-315e5578b57ec7910d57ff00a15b02c2

Boa tarde a todos, Alessandro, fiz um merge das suas alterações e algumas correções. Joffas, implementei o método Download. Novos métodos implementados no componente ACBreSocial function ConsultaIdentificadoresEventosEmpregador(const CnpjEstab: String; tpEvt: TTipoEvento; PerApur: TDateTime): boolean; function DownloadEventos(const CnpjEmpr, PorID, PorNrRecibo: String): boolean; O primeiro como podem ver é especifico para Eventos do Empregador, tem ainda do Trabalhador e Tabelas que precisam ser implementados. O de Download devemos informar o CNPJ e o ID ou CNPJ e o Numero do Recibo. Exemplo: ACBreSocial.DownloadEventos(xCNPJ, xID, ''); ou ACBreSocial.DownloadEventos(xCNPJ, '', xRecibo); É preciso melhorar, sendo assim preciso que façam testes. Essas alterações já estão disponíveis no repositório. Se faz necessário agora alterar o programa exemplo, ou seja criar novos botões exemplificando esses novos métodos. Desde já o meu muito obrigado a todos.

Daniel, Realmente tinha uma configuração na impressora que estava fazendo cortar a parte inferior do Danfe. Estava cortando também os valores a direita, mas eu mudei a "LarguraBobina" e funcionou. Obrigado.

Provavelmente você tem uma versão antiga, e não o pacote indicado no erro Fortes Report CE

Basta LER o erro Ou Seja, você quer instalar os DANFEs em Fortes Report, ,mas não tem o Fortes Report instalado...

Boa tarde, Andremomb. Tente fazer da seguinte forma: Baixe os fontes e jogue na raiz do c, execute o instalador como administrador, marque a opção de remover arquivos antigos e a opção de usar arquivo de configuração .cfg e tente novamente.

As imagens não ajudam... anexe o Log do Instalador

Esses caracteres, no inicio do arquivo, são conhecidos como "BOM" https://en.wikipedia.org/wiki/Byte_order_mark Infelizmente o Delphi Rio, teima em converter as arquivos para UTF8... (Já corrigi no SVN)

Você está seguindo o funcionamento de algum outro componente? Porque não me parece que o objetivo dessa propriedade NomeDocumento seja definir o nome e local a ser salvo do arquivo PDF. Ela me parece ter sido criada para alterar o nome que aparece no "SPOOL" do Windows.

Bom dia. Conseguiu alguma orientação junto ao banco? Att.

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

Bom dia não tem no monitor a NFS-e . para usar o ACBr somente com Delphi ou Lazarus na NFS-e

Atualizei os fontes, testado e funcionando ok.

Bom dia, Juliomar! Acabei resolvendo aqui. O procedimento que utilizei, foi o seguinte: Limpei todo o conteúdo do FORTES, ou seja, deletei os arquivos e realizei o UPLOAD novamente, desinstalei o FORTES do delphi também. E realizei a instalação pelo instalador do FORTES. Em seguida, realizei a limpeza do ACBr e fiz o upload da pasta novamente, desinstalei o que tinha do ACBr do delphi, utilizei o instalador do ACBr. Após, realizado esses procedimentos, o ACBr foi instalado com sucesso, sem problema algum em minha máquina. Muito obrigado!

Atualizei os fontes, testado e funcionando ok.

Verifique a propriedade "EspacoFinal".... tente valores em torno de 40 ou mais... Mas realmente o ideal é usar Esc/Pos... Veja as vantagens, nesse post:

Acredito que não tenha relação com o Filtro para PDF, pois olhando o código fonte do fortes é possível verificar que é feita a instanciação de um objeto canvas que gera um bitmap como saída, e o erro ocorre durante a manipulação do componente ao ser inserido diretamente em um form como pode ser visto na imagem que postei

Pessoal, eu resolvi o meu problema entrando na pasta \\AcBr\DLLs\XMLSec\MinGW\32 e copiando todas as Dll's para a raiz da minha aplicação.

Olá, Na pasta ...\Projetos\ACBrMonitorPLUS\Lazarus\Exemplos tem uns muito bons.

Realizei novos testes e verifiquei que o problema ocorre devido a variação na quantidade de caracteres conforme pode ser visto na imagem em anexo. O fato de funcionar usando o bcEAN128C com Ratio 2 se deve realmente ao fato da inclusão do dígito verificador fazendo com que o código resultante fique em 46 caracteres, aparentemente o problema esta no fortesreport-ce

Boa tarde Suas sugestões foram disponibilizadas nos fontes do Projeto ACBr. Obrigado pela contribuição!

Encontrei o problema, esta na propriedade AutoSize ao selecionar bcCode128C e incluir um código de barras com 44 caracteres ele esta definindo o Width para 286 porém desmarcando a opção AutoSize e definindo manualmente o Width para 289 a renderização ocorre corretamente

Vou reportar o erro no projeto Fortes Report CE, as vezes algum pequeno ajuste resolva o problema, mas de imediato acredito que incluindo uma diretiva para alterar o tipo de código de barras de bcCode128C para bcEAN128C quando a compilação for realizada no Linux resolva o problema

Tentou fazer uma pesquisa aqui mesmo no fórum por "TEF iniciante"? ou TEF recomendações?

Esse tópico é antigo e como você pode ler pelas mensagens anteriores... muito provavelmente a causa do problema é a falta de atualização do Windows, que só suporta TLS1.2 nas versões mais novas... Se o seu certificado for A1, use OpenSSL...

Exclui o tópico de Pedro Lune por não ser permitido propaganda neste local. Caso queira anunciar serviços, informe no link abaixo: https://www.projetoacbr.com.br/forum/forum/14-classificados/

Boa tarde Pode acessar as propriedades dessa classe diretamente pelo método SSL. ex: ACBrNFe1.SSL.CertIssuerName / ACBrNFe1.SSL.CertCertificadora.

Tópico fechado por falta de retorno do usuário

Bom dia. Conseguiu esclarecer sua dúvida? acredito que a melhor fonte seria o contador de seu cliente. Att.

Por isso que você não teve problemas na Assinatura... (o Hash está sendo calculado pela XMLSec)... Hoje em dia, o ACBr usa rotinas próprias, para computar a Assinatura digital dos XMLs... isso é bom, pois remove a dependência da XMLSec... Nossas rotinas de calculo de Hash e Sign Digest, estão em: ACBrDFeOpenSSL.pas... e elas são usadas, quando a biblioteca de Assinatura do XML é configurada como xsLibXml2, creio que nesse cenário... você terá novos problemas, com o OpenSSL 1.1

Tópico fechado por falta de retorno do usuário

Bom dia, cgarrotti Você está com os fontes atualizados? Sem informar o problema, fica difícil tentar te ajudar. Sugiro que descreva as suas dúvidas.

Bom Dia JJA, de maneira alguma, uso aqui a muito tempo as duas IDEs e nunca tive problemas com isso. Hoje estou Usando o CE Tokyo com o Lazarus 1.8.4 e não tive problemas nenhum. Até estou instalado uma Estância do Lazarus 2.0.0 nesta mesma máquina e está tudo normal.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia, confesso que a um tempo atrás imaginava que o Lazarus havia entrado no esquecimento, vi que estava muito errado. Irei ingressar para o mundo de Lazarus, porém me surgiu uma dúvida: tendo o Delphi instalado, existe algum tipo de incompatibilidade se instalar o Lazarus? Ou seja, gostaria de deixar as 2 IDEs instaladas até que engrene com o Lazarus. Bom dia.

Boa tarde. Anexe seus logs e ini de configurações. Att.

Boa tarde Suas sugestões foram disponibilizadas nos fontes do Projeto ACBr, juntamente com outras correções. Obrigado pela contribuição!

Boa tarde Waldir, Ajustes disponíveis no SVN, juntamente com outras correções deste banco. Favor atualizar os fontes... Obrigado!

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

Ok. Muito obrigado agora ficou claro.

Boa tarde, anexei somente os fontes alterados. ACBreSocial.rar

Pessoal, apenas para deixar minha sugestão! Acabei de passar por uma situação idêntica. Uso Delphi 10.1 Berlin e Windows 10 Home 64 bits. Depois de fazer todas as sugestões aqui descritas e ainda assim não obtendo êxito, imaginei, como observado nos comentários, que o problema pudesse estar nas dll’s e que por algum motivo elas não estariam sendo carregadas juntamente com os pacotes do ACBr, mesmo estando elas em seus devidos lugares (pastas do sistema e path). Como o ACBr coloca os pacotes compilados na pasta “\Delphi\LibD24” (esta pasta pode variar de acordo com a versão do delphi) a partir da pasta raiz da instalação, tive a ideia de colocar dentro desta pasta, junto com os pacotes, as respectivas dll’s (Capicom, OpenSSL, XMLSec). Assim quando os pacotes foram carregados, os vínculos com as dll’s puderam ser estabelecidos e os pacotes carregaram sem problemas. Nunca tinha tido este problema antes usando outras versões do Delphi e outras versões do Windows. Mesmo não entendendo a lógica de porque não reconhecer as bibliotecas que estavam devidamente configuradas no path do sistema, imagino que isto possa ajudar alguém que esteja passando pela mesma situação.