Valdir Dill

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.

Bom dia Atualizei e reinstalei e não deu mais erros. Tente instalar marcando "apagar arquivos antigos do disco". Obrigado.

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

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º 97 O 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.

Show de bola! Obrigado a todos pelas dicas!

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.

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.

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.

Bom dia, Sei que este canal não é bem para dúvidas sobre o Fortes Report. Mas, como já tentei , mas como já tentei tudo que podia e o Acbr tem muito a ver com o FR, talvez alguem possa me dar alguma dica para o problema q estou enfrentando. É assim: qualquer aplicação onde tenho um componente RLReport, ao tentar carregar o form que abriga esse RLReport, ocorre uma demora exagerada. Chega a dar 10 segundos... Isso ocorre tanto no projeto (ao executar um shift+F12), como depois, na aplicação em runtime. Só ocorre na primeira chamada de um form naquele computador após ele ter sido reiniciado. Se eu tiver duas aplicações, naquela que acionar primeiro um form que abrigue um RLReport, vai ocorrer a demora. Dali em diante, seja na mesma aplicação, seja em outra aplicação, o problema não ocorre mais até que se reinicie o micro de novo. Fiz um debug e ocorre exatamente no form.create. Se eu tirar o componente rlreport do form, o problema não acontece, ou seja, ao que parece, o Delphi precisa construir algo ao carregar a primeira vez o form com um rlreport naquela máquina. Delphi 10.3.3. Fortes Report CE atualizado. Obrigado.

Bom dia, Beleza. Atualizado, testado e aprovado, rs.. Obrigado.

Bom dia, O município de Uruçuí-PI (2211209) teve mudança de provedor. Novas URLs Produção:http://177.129.224.58:8080/IssWeb-ejb/IssWebWS/IssWebWS?wsdl Homologação:http://fi1.fiorilli.com.br:5663/IssWeb-ejb/IssWebWS/IssWebWS?wsdl Em anexo envio os arquivos Cidades.ini e Fiorilli.ini atualizados e testados. Obrigado. Cidades.ini Fiorilli.ini

Bom dia, Na minha opinião, se a houver possibilidade do recebedor fazer uma espécie de leitura on-line dos pagamentos recebidos através de uma API ou uma espécie de arquivo de retorno, com certeza, no dia seguinte à liberação do PIX, o boleto sem registro cai por terra. Bastará gerarmos um ID (o mesmo "nosso número", que sua usa hoje no caso do boleto) , registrar esse ID no qrCode que será passado ao pagador e também registrar o ID no sistema gerenciador financeiro e depois fazer a leitura dos IDs pagos no dia. Não vejo como como isso não venha a ser uma realidade, principalmente por dois motivos: 1) O PIX é praticamente em tempo real. Muito melhor que boletos. Já tive casos do boleto demorar 4 dias para creditar por conta de feriados; 2) O PIX não tem custo. Abraços

Boa tarde, Dá uma olhada em -> Abraços.

Eu também acredito que seja isso...alguma coisa no gerenciador do certificado talvez... Mas não tivemos acesso à máquina do usuário para uma análise mais detalhada. Como foi um caso beeeem isolado, deixamos para lá e orientamos o usuário a comprar um A1 na próxima renovação de certificado, hehe!

Boa tarde, Também temos um usuário onde isso acontece. Num universo de centenas de usuários, apenas um único ocorre isso. Certificado A3. A senha é alimentada tudo certinho no componente. Tanto é que em todos os demais usuários que usam o mesmo sistema, o processo de assinatura de XMLs ocorrem normalmente, ou seja, sem pedir a senha. Mas nesse único usuário, assim que o procedimento de assinar é acionado, abre-se a telinha do certificado para informar a senha. É como se não tivesse sido informada a senha no componente. Obriagdo

Bom dia

Bom dia, Só atualizar os Schemas. Use os arquivo que estão no svn que resolve. Abraços.

Boa noite, Tivemos vários usuários que ao utilizar essa impressora em NFCe com mais de 50 itens, imprimia apenas até o item 50. A segundo eles (não chegamos a testar aqui em laboratório pois não temos esse modelo) é atualizar o Driver da impressora que o problema desaparece. Abraços.

Boa tarde, Corrigido na 18034. Obrigado.

Boa tarde, É só você localizar esse arquivo novo na pasta dos fontes e adicionar esse path no library do Delphi. Abraços.

Bom dia, Atualizei os fontes neste momento (18009). Mas as impressões do código de barras de da chave continuam desalinhados no MDFe. No print anexo dá para verificar. Obrigado.

Boa tarde, Ao que tudo indica está tudo normal novamente no envio de NFe produtor rural SEFAZ-PA. Depois de 3 dias a SEFAZ-PA insistindo que o problema era no sistema emissor da nota, milagrosamente o problema se resolveu sem nenhuma alteração nossa sistema, hehe! Tópico resolvido! Obrigado.

Existe alguma forma de comprovar para a SEFAZ que o sistema está enviando o XML para o WS correto, ou seja, SVRS? O problema é que a SEFAZ-PA alega que o sistema está enviando para o WS antigo (SVAN). Aí o cliente nos cobra. Até onde verifiquei, isso não fica nada registrado nos XML, ou fica? Obrigado.