João Vitor Bogo

Outro detalhe que encontramos foi que, a unit ACBrBancoAsaas, estava com o tamanho máximo da conta com 6 digitos, porém a nossa própria conta bancária aqui da empresa possui 7 dígitos, então foi necessário fazer uma alteração tanto na unit de 6 para 7 no tamanho da conta, e também de '12' para '11' a quantidade de zeros na função 'DefineCampoLivreCodigoBarras' Segue anexo com a alteração ACBrBancoAsaas.pas

Bom dia, já vou atualizar os fontes para fazer os testes, mas já adianto que pelas modificações que eu vi, ainda não foi postado nada referente ao seguinte bloco que eu comentei sobre a instrução 'deleted' que vem no JSON de consulta detalhe Outro detalhe, ao consultar um título, a informação referente ao campo 'ValorPago' está incorreta (no meu ponto de vista), está pegando o 'originalValue', que na teoria é o valor original do título quando foi enviado ao banco, ao invés do que foi realmente pago (que deveria ser o netValue) Vou agora atualizar os componentes e realizar mais alguns testes, volto no final da tarde caso tenha mais alguma coisa pra adicionar

Boa tarde, só queria adicionar um comentário à respeito da consulta detalhe da unit de retorno Atualmente, só existe no 'tpCancelar' tratando a informação se o título foi 'deleted' ou não. Isso também deve ser analisado no 'tpConsultaDetalhe' pois essa informação também vem no JSON de retorno (pois o cliente pode fazer isso direto pelo banco)

Bom dia, aparentemente pelos testes que eu fiz está tudo OK

Bom dia, segue link https://docs.asaas.com/reference/recuperar-uma-unica-cobranca

Tive que fazer mais alterações, agora relacionado ao 'valorpago' que estava analisando outro campo, em vez do que realmente foi pago, segue a unit completa (com a alteração correta na leitura do json e com a procedure temporária para consultar o QRCode ACBrBoletoRet_Asaas.pas

Só um comentário, para funcionar (igual estava antes) a consulta do QR Code, eu adicionei temporariamente essa função dentro da unit de retorno (e chamei dentro da consulta detalhe): Ela foge do padrão até então escrito, mas fiz o que era necessário para não quebrar os clientes que estão rodando, acredito que também seja necessário implementar algo parecido

Bom dia, eu vi que já subiram a unit do Asaas e fui fazer uns testes, atualmente estão montando a URL do tpConsultaDetalhada assim: Porém esse 'billinginfo' não retorna quase informação nenhuma do boleto: Fazendo que quando passa pela classe de retorno a function TRetornoEnvio_Asaas.LerListaRetorno não consiga ler nenhuma informação como Valor, Estado do Título, etc... Acredito que a URL deva ser montada assim: Pois faz com que o retorno seja assim: A URL sendo montada com a 'billinginfo' é para consulta das informações de pagamento, não sobre os dados do boleto em si. Ainda ficará faltando 1 ponto da unit (pois acredito que ela não está finalizada), que é agora sim sobre o retorno das informações do PIX, que deverão ser salvas nas tags ARetornoWS.DadosRet.TituloRet.UrlPix, ARetornoWS.DadosRet.TituloRet.EMV e ARetornoWS.DadosRet.TituloRet.TxId (caso se aplique) Segue unit com a alteração ACBrBoletoW_Asaas.pas Se puderem dar uma olhada e já validar, eu agradeço, também estou a disposição se precisarem de alguma conta em produção/sandbox para realizar os testes

Boa tarde, só queria deixar uma atualização à respeito das units. Estava fazendo sempre uma consulta à mais para pegar o ID do boleto no Asaas, porém isso não era necessário, o ID é retornado na inclusão, eu só não estava salvando. Também fiz uma alteração geral na estrutura das 2 units a seguir para ficar mais parecido ao padrão ACBR ACBrBoletoRet_Asaas_API.pasACBrBoletoW_Asaas_API.pas

Olá pessoal, Gostaria de contribuir com a implementação do Banco Asaas (código 461) no ACBrBoleto. Realizei o desenvolvimento das units necessárias e já executei testes tanto em ambiente de homologação quanto em produção. Toda produção foi feita levando como base a unit do Banco Inter. Informações Técnicas Versão do Delphi utilizada: 12.1 Ambiente testados: Homologação e Produção (Ambos somente via API, não foi feito teste via CNAB) Units Implementadas Segue anexo as seguintes units: ACBrBancoAsaas.pasACBrBancoAsaas_Const.pasACBrBoletoWS.pasACBrBoleto.pasACBrBoletoW_Asaas_API.pasACBrBoletoRet_Asaas_API.pas Observações As units seguem o padrão do ACBrBoleto e são compatíveis com a estrutura atual do componente. (Com exeção da unit de 'Const', onde acredito que foi melhor criar ela para não precisar repetir a mesma coisa em várias units diferentes) Estou à disposição para realizar ajustes, melhorias ou esclarecimentos que se fizerem necessários para a incorporação oficial dessas implementações ao projeto. Agradeço antecipadamente a atenção e fico no aguardo de um retorno.

Bom dia, alguma posição sobre essa alteração?

Boa tarde pessoal, eu tenho um cliente que está fazendo a consulta na hora de gerar o recebimento e o campo "DataBaixa" está ficando sem preencher, tudo isso por que não está caindo no bloco a seguir O problema é que no arquivo de retorno JSON, o campo 'dataHoraSituacao' não pertence ao AJsonObjectItem, e sim ao LJsonObject da mesma maneira que os seguintes campos: Eu já fiz o ajuste pra preencher a DataBaixa igual os oturos campos são preenchidos, porém mantive o bloco da primeira imagem, pois imagino que em algum outro exemplo possa vir preenchido dessa maneira. Segue arquivo JSON (censurado) e unit com as alterações: json censurado.jsonACBrBoletoRet_Inter_API.pas

Pelo que tenho anotado aqui seria Itau, Inter, Santander e Sicoob

ACBrBoletoWS.Rest.pas anexo arquivo com o comentário do porquê foi feito a alteração

Bom dia, fui atualizar o ACBR somente agora e fazer alguns testes, porém não funcionou corretamente. Fui mais à fundo ver o motivo, e pelo que eu testei, é por causa dessa ordem aqui: Na esquerda está o que é no Fontes do ACBR atualmente, na Direita foi a única maneira que eu consegui fazer enviar, caso contrário estava recebendo erro 403 de falha na autenticação. (Pois como citei inicialmente no tópico, é necessário do Certificado definido para só assim conseguir gerar a Authorization)

Boa tarde Gostaria de reforçar que a inclusão de um parâmetro específico não é um “trabalho à toa”, mas sim um investimento em clareza, robustez e manutenção futura. É bom notar alguns pontos para reflexão sobre isso: Clareza na configuração Ter campos separados para Inscrição Municipal e Código Mobiliário evita ambiguidades e “gambiarras” futuras. Facilita a leitura do código, o entendimento de novos desenvolvedores e a detecção de erros. Manutenção e escalabilidade Hoje apenas um provedor exige o Código Imobiliário mas amanhã outro pode precisar dele também. Planejar para o crescimento do componente reduz retrabalho e dores de cabeça posteriores onde a emissão de determinadas prefeituras podem 'parar' por falta disso. A adição de um parâmetro dedicado segue o conceito de clean code, onde cada elemento tem responsabilidade única e clara. Esforço de implementação reduzido No ACBrMonitor, basta adicionar um novo campo de configuração (não é algo complexo) Na Lib, é possível usar exatamente a lógica sugerida, sem alterar o fluxo atual de quem já está em produção: Basta utilizar um IF no preenchimento da Tag com o campo novo, quem já está rodando não vai ter nada preenchido nele, e nesse caso, continua utilizando o que já estava antes. Adicionar um parâmetro novo traz benefícios claros sem quebrar compatibilidade com quem já está em produção. Dessa forma, garantimos um componente mais organizado, preparado para o futuro e com impacto mínimo para os atuais usuários. Um último ponto à respeito disso, é que até o momento ninguém que está utilizando pareceu se importar nem com a impressão da NFS desse Provedor, pois como eu cito no meu outro post relacionado à leitura do XML, o 'mesmo campo' está sendo lido como Inscrição Municipal, quando na verdade não é assim. Então eu acredito que essa modificação não terá impacto algum para quem já está utilizando.

Boa tarde pessoal. Eu fiz um tópico faz alguns minutos, relacionado a Inscrição Municipal / Código Imobiliario no Assessor Público. Sobre a parte da leitura do XML retornado da prefeitura Nesse tópico eu abordei (corretamente acredito eu) sobre a leitura dos campos que estavam erradas. Porém agora o problema que eu acredito que existe é no envio da requisição para o Assessor. Como podem ver nessa print, é preenchido a tag 'INSCRICAO' com o campo "InscMun", até então, não deveria haver problemas, porém o próprio Assessor Público, não espera a Inscrição Municipal nessa tag, e sim o Código Imobiliario. Tanto que fazendo os testes e preenchendo essa tag com a Inscrição Municipal de fato, eu tenho o seguinte retorno da prefeitura: Isso pois eles tratam de uma maneira equivocada como as tags são preenchidas. A minha sugestão (caso o ACBR concorde que o preenchimento não deve ser feito assim) é a seguinte: Criar na unit ACBrNFSeXConfiguracoes o campo "Codigo Imobiliario" e alterar na unit AssessorPublico.Provider a montagem do campo Emitente.InscMun para Emitente.CodigoImobiliario. Caso queiram, aqui está as units com as modificações: AssessorPublico.Provider.pas ACBrNFSeXConfiguracoes.pas

Boa tarde. Ao analisar os XMLs de retorno da NFSeX com o provedor do Assessor Público (unit AssessorPublico.LerXml), percebi que o componente está lendo a Inscrição Municipal do prestador usando a seguinte tag: No entanto, essa tag (PRESTCODMOBILIARIO) não representa a Inscrição Municipal. Ela representa o Código Imobiliário. A tag correta que traz a Inscrição Municipal real, é a seguinte: Como podem ver no XML: Comparei os valores retornados pelas duas tags e eles são diferentes. Por isso, acredito que o componente esteja lendo o campo errado. Sugestão: Sugiro alterar a leitura para usar PRESTINSCRICAOMUN, que de fato representa a inscrição municipal. Se alguma prefeitura do Assessor Público exigir a leitura do PRESTCODMOBILIARIO, talvez seja o caso de tratar isso de forma condicional. Unit com as alterações: AssessorPublico.LerXml.pas

Olá, equipe ACBr! Gostaria de sugerir uma melhoria na procedure TfrlXDANFSeRLRetrato.rbCodServicoBeforePrint, responsável por preencher o campo "Código Serviço" no DANFSe. Contexto: Atualmente, o preenchimento do campo "Código Serviço" é feito com base na lista Servico.ItemServico. No entanto, há casos em que a prefeitura retorna um ou mais itens dentro de ItemServico, mas sem preencher os campos ItemListaServico e xItemListaServico. Nestes casos, o relatório não exibe nenhuma informação, pois o código atual apenas considera a exibição dos campos “pais” (Servico.ItemListaServico e Servico.xItemListaServico) quando ItemServico.Count = 0. Problema: Servico.ItemServico.Count > 0, mas os itens estão sem dados nos campos necessários. A lógica atual impede que os campos alternativos sejam utilizados, resultando na ausência do "Código Serviço" no relatório. Proposta de solução: Ajustar a lógica para que o bloco alternativo (que utiliza Servico.ItemListaServico e Servico.xItemListaServico) também seja executado quando não há nenhum ItemServico com dados válidos. Com essa modificação, evitamos situações em que o relatório fica com o campo em branco, mesmo havendo informações disponíveis nos campos principais. Unit com a alteração: ACBrNFSeXDANFSeRLRetrato.pas Fico à disposição para enviar a modificação completa, caso necessário.

Bom dia, segue anexo sugestão da alteração nessa unit ACBrBoletoW_Sicredi_APIV2.pas

Olá, desculpa reviver esse meu tópico antigo, queria saber se posso ajudar em algo pra essa TK sair

Bom dia, Apenas para esclarecer, em nenhum momento afirmei que o código não está funcionando. O ponto que levantei é que nem todas as opções disponíveis estão sendo devidamente tratadas. Com a lógica atual, as propriedades ATitulo.DiasDeProtesto / ATitulo.TipoDiasProtesto e ATitulo.TipoDiasNegativacao acabam sendo subutilizadas. Isso força o ERP a calcular manualmente os dias da instrução (com base em DataProtesto - Vencimento), quando o ideal seria simplesmente passar os parâmetros completos e permitir que o próprio componente se encarregue desse cálculo, conforme foi projetado. Isso poderia evitar inconsistências e tornar o processo mais flexível e aderente à estrutura já existente.

Atualmente já está com a URL de Produção, mas também existe a de homologação conforme exemplo abaixo: [3537305] Nome=Penapolis UF=SP Provedor=AssessorPublico ProRecepcionar=http://s33.asp.srv.br/issonline/servlet/anfse HomRecepcionar=https://s1.asp.srv.br/issonline-homolog/servlet/anfse

Bom dia, estou fazendo a implementação da Negativação/Protesto e me deparei com o seguinte bloco Não entendi por quê está sendo utilizado ATitulo.DataProtesto - ATitulo.Vencimento sendo que já existem as propriedades ATitulo.DiasDeProtesto e ATitulo.TipoDiasProtesto, que atualmente não estão sendo utilizadas. Aproveitando, uma linha abaixo tem o seguinte bloco que já está analisando o campo ATitulo.DiasDeNegativacao mas não leva em consideração o campo ATitulo.TipoDiasNegativacao. Minha dúvida é se isso foi feito intencionalmente dessa maneira, ou se só acabou passando batido

Bom dia, eu estou fazendo alguns testes e vi que até então existe apenas uma constante ERR_NAO_IMP que diz "Serviço não implementado para este provedor.", a minha sugestão é alterar para "Serviço %s não implementado para este provedor.", então em cada lugar que chama essa constante, é passado um 'Format' pra indicar qual é o serviço que não está implementado, acredito que isso vai fazer com que fique muito mais fácil para entender exatametne o quê não está implementado. Segue anexo arquivo com a alteraçãoACBrNFSeXWebserviceBase.pas