Italo Giurizzato Junior

Bom dia Thaine, Poste como anexo o XML que foi rejeitado.

Bom dia André, Notei que foi removida a linha que dependendo do código do pais ele mantem a UF, código do municipio, não teria como identificar se a nota é de importação ou não ? Se for em vez de pegar o código do pais do destinatário usariamos o código do Brasil.

Bom dia ncc, Você já tentou entrar em contato com o provedor? e expor o problema: Assinatura do Hash nao confere Se não, aproveite e solicite o XML de envio completo ou seja com as TAGs do envelope.

Ricardo, Sendo assim a rotina que gera o XML vai ter que tratar essas duas situações, quando é de importação e quando não é.

Bom dia Ricardo, Eu nunca emiti uma NF-e de importação, mas você esta informando como destinatário uma empresa estrangeira? Lembre-se que o local de entrega esta atrelado ao destinatário.

Vilmar, O horario da emissão eu sei, a minha pergunta foi, quando ocorreu o cancelamento? Foi logo após o envio, ou minutos, ou horas depois?

Boa tarde Vilmar, A nota foi emitida as 11:30:12 mas quando ocorreu a tentativa de cancelamento? Você esta pegando a data e hora do relógio da maquina, esse relógio esta em conformidade com a data e hora da SEFAZ para onde o evento esta sendo enviado?

Thaine, Note que você tem que configurar o componente para um determinado tipo de ambiente. E ao alimentar o componente com os dados deve informar o mesmo tipo de ambiente. Caso contrario ocorre esse erro.

Boa tarde Adilson, Já esta incluido.

Boa tarde Thaine, Atualize a Unit pcteCTe.pas O seu icone tem que ficar com a bolinha verde caso contrario não esta atualizada.

Boa tarde a todos, Procure deixar essas propriedades com os seus valores padrões. A SEFAZ de São Paulo deve esta passado por varias manutenções e deve estar provocando esses problema. Verifique se a sua rotina não esta disparando chamadas ao Web Service de consulta ao Status de Serviços em curto intervalo de tempo. Se sim, remova essa chamada.

Boa tarde, Poste o XML como anexo para que possamos verificar.

Boa dia Graça, Se não me falha a memória inclui o FormatarPlaca na Unit ACBrDFe que encontra-se na pasta ACBrComum. Verifique se essa Unit esta atualizada e se no Library Path o Path da pasta ACBrComum vem antes do ACBrMDFe.

Bom dia a todos, Primeiramente vamos esclarecer algumas coisas: 1. informar os documentos originários. Um CT-e só pode ter apenas um tipo de documento originário, os tipos são: NF comum (papel), NF-e e outros. Um CT-e pode conter varios documentos originários desde que seja do mesmo tipo. Se tratanto de NF-e basta informar a chave da mesma dentro do grupo <infNFe> (manual versão 1.04c do CTe, página 109). Quando um CT-e tem mais de um documento originário, por exemplo 3 NF-e, as três notas tem que ter o mesmo emitente e o mesmo destinatário, caso contrario não pode. Vamos a um exemplo: NF-e 1: Emitente A, Destinatário B NF-e 2: Emitente A, Destinatário B NF-e 3: Emitente A, Destinatário B Neste caso posso emitir apenas 1 CT-e e colocar as 3 NF-e como documentos originários. Outro exemplo: NF-e 1: Emitente A, Destinatário B NF-e 2: Emitente A, Destinatário B NF-e 3: Emitente A, Destinatário C Neste caso posso emitir 1 CT-e e colocar as NF-e 1 e 2 como documentos originários, mas devemo emitir um segundo CT-e e colocar a NF-e 3 como documento originário, uma vez que o destinatário é diferente. Tipos de transporte, Carga Fracionada e Lotação: Carga Fracionada (aparece 0 na tag <lote>) indica que a carga é composta de varios remetente e vai para varios destinatários, logo temos vários CT-e emitidos para esse caminhão. Lotação (aparece 1 na tag <lote>) indica que toda a carga é de um unico remetente e vai para um unico destinatário, sendo assim temos apenas 1 CTe emitido para esse caminhão. Quanto as informações do Seguro da Carga (página 119 do manual) note que o grupo <seg> é opcional, mas nas observações temos: "Dados obrigatórios apenas no Rodoviário, ...." Espero ter ajudado.

Bom dia Walter, No seu XML notei duas coisas: 1. Você informou 3 notas no caso NF-e, mas esta errado do jeito que você fez, pois esta utilizando o grupo <infOutros> em vez do <infNFe>, já que trata-se de NFe e não um outro tipo de documento. Fica aqui uma pergunta essas 3 notas tem o mesmo emitente e é para o mesmo destinatário? Se sim sem problemas, caso contrario deve-se emitir um CT-e para cada uma. 2. Você informou que trata-se de lotação <lote>1</lote> e não carga fracionada, sendo assim devemos informar os dados do veículo e no seu XML não consta o grupo <veic> Quanto a Rejeição esta estranho, uma vez que você informou sim o valor da carga. Como as SEFAZ estão passando por manutenções, acredito que a mensagem da Rejeição esta errada, em vez de valor da carga seria dados do veículo. Reveja a forma como você esta gerando o XML, quem sabe o problema é sanado.

Boa tarde, Você notou que se trata da IE do Destinatário?

Por favor, Postem os resultados dos testes: Ambiente de Homologação: * Schema que adminite somente 9 digitos * Schema que adminite somente 11 digitos para o Renavam Ambiente de Produção: * Schema que adminite somente 9 digitos * Schema que adminite somente 11 digitos para o Renavam Ao meu ver, e segundo a NT no ambiente de homologação é para funcionar somente com 11 digitos, já no ambiente de produção somente com 9 digitos.

Boa tarde, Note que na mensagem de erro diz que o elemento infCarga esta incompleto, de acordo com o Schema é esperado infQ. De uma olhada no Manual versão 1.04c do CTe página 116.

Boa tarde Pessoal, NT 2013/001 no Portal Nacional do CTe. Por favor baixem e deem uma lida. O RENAVAM vai passar a ter 11 digitos, ja esta disponivel o novo schema também no portal. É bem provavel que vai ter que incluir zeros a esquerda. Mas note que a data de liberação para o ambiente de homologação é 15/04/2013 (hoje) e ambiente de produção é 15/05/2013 . Acabo de disponibilizar o schema que comporta só 9 digitos e uma alteração no componente capaz de gerar o Renavam com 9 ou 11. Continuem com os testes.

Thiago, Após realizar a alteração, você compilou a sua aplicação usando a opção Build?

Boa tade João, Estou atarefado, mas vamos ver se consigo até o final desta semana.

Boa tarde a todos, Por favor abram a Unit ACBrCTeDACTeQR, verifiquem se após as linhas: QRCTe.Prepare; QRCTe.Preview; tem as seguintes linhas: // Incluido por Italo em 11/04/2013 // Segundo o Rodrigo Chiva resolveu o problema de travamento // após o fechamento do Preview Application.ProcessMessages; tem que ficar desse jeito: (...) QRCTe.Prepare; QRCTe.Preview; // Incluido por Italo em 11/04/2013 // Segundo o Rodrigo Chiva resolveu o problema de travamento // após o fechamento do Preview Application.ProcessMessages; end else begin (...)

Boa tarde Helderlr, Não consegui caminhar sobre o problema, acredito que deve ser algum problema nos web services deles. Favor entrar em contato e solicitar um exemplo completo (com as tags do envelope) de envio.

Bom dia a todos, É bem provavel que seja algum problema na SEFAZ-SP. Este final de semana, mais precisamente Domingo, todas as SEFAZ estavam fora do AR, só retornou depois das 18 horas. Devem ter alterado alguma coisa que esta provocando esse problema.

Bom dia Renemelo, Se não atualizou é porque o componente não esta configurado para que isso ocorra. O componente possui uma propriedade: Geral.AtualizarXMLCancelado, favor atribuir o valor True. Segundo, para atulizar o XML, ou seja remover o protocolo de autorização e colocar em seu lugar o de cancelamento, basta executar o seguinte procedimento: // Carrega no Componente o CTe salvo em Arquivo XML ACBrCTe.Conhecimentos.Clear; ACBrCTe.Conhecimentos.LoadFromFile(NomeArquivo); ACBrCTe.Consultar; ACBrCTe.Conhecimentos.Clear; ACBrCTe.Conhecimentos.LoadFromFile(NomeArquivo); ACBrCTe.Conhecimentos.Imprimir; Espero ter ajudado