Italo Giurizzato Junior

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

Boa tarde Paulo, Favor atualizar os fontes e faça um teste com a minha alteração.

Boa tarde Carlos, Primeiramente peço que não poste código como parte do texto da postagem a não ser que seja meia dúzia de linhas, caso contrario coloque em um arquivo texto e anexa a postagem. Segundo, favor anexar os arquivos soap tanto do envio quando do retorno para que possamos analisar.

Bom dia Roberto, O grupo <infFretamento> só será gerado se for um CT-e OS e se o tipo de serviço for 6 = Transporte de Pessoas, ou seja, Fretamento. Se não for esse o seu caso, não precisa se preocupar.

Bom dia Eduardo, Por favor, vamos seguir as regras do fórum, não faça a mesma pergunta em vários tópicos.

Bom dia Eduardo, Use o programa exemplo do componente. Configure para salvar os arquivos soap. Configuracoes.WebServices.Salvar := True; Ao enviar será gerado o XML envelopado.

Bom dia Edson, Como não existe mais a tag <refCTe> a solução para referenciar é colocando a chave deste CT-e no campo de observação.

Boa tarde Costa, No ambiente de produção você informou o idCSC e CSC de produção? No ambiente de homologação qual versão do QR-Code você estava usando (1.00 ou 2.00)? Manteve a mesma versão para o ambiente de produção?

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

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

Boa tarde Rafael, Favor atualizar os fontes e faça novos testes.

A assinatura é realizada pelas classes ACBrDFe. Os componentes que mencionei herdam o método Assinar implementado no ACBrDFe.

Boa tarde Robson, Você esta carregando um XML não assinado? Outra coisa, quem disse a você que o numero do recibo que devemos usar para a consulta se encontra na chave do MDF-e?

Boa tarde Alison, Na imagem que você anexou, a pasta Fontes possui uma bolinha vermelha. Isso significa que dentro dessa pasta ou sub pasta existe pelo menos um fonte que foi alterado. Como a Graça disse, as vezes o Tortoise não atualiza o fonte que esta alterado. Procure o(s) fonte(s) que tenham a bolinha vermelha e apague. Depois atualize novamente, você vai ver que os mesmos serão restaurados. Verifique novamente se a pasta Fontes agora esta com uma bolinha verde. Caso afirmativo, execute o ACBrInstall_Trunk2, não esqueça de primeiro fechar o Delphi. Outra coisa importante ao executar o instalador ative a opção para apagar os fontes antigos, esse processo é demorado mas pode resolver muitos problemas.

Boa tarde a todos, Erro não catalogado é problema na SEFAZ. Favor entrar em contato e relatar o problema.

Boa tarde Sandro, Pelo que pude ver essa assinatura requer 3 algoritmos de transformação, a assinatura usada pelos documentos fiscais eletrônicos tais como: NF-e, NFC-e, CT-e, CT-e OS, MDF-e, BP-e, eSocial e Reinf e grande maioria dos provedores de NFS-e se utilização de apenas 2 algoritmos de transformação. O provedor IPM, mais uma vez querendo ser diferente. Não vejo a hora da NFS-e Padrão Nacional se tornar realidade e acabar com essa palhaçada dos provedores.

Boa tarde João, Você poderia anexar o XML gerado pelo componente para que possamos comparar com o modelo que você anexou?

Boa tarde Kleiser, Acredito que a unit que gera o evento 1060 não tenha sido atualizada e não foi criado a unit referente ao evento 1065. Se desejar contribuir com as alterações e implementação ficaremos agradecidos.

Boa tarde Luciana, Não existe o serviço de inutilização de numero ou faixa de números no que diz respeito ao MDF-e. Sendo assim a minha sugestão é que ocorra o envio do MDF-e e depois o seu cancelamento, informando como justificativa: desacordo comercial ou algo do tipo. Não exclua da base de dados o MDF-e que não foi enviado, pois a amanhã a SEFAZ poderá cobrar uma explicação pelos "pulos" de numeração.

Boa tarde Rene, Acredito que a rejeição seja: 577. Se sim, lembre-se que se o tomador for contribuinte do ICMS o CT-e a ser substituído não pode ter sido anulado. Só anulamos um CT-e quando o tomador não for contribuinte do ICMS. Neste caso o tomador deverá emitir uma declaração. No CT-e de substituição devemos informar a chave do CT-e a ser substituído (original) e em refCteAnu informar a chave do CT-e de anulação. Quando o tomador é contribuinte do ICMS, este deverá emitir um documento fiscal que poderá ser uma NF-e ou NF (comum de papel caso ainda não seja obrigado a emitir NF-e) ou CT-e (caso seja outra transportadora). E no CT-e de substituição devemos informar a chave da NF-e no campo refNFe, se for CT-e informar a chave deste no campo refCTe, se for uma NF (comum de papel) informar os dados nos campos que compõe o grupo refNF.

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

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

Alison, Notei nesse XML que a URL referente ao QR-Code foi gerada segundo a versão 1.00 e não na versão 2.00 Você disse que definiu a versão diretamente no componente, mas esta gerando na versão 1.00 Todos os fontes de todas as pastas estão atualizados? Após baixar a atualização, você reinstalou os componentes através do ACBrInstall_Trunk2? Será que a sua aplicação não esta pegando um DCU antigo de alguma unit do componente?

Bom dia Adryelle, A principio o que deveria ocorre ao realizar a consulta. A SEFAZ retornar o grupo infProt com os dados referente a autorização da nota e em seguida a lista de eventos vinculados a mesma, que neste caso seria o evento de cancelamento. É bem provável que a SEFAZ em vez de retornar os dados referente a autorização, esta retornado os dados referente ao cancelamento dentro do grupo infProt mais o evento de cancelamento. Isso explica o fato de ao consultar o grupo infProd não ser adicionado ao XML quando a propriedade AtualizarXMLCancelado esta com o valor False.

Bom dia Alison, Favor anexar o XML da nota que esta sendo rejeitada, para podermos analisar.