Italo Giurizzato Junior

Luiz, Esse CT-e é de complementação de valores e não um CT-e Normal. Sendo assim ele não possui o grupo infCTeNorm consequentemente não temos a TAG qCarga. Abra o XML usando um navegador que você vai notar após o grupo <imp> a presença do grupo infCteComp com a TAG chave, chave esta do CT-e que foi complementado. Você deve inicialmente checar se a lista possui elementos para que você possa ler, caso contrario vai ocorrer erro. Por exemplo: if AcbrCte.Conhecimentos.Items[0].Cte.infCteNorm.InfCarga.InfQ.count >0 then Carga := AcbrCte.Conhecimentos.Items[0].Cte.infCteNorm.InfCarga.InfQ.Items[0].qCarga;

Boa tarde Luiz, Por favor post como anexo o XML do CT-e que você esta tentando ler os dados.

Bom dia Tatieli, Segundo o seu MDF-e a UFIni = RS e UFFim = ES sendo assim o o Percurso tem que ser: SC / PR / SP / MG / ES ou SC / PR / SP / RJ / ES você informou apenas SC e PR Lembre-se que o percurso é só de ida e não devemos informar a UF de inicio e a de Fim que no seu caso é RS e ES.

Boa tarde Edson, Você esta configurando desta forma? ACBrNFe1.DANFE.TipoDANFE := tiNFCe;

Boa tarde Lalin, Neste caso é preciso checar se o XML esta sendo gerado segundo um modelo e ao enviar esta sendo configurado o componente com outro modelo, por exemplo o modelo que consta no XML é 65 (NFC-e) mas o componente esta sendo configurado como sendo 55 (NF-e).

Bom dia Lalin, A rejeição diz: Lote So Podera Conter Nf-E Ou Nfc-E, isso me faz concluir que o lote possui 2 ou mais notas, neste caso todas tem que ser do mesmo modelo. ​Não posso enviar um lote contendo NF-e e NFC-e, se o emitente hora emite NF-e (para pessoa jurídica por exemplo) e hora emite NFC-e (para pessoa física por exemplo) tem que gerar e enviar dois lotes caso tenha varias notas de modelos diferentes para serem enviadas.

Bom dia Abrantes, Se você programa em Delphi, não faz sentido você utilizar um outro programa como é o caso do Monitor. O Monitor foi criado para os desenvolvedores que não programam em Delphi. Garanto que você terá menos problemas.

Atualiza os fontes e tente novamente.

Bom dia Thiago, O certificado não esta vencido? Se não esta, por que você não utiliza o método DistribuicaoDFe?

Bom dia, O certificado não esta vencido?

Bom dia Luiz, Quando você diz: "Os XML gerados pelo nosso sistema nunca ocorre isso,..." concluo que o seu sistema utiliza o ACBrNFe, correto? Se sim, isso é uma prova que os componentes ACBr estão em conformidade com os manuais e notas técnicas. Com certeza os sistemas dos fornecedores não utilizam os componentes ACBr. Paciência. Uma outra coisa para se checar é se o programa de e-mal que você utiliza não esta gerando essas quebras de linha. Uma vez fiz o seguinte teste: Recebi um e-mail com o XML de uma nota, salvei o mesmo em disco tudo OK, anexei o mesmo em outro e-mail e envie para um terceiro, este recebeu o XML com as quebras de linhas.

Bom dia Enderson, Aconselho você passar a usar o método DistribuicaoDFe em vez do ConsultarNFeDest, pois este último será desativado.

Bom dia Edson, Veja bem não existe o tipo de impressão = 6, conforme a sua alteração se configurarmos o componente para Tipo de Impressão = tiNFCeA4 ao gerar o XML será informado o numero 6 e desta forma vai ocorrer um erro de validação ou Rejeição. Da forma que estava antes, bastaria configurar o componente e alimentar a propriedade tpImp segundo o tipo tiNFCeA4 que iria funcionar. Com a sua alteração devemos configurar o componente com o valor tiNFCeA4 e alimentar a propriedade tpImp com o valor tiNFCe, para que não ocorra erro.

Bom dia Tatieli, Esse XML não foi gerado pelo componente ACBrMDFe, correto? Se sim, compare os nomes das TAGs do seu XML com a estrutura que encontra-se na Nota Técnica 2013/004 versão 1.00a de Outubro. No seu XML consta a TAG: infmuncarrega e na NT temos: infMunCarrega, esse é apenas uma das TAGs que esta com a grafia errada. Da onde você tirou a informação que a versão do modal informado no MDF-e é 2.00? Em uma passada rápida pelo seu XML encontrei vários outros erros, a minha sugestão é que você utilize o componente mencionado acima, pois ele esta em conformidade com a Nota Técnica.

Boa tarde Felipe, Lembre-se que o cancelamento é por evento, sendo assim uma nota autorizada nunca terá o seu numero de protocolo de autorização alterado por um de cancelamento. E ao executar o método Consultar é para sempre retornar o O status de Autorizado e caso a nota possua eventos vinculados a mesma será retornado a lista de eventos. Como a nota foi cancelada é para constar nessa lista o evento de cancelamento. Proponho a não atribuir o valor True a propriedade AtualizarXMLCancelado.

Boa tarde Rene, Sendo o Schema o campo Competência só existe na estrutura da NFS-e e não existe na do RPS. Sendo assim, não tem como informar e mesmo que seja informado não sera gerado no XML do RPS. Se no caso de Curitiba esse campo esta sendo gerado com o valor 01/0001 no XML da NFS-e, com certeza é um erro no Web Service do provedor. Lembre-se sempre o componente gera o XML do RPS, envia para o provedor e este por sua vez gera o XML da NFS-e caso o RPS seja processado com sucesso.

Bom dia Tiago, Os componentes: ACBrNFe e o do DANFE são criados e destruídos toda vez que você vai emitir uma nota ou é criado na execução da aplicação e só é destruído quando a mesma é encerrada? Tenho uma aplicação que emite NF-e, coloquei os componentes em um Data Module, testei a minha aplicação com certificado A1, com A3 no formato cartão e tokem, sem nenhum problema. O projeto da minha aplicação, cria todos os form assim que a mesma é carregada e os destrói assim que é finalizada.

Bom dia Mateus, O componente ACBrCTe até tem a propriedade VersaoDF, mas se não me falha a memória não é utilizada, pois o mesmo só gera os XMLs na versão 2.00

Bom dia Thiago, Você tem que informar o ambiente ( taHomologacao ou taProducao) em dois lugares. 1. Na configuração do componente 2. Na alimentação do mesmo junto com os demais dados referente ao transporte da carga. é lógico que em ambos os lugares tem que ser igual, caso contrario ocorre essa rejeição.

Bom dia Carlos, Esta errado, note que o nome da TAG é campoAlterado e não caminho do do campo alterado. Sendo assim o campoAlterado é qCarga e o grupoAlterado é o grupo que o campo pertence, ou seja infQ, portanto o correto é: ... <infCorrecao> <grupoAlterado>infQ</grupoAlterado> <campoAlterado>qCarga</campoAlterado> <valorAlterado>95</valorAlterado> </infCorrecao> ... Mas você deve primeiro consultar uma tabela que contem a relação dos campos que não podem ser alterados por uma CC-e, essa tabela esta no Manual versão 2.00a do CT-e.

tiautomação, esse é a quarta postagem em tópicos diferentes que você aborda o mesmo problema. Por favor se atenta as regras do fórum.

Bom dia, Alguns detalhes que notei no seu XML. 1. Foi informado 2 veículos no CT-e e ambos o tipo de proprietário de ambos é Terceiro, neste caso devemos informar quem é o proprietário dos veículos. 2. Ambos são do tipo de rodado igual a outros, quando informamos dois veículos, um é o "cavalo" e o outro é a carreta. 3. Ambos são do tipo Carreta igual a não aplicado, como foi informado dois veículos, o segundo é uma carreta, logo você deve informar o seu tipo. 4. Foi informado duas vezes o mesmo motorista, acredito que seja uma falha na sua aplicação, ao incluir dois veículos, esta incluído o motorista também duas vezes. a quantidade de motoristas não esta vinculada a quantidade de veículos. Pois posso ter apenas um veículo e 3 motoristas diferentes, que vão se revesando durante a viagem.

Boa tarde a todos, Peço a gentileza de acessar o Portal Nacional do MDF-e e baixar a Nota Técnica 2015/002 que trata sobre o assunto do Web Service de Distribuição de DF-e. São apenas 11 páginas, em uma rápida leitura a ideia e a estrutura é semelhante para não dizer igual ao mesmo Web Service da NF-e com o mesmo propósito. Sendo assim acredito em em poucos dias estaremos disponibilizando a sua implementação no componente ACBrMDFe. Mas a liberação do ambiente de homologação esta prevista para o dia 01/09/2015 e para o ambiente de produção: 15/09/2015. Sendo assim, mesmo que até o final deste mês esteja tudo implementado, os testes só vão poder ser realizados em setembro. Como temos 3 meses para implementar, peço mais uma vez que baixem a NT e leiam com muita calma. Gente são apenas 11 páginas.

Boa tarde Lucas, Foi eu que implementei o DANFE NFC-e em Quick Report e nos meus testes a leitura do QR-Code ocorreu 100%. Na época usei uma bematech MP-4000 TH não fiscal.

Boa tarde Thiago, No que diz respeito a alimentação do componente com os dados pertinentes ao transporte da carga, favor estudar o fragmento de código que esta salvo com o nome alimentarcomponente.txt dentro da pasta: ...\Exemplos\ACBrCTe Com relação ao PIN, isso mesmo somente devemos informar quando se tratar da zona franca de Manaus.