Diego Foliene

Realmente, pelo que pude conferir é necessário estar credenciado para emissão de NF-e ou de CT-e na Sefaz respectiva para efetuar emissão de MDF-e. No arquivo INI que disponibilizou anteriormente o código da UF no grupo Ide é o de Goiás. Essa também é a UF configurada na solução que está usando? Se você está usando o ACBrMonitor, por exemplo, precisa estar configurado GO nessa aba:

Boa tarde! É possível que o micro que esteja apresentando problema esteja pegando as dlls incorretas ou de versão indesejada, por isso o teste adicionando elas na mesma pasta do .EXE. Também é por isso que questionei se colocou as dlls da versão x64. Você está compilando o exemplo especificamente em x64? Por default a compilação é x86. Coloque as dlls da x86 na mesma pasta do .EXE A princípio não. Tanto que em um dos testes que fiz, apaguei meu arquivo ACBrNFe.ini que tem as configurações do exemplo salvas e ele ficou sem o PathSchemas configurado. Só confirmando: Sempre que atualiza os fontes, você reinstala o ACBr, correto? Você tem mais de uma versão do Delphi na sua máquina? Essa máquina que apresenta problema é Windows? Se sim, qual é a versão do mesmo?

Boa tarde! Primeiro de tudo, agradeço pela análise. É visível que houve muito esforço e empenho em buscar a solução do problema. É muito bom ver isso. E tenho certeza que mergulhar nos fontes fazendo o debug dessa forma foi uma experiência enriquecedora. Também é muito bom que tenha conseguido encontrar a solução do problema. Só um pequeno detalhe: Essas classes Wervices.Retorno são usadas quando o envio é feito de forma assíncrona. Se você conferir no tópico que o @Italo Giurizzato Juniorou mesmo no programa exemplo em btnCriarEnviarSincronoClick vai ver que a classe em que as informações de retorno são lidas é a ACBrMDFe.WebServices.Enviar.XXXX Veja se usando elas ao invés de WebServices.Retorno, as informações não são devolvidas para você.

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

Bom dia! Não temos exemplo de boleto disponível para esta linguagem. Como o @Daniel InfoCotidiano demonstrou que testando com o C# não ocorreu o problema, por favor, pode disponibilizar um exemplo simples em Visual FoxPro para que possamos testar?

Bom dia! Apenas dando um retorno. A TK foi alocada no sprint dessa semana e estamos analisando o problema.

Bom dia! Tentei imitar a estrutura de arquivos, mas não tive problemas. No seu exemplo, dentro da pasta dos fontes, libssl-1_1-x64.dll, libcrypto-1_1-x64.dll e inpoutx64.dll Isso me faz entender que você compila o .EXE em x64. É isso mesmo? Se sim, existe algum motivo em específico?

Sendo tratado no tópico:

Bom dia! E em nenhum dos casos informei o campo N39a (qBCMonoReten). Feitos novos testes e parece ser algo do validador do RS mesmo. As rejeições 767 e 769 foram validadas conforme o esperado, só a 768 não foi mostrada. Conferindo junto a equipe de consultores, considerando as regras de validação da NT, foi decidido que mesmo que os campos sejam opcionais, logicamente falando faz sentido eles serem obrigatórios, pois existem rejeições que obrigam o preenchimento. Enviado ao SVN na Rev-34473 alteração para que as tags sejam adicionadas no XML mesmo quando o valor esteja zerado. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

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

Bom dia! Conferindo seu comando e comparando com a documentação, você já está utilizando os parâmetros corretos. No entanto, no seu log, temos a mensagem de erro: É possível que o problema seja versão para a qual esteja fazendo o envio. Por favor, faça um teste usando o comando MDFE.SetVersaoDF("3.00") antes de fazer toda a operação.

Bom dia. Por favor, veja:

Bom dia! Por favor, faça um teste utilizando o impresso em EscPos. Nele a comunicação ocorre direto com a porta da impressora. Pode ser que o Fortes que comunica com o spooler do windows esteja se perdendo ao realizar múltiplas impressões em sequência.

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

Bom dia! Fiz um teste com seus arquivos utilizando a versão 1.4.0.263 do ACBrMonitorPLUS. Em anexo o arquivo gerado. Nele, a posição 61 do segmento P está com o valor 2 que de acordo com o manual que temos disponível corresponde a cliente emite. Este não é o valor correto? cb160701.rem

Bom dia! Complementando a resposta do @Italo Giurizzato Junior, a URL que a citou coincide com a da versão 1.0 Atualmente o MDFe está na versão 3.0. Por favor, atualize o Monitor para a versão mais recente e configure a versão do MDFe para a 3.0 nas configurações: Ou usando o comando MDFe.SetVersaoDF

Bom dia! Por favor, apenas confirmando, qual é a configuração que está utilizando para CodificacaoResposta na Lib? Você está utilizando a versão Single Thread ou Multi Thread? Em nossa lista de exemplos disponíveis, existe algum para a sua linguagem? Caso afirmativo, por gentileza, pode fazer um teste com o mesmo para ver se o comportamento é o mesmo?

Bom dia! Por favor, qual é a versão do ACBrMonitorPLUS que está utilizando? Se o problema ainda persiste disponibilize o Log do ACBrMonitorPLUS 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.

Combinado, ficamos no aguardo.

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

Boa tarde @Claudio Consulim! Por favor, pode disponibilizar os XMLs que está utilizando e está passando no validador? Se julgar que tem dados sensíveis e não possa ser disponibilizado direto aqui, envie para [email protected] com o link da mensagem do Discord no corpo do e-mail para posterior identificação. Fiz um teste em meu ambiente. Gerei um XML de NF-e e um de NFC-e utilizando o próprio programa exemplo, mas em nenhum dos casos o validador me apontou esta rejeição: NFC-e: <comb> <cProdANP>210203003</cProdANP> <descANP>Combustível</descANP> <UFCons>SP</UFCons> </comb> <...> <ICMS> <ICMS15> <orig>0</orig> <CST>15</CST> <qBCMono>100.0000</qBCMono> <adRemICMS>10.0000</adRemICMS> <vICMSMono>10.00</vICMSMono> <adRemICMSReten>10.0000</adRemICMSReten> <vICMSMonoReten>10.00</vICMSMonoReten> <pRedAdRem>10.00</pRedAdRem> <motRedAdRem>1</motRedAdRem> </ICMS15> </ICMS> Rejeições apontadas: NF-e: <comb> <cProdANP>210203003</cProdANP> <descANP>Combustível</descANP> <UFCons>SP</UFCons> </comb> <...> <ICMS15> <orig>0</orig> <CST>15</CST> <qBCMono>100.0000</qBCMono> <adRemICMS>10.0000</adRemICMS> <vICMSMono>10.00</vICMSMono> <adRemICMSReten>10.0000</adRemICMSReten> <vICMSMonoReten>10.00</vICMSMonoReten> <pRedAdRem>10.00</pRedAdRem> <motRedAdRem>1</motRedAdRem> </ICMS15> </ICMS> Rejeições: Veja que apesar das rejeições, em nenhum dos casos temos: E em nenhum dos casos informei o campo N39a (qBCMonoReten).

Por favor, aguarde nova compilação da Lib para realizar os testes. A Lib costuma ser compilada todas as terças-feiras de manhã.

Boa tarde! Foi enviado ao SVN na Rev-34406 um commit adicionando as informações NumeroNota, CodigoVerificacao, NumeroRPS, SerieRPS e Data na resposta da Lib. As respectivas informações foram adicionadas na seção [ArquivoXX]. O motivo deste ter sido o local escolhido para adição das informações é porque em um lote de RPS podem ser enviados até 50 RPS e portanto podem ser devolvidas até 50 NFSes. (Pode ter até 50 ocorrências do grupo <CompNFSe> dentro do <ListaNFSe> no XML de retorno). Então, na LibNFSe compilada depois do dia 15/07/2024 a resposta será devolvida assim: { "ConsultaLoteRps": { "CodVerificacao": "PJ8F-IYAG", "Arquivo1": { "CaminhoCompleto": "C:\\ACBr\\trunk2\\Projetos\\ACBrLib\\Demos\\C#\\NFSe\\Demos\\ACBrLib.NFSe.Demo\\bin\\Debug\\Docs\\Notas\\20-nfse.xml", "CodigoVerificacao": "PJ8F-IYAT", "NomeArquivo": "20-nfse.xml", "NumeroNota": "20", "NumeroRPS": "56", "SerieRPS": "1" }, "Arquivo2": { "CaminhoCompleto": "C:\\ACBr\\trunk2\\Projetos\\ACBrLib\\Demos\\C#\\NFSe\\Demos\\ACBrLib.NFSe.Demo\\bin\\Debug\\Docs\\Notas\\21-nfse.xml", "CodigoVerificacao": "PJ8F-IYAG", "NomeArquivo": "21-nfse.xml", "NumeroNota": "21", "NumeroRPS": "57", "SerieRPS": "1" }, "Lote": "1", "Protocolo": "123465798", "Situacao": "4", "XmlEnvio": "<ConsultarLoteRpsEnvio xmlns=\"http://www.abrasf.org.br/ABRASF/arquivos/nfse.xsd\">..." "XmlRetorno": "<ConsultarLoteRpsResposta xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://www.abrasf.org.br/ABRASF/arquivos/nfse.xsd\"><ListaNfse><CompNfse>..." } }

Muito obrigado! O e-mail é: [email protected]