Italo Giurizzato Junior

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

Boa tarde Júlio, Favor atualizar os fontes e faça novos testes.

Bom dia Júlio, Analisando os fontes do componente temos: Unit: ACBrNFe.pas - método EnviarEmailEvento: ImprimirEventoPDF; NomeArq := OnlyNumber(EventoNFe.Evento[0].InfEvento.Id); NomeArq := PathWithDelim(DANFE.PathPDF) + NomeArq + '-procEventoNFe.pdf'; AnexosEmail.Add(NomeArq); Nesse fragmento de código, temo a chamada para gerar o PDF em seguida a montagem do nome do arquivo a ser anexado ao e-mail, note que o nome do arquivo é: <ID>-procEventoNFe.pdf Unit: ACBrNFeDANFeRLClass.pas - método ImprimirEventoPDF: procedure TACBrNFeDANFeRL.ImprimirEVENTOPDF(ANFe: TNFe); var Impresso: Boolean; I, J: Integer; NumID, ArqPDF: String; function ImprimirEVENTOPDFTipo(EventoNFeItem: TInfEventoCollectionItem; ANFe: TNFe): String; begin Result := Self.PathPDF + OnlyNumber(EventoNFeItem.InfEvento.id) + '-procEventoNFe.pdf'; // TipoDANFE ainda não está sendo utilizado no momento TfrlDANFeEventoRLRetrato.SalvarPDF(Self, EventoNFeItem, Result, ANFe); end; begin (...) end; Nesse fragmento de código, temos uma função chamada ImprimirEventoPDFTipo que monta o nome do PDF e chama o método SalvarPDF passando como parâmetro o nome do PDF. Note que o nome do arquivo PDF é: <ID>-procEventoNFe.pdf Portanto tanto a rotina que salva o PDF quanto a que anexa o PDF no e-mail para ser enviado utilizam o mesmo nome. Concluo que na sua maquina a unit ACBrNFeDANFeRLClass.pas foi alterada e consequentemente ao executar o Tortoise para atualizar os fontes ele não esteja conseguindo atualizar. Verifique se essa unit e outras não contenham uma bolinha vermelha. Caso afirmativo exclua a unit e atualize novamente os fontes, feito isso reinstale a suíte ACBr usando o ACBrInstall_trunk2 com a opção de apagar arquivos antigos marcada. Por fim faça novos testes.

Bom dia Matheus, Favor atualizar os fontes, inclusive do programa exemplo que inclusive nele existe um comentário sobre o campo CodigoTipoCarga.

Bom dia Pires, Esse erro também ocorre com o programa exemplo? Favor anexar os XMLs gerados ao tentar enviar o evento de cancelamento.

Boa noite Cleber, Favor atualizar mais uma vez os fontes e faça novos testes.

Cleber, Favor anexar o XML de envio.

Boa tarde Cleber, Você atualizou todos os fontes de todas as pastas e reinstalou os componentes?

Boa tarde Cleber, Favor atualizar os fontes e faça novos testes.

Boa tarde Cleonir, Muito obrigado pela colaboração, inverti a posição do enumerador tpNaoAplicavel, ou seja, coloquei ele em primeiro lugar. Não vejo problemas. Atualizei o programa exemplo colocando uma observação referente a alimentação do campo. Já esta tudo no repositório.

Boa tarde Edson, Esses XML não é o componente ACBrMDFe que esta gerando, correto? Pois bem a sua rotina foi implementada de forma errada, veja esse diagrama que consta na NT 2020/001: Note que a "moldura" da tag xNome é pontilhada indicando que se trata de uma tag opcional Temos o símbolo de chave seletora onde devemos selecionar se vai ser gerado a tag CPF ou CNPJ ou idEstrangeiro. O contratante pode ser uma pessoa brasileira física ou jurídica ou uma pessoa estrangeira (não importa se é física ou jurídica). No seu caso noto que o contratante é uma pessoa jurídica brasileira, logo não se trata de um estrangeiro, de onde você tirou esse numero para informar em idEstrangeiro? Numero do passaporte dele?

Boa tarde Matheus, Estamos analisando o problema, assim que tivermos uma solução definitiva será enviada para o repositório.

Boa tarde Yago, Independente da onde é o emitente e também independe da UF informada na configuração do componente o MDF-e sempre vai ser enviado para a SEFAZ-Virtual do RS. Você esta usando o componente para gerar o XML, ou é a sua aplicação que esta gerando o XML e esta usando o componente para assinar e enviar?

O programa exemplo mostra como você deve alimentar o componente, as informações ali atribuídas é meramente ilustrativas.

Bom dia a todos, Já enviei os arquivos anexados pelo BigWings para o repositório.

Bom dia Edson, Favor anexar o XML para que eu possa analisar.

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

Bom dia Cleonir, Favor anexar as units alteradas.

Cleber, Neste caso você deve entrar em contato com o eFrete e questiona-los.

Bom dia Hélio, Segundo a NT 2020/001 - MDF-e Integrado, deixa claro que o CIOT vai ser gerado automaticamente pelo Sistema MDF-e. No meu entendimento o Sistema MDF-e é o webservice da SEFAZ que recepciona o MDF-e. Agora a partir de quando isso vai começar a ocorrer e como vai ser esse processo, ou seja, não vai mais ser necessário informar o CIOT no MDF-e, não sei lhe informar pelo simples fato da NT não deixar claro isso. Sendo assim você deve gerar via site ou através do ACBrCIOT que se utiliza do eFrete e enviar o CIOT no MDF-e.

Como dito anteriormente, para que o Destinatário possa obter o XML completo precisa enviar o evento de Manifestação do Destinatário. Já a transportadora obtém o XML completo independente do Destinatário ter enviado o evento ou não. O único requisito é que o CNPJ da transportadora esteja informado no campo CNPJ que se encontra dentro do grupo <transporta>. Configure o componente para salvar os arquivos em disco. Faça um novo teste e depois anexe os XMLs gerados aqui no fórum para que possamos analisar.

Bom dia Cleonir, Muito obrigado pela colaboração, já estou enviando para o repositório.

Bom dia Cleber, Já chegou a fazer testes com o programa exemplo, mas atribuindo o valor libWinCrypt a SSLLib?

Bom dia, É possível sim, da seguinte forma: // após a execução do método DistribuicaoDFePorChaveNFe // a variável aXML é do tipo string, ela vai conter o XML da NF-e obtida pelo método DistribuicaoDfe aXML := ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip[0].XML; // Para ler o XML de uma string usamos o método abaixo ACBrNFe1.NotasFiscais.LoadFromString(aXML); // a partir deste ponto as informações podem ser lidas dos campos desejados

Bom dia, A mensagem de erro é: Sistema e-FRETE (www.efrete.com.br): [Negócio] (Protocolo: 365.227) Erro adicionando operação de transporte: Erro validando motorista: Celular do motorista diferente, verifique se o mesmo celular não está sendo informado para o motorista e o proprietário do veículo. Um telefone celular apenas pode ser informado para uma pessoa. Pela mensagem de erro concluo que o numero do celular informado ao motorista é o mesmo que foi informado ao proprietário do veiculo. Por ser TAC-Agregado o próprio motorista é o proprietário do veiculo, sendo assim deveria aceitar. Para resolver esse problema, o jeito é informar um telefone fixo por exemplo ao cadastrar o proprietário do veiculo e o numero do celular ao cadastrar o motorista, a pesar de ser a mesma pessoa. Você também pode entrar em contato com o eFrete e questionar sobre esse problema. Quem sabe eles melhoram as regras de validação deles.