Valdir Dill

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

Certo. Isso seria algo provisório para ele poder emitir as notas agora. Mas eu estava me referindo mais sobre a questão de como comunicar isso (o que preciso informar) para que os fontes no repositório do Acbr sejam atualizados. Obrigado.

Bom dia, De acordo com o arquivo cidades.ini do Acbr, o provedor de Uruçuí-PI (2211209), o provedor para NFSe seria o ISSIntel. Mas, segundo um cliente de lá, a prefeitura informa que o provedor deles é o Fiorilli. Nesta endereço, http://177.129.224.58:8080/issweb/home.jsf, que é o site da prefeitura, no menu "Dúvidas -> Manual de Credenciamento", é feito o download do manual do Fiorilli, o que confirma a informação do usuário. O que precisa para mudar isso no Acbr? Só mudar o provedor no cidades.ini? Obrigado.

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, Ok, tudo certo agora. Obrigado!

Bom dia, Numa das últimas atualizações, a ACBrBoletoConversao.pas teve o tipo TACBrPessoa = (pFisica,pJuridica,pOutras) implementado com o enumerador pNenhum para atender demanda relatada neste tópico Porém, atualizei os fontes agora pouco e não consta mais o pNenhum. Qual a orientação? Houve alguma mudança mesmo? Obrigado.

Testado e aprovado! Show de bola! Obrigado.

Arquivos em anexo. Obrigado. 26200610241975000165580010000020501305985767-mdfe.xml 26200610241975000165580010000020501305985767-MDFeDFe.xml 26200610241975000165580010000020501305985767-ped-sit.xml 26200610241975000165580010000020501305985767-ped-sit-soap.xml 26200610241975000165580010000020501305985767-sit.xml 26200610241975000165580010000020501305985767-sit-soap.xml

Bom dia, Consultei o documento diretamente no portal da SEFAZ (vide anexo).

Bom dia, Estou com uma situação em um MDFe e gostaria de sugestão de como poderia contornar o problema. No nosso sistema o MDFe está como autorizado. Mas no WS já está encerrado. Isso indica que o XML com o encerramento foi enviado, mas, por algum motivo, não houve a gravação do retorno do WS no BD do sistema. Quando isso ocorre, fazemos uma consulta (ACBrMDFe1.Consultar) e, se for retorno 132, é porque está encerrado; se for 101, é porque está cancelado,... Então, para atualizar o BD, executamos a seguinte rotina: if ACBrMDFe1.WebServices.Consulta.cstat = 101 then begin for I := 0 to ACBrMDFe1.WebServices.Consulta.procEventoMDFe.Count-1 do if ACBrMDFe1.WebServices.Consulta.procEventoMDFe.Items.RetEventoMDFe.InfEvento.tpEvento = teCancelamento then begin FDQueryMDFe.FieldByName('DATA_CANC').AsDateTime := ACBrMDFe1.WebServices.Consulta.procEventoMDFe.Items.RetEventoMDFe.retEvento.Items[0].RetInfEvento.dhRegEvento; FDQueryMDFe.FieldByName('PROT_CANC').AsString := ACBrMDFe1.WebServices.Consulta.procEventoMDFe.Items.RetEventoMDFe.retEvento.Items[0].RetInfEvento.nProt; FDQueryMDFe.FieldByName('SITUACAO').AsString := 'Cancelada'; break; //para sair do loop de eventos. end; end else if ACBrMDFe1.WebServices.Consulta.cstat = 132 then begin for I := 0 to ACBrMDFe1.WebServices.Consulta.procEventoMDFe.Count-1 do if ACBrMDFe1.WebServices.Consulta.procEventoMDFe.Items.RetEventoMDFe.InfEvento.tpEvento = teEncerramento then begin FDQueryMDFe.FieldByName('DATA_ENCERR').AsDateTime := ACBrMDFe1.WebServices.Consulta.procEventoMDFe.Items.RetEventoMDFe.retEvento.Items[0].RetInfEvento.dhRegEvento; FDQueryMDFe.FieldByName('PROT_ENCERR').AsString := ACBrMDFe1.WebServices.Consulta.procEventoMDFe.Items.RetEventoMDFe.retEvento.Items[0].RetInfEvento.nProt; FDQueryMDFe.FieldByName('SITUACAO').AsString := 'Encerrada'; break; //para sair do loop de eventos. end; end; Funciona beleza. Contudo, estamos com um MDFe atípico. Ele consta lá no WS como "Encerramento Fisco", ou seja, foi a SEFAZ q fez o encerramento. O problema é que ao executar a consulta acima, temos o retorno de 10 eventos, mas todos com o ACBrMDFe1.WebServices.Consulta.procEventoMDFe.Items.RetEventoMDFe.InfEvento.tpEvento = teNaoMapeado. Aí não dá para saber qual deles é o evento de encerramento para pegar o dhRegEvento e nProt. Alguma dica sobre essa situação? Obrigado!

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

Boa tarde, Solução encontrada: Sacado.SacadoAvalista.Pessoa := pOutras; Isso gera valor 9 na coluna 154 e o arquivo foi aceito pelo banco. Testes feito com banco Santander.

Boa tarde, Estou tendo rejeição do arquivo remessa santander, cnab240. O problema começou a ocorrer após uma das últimas atualizações dos fontes. Erro: NUM.INSC.(CNPJ)SACADOR/AVAL.NAO NUMERICO Print anexo. Segundo nota do banco, o problema está no registro Q, posição 154 a 154 Essa posiçao define o tipo de pessoa do sacado.Avalista (Sacado.SacadoAvalista.Pessoa) Analisando no fonte do componente temos: with ACBrTitulo do begin case Sacado.SacadoAvalista.Pessoa of pFisica : Result := '1'; pJuridica : Result := '2'; pOutras : Result := '9'; else Result := '0'; end; end; Como eu nao alimento essa propriedade - Sacado.SacadoAvalista.Pessoa - o componente assume 1 por default. Porém o banco diz que o valor dessa coluna no remessa deveria ser "0". A pergunta é: se só há as opções pFisica, pJuridica e pOutras, como é que alimento Sacado.SacadoAvalista.Pessoa para q fique com valor 0? rejeição remessa de arquivo.pdf

Ok, unit alterada, em anexo. Obrigado. pnfsConversao.pas

Boa tarde, Se eu fizer ProvedorToStr(proFISSLEX), vai retornar FISSLEX. Porém, o arquivo .ini desse provedor na pasta dos arquivos está assim FISSLex.ini. No nosso sistema fazemos assim: hospedamos os .ini todos no nosso servidor. Aí, no sistema, temos a rotina que define o nome do arquivo para download, conforme for a cidade/provedor do usuário. Porém, se tentar baixar o arquivo FISSLEX.ini, não vai existir, já que a url para donwload é case sensitive. Reparei que os demais provedores estão no padrão correto, ou seja, se o nome do provedor é BHISS, por exemplo, tudo maiúsculo, o arquivo .ini também será BHISS.ini. Se for parte minúsculo, essa parte também será minúsculo no nome do arquivo. Sugiro que essa função ProvedorToStr da pnfsConversao.pas tenha o texto FISSLEX alterado para FISSLex ou então mudar o nome do ini para FISSLEX.ini. Obrigado.

Bom dia @Juliomar Marchetti, Acho que consegui me encontrar, rs... Não estava me achando porque estava tentando criar o registro 1300 no bloco 0. O correto é no bloco 1, certo? Por isso pensei que talvez não houvesse suporte ao registro 1300, mas consegui dar o tranco aqui, rs e agora vai. Obrigado.

Boa noite, Estamos precisando implementar a geração do SPED Fiscal para registros 1300, 1310, 1320, ...ou seja, são registros específicos para postos de combustíveis. No demo do Acbr e mesmo fuçando no componente não encontrei muita coisa sobre isso. Só encontrei uma referência do registro 0206. Gostaria de saber se algum colega poderia me auxiliar com algum exemplo. Um pontapé inicial já ajudaria. Obrigado.

Perfeito. Esclarecido. Obrigado.

Você diz que a Impressão está ocorrendo mesmo que você não chame o método "Imprimir" ? Exato. A impressão acontece assim que primeiro ACBrPosPrinter1.Buffer.Add('... é executado. Mas analisando melhor meu código, notei que estava com ACBrPosPrinter1.LinhasBuffer = 1 Se mudar para ACBrPosPrinter1.LinhasBuffer = 0, aí não imprime se não executar ACBrPosPrinter1.Imprimir(.... É isso mesmo então? Ou seja, se ACBrPosPrinter1.LinhasBuffer = 1, então ACBrPosPrinter1.Buffer.Add(' inicia a impressão e, nesse caso, dispensa-se ACBrPosPrinter1.Imprimir(...? Obrigado.

Bom dia, Com base no demo do posPrinter utilizamos esse componente da seguinte forma. ConfiguraACBrPosPrinter; //alimenta dados da porta, impressora, etc. ACBrPosPrinter1.Ativar; ACBrPosPrinter1.Buffer.Add('</zera>'); ACBrPosPrinter1.Buffer.Add('<n></ce>Título</n>'); ACBrPosPrinter1.Buffer.Add('</ae></linha_simples>') ACBrPosPrinter1.Buffer.Add('Linha 1'); ACBrPosPrinter1.Buffer.Add('Linha 2'); ACBrPosPrinter1.Buffer.Add('Linha 3'); ACBrPosPrinter1.Imprimir('', True, True, True, 1); Está funcionando tudo ok. A questão é que esta última linha ACBrPosPrinter1.Imprimir('', True, True, True, 1), se ela for executada ou não, não faz diferença, ou seja, a impressão ocorre de toda forma, mesmo que eu tirar/comentar essa linha. Pergunto: - É isso mesmo ou estou fazendo algo errado? - Se a impressão acontece, mesmo sem essa linha, então qual seria a função desse método ACBrPosPrinter1.Imprimir? Obrigado!