OlavoJr

Boa tarde, Victor! Demorei para responder, é que fiz novo contato com o suporte e me confirmaram sua afirmação, somente os numéricos. Fiz a correção na unit, em anexo, gerei uma nova remessa e fiz a validação, conforme abaixo, deu certo. Só para informação a documentação do BTGPactual eles orientaram a seguir, layout Febraban 240 v10.9: https://cmsarquivos.febraban.org.br/Arquivos/documentos/PDF/Layout padrao CNAB240 V 10 09 - 14_10_21.pdf ACBrBancoBTGPactual.pas

Na homologação junto ao suporte do banco foi feito a seguinte orientação: "Sugerimos o preenchimento com zeros os campos numéricos do segmento R, pois serão usados no futuro pelo banco." Com a explicação na imagem abaixo: Vou anexar a tela com a imagem da validação OK feita no ambiente deles com a devida correção. Segue em anexo, a unit com a correção mencionada. Olavo ACBrBancoBTGPactual.pas

Danilo, eu consegui resolver, reinstalando o componente (ACBRInstall) e depois abrir o projeto e indo no form que tem o ACBRBoleto ai acusou a falta da propriedade, importante aceitar para remover a propriedade obsoleta e salvar o form (dfm), só da uma movida no no objeto e salvar, ai pode compilar/build e testar que deve funcionar.

Da uma olhada nestes post: e https://www.projetoacbr.com.br/forum/topic/75503-fim-suporte-svn-no-github-em-24012024/

@Juliomar Marchetti Eu até já fiz isso em outro post, mais para gerar o problema só acontece em determinados clientes e com certos usuários, acho que tem a ver com o windows/configuração da máquina, ou seja, acontece "muito raramente". A nossa proposta é trocar o Round() pelo RoundABNT() em todas as units do Boleto, visto que no setValorDocumento vocês mesmo usam o RoubdABNT() mais como o problema só acontece "muito raramente" o @José M. S. Junior analisou o outro post e acho que ficou meio com pé atrás aceitar a correção e afetar os demais usuários de alguma forma. Se der para o @jdazevedo fazer a troca do tipo de campo conforme foi orientado e ver se resolve e postar aqui o resultado aqui, caso persista o problema, ai sim volto a insistir na troca da função, senão permaneço com a minha solução só nos meus fontes mesmo, devido a não conseguir nem mesmo demonstrar o problema devido ao "muito raramente".

Boa tarde, João! Conosco este caso acontece raramente, mais para resolver experimente alterar a unit ACBrBancoBradesco e trocar o Round pelo RoundABNT. Mesmo que aparente não precise pois no setValorDocumento da unit ACBrBoleto já foi ajustado o arredondamento com RoundABNT, acredito que a unit Round bagunce o arredondamento depois de setado o valor. Olavo

Boa noite, Carlos! Os componentes de Boleto do ACBR, tratam somente a remessa/retorno de BOLETOS não tem o formato para PAGAMENTOS. Somente como observação abra o seu arquivo com o NOTEPAD++ e ative no menu superior em VISUALIZAR / MOSTRAR SIMBOLO / EXIBIR TODOS OS CARACTERES vai notar que a última linha que é o trailer esta sem o carácter de final de linha, mais uma observação os meus tive problema semelhante e precisei também deixar uma linha em branco no final do arquivo (somente um palpite).

Bom dia, @Daniel Simoes! Fiz como pediu (voltando a pasta pelo SVN) e ainda persistiu o mesmo erro, desinstalei o Lazarus, reinstalei os componentes e fazendo diversos testes consegui executar removendo os componentes (ACBrBoletoFCFortes1 e ACBrBoletoFCLazReport1), para isso removi os componentes visualmente e comentei as units e executou, como pode ver em anexo eu já instalei o FORTES e o LAZREPORT, o mais poderia estar faltando? Olavo

Boa tarde, @Juliana Tamizouanexei o LFM conforme a dica que o @Daniel Simoespassou! @Daniel Simoes mesmo que tenha resolvido como ajustar o LFM (estou perguntado neste tópico porque as imagens já estão anexadas acima), gostaria de saber o que tá errado com minha instalação do Lazarus , pode me dar uma dica sobre o erro na execução do demo do boleto que dá "External: SIGSEGV", o LazReport esta instalado conforme a @Juliana Tamizou pediu para verificar, o erro acontece na chamada do CreateForm e se coloco um BreakPoint no evento OnCreate nem chega nele. ACBrBoletoFCFortesFr.lfm

Sim já estava instalado (por segurança abri e instalei novamente), anexei a imagem dos componentes instalados, estranho que se ainda fosse dependência de algum componente ele avisaria no build, né? (eu até consigo abrir o ACBrBoletoFCFortesFr e mexer para te mandar o lfm, mais queria testar, executando e gerando um PDF para ver se ficou OK a alteração)

Bom dia, @Juliana Tamizou Estou tentando alterar o lfm, mais tô "apanhando" com o Lazarus (no Windows/x64) se alguém puder da uma força @Daniel Simoes que usa em produção mesmo, instalei os componentes "dependentes" do demo do boleto mais não vai, consegui abrir e executar o demo do TCP / ConsultaCNPJ tudo OK, mais o demo boleto não passa do CreateForm( fmDemo), o que poderia ser, segue a imagem debugando e o erro? Olavo

Boa noite! Fiz um teste com o próprio demo do boleto para o banco BRADESCO (layout padrão) e anexei o PDF gerado, anexei também uma imagem apontando alguns pequenos detalhes de altura de alguns componentes que faz o tracejado, em anexo segue a correção .DFM. Olavo boleto.pdf ACBrBoletoFCFortesFr.dfm

Bom dia! Não esta disponível, consegui validar através de uma terceira pessoa que foi designada pela RFB como testador. Com as alterações que passei, passou pelo validar e já atendendo a versão 1.2 da documentação.

Bom dia! Adicionei a unit Unit2.pas da pasta "ACBR\Exemplos\ACBrTXT\ACBrLCDPR\Delphi" referente ao EXEMPLO já ajustado para a versão 1.2, procurei melhorar o exemplo colocando informação como se fosse de dois meses Janeiro e Fevereiro isso afeta diretamente nos registro Q200. Olavo Unit2.pas

Elton, já para sua revisão, tive de mexer em mais código, consegui fazer testes em uma prévia de validador da própria RFB, segue conforme abaixo: Na unit UACBrLCDPR, deu problema com o DELIMITADOR que na última coluna não pode ser gerado, ou seja o último caracter da linha não pode ser o piper conforme documentação, sendo assim, foi criado um parametro na função abaixo, seguindo outros componentes próprio ABCR que geram txt function AddCampo(const Value : String; AddDelimiter: Boolean = True ) : String; function TACBrLCDPR.AddCampo(const Value: String; AddDelimiter: Boolean): String; begin Result := Trim(Value); if AddDelimiter then Result := Result + Delimitador; end; Com isso ainda na unit UACBrLCDPR nas funções de WRITEBLOCOS na ultima chamada AddCampo() foi passado o parametro FALSE. Na unit BlocoQ e RegistroQ200 foi removido o valor PAIS, não consta mais na documentação. Olavo UACBrLCDPR.pas BlocoQ.pas RegistroQ200.pas

Boa tarde! Fiz algumas adequações para atender a documentação da versão 1.2, segue abaixo as descrições das implementações: Unit Registro0030 e UACBrLCDPR os comentários com a licença estava perdido no corpo do código, foi colocado logo no inicio. Unit RegistroQ200 necessário criar o registro como uma LISTA Unit BlocoQ o "FRegistroQ200: TRegistroQ200" tornou-se "FRegistrosQ200: TRegistroQ200List" Unit LCDPRBlocos - Foi necessário adicionar alguns tipos a mais para atender a documentação 1.2 e também foi alterados as funções que devolvem o STR para os valores de acordo com a documentação 1.2 TCodVer adicionado o valor Versao011 (o manual da receita é 1.2 mais no exemplo o valor estava com 011!) TTipoExploracao adicionado o valor teOutro TTipoContraparte adicionado o valor tpcOutro TTipoLanc, foi removido tlDespesaNaoDedutivel e tlAdiantamentos As funcões abaixo foi necessário, ajustar os valores para atender a documentação 1.2: function IndFormaApurToStr(IndFormaApur : TFormaApur) : String; function TipoExploracaoToStr(TipoExploracao : TTipoExploracao) : String; function TipoContraparteToStr(TipoContraparte : TTipoContraparte) : String; function TipoDocToStr(TipoDoc : TTipoDoc) : String; function TipoLancToStr(TipoLanc : TTipoLanc) : String; A constante "crFinal = 'CRLF'" foi atribuido o valor '', acredito que houve um equivoco porque no manual se refere aos caracteres "CR" (Carriage Return) e "LF" (Line Feed) correspondentes a "retorno do carro" e "salto de linha", respectivamente (CR e LF: caracteres 13 e 10, respectivamente, da Tabela ASCII) e criaram como uma STRING. Olavo. LCDPRBlocos.pas UACBrLCDPR.pas BlocoQ.pas RegistroQ200.pas Registro0030.pas

O Tortoise atual versão 11 esta com este problema, remove e instala versão 10 ou 9 e vai conseguir fazer o checkout ou a solução na versão 11 é baixar o zip e instalar mais ficará desatualizado.

Utilizando o ACBRCHQm com a configuração de modelo para "impressora comum" (no caso será um EPSON matricial), como se faz para tratar impressão de cheque com canhoto, no caso apareceu um formulário (continuo) do banco Caixa e olhando o código na classe ACBRCHQClass o default ficaria: WriteString('Formato','104','56,13,01,04,18,48,53,72,01,04,07,10,12') ; Com isso vai considerar o inicio desde a coluna 1 e no caso do canhoto teria de começar algumas colunas a mais direita, alguém já passou e por isso e conseguiu resolver?

No componente tem a propriedade "ImprimirMensagemPadrao" passe para False e controle você mesmo as linhas de mensagens, colocando na propriedade Mensagem o conteúdo "que quiser" (leia o manual para considerar esse o "que quiser"), observe que depois terá de fazer o envio da REMESSA e cada banco tem a limitação de linhas e quantidade de bytes por linha e terá neste momento de enviar o que imprimiu.

Qual é banco em questão e qual o layout utilizado?

Isso mesmo, obrigado:

Esta com algum problema no momento?

Assinando o SAC, além do suporte é liberado a versão mais recente para download, minha dúvida é para quais plataformas são disponibilizados os executáveis, em especial para o Linux (x64)? Para me orientar melhor no ambiente Linux (x32 e/ou x64), caso não instale o Lazarus para obter o binário compilado, obtendo da área de download do SAC, além de buscas pelo fórum, tem algum documento no projeto com as dependências necessárias para funcionamento, como a necessidade de instalação de pacotes e orientação de como instala-los, tipo: OpenSSL, ....?

Bom dia, @Juliomar Marchetti! Posteriormente em 17 de agosto de 2016 você fez um commit de um outro colaborador que contemplou a minha alteração, ou seja, pode desconsiderar esta minha implementação, obrigado!

Rodrigo, Olhando o seu arquivo e comparando com a documentação ele não é um arquivo de RETORNO por isso a mensagem, observe na primeira linha na coluna 143 é esperado que o valor seja 2 conforme o manual e no seu caso é 1, coloquei abaixo o endereço com os manuais existentes aqui mesmo no forum: svn://svn.code.sf.net/p/acbr/code/trunk2 Espero ter ajudado, abraços