Valdir Dill
-
Total de ítens
962 -
Registro em
-
Última visita
-
Days Won
5
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Valdir Dill
-
-
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.
-
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
-
-
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.
-
41 minutos atrás, Daniel Simoes disse:
Será que isso não é uma configuração no Driver do Fabricante do A3 ?
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!
-
1
-
1
-
-
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
-
1
-
-
12 minutos atrás, Juliana Tamizou disse:
Bom dia.
Creio que seja algo que foi discutido no chat dos assinantes do SAC Anual, onde as 3 primeiras posições não eram de fato livres e se fosse enviado 8 dígitos os 3 primeiros acabavam sendo ignorados.
Relativo aos problemas que vc está tendo, por favor seja mais especifico, quais seriam?
Att.
Bom dia
24 minutos atrás, Juliana Tamizou disse:Bom dia @Juliana Tamizou
Vou me intrometer no post, pois tive problemas também nessa alteração nas rotinas do Acbr Sicredi. Eu acabei nem abrindo um tópico porque contornei a situação, a qual explico abaixo.É o seguinte: não sei é o mesmo problema/situação que o colega @marcianobandeira está enfrentando, mas nós aqui fazíamos assim:
Tomemos com exemplo o boleto número 57
Antes dessa atualização, enviávamos para o campo nossonumero do componente o número já formatado no padrão Sicredi. Desta forma: 20 2 00057 (sem os espaços, é claro).
Esse valor 20200057 também era gravado no BD local para controle depois da leitura das baixas e localização à qual conta a receber pertence cada boleto.
Porque é feito essa gravação com o número completo no padrão Sicredi? Porque a orientação do Sicredi é que a cada ano o usuários reinicie esse sequencial do boleto.
Então, no futuro, teremos o boleto 20200057 e 21200057. Se gravarmos apenas o sequencia do boleto, ficariam DOIS títulos com o mesmo número 00057, o que logicamente, daria problemas lá na frente.Até antes desta atualização do Acbr, o nossonumero era alimentado nesse padrão de 8 dígios e tudo certo. Porém, como agora o tamanhomaximo ficou igual a 5, ao gerar o boleto, dá o erro.
Aqui contornamos isso da seguinte forma:
- Ao alimentar o componente, nossonumero := 00057
- No BD gravamos 20200057
- Quando vamos tratar as baixas, fazemos um copy dos 5 últimos digitos do campo do BD e tudo certo.Espero ter sido claro na minha esplanação.
Obrigado.
-
1
-
-
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.
-
2
-
-
Boa tarde,
Corrigido na 18034.Obrigado.
-
2
-
-
Boa tarde,
É só você localizar esse arquivo novo na pasta dos fontes e adicionar esse path no library do Delphi.
Abraços.
-
1
-
-
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.
-
3
-
-
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.
-
Bom dia,
KKK...só para descontrair um pouco, relato o que o atendimento da SEFAZ-PA respondeu a um cliente: ligue no telefixo do Sebrae Rio Grande do Sul 51 3211-1562 para falar sobre o erro que esta acontecendo já que eles são responsaveis pelas atualizaçoes...
Parece piada, mas não é, confirmei com o cliente e foi isso mesmo que orientaram. Pode?
Abraços.
-
3
-
-
Bom dia,
Deixa eu esclarecer um pouco a questão...
Na verdade o problema não está ocorrendo a nível nacional. É apenas na SEFAZ-PA e passou a ocorrer a partir de ontem (02/09). Até então era possível emitir NFe com CPF, sem ter CNPJ vinculado e sem problema algum.
O que ocorre é que a SEFAZ-PA mudou seus endereços de SVAN para SVRS e, imagino eu, que o novo servidor não está preparado para receber nota cujo certificado é apenas CPF.
Estamos tendo o mesmo problema aqui com vários clientes. A SEFAZ-PA alega que é problema no nosso sistema que não atualizou os WS, mas a rotina que envia o XML de NFe de CPF é exatamente a mesma rotina que envia o XML de CNPJ e, NFe de CNPJ está enviando normal, sem nenhum erro. Então, não é no sistema e, com absoluta certeza, o problema é no WS novo deles que não está preparado para NFe vinda de CPF.
Enviamos todos os XMLs para eles e estão analisando, mas...é sempre assim, se não têm 100% que o problema é lá, sempre vão dizer que o problema é no sistema emissor, rs..
Abraços...
-
1
-
-
Boa tarde,
Também estou com esse problema. Não sei se é alguma coisa no Acbr que mudou, pois até semana passada não fazia isso.
E não é o Gmail o problema, pois testei tanto com Gmail com outros servidores e acontece a mesma coisa.
Ele vai como anexo e também como texto no corpo do e-mail.
Obrigado.
-
Boa tarde,
Fontes atualizados, testados e problema resolvido.
Obrigado.
-
2
-
-
13 horas atrás, Italo Jurisato Junior disse:
Boa tarde Valdir,
Acabei de enviar tudo, favor atualizar os fontes e reinstale usando o ACBrInstall_Trunk2, não esqueça de marcar a opção para apagar os fontes antigos.
Bom dia,
Beleza, atualizei novamente agora e tudo certo, as mudanças estão presentes.
Obrigado.
Abraços.
-
2
-
-
Boa tarde,
Essas mudanças já foram upadas para o repositório?
Baixei os fontes hoje e os resDFe e chDFe não estão disponíveis para uso.
Obrigado.
-
Boa tarde,
Fontes atualizados, teste efetuado e problema resolvido.
Obrigado.
-
2
-
-
5 minutos atrás, Daniel Simoes disse:
Não é o caso de usar o novo componente exclusivo para NFCe, no Fast ?
Boa tarde,
Mas é no novo componente que o problema ocorre.
-
Boa tarde @BigWings,
Não sei bem se o que fiz é correto, rs..Não consegui analisar ainda bem em detalhes o debug, mas só para dar um caminho para sua análise...
Eu fiz o seguinte: na llinha 1006 da ACBrNFeDANFEFRDM.pas eu incluí a linha -> else FieldByName('DescricaoProduto').AsString := StringReplace( Prod.xProd, ';', #13, [rfReplaceAll]);
Acho que o problema está nesse campo DescricaoProduto que não está sendo alimentado.
Veja se isso ajuda...
Abraços.
-
Boa tarde,
Também estou com esse problema. Tanto utilizando o DANFeNFCe3_50.fr3, como o DANFeNFCeA4.fr3.
Obrigado.
1/2 Off - Form com RLReport Demorando para Carregar
em Object Pascal - Delphi & Lazarus
Postado
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.