João Vitor Bogo

Obrigado, dessa vez eu acabei fazendo direto pelo meu programa sem testar pelo exemplo da NFSeX, eu estava executando uma procedure que limpava essas informações.

Boa tarde, estou fazendo a leitura do XML da cidade de Campinas, porém logo abaixo da "Discriminação dos Serviços" e acima dos "Tributos Federais", o Código do Serviço está ficando em branco, mesmo ele estando presente no XML e sem marcar a opção "TabServicosExt" no componente. Impressão atualmente: Eu vi que dentro da unit ACBrNFSeXLerXml_ABRASFv2 , a procedure TNFSeR_ABRASFv2.LerServico(const ANode: TACBrXmlNode) Não estava adicionando um novo ItemServico, então na hora de imprimir, essa informação simplesmente estava ficando igual na imagem acima. Eu fiz a seguinte alteração nessa procedure: Depois isso, a impressão começou a funcionar corretamente Segue anexo um XML emitido em HOMOLOGAÇÃO + Unit com a alteração. ACBrNFSeXLerXml_ABRASFv2.pasxml homologacao.xml

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