Italo Giurizzato Junior

Boa noite Neliodv, Muito obrigado pela colaboração, já fiz a alteração e enviei para o repositório.

Bom dia Luiz, O que você quer dizer com "Consultar NFe e CTe"? Baixar o XML ou retornar a informação que o Documento Fiscal Eletrônico consultado esta autorizado ou não? Se a intenção for apenas consultar a situação atual, lembre-se que o método Consultar disponível nos componentes ACBrNFe e ACBrCTe realizam a mesma tarefa e com custo zero. Agora se a intenção é baixar o XML da NF-e, o ACBrNFe possui o método DistribuicaoDFe, se tratando de transportadora o único requisito é que o Emitente da NF-e tem que informar o CNPJ da transportadora no grupo <transporta>. Em breve será possível através do DistribuicaoDFe baixar uma NF-e informado a sua chave, tudo conforme Notas Técnicas publicadas pelo ENCAT e disponibilizadas no Portal Nacional da NF-e. Como você pode ver os recursos disponibilizados nos componentes ACBr sempre estão em conformidade com a legislação, Manuais e Notas Técnicas.

Boa tarde Jean, Colocar 15 chaves de NF-e onde? Como documento originário? Se sim, como você fez para ADD uma chave? Faça o mesmo para ADD as demais.

Boa tarde Claudio, Você não pode inutilizar um numero de um Documento Fiscal Eletrônico no caso o CT-e que foi enviado para SEFAZ seja no ambiente de homologação ou produção. Só é possível inutilizar um numero de um CT-e que não foi enviado, ou seja, não existe. Lembre-se, você inutiliza numero e não CT-e, você cancela CT-e e não numero.

Boa tarde a todos, As informações: Valor total da Carga (Tag: vCarga), Produto Predominante (Tag: proPred) e Outras Características da Carga (Tag: xOutCat) estão dentro do grupo <infCarga> que por sinal esse grupo é obrigatório (1-1). Por outro lado a informação referente ao Código da Unidade de Medida (Tag: cUnid) entre outras informações estão dentro do grupo <infQ>, grupo este obrigatório (1-N). Um detalhe importante o grupo <infQ> é filho de <infCarga> Rogério, por favor veja as páginas 133 e 134 do Manual versão 2.00a do CT-e ou 167 e 168 do Manual versão 3.00 do CT-e.

Boa tarde Marcelo, Muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde LariLopes, Desculpe não entendi nada o que você escreveu no primeiro paragrafo, principalmente: "transportadora emitida em NFe". Por favor seja mais claro, para que possamos ajudar.

Bom dia a todos, Segundo o que consta na página 148 e 145 podemos informar até 4 veículos. Se tratando de um transporte Rodoviário o mais comum é termos 1 ou 2 no caso de (veículo tração "Cavalo" e o reboque "Carreta"). Com exceção do transporte de peças para usinas que pode ocorrer de ter 2 veículos de tração mais o reboque, do resto podemos considerar o que esta acima. Por outro lado, o MDF-e só aceita apenas UM veículo de Tração e até 3 Reboque. Sendo assim aconselho seguir a mesma regra. Tiago, comece a ler o Manual da versão 3.00 do CT-e, não existe mais essas informações, isso me leva a crer que com a obrigatoriedade da emissão do CT-e na versão 3.00 ( Dezembro/2017) será obrigado também emitir o MDF-e versão 3.00, como dito no MDF-e podemos informar 3 veículos, sendo que UM sempre será de tração e os outros 3 caso existam sempre serão Reboques.

Bom dia Luiz, Essa mensagem de erro não tem nada haver com o valor da UF de encerramento e sim com a UF de configuração do componente. Você esta configurando corretamente o componente antes de executar o envio do evento de encerramento do MDF-e?

Boa noite Roberto, Página 134 do Manual versão 2.00a do CT-e. Campo 262 - infNF o elemento é CG Página 137 Campo 297 - infNFe o elemento é CG Página 138 Campo 319 - infOutros o elemento é CG Página 110 temos: CG - indica que o campo é um Elemento de Grupo que deriva de uma Escolha (Choice); Isso significa que você tem que escolher UM entre os TRÊS. Um CT-e pode ter até 2000 documentos originários, mas todos tem que ser NF ou NFe ou Outros. Não podemos misturar, como você pretende, dai o erro de validação.

Boa noite Adriano, Entre em contato com o provedor e questione sobre o Serviço: ConsultarLoteRps, precisamos saber se esse serviço esta disponível ou não.

Boa tarde Leonardo, Se esta gerando uma chave nova é porque você esta atribuindo o valor zero a propriedade cMDF. A propriedade cMDF significa: código aleatório do MDF-e. Na minha aplicação antes de gravar os dados do MDF-e no banco de dados, gero esse código com 8 dígitos e salvo junto com os demais dados. Ao alimentar o componente leio o campo do banco de dados que contem o código aleatório e atribuo a propriedade cMDF. Desta forma como cMDF não é zero ao gerar novamente o mesmo MDF-e a chave não vai mudar.

Bom dia Adriano, Atribua o valor True a propriedade ConsultarLoteAposEnvio.

Bom dia xara, Você não acha loucura desenvolver uma aplicação para emissão de MDF-e 100% Web? Onde vai rodar essa aplicação, no seu servidor Web ou da Transportadora que vai emitir o MDF-e ou de um provedor de Internet? Supondo que ele vá rodar no seu servidor ou de um provedor de Internet, o que você vai dizer para o dono da Transportadora que a sua aplicação esta "fora do ar", logo ele não tem como emitir o MDF-e, por consequência o caminhão não vai poder sair.

Bom dia Eliezer, Fiz mais alguns ajustes e enviei para o repositório, favor atualizar os fontes e fazer novos testes.

Bom dia Rafael, Tenha em mente o seguinte: 1. O componente ACBrNFSe não gera o XML da NFS-e, este é retornado pelo provedor, o componente apenas o extrai do retorno e salva em disco. 2. O componente gera o XML do RPS, este é enviado para o provedor que valida e processa, o resultado desse processamento é a NFS-e.

Boa noite Alexandre, Qual é o provedor? Você esta com todos os fontes de todas as pastas atualizados?

Boa noite TS1Desenvolvedor, Em vez de alterar o componente que é usado por dezenas e até centenas sem nenhum problema, porque você não procure saber porque esta sendo ADD dois conhecimentos na lista? Vasculhe a sua rotina a procura de dois: ACBrCTe.Conhecimentos.Add você vai encontrar eu lhe garanto.

Boa noite Eliezer, Vou avaliar as suas alterações, caso estejam corretas vou enviar para o repositório.

Rodrigo, Desenvolvi a minha aplicação para emissão de CT-e sem ter um certificado digital de cliente. Usei um certificado digital disponibilizado pela SEFAZ-RS, mas esse certificado só serve para assinar o XML, logo não serve para enviar o CT-e para SEFAZ. Apesar dessa restrição, consegui fazer com que a minha aplicação gerasse o XML, assinasse e validasse sem nenhum erro. Procurei deixar todas as rotinas prontas, quando apareceu o primeiro cliente, pedi a ele o certificado para realizar os testes de envio. Você não tem nenhum cliente que seja transportadora tudo bem, mas o seu Escritório de contabilidade não possui nenhum cliente que seja uma transportadora? Transportadora esta que utiliza o certificado A1 e que possa disponibilizar uma cópia para que você possa realizar os seus testes?

Boa tarde Rodrigo, Repito, esse fiscal não sabe o que almoçou hoje, logo o que ele disse é uma tremenda asneira. Por outro lado, você deve através do seu Contador fazer com que ele desfaça esse loucura de ter transformado a sua empresa de desenvolvimento em uma transportadora.

Boa tarde, Primeiramente não devemos trocar o protocolo de autorização pelo de cancelamento, caso a nota venha ser cancelada. Na versão 6.0 do Manual da NF-e em nenhuma linha esta escrito que devemos fazer essa troca. O arquivo *-nfe.xml para ter validade jurídica tem que estar assinado e com o protocolo de autorização. Esse arquivo tanto o emitente quanto o destinatário da mercadoria tem que possuir e guarda-lo pelo período legal. Caso a nota venha ser cancelada, teremos o arquivo *-procEventoNFe.xml. Esse arquivo contem o pedido de cancelamento, mais a assinatura digital do emitente, mais o protocolo da SEFAZ que atesta que a nota foi cancelada. O *-procEventoNFe.xml também deve ser enviado ao destinatário, primeiro para ele saber que a nota foi cancelada, segundo, ele também deve ser guardado por ambos pelo período legal. Agora se ao carregar o XML da NF-e sem o protocolo de autorização e você tem o erro de DigestValue diferente ao termino da execução do Consultar, tente fazer desta forma: LoadFromFile( xNomeXML, False); // False = Não gerar novamente o XML Consultar;

Boa tarde Clerisonb, O arquivo *-pro-lot.xml contem 2 TAGs chamadas cStat. A primeira informa o status do processamento do lote, que no caso tem que ser 104 = Lote Processado com Sucesso. Já a segunda informa o status do processamento da nota, que no caso tem que ser 100 = Autorização de Uso. Os arquivos *-env-lot.xml se trata do arquivo de envio do lote, o componente não possui nenhum método capaz de carregado-lo para ser enviado novamente. Repito, você tem que ler o arquivo *-nfe.xml (assinado e sem o protocolo de autorização) usando para isso o método LoadFromFile da seguinte forma: LoadFromFile(xNomeXML, False); O segundo parâmetro ( False ) diz ao método que o objetivo é apenas ler o conteúdo do XML que precisa estar assinado. Depois basta executar o método Consultar. Agora se você não tem o arquivo *-nfe.xml a solução é: Ler os dados da venda do banco de dados para alimentar o componente. É preciso garantir que o valor de cNF tem que ser exatamente o mesmo de quando o nota foi gerada pela primeira vez. Após alimentar o componente, devemos executar o método Assinar e em seguida o Consultar. Não confunda nNF com cNF, o primeiro se refere ao numero da Nota Fiscal, já o segundo se refere ao código aleatório da Nota Fiscal. O numero da NF tem 9 dígitos já o código da NF tem apenas 8 dígitos. Muitos atribuem o valor de nNF a cNF, isso esta errado por 2 motivos. Primeiro, o que você vai fazer quanto o numero da NF chegar a ter 9 dígitos? Segundo, a SEFAZ recomenda que seja um código aleatório por motivos de segurança para o próprio emitente da NF. Dica: quando for salvar no banco de dados os dados da NF, acrescente mais uma campo na tabela. Esse campo pode se chamar CodigoNF e ser do tipo Inteiro. Na sua aplicação faça com que seja gerado um numero com 8 dígitos, utilize para isso a função Random. Quando for alimentar o componente leia o valor do campo CodigoNF e atribua a propriedade cNF do componente.

Boa tarde Vanderlei, Solicite junto ao provedor um XML de exemplo, de preferencia já envelopado para o envio.

Boa tarde Tulio, O arquivo Tinus.ini não deve ser alterado apenas o Cidades.ini conforme BigWings postou. Certifique-se que todos os arquivos de todas as pastas estão atualizados. No arquivo Tinus.ini a URL de homologação tem que estar dessa forma: http://www2.tinus.com.br/csp/teste%NomeURL_H%/WSNFSE.... O componente troca automaticamente o %NomeURL_H% pelo valor informado em: Nome_URL_H que se encontra no arquivo Cidades.ini da respectiva cidade.