João Vitor Bogo

Boa tarde, atualmente na unit ACBrBoletoRet_Sicredi_APIV2 não é analisado o campo "dataPrevisaoPagamento" que vem no retorno JSON do banco. Nesse exemplo do título à seguir, o título foi pago no dia 06 (domingo), levou o dia 07(segunda) processando e só vai ter o crédito em conta no dia 08(terça), mas atualmente o ACBR está levando em consideração apenas o que está dentro do bloco "dadosLiquidacao" Para resolver esse problema eu adicionei o seguinte IF na unit Edit: Acredito que, nesse caso, seria ideal preencher a "DataCredito" e não "DataBaixa" como nos exemplos que enviei. Retorno Sicredi v2.json ACBrBoletoRet_Sicredi_APIV2.pas

Tentei editar o Post mas não consegui, está dizendo que postei a muito tempo. Segue anexo minha sugestão de alteração da Unit, preenchendo agora a DataCredito, ValorMoraJuros, ValorMulta e ValorPago caso o título tenha sido baixado com o motivo "BAIXA POR TER SIDO LIQUIDADO" ACBrBoletoRet_Itau_API.pas

Bom dia pessoal. Estou com um problema em um cliente, onde caso o pagador do boleto, pague ele depois da Data de Vencimento, o bloco "pagamentos_cobranca" não existe, sendo assim, o Valor Pago fica zerado. Eu pensei em fazer um ajuste no seguinte bloco, fazendo um cálculo do Valor do Documento + A diferença de dias entre a data de Vencimento + A data de Baixa, calculando o Juros e Multa em cima disso (Visto que no JSON já existe o campo valor_multa e valor_juros) Não fiz essa alteração ainda pois queria confirmar com vocês se estou seguindo a linha de raciocínio correta. Segue anexo 1 título que foi pago em dia e outro que foi pago com atraso para comparação. OBS: Censurei algumas informações pois são títulos Reais de um Cliente. Título Pago com Atraso.json Titulo Pago Em Dia.json

Acho que talvez eu me expliquei mal, vou dissertar um pouco mais para deixar mais claro. Imagine que eu tenho 2 boletos idênticos que foram pagos no mesmo dia, porém o boleto nº1 foi pago pelo qrcode e o boleto nº2 foi pago pelo código de barras. O Boleto 1 vai entrar na minha conta no mesmo dia que foi pago, o boleto 2 vai entrar na minha conta no próximo dia. Porém, no arquivo JSON que o Itaú retorna, o campo "data_inclusao_pagamento", está preenchido em ambos com a mesma data, então só por esse campo, eu não consigo saber se o título foi pago pelo QRCode ou pelo Código de barras. A única diferença que esses 2 títulos tem no arquivo JSON que o Itaú retorna, é o preenchimento da tag "descricao_instrumento_cobranca" O Boleto 1 vai ter a tag "descricao_instrumento_cobranca" preenchida com a string "BoleCode" O Boleto 2 vai ter a tag "descricao_instrumento_cobranca" preenchida com a string "boleto" Levando isso em consideração, e 'convertendo' para os campos do ACBR, essa informação deveria ser preenchida no campo "CodigoCanalTituloCobranca" (Campo esse que até então, não é preenchido no Itaú). Agora sim, com o campo "CodigoCanalTituloCobranca" preenchido, eu consigo saber na hora de tratar esse retorno, se o título foi pago pelo QRCode (E deve entrar no extrato da conta bancária no mesmo dia) ou se ele foi pago pelo código de barras(E deve entrar no extrato de conta bancária somente no próximo dia)

up

Pessoal, bom dia! Eu tive um problema com um cliente que emite boletos e BoleCodes (QR Code com Pix) via API do Itaú. A questão era que os pagamentos feitos por boleto só eram creditados na conta bancária no dia seguinte, enquanto os pagos via BoleCode caíam na mesma hora. Porém, no JSON retornado pelo banco, a única diferença entre os dois tipos de pagamento estava no campo "descricao_instrumento_cobranca", onde um vinha como "BoleCode" e o outro como "boleto". Até mesmo o campo "data_inclusao_pagamento" era idêntico para ambos os casos, o que dificultava a diferenciação. Notei que o ACBR não realizava nenhum tratamento específico para a tag "descricao_instrumento_cobranca", o que me impedia de identificar claramente qual pagamento havia sido feito por boleto e qual por BoleCode. Fiz a alteração necessária para tratar essa diferença e agora consigo identificar corretamente os pagamentos. Agora estou preenchendo e analisando o campo "CodigoCanalTituloCobranca" com o valor da tag "data_inclusao_pagamento". Segue anexo unit com as alterações para análise. ACBrBoletoRet_Itau_API.pas

deixando um up aqui só pro tópico não cair no esquecimento

Boa tarde, eu fiz os testes e funcionou normalmente a emissão e o cancelamento da NFSe, segue a seguir apenas a configuração no arquivo INI de como tem que ficar: [3556008] Nome=Urupes UF=SP Provedor=Fiorilli Versao=2.00 ProRecepcionar=http://transparencia.urupes.sp.gov.br:5661/IssWeb-ejb/IssWebWS/IssWebWS ProLinkURL=http://transparencia.urupes.sp.gov.br:5661/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso%

Aqui está a modificação que eu fiz, alterei de Integer para String. ACBrDFeComum.RetConsCad.pas

Qual manual seria esse? pois na Nota Técnica onde descreve tanto o campo do CEP quanto o CPF/CNPJ, os 3 estão descritos da mesma maneira

Eu ainda não vejo sentido esse argumento, pois no mesmo bloco do manual os campos CPF e CNPJ também são numéricos e variam de 3-14 e 3-11, porém ainda sim devido à natureza deles que permite começar com zero, eles são tratados como String em vez de Integer

Bom dia, na unit ACBrDFeComum.RetConsCad existe a propriedade 'CEP' como um Integer, mas na verdade deveria ser uma String (pois existem CEPs com zero à esquerda) Exemplo do problema que está acontecendo: ObterConteudoTag(AuxNode.Childrens.FindAnyNs('CEP'), tcInt) me retorna 7094000 O ideal seria ser uma String e fazer a chamada ObterConteudoTag(AuxNode.Childrens.FindAnyNs('CEP'), tcStr) para retornar '07094000' Eu publiquei essa dúvida no Discord porém me foi dado a seguinte resposta: Ao meu ver isso não faz sentido pois ao definir um campo que contém números com 7 a 8 dígitos, é importante considerar sua natureza e propósito. Se o valor pode começar com zero — como acontece frequentemente com códigos, identificadores ou CEPs — o campo deve ser armazenado como uma string, e não como um integer. Quando armazenado como integer, o zero à esquerda é removido automaticamente, comprometendo a integridade dos dados. Por exemplo, o código 01234567 se tornaria 1234567, alterando significativamente sua representação. Além disso, esse campo não se destina a operações matemáticas, mas sim à identificação ou classificação, o que reforça o uso de string. Assim, garantindo consistência e clareza no armazenamento desses valores. Essa mesma lógica se aplica ao CPF ou CNPJ, que podem começar com o dígito zero e, por esse motivo, é corretamente armazenado como string (mesmo que na NT esteja como Númerico), preservando sua estrutura original.