Italo Giurizzato Junior

Bom dia a todos, Ainda hoje estarei enviando para o repositório, muito obrigado pela colaboração.

Bom dia Luiz, Os XMLs alem da versão ser diferente a SEFAZ-Autorizadora também é, dessa forma não da para fazer comparações. Outra coisa importante, em nenhum Manual ou Nota Técnica ou na Legislação consta que ao cancelar um CT-e o protocolo de autorização deve ser substituído pelo de cancelamento. Infelizmente a SEFAZ-MT no Web Services da versão 2.00 do CT-e (espero que consertem na versão 3.00) ao realizar uma consulta se o CT-e estiver cancelado é retornado o protocolo de cancelamento, sendo que o correto seria retornar o protocolo de autorização e o evento de cancelamento vinculado ao CT-e em questão. O componente por sua vez acaba pegando o protocolo de cancelamento uma vez que o de autorização não é retornado. Na unit ACBrCTeWebServices temos o seguinte fragmento de código que comprova o que foi dito acima. Atualiza := (NaoEstaVazio(CTeRetorno.XMLprotCTe)); if Atualiza and TACBrCTe(FPDFeOwner).cStatCancelado(CTeRetorno.CStat) then Atualiza := False; if (CTeRetorno.cUF = 51) and (CTeRetorno.CStat = 101) then Atualiza := True; Inicialmente a variável Atualizar recebe o valor True caso temos um retorno que contenha o grupo <protCTe>. Depois essa variável poderá se tornar False caso o status do CT-e seja cancelado. Em seguida poderá receber o valor True caso a UF seja 51 (MT) e o status seja 101 (cancelado). A variável Atualiza sendo True faz com que o XML caso esteja com o protocolo de autorizado, faz com que seja atualizado, ou seja, o protocolo de autorização seja substituído pelo de cancelamento. Como dito anteriormente isso esta errado, mas infelizmente a SEFAZ-MT ao consultar um CT-e cancelado não retorna o protocolo de autorizado mais o evento de cancelamento. Se removermos o IF em negrito (acima) um XML que esteja somente assinado, ao realizar essa consulta, corre o risco de ficar sem o protocolo, principalmente se este foi cancelado. Não sei se ficou claro. Mas procure fazer testes na SEFAZ-MT e na de MG com a versão 3.00 para ver o comportamento de de ambas. Faça o seguinte teste. Emita um CT-e na versão 3.00 na SEFAZ-MT, o XML é para ficar com o protocolo de autorizado. Depois remova o protocolo de autorização, carregue o XML e realize uma consulta, é para repor o protocolo de autorizado. O próximo passo é realizar o cancelamento desse CT-e. Remova novamente o protocolo de autorizado, carregue o XML e realize a consulta, verifique se o XML recebeu o protocolo de autorizado (correto) ou o de cancelamento. Depois fação o teste acima com a SEFAZ-MG e compare o resultado de ambas.

Boa noite Luciano, Isso ocorreu porque os seus fontes estão desatualizados, pois essa propriedade esta com o valor default igual a tiNao.

Boa noite, Muito obrigado pela colaboração, já foi enviado para o repositório.

Boa noite, O ACBrCTe possui um método chamado DistribuicaoDFe. Acesse o Portal Nacional do CT-e, baixe a Nota Técnica 2015/002 versão 1.00a e leia atentamente.

Boa tarde, Levei o problema para os demais colegas, para que juntos possamos avaliar melhor.

Boa tarde Rodrigo, Você esta com todos os fontes de todas as pastas atualizados? Não fez nenhuma alteração em nenhum fonte do MDF-e?

Bom dia Marcio, A mensagem de erro não significa que os arquivos XSD estejam incompletos ou errados. A mensagem é clara, você esta tentando validar um XML que não esta assinado. Você deve primeiro executar o método Assinar e depois o Validar só assim o erro vai ser sanado. Se o XML não esta sendo gerado é porque você esta alimentando o componente e depois esta executando o método validar, este não salva XML nenhum no disco, apenas o valida. Quem salva o XML em disco é o Assinar, que alem de assinar o XML o salva em disco caso o componente esteja configurado para tal.

Bom dia Robinho, Antes do componente enviar um evento ou realizar uma consulta, ele verifica se ocorreu a carga de um XML. Se sim busca o tipo de ambiente e a versão, para que o evento ou a consulta seja enviada para o mesmo ambiente e versão. Caso contrario utiliza o tipo de ambiente e versão que consta na configuração. Lembrem-se sempre, para realizarmos o envio de um evento não se faz necessário carregar o XML do MDF-e. Ao realizar a Consulta, podemos carregar ou não o XML do MDF-e. Quando devemos carregar o XML antes de realizar a consulta? Se e somente se o XML em questão foi enviado e ficou sem o protocolo de autorização. Neste caso devemos carregar o XML (assinado) e realizar a consulta, caso o envio foi bem sucedido e a SEFAZ autorizou, será retornado o protocolo e o componente se encarrega de atualizar o XML deixando-o assim completo, ou seja, assinado e protocolo. Por outro lado se a intenção é apenas realizar uma consulta, ai não se faz necessário carregar, devemos apenas informar a chave.

Boa noite André, Sem os XML de envio e de retorno não tem como nós lhe ajudar.

Boa noite Luiz, Não temos o Recibo, pelo simples fato de que o envio do CT-e OS ser síncrono, ou seja, o retorno que temos ao enviar já é o resultado do processamento. Logo você vai ter o retorno da seguinte forma: Protocolo := ACBrCTe.Conhecimentos.Items[ 0 ].CTe.procCTe.nProt; Os demais dados você consegue mudando o nProt pelas demais propriedades disponíveis.

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

Boa noite a todos, Essa alteração resolve o problema, mas a de concordar que a versão 1.00 era para ser encerrada em junho/2017 e foi prorrogada para outubro/2017. Sendo assim as aplicações já deveriam estar prontas e rodando em produção antes de junho/2017. Nós nos esforçamos em adequar os componentes para as novas versões para que eles fiquem prontos as vezes antes da liberação do ambiente de homologação. Neste caso o ACBrMDFe foi adequado em 17/08/2016, nada mais nada menos do que a um ano. Segundo o Manual do MDF-e versão 3.00 temos: Data de início de vigência no ambiente de homologação: 03/10/2016 Data de início de vigência no ambiente de produção: 05/12/2016 Data final da vigência da versão 1.00: 05/06/2017 Como todos podem ver, liberamos o componente ACBrMDFe para a versão 3.00 dois meses antes de liberar o ambiente de homologação. 17/08/2016 -- diversos -- [+] Criada a unit pmdfeConsts que contem as constantes de mensagens usadas na geração dos XML e que são apresentadas quando ocorre erro na validação. [*] Alteração em diversas units em virtude das novas units e para antender a nova versão 3.00 do MDF-e. por: Italo Jurisato Junior Fico muito triste com essas postagens. Paciência, vamos em frente.

Boa noite, A mensagem é clara: Nenhum valor informado no campo NroRegEstadual, esse campo é composto por 25 dígitos.

Boa noite Robinho, Você esta carregando o XML do MDF-e antes de executar a consulta? Se sim, ai esta o problema. Ao carregar o XML o componente se reconfigura baseado na versão do MDF-e carregado que neste caso é 1.00

Rodrigo, Se a empresa é uma transportadora e emite CT-e você não pode dizer que o emitente é transportador de carga própria, pelo simples fato de que a carga não é do emitente e sim de um terceiro (remente). Não tem jeito, essa transportadora vai ter que fazer o seguro da carga que ele vai transportar.

Boa noite José, Se tratando do MDF-e todos os os envios vão para a SEFAZ-RS, não importa a UF do Emitente.

Boa tarde Rodrigo, Você alimentou o componente de forma errada, esta dizendo que o tipo de emitente é um Transportador de carga própria e não um Prestador de serviço de transporte. Sendo assim ele espera a ADD de chNFe e não chCTe. Veja a tag: <tpEmit>2</tpEmit> o correto seria 1 e não 2. Jamais atribua o mesmo valor de nMDF a cMDF por 2 motivos: 1. o tamanho do campo cMDF é de 8 dígitos e de nMDF é 9, logo não cabe um numero de 9 dígitos onde só é aceito 8. 2. quando cMDF é igual a nMDF o documento se torna vulnerável. Essa dica é valida também para a NF-e / NFC-e e CT-e.

Boa tarde Pedro, Só uma correção. As novas versões são: NF-e / NFC-e versão 4.00 CT-e versão 3.00 MDF-e versão 3.00 e não 2.00

Boa tarde, Você tem XSD do CT-e junto com os do MDF-e? Se sim, nunca misture XSD de tipo de documento com outro, terá problemas.

Boa tarde Pedro, Favor anexar o XML do MDF-e rejeitado para que possamos analisar.

Boa tarde, Com essa alteração o grupo <infTribFed> sempre será gerado, desta forma fica em desacordo com o manual.

Boa tarde Graça, Note que no caso do CT-e e NF-e devemos averbar, já o MDF-e devemos declarar. No manual, consta o web services para realizar a declaração do MDF-e e através do mesmo web services podemos enviar os eventos de cancelamento, encerramento e inclusão de condutor. No meu entendimento devemos sim declarar o MDF-e depois de averbar todos os CT-e/NF-e contidos no MDF-e. Quanto ao DAMDFE não encontrei nada.

Boa tarde Flavia, Favor anexar os XML de envio e de retorno do evento de encerramento.

Boa tarde Cleonir, Então o problema não é pegar o retorno do envio e sim erro de validação. O conteúdo do campo NroRegEstadual tem que ter obrigatoriamente 25 dígitos, preencher com zeros a esquerda se necessário.