Thiago Linhares

Boa tarde pessoal, Temos acredito 3 colegas que já homologaram a geração de boletos/Remessas do "exotérico" Sicoob usando Correspondente Banco do Brasil! Eu tb tenho que fazer esta integração. Logo que puderem, por favor postem suas units neste tópico para contribuir com o projeto, se possível. Podemos ver vários colegas que gostariam de usar a solução montada por vcs. Qq problema para postar os arquivos avisem que tenho certeza que os moderadores resolvem! Espero que vá um emailzinho para cada um alertando sobre este post . Uma vez que cada um poste suas units podemos analisar as mesmas e propor uma solução oficial para o problema. Sei que depois que homologamos tendemos a deixar de lado, mas qto mais contribuirmos mais o nível do projeto como um todo aumenta e mais forte ele fica... qto antes responderem melhor! Grande abraço!

Em tempo, a chama de CalcularTamMaximoNossoNumero no TACBrCaixaEconomicaSICOB.FormataNossoNumero não faz nada... ficou estranho, teria que ser retirada.

Boa tarde Juliana, a função TACBrCaixaEconomicaSICOB.CalcularTamMaximoNossoNumero ainda está incorreta, pelo menos de acordo com a lógica que parece que foi pensada no código fonte dela. Na lógica, ao invés de setar o Result, está sendo setado uma variável local wTamNossoNumero, que não é usada para nada. Creio que não precisa enviar a unit, pois está bem evidente ali na função. O impacto disto seria talvez sobre as lógicas de leitura do retorno de remessa... que é onde o CalcularTamMaximoNossoNumero é usado, além do SetNossoNumero. Mas como não estou usando retorno de remessa agora, não testei o retorno para ver o que daria errado... acredito que daria, já que está inconsistente... mas vai saber se o retorno tem formatações diferentes. Mas de qq forma, o código da função atual CalcularTamMaximoNossoNumero não faz sentido. Agora, Outro ponto, que ai realmente me afeta, é sobre forçar que sempre seja usado o padrão de 16 posições no nosso número quando a carteira for SR (sem registro) e operação do convênio for 870 (é SICOB tb). Eu tenho um caso desse que estou implementando agora para homologação, e o banco enviou documentação para uso de 11 dígitos do nosso número, não 16! Sei que tem um outro manual (que o banco não enviou, mas este enviado é mais novo acredito) que se refere a operação 870 para carteira SR usando nosso nr de 16 posições... mas o fato do banco ter solicitado no meu caso o de 11 posições, cria a dúvida de que esta regra não é uma regra, e sim uma opção talvez. Alguém sabe se clientes do banco que tenham SR e 870 talvez possam escolher usar um ou outro layout? Será que mesmo se o banco pedindo 11 posições, enviar o de 16, eles aceitam? Alguém teve um caso similar ou tem alguma info sobre isto? Por fim, sobre a abordagem de obrigar a setar o nosso número fora do componente, sou contra, pois vai contra as boas práticas de encapsulamento e coesão. Hoje para não desencapsular uma pá de regras de bancos, eu seto o NossoNumero com o mesmo valor do NumeroDocumento, cuidando para que ele não estoure o tamanho máximo... e o ACBr faz o resto.. não preciso colocar regras de formatação de nosso número pela aplicação. Mas devido a forma como o ACBr está implementado... essa abordagem ainda fica estranha, pois não foi feito com esta estratégia em mente. Entendo que a melhor abordagem é a de encapsulamento... onde propriedades como NumeroDocumento, que hoje fazendo um search são usadas somente para geração de remessas, seriam usadas internamente para montar o Nosso Número "final". Preocupações para construção do NossoNumero deveriam ficar todas encapsuladas dentro das classes. E surgindo casos como o do 870 com SR acima, são tratáveis de uma forma ou de outra, sem precisar desencapsular. Por exemplo.. o antigo GBBoleto usava uma diferenciação na carteira para decidir se gerava com 11 dígitos ou 16 dígitos, bastando passar a carteira pra ele como "SR" ou "SR16" respectivamente (não que esse devesse ser uma solução para o ACBr, mas é uma ideia interessante se for preciso). Inclusive esta abordagem do GBBoleto me chamou a atenção para o meu caso onde usar a especificação de 11 ou 16 dígitos talvez seja uma escolha do cliente ou do próprio banco, sendo impossível "calcular" (é só uma suposição... infos please! )... o GBBoleto suportava esta escolha. Enviando o manual atualizado que o banco mandou, para referência se necessário. Abraços! Leiaute_Boleto_Caixa.dot

Olá, estou ciente obrigado, eu uso bastante o changelog, principalmente qdo fazemos o merge de volta para a versão que usamos aqui pra ver se não vai quebrar nada, mas no dia a dia não é muito produtivo ficar checando. É que pelo seu comentário deu a entender que não teria ido. De qq forma olhei rapidinho agora e não achei pelos comentários. Se foi em algum commit relacionado saberei no nosso próximo merge :-) Aproveitando pra corrigir um texto no meu último post... "uma gambiarra como o próprio dev3" faltou o "disse" no final, "uma gambiarra como o próprio dev3 disse" Abraço

Boa tarde, Para retorno, informo que o banco tb homologou com as alterações do meu último post faz várias semanas já. Só demorou o retorno mesmo. Juliana, Não vi novamente o que foi comitado desde então (caso tenha incluído, pode ignorar o texto abaixo :-)), mas sobre não ter que alterar nada para no componente, que foi a abordagem usada pelo dev3, mesmo que não tenha precisado alterar nada pra "funcionar", não quer dizer que a solução que ele usou está correto conceitualmente ou fácil de manter. Considero tal abordagem como quebra de encapsulamento, e baixa coesão da lógica, um workaround (uma gambiarra como o próprio dev3). Usamos um componente justamente para não termos que nos preocupar com IFs e detalhes específicos de cada banco em nossas apps, apesar de ajudar muito, acabamos tendo várias situações específicas para tratar e força desenvolvedores a se debruçarem sobre manuais e especificações técnicas de coisas que não precisariam. Acredito que ele só usou assim devido a não querer fazer as alterações no componente por insegurança que ele expressou no post dele. Eu validei certinho as minhas alterações em relação ao resto do código (única exceção, importante mencionar, não validei o retorno pq não estou usando agora, talvez questões que o sysbase levantou acima, mas não tem porque ter que alterar a abordagem que sugeri devido a isto, talvez algum ajuste na lógica do retorno se fosse o caso). Gostaria tb que minhas alterações fossem incluídas, e idealmente que a estratégia de tentar encapsular mais tal tipo de lógica seja aplicada em outros pontos/bancos tb, pelo que entendi foi a opinião do dev3 tb. A única coisa que tem tem cuidar é sobre a compatibilidade com gambiarras feitas... pois enquanto não está encapsulado o pessoal vai fazendo gambiarra e ai fica-se com receio de melhorar o componente porque isto quebraria as gambiarras feitas. Minha sugestão qdo tivesse algo assim é um texto no commit com um "ALERTA/IMPORTANTE: QUEBRA COMPATIBILIDADE" grande em caixa alta, mas qto mais tempo segurar melhorias como essa maior débito técnico estamos adquirindo, que sabemos que pagamos com juros mais para frente. É a minha opinião sobre esta questão, espero poder continuarmos ajudando a melhorar o componente. Obrigado pela atenção.

Olá dev3 e Juliana, mil perdões... realmente movi para o fórum o arquivo errado (estava com 2 Explorer abertos e peguei do errado por engano), não tem nele nenhuma modificação nossa. Segue o arquivo correto do Sicredi. Envio junto tb o ACBrBoleto.pas, mas a princípio para o assunto que estamos falando as alterações foram somente no ACBrBoletoSicredi.pas mesmo. Ainda não tive retorno se homologou ou não... mas normalmente quando o retorno demora é que homologou... quando encrenca a coisa volta rápido. Mas não tenho uma confirmação oficial ainda. Uma possibilidade de não homologar conhecida por mim é a pela Logo colorida, que no manual diz que não é pra usar... mas até agora o Sicredi não comentou nada sobre ela, por hora estou deixando rolar. A planília que eu usei recebi de um funcionário da área de boletos do Sicredi... o meu arquivo é mais novo que o do dev3, mas tb eh bem menor. De qq forma passou na planília que usei. Não testei com esta outra. Segue a planília que usei tb em anexo se quiserem usar. Abraço! ACBrBancoSicredi.pas ACBrBoleto.pas Planilia Usada pelo Sicredi para Analise__Analise_boletos_UA61.zip

Boa noite, Postei antes que as remessas haviam sido aprovadas, realmente foram... porém recebi agora que o banco rejeitou o Boleto em si (não a remessa) devido ao NossoNumero incorreto e decorrentes cálculos de DVs. Eu já corrigi e passou no teste da Planília exel que o Sicredi usa pra validar linha digitável. Entendo que existe um erro conceitual na forma como está implementado no Sicredi o método que gera o Cod de Barras. Enquanto em units como o Banco do Brasil, ao gerar o cod de barra o Nosso Numero é calculado usando a propriedade FNossoNumero como parte do cálculo e não sendo o nosso número já todo, no Sicredi ele está usando a FNossoNumero existente setado em algum lugar do além com a formatação que o banco espera, abordagem que eu não concordo postada aqui por exemplo: http://www.projetoacbr.com.br/forum/topic/22175-mudança-de-montagem-do-nosso-número-banco-sicredi/?page=2#comment-152525 Eu acredito que o objetivo de usar o componente seja de encapsular as especificidades para que de fora do componente não tenhamos que nos preocupar com detalhezinhos de cada banco. Quanto mais encapsulado, melhor. Além claro, da consistência de abordagem de uso entre os bancos (como do BB que eu citei), que é algo crítico. Este erro passou a acontecer depois que a propriedade NossoNumero deixou de ser setada magicamente no método onde monta o nosso número (o que reforço que é mil x mais claro e bom, mas gerou esse bug extra além dos outros que foram corrigidos nos posts acima). Caso possível enviarei o resultado da homologação aqui. Segue a unit alterada... desculpem mas é no trunk ainda pois devido ao nr de correções que temos ainda não conseguimos migrar. Porém a correção é muito simples, é 1 linha no método que gera o cod de barras... está comentado com Modula Changes no local. CUIDADO: usar esta correção irá dar mais consistência de uso para os vários bancos. Porém acredito (não validei, pois não usaremos a abordagem que consideramos conceitualmente incorreta e complicante) que irá quebrar para quem usa a abordagem como a que está no post que eu comentei acima. Abraço! ACBrBancoSicredi.pas

Olá, para ciência, informo que a remessa CNAB400 foi homologada pelo banco com as units que eu enviei acima. Reforçando, as units são do Trunk porque não podemos ainda migrar para o Trunk2, mas já vi o código do Trunk2 destas units e o merge é bem simples. Abraço

Olá, Dei uma olhada nos manuais do BB e tb no padrão da febraban: http://www.febraban.org.br/7Rof7SWg6qmyvwJcFwF7I0aSDf9jyV/sitefebraban/subcpadr15-layout padrao V 09 00 - 02.03.pdf Não diz nada sobre acentuação ou símbolos especiais. Podemos inferir que seja ANSI, mas quais caracteres aceitos não achei documentação, a não ser da própria Sicredi conforme documento postado. Se tiver algum documento que fale sobre isso quem puder poste por favor. Portanto, alterei os fontes não para usar um bloco genérico, e sim bem específico para o Sicredi, pois lá eles comentam quais símbolos são aceitos (não pode um ">" por exemplo), não me pareceu algo tão genérico a ponto de botar em uma função global alterando todos os caracteres do arquivo de remessa gerado. Geralmente eu não gosto de executar lógicas que deixam alguma potencial ponta solta de robustez. Acabei convertendo os valores de acordo com a formatação das remessas do Sicredi, sendo algo de formatação, assim como os zeros a esquerda ou a direita.. por alta coesão tais blocos ficam juntos na geração do arquivo, o que faz sentido. Tem um TODO lá para mover os blocos genéricos para uma unit mais genérica, quem for comitar poderia simplesmente mover tranquilamente. As alterações para o Sicredi eu postei junto com outras, no post http://www.projetoacbr.com.br/forum/topic/14139-problema-no-calculo-do-dígito-verificador-do-nosso-número-sicredi/#comment-156857 Testado no validador online, passou. Abraço!

Olá Juliana, Como não estou no trunk2 ainda não enviei, por serem poucas linhas. Segue o arquivo do trunk. Todas as alterações são comentadas com MODULA CHANGES para o nosso controle aqui até que tenhamos o merge de volta feito. Fica fácil de vc achar as alterações simplesmente procurando por MODULA no arquivo... todas elas são comentadas. Vc vai achar mais alterações além das que são pertinentes deste post. Tem correção/proteção contra caracteres acentuados e símbolos também (relacionado a outro post http://www.projetoacbr.com.br/forum/topic/7184-arquivo-remessa-banco-brasil/#comment-156781) e mais algumas correções mais antigas que não havíamos postado de volta ainda por falta de tempo... se for o caso de incluí-las também melhor ainda. Testei hoje com o validador online do Sicredi tanto o CNAB400 como o 240 e passou, e estará em processo de homologação com o cliente em breve. Qq ponto estou a disposição. Obrigado. ACBrBancoSicredi.pas

Olá, estou homologando as remessas do Sicredi, e também precisei fazer esta alteração mencionada pelo bhungaro. Basicamente é seguir a mesma abordagem que foi feita no CNAB400, onde deve ser chamada a função MontarNossoNumero, que agora felizmente não mais altera o NossoNumero internamente (está infinitamente melhor assim... se é uma função realmente deveria somente retornar um valor calculado, e não alterar propriedades magicamente por baixo... mas ainda tem outros casos similares e perigosos, coisa pra outros esforços)... assim devemos usar o resultado da função como o bhungaro mencionou, implementação similar do CNAB400 que já foi feita como comentei. Com esta mudança... nos caracteres 038 a 057 basta usar o valor calculado, não mais somando o dig verificador como está, pois está duplicado já que a função MontarCampoNossoNumero já tem ele. Acabei de passar pelo validador com estas mudanças, e passou (tirando o problema abaixo). Só achei mais um outro problema ainda de acentuação, pois não é permitido... isto postei no tópico: http://www.projetoacbr.com.br/forum/topic/7184-arquivo-remessa-banco-brasil/#comment-156781 Porém sobre o cálculo do DígitoVerificador, não tive problemas... revisei logicamente a função e não achei problemas. No DV da agência vai o Posto/UA que são 2 dígitos... sem problemas identificados.

Olá, estou homologando a remessa do Sicredi (tanto CNAB400 como 240) e pela documentação atual (por exemplo: https://www.sicredi.com.br/html/para-voce/recebimentos/cobranca/arquivos/manual_beneficiario_cobranca_cnab_240.4.pdf) eles tb não aceitam acentuação, e passam tudo para caixa alta de qq forma. A correção é pertinente portanto, certamente para o Sicredi, mas eu não confirmei na documentação do Banco do Brasil, mas creio que o amigo tenha conferido. Boas chances de que isto exista para vários outros bancos tb. A princípio, entendo que isto é algo específico para a remessa, não para a geração dos Boletos, então tal bloco na camada de remessas parece correto. Estarei fazendo isto somente para o Sicredi por hora, e posteriormente para outros bancos na medida que for identificando. A propriedade ajuda bastante neste caso. Seria legal temos a correção no ACBr.

Olá webjoel, Aproveitando para alertar, os arquivos postados estão errados, não compila. O nr de elementos no array é 179 mas vc baixou o nr na declaração dele para 178. Eu estava vendo uma questão no Sicred e esbarrei neste post... então não validei o restante da lógica pois não estou usando no momento. Abraço!

Pessoal, retornando com o feedback da nossa revisão das URLs aqui na Módula... revisamos todas as URLs, tanto de NFe como de NFCe, e atualmente todas estão corretas já de acordo com as novas mudanças do RS. Com exceção do Piauí que não foi encontrada uma referência oficial das URLs para NFCe. O restante tudo em ordem, incluindo o Pará. Entendo ser alguma outra coisa ai tchuck. No momento não vamos alterar nada extra aqui, mas não temos clientes com NFCe no Pará ainda. O que podemos fazer é reportar que nos nossos testes em geral não acusaram erros, mas realmente não testamos para o Pará.

Olá, tchuck, tem certeza de que vc não está configurando o componente para acessar o ambiente errado? Vendo o post do BigWings ele comentou que teve uma resposta correta lah, e ao alterar para SVC deu o mesmo erro que vc teve... "alterar para SVC" no caso dele acredito que não tenha sido alteração nos fontes onde monta as URLs, mas sim configurar o componente. Talvez vc ainda não tenha encontrado o problema raiz, que parece estar mais na linha da configuração do componente. Aqui na empresa estamos neste momento validando todas as URLs fazendo merge desta parte, daqui a pouco dou um retorno se achar alguma URL incorreta, até o momento nenhuma no trunk do ACBr.