Italo Giurizzato Junior

Boa tarde Souza, Se você utiliza os componentes ACBr o novo componente ACBrNFSeX, já contempla essa cidade.

Boa tarde Luiz, No layout da ABRASF tanto versão 1 quanto na 2 existe um campo chamado OutrasInformacoes, mas esse campo pertence ao layout da NFS-e e não do Rps. Como o XML da NFS-e é gerado pelo Webservice esse campo é gerado ou não a pedido da prefeitura. Resumindo, não tem o que fazer.

Estou achando que não é o MD5, vou pesquisar também.

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

Boa tarde Isaque, Se para a cidade em questão a versão é 2.03, não adianta você informar que o provedor é GovBr. Esse provedor só tem na versão 1 O que tem na versão 1 e 2 é o Pronim. No arquivo Cidades.ini você vai ter que informar que o provedor é Pronimv2 para essa cidade.

Ramon, Faça uma cópia dessa unit, atualize os fontes e reinstale o ACBr. Faça novos testes.

Boa tarde Ramon, Vou incluir na minha lista de tarefas para verificar esse problema.

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, Fiz mais uma alteração, vamos ver se vai resolver. AssessorPublico.Provider.pas

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.

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

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, 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.