theiller

ok, aguardando algumas das minhas contribuições para garantir a atualização dos fontes locais. Existe alguma previsão?

O objeto TMateraQRCodeResponse possui propriedades do tipo `DateTime` e ao exportar como JsonText pelo método `DoWriteToJSon` está perdendo o horário devido formatação "yyyy-mm-dd". "transactionDate": "2025-05-05T14:20:24.597-03:00" "transactionDate": "2025-05-05" Deveria utilizar AddPairISODateTime e ValueISODateTime Segue fonte ajustado ACBrSchemasMatera.pas

Em média quanto tempo demora para avaliar e disponibilizar alguma contribuição? Gostaria de atualizar todos os meus fontes para validar outras situações mas ainda não posso devido algumas correções ainda não disponibilizadas.

Identifiquei uma falha ao carregar dados usando json text. A conversão do tipo mdtUnknown estão divergentes, causando falha em WriteToJSon = "UNKNOWN" enquanto ReadFromJSon = "UNKNOW". Isso resulta em não encontrar o tipo associado ficando "mdtNone" indevidamente, que consequentemente fica vazio ao fazer o envio o conteúdo em "body": Fiz a correção, segue contribuição do fonte: ACBrSchemasMatera.pas

Identifiquei que não existia o método para atualização da conta. Fiz a implementação e já realizei a atualização, segue contribuição do fonte: ACBrPIXPSPMatera.pas

@Juliomar Marchetti Necessita passar os dois parametros, pois caso passe somente o Token retorna False para o fpAutenticado que faz o processo de gerar novo token. @EliasCesar O componente realmente trata o reuso do token da forma como citei no tópico, inclusive renova após a validade, porem existe alguma falha que retorna erro 500 ao tentar setar para reuso do token e validade recuperado.

Toda vez que fazia uma requisição, ocorria anteriormente uma outra requisição para obter novo token. Identifiquei que existe a possibilidade de reutilizar o mesmo token devido a expiração ser de 300 segundo (5 minutos), inclusive já existe o tratamento de renovação posterior essa data de validade, isso resulta em performance. Fiz uso dos metodos DoAntesAutenticar e DoDepoisAutenticar para interceptar o token, porem ao tentar usar o mesmo token na segunda requisição ocorre erro 400 bad request. Existe a necessidade de fazer algum outro tipo de ajuste? Esse problema já foi relatado/observado anteriormente? Talvez alguma configuração esteja ocorrendo a mais ou a menos quando se reusa o token. Vi que nos logs que o request estão iguais nas duas requisições, a que obteve pra utilizar o token e a que reutilizou o token. procedure TPSPServices.OnAntesAutenticar(var aToken: String; var aValidadeToken: TDateTime); begin aToken := FToken; aValidadeToken := FValidade; end; procedure TPSPServices.OnDepoisAutenticar(const aToken: String; const aValidadeToken: TDateTime); begin FToken := aToken; FValidade := aValidadeToken; end; Em questionamento ao suporte, foi confirmado que poderia reutilizar o token enquanto período válido, e fiz o teste utilizando o Postman que confirmou a possibilidade com retorno 200 e 401 posterior a validade. Flagship_postman_collection.zip

O provedor CTAConsult não retorna o "xml da nota fiscal autorizada", e sim um "xml do protocolo da autorização", foi identificado que existem algumas tags que não estão sendo carregadas, embora existam no xml e no classe de retorno: NumeroNota Link CodigoVerificacao Segue exemplo do retorno xml em ambiente homologação Ajuste: Fontes\ACBrDFe\ACBrNFSeX\Provedores\CTAConsult.Provider.pas TACBrNFSeProviderCTAConsult.TratarRetornoEmitir Response.Protocolo := ObterConteudoTag(ANode.Childrens.FindAnyNs('protocolo'), tcStr); Response.Situacao := ObterConteudoTag(ANode.Childrens.FindAnyNs('codigoStatus'), tcStr); Response.NumeroNota := ObterConteudoTag(ANode.Childrens.FindAnyNs('numeroNota'), tcStr); Response.Link := ObterConteudoTag(ANode.Childrens.FindAnyNs('linkPdfNota'), tcStr); Response.CodigoVerificacao := ObterConteudoTag(ANode.Childrens.FindAnyNs('chaveSeguranca'), tcStr); Segue em anexo o fonte atualizado. CTAConsult.Provider.pas

Correção: havia feito o ajuste fora do compilador, acabei invertendo os parâmetros da função. Segue arquivo banco santander corrigido. ACBrBancoSantander.pas

Identifiquei que na maioria dos bancos os campos de descontos 2 e 3 não estão sendo tratados da forma que é tratado os campos de descontos "1". Na classe TACBrBancoClass possui duas funções que podem ser implementadas e tratam o desconto "1" mas não existem algo parecido para os campos de descontos 2 e 3. function DefineCodigoDesconto(const ACBrTitulo: TACBrTitulo): String; virtual; function DefineDataDesconto(const ACBrTitulo: TACBrTitulo; AFormat: String = 'ddmmyyyy'): String; virtual; Minha sugestão é também ter a mesma funcionalidade para os demais campos, facilitando e permitindo popular corretamente os registros de forma simples e reuso do código, ainda manda a função anterior já como deprecated. function DefineCodigoDesconto(const ACBrTitulo: TACBrTitulo): String; virtual; deprecated 'Moved to the AnsiStrings unit'; //Utilizando para definir Código de Desconto na Remessa function DefineCodigoDescontoId(const ATipo: TACBrTipoDesconto; const AValor: Currency): String; virtual; //Utilizando para definir Código de Desconto na Remessa function DefineDataDesconto(const ACBrTitulo: TACBrTitulo; AFormat: String = 'ddmmyyyy'): String; virtual; deprecated 'Moved to the AnsiStrings unit'; //Utilizado para definir a Data de Desconto na Remessa function DefineDataDescontoId(const AData: TDateTime; const AValor: Currency; const AFormat: String = 'ddmmyyyy'): String; virtual; //Utilizado para definir a Data de Desconto na Remessa //... function TACBrBancoClass.DefineCodigoDesconto(const ACBrTitulo: TACBrTitulo): String; begin with ACBrTitulo do begin Result := DefineCodigoDescontoId(TipoDesconto, ValorDesconto); end; end; function TACBrBancoClass.DefineCodigoDescontoId( const ATipo: TACBrTipoDesconto; const AValor: Currency): String; begin if (AValor > 0) then begin case ATipo of tdValorFixoAteDataInformada : Result := '1'; tdPercentualAteDataInformada: Result := '2'; else Result := '1'; end; end else Result := '0'; end; function TACBrBancoClass.DefineDataDesconto(const ACBrTitulo: TACBrTitulo; AFormat: String): String; begin with ACBrTitulo do begin DefineDataDescontoId(DataDesconto, ValorDesconto, AFormat); end; end; function TACBrBancoClass.DefineDataDescontoId(const AData: TDateTime; const AValor: Currency; const AFormat: String): String; begin if (AValor > 0) then begin if (AData > 0) then Result := FormatDateTime(AFormat, AData) else Result := PadRight('', Length(AFormat), '0'); end else Result := PadRight('', Length(AFormat), '0'); end; Assim simplifica o ajuste nas classes dos bancos, mantendo a mesma lógica do código: Segue código com o ajuste. ACBrBoleto.pas ACBrBancoSantander.pas

Eu desde sempre utilizo: TACBrNFSe = class(TACBrDFe), mudou algo? ta no exemplo? vou conferir.

A cidade Vitoria da conquista-BA utiliza o provedor WebISS v1, ao tentar emitir uma NFSe recebi o retorno que a aliquota não era correspondente. Fiz a verificação dos dados da versão do provedor WebISS, código do serviço, alíquota e valores... Ao compararmos com um XML enviado diretamente pelo site da prefeitura na plataforma webiss, identificamos que a falha está na geração do XML de envio, que requer que a alíquota já esteja dividida pelo percentual (2.10 / 100 = 0.021). Na análise do arquivo pnfsNFSeW_ABRASFv1.pas existe essa tipo de tratamento, porem para o webiss esta sendo passado o percentual direto ao invés de dividir por 100, como ja existe a regra para outros provedores. Imagino que os desenvolvedores da região estejam preenchendo o objeto do acbr passando o valor já dividido, quando o correto deveria ser tratado pelo componente. Então fiz um ajuste para considerar a possibilidade de passarem o valor já dividido ou o percentual, para evitar o erro pós atualização caso outros projetos estejam tratando isso diretamente no código de cada projeto: //Retrocompatibilidade, se alguem estiver passando o valor da aliquota já dividida por 100 proWebISS: if (NFSe.Servico.Valores.Aliquota > 0) and (NFSe.Servico.Valores.Aliquota < 0.1) then Gerador.wCampo(tcDe4, '#25', 'Aliquota', 01, 05, 1, NFSe.Servico.Valores.Aliquota, DSC_VALIQ) else Gerador.wCampo(tcDe4, '#25', 'Aliquota', 01, 05, 1, (NFSe.Servico.Valores.Aliquota / 100), DSC_VALIQ); Segue anexo do xml emitido pela própria plataforma assim como o arquivo fonte alterado. NFSe-WebISSv1-Vitoria-Conquista.zip pnfsNFSeW_ABRASFv1_Alterado.zip

Na NFSe e possível fazer a emissão informando o município de prestação e/ou incidência, em que podem ser diferentes, porem na impressão esta sendo impresso o nome da cidade de prestação em ambos. Verfiquei com o XML esta correto e o arquivo de impressão também. A falha foi identificada em: Arquivo: Método: Atual: FieldByName('MunicipioIncidencia').AsString := CodCidadeToCidade(StrToIntDef(CodigoMunicipio, 0)); // Antes: Correção: FieldByName('MunicipioIncidencia').AsString := CodCidadeToCidade(IfThen(MunicipioIncidencia > 0, MunicipioIncidencia, StrToIntDef(CodigoMunicipio, 0))); Segue em anexo arquivo para análise e correção em repositório. ACBrNFSeDANFSeFR.pas

Desculpe, acho que encaminhei o arquivo ajustado parcialmente, segue novo. AcbrBoletoSicredIntensaoPagamentoAjuste.rar