João Vitor Bogo

Que estranho, não faço ideia por quê o anexo está ficando assim visto que é um arquivo diferente que eu estou enviando, vou anexar novamente, porém a única diferença pro exemplo que você tem, é que em vez de DataBaixa eu estou preenchendo a DataCredito ACBrBoletoRet_Sicredi_APIV2.pas

Boa tarde. Estou com um problema na consulta do evento(Carta de correção) de uma NF-e. Basicamente o quê acontece é, ao fazer o envio desse evento para SEFAZ, o XML de retorno é salvo corretamente com a seguinte estrutura: Porém caso eu perca o XML, para gerar novamente eu preciso consultar essa Nota na SEFAZ, porém a estrutura do XML vem assim: Então, se eu carregar esse segundo XML e chamar a function LerXml, a impressão está ficando em branco. Eu vi melhor o problema e aparentemente na unit ACBrNFe.RetEnvEvento não estava sendo tratado o XML que a tag principal é 'NFeDFe'. Eu fiz a alteração acima na Unit e funcionou, porém não sei se isso é o correto, ou se eu estou fazendo algum processo errado (E por isso o segundo XML é gerado com uma estrutura diferente) Segue anex o os XMLs que foram gerados(Emitidos em homologação com dados fictícios), bem como a Unit com alteração. 1101103525040425024000010355001002028569140032581904-procEventoNFe(Gerado na Inclusão).xml1101103525040425024000010355001002028569140032581904-procEventoNFe(Gerado via Consulta).xmlACBrNFe.RetEnvEvento.pas

Fiz os teste sim, dessa vez eu mandei o arquivo com o campo "DataCredito" Diferente do primeiro que eu mandei com "DataBaixa" Acredito que talvez houve uma confusão já que o nome do arquivo é o mesmo

Fiz sim, preencendo a DataCredito, segue anexo ACBrBoletoRet_Sicredi_APIV2.pas

Bom dia pessoal. Nossos clientes atualmente já tem o certificado PFX carregado dentro do banco de dados para fazer a emissão da NF-e, seria muito mais trabalhoso para nós fazer com que fosse necessário criar um arquivo CRT ou KEY para ler na hora de enviar os boletos ao banco. Tendo isso em mente, eu fiz uma alteração na unit ACBrBoletoWS.Rest para funcionar carregando também os dados PFX e SENHA do certificado digital, então na hora de gerar o AcessToken, funciona normalmente, só foi necessário fazer 2 alterações. A Primeira alteração é na procedure TBoletoWSREST.DefinirCertificado; Onde eu adicionei 2 linhas para ler os DadosPFX e a Senha, e em baixo mais um bloco para preencher o SSL com os mesmos A Segunda alteração foi no inicio da function TBoletoWSREST.Enviar, onde eu mudei a ordem da chamada das procedures, para chamar a procedure DefinirCertificado antes da DefinirAuthorization(pois dessa maneira é preciso do Certificado PFX para gerar a Authorization) ACBrBoletoWS.Rest.pas Segue anexo o arquivo com as alterações. Fico aguardando algum feedback se possível.

Isso mesmo, na hora que eu fiz o post tinha colocado DataBaixa mas o ideal seria DataCredito

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.