Valdir Dill
-
Total de ítens
962 -
Registro em
-
Última visita
-
Days Won
5
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Valdir Dill
-
-
Boa tarde,
Alguém conhece alguma rotina ou componente (Delphi) que vabilize saber onde (coordenadas) se clicou em um .pdf? Já tivemos algum progresso utilizando com API Hook, mas não conseguimos fazer funcionar legal.
Queremos fazer um assinador de .pdf com certificado digital. Estamos usando a dll ChilKat, mas ela não tem essa opção. Assinar funciona tudo beleza, mas para posicionar o quadro da assinatura é preciso enviar os valores (margens). Funciona, mas se pudéssemos abrir o pdf para o operador clicar em uma área livre do documento e aí retornar as coordenadas de onde foi clicado, seria muito mais prático.
Assim como fazem o Adobe, gov.br, ...Obrigado!
-
Boa tarde,
Temos um caso aqui que é parecido (se não for igual) ao do colega @bfbraz
Um MDFe que foi autorizado e encerrado no dia 18/04. Quando efetuamos a consulta dele com -> ACBrMDFe1.Consultar, ele retora ACBrMDFe1.WebServices.Consulta.cstat = 132, ou seja, encerrado.
Porém o ACBrMDFe1.WebServices.Consulta.procEventoMDFe.Count é igual a 0.
Aí nossa regra de negócios, ao buscar os eventos vinculados ao MDFe, não encontra o cancelamento e, por conseguinte, não consegue tratar. Até poderia pegar só o ACBrMDFe1.WebServices.Consulta.cstat, mas aí não temos os demais dados (data de encerramento, protocolo de encerramento,...).
Obrigado!
-
2 minutos atrás, adilsonpazzini disse:
Pior que ta dando HTTP500 agora ..
Deve estar fora do Ar
Bom dia,
Estávamos com esse erro desde sexta passada, que foi quando iniciou a obrigatoriedade das MEIs usarem o novo serviço. Mas, de ontem para cá, está melhorando gradativamente. Às vezes precisa fazer 2 ou 3 tentativas e ocorre esse erro, mas depois vai.
É instabilidade no WS mesmo.
Abs.
-
4
-
-
3 horas atrás, Juliomar Marchetti disse:
Muitos componentes de terceiros?
no library path deveria estar só com os path dos arquivos compilados *.dcu
e no browsing path é que fica dos fontes dai o delphi consegue gerenciar senão ele fica indexando um monte de path e fontes
Boa tarde,
Pela quantidade de componentes acredito que não seja a causa. Temos 5 componentes de terceiros, além é claro dos componentes Acbr.
De toda forma, vamos tentar implementar sua sugestão sobre os paths (fontes e .dcus) assim que possível.
Obrigado!
-
3 horas atrás, Victor H. Gonzales - Panda disse:
Bom dia,
Nas propriedades do seu projeto, coloque os "paths" das units no searchpath, deve resolver o seu problema
Boa tarde,
Agradeço pela sugestão, mas não é a solução. Já havia tentado isso. Coincidência ou não isso acontece desde que instalamos o Delphi 10.4.
Mas tranquilo, vamos tocando assim mesmo, rs.
Obrigado!
-
Bom dia,
Estou com uma dúvida/dificuldade não relacionada diretamente ao Acbr e sim ao Delphi...
É assim: em uma classe declarada em uma unit qualquer, quando se clica com o mouse sobre o nome da classe e se estando com o ctrl pressionado, deveria abrir aquela unit onde eh criada aquela classe, certo?
Ou então quando se posiciona o mouse sobre a classe, deveria aparecer um "popup" com o nome da unit onde aquela classe está declarada, correto?O problema é que aqui, isso ocorre, às vezes sim e, às vezes não...
Nos faz falta isso, pois é algo bastante usado...No print anexo, peguei como exemplo a AcbrJSON.pas, mas poderia ser qualquer outra unit/classe, pois acontece em várias outras.
O problema também não é a unit em si e sim a classe. Note que no segundo print, temos outra classe na mesma unit e nesta classe funciona direitinho, ou seja, mostra a unit onde a classe é criada.Alguma sugestão?]
Obrigado!
-
Bom dia,
Por motivos que não se faz necessário explicar aqui, nem sempre conseguimos atualizar o ACBrNFeServicos.ini em atualizações da nossa aplicação. Aí, pode ocorrer da versão da aplicação estar atualizada, mas o ACBrNFeServicos.ini não estar. Ele pode existir na pasta, mas desatualizado.
Ocorrendo essa situação, nos surge a seguinte duvida: se o arquivo ACBrNFeServicos.ini estiver na pasta da aplicação, o Acbr vai sempre obrigatoriamente ler os endereços de WS do arquivo ou isso dependerá de DMDocEletr.ACBrNFe1.Configuracoes.Arquivos.IniServicos estar setado com "ACBrNFeServicos.ini"?
Por exemplo, se DMDocEletr.ACBrNFe1.Configuracoes.Arquivos.IniServicos = '', mas ACBrNFeServicos.ini existir na pasta da aplicação, o que vai acontecer? O componente vai usar o arquivo mesmo assim ou vai buscar as URLs no .res que vai empacotado na aplicação?
Obrigado!
-
11 minutos atrás, Daniel Simoes disse:
Apliquei uma possível correção, no commit: Commit [r25429]
Ok. Corrigido.
Obrigado!
-
Bom dia,
Estamos tendo o erro do print anexo quando se tenta consultar ACBrIBGE1.BuscarPorNome( ...
O problema só ocorre se o ACBrIBGE.txt não existir ou, pelas configurações do CacheDiasValidade, for necessário atualizá-lo.
Testamos inclusive no demo do componente.
Obs.: se eu colocar o endereço https://servicodados.ibge.gov.br/api/v1/localidades/estados/41/municipios no browser, não dá erro e mostra a lista de cidades certinho.
-
Bom dia,
Acredito ser instabilidade no WS.
Também tivemos esse problema e logo em seguida, sem alterar nada, a nota foi aceita.
-
Boa tarde,
Deixe-me ver se entendi.
Devemos fazer a consulta das notas emitidas contra o cliente através do DistribuicaoDFePorUltNSU para listá-las.
Em seguida ele (o usuário) manifesta as notas e aí deve ser feita uma nova DistribuicaoDFePorUltNSU para que desta vez o XML da nota retorne ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Items[I].XML, seria isso?
Obrigado!
-
Boa tarde,
Acho bem positiva a ideia. Ficaria bem mais transparente.
Temos essa situação de usar os enumeradores (If Provedor = proGinfes then), mas acho seria muito simples adaptar o código à nova nomenclatura.
Obrigado!
-
1 hora atrás, Italo Giurizzato Junior disse:
Bom dia Valdir,
Não estamos mais dando manutenção aos fontes do componente antigo: ACBrNFSe, somente no componente novo ACBrNFSeX.
Por favor procure atualizar todos os fontes de todas as pastas, reinstale a suíte ACBr marcando os 2 novos componentes (ACBrNFSeX e o DANFSE) e inicie os testes usando o programa exemplo do novo componente.
Já estamos testando/usando o AcbrNFSeX há algumas semanas. Por um lapso esquecemos que o novo componente não usa mais o cidades.ini para ver URLs, conforme inclusive está informado na documentação de migração de componente antigo para o novo. Peço desculpas...
Obrigado!
-
2
-
-
Em 10/09/2021 at 15:30, Italo Giurizzato Junior disse:
Boa tarde,
Já esta no SVN.
Bom dia,
No cidades.ini ainda está marcando esse município como vinculado ao provedor antigo, Fiorilli.
[2101202]
Nome=Bacabal
UF=MA
Provedor=SigCorp
NomeURL_H=testeabrasfbacabal.sigcorp
NomeURL_P=abrasfbacabal.sigcorpObrigado.
-
7 minutos atrás, Joas Vilas Boas Fernandes disse:
Valdir,
Não da erro na instalação.
Veja se carrega o delphi normal?Sim, primeiro estava dando esse erro ao acessar o Delphi. Aí o pessoal fez um ajuste e passou a dar erro ao tentar instalar...
Mas agora não está dando mais nenhum erro, nem ao instalar e nem ao acessar o Delphi.
-
1
-
-
Bom dia
Atualizei e reinstalei e não deu mais erros.
Tente instalar marcando "apagar arquivos antigos do disco".
Obrigado.
-
1
-
-
Em 31/05/2021 at 12:38, Daniel Simoes disse:
@BigWings, o que acha ?
Uma solução, seria editar o próprio arquivo do IBPT... isso invalidaria ele, de alguma forma ?
Boa noite,
Não, não invalida. Na tabela anterior havíamos feito isso, ou seja, mexemos nos 27 arquivos antes de liberar para o usuário baixar. E funcionou legal.
Mas concluímos que dá bem menos trabalho incluir esse stringReplace que citei na postagem anterior.
Abraços
-
Bom dia,
Só para contribuir...
O erro ocorreu aqui também. Acontece porque na linha 6093 de todos os arquivos .csv, na tabela 21.1.H e agora também na 21.1.I , traz um texto com duas aspas duplas repetidas.
39233090;01;0;""Ex" 01 -
Isso faz com que o quebralinha gere um erro.
A solução que adotamos foi -> VLinha := StringReplace(VLinha,'""Ex"','"Ex',[rfReplaceAll]), direto na nossa aplicação, sem mexer nos fontes Acbr.
Obrigado
-
2
-
-
2 minutos atrás, Juliomar Marchetti disse:
Está usando FireDAC?
Sim.
-
Bom dia,
Estou com um problema que ocorreu já umas duas vezes em 1 cliente.
O problema é off-tópic, mas como tem relação com gravação de dados em DFes, talvez alguém do grupo já tenha vivido situação semelhante e agradeço se puder me ajudar.É o seguinte: para gravar os XMLs de DFes no banco de dados, utilizamos a função zip da acbrUtil.
O erro acontece quando vamos descompactar (unzip) o dado gravado. Dá o "error reading zip file".
Analisando o dado gravado no banco nesse campo aparece o seguinte texto:
x��:[��Ȓ��+��<���"�zi�&WQnrQ��|�(�
O texto é bem maior, mas tudo assim, com caracteres estranhos. É como se o sistema ao gravar ou então o banco de dados tivesse disparado uma conversão em outro encoding.Investigando mais, verificamos que não é o zip() que causou o problema. Imagino eu que possa ser alguma coisa na máquina do usuário.
Em outros campos de outras tabelas onde o conteúdo do texto tenha acentos, ocorreu o mesmo problema, ou seja, ficou gravados caracteres estranhos no banco.
Por exemplo:
Um texto que deveria estar assim: Iniciou a NFe 95 série 1, vinculada à venda n° 97
Está assim: Iniciou a NFe 95 série 1, vinculada à venda nº 97O mais estranho ainda é que isso ocorreu apenas em um dia específico. Nos dias anteriores e nos dias seguintes, o mesmo sistema, no mesmo banco de dados, tudo foi gravado corretamente.
É como se alguma coisa na máquina, nesse dia e apenas nesse, tivesse mudado e depois retornado ao normal.O charset do banco é CHARACTER SET WIN1252 COLLATE WIN_PTBR.
Se alguém já tiver passado por uma situação dessas e puder me dar alguma dica...
Obrigado.
-
2 minutos atrás, EMBarbosa disse:
Que legal que conseguiu Valdir. Vai ser isso mesmo.
É provável que o Windows esteja consultando o driver pra alguma coisa e ele está demorando pra responder...
Mas fiquei feliz que com um pouco de paciência você conseguiu descobrir onde o problema estava. A boa notícia é que provavelmente isso não vai afetar seu programa em outras máquinas, porque elas não devem ter essa impressora.
Show de bola!
Obrigado a todos pelas dicas!
-
8 minutos atrás, Juliomar Marchetti disse:
duvida o fortes foi atualizado? pois recente foi feito melhorias nele
Sim, FR CE atualizadíssimo.
Boa tarde,
Acho que achei a causa do problema. Ao que tudo indica, é alguma coisa na minha impressora padrão (uma HP Laser 1022), alguma coisa no driver eu acho.
O problema ocorre quando passa na rotina DC := CreateHandleFunc(PChar(Driver), PChar(Device), PChar(Port), FDevMode) da vcl.Printes.pas.
Excluí essa impressora do Windows e aí não ocorreu mais o problema.
Obrigado.
-
1
-
-
1 hora atrás, Daniel Simoes disse:
Me parece ser a carga de alguma DLL...
Tente rodar o programa em uma V.M. "crua", para ver qual poderia ser (ele acusaria erro pela falta da DLL)
Basta informar para a IDE, nessa mesma janela, onde estão os fontes do FastReport...
Consegui debugar no FR.
Ao que parece tem mesmo a ver com a (as) impressora, conforme o @EMBarbosasuspeitou.
Debuguei e verifiquei que o problema ocorre na rotina dc := Printer.Handle da RLPrinters do Fortes. Essa rotina aciona a procedure TPrinter.SetState(Value: TPrinterState) da vcl.Printers (unit do Delphi).
Tenho apenas 5 impressoras instaladas no Windows. Em teste, a causa, não poderia ser pela quantidade.
Mas vou cavar mais para tentar ver se encontro a causa.
Obrigado.
-
2
-
-
29 minutos atrás, EMBarbosa disse:
Bom dia Valdir.
O Fortes tem algum código de inicialização mesmo. Mas é difícil saber exatamente o que está causando a lentidão sem ter um código pra reproduzir.
Sugiro você tentar montar o código mais simples possível que reproduza o problema. Por exemplo, se criar uma nova aplicação, apenas com esse componente no form isso acontece?
Há a mesma lentidão se executar como administrador? Existe antivírus ou alguma aplicação de proteção bancária na máquina?
Depois teste a mesma aplicação em outra máquina. É bom que você verificar se não é alguma característica da máquina que está afetando a lentidão. Por exemplo, talvez existam muitas impressoras alistadas... (só um exemplo...).
Mas o mais assertivo, seria debugar o código do Fortes pra verificar onde a lentidão está.
Bom dia @EMBarbosaobrigado pelas dicas.
Já tentei todas elas (executei como adm, desabilitei antivírus, defender, não tem programa de banco instalado, ...) Em relação a uma aplicação, fiz uma somente com a criação do componente em runtime, sem chamar form e dá o mesmo problema. No comando do TRLReport.create acontece a demora. Vide print anexo.
Quando tento debugar, dá o erro anexo. Tem alguma sugestão para esse erro?
Obrigado.
Nova licença Delphi 30anos
em Object Pascal - Delphi & Lazarus
Postado
Boa tarde,
Só para contribuir, ok?
Aqui nós dependemos do Enterprise, que custa 2 vezes mais, rs.. justamente e tão somente por causa do Firedac.
Então, se você vai ter que refazer todo seu código para utilização de novos componentes, eu recomendaria usar o Zeos, por exemplo, que é free. E aí você pode ficar no Rad Professional.
Acredite, não é apenas o valor de aquisição da licença atual. Você vai ter esse custo, pelo menos a cada 2 a 3 anos, pois as versões Delphi depois do 7, sempre vêm com bugs e são corrigidos em updates futuros. Se você não tiver mais suporte da licença, precisa comprar de novo. Aí você começa a usar e vai criando dependência. Compra hoje e daqui 2,3, ... anos você se obriga a comprar novamente.
Pelo menos nossa experiência está sendo assim.
Nós não temos como fugir do Firedac, pois o custo seria maior por conta do tamnanho que o sistema está hoje. Se nao fosse isso, com certeza nossa opção seria o Delphi Pro + Zeos.
Esperto ter ajudado!
Abraços