Italo Giurizzato Junior

Bom dia Warley, Favor anexar o XML de retorno da SEFAZ após enviar um CT-e com numeração já utilizada.

Bom dia Antônio, Verificando o Schema a palavra "NÃO" tem que estar acentuada. O rejeição é a 599, que diz que não pode ter caracteres de edição. Através do bloco de notas não vi nada de anormal, algo do tipo: tabulação, mudança de linha, espaços em branco. Favor verificar a sua rotina que gera o XML, para descobrir se nenhum outro tipo de caractere esta sendo inserido.

Bom dia Augusto, Com essa alteração, as cidades que se utilizam desse provedor o envio ocorreu com sucesso? Ou tem alguma cidade que o valor de URI tem que ser 1?

Bom dia Valdelir, Você esta com todos os fontes de todas as pastas atualizados? Reinstalou os componentes usando o ACBrInstall_Trunk2? A sua aplicação esta usando os arquivos INI atualizados? Pelo fato de alguns provedores estarem usando versões diferentes, como é o caso do Pronim, que para uma determinada cidade a versão é 2.02 e para outra é 2.03, decidi incluir um campo chamado VersaoDados no arquivo Cidades.ini Se a cidade em questão tem uma versão diferente da que consta no arquivo INI do provedor, devemos incluir esse campo no arquivo Cidades.ini para a respectiva cidade.

Bom dia Luis, Muito obrigado pela colaboração, já enviei para o repositório. Fiz uma pequena alteração, em vez de "igual" mudei para "maior ou igual" no IF que verifica a versão. Fique a vontade em realizar novos ajustes para compatibilizar com a nova versão.

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

Boa tarde Walter, Como isso ocorreu? A sua aplicação não gera automaticamente a numeração do CT-e? Ela permite que o usuário possa alterar o numero do CT-e? Você pode sim inutilizar uma faixa de números, sendo que a faixa máxima é de 10 mil. Se for necessário inutilizar uma faixa de 15 mil por exemplo deverá ser feita em duas etapas.

Boa tarde Antônio, Remove o acento da palavra "NÃO". E tente novamente.

Boa tarde Roberto, Primeiramente esse XML não esta assinado. Segundo, qual foi o erro de validação?

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

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.

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.