Italo Giurizzato Junior

Olá Pessoal, Foi publicado a versão 1.02 da NT e o que foi alterado foi simplesmente o código da rejeição e a descrição da mesma. Antes era: Rejeição 831: CFOP inválido, não informar 5932 ou 6932 para operações internas. Agora é: Rejeição 908: CFOP inválido, não informar 5932 ou 6932. Fonte: http://www.cte.fazenda.gov.br/portal/informe.aspx?informe=101

Rogério, Verifica se não tem nenhuma unit que faz parte do componente com uma bolinha vermelha, caso afirmativo delete a unit, atualize novamente, reinstale e compila novamente o programa exemplo e por fim faça novos testes.

Douglas, A minha sugestão de você olhar o MOC é que ele apresenta os cálculos e mostras em quais campos devem ser atribuídos os resultados. Infelizmente não tenho nenhuma rotina para anexar que você poderia tomar como base.

Boa tarde Douglas, Pega o MOC - Manual versão 7.03 - Visão Geral da NF-e, item 9. Sistemática de Cálculo em Operações Interestaduais (EC 87/2015) Quem sabe lhe ajuda a encontrar o problema. Veja o que diz a regra referente a rejeição 695: Informado indevidamente o grupo de ICMS para a UF de Destino (tag:ICMSUFDest): - Não é operação Interestadual (idDest<>2) ou - Não é operação com Consumidor Final (indFinal<>1) ou - Não é operação com Não Contribuinte (indIEDest<>9) ou - Operação de prestação de serviços (existe tag “ISSQN”) ou - Operação com combustível (tag:comb) derivado de petróleo: código ANP diferente de: 820101001, 820101010, 810102001, 810102004, 810102002, 810102003, 810101002, 810101001, 810101003, 220101003, 220101004, 220101002, 220101001, 220101005, 220101006, 560101001, ou - Data de Emissão anterior a 01/01/2016. Exceção 1: A critério da UF a regra de validação acima não se aplica na devolução (finNFe=4) por NFe Avulsa com IE do Emitente=ISENTO. Exceção 2: A regra de validação acima não se aplica se informada UF do local de entrega (tag: entrega/UF) diferente da UF do emitente (tag: emit/enderEmit/UF). Exceção 3: A regra de validação não se aplica, em produção, para Nota Fiscal com data de emissão anterior a 01/07/2016. (NT 2015.003)

Rogério, Favor atualizar os fontes, reinstale o ACBr e faça novos testes.

Boa tarde Marcos, Isso pode ser uma sobrecarga no webservice deles. Peça para os seus clientes abrir um protocolo na prefeitura expondo o problema, desta forma a prefeitura vai forçar o provedor resolver o problema. Quanto mais empresas que emite notas de serviço, protocolarem uma reclamação na prefeitura, mais rápido o problema será resolvido.

Boa tarde Rogerio, Já inclui na minha lista de tarefas. TK-2793

Boa tarde Rogério, Neste caso eu aconselho você usar o Fast Report em vez do Fortes Report. Pois com o Fast você pode criar um FR3 exclusivo para atender as suas necessidades.

Boa tarde Francelin, Muito obrigado pela colaboração, já fiz a alteração e enviei para o SVN. Se você ainda esta usando o componente antigo ACBrNFSe. Lhe convido a iniciar os testes com o novo componente de emissão de NFS-e: ACBrNFSeX O componente antigo: ACBrNFSe não esta mais tendo manutenção. Faça os testes usando o programa exemplo do novo componente. 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/

Bom dia Dercide, Atualizou todos os fontes de todas as pastas? Não tem cópia do ACBr no HD? Na minha maquina também tenho o D7 e não ocorreu esse erro.

Boa pergunta.

Bom dia, No meu entendimento devemos informar qual é o produto predominante de toda a carga que será transportada, independente de qual que seja o CT-e.

Bom dia Igor, Noto que você ainda esta usando o componente antigo. Lhe convido a iniciar os testes com o novo componente de emissão de NFS-e: ACBrNFSeX O componente antigo: ACBrNFSe não esta mais tendo manutenção. Faça os testes usando o programa exemplo do novo componente. 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/

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

Boa tarde, O jeito vai ser entrar em contato com o provedor e expor o problema. Lembre-se o componente apenas gera e envia o XML do Rps para o webservice do provedor. Os arquivo *-soap.xml se referem ao XML que foi enviado para o webservice ou o que foi retornado por ele, O arquivo 341077-lista-nfse-sinc-soap.xml é o de retorno ele conte a lista de NFS-e. Por que lista? Simples, ao enviar um lote este pode ter até 50 Rps. Se eu envio apenas 1 Rps, no retorno é para consta apenas 1 NFS-e caso o Rps tenha sido processado com sucesso. Se eu envio 30 Rps e todos são processados com sucesso, tenho no retorno 30 NFS-e. No seu caso, você esta enviado 1 Rps e é retornar "N" NFS-e, isso esta errado. O WebService com certeza esta com algum bug muito feio.

Boa tarde, O erro 404 não significa que a URL não existe? Caso afirmativo, o que pode ter ocorrido: 1. A cidade mudou de provedor. 2. O provedor mudou a URL da cidade em questão.

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

Márcio, Maravilha, se for geral seria interessante já arrumar para todas as cidades. Se você descobrir com eles todas as cidades que eles atende seria uma mão na roda.

Boa tarde, Fiz uma pequena mudança na sua contribuição e envie para o SVN. Favor atualizar os fontes, reinstalar o ACBr e faça novos testes.

Boa tarde Marcio, Já esta no SVN. Você sabe me informar se o provedor Coplan vai adotar essa nova formatação das URLs para todas as cidades atendidas por ele?

Boa tarde, Já esta no SVN.

Boa tarde Eduardo, Já enviei para o SVN. Note que foi feito um refactoring do componente.

Boa tarde Diego, Favor atualizar os fontes, reinstale o ACBr e faça novos testes. Note que foi realizado um Refactoring no componente.

Boa noite Juliomar, Sim consta no MOC do CTe essa informação.

Boa noite Marcio, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-2774