mlgoncalves

Olá pessoal, A unit ACBrBoletoW_Santander_API está apresentando erro no momento de gerar a tag 'messages' que contém as mensagens do boleto. procedure TBoletoW_Santander_API.GerarMensagens(AJson: TACBrJSONObject); var LJsonArray: TACBrJSONArray; I: Integer; begin if Assigned(ATitulo) and Assigned(AJson) then begin LJsonArray := TACBrJSONArray.Create; for I := 0 to PRed(ATitulo.Mensagem.Count) do begin //está dando erro na linha abaixo. ATitulo.Mensagem[I] = 'Teste' // LJsonArray.AddElementJSONString(ATitulo.Mensagem[I]); //fiz o ajuste abaixo para funcionar LJsonArray.AddElement(ATitulo.Mensagem[I]); end; AJson.AddPair('messages',LJsonArray); end; end; Não sei se é a melhor forma de se fazer, mas está funcionando. Segue em anexo a unit modificada e ficamos no aguardo do devido ajuste. Atc, Marcelo Gonçalves ACBrBoletoW_Santander_API.rar Segue link do manual de montagem do JSON para esclarecer eventual dúvida. https://developer.santander.com.br/api/documentacao/api-de-emissao-de-boletos#/paths/workspaces-workspace_id--bank_slips/post

Bom dia, Juliomar! Muito obrigado pelo retorno. SVN conferido. Pode fechar o tópico.

Bom dia, Ítalo! Muito obrigado pelo retorno. Conferido no SVN. Pode fechar o tópico

Boa tarde! Estou enviando nova versão da unit. A versão anterior estava com erro. PagFor.BancodoBrasil.GravarTxtRemessa.rar

Boa tarde! Baixei atualização do ACBr e fiz novamente o ajuste na unit que está em anexo. Favor validar e subir para o SVN. Atenciosamente, ACBrBoletoW_Santander_API.rar

Boa tarde! Baixei atualização do ACBr e ajustei o FGTS DIGITAL conforme unit em anexo. Favor validar a alteração e subir para o SVN. Atenciosamente, PagFor.BancodoBrasil.GravarTxtRemessa.rar

Bom dia, Italo! Conferido e muito obrigado. Pode fechar o tópico.

Boa tarde! Por favor validem as alterações e se precisar de algum ajuste é só falar. Atenciosamente,

Boa tarde! Por favor validem as alterações e se precisar de algum ajuste é só falar. Atenciosamente,

Boa tarde! Por favor validem o procedimento. Se tiver que alterar alguma coisa é só avisar que iremos providenciar. No aguardo.

Prezados, boa tarde! Para processar corretamente o arquivo retornado do Banco do Brasil foi necessário descomentar a linha que faz a leitura do registro complementar Z do seguimento A. Fizemos todos os testes e está ok. Antes era: // LerSegmentoZ(PagFor.Lote.Last.SegmentoA.Last.SegmentoZ, I); E agora passou a: LerSegmentoZ(PagFor.Lote.Last.SegmentoA.Last.SegmentoZ, nLinha); Estou anexando a unit modificada e o layout do banco para quaisquer dúvidas. Favor validar este post e subir para o SVN. Atenciosamente, Marcelo Gonçalves PagFor.BancodoBrasil.LerTxtRetorno.rar PgtVer03BB.rar Trecho de arquivo segmento A retornado do banco.rar

Bom dia, pessoal! Vocês poderiam validar esse tópico, por favor?

Pessoal, boa tarde! Precisei de ajustar o layout do Banco do Brasil para compatibilizar com as novas orientações para pagamento do FGTS Digital. Estou anexando o manual do Banco do Brasil e a unit alterada. Solicito que as alterações feitas sejam ratificadas e subidas para o SVN. Atenciosamente, Marcelo Gonçalves Cnab240 para FGTS Digital v. 1.1. de 06.03.2024.pdf PagFor.BancodoBrasil.GravarTxtRemessa.rar

Boa tarde! Favor incluir a informação da quantidade de dias para baixa de boleto não liquidado no JSON a ser enviado ao banco. O manual diz em https://developer.santander.com.br/api/documentacao/api-de-emissao-de-boletos#/paths/workspaces-workspace_id--bank_slips/post writeOffQuantityDays string Quantidade de dias para baixa >= 1 characters<= 2 characters Example: 32 Match pattern: \d{1,2} Fizemos a alteração na unit ACBrBoletoW_Santander_API.pas conforme trecho abaixo, e anexamos o arquivo completo com a modificação. procedure TBoletoW_Santander_API.GerarProtesto(AJson: TJsonObject); begin if Assigned(ATitulo) then begin with ATitulo do begin if Assigned(AJson) then begin if DiasDeProtesto = 0 then begin AJson.Add('protestType').Value.AsString := 'SEM_PROTESTO'; end else begin case TipoDiasProtesto of diCorridos: AJson.Add('protestType').Value.AsString := 'DIAS_CORRIDOS'; diUteis: AJson.Add('protestType').Value.AsString := 'DIAS_UTEIS'; end; AJson.Add('protestQuantityDays').Value.AsString := IntToStr(DiasDeProtesto); end; //prazo de baixa/devolução em dias, opcional if (DataBaixa <> 0) and ((DataBaixa - Vencimento) > 0) then AJson.Add('writeOffQuantityDays').Value.AsString := IntToStr(trunc(DataBaixa - Vencimento)); end; end; end; end; ACBrBoletoW_Santander_API.rar

Pessoal, Desistimos de tentar compatibilizar os dois canais de envio e recebimento de boletos do Santander. Assim sendo, desativamos o envio/recebimento através de CNAB e adotamos por padrão o uso da API. Podem encerrar esse tópico.

Pessoal, bom dia! Ainda estamos com esse assunto em aberto. O questionamento que estou fazendo é de que os canais de envio de boleto para o banco Santanter (via arquivo remessa e via API) estão incompatíveis. Se você envia através de arquivo remessa só pode receber via arquivo retorno. Se envia via API só pode receber via consulta da API. É isso mesmo? Se sim, vida que segue, mas acho que deveria haver compatibilidade de dados entre os canais. Exemplo do problema que está ocorrendo: Preencher o componente com a informação do Nosso Número, por exemplo: ACBrTitulo.NossoNumero := '14864'; Enviando o boleto via arquivo remessa, fica registrado no banco o nosso número: 148644 (ou seja, o componente adicionou automaticamente o dígito verificador 4 para depois incluir o nosso número na remessa) Enviando o boleto via API, fica registrado no banco o nosso número 14864 (ou seja, o componente não adiciona o nosso número) Daí pra frente é só inconsistências... A proposta que gostaria de fazer era de padronizar, simples assim. Ou adiciona o nosso número automaticamente pelo componente, tanto na remessa quanto no envio via API ou não se adiciona o nosso número, ficando a cargo do programa fazer essa inclusão. Desse modo tanto a API ENVIO/CONSULTA quando a REMESSA/RETORNO estariam compatíveis. Está coerente a minha colocação?

Mas questionar o que, exatamente? No banco existe exatamente o que foi enviado. Não vejo o que questionar. Se enviar Nosso Número com DV fica com DV no banco (o DV é incluído automaticamente na geração do CNAB400), se enviar nosso número sem DV fica sem DV no banco (é o que ocorre na API, onde o DV deveria ser gerado automaticamente, mas não é). Se mantiver essa situação no componente, deverei alterar a programação no meu sistema para: .... NossoNumero recebe próximo número da sequencia; se banco_santanter e transmissao_via_API então calcular o dígito verificador e adicionar no final do NossoNumero fimse; .... Não acho que isso deveria acontecer.

Consultei os boletos diretamente no site do banco Santander: 1424 0000000148890 18.000,00 F33108 0000000148911 3.336,91 1424 0000000149187 18.000,00 29112 0000000148938 1.952,24 3110 0000000149080 2.303,50 F32120 0000000149098 3.433,91 F35120 0000000149101 5.183,73 3110 0000000149110 2.303,50 40120 0000000149128 5.092,07 <<<---Até aqui os boletos tinham sido enviados pelo CNAB400, depois usando a API os boletos ficaram sem o dígito verificador. F35120 0000000014923 8.117,71 F35120 0000000014924 6.521,23 33109 0000000014925 3.096,08 3148 0000000014926 5.771,17 2997 0000000014927 3.141,57 3181 0000000014928 2.248,87 F9120 0000000014929 9.927,83 33110 0000000014930 1.349,70 312 0000000014931 2.600,00

Bom dia! A documentação da API dos boletos está em https://developer.santander.com.br/api/documentacao/api-de-emissao-de-boletos#/ Nela não descreve como deve ser montado o Nosso Número (banknumber) mas somente como deve ser preenchido. bankNumber string required Nosso Número do boleto >= 1 characters<= 13 characters Example: 123 Match pattern: ^[0-9]{1,13}$ O único local que encontrei onde descreve sobre o campo é no manual citado acima. Então entendo que existe apenas uma definição para o campo. Então o componente do ACBr não deveria ter o mesmo comportamento para o campo independente do canal de transmissão utilizado?

Pessoal, boa noite! Esta semana implementei o uso de API de enviar boletos para o banco Santander. Até então utilizava o envio de arquivo remessa CNAB400. Ocorre que tive um problema na leitura do nosso número retornado do banco, estava cortando o último dígito do nosso número que tinha enviado. Após estudar a rotina do CNAB400 e o JSON do boleto percebi que existem diferenças entre elas na montagem do nosso número e é exatamente aí que gerou o problema, que estou propondo agora que seja corrigido. 1) Vamos direto ao ponto. No manual do Santander (em anexo) diz assim: >> Nota 3: Forma de cálculo do dígito de controle >> Nosso número >> Campo opcional. Se igual a zeros, o sistema de cobrança do Banco atribuirá automaticamente o nosso número, se não for igual a zeros, observar instruções abaixo: >> Composição >> NNNNNNN-D onde: >>NNNNNNN = Faixa seqüencial de 0000001 a 9999999. D = Dígito Verificador. Significa que o nosso número é um numero sequencial seguido de um dígito verificador. 2) O gerador do arquivo CNAB400 ao anotar o nosso número adiciona o digito verificador, ou seja, o NossoNumero do componente é alimentado com o número sequencial e o próprio componente se encarrega de adicionar o dígito verificador completando assim a informação do nosso número, conforme descrito no manual (7 dígitos para o número sequencial e 1 dígito para o dígito verificador). Trecho da unit ACBrBancoSantander que mostra o descrito acima e que está de acordo com o manual: wLinha:= '1' + // 1- ID Registro IfThen(Cedente.TipoInscricao = pJuridica,'02','01') + // 2 a 3 PadLeft(trim(OnlyNumber(Cedente.CNPJCPF)),14,'0') + // 4 a 17 PadRight(trim(Cedente.CodigoTransmissao),20,'0') + // 18 a 37 PadRight( SeuNumero ,25,' ') + // 38 a 62 PadLeft(RightStr(NossoNumero,7),7,'0') + DigitoNossoNumero + // 63 a 70 IfThen(DataAbatimento < EncodeDate(2000,01,01), '000000', FormatDateTime( 'ddmmyy', DataAbatimento)) + // 71 a 76 3) Quando no retorno dos dados do banco, arquivo retorno, o nosso número ocupa exatamente as mesmas posições da remessa, ou seja, 63 a 70. Então o componente do ACBr, unit ACBrBancoSantander, ao ler o retorno faz a seguinte atribuição que também está coerente com o que foi feito na remessa: ... with Titulo do begin SeuNumero := copy(Linha,38,25); NossoNumero := Copy(Linha,63,07); Carteira := Copy(Linha,108,1); ... Nessa atribuição do NossoNumero, o componente descartou o último dígito (dígito verificador) mantendo apenas a primeira parte do nosso número, que é o número sequencial. Então tanto a REMESSA CNAB400 quando o RETORNO CNAB400 estão coerentes no tratamento do campo NossoNumero. 4) Vamos ao problema: ao gerar o JSON de envio pro branco, o componente está gerando o nosso número incompleto, ou seja, não está incluindo o dígito verificador como era de se esperar. O banco não confere se o último dígito é ou não o verificador, simplesmente acata em seu sistema, e no arquivo retorno CNAB400 esse mesmo número incompleto ocupa as 8 posições previstas no layout (um 0 (zero) foi acrescentado à esquerda) e o componente do ACBr descarta o último dígito como se fosse o dígito verificador, no momento da atribuição para a propriedade NossoNumero, ficando o NossoNumero errado no compomente. Diante do exposto, entendendo que existe uma divergência na geração da informação do nosso número nos dois processos de envio de boleto, CNAB400 e API, sugiro corrigir a unit ACBrBoletoW_Santander_API, na linha 484, para acrescentar o dígito verificador que falta: Json.Add('bankNumber').Value.AsString := NossoNumero + ATitulo.ACBrBoleto.Banco.CalcularDigitoVerificador(ATitulo); e corrigir a unit ACBrBoletoRet_Santander_API no tratamento do nosso número retornado, removendo o dígito verificador das diversas linhas da unit, como no exemplo: ARetornoWS.DadosRet.IDBoleto.NossoNum := copy(LJSONObject.AsString['bankNumber'], 1, length(LJSONObject.AsString['bankNumber']) -1); Desse modo tudo fica logicamente correto, o NossoNumero enviado ao banco tanto pelo CNAB400 quanto pela API é retornado no CNAB400 e o componente lê e preenche corretamente a propriedade NossoNumero no momento do retorno, permitindo o uso padronizado para clientes com envios de boleto em canais diferentes. Anexei as units já modificadas. Diante disso, solicito que sejam validadas minhas considerações e atualizado o SVN caso sejam aprovadas. Atc, Marcelo Gonçalves ACBrBoletoRet_Santander_API.pas ACBrBoletoW_Santander_API.pas Layout CNAB 400 posições Out de 2009.pdf

Bom dia! Realmente, eles trataram desse assunto lá. Aproveitei para conferir e o SVN já está atualizado. Obrigado, e pode fechar o tópico.

Bom dia! Desculpe, mas esqueci de detalhar o problema, então vamos lá. 1) svn atualizado 2) O tópico sugerido não se refere ao problema detectado. 3) Segue o detalhamento do erro. Na linha 130 da unit ACBrBoletoRet_Bancoob.pas está dando erro de excessão porque no JSON retornado o campo 'resultado' é outro JSON e não um array de JSON. Linha com erro: aJsonViolacoes := aJson.Values['resultado'].AsArray; Proposta de correção, testar se o campo resultado é um array antes de obter o valor. if aJson.Values['resultado'].IsJsonArray('resultado') then begin aJsonViolacoes := aJson.Values['resultado'].AsArray; ... Favor validar a proposta de correção e, estando de acordo, confirmar no SVN. Atenciosamente, Marcelo

Boa tarde! Está dando erro na leitura do JSON retornado de uma consulta. Fizemos a devida correção que estamos anexando neste chamado, para que seja analisada e ratificada. Atenciosamente, Marcelo.ACBrBoletoRet_Bancoob.rar

Pessoal bom dia! Muito obrigado, Ítalo! Conferi as alterações e está tudo certo. Parabéns mais uma vez pelo excelente trabalho de vocês. Podem encerrar o tópico. Marcelo.

Olá pessoal, Estamos implantando a emissão da NFS-e para a prefeitura de Três Rios/RJ e durante o desenvolvimento tivemos de fazer uns ajustes no ACBrNFSeX para o perfeito funcionamento da integração, e solicitamos que esses ajustes sejam revisados e incorporados no componente. Provedor: WEBFISCO / FGMAISS Units: 1) WebFisco.GravarXml.pas Completar preenchimento do XML com IR e CSLL NFSeNode.AppendChild(AddNode(tcDe2, '#', 'irrf', 1, 12, 1, NFSe.Servico.Valores.ValorIr, '', True, xAtrib)); NFSeNode.AppendChild(AddNode(tcDe2, '#', 'csll', 1, 12, 1, NFSe.Servico.Valores.ValorCsll, '', True, xAtrib)); 2) WebFisco.LerXml.pas Atribuir o ID da NFS-e retornada, que é chave utilizada para consultas no provedor InfID.ID := ObterConteudo(ANode.Childrens.FindAnyNs('nfecontrole'), tcStr); 3) FGMaiss.Provider.pas Corrigir a URL informando a porta 443 de acesso Result := 'https://www1.fgmaiss.com.br:443/issqn/wservice/'; Segue em anexo as units modificadas Atenciosamente, Marcelo Gonçalves FGMaiss.Provider.pas WebFisco.GravarXml.pas WebFisco.LerXml.pas