mlgoncalves
-
Total de ítens
73 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por mlgoncalves
-
-
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.
bankNumberstringrequiredNosso Número do boleto
>= 1 characters<= 13 charactersExample:123Match 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.
-
1
-
-
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 CSLLNFSeNode.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 provedorInfID.ID := ObterConteudo(ANode.Childrens.FindAnyNs('nfecontrole'), tcStr);
3) FGMaiss.Provider.pas
Corrigir a URL informando a porta 443 de acessoResult := '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
-
Pessoal, obrigado pelo retorno.
Segui a orieBoletos IMPRESSOS FastReports teste código de barras.rarntação do Alexandre de Paula e consegui ler no APP SICOOB a maioria dos códigos de barras impresso dos diversos layouts FastReports e FortsReports. Usando um leitor NoNus a experiência foi péssima onde não foram lidos a maioria dos códigos de barras e os que foram lidos foi com muita paciência.
Ainda, seguindo a dica do Renato Rubinho, fiz experiências com resolução em 100%, 120% e 150% para os boletos do FastReports usando FoxIt e não consegui ler nenhum boleto, exceto o boleto carnê em resolução mais alta, sendo que em 100% não foi possível fazer a leitura.
Finalmente a conclusão que consegui chegar foi de que se depender da leitura do código de barras para efetuar o pagamento, o usuário vai ficar estressado.
Outro ponto que está fora de prática é imprimir boleto para pagar. Muitos usuários estão lendo o código de barras (ou pelo menos tentando ler) diretamente do monitor.
É isso aí.
Estou anexando os testes com os boletos impressos somente do FastReports. Do FortsReports o APP do Sicoob leu quase todos e o leitor Nonu não leu quase nenhum.
Por mim podem fechar o tópico.
-
1
-
-
Pessoal, boa tarde!
Um cliente entrou em contato reclamando que não conseguia ler o código de barras do boleto. Fizemos testes aqui no escritório e também não conseguimos ler a maioria dos códigos de barras dos diversos layouts de boletos existentes.
Investimos um tempinho para fazer testes e abaixo segue o resultado.
Definições:
1) Utilizamos o programa de exemplo do acbr para gerar os boletos e fazer os testes
2) Não imprimimos os boletos. Os códigos de barras foram lidos diretamente na tela do preview do programa de exemplo e também do leitor de pdfs FoxIt
3) Utilizamos o APP do SICOOB para fazer as leituras.
Conclusões dos testes
4) Testamos todos os layouts do FastReports e somente no BoletoCarne foi que conseguimos ler o código de barras
5) Testamos todos os layouts do FortesReports e conseguimos ler o código de barras em quase todos os layouts, exceto no layout BoletoA5 que não conseguimos ler.
Estamos anexando todos os boletos dos testes gerados no FastReposts e apenas o boleto do FortsReports que deu problema.
Pergunta: O que pode estar ocorrendo e como resolver isso?
Ficamos no aguardo.
Atenciosamente,
Marcelo Gonçalves
Boletos FortsReports teste código de barras.rar Boletos FastReports teste código de barras.rar
-
Obrigado, senhores!
Conseguimos implementar a codificação.
Marcelo
-
Boa tarde, Renato!
Depuramos a rotina e descobrimos que o problema está na falta da URL do serviço de ConsultarNFSeRps no arquivo ACBrNFSeXServicos.ini conforme abaixo:
ProConsultarNFSeRps=https://www1.fgmaiss.com.br:443/issqn/wservice/wsnfeconsultaxml.php
Segue em anexo o arquivo corrigido.
Obrigado pelo retorno.
Marcelo.ACBrNFSeXServicos.ini
-
1
-
-
Olá pessoal,
Ao clicar no botão de Consultar NFS-e por RPS do programa de exemplo, está dando o erro abaixo. Já o botão Consultar NFS-e por Número está funcionando corretamente. O que pode estar ocorrendo?
OpenSSL 1.1.1j 16 Feb 2021
01.01.01.0AF
C:\WINDOWS\SYSTEM32\libcrypto-1_1.dll
C:\WINDOWS\SYSTEM32\libssl-1_1.dll
------------------------------
Requisição
Ambiente : 1
Cidade : Tres Rios/RJ
Provedor : FGMaiss Versão: 1.00
Data/Hora: 11/12/2023 21:32:38
Método Executado: Consultar NFSe Por Rps
Parâmetros de Envio
Numero do Rps : 1
Série do Rps : 1
Parâmetros de Retorno
Numero do Lote:
Numero do Prot:
Situação :
Data : 30/12/1899
Desc. Situação:
ID Nota :
Link :
Sucesso : False
Erro(s):
Código : X999
Mensagem: Erro de Conexão: Erro Interno: 12005
Erro HTTP: 0
URL: *
Erro: 12005 -
Falha abrindo Conexão HTTP. Erro: 12005 -
Correção:
--------- -
Prezados, boa noite!
Precisamos de consultoria para implementar em Delphi o consumo de API do Banco Itaú que está funcionando no PostMan, e ainda algumas dicas sobre API.
Fico no aguardo.
Marcelo
-
Prezados, bom dia!
Quando enviamos um boleto já registrado anteriormente é retornado um JSON com a mensagem de erro que não está sendo devidamente tratado no componente. Fizemos o ajuste e anexamos aqui a unit para validação.
Exemplo de JSON retornado:
{
"codigo": "",
"mensagem": "Erro na validação de Campos",
"detalhes": [{
"codigo": "",
"mensagem": {
"campo": "COD-RET",
"mensagem": "Título já cadastrado na cobrança",
"valor": ""
}
}
]
}
Atenciosamente,
Marcelo Gonçalves
-
Boa noite!
Resolvido. O problema estava na conversão da string acentuada para UTF8.
Obrigado.
Solução:
Removido os acentos da string "reason"
{"reason":"Texto livre indicando motivo da operacao","code":"UNAVAILABLE_ITEM","mode":"AUTO","outOfStockItems":[],"invalidItems":[]}
-
Pessoal, bom dia!
Não estou conseguindo utilizar o evento de cancelamento de pedido do OpenDelivery. Está dando erro no retorno e eu não consegui entender e resolver o problema.
Vocês poderiam me ajudar? No postman está funcionando corretamente.
ENDPOINT conferido:
https://api.deliveryvip.com.br/merchant/v3/orders/0580de97-27fc-4388-b7e1-3339a5279c16/requestCancellationJSON gerado pelo ACBROpenDelivery que funciona corretamente no postman:
{"reason":"Texto livre indicando motivo da operação","code":"UNAVAILABLE_ITEM","mode":"AUTO","outOfStockItems":[],"invalidItems":[]}RETORNADO:
{"status":400,"error":"Bad Request"}No aguardo.
Atc,
Marcelo Gonçalves
-
Olá pessoal,
O código do juros continua errado.
Segue a unit corrigida.
Atenciosamente,
-
Conferido e ok.
Utilizar a mesma lógica no preenchimento de SeuNumero em outras partes da Unit.
Segue em anexo unit corrigida.
Atenciosamente,
-
Obrigado. Conferido ok.
-
Olá Victor, na alteração ficou faltando uma correção.
Segue a UNIT corrigida
Marcelo
-
1
-
-
Olá Victor,
Como saber se um boleto foi ou não registrado no banco Sicoob? Resposta: quando o codigo do objeto status estiver preenchido com 200; ou ACBrBoleto.Enviar retornar false.
Como disse no post de abertura desse tópico, o Sicoob retorna sempre o código 207 (quando a comunicação é feita com sucesso) para boleto registrado ou não registrado, que retorna TRUE na função ACBrBoleto.Enviar Então não pode consultar esse valor retornado como indicador de registro de boleto.
Entendo que a outra forma seria consultar a lista ListaRejeicao que, se contiver linha preenchida indicará o motivo da rejeição. Se não tiver linha preenchida indicará que o boleto foi registrado com sucesso.
Nesse sentido estou anexando a Unit com a proposta de modificação.
Agora, caso vocês interpretem uma lógica diferente, onde o programador deverá consultar obrigatoriamente a ListaRejeicao para saber se o boleto foi ou não registrado no banco, mesmo assim será necessário corrigir a programação que alimenta a lista pois não está funcionando corretamente. Estou anexando também um exemplo de retorno.
No aguardo.
-
-
Olá Pessoal,
Desculpe mas passei informação errada sobre o campo SeuNumero no banco Sicoob. Somente descobri quando peguei hoje o arquivo Retorno.
O campo SeuNumero no Sicoob contém o número do documento a que o boleto se refere (ex. NF.393939, etc) que também é impresso no boleto. É um campo alfanumérico e é retornado nas posições 59 a 73 do segmento T do CNAB240.
>> Entendo que o campo SeuNumero do Sicoob corresponde ao campo NumeroDocumento do ACBrBoleto.
O campo identificacaoBoletoEmpresa no Sicoob é para ser utilizado pelo ERP anotando o ID do boleto, por exemplo e não é impresso no boleto. Também é um campo alfanumérico e é retornado nas posições 106 a 130 do segmento T do CNAB240.
>> Entendo que o campo identificacaoBoletoEmpresa do Sicoob corresponde ao campo SeuNumero do ACBrBoleto.
Segue abaixo a Unit modificada.
Atenciosamente,
Boleto Santander - Nosso Número com ou sem dígito verificador
em ACBrBoleto
Postado · Editado por mlgoncalves
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.