Italo Giurizzato Junior

Informe a senha normal se criptografar ela. Mas utilize a unit em anexo. AssessorPublico.Provider.pas Vamos ver se vai ocorrer o mesmo problema.

Boa tarde, Você tem o manual desse provedor, quero saber como devemos informar a senha.

Thiago, Pelo jeito só o envio unitário que esta funcionando. Retorno do envio do lote no modo síncrono: <return>Erro: ERRO AO INICIAR A CONEXAO: (). The transaction log for database 'SMARtb' is full due to 'LOG_BACKUP'.</return> Retorno do envio unitário: <Mensagem>Signature failed core validation&#13;O RPS 1361 JÁ EXISTE. &#13;Signature failed core validation&#13;O CNPJ/CPF do Tomador não pode ser igual o CNPJ/CPF do Prestador.&#13;O campo Atividade informado não pertence a lista de atividades do CCM.&#13;O campo CEP do Tomador é obrigatorio.</Mensagem> A mensagem diz que o Rps de numero 1361 já existe, logo você não pode enviar ele novamente. Outro erro: foi informado como tomador (CNPJ/CPF) o mesmo do prestador e isso não é aceito. Por fim foi informado uma atividade que não existe e o CEP do tomador deve ser informado.

Esses 2 XML são de consulta.

Boa tarde, Muito obrigado pela colaboração, já inclui na minha lista de tarefas.

Boa tarde Rafael, Complementando o que o Daniel escreveu, a inutilização não é um evento, pois ao enviar um evento devemos informar a chave de uma NF-e, já a inutilização consiste em apenas inutilizar um numero ou uma faixa de números, números este que não se referente a nenhuma nota. Logo a dica do Daniel em realizar uma consulta só vai funcionar para os eventos e não para a Inutilização. Verifique se o numero de protocolo retornado ao inutilizar novamente o mesmo numero se é o numero do protocolo gerado ao inutilizar o numero. Acredito que essa pesquisa da para ser feita no Portal Nacional da NF-e. Se for o mesmo, o jeito vai ser reconstruir na unha o arquivo *-ProcInutNFe.xml que é o arquivo que contem o pedido de inutilização, mais o retorno da SEFAZ com o protocolo de inutilização.

Boa tarde João, Muito obrigado pela contribuição, já inclui na minha lista de tarefas.

Boa tarde Patrick, Se você tiver alguma unit alterada por você o tortoise não costuma atualizar. Veja se não tem nenhuma unit referente ao componente que esteja com uma bolinha vermelha em seu ícone, caso tenha delete a unit, atualize novamente e reinstale o ACBr.

Boa tarde, Por favor não cole conteúdo de XML como parte do texto, procure sempre anexar o arquivo. Da forma que você fez fica difícil de saber o que esta ocorrendo. Quanto ao provedor Ginfes, já faz uma semana que o ambiente de homologação esta parado, pelo jeito o de produção esta com problemas agora.

Boa tarde, O numero do protocolo normalmente é retorno ao enviar o lote no modo Assíncrono e ele é utilizado depois para consultar a situação do lote e por fim consultar o lote. Quanto enviamos o lote no modo Síncrono não temos o numero do protocolo, pois nesse modo já temos o XML da NFS-e como resposta. A cidade de São José/SC se utiliza do provedor Betha que segue a versão 1 do layout da ABRASF, sendo assim o envio é no modo Assíncrono. Você consegue pegar o numero do protocolo de outra forma, vide o programa exemplo.

Boa tarde Gabriel, Lhe convido a iniciar os testes com o novo componente de emissão de NFS-e: ACBrNFSeX O componente ACBrNFSe não vai mais ter manutenção. Manual de Migração https://www.projetoacbr.com.br/forum/topic/63017-manual-de-migração-para-o-novo-componente-de-emissão-de-nfs-e/

Boa tarde Djean, Estou fazendo alguns testes usando o novo componente com o programa exemplo e não tive esse erro. Seria interessante debugar para saber o que esta sendo retornado. Nos meus últimos testes com esse provedor o retorno veio no formato Json e não XML.

Boa tarde Thiago, Favor anexar os XML de envio e de retorno (soap) para que eu possa analisá-los e fazer algum ajuste necessário.

Boa tarde Fábio, Na Nota Técnica 2020/005 diz que o tipo da tag passou a ser "C", ou seja, Caractere e o seu tamanho máximo para 20. Mas veja o que esta escrito na coluna de observação dessa tag: O número do Ato Concessório de Suspensão deve ser preenchido com 11 dígitos (AAAANNNNNND) e o número do Ato Concessório de Drawback Isenção deve ser preenchido com 9 dígitos (AANNNNNND). (Observação incluída na NT 2013/005 v. 1.10) Note que tanto o numero do Ato Concessório de Suspensão quanto o de Isenção são compostos por dígitos. O que eu não entendi é o fato do tamanho agora ser de 20 caracteres. Existe a possibilidade de informar ambos os números, ou seja, na mesma tag informar o número do Ato Concessório de Suspensão e o de Isenção? Se sim, então explica o tamanho 20, pois um tem 11 e o outro tem 9, informando os dois teríamos um numero com 20 dígitos. Se existe essa possibilidade, então devemos realmente fazer um ajuste nessa função. Ou para informar que o numero é de Suspensão ou Isenção devemos informar da seguinte forma: SUSPENSAOAAAANNNNNND - quantidade de caracteres 20 ISENCAOAANNNNNND - quantidade de caracteres 16 Isso explica a mensagem no inicio da NT que diz que a tag agora passa a ser alfa-numérico. Se for dessa forma que devemos agora informar no XML, não vejo necessidade de alterar a função, pois ela elimina os caracteres que não são dígitos.

Bom dia Guilherme, Não estamos mais dando manutenção no componente antigo. Por favor instale e faça os testes com o novo componente de emissão de NFS-e: ACBrNFSeX.

Bom dia Patrick, Você atualizou os fontes? Pela sua imagem continua gerando da forma antiga. E o componente foi alterada para gerar conforme solicitado pelo provedor IPM.

Bom dia, Com essa alteração resolveu o problema? Se sim, favor anexar a unit alterada para que possamos validar e enviar para o SVN.

Bom dia Thiago, Essa rejeição ocorre ao enviar o CT-e para a SEFAZ ou ocorre ao averbar o CT-e?

Bom dia José, Eu não tenho nenhuma aplicação que envia o eSocial e não conheço a fundo para te orientar com uma certa propriedade. Mas pelo o que eu entendi, você exclui o cadastro de um funcionário e agora quer cadastrar ele novamente. Pela mensagem de erro, concluo que existem eventos referentes a esses funcionário que foi excluído e pela orientação que consta na mensagem você deve excluir também todos esses eventos. Depois você cadastra ele novamente e envia novamente todos os eventos referente a esse funcionário. Você seguiu a orientação que consta na mensagem?

Bom dia Italo, Pelos XMLs em anexo noto que você esta usando o componente antigo. Por favor faça os testes usando o novo componente.

Bom dia Valdir, Nos últimos testes que realizei, notei que o provedor IPM esta retornando a resposta no formato Json em vez de XML, o componente ainda não esta preparado para ler o retorno no formato Json. Já estamos trabalhando para contornar esse problema.

Boa tarde Diego, Já esta no SVN.

Boa tarde a todos, Sim, o problema é no ambiente de homologação do Ginfes que não esta funcionando.

Boa tarde Soares, Se você conseguir fazer um teste com o componente antigo que segundo o Leandro esta funcionando, favor anexar os XMLs (soap) gerados tanto de envio quanto de retorno para que eu possa comparar com o que esta sendo gerado pelo componente novo.

Boa tarde, Verifica com o provedor se esse usuário e senha que você utiliza no site pode ser utilizados no webservice. Talvez para o webservice se faz necessário um outro usuário e senha.