Ir para conteúdo
  • Cadastre-se

Diego Foliene

Consultores
  • Total de ítens

    5.300
  • Registro em

  • Última visita

  • Days Won

    154

Tudo que Diego Foliene postou

  1. Bom dia. Foram preenchidos ArquivoCRT e ArquivoKey na seção [BoletoWebService] do arquivo ACBrLib.ini? As dlls de dependência do OpenSSL foram distribuídas corretamente?
  2. Correto, é o caminho completo do arquivo. Ficamos no aguardo de um feedback dos testes.
  3. Bom dia. Este código de ativação 00000000 está correto? É este valor mesmo? O equipamento é de produção a informação de Assinatura Sw. House foi configurada corretamente em "Configuração > Dados Sw.House"? Se você conferir no gerenciador de dispositivos do windows consta aparelho SAT na lista?
  4. No seu arquivo log, ele também está desta forma: Você censurou as informações para disponibilizar aqui ou ele está assim porque você preencheu com dados fictícios? A mensagem está dizendo que não encontrou o anexo. "ZZZZZZZ" não é um caminho válido.
  5. Bom dia. A mensagem serve para informar que o seu tópico já foi movido para área do SAC, que é a seção exclusiva para quem é PRO. No que diz respeito ao problema propriamente dito, pelo seu print, você parece estar utilizando o programa exemplo do componente ACBrNFSe. Este componente foi descontinuado e já não recebe mais manutenção, por favor, faça um teste usando o programa exemplo do componente ACBrNFSeX localizado em \ACBr\trunk2\Exemplos\ACBrDFe\ACBrNFSeX Certifique-se de preencher nele os campos de usuário e senha: Faça um teste com os ambientes de homologação e de produção para o caso de serem credenciais diferentes para os ambientes. Ficamos no aguardo de um feedback.
  6. Bom dia! Esta trecho está estranho. Ele foi gerado assim no log? O comando de acordo com a documentação é: NFE_EnviarEmail(ePara, eXMLNFe, AEnviaPDF, eAssunto, eCC, eAnexos, eMensagem); Transcrevendo o seu comando temos: NFe_EnviarEmail( <ePara>: [email protected], <eXMLNFe>: C:\NFCE\CUSTODIA\33240449576924000120550050000001241146638333-nfe.XML, <AEnviaPDF>: PDF, <eAssunto>: aaaaaa, <eCC>: ccccccc, <eAnexos>: ZZZZZZZ, <eMensagem>: bbbbbbb ) Essas informações estão sobrando: nfe.XML,PDF,aaaaaa,ccccccc,ZZZZZZZ,bbbbbbb Por favor, disponibilize o arquivo de log que foi gerado pela Lib para análise. Se julgar que o mesmo tenha dados sensíveis e não possa ser disponibilizado direto aqui, envie para [email protected] com o link do tópico do fórum no corpo do e-mail para posterior identificação.
  7. @Destak, foi enviado ao SVN na Rev-34792 uma alteração visando corrigir o problema que está enfrentando. Por favor, queira atualizar seus fontes, reinstalar o ACBr para que possa realizar novos testes e reportar qualquer problema.
  8. Bom dia! Apenas dando um retorno sobre este caso. Fiz um teste utilizando o botão cancelar do programa exemplo. Com o programa em execução, na primeira vez que clico, ele comunica com o web service normalmente e me devolve uma rejeição, no entanto, se clicar uma segunda vez, recebo o mesmo erro. Criada a #TK-5850 para análise do caso e parecer por parte da equipe de consultores.
  9. Olá pessoal! Conferindo na página Sobre a NF-e consta um aviso informando que foi disponibilizado no ambiente de testes um autorizador síncrono para NF-e. Aviso reproduzido na íntegra: Síncrono... Assíncrono... que raios é isso?! Na transmissão de documentos fiscais, o envio para o web service pode ocorrer de duas maneiras. No envio assíncrono, o XML é enviado para o web service, que devolve um número de recibo. Em seguida, o emissor faz uma nova conexão com o mesmo web service para consultar o número de recibo e receber o resultado do processamento. No envio síncrono, o XML é enviado para o web service, que já devolve o resultado do processamento na mesma resposta, ou seja, tudo é feito em uma única conexão. E por que isso é importante? Apesar de existir as duas formas de envio, recentemente alguns documentos fiscais tem adotado exclusivamente o modo de envio síncrono e desativando o modo assíncrono. Isso aconteceu com a NFC-e: Com a versão 4.00 do CT-e: Com o MDF-e: E logo com a NF3e também: Para a NF-e especificamente, ainda existe ambos os métodos, com exceção de SP e BA que não aceitam o modo síncrono. Esse aviso indica que a Sefaz de SP está caminhando para que isso não seja mais o caso e ela passe a aceitar o envio síncrono também. O que pode ser um passo para que a NF-e também mude somente para o modo síncrono futuramente. Está edição do Papo PRO traz considerações sobre as formas de envio: Um agradecimento ao membro de nossa comunidade @Felipe Marianopor compartilhar a informação no canal #sefaz em nosso Discord.
  10. Boa tarde! Entendido, vou fazer um teste em meu ambiente forçando o conteúdo da sua resposta para ver o resultado.
  11. until
    Para mais informações confira:
  12. Olá pessoal! Conferindo na página SPED MG na área específica para NF-e, consta um aviso informando que no dia 09/08/2024, à partir das 18h00 será realizada uma atualização do ambiente de infraestrutura da Sefaz de Minas Gerais. Não há previsão de indisponibilidade, no entanto, os serviços de autorizações de Documentos Fiscais Eletrônicos – NF-e, CT-e, CT-e OS e BP-e podem apresentar instabilidade e variação no tempo de resposta durante este período. O processo de manutenção tem previsão inicial de ser concluído às 08h00 do dia 12/08/2024.
  13. Obrigado pela contribuição, em breve será validada para possível inclusão ao svn #TK-5843
  14. Tópico movido para a área do SAC, para que o SLA de respostas seja considerado
  15. Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.
  16. Bom dia! Por favor, apenas para confirmar: Você utiliza componente nativo para Delphi/Lazarus, Monitor ou Lib? Independente da solução que está utilizando, a mesma está atualizada?
  17. Boa tarde! No componente nativo para Delphi/Lazarus existe uma propriedade ImprimeCanhoto. No entanto, pelo que pude averiguar, a mesma não é implementada no Monitor e na Lib. Criada a #TK-5840 para a adição da mesma em ambas as soluções.
  18. Muito obrigado por todo o apoio e pelas informações @fredsmartfull. Com certeza quando disponibilizarmos o provedor e criamos um tópico para informar a comunidade, vamos lhe dar os devidos créditos.
  19. Boa tarde! Uma retratação em minha resposta anterior: Uma alteração foi necessária nos fontes do ACBr. A mesma foi enviada ao SVN na Rev-34776. Ainda assim, acredito que a mesma não tenha relação com o problema "Receita nao exige o tipo de documento informado!" e reforço minha orientação para entrar em contato com o Sefaz.
  20. Bom dia! Em minha postagem anterior, no "Tópico³" tem informações de como pode buscar a informação. Nesse mesmo tópico, um colega disponibiliza um print de uma tela. Veja se não consegue acesso semelhante. Pelas informações, acredito que seria o acesso do prestador.
  21. Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.
  22. Bom dia! Você utiliza componente nativo para Delphi/Lazarus, ACBrMonitor ou ACBrLib?
  23. Bom dia! Que bom que deu certo! Muito obrigado pelo feedback! Só para confirmarmos então, você precisou usar a unit do PSP alterada que foi anexada no tópico ou deu certo usando a que está no SVN?
  24. Obrigado pela contribuição, em breve será validada para possível inclusão ao svn #TK-5837
×
×
  • 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.