Valdir Dill

Mesmo resultado.

LibXML2

Não entendi. Eu estou ciente que uma vírgula que seja alterada no XML vai invalidar o XML todo. Mas não foi esse o caso. Esse XML é um arquivo baixado pelo usuário direto do portal da SEFAZ. Outro ponto, como já mencionei, é que o XML é validado no validador da SEFAZ-RS. Obrigado.

Bom dia, Estou tentando validar o xml anexo com ACBrNFe1.NotasFiscais.Validar... ocorre o erro "...no matching global declarationo available...'' (print em anexo). No validador da SEFAZ-RS não dá nenhum erro. Para adiantar uma possível análise, informe que relatei a situação chat do SAC e tive a resposta: "Big Wings: Testei aqui pelo Notepad++, validando o XML todo contra o schema procNFe_v4.00.xsd ele valida, mas se extrair o grupo <NFe> e validar contra o nfe_v4.00.xsd, que é o que o ACBr faz, causa erro de validação. Acho melhor abrir um tópico no fórum". Alguma sugestão da causa/solução dessa situação? Obrigado. 50201004970863000142550010000110291706594010-NFe.xml

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

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.