Italo Giurizzato Junior

Boa tarde, Será que só o MD5 deve ser aplicado a senha? Após o MD5 não seria o caso de converter para Hexa?

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

Bom dia A cidade de Maceió se utiliza do provedor Ginfes que segue a versão 1 do layout da ABRASF. Os serviços: ConsultarLote, ConsultarNFSePorRps e ConsultarNFSe disponibilizados pelos provedores que seguem essa versão da ABRASF se a informação passada estiver correta será retornado o XML da NFS-e, logo nas Procedures que tratam o retorno desses serviços vamos encontrar a chamada: SalvarXmlNfse. A procedure SalvarXmlNfse alem de salvar o XML em disco atribui o valor True a propriedade Confirmada. Eu utilizaria a propriedade Confirmada para saber se a nota foi emitida com sucesso ou não. Já a propriedade Status tem como finalidade informar se a nota é Normal ou Cancelada.

Bom dia, Fiz mais uma alteração, vamos ver se vai resolver. AssessorPublico.Provider.pas

Bom dia, Qual é a cidade/provedor?

Bom dia Ignacio, Altere a linha rodo.valePed.disp.add por rodo.infANTT.valePed.disp Outra coisa, configure o componente para a versão 3.00

Bom dia, Já esta no SVN.

Boa noite ALA, Após atualizar todos os fontes de todas as pastas, você reinstalou o ACBr?

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

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.