Joathan Theiller

Precisei emitir uma MDFe com dados do Seguro, porem apesar dos dados constarem no XML, notei que não estavam sendo apresentados na impressão do DAMDFe. Referência: https://svn.code.sf.net/p/acbr/code/trunk2/Exemplos/ACBrDFe/ACBrMDFe/Delphi/Report/DAMDFe_Retrato.fr3 Fiz os ajustes baseado na estrutura já utilizada: Adicionado conjunto de dados: Seg Adicionado novo SubReport "SBSeg" em "SBModalRodoviario" Alinhamento / Posicionamento dos componentes Textos utilizando mesma Fonte (Nome, tipo e tamanho) Uso de MasterData para considerar múltiplos seguros Segue em anexo arquivo de impressão fastreport alterado para contribuição e atualização dos fontes: DAMDFe_Retrato-ComDadosDoSeguro.zip

Compreendo, mas essa forma de alterar o ini afeta diretamente a infra estrutura, dando acesso a parte restrita do servidor "arquivos". Acredito que isso poderia ser tratado somente para as situações das URLs, que devido a falta de padrões dos demais provedores existe situações específicas. A carga via arquivo .ini gera outros problemas: 1. Quando a prefeitura altera o provedor e a estrutura do conteúdo xml deles tem particularidades, Exemplo: 2024 era o proEL, em 2025 trocou para o proSaatri? 2. Agora com a mudança da reforma de 2025 para 2026, muitas prefeituras alteram para o provedor nacional, a leitura do XML é completamente diferente, não sendo possível carregar os dados do xml que havia sido emitido por outro provedor. 3. Não faz sentido alterar o arquivo .ini do client todo vez que precisar imprimir notas porque foram emitidos por provedores diferentes. O uso das propriedades do tipo do provedor "publico" e nome do provedor xProvedor "privado" carregado exclusivamente pelo arquivo .ini, gera um conflito e limita o uso do componente, além de abrir falhas em ter um type definido um provedor e o nome carregado forçadamente pelo .ini diferentes, como forme apresentei o código na abertura. O que acha e sugere sobre essa situação?

Devido ao momento atual da reforma tributária, com mudança dos provedores para o padrão nacional está ocorrendo por demanda, e ficar compilando .exe ou tendo que conectar no ambiente cliente a cliente, torna-se muito custoso. Como posso alterar o provedor de uma cidade runtime, de forma a carregar as definições escolhidas pelo usuário? Observei que as configurações de provedores esta condicionada a usar os dados do ini já embarcados como recurso, ou caso exista o arquivo carrega as configurações locais. Essa carga ocorre ao definir o código do município. Para tentar conseguir força a mudança, fiz a troca do provedor posterior ao código do município, porem internamente o ACBr faz verificações do descritivo "xProvedor" que não permite a escrita, carregando indevidamente os schemas do provedor do arquivo. O que posso fazer para conseguir atender essa necessidade? segue código exemplo: ACBr.Configuracoes.Geral.CodigoMunicipio := Emitente.Endereco.Cidade.CodigoMunicipio; // Se em parâmetro foi definido, redefine var LProvedorManual := StrToProvedor(Emitente.DOCe.NFSeProvedor)); if LProvedorManual <> TnfseProvedor.proNenhum then begin ACBr.Configuracoes.Geral.Provedor := LProvedorManual; ACBr.Configuracoes.Geral.Versao := Emitente.DOCe.VersaoNFSe; ACBr.Configuracoes.Geral.LayoutNFSe := Emitente.DOCe.LayoutNFSe; ACBr.SetProvider; end;

Quando nesse chamado ainda usava previewpages, atualmente o código foi alterado para pages, mas isso muda o arquivo modo designer, por isso acredito que seja válido a mudança que propus.

Notei que a impressão do DANFE está ficando com uma área fora da página de impressão, devido ao uso das margens via código. Isso ocorre porque o método que faz o ajuste de margens nas páginas, faz isso nas páginas já processadas que já estão prontas para impressão, porem como alguns componentes de impressão possuem "posicionamentos relativos", e utilizam da propriedade que permite "esticar" conforme o tamanho se necessário, ao alterar as margens altera também área de impressão vertical, mas a rotina utilizada possui uma falha, pois não muda o tamanho da página, apenas do conteúdo. Outra coisa que notei é que se usar o "modo designer" para adaptar o arquivo e executar a visualização, a configuração de margem não tem efeito, pois são gerados novos previews que já não são afetados/reprocessado runtime via código. Após analisar o código e os problemas, acredito que a única forma segura que permita definir essas configurações via código, ou via arquivo, que seja aplicável também em modo designer, seria usando uma variáveis do fast report no código ACBr, e utiliza-los no script do arquivo. Vantagens: Será utilizado a margens padrão do componente ou se definida via código. Se zeradas via código, permitirá usar as margens definida no próprio arquivo. Não obriga ter margem salvas no arquivo, mas é visível no preview normal quanto no preview do designer. Resolve o problema da área de impressão fora da página devido auto ajustes com elementos de esticam/crescem para apresentar todos descritivo Evita que o designer carregue configurações de margens do código, evitando gravar arquivos com margens que não deveria pertencer ao arquivo. Desvantagens: Requerer atualizar arquivos modelos .fr3 ACBrNFeDANFEFRDM.pas frxReport.Variables['MargemSuperior'] := DANFEClassOwner.MargemSuperior; frxReport.Variables['MargemInferior'] := DANFEClassOwner.MargemInferior; frxReport.Variables['MargemEsquerda'] := DANFEClassOwner.MargemEsquerda; frxReport.Variables['MargemDireita'] := DANFEClassOwner.MargemDireita; DANFeNFCe.fr3 begin if <MargemSuperior> > 0 then Page1.TopMargin := <MargemSuperior>; if <MargemInferior> > 0 then Page1.BottomMargin := <MargemInferior>; if <MargemEsquerda> > 0 then Page1.LeftMargin := <MargemEsquerda>; if <MargemDireita> > 0 then Page1.RightMargin := <MargemDireita>; end. ACBrNFeDANFEFRDM.pas DANFeNFCe5_00.fr3

olá, existe alguma previsão, tempo médio para ser analisada?

olá, existe alguma previsão?

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

Necessidade identificada devido essa ocorrência também carregar o valor recebido, embora não tenha a data de crédito. Ao fazer a conciliação ocorreram conflitos de validações.

AcbrBoletoSicredIntensaoPagamento.rar

Atualização CNAB 240 e 400 banco sicred: Intenção de pagamento Segue em anexo, manuais e ajustes dos fontes para atualização do SVN. Criei mais um TACBrTipoOcorrencia: toRetornoIntensaoPagamento ACBrBancoSicredi - TACBrBancoSicredi.CodMotivoRejeicaoToDescricao - ACBrBanco.ACBrBoleto.LayoutRemessa: 400 toRetornoIntensaoPagamento: case AnsiIndexStr(CodMotivo, ['00','H5']) of 0 : Result:= '00-Devolução de Comunicado pelos Correios'; 1 : Result:= 'H5-Recebimento de liquidação fora da rede Sicredi – VLB Inferior – Via Compensação '; else Result:= PadLeft(CodMotivo,2,'0') +' - Outros Motivos'; end; ACBrBancoSicredi - TACBrBancoSicredi.TipoOcorrenciaToDescricao - ACBrBanco.ACBrBoleto.LayoutRemessa = c240 91: Result := '07-Intenção de pagamento'; ACBrBancoSicredi - TACBrBancoSicredi.TipoOcorrenciaToDescricao - ACBrBanco.ACBrBoleto.LayoutRemessa = c400 07: Result := '07-Intenção de pagamento'; ACBrBancoSicredi - TACBrBancoSicredi.CodOcorrenciaToTipo - ACBrBanco.ACBrBoleto.LayoutRemessa = c240 ACBrBancoSicredi - TACBrBancoSicredi.CodOcorrenciaToTipo - ACBrBanco.ACBrBoleto.LayoutRemessa = c400 ACBrBancoSicredi - TACBrBancoSicredi.TipoOCorrenciaToCod - ACBrBanco.ACBrBoleto.LayoutRemessa = c240 ACBrBancoSicredi - TACBrBancoSicredi.TipoOCorrenciaToCod - ACBrBanco.ACBrBoleto.LayoutRemessa = c400