Italo Giurizzato Junior

Bom dia Matheus, Dependendo da alteração feita no arquivo INI de um provedor não tem nada haver com o código do componente, sendo assim não impede de você criar um novo tópico. Quero lembrar que agora temos um tópico exclusivo para postagens de alterações e acréscimos de cidades.

Bom dia, Ao assinar o RPS de numero 7 a configuração do componente era libCapicom e ao assinar o RPS de numero 9 a configuração foi libWinCrypt? Se sim, esta ai o problema. Ao assinar com libWinCrypt é acrescentado na assinatura as tags de fechamento e o webservice do provedor ao encontrar essas tags acaba acusando que a assinatura esta invalida. Exemplo de como é no Capicom e no WinCrypt: Capicom: <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> WinCrypt: <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></Transform>

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

Bom dia José, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Everto, Muito obrigado pela colaboração, já esta no repositório.

Bom dia Rogerio, Se a tag não esta sendo gerada, a minha suspeita é os caracteres "(" e ")" que constam na mensagem. ValorDesconto=0.00 infAdProd=mais acessorios (ferragens), para adequacao de armario para guarda e organizacao de materiais diversos Mude para: ValorDesconto=0.00 infAdProd=mais acessorios [ferragens], para adequacao de armario para guarda e organizacao de materiais diversos Vamos ver se resolve o problema.

Boa tarde Rogerio, E no XML contem a tag infAdProd?

Bom tarde, O meu conselho é você procurar um bom contador para que lhe passe o calculo correto.

Boa tarde, Você tem o XML de envio (*-ger-nfse.xml e o *-ger-nfse-soap.xml) antes da atualização?

Boa tarde João, Favor atualizar os fontes e faça um novo teste.

Bom dia Gean, No caso da carta de correção quem tem que fazer é a transportadora e não o destinatário ou remetente da carga. Como foi informado que o tomador é o remetente em vez do destinatário, o responsável por enviar o evento de Prestação de Serviço em Desacordo é neste caso o Remetente, uma vez que é ele que aparece como sendo o Tomador do Serviço. Outra coisa, a transportadora tem por obrigação legal assim que obtém o protocolo de autorização do CT-e enviar o XML assinado e protocolado para o Tomador do Serviço. Se o seu cliente tivesse recebido esse XML (uma vez que ele figura como o tomador), por e-mail (por exemplo) e notado que estava errado, já teria tomado providencias. Como a transportadora não enviou o XML, o seu cliente só ficou sabendo quando foi cobrado pelo frete. Nessa história toda, todos tem culpa no cartório. A transportadora por não ter enviado o XML para o tomador do serviço (mesmo este não sendo o tomador). O seu cliente que ficou discutindo com a transportadora e com o destinatário da mercadoria. A pessoal que orientou a pessoa errada para fazer a carta de correção. Quanto a quem deve orientar, na minha opinião tem que ser você, visto que existem muitos contadores por ai que só sabem contar até 10. Pedem coisas absurdas, estão mais pedidos que cego em tiroteio. Então meu caro, trate de estudar tudo sobre os Documentos Fiscais Eletrônicos.

Bom dia Edu, O componente faz tudo, gera, assina e envia os XML dos eventos do Reinf. Não entendo o porque de alguns desenvolvedores quererem gerar o XML através da sua aplicação e usar o componente para fazer o resto. Alguns acabam gerando o XML fora do layout esperado e depois ficam batendo cabeça para descobrir o porque a coisa não funciona. Quanto a documentação, não temos um manual do componente, mas temos um programa exemplo onde você pode estudar nele as funcionalidades que foram implementadas no componente.

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

Bom dia Alisson, Você pegou os fontes do CIOT do Branches? Já vai fazer 3 meses que os fontes do ACBrCIOT já estão no Trunk2. A quanto tempo você não atualiza os seus fontes?

Bom dia João, Acho que deve estar invertido, em vez de tpSim o correto seria tpNao. Por favor faça essa alteração e depois novos testes.

Bom dia Luiz, Muito obrigado pela colaboração, os arquivos corrigidos já se encontram no repositório. Vou fechar o tópico.

Bom dia, Esse erro também ocorre com o programa exemplo? Mas antes não estava enviando e obtendo o retorno?

Carlos, Vou analisar a sua colaboração.

Boa tarde, Favor atualizar novamente todos os fontes de todas as pastas e reinstale a suíte ACBr.

Boa tarde a todos, Enquanto uma meia dúzia ficar conversando com esse pessoal da SimplISS não vai resolver. Você precisam fazer com que todos os seus clientes protocolem uma reclamação na prefeitura. Quem sabe o prefeito tira a bunda da poltrona do gabinete e vai conversar pessoalmente com esse pessoal. Não custa nada sonhar.

Boa tarde a todos, Na versão 2 do layout da ABRASF não existe o método Consultar Situação do Lote, dai a mensagem informando que esse método não foi disponibilizado pelo provedor. Na versão 2, depois do envio devemos consultar o Lote e não a situação do mesmo.

Favor atualizar os fones e faça novos testes. Note que fiz uma alteração no arquivo INI do provedor.

Boa tarde João, Muito obrigado pela colaboração, já esta no repositório.

Boa tarde Jefferson, Basta usar o programa exemplo do componente. Configure ele para uma cidade que utiliza esse provedor.

Boa tarde Mateus, Favor atualizar os fones e faça novos testes.