RobertoSchuster

Bom dia, Ao atualiza o ACBr passou a ocorrer um problema ao ler o arquivo de retorno do banco Sicoob 240, pois não está identificando a conta bancária se a mesma possuir mais que 7 dígitos. Verifiquei e isso se deve à linha 504 do arquivo ACBrBancoBancoob.pas, conforme abaixo: Cedente.Conta := PadLeft(IntToStr(StrToIntDef(Cedente.Conta,0)), 7, '0'); Aqui está sendo truncando o número da conta em 7 dígitos e no meu caso a conta possui 8 (sem o dígito verificado). Antes esta linha não estava causando problemas pois ela estava mais no início do código. Portanto, no meu caso apenas alterei de 7 para 10 no PadLeft (acima de 10 ocorre exception). Cedente.Conta := PadLeft(IntToStr(StrToIntDef(Cedente.Conta,0)), 10, '0'); Na verdade não sei se essa linha é realmente necessária, pois pelo que entendi o objetivo dela seria apenas remover os zeros á esquerda. Fonte em anexo. ACBrBancoBancoob.zip

Olá José, obrigado pelo retorno. Pelo que verifiquei as correções estão OK. Novamente obrigado.

Olá José, obrigado pelo retorno. Pelo que verifiquei as correções estão OK. Novamente obrigado.

Boa tarde, alguma posição sobre as correções?

Boa tarde, alguma posição sobre as correções?

Olá José, Por gentileza, existe alguma previsão para estas alterações serem avaliadas e "comitadas"? Pergunto apenas para me agendar aqui. Obrigado.

Olá José, Por gentileza, existe alguma previsão para estas alterações serem avaliadas e "comitadas"? Pergunto apenas para me agendar aqui. Obrigado.

Boa tarde, Em processo de homologação com o Sicredi, nos foi enviado o logo atualizado. Portanto estou repassando já nas dimensões apropriadas, colorido e preto e branco. 748.bmp 748.bmp

Olá pessoal, Por gentileza, alguém consegue me explicar o motivo do seguinte código abaixo estar presente nas units do ACBrBoleto? (ACBrBancoAmazonia, ACBrBancoBradesco, ACBrBancoBrasil, ACBrBancoCaixa, ACBrBancoHSBC, ACBrUniprime) // Quando o numero documento vier em branco if Trim(NumeroDocumento) = '' then NumeroDocumento := NossoNumero; ou // prevenir quando o seunumero não vem informado no arquivo, altera para NossoNumero do banco wSeuNumero := StringReplace(SeuNumero, '0','',[rfReplaceAll]); if (AnsiSameText(wSeuNumero, EmptyStr)) then begin SeuNumero := NossoNumero; NumeroDocumento := NossoNumero end; Isso é alguma prática definida nos manuais? Toda vez eu tenho que remover estes trechos de código dos fontes porque, no meu ponto de vista, não tem sentido. São dois campos diferentes: NossoNumero é uma numeração do banco, que pode ser diferente de NumeroDocumento, o qual corresponde a uma numeração interna da empresa, justamente para ser controlada pelo ERP do jeito que cada empresa quiser. Minha sugestão é que cada um controle NumeroDocumento e SeuNumero em seu próprio ERP do jeito que preferir, quem quiser igualar o NumeroDocumento ao NossoNumero, que faça em seus próprios fontes. Do jeito que está agora, este tratamento está sendo imposto, mascarando o valor real que vem no arquivo de retorno. Sem falar que está sendo implementado em apenas algumas units. Ou seja, nem é uma prática padrão. Fontes em anexo. PS: Na unit ACBrbancoBrasil, aproveitei e substituí DataMoraJuros por DataMulta na função GerarRegistroTransacao400 (na função GerarRegistroTransacao240 já estava correto). PS: Estão indo junto as alterações que enviei no tópico Correção na Comparação de Datas (TDatetime) com Null pois ainda não foram comitadas. Concordam? ACBrBancoBrasil.pas ACBrBancoHSBC.pas ACBrBancoBancoob.pas ACBrBancoBrasil.pas ACBrBancoHSBC.pas ACBrBancoCaixa.pas ACBrUniprime.pas ACBrBancoBradesco.pas ACBrBancoAmazonia.pas ACBrBancoItau.pas ACBrBancoCecred.pas ACBrBancoCaixaSICOB.pas

Olá, aproveitei que atualizei meus fontes para repassar essas correções. Ainda existiam algumas comparações de TDateTime com Null, como por exemplo: if Data <> Null then Esta condição sempre será verdadeira pois TDateTime é float e não pode nem receber Null. Portanto, alterei as comparações para: if Data > 0 then Fontes em anexo. ACBrBancoBancoob.pas ACBrBancoItau.pas ACBrBancoCecred.pas ACBrBancoCaixaSICOB.pas ACBrBancoCaixa.pas ACBrBancoBrasil.pas ACBrBancoAmazonia.pas

Bom dia, Eu também estava com este problema e, lendo este tópico, resolvi assinando a nota antes de validar (antes apenas gerava, validava e transmitia). Contudo ficou uma dúvida: antes de saber desta solução, para testar as possibilidades eu apenas removi a chamada ao método Validar e fui direto para a transmissão da nota e transmitiu normal. Isso confere?

Olá, Segue em anexo logo do Santander atualizado em preto e branco. Foi rejeitado no processo de homologação com o atual, que inclusive não corresponde à imagem do logo colorido. Obrigado. 033.bmp

Olá, verifiquei que na revision 12732, de 26/12/2016, foi incluída a seguinte linha na unit do banco Santander, na função LerRetorno240: Vencimento := StrToDateDef(Copy(Linha, 70, 8), 0); Contudo, este código não deve obter a data corretamente pois o valor extraído vem sem as barras "/". Neste sentido sugiro o seguinte código: Vencimento := StringToDateTimeDef(Copy(Linha, 70, 2)+'/'+ Copy(Linha, 72, 2)+'/'+ Copy(Linha, 74, 4), 0, 'dd/mm/yyyy' ); PS: Não estou anexando o fonte pois tenho alterações aqui no arquivo local.

Olá Juliana, Entendo. Foi hoje para homologação, estou aguardando o resultado.

Bom dia, Fiz um pequeno ajuste na remessa 240 do Santander, pois obtive rejeição em processo de homologação. Caso Valor Mora Juros for maior que zero, Data Mora Juros não pode ser '00000000'. Portanto, neste caso defini a data do vencimento. O que acham? ACBrBancoSantander.pas

Bom dia, No campo Data da Multa (segmento R), a fim de evitar a data 30/12/1899 no arquivo de remessa, fiz um pequeno ajuste para aparecer '00000000' no lugar. Utilizei a mesma variável utilizada na Data de Mora Juros (segmento P), pois pelo que venho acompanhando Data da Multa e Data de Mora Juros são consideradas a mesma. Correto? ACBrBancoSantander.pas

Boa tarde, Realizei uma pequena melhoria nas units ACBrBancoSicredi.pas e ACBrBoleto.pas para fins preventivos, uma vez que me deparei com erros de homologação em função disso. Verifiquei que a propriedade TACBrTitulo.TipoImpressão não é explicitamente inicializada, portanto inicia com o valor tipCarne, em vez de tipNormal. Isso impacta lá na geração da remessa (CNAB 400), pois as propriedades Parcela e TotalParcelas iniciam com zero. Logo, conforme imagem abaixo, Número de Parcelas não deve ser zero se Tipo de Impressão for carnê (B) e deve ser zero (ou em branco) se Tipo de Impressão for normal (A). ACBrBoleto.pas ACBrBancoSicredi.pas

Segue anexo. BoletoTeste.pdf

Bom dia, Verifiquei que somente o nome do Sacador/Avalista está sendo exibido nos boletos (FortesReport) e não encontrei nenhum tópico falando a respeito. Portanto, realizei uma pequena adaptação na disposição das informações do Pagador, a fim de permitir que os dados de endereço do Sacador/Avalista sejam exibidos também, mantendo o mesmo espaço. Segue em anexo para análise e, se possível, commit. ACBrBoletoFCFortesFr.pas ACBrBoletoFCFortesFr.dfm

Olá Juliana, Te agradeço pela ajuda. Não realizei nenhuma alteração inicialmente justamente porque esta parte é bem delicada mesmo, envolvendo outros manuais e afetando todos os outros tipos de convênio.

Olá Juliana, obrigado pelo retorno. Entendo, porém o estranho é que meu cliente já utilizava estas configurações em outro software e estava emitindo boletos sem registro (carteira 18), com o nosso número no formato que mencionei. Encontrei algo no manual em anexo, pág 8: Banco do Brasil - Particularidades CNAB 240.pdf

Olá, Estou enfrentando problemas para gerar boletos do Bando do Brasil, utilizando carteira 18 e convênio de 6 posições. À primeira vista, o NossoNumero está sendo gerado com 17 dígitos em vez de 11. NossoNumero (nº sequencial): 1 Convênio: 123456 NossoNumero completo esperado: '12345600001' (11 dígitos) NossoNumero completo obtido: '00000000000000001' (17 dígitos) Passos para reprodução do problema: 1. Criar um Titulo na lista (Titulo := ACBrBoleto.CriarTituloNaLista) 2. Popular os dados do boleto, sendo que Titulo.NossoNumero recebe o número sequencial (Titulo.NossoNumero := '1') Neste momento ocorre: a. Chamada à função SetNossoNumero() b. SetNossoNumero() chama CalcularTamMaximoNossoNumero('18', '1') c. CalcularTamMaximoNossoNumero('18', '1') resulta em 11 dígitos d. Então Titulo.NossoNumero (fNossoNumero) recebe '00000000001' 3. Exibir o boleto (ACBrBoleto.Imprimir) Neste momento ocorre: a. Chamada à função MontarCampoNossoNumero(Titulo) // Aqui Titulo.NossoNumero ainda é igual a '00000000001' b. MontarCampoNossoNumero(Titulo) chama FormataNossoNumero(Titulo) // Aqui Titulo.NossoNumero ainda é igual a '00000000001' c. FormataNossoNumero(Titulo) chama CalcularTamMaximoNossoNumero('18', '00000000001') d. CalcularTamMaximoNossoNumero('18', '00000000001') resulta em 17 dígitos, pois entra no primeiro if e. Então FormataNossoNumero(Titulo) resulta em '00000000000000001', com 17 dígitos f. A partir daí o nosso número passa a ter 17 dígitos.... Será que estou preenchendo de forma incorreta as propriedades ou preenchendo em uma ordem incorreta? Obrigado.

Entendo perfeitamente @Juliomar Marchetti. Falha minha.

Bom dia pessoal, agradeço pela atenção ao post. Pelo que entendi, acredito que o @Roberto Borchardt esteja com um problema similar ao meu. Estou na revision 10745, de 28 de dezembro de 2015, verifiquei várias vezes no log do SVN e não encontrei nenhum commit que me chamasse a atenção sobre este problema. Logo, só terei como confirmar se o problema persiste quando eu atualizar o ACBr, na semana que vem. O que posso afirmar é que por enquanto isso acontece (não sei se ocorria antes pois eu usava o Rave).

Bom dia, Hoje assisti ao novo vídeo da Tecnospeed, que fala sobre a partilha do ICMS e principalmente sobre a diferença no preenchimento das tags quando a empresa for do Simples Nacional. Pelo que entendi, a única diferença é que a tag vICMSUFRemet fica zerada, conforme destacado na imagem abaixo. No entanto, independente desta peculiaridade do Simples, fui refazer o cálculo todo para confirmar se os outros valores fechariam. E não fecharam. Eis a dúvida: até então, para obter o DIFAL eu faria 19% - 12% = 7%, que seria aplicado à base de cálculo: R$ 1000,00 x 7% = R$ 70,00. Então 40% destes R$ 70,00 iriam para a UF de destino e 60% para a UF de origem (zerado quando for Simples Nacional). E 40% de R$ 70,00 corresponde a R$ 28,00 e não os R$ 20,00 preenchidos no exemplo da Tecnospeed. Pelo que pude perceber, apesar de terem preenchido 19% na tag pICMSUFDest, a partilha foi realizada utilizando 17%, ficando: 17% - 12% = 5%, que aplicado à base de calculo fica: R$ 1000,00 x 5% = R$ 50,00. Então 40% de R$ 50,00 são os R$ 20,00 que aparecem na imagem abaixo. O que vocês acham? Abaixo segue o print do vídeo da Tecnospeed: