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