Valdir Dill

Não, à direita. Clico no meu login bem acima, à direita e depois em "Conteúdo Seguido", como sempre eu fazia no layout anterior. Veja o print anexo. Obrigado.

Bom dia, Sinto falta do funcionamento do menu "Conteúdo Seguido" que no novo fórum não funciona mais. O menu ainda está lá, mas ao acionar diz que não "Não há nada aqui ainda". Eu achava bastante útil essa opção para ver e rever (e até excluir) posts da minha lista de acompanhamento. Obrigado.

Bom dia, Certo @José M. S. Junior entendi. Realmente minha alteração não estaria correta. Porém, do jeito que está, também não está correto. Por gentileza, me acompanhe na análise abaixo e veja se ela está correta. Estou anexando o arquivo remessa que dá erro o no crivo do banco. Nessa remessa Mensagem.Count é igual a 5. Então, com 5 mensagens, ou seja Mensagem.count > 2, a linha 690 da AcbrBancoBrasil.pas (ifthen( (Mensagem.Count <= 2), '0', '8' )) gera o valor "8" para a posição 18, correto? Porém, segundo o manual do banco - destaques no print anexo - diz que o campo 18 deve ser preenchido com "8" apenas para tipos 1 e 2. Se tipo for igual a 3, então essa posição 18 deve ter valor "0". Então, se, quando Mesnagem.Count maior que 2, tipo será igual a 3, a linha 690 não dever ser: ifthen( (Mensagem.Count <= 2), '8', '0' ) ao invés de: ifthen( (Mensagem.Count <= 2), '0', '8' ) ? Obrigado. cb271001.rem

Buenas... Pelo que analisei a passagem de ônibus (ida e volta) está na faixa de R$ 250,00. Distância de 400 km +- daria uns R$ 300,00 de combustível, ou seja, pouco mais de uma passagem. Não sei quanto tem de pedágio, mas creio que não seja muito. Isso sem contar que de ônibus demora bem mais. Ainda tem a questão dos horários que ficamos condicionados aos do ônibus. Mas tranquilo...Qualquer coisa me avise. Já deixei meu fone aí no post. Obrigado.

Bom dia, Gostaria de ir, mas de de avião fica inviável por causa dos valores e horários de vôos. Talvez possamos ir juntos de carro. Me add no WhatsApp 41-99709-5622. Abraços.

Sim @Juliana Tamizou, bate com o manual. Se você analisar minha segunda postagem neste tópico vai ver que anexei um print do manual onde fala sobre esse layout. Nesse print eu destaco esse campo que diz que deve ser informado '00'. Eu também tinha clientes utilizando sem erro, mas começou a ocorrer esta semana. O que reparei no arquivo remessa de alguns dias atrás (quando não dava erro) do cliente é que antes o arquivo dele não gerava o segmento S. Acho que esse segmento é opcional. Não sei porque antes não era gerado, mas no arquivo remessa do meu cliente de alguns dias atrás não tem esse segmento. Já o arquivo atual tem. Abraços.

Boa tarde, Resolvi o problema com a alteração da AcbrBancoBrasil.pas, a qual envio em anexo para possível atualização no svn. As alterações que fiz são: - Linha 690 de: ifthen( (Mensagem.Count <= 2), '00', '' ) + // 019 - 020 - Reservado (uso Banco) para: '00' + // 019 - 020 - Reservado (uso Banco) - Linha 441 de: Result := PadRight(Result, 200); para: Result := PadRight(Result, 198); Abraços. ACBrBancoBrasil.pas

Boa tarde, Não. Foi um cliente que me trouxe essa situação. Pedi para ele alterar manualmente o valor do campo 5 de 000007 para 000006 e aí o arquivo foi transmitido sem erro. Sinistro, rs... Vou tentar contato com o banco. Se conseguir alguma coisa, o que acho difícil, rs, posto aqui. Obrigado.

Boa tarde, Peço desculpas por abrir novo tópico. Sei que já tem um tópico sobre esse assunto, mas ele ficou confuso e, ao que parece, o problema estaria resolvido, mas não está, pois tenho os fontes atualizados e foi enviado o arquivo remessa ao banco no dia hoje e retornou com rejeição quanto ao contador de linha. Em anexo envio arquivos com análise do manual do banco, o print do retorno do banco com o erro e próprio arquivo remessa. Não sei, mas em princípio me parece que o Acbr está gerando corretamente o número de linhas no campo 5, ou seja, são 6 linhas dos registros e mais a linha do trailer, o que dá 7 linhas. Porém, o retorno do banco em que o arquivo é rejeitado, diz que teriam que ser 6 linhas. Alguma dica sobre o porque do erro e como resolver? Obrigado. cb181001.rem

Em uma pesquisa mais detalhada no manual do banco, verifiquei que nas posições 19 s 20 do segmento S deve ser informado '00', pois é um campo não tratado. Vide destaque no print do manual anexo. Acredito que a seguinte mudança da linha 691 da AcbrBancoBrasil.pas seria a solução: De ifthen( (Mensagem.Count <= 2), '00', '' ) + Para '00' + Obrigado.

Boa tarde, Estou tendo problemas em homologar arquivo de remessa Banco do Brasil. Em anexo estou enviando arquivo com o retorno do banco indicando que na linha 6 (Segmento S), posição 19, deveria haver um número, mas nessa posição o Acbr está iniciando as mensagens de texto de multa/juros. Verifiquei na AcbrBancoBrasil.pas (print anexo), função GerarRegistroTransacao240, parece realmente haver um erro na linha ifthen( (Mensagem.Count <= 2), '00', '' ) , pois, pelo que entendi, essa linha gera 00 para a posição 19 quando houver 2 ou menos mensagens e '' (nada) se houver mais de 2 mensagens. Como esse título tem mais de 2 mensagens, a posição 19 fica em branco (sem valor) e, com isso, a posição 19 recebe o início do textos das mensagens ("Cobrar juros,,,), quando deveria receber valor 1 ou 2, conforme inclusive está no comentário do acbr dessa linha. Estou certo nessa minha análise? Como resolver? Obrigado. cb171001.rem

Bom dia, Perfeito. Testado e aprovado. Obrigado!

Obrigado Daniel...era isso mesmo, eu tinha baixado há alguns dias e, não notei que baixei o 64 bits...Instalei o Lazarus 32 e consegui instalar o Acbr 100% sem nenhum erro. Vou me aprofundar... No dia do Acbr vou tentar ir...De toda forma, parabéns pela iniciativa. Se um dia for viável fazer aqui em Curitiba também, seria ótimo. Abraços

Boa tarde, Sempre pensei em utilizar o Lazarus. Mas nunca havia feito nada de prático nesse sentido. Depois que vi um aqui no fórum uma afirmação do @Daniel Simoesdizendo que todo o DJSystem é feito em Lazarus, aí me animei, afinal é uma indicação e tanto, rs... Muito bem, iniciei a instalação do Lazarus para fazer alguns testes e, quem sabe, passar a utilizá-lo. - Instalação do Lazarus -> Tudo ok; - Teste de alguns projetos simples -> ok; Instalação de componentes - Fortes -> ok; - Alguns do Acbr, como Boleto e outros -> 0k; - Ao iniciar a instalação dos pacotes DFe, deu erro e é aqui que gostaria de uma ajuda. - Iniciei pelo MDFe. Instalou tudo certo e fez o procedimento de reinicialização do Lazarus. Quando foi abrir novamente, deu erro pedindo a libxml2-2.dll. Copiei ela para a pasta \System do Windows. Aí passou a dar o erro anexo e não consigo sequer mais entrar no Lazarus. Se excluo a libxml2-2.dll e tento entrar no Lazarus, novamente dá o erro de falta dessa .dll e também não abre o Lazarus. 1 - Alguma dica? 2 - Alguém presta consultoria em instalação do Lazarus e migração de sistema Delphi -> Lazarus? Procurei na aba de consultorias aqui do fórum, mas não encontrei ninguém lá; 3 - Há tão pouca gente assim usando o Lazarus? Em princípio me parece um excelente opção. Porque me parece que poucos utilizam? Obrigado!

Boa noite, Tenho algumas dúvidas sobre as tags relativas às configurações de fonte para o acbrPosPrinter. 1 - Qual a diferença das tags "<c> - Liga Condensado" e "</fb> - Liga Fonte Tipo B (condensada)"? Não seriam ambas para a mesma função? 2 - Qual a diferença das tags "</fn> - Fonte Normal" e "</fa> - Liga Fonte Tipo A (normal)"? 3 - Se na impressão não for incluída nenhuma dessas tag de fontes, qual delas será utilizada como padrão pelo acbrPostPriner? Sei que poderia fazer um teste na impressão e tentar ver, mas não tenho impressora para isso no momento. Obrigado.

Boa tarde, Não sei se vai ser igual para todas as UFs, mas estamos iniciando alguns testes com NFe para CPF em MG. Nessa UF é preciso que o emitente faça um cadastro especial para poder emitir a nota. Ainda não conseguimos fazer nenhum teste porque a liberação desse cadastro não saiu. Demora alguns dias. Talvez aí na sua UF também precise desse cadastro e, por isso, esteja ocorrendo a rejeição. Abraços.

Boa tarde @José M. S. Junior, Realmente os bancos normalmente não analisam isso, até porque o que importa são os valores informados no arquivo remessa. Nesse texto não tem a menor importância no registro dos títulos. Mas esse banco/agência analisou. O problema maior é que a impressão do boleto também fica errada. Uma outra solução que talvez seja mais simples e não afete a geração do arquivo remessa seja esta abaixo: Na linha 2064 da AcbrBoleto.pas eu mudei De if DataMulta <> 0 then AStringList.Add(ACBrStr('Cobrar Multa de ' + FormatCurr('R$ #,##0.00', IfThen(MultaValorFixo, PercentualMulta, ValorDocumento*( 1+ PercentualMulta/100)-ValorDocumento)) + ' a partir de '+FormatDateTime('dd/mm/yyyy',ifthen(Vencimento = DataMulta, IncDay(DataMulta,1),DataMulta)))) Para if DataMulta <> 0 then AStringList.Add(ACBrStr('Cobrar Multa de ' + FormatCurr('R$ #,##0.00', IfThen(MultaValorFixo, PercentualMulta, ValorDocumento*( 1+ PercentualMulta/100)-ValorDocumento)) + ' após '+FormatDateTime('dd/mm/yyyy',ifthen(Vencimento = DataMulta, IncDay(DataMulta,1),DataMulta)))) Só alterado o "a partir de" por "após". Isso diminuiu alguns caracteres e resolveu o problema. Em anexo a unit alterada caso queiram aplicar essa mudança oficialmente nos fontes. Obrigado ACBrBoleto.pas

Boa tarde, Resposta SEFAZ-MS. " Devido a problemas de fornecimento de energia (pane elétrica ocorrida na região do Parque dos Poderes) alguns computadores da SGI foram afetados. Todo o esforço de reestabelecimento dos sistemas informatizados está sendo realizado, a previsão de normalização que nos foi repassada será a partir das 12:00h de hoje, 31/08/18. Os cancelamentos de NF-e estão sendo prejudicados em função de checagem em sistemas paralelos. Tão logo estes sistemas paralelos estejam normalizados, as solicitações de cancelamento de NF-e também estarão normalizadas. Informamos que todos os pedidos de cancelamento de NF-e que tenham sido solicitados dentro do período da pane elétrica serão liberados, assim que a situação esteja normalizada. Portanto, favor aguardar. Atenciosamente, Equipe NF-e" Aberaços

Boa tarde, Estou tendo problema de rejeição de homologação no Santander. A causa é um corte que o acbr acaba fazendo no texto de uma das mensagem no MontarInstrucoes2 da acbrBancoSantamder.pas. A mensagem final fica assim: "Cobrar juros de R$ 0,01 por dia de atrasCobrar Multa de R$ 0,03 a partir 23/09/2". Note que na terceira mensagem falta os 3 últimos dígitos do ano. Isso gera rejeição da homologação pelo Santander. O corte ocorre porque a function function MontarInstrucoes2: string; copia apenas 40 caracteres de cada mensagem e, como a mensagem tem mais de 40 caracteres...acaba cortando. Aumentei o tamanho do copy dessa function para 45. Unit com a correção em anexo. Não sei se é a melhor forma, mas para mim resolveu. Se possível, atualizem no svn. Obrigado. ACBrBancoSantander.pas

Bom dia, Consegui fazer um testes de remessa. Ao gerar o arquivo remessa e tentar enviar com tamanho setado em 10 no nosso número, ocorre erro (anexo) de nosso número inválido. O erro ocorre porque o DV acaba não sendo incluído e fica errado com 10 no tamanho máximo. Com tamanho 7 ele calcula tudo correto. Porém, aí no tratamento do arquivo de retorno, o valor de ACBrBoleto1.ListadeBoletos.Objects.NossoNumero acaba ficando errado porque ele lê apenas 7 dígitos, ou seja, das posições 38 a 45. Enfim, se colocar tamanho máximo 10, corrige o tratamento do retorno, mas gera erro na remessa. Se colocar 7, resolve a remessa, mas cria erro no tratamento do retorno. O que talvez pudesse ser uma solução seria mudar a linha 537 da acbrBancoBancoob.pas de "NossoNumero := Copy(Linha,38,7);" para "NossoNumero := copy(Linha,38,10);" e não deixar o tamanho máximo do nosso num em 7. Isso corrigiria o tratamento do retorno e não influenciaria diretamente na remessa pois essa linha é somente do retorno. Porém, isso geraria uma exceção na "procedure TACBrTitulo.SetNossoNumero ( const AValue: String );". Sinceramente travei. Não tenho mais ideias para acerta isso, hehe! Se alguém tiver uma sugestão... Obrigado. cb220801.rem

Só um detalhe que acho que precisaríamos analisar @José M. S. Junior. Veja o que você me diz. É o seguinte: no arquivo de retorno do banco, o título que mencionei (número 455), nosso número com 10 dígitos, ele retorna assim: "0000004551", ou seja, o "1" é o DV, correto? Com tamanho 7, esse de fato é o DV desse título. Porém, quando gero o boleto com a mudança proposta, ou seja, colocar o tamanho máximo do nosso número para 10, o ACBR gera o boleto assim: "0000004550", ou seja, com DV=0. Pela lógica isso vai dar erro na hora do banco processar o arquivo remessa, pois, se, mesmo já no novo layout (tamanho 10), o banco aceitou com DV=1, então, se enviar com DV=0, será rejeitado, entendeu? Ainda não tive como testar isso.

Não. Não tenho como testar com cnab400. Até porque o Sicoob está abolindo essa opção. Os convênios (pelo menos os novos) dessa cooperativa agora são aceitos apenas com cnab240. Obrigado.

Acredito que na ACBrBancoob.pas teriam que ser alterado as linhas: 88 - de "fpTamanhoMaximoNossoNum := 7;" para "fpTamanhoMaximoNossoNum := 10;" e 537 - de "NossoNumero := Copy(Linha,38,7);" para "NossoNumero := Copy(Linha,38,10);" Unit alterada em anexo. Obs.: não sei dizer se essa alteração, principalmente da linha 88 não vá gerar outros problemas, talvez na emissão. Estou apenas postando as alterações que fiz aqui e resolveram para a leitura do retorno. Mas acho que os moderadores devem analisar e, se for o caso, atualizar os fontes. Obrigado. ACBrBancoBancoob.pas

Bom dia, A linha 537 ACBrBancoob.pas (função procedure TACBrBancoob.LerRetorno240) está assim "NossoNumero := Copy(Linha,38,7);" Ou seja, está buscando o nosso número das posições 38 a 44. Porém, no arquivo de retorno (anexo), esse dado está vindo das posições 40 a 46. No arquivo anexo tem dois títulos baixados. Vejamos apenas o primeiro: o nosso número desse título é 0000453. A leitura retorna 0000004. Será que há algum erro no Acbr ou é o banco que mudou esse layout de retorno? Obrigado. 3180_00265012_20180820_C240_00.ret

Boa tarde, Acho que era problema de schemas desatualizados. Copiei os schemas do svn e resolveu. Obrigado.