Alexandre Felippeto Henzen

Ao cancelar uma nota estou recebendo o retorno 'E999 - Ocorreu um erro inesperado. - As possíveis causas são formatações XML incorretas.' Onde pode estar o erro? 1337-can.xml 1337-can-soap.xml 1337-ped-can.xml 1337-ped-can-soap.xml

Bom dia, alguém com problemas no portal Govbr de Pato Branco/PR? Não estou conseguindo consultar o meu RPS e ao acessar o portal também não exibe nenhuma informação.

Perfeito, compreendi. Vou contatar novamente para ver qual o retorno da parte deles.

Boa tarde, ao fazer um envio de NFS-e no ambiente de homologação para o município de Pato Branco - PR, foi verificado uma instabilidade, e prontamente foi realizado um contato com a prefeitura para verificar a normalização deste ambiente. No retorno da prefeitura, eles confirmaram a instabilidade e afirmaram que foi realizada uma correção. Após isso, novamente foram realizados testes no envio de NFS-e no ambiente de homologação, e agora a mensagem de retorno é: "E232: Ocorreu um erro no processamento do arquivo. X202: Lista de NFSe não encontrada! (ListaNfse)" Como poderia ser resolvido este problema? Segue em anexo os XMLs de envio e retorno da nota. xml_retornoPB.xml xml_envioPB.xml

Boa tarde, conforme já aberto em outro chamado, foi visualizado que no município de Lapa - PR com o provedor IPM, também foi necessário adicionar o parâmetro extra "Params=ParametroExtra:eletron=1" no arquivo ACBrNFSeXServicos.ini para que retornasse um xml básico com o HTML, consequentemente resolvendo um problema de retorno de consulta de NFS-e. A seção ficou da seguinte forma: [4113205] Nome=Lapa UF=PR Provedor=IPM Params=ParametroExtra:eletron=1 Algum adendo sobre essa incidência? Caso contrário, segue a mesma como contribuição.

Boa tarde! Ao enviar uma NFS-e pelo ambiente de homologação para a prefeitura de Pato Branco - PR, obtive o seguinte retorno: X999: Erro de Conexão: Erro Interno: 0 Erro HTTP: 500 URL: http://nfse2.patobranco.pr.gov.br/nfse.portal.integracao.teste/services.svc WebService retornou um XML vazio. O mesmo problema parece ocorrer para o município de Curitiba - PR, também em envios de Homologação. A emissão de notas de serviço para essas prefeituras estão fora, ou algo do tipo?

Bom dia, aconteceu um caso de rejeição por duplicidade onde não retornou o recibo: 204 - Rejeicao: Duplicidade de NF-e Normalmente recebo assim: 204 - Duplicidade de NF-e [nRec:411002156471682] Ou assim: 204 - Rejeicao: Duplicidade de NF-e [chNFe:42230284951649000340550010000014151204731236][nRec:423006317625473] Alguém tem alguma ideia o motivo de não ter retornado o recibo?

O XML em anexo foi incorretamente, vou anexa-lo novamente. 5342-can.xml 5342-can-soap.xml 5342-ped-can.xml 5342-ped-can-soap.txt

Bom dia, no município de Telêmaco Borba (provedor IPM), ao cancelarmos uma NFS-e obtivemos um XML de retorno do cancelamento com duas 'tags' de retorno, sendo uma com sucesso e outra com o erro ao cancelar. Vou deixar em anexo para análise. O que pode ter causado essa incidência? 5281-can-soap.xml

Boa tarde, conforme já aberto em outro chamado, foi visualizado que no município de Colombo - PR com o provedor IPM, também foi necessário adicionar o parâmetro extra "Params=ParametroExtra:eletron=1" no arquivo ACBrNFSeXServicos.ini para que retornasse um xml básico com o HTML, consequentemente resolvendo um problema de retorno de consulta de NFS-e. A seção ficou da seguinte forma: [4105805] Nome=Colombo UF=PR Provedor=IPM Params=Assinar:AssRpsGerarNFSe|ParametroExtra:eletron=1 Algum adendo sobre essa incidência? Caso contrário, segue a mesma como contribuição.

Boa tarde, visualizado que no município de Telêmaco Borba - PR com o provedor IPM, foi necessário adicionar o parâmetro extra "Params=ParametroExtra:eletron=1" no arquivo ACBrNFSeXServicos.ini para que retornasse um xml básico com o HTML, consequentemente resolvendo um problema de retorno de consulta de NFS-e. A seção ficou da seguinte forma: [4127106] ; Atualizado em 29/11/2021 Nome=Telemaco Borba UF=PR Provedor=IPM Params=ParametroExtra:eletron=1 Algum adendo sobre essa incidência? Caso contrário, segue a mesma como contribuição.

Bom dia pessoal, Alguma previsão para liberação de emissão de NFS-e para Campo Largo no novo layout?? O layout anterior já não está sendo mais aceito.. Agradeço desde já!!

Bom dia @Daniel InfoCotidiano Neste meu cenário estou deixando o ACBrBoleto preencher. Sem mensagem complementar. Conforme o print, antes era analisado se tinha através do if Mensagens.Text <> '', agora isso não é mais feito..

Bom dia @Italo Giurizzato Junior Sobre Campo Largo, teve mudança da IPM recente sobre o layout, está sendo tratado pelo ACBr neste tópico: Estou aguardando o pessoal liberar esta correção de Campo Largo para dar sequencia, no momento estou sem emitir pra Campo Largo.. Sobre Pinhais, na verdade não tive erros... Atualizei a URL no meu ACBrNFSeXServicos.ini sim e uma emissão para Pinhais funcionou normal.. Conforme comentário anterior, liguei para a IPM no (47) 3531-1500 (opção 3 Fiscal, opção 3 Paraná, opção 1 Nota Fiscal) e a atendente confirmou a URL de pinhais sem o &cidade=padrao. Se quiser ligar la e re-confirmar, assim ficará mais claro para mandar a alteração adiante ou não.

Então @Juliana Tamizou Meu problema na verdade era de Campo Largo, onde a IPM atualizou do layout 1.00 para o 1.01 dia 04/12/2023 conforme o atendente no 47 3180-0578. Vi que o pessoal está já tratando este assunto aqui neste tópico: Liguei para a IPM novamente no (47) 3531-1500 (opção 3 Fiscal, opção 3 Paraná, opção 1 Nota Fiscal) e a atendente confirmou a URL de pinhais sem o &cidade=padrao. Verifiquei alguns logs, e após retirar a URL confirmei emissão de sucesso para Pinhais de alguns clientes meus sem problemas. Resumindo, não tive erro pra Pinhais no inicio da minha resposta, mas sim Campo Largo. Porém mudei URL Pinhais e funcionou normalmente. Desculpem a confusão..

Boa tarde, Em 01/12/2023 foi mesclado esta alteração ACBrBancoBradesco.pas: Isso acabou exigindo que o Mensagem tenha 1 registro pelo menos na posição 0, isso não ocorria antes por conta do if logo antes... Tenho um teste onde meu cenário antes não tem nem SacadoAvalista, e nem Mensagem preenchida... Não encontrei se esta mensagem é obrigatória em todos os casos e se meu cenário está errado, ou se realmente dentro do ACBr deveria ainda ter o if <> '' antes de acessar a posição 0. Aguardo avalição/retorno ou orientação sobre o preenchimento correto dos dados.

Assim que possível retorno @Juliana Tamizou!!

Bom dia @Italo Giurizzato Junior Atualizei os componentes e um cliente teve o seguinte erro ao enviar uma nota para Pinhais: 00304 - Atividades encerradas para o municí­pio prestador do serviço. Em contato com a IPM, eles me perguntaram a URL, eu passei a que estava no .ini do ACBr, que é a mesma informada acima pelo @Dercide Alvarez acima, eles me informaram que a correção é tirar o final ali &cidade=padrao Ficando a URL apenas : https://pinhais.atende.net/atende.php?pg=rest&service=WNERestServiceNFSe Ainda não consegui realizar testes com esta alteração...

Alguém já teve esse problema abaixo com o provedor da IPM? É umas situação esporádica... Enviado cancelamento de nota pro portal e retornado com sucesso, mas quando verificamos na prefeitura a nota ainda está como autorizada. Entrei em contato com o suporte do provedor e me responderam "Não conseguimos identificar o motivo do erro, tendo em vista que do nosso lado não há registros de tentativas de comunicação de cancelamento." <retorno> <mensagem> <codigo>00001 - Sucesso</codigo> </mensagem> <identificador>nfse</identificador> <alerta/> <rps> <nro_recibo_provisorio>870</nro_recibo_provisorio> <serie_recibo_provisorio>2</serie_recibo_provisorio> </rps> <numero_nfse>5267</numero_nfse> <serie_nfse>1</serie_nfse> <data_nfse>09/11/2023</data_nfse> <hora_nfse>14:05:33</hora_nfse> <arquivo_gerador_nfse>5267-ped-can.xml</arquivo_gerador_nfse> <nome_arquivo_gerado_eletron>5267-ped-can.xml</nome_arquivo_gerado_eletron> <link_nfse>http://sync.nfs-e.net/datacenter/include/nfw/nfw_imp_notas.php?codauten=0179150018346874</link_nfse> <cod_verificador_autenticidade>0179150018346874</cod_verificador_autenticidade> </retorno>

Aconteceu um caso com nosso de cliente de retornar a rejeição 'TAG:<dest><enderDest>ID:E07/nro(Número) - Nenhum valor informado'. Realmente o cadastro do cliente estava incorreto, após informar o número deu tudo certo. Ao tentar simular o mesmo erro em ambiente de homologação percebi que não está gerando as informações de endereço do destinatário no xml, onde estou errando? NFCE.xml

Ao emitir a primeira NFe da empresa está retornando a rejeição "203 - Emissor nao habilitado para emissao da NF-e" Validado dados do Sintegra e do CCC e tudo aparenta estar correto, alguma ideia? RC CURITIBA.xml

Verifiquei sim, acredito que resolve nosso problema também. Assim passo o layout 6 e o uso continua o que já é hoje. Tem previsão para ficar disponível no svn?

Olá entrei em contato com o banco DAYCOVAL e peguei um manual mais atualizado E como citado ali em cima continua na mesma posição o nosso número 63 com 10 digitos: Segue em anexo o manual SET/2023 que consultei: Manual M. 707 - Banco Daycoval Set-23.pdf

Em contato com o Sefaz de MG (31) 3069-6601 - opção 5 - opção 3, falei com a atendente Maria e a mesma me informou que já foi identificado o problema no portal deles em relação a rejeição 719 e estão trabalhando para resolver.

Se trata de uma nota de exterior então eu posso deixar essa tag vazia.