Diego Foliene

Bom dia! Por favor, substitua o seu arquivo ACBrNFSeXServicos.ini pelo em anexo, execute o arquivo compila_res.bat que fica na pasta dos fontes do ACBrNFSeX, reinstale o ACBr, de um build all e faça um novo teste. Neste arquivo, removi as URLs especificas da cidade de Estrela/RS, ficando assim: [4307807] ; Atualizado em 18/04/2024 Nome=Estrela UF=RS Provedor=IPM Desta forma, o componente vai pegar a URL desta seção do mesmo arquivo: [IPM] ProRecepcionar=http://sync.nfs-e.net/datacenter/include/nfw/importa_nfw/nfw_import_upload.php HomRecepcionar=http://sync.nfs-e.net/datacenter/include/nfw/importa_nfw/nfw_import_upload.php ProLinkURL=http://sync.nfs-e.net/datacenter/include/nfw/nfw_imp_notas.php?codauten=%CodVerif% HomLinkURL=http://sync.nfs-e.net/datacenter/include/nfw/nfw_imp_notas.php?codauten=%CodVerif% ACBrNFSeXServicos.ini

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

Bom dia! Que bom que deu certo! Apenas complementando, você pode obter o nome do arquivo gerado lendo a propriedade: ACBreSocial.Eventos.Gerados.Items[Indice].PathNome; Conforme demonstrado no botão "Gerar Arquivos" do programa exemplo.

Bom dia! Por favor, se você tentar dar um step-into com o F7 ele não mostra com mais exatidão o local do erro? Configure as propriedades: ACBrBoleto.Configuracoes.Arquivos.LogNivel := logParanoico; ACBrBoleto.Configuracoes.Arquivos.PathGravarRegistro := Caminho onde vai salvar; ACBrBoleto.Configuracoes.Arquivos.NomeArquivoLog := Nome do arquivo E veja qual é o conteúdo do mesmo.

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

Olá pessoal! Conferindo no painel Situação SVC, é possível observar que a Sefaz de Pernambuco está com contingência agendada para o dia 21/04/2024, com previsão de inicio às 07h00 e encerramento no dia 22/04/2024 às 09h00. Para utilizar as soluções ACBr em contingência durante este período, siga as orientações do tópico abaixo: Um agradecimento ao membro de nossa comunidade @Felipe Mariano por compartilhar a informação no canal #sefaz em nosso Discord.

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

Boa tarde. Analisando está mensagem a mesma está dizendo que o valor vazio para o campo "Competência não é um valor válido para o campo data. Foi verificado que a modificação recente foi feita na criação do arquivo INI por parte da Lib, alterando para que caso a informação tenha sido alimentada, seja passado o valor da mesma e caso não o tenha, seja usado a data atual para adicionar a informação ao usar o ObterINI ou o GravarIni. Por favor, verifique se no arquivo INI que está usando para alimentar a Lib você está informando Compentencia na seção [IdentificaçãoRPS], conforme exemplo: [IdentificacaoRps] Competencia=17/04/2024 Caso negativo, adicione a informação e faça um novo teste.

Combinado, ficamos no aguardo.

O conteúdo deste -soap está estranho, veja: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>500</faultcode> <faultstring>ERROR: 42601: syntax error at or near "where" LINE 42: #32 {main}$$)) where md5(nfltextoenvio) = md5(trim($$ soape... ^ LOCATION: scanner_yyerror, scan.l:1134 SQL:SELECT 1 FROM WNE.tbnotafiscaleletronicalog where ecocadastro = '20146' and nflsituacao = 2 and md5(nfllogerro) = md5(trim($$ ERROR: 23505: duplicate key value violates unique constraint "ui_tbautorizacaorps_aberta" DETAIL: Key (ecocadastro)=(20146) already exists.(...) exception 'UniqueConstraintException' with message 'Não é possível inserir o registro, pois já existe um registro com estas informações' in /var/www/html/migracao.atende.net/estrutura/est_class_sql_trigger_exception.inc:42(...) </faultstring> </SOAP-ENV:Fault> </SOAP-ENV:Body> Isso me parece ser um erro de banco de dados no lado do servidor. Verifique se não existe nenhum RPS já emitido, se 20146 for o número do RPS, tente incrementar.

Olá pessoal! O envio do MDFe de forma assíncrona está com os dias contados, com a previsão de ser encerrado no dia 30/06/2024. O tópico abaixo tem mais detalhes a respeito. Mas fica então o questionamento, o que muda? Bem, antes de falar sobre isso, vamos responder a outra pergunta: Qual é a diferença entre o envio assíncrono e o envio síncrono? De maneira bem simples, a diferença entre essas formas de envio é a quantidade de conexões que é feita para com o web service da Sefaz. No envio assíncrono, primeiro sua aplicação envia o XML para o web service e recebe um número de recibo. Então, a aplicação faz uma nova requisição para o web service consultando o número de recibo para obter as rejeições ou em caso de sucesso o MDFe. Já no envio síncrono, em uma só requisição é enviado para o web service e na resposta já vem as rejeições ou o MDFe quando em caso de sucesso. Se você pensou: Isso se deve ao fato de que visando auxiliar os desenvolvedores que utilizam o componente, esse processo é automatizado, ou seja, a consulta já era feita automaticamente pela solução. Entendi a diferença entre os modos de envio, mas o que eu preciso mudar na minha aplicação? A primeira coisa que você deve se atentar é no comando que utiliza para fazer o envio do MDFe para o web service. Veja quais são os parâmetros do método Enviar no comando nativo. // Parâmetros do método Enviar: // ALote = Número do Lote // AImprimir = Se True imprime automaticamente o DAMDFE // ASincrono = Se True o envio é no modo Síncrono, caso contrario Assíncrono. ACBrMDFe.Enviar(Alote, AImprmir, ASincrono); Estes parâmetros são refletidos também nos comandos tanto da Lib: MDFE_Enviar(ALote, AImprimir, ASincrono, sResposta, esTamanho); Quanto do Monitor: MDFE.ENVIARMDFe(nXMLMDFe, [nLote], [nAssinar],[nImprimi],[nImpressora], [bAssincrono], [bEncerrado] ) Parâmetros: nXMLMDFe - Caminho do XML do MDF-e nLote - Número do Lote (opcional) nAssinar - Assinar o XML (opcional - informe 0 para não assinar) nImprimi - Imprimir MDF-e (opcional - informe 1 para imprimir) nImpressora - Nome da Impressora (opcional) bAssincrono - Por padrão o envio é Assíncrono, informa "False" para envio Sincrono bEncerrado - Imprimir Mensagem de "MDFe Encerrado", (opcional - informe 1 para imprimir) Então, a partir de 30/06/2024, será preciso informar corretamente o parâmetro que define o modo de envio, para que o mesmo seja feito de forma síncrona. No momento de ler o retorno, também serão necessárias mudanças. Caso utilize o componente nativo para Delphi/Lazarus, a classe que vai ler as informações não é mais a Retorno e sim a Enviar. //Ao invés de ler as informações de: ACBrMDFe.WebServices.Retorno.XXXX //Agora vai ler de: ACBrMDFe.WebServices.Enviar.XXXX Se você utiliza o Monitor ou a Lib, a principal diferença será no momento de ler as informações do MDFe. No envio assíncrono elas ficavam contidas na seção [MDFe + Número do MDFe], no entanto, na resposta do envio síncrono elas ficam em [MDFe+ Chave de Acesso do MDFe]. Mas eu não tenho a Chave de Acesso ainda, como vou conseguir ler? A chave de acesso de um documento fiscal deve ser montada seguindo uma regra estabelecida no MOC. Por isso, tanto a Lib quanto o Monitor possuem um método específico que se alimentado com as informações necessárias devolvem a chave de acesso montada. São eles: MDFe.GerarChave para o Monitor. MDFe_GerarChave para a Lib. Portanto, fazendo uso deste método é possível obter a informação que é precisa para realizar a leitura da seção.

Foi enviado uma atualização no SVN na Rev-33342 visando resolver está questão. Agora a propriedade IndDeduzDeson aceita os valores tieSim, tieNao e tieNenhum, sendo este último usado para validar se vai gerar a tag ou não e o tieSim e tieNao sendo valores válidos para inserir no XML. Caso utilize Lib ou Monitor, basta não informar no arquivo INI. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos teste e reportar qualquer problema.

Boa tarde! Estamos analisando esta questão em uma tarefa na sprint desta semana. Assim que houver atualização, informamos aqui.

Boa tarde! Foi feito uma reunião da equipe de consultores e após diversas considerações, chegou-se a conclusão que uma alteração na estrutura de resposta da lib poderia causar problemas inesperados a outros membros que já utilizam a Lib em envio síncrono desta forma. Dado a ausência de outros relatos semelhantes, a recomendação é que seja utilizado o método MDFe_GerarChave para obter a informação da chave de acesso e realizar a leitura da seção [MDFe+Chave de Acesso] na resposta da Lib.

Boa tarde! Boa, já é um avanço, agora ele parece estar pegando o endereço correto. Por favor, nesta tentativa que devolveu este erro qual é o conteúdo do -soap de resposta? Apesar de ser o mesmo provedor, a versão que atende a cidade de Igrejinha/RS é a 1.01.

Qual é a linguagem que você utiliza para desenvolvimento? Caso ela gere um .EXE, faça um teste colando este arquivo ACBrNFSeXServicos.ini na mesma pasta do mesmo. Indique também o arquivo na seção IniServicos da seção [NFSe] do seu arquivo de configurações ACBrLib.ini, passando o caminho completo dele.

Há uma diferença nas URLS, por isso o erro. Veja: Por favor, altere no arquivo ACBrNFSeXServicos.ini e faça um novo teste.

Bom dia! Foi enviada uma alteração no SVN na Rev-33268 visando corrigir esta questão. Por favor, caso ainda não o tenha feito, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

Bom dia! Por favor, consegue confirmar junto ao IPM se a URL está correta? Se eu tento acessar o link direto pelo navegador mesmo ele já me devolve o retorno de "Parâmetros Inválidos" veja:

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

Bom dia! Se você está consultando os NSUs de acordo com a sequência que controla, mas ainda assim está recebendo um erro de consumo indevido com um novo número de NSU para a próxima consulta, então é um indicativo de que está havendo consulta paralela. Mais alguém esteja consultando.

Olá pessoal! No dia 04/04/2024 foi publicada a Resolução Sefaz Nº636, alterando novamente o artigo 9º da Resolução Nº578, dando ao mesmo a seguinte redação: Postergando novamente a entrada em vigor dessa obrigatoriedade para 01/05/2024. Um agradecimento ao membro de nossa comunidade @Bruno da Silva Pereira por compartilhar a informação em nosso fórum.

Olá pessoal! Foi publicado pelo ITI novo FAQ sobre o fim do certificado A1: 01/2024 - Modernização da ICP-Brasil > Questionamentos mais frequentes

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

Boa tarde! Este campo define a informação que é adicionada e enviada no XML da nota. Por favor, faça um teste definindo na seção [DANFe] no seu arquivo ACBrLib.ini que contém as configurações da Lib. No programa exemplo em C# pode ser definido assim: Lembrando que é preciso chamar o ConfigGravar posteriormente. Veja na rotina SalvarConfig e LoadConfig para um melhor entendimento.