fernandoschulz

Bom dia, Só para fins informativos, também tive problemas com o código de barras e linha digitável ao utilizar o cnab 240 do banco Safra do repositório, e utilizando a correção efetuada pelo João os boletos homologaram corretamente. att, Fernando Schulz.

Bom dia, O erro de retorno "C2 - Aceite do título inválido" do banco Sicredi CNAB 400 não está tratado no Acbr e está acusando o erro "'C2' is not a value integer value". Tratei o C2 e aproveitei e coloquei o tratamento para os erros C1 e C3 que vi no manual e não estavam na unit também, segue unit em anexo. Obs: Atualizei o componente de boleto agora a pouco antes de efetuar as alterações. Obrigado, Fernando Schulz. ACBrBancoSicredi.pas

Boa tarde @Italo Jurisato Junior Acompanhei uns dias o fórum e percebi que vocês fizeram algumas modificações após outros usuários reportarem erro na assinatura do xml de cancelamento, enfim, resolvi fazer um update e testar em Joinville pra ver se já estava funcionando, porém, ocorreu um erro novamente, mas dessa vez o erro era diferente, o acbr nem tentou enviar o xml pra prefeitura, o erro é o seguinte: Na Unit ACBrDFeXsMsXmlCapicom na parte onde faz a assinatura do xml: // Inserindo Template da Assinatura digital // if (not XmlEstaAssinado(AXml)) or (vSignatureNode <> CSIGNATURE_NODE) then AXml := AdicionarSignatureElement(AXml, False, docElement, IdSignature, IdAttr); Após ele assinar o xml por essa função acima ele perdia a tag de fechamento do xml, ficava dessa forma: <CancelarNfseEnvio xmlns="http://nfews.joinville.sc.gov.br"><Pedido>[...]</Pedido> Ou seja, como podes reparar acima ele não inseria a tag de fechamento </CancelarNfseEnvio> e dava erro na função logo abaixo dizendo que não conseguiu carregar o xml. Eu alterei a Unit ACBrNFSeWebServices na parte onde é inserido o DocElement do XML conforme o servidor, ISSJoinville estava setado para ser como: FdocElemento := FPrefixo3 + 'Pedido'; E eu alterei para ficar igual aos servidores BHISS, Betha e SystemPro: proBHISS, // proPublica, proBethav2, proSystemPro, proISSJoinville: FdocElemento := FPrefixo3 + 'Pedido></' + FTagGrupo; Após efetuar essa alteração assinou o xml corretamente e enviou a prefeitura sem problemas, conforme verifiquei no portal cancelou a nota na prefeitura. Não sei se muda algo nessa parte, mas no caso de Joinville eu teria que ter setado alguma outra configuração pra funcionar sem fazer essas alterações? Minhas configurações de certificado que utilizo em todos os servidores que tenho implementado estão da seguinte forma: ACBrNFSe1.Configuracoes.Geral.SSLCryptLib := cryCapicom; ACBrNFSe1.Configuracoes.Geral.SSLHttpLib := httpIndy; ACBrNFSe1.Configuracoes.Geral.SSLLib := libCapicom; ACBrNFSe1.Configuracoes.Geral.SSLXmlSignLib := xsMsXmlCapicom; Caso não e as alterações que fiz estão corretas, coloquei a Unit alterada em anexo. Agradeço a atenção, Fernando Schulz. ACBrNFSeWebServices.pas

Ah entendi, dei azar que peguei o erro bem quando estava implementando uma nova cidade e acabei achando que era algo que eu estava fazendo errado, enfim, agradeço a resposta e fico no aguardo. Obrigado, Fernando Schulz.

Boa tarde pessoal, Possuo a nfs-e de diversas cidades implementadas e funcionando com o acbr a um bom tempo, porém, a tentar implementar a cidade de Joinville/SC, no serviço de cancelamento da nfs-e sempre me retorna o erro "CheckSignature, arquivo editado apos a assinatura", já tentei debugar comparando o xml antes e depois da assinatura, mudar diversas opções, utilizei o demo do acbr, tentei enviar o xml pelo SoapUI e em todos acontece o mesmo problema, passei o xml em um validador e me retorna que a assinatura realmente está com problema, dessa forma, imagino que seja alguma configuração que estou usando errado pois o envio do lote e consulta de lote e rps consegui implementar sem problemas para esse município, e pelo que vi no Fórum alguns colegas já utilizam essa nfs-e de Joinville pelo acbr e ninguém relatou algo parecido. Alguém já teve um problema semelhante que possa me dar uma dica/ajuda? Obs: Todos os fontes estão atualizados. Agradeço a atenção, Fernando Schulz.

Boa tarde, Ao importar um retorno no Sicredi ocorreu o seguinte erro: "'S4' is not a valid integer value". O problema são duas novas ocorrências de Tarifa no retorno que não estão tratadas no componente ACBR. Efetuei o download do manual atualizado do CNAB 400 do Sicredi e as ocorrências não implementadas no acbr que constam na página 18 do manual são: Antes de efetuar as alterações fiz um update no componente, porém, ainda não estavam implementadas, sendo assim implementei e anexei o fonte atualizado para serem atualizados no ACBR. O manual atualizado não consegui anexar por ser maior que 2MB, então segue link: https://www.sicredi.com.br/html/para-sua-empresa/recebimentos/cobranca/arquivos/manual-cnab-400---2018-v1.pdf Alterações: Antigo: toRetornoDebitoTarifas: //28 case AnsiIndexStr(CodMotivo,['A9', 'B1', 'B2', 'B3', 'E1', 'F5']) of 0: Result:= 'A9-Tarifa de manutenção de título vencido'; 1: Result:= 'B1-Tarifa de baixa da carteira'; 2: Result:= 'B2-Não implementado'; 3: Result:= 'B3-Tarifa de registro de entrada do título'; 4: Result:= 'E1-Não implementado'; 5: Result:= 'F5-Tarifa de entrada na rede SICREDI'; else case StrToInt(CodMotivo) of 03 : Result:= '03-Tarifa de sustação'; 04 : Result:= '04-Tarifa de protesto'; 08 : Result:= '08-Tarifa de custas de protesto'; else Result:= PadLeft(CodMotivo,2,'0') +' - Outros Motivos'; end; end; Novo: toRetornoDebitoTarifas: //28 case AnsiIndexStr(CodMotivo,['A9', 'B1', 'B2', 'B3', 'E1', 'F5', 'S4', 'S5']) of 0: Result:= 'A9-Tarifa de manutenção de título vencido'; 1: Result:= 'B1-Tarifa de baixa da carteira'; 2: Result:= 'B2-Não implementado'; 3: Result:= 'B3-Tarifa de registro de entrada do título'; 4: Result:= 'E1-Não implementado'; 5: Result:= 'F5-Tarifa de entrada na rede SICREDI'; 6: Result:= 'S4-Tarifa de inclusão negativação'; 7: Result:= 'S5-Tarifa de exclusão negativação'; else case StrToInt(CodMotivo) of 03 : Result:= '03-Tarifa de sustação'; 04 : Result:= '04-Tarifa de protesto'; 08 : Result:= '08-Tarifa de custas de protesto'; else Result:= PadLeft(CodMotivo,2,'0') +' - Outros Motivos'; end; end; Agradeço a atenção, Fernando Schulz. ACBrBancoSicredi.pas

Qual o banco? Eu não vou lembrar qual é o banco agora, mas tem um que quando a remessa cnab240 não é aceita, na posição 143 do retorno que deveria voltar "2", ele volta "5" e o acbr diz que não é o layout certo, mas na verdade é só porque a remessa não foi aceita. Na Unit ACBRBoleto tem esse código aqui que da o erro, ali no if volta '5' e ele diz que o layout ta errado: 240 : begin if Copy(SlRetorno.Strings[0],143,1) <> '2' then Raise Exception.Create( ACBrStr( NomeArq + sLineBreak + 'Não é um arquivo de Retorno de cobrança com layout CNAB240') ); BancoRetorno := Copy(SlRetorno.Strings[0],0,3); LayoutRemessa := c240 ; end; Tem até um outro tópico que fala sobre isso, da uma olhada se não pode ser isso seu problema.

Bom dia, Precisei implementar a propriedade CodigoMora na Unit do Banco do Brasil CNAB 240. Atualmente a programação só contemplava o código mora = 1 (Valor Diário) e 3 (Isento), conforme programação abaixo: IfThen(ValorMoraJuros > 0, '1', '3') + // 118 - Código de juros de mora: Valor por dia Conforme manual do banco do brasil existe o código 2 (Taxa Mensal) também, segue abaixo: Em anexo Unit com alterações, fiz update no acbr boleto hoje de manhã antes de efetuar as alterações. Obs: Fiz uma programação no início da função que gera o registro de transação 240 que, caso alguém não trabalhe com a propriedade CodigoMora, as alterações que fiz não irão dar problema para essa pessoa: {Código Mora} if CodigoMora = '' then begin if ValorMoraJuros > 0 then CodigoMora := '1' else CodigoMora := '3'; end; Obrigado, Fernando Schulz. ACBrBancoBrasil.pas Esqueci de falar, já mandei remessa para o banco e está tudo certo, banco aceitou normal, e impressões pelo banco e componente ficaram corretas

Boa tarde @Juliana Tamizou, Então, na verdade isso foi uma especulação minha que pode vir a ter mais tipos de retornos nesse código 48 pela descrição que aparenta ser bem ampla dele, mas, até então, foi a primeira vez que peguei esse código e foi apenas com antecipações, pode inclusive, ter antecipações que venham com outro código, mas no manual do sicoob não tem nenhuma ocorrência que deixa clara ser uma antecipação, dessa forma, acabamos descobrindo quando pegamos uma situação assim nos retornos dos clientes. Referente ao porque eu tratei e não deixei como OutrasOcorrencias, é porque quando é antecipação eu preciso ter como identificar isso e tratar no meu sistema, e como OutrasOcorrencias eu não consigo fazer isso, no relatório de retornos que faço para o cliente se eu deixar só como OutrasOcorrencias acaba gerando muitas ligações de suporte porque o cliente não sabe o que isso significa, porque pode voltar qualquer coisa ali que não esteja tratado. Vale ressaltar também, que no caso de antecipações a data de crédito vem zerada, então eu usei o código 48 pra isso também, não tentar usar uma data zerada. Enfim, só por questões de tratamentos mesmo, saber o que fazer com o financeiro desse boleto. Obrigado, Fernando Schulz.

Resolveu usando as minhas alterações Cleonir, ou fez alguma coisa diferente? Bom dia @Juliana Tamizou, tem como colocar essas alterações no svn, ou queres que eu faça algo diferente? Obrigado. att, Fernando Schulz.

Perdão, não tinha vindo a imagem antes.. Cara, uma dica, entra na unit do Bancoob dentro da pasta fontes > Boleto no trunk2 do acbr e procura as propriedades conforme o número da posição inicial, ta tudo comentado lá, fica bem fácil achar o que vc precisa. as propriedade são: CodigoMora, ValorMoraJuros, DataMoraJuros, DataDesconto, ValorDesconto Vale ressaltar que isso aí são propriedades que tens que combinar com o banco, a taxa de juros e etc.. Esse esquema do desconto é outra regra combinada com o cliente e banco, por exemplo, o cara quer dar um desconto de 10% no boleto caso ele seja pago antes da data limite de desconto, aí vc informa essas propriedades.

ACBrBoleto1.LayoutRemessa := IIF(Pos('c240', IBQBancoDS_LAYOUT.AsString) > 0, c240, c400);

Não tenho essas propriedades preenchidas, isso é algo mais específico que as vezes o banco pede, mas até o momento nunca usei

Tenta colocar na propriedade Cedente.CodigoCedente := 202789

Se eu não me engano já tive problemas com código do cedente nos bancos, que uns usam o dígito verificador e outros não, mas posso estar te falando mentira.. chegou a tentar informar com e sem pra ver se muda algo? Outra coisa, o Sicoob tem um arquivo em excel onde ele calcula o dígito verificador pra ti, pede pra ela te passar esse excel preenchido com as informações que ela diz q ta errado pra ti comparar. Vou botar o que tenho aqui em anexo pra ti dar uma olhada. Calculo DV Nosso Numero.xlsx

Gera sim Eleandro, Abre a Unit "Bancoob" e procure pela função "MontarCampoNossoNumero", vai ver que ali dentro tem a função "CalcularDigitoVerificador", só botar breakpoint nessa função aí que vc acha o seu problema com certeza. Como o Dercide disse, tem que informar a agencia e código do cedente corretos para esse cálculo.

Boa tarde, Tenho um cliente que trabalha muito com antecipação de boletos e acabei tendo um problema com isso por faltar tratamento no Acbr da ocorrência que volta do banco. Nesses boletos antecipados, a ocorrência volta como "48 - Confirmação de instrução de transferência de carteira/modalidade de cobrança", e ao revisar o fonte do Sicoob vi que não tem tratamento para essa ocorrência na função "CodOcorrenciaToTipo", dessa forma, ele colocava o tipo como "toRetornoOutrasOcorrencias" Modificações que fiz: 1 - Criei um novo tipo na Unit "AcbrBoleto" chamada "toRetornoConfInstrucaoTransferenciaCarteiraModalidadeCobranca". Obs: Como eu achei bem ampla a descrição dessa ocorrência "48" do banco sicoob aparentando inclusive ser utilizada para outras coisas além de antecipações, decidi criar um nome bem parecido com o do próprio banco ao invés de criar algo relacionado apenas a antecipações. Se acharem que está incorreto dessa forma, ou se já tem algo parecido posso alterar para outro nome sem problemas, eu procurei e não consegui achar nenhum tipo já criado que me servia. 2 - Coloquei esse novo tipo na função dentro da unit do sicoob. 48: Result := toRetornoConfInstrucaoTransferenciaCarteiraModalidadeCobranca; Segue em anexo as duas unit's alteradas, atualizei-as hoje antes de efetuar as modificações. Agradeço a atenção, Fernando Schulz. ACBrBoleto.pas ACBrBancoBancoob.pas

Bom dia @Italo Jurisato Junior A cidade de Rio do Sul/SC consta no cidades.ini como Betha ainda, mas eles mudaram para IPM em 2012. Para mudar ela pra IPM, basta apenas mudar no cidades.ini de Provedor=Betha para Provedor=IPM e testar, ou teria que fazer algo mais? Agradeço a atenção, Fernando Schulz.

Bom dia @marcos.serafim A Betha te deu algum retorno? ainda estou com problemas no cancelamento. Agradeço a atenção, Fernando Schulz.

Boa tarde @José M. S. Junior Agradeço a atenção, irei aguardar as alterações no svn para realizar os testes. Obrigado, Fernando Schulz.

Boa tarde @Juliomar Marchetti Preciso homologar um cliente com a opção "2" (dias úteis) na posição 221 (tipo de protesto), e isso até foi programado já por você mesmo na revisão 13287 do dia 09/05/2017, porém, usando a opção 2, a variável "DiasProtesto" fica errada, pois ela usa a função DaysBetween entre a data de protesto e vencimento. Exemplo: se o nr. de dias de protesto for 7 dias úteis por exemplo, e no meio tiver um final de semana, o componente já calculou o vencimento levando em consideração apenas os dias úteis lá na função "AtualizaDatasProtesto", dessa forma, usando o DaysBetween a variável "DiasProtesto" fica 9 ao invés de 7, só que como já estamos mandando o tipo de baixa como dias úteis na posição 221, o banco sabe que esse 7 é dias úteis, não precisa ser enviado 9 dias para o vencimento, dessa forma a remessa não está validando afirmando que "Quantidade de dias para protesto diferente da informada no layout". Eu fiz uma alteração no fonte apenas calculando a variável DiasProtesto com a função "WorkingDaysBetween" quando o tipo de protesto é dias úteis. Por gentileza se puder verificar se é realmente necessário ou se tem outra forma já programada. Atual: if (DataProtesto > 0) then begin DiasProtesto := IntToStrZero(DaysBetween(DataProtesto,Vencimento),2); case TipoDiasProtesto of diCorridos : ProtestoBaixa := '1'; diUteis : ProtestoBaixa := '2'; end; end else begin DiasProtesto := '00'; ProtestoBaixa:= '3'; //NÃO PROTESTA end; Nova: if (DataProtesto > 0) then begin case TipoDiasProtesto of diCorridos : begin ProtestoBaixa := '1'; DiasProtesto := IntToStrZero(DaysBetween(DataProtesto,Vencimento),2); end; diUteis : begin ProtestoBaixa := '2'; DiasProtesto := IntToStrZero(WorkingDaysBetween(Vencimento, DataProtesto),2); end; end; end else begin DiasProtesto := '00'; ProtestoBaixa:= '3'; //NÃO PROTESTA end; ACBrBancoBancoob.pas

Só uma observação, esse portal que utilizo é de SC, então pode ser que outros estados tenham versões diferentes realmente, interessante é os colegas acima postarem os manuais deles também para compararmos... se for isso mesmo, temos que fazer uma forma de isso ser dinamico ao invés de fixo no fonte.

Boa tarde @José M. S. Junior Sinceramente não sei por onde estão se baseando para essa informação da versão 087 e 045 Mas vou botar em anexo o manual que acabei de baixar do portal de homologações do sicoob, não sei a data dele, mas se está no portal creio que seja atualizado. Além disso, eu voltei o número das versões e mandei a remessa no portal novamente, agora validou sem problemas como pode ver na imagem. Layout_Para_Troca_de_Informacoes.xls

Boa tarde, Essa discussão da versão do layout é antiga, atualizei agora e começou a dar problemas para homologar no validador do Sicoob com essas versões 085 e 045 Essas versões já haviam dado problema e foi voltado para 081 e 040 porque a maioria dos usuários reclamaram Podem verificar na revisão 12834 do dia 17/01/2017 comitada pelo juliomar na qual foi voltada o número dessas versões tópicos na qual foi discutido isso também: Erro do validador que acabei de tentar homologar com o acbr atualizado:

Boa tarde @marcelonarezzi Acho que estamos falando de problemas diferentes, no seu caso era só informar 101 no código da modalidade. Nas informações geradas no arquivo de remessa como mencionei no meu post anterior, no manual versão 2.15 Março/2017 página 16 diz o seguinte:Complemento Conta Cobrança (posições 384-385): preencher com a última posição da conta cobrança e com o dígito (CCCCCCCCC-D) E essa regra não está sendo respeitada na última versão pois como você pode verificar na última versão foi tirada a linha de código que copiava o último carácter do número da conta, e está sendo enviado apenas o dígito verificador, e isso está diminuindo em 1 posição o tamanho do arquivo de remessa.