Italo Giurizzato Junior

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.

Bom dia Paulo, O DAMDFE foi feito em Quick Report, Fast Report e Fortes Report. Para cada um existe um pacote de instalação, no caso do Fortes você deve utilizar o ACBrMDFeDAMDFeRLpkg.

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.

Boa tarde Heronim, Muito obrigado pela colaboração, já esta disponível.

Boa tarde Gabriel, Porque você não utiliza o próprio componente para gerar o XML? Porque você carrega o XML salvo em disco em uma variavel Stream e depois o carrega novamente usando o loadfromstream? Sendo que você pode: ACBrNFSe.NotasFiscais.LoadFromFile(<nome completo do arquivo>);

Boa tarde Rômulo, Esse IF pelo que estou vendo faz parte da sua rotina que alimenta o componente, correto?

Boa tarde Jefferson, É preciso comparar o conteúdo do XML do RPS com o da NFS-e, no que diz a rentenção. Lembre-se que o XML do RPS é gerado pelo componente, já o XML da NFS-e é gerado pelo provedor.

Jorge, Não utilizo o Delphi XE somente o Delphi 7.

Boa tarde CSO, Antigamente ao cancelar uma nota o componente trocava o protocolo de autorização pelo de cancelamento se fosse configurado para realizar essa troca. Mas com a mudança do cancelamento para evento e a possibilidade de emitir um "documento" com os dados do cancelamento, ou seja, numero do protocolo, data, motivo, etc. o componente deixou de realizar a troca mencionada acima. Sendo assim, o componente ACBrNFe que é utilizado no ACBrNFeMonitor não altera o XML de uma NF-e. Para quem programa em Delphi e dependendo do Report utilizado para impressão do DANFE até existe uma possibilidade de imprimi-lo com tarja: NF-e Cancelada, como não utilizo o ACBrNFeMonitor não sei se isso é possível com ele. De qualquer forma é possível através do ACBrNFeMonitor: enviar por e-mail o XML e o PDF referente ao "documento" que comprova que a nota foi cancelada, bem como a sua impressão. Espero ter ajudado.

Boa tarde Jorge, Acredito que o problema seja a versão do Quick Report para o Delphi XE. Veja o DACTE usando o seu XML gerado através da minha aplicação compilada com o Delphi 7 - Quick Report 5.02 31150608384759000127570000001280541001280545-cte.pdf

Boa tarde Lucas, Realmente o prazo para o cancelamento mudou agora é de 24 horas. No caso do MDF-e todos os Estados brasileiros se utilizam da SEFAZ-RS portanto a regra neste caso é unica.