Diego Foliene

Boa tarde! Neste exemplo o ultNSU e o maxNSU possuem o mesmo valor, o que indica que não há mais documentos a serem devolvidos pelo web service.

Boa tarde! Você está inserindo a informação na seção [WebService] em seu arquivo Cedente.ini e utilizando o comando BOLETO_ConfigurarDados correto? Apenas por desencargo, faça um teste informando direto no arquivo ACBrLib.ini, conforme observação da própria documentação do método:

Boa tarde! O e-mail do remetente da mensagem é do g-mail, hotmail ou de um provedor de e-mails próprio? Neste tópico tem um exemplo das configurações para os principais provedores de e-mails: Dito isso é importante considerar: Para o g-mail, por exemplo, você vai configurar uma senha de app e definir ela na config da Lib ao invés da senha padrão da conta. Você deve usar o método MAiL_ConfigGravarValor para salvar a informação da senha. Você não pode simplesmente colocar ela direto no ACBrLib.ini porque a senha é criptografada pela Lib.

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn #TK-5853

Bom dia. Complementando a resposta do meu amigo @Juliomar Marchetti: \ACBr\trunk2\Projetos\ACBrLib\Demos\PHP E também:

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?

Correto, é o caminho completo do arquivo. Ficamos no aguardo de um feedback dos testes.

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?

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.

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.

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.

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

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.

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.

Boa tarde! Entendido, vou fazer um teste em meu ambiente forçando o conteúdo da sua resposta para ver o resultado.

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.

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn #TK-5843

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

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?

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.

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.

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.

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.