Ir para conteúdo
  • Cadastre-se

Valdir Dill

Membros Pro
  • Total de ítens

    935
  • Registro em

  • Última visita

  • Days Won

    5

Posts postados por Valdir Dill

  1. 4 minutos atrás, Italo Jurisato Junior disse:

    Valdir,

    Vamos aos porquês.

    Porque no validar da SEFAZ diz que o XML é valido?

    Simples, se o XML possuir a tag procNFe o validador da SEFAZ se utiliza do schema procNFe_v4.00.xsd, se não tem a tag e sim a tag NFe ele usa o schema nfe_v4.00.xsd para validar o XML.

    O tem XML possui a tag procNFe e esta tem o namespace, logo ele é validado com sucesso.

     

    Porque no validador do ACBrNFe diz que o XML é invalido?

    Simples, o componente extrai da tag procNFe a tag NFe e suas filhas e usa o schema nfe_v4.00.xsd para validar, como a tag NFe esta sem o namespace ocorre o erro.

    O componente tem esse comportamento de pegar somente a tag NFe e suas filhas para validar, pois antes de enviar a nota para a SEFAZ a mesma é validade e o XML antes do seu envio não tem a tag procNFe.

     

    Analisando o código do componente notamos que é mais simples acrescentar o namespace caso este não exista no momento da validação em vez de trocar os schemas.

    O XML original não é afetado, pois tudo ocorre em memória e o XML é validade sem ocorre o erro por falta de namespace.

    Certo, entendi.

    Então o XML que fica lá na SEFAZ não é o mesmo daquele gerado pelo sistema (via Acbr)? Porque a pergunta? porque antes do nosso sistema enviar o XML é feita a validação dele e valida, tudo certo. Porém, agora, ao tentar fazer a mesma validação, mas no arquivo baixado do portal, dá o erro. 

    Portanto, se antes validade e agora não...me perdoe se estou falando besteira, rs...mas é o que eu entendi da situação.

  2. 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.
     

     

    ErroValidar.png

    validaSEFAZ.png

    50201004970863000142550010000110291706594010-NFe.xml

  3. 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!

  4. 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.

    • Curtir 1
  5. 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.

    • Curtir 2
  6. 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.

    FortesDebug.png

  7. 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.

  8. 11 minutos atrás, BigWings disse:

    Alterar o provedor no arquivo Cidades.ini e informar a URL de recepção para a cidade específica no arquivo Fiorilli.ini, na seção [URL_P].

    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.

  9. 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.

  10. 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

    • Curtir 1
  11. 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.

     

     

     

    • Curtir 1
  12. 18 minutos atrás, Italo Jurisato Junior disse:

    Bom dia Valdir,

    No XML de retorno consta os eventos: 310112 = Encerramento Fisco (que não constava na lista de eventos) e o 510620 = Registro de Passagem Automático.

    Fiz uma alteração em duas units para que esses dois eventos sejam identificados.

    O de encerramento recém incluído tem o enumerador: teEncerramentoFisco e o outro teRegistroPassagemBRId.

    Favor atualizar os fontes e faça novos testes.

    Testado e aprovado!

    Show de bola!

    Obrigado.

    • Curtir 3
  13. 21 minutos atrás, Italo Jurisato Junior disse:

    Bom dia Valdir,

    Favor anexar o XML de retorno da consulta.

    Se o valor de tpEvento é teNaoMapeado isso significa que o código do evento de Encerrando Fisco é diferente do Encerramento realizado pelo emitente.

     

    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

  14. 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!

  15. 1 hora atrás, Denis Queiroz disse:

    Bom dia, o meu problema é o mesmo deste tópico no caso o amigo resolveu usando outros gerando o valor 9 na coluna 154, mas atualmente eu gero como 0, esta opção é válida no manual, onde assume o valor de "Não informado" e não "Outros" conforme foi sugerido, como o Juliomar mencionou no tópico criar um enumerador como nenhum seria o correto, irei fazer uma alteração no meu componente, e qualquer coisa posso anexar aqui.

    EDIT

    Anexado o novo enumerador, meu fonte do ACBR está atualizado até o dia 03/08/2020 devido a esta outra correção.

     

    ACBrBoleto.pas 207 kB · 0 downloads ACBrBoletoConversao.pas 8 kB · 0 downloads

    Boa tarde,

    Dá uma olhada em -> 

    Abraços.

     

     

  16. 5 horas atrás, Juliomar Marchetti disse:

    Creio que precise ser criado o enumerador pNenhum e informar.

    vou conversar aqui e lhe retorno

    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.

    • Curtir 3
  17. 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

  18. 10 minutos atrás, Italo Jurisato Junior disse:

    Boa tarde Valdir,

    É preciso sim fazer uma padronização.

    A grafia do enumerador, do retorno da função ProvedorToStr bem como o nome do arquivo INI tem que ser exatamente a mesma.

    No caso do provedor em questão deve ser FISSLex, ou seja, proFISSLex, retorno da função FISSLex e FISSLex.ini

    Caso você deseja fazer essa correção e anexar aqui, agradeço.

     

    Ok, unit alterada, em anexo.

    Obrigado.

    pnfsConversao.pas

    • Curtir 3
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.