-
Total de ítens
935 -
Registro em
-
Última visita
-
Days Won
5
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Valdir Dill
-
-
45 minutos atrás, Daniel Simoes disse:
Por favor teste, usando MSXML
Mesmo resultado.
-
5 minutos atrás, Daniel Simoes disse:
@valdirdill, você usa LibXML2 ou MSXML, na configuração de DFeSSL ?
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.
-
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.
-
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 minutos atrás, Italo Jurisato Junior disse:
Bom dia Valdir,
Já esta no repositório.
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?wsdlEm anexo envio os arquivos Cidades.ini e Fiorilli.ini atualizados e testados.
Obrigado.
-
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.
-
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
- 1
-
18 minutos atrás, José M. S. Junior disse:
Favor atualizar os fontes...
Boa tarde,
Ok, tudo certo agora.
Obrigado!
- 1
-
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.
- 1
-
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.
- 3
-
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
-
-
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!
-
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.
-
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.
- 3
-
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?
-
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.
- 3
Validação de XML
em NFe/NFCe - Nota Fiscal Eletrônica
Postado
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.