Pesquisar na Comunidade

O que é o CIOT? CIOT é a sigla para Código Identificador da Operação de Transporte. Esse é um código gerado para registrar operações de transporte rodoviário remunerado de cargas junto à ANTT (Agência Nacional de Transportes Terrestres). Ele é obrigatório para o controle e rastreabilidade dessas operações no território nacional. Atualmente a regulamentação mais recente relacionada a ele sendo a Resolução nº 6.078, de 24 de março de 2026. O CIOT é uma novidade? Não. O CIOT já existe desde 2011. No entanto, quando foi estabelecido, seu uso era obrigatório apenas em operações de transporte muito específicas. Esse cenário mudou em 2026 com a Resolução nº 6.078, de 24 de março de 2026, que efetivamente tornou o CIOT obrigatório em praticamente todas as operações de transporte rodoviário remunerado de cargas. Veja abaixo a evolução da legislação: Quem deve gerar o CIOT? A Resolução nº 6.078/2026 estabeleceu em seu Art. 1º-A que toda operação remunerada de transporte rodoviário de cargas deverá ser registrada por meio de um CIOT, delegando a responsabilidade pela sua geração conforme a tabela abaixo: Operação de Transporte Responsável pelo CIOT Quando há contratação de TAC ou TAC Equiparado Contratante/Subcontratante Quando NÃO há contratação de TAC ou TAC Equiparado A própria ETC O que significam os termos TAC, TAC Equiparado e ETC mencionados acima? TAC é a sigla para Transportador Autônomo de Cargas. É a pessoa física que realiza o transporte rodoviário de cargas como atividade profissional. ETC é a sigla para Empresa de Transporte Rodoviário de Cargas. É a pessoa jurídica que tem como atividade principal o transporte rodoviário de cargas. TAC Equiparado é a denominação dada à ETC que possui em sua frota até 3 veículos registrados junto ao Registro Nacional de Transportadores Rodoviários de Cargas (RNTRC), bem como às Cooperativas de Transporte de Cargas, que também se enquadram nessa categoria. TAC Agregado é o Transportador Autônomo de Cargas que coloca veículo de sua propriedade ou posse — conduzido por ele mesmo ou por um preposto — a serviço de um contratante em regime de exclusividade, mediante remuneração previamente acordada. IPEF é a sigla para Instituição de Pagamento Eletrônico de Frete. É a instituição regulamentada pela ANTT responsável por realizar o pagamento eletrônico do frete e vinculá-lo à operação de transporte remunerado correspondente. Além disso, a IPEF participa do arranjo de pagamentos instantâneos instituído pelo Banco Central do Brasil, o que na prática significa que o pagamento do frete pode ser realizado via Pix. Devo gerar o CIOT quando a empresa possui frota própria e motoristas empregados? Sim, quando a empresa presta transporte rodoviário remunerado de cargas para terceiros. Ter frota própria e motoristas empregados não caracteriza, por si só, a operação como transporte de carga própria. Se a empresa transporta cargas ou encomendas de terceiros mediante remuneração, trata-se de uma operação de transporte por conta de terceiros, e o CIOT deve ser gerado conforme a regulamentação vigente. Por outro lado, se a carga transportada é da própria empresa, sem prestar serviço a terceiros e sem recebimento de frete, a geração do CIOT não é necessária. Como faço para gerar o CIOT? A geração do CIOT é feita de formas distintas dependendo de quem é o responsável pela operação. Se houve contratação de TAC ou TAC Equiparado, o CIOT deve ser gerado por uma das IPEFs habilitadas pela ANTT, por meio de portal próprio ou integração direta via web service disponibilizado pela própria IPEF. Caso a ETC seja a responsável, ela pode utilizar o sistema disponibilizado pela ANTT por meio do programa CIOT para Todos. Para que servem a DLL e o executável encontrados no programa CIOT para Todos? Não para uso rotineiro. A geração do CIOT por meio do programa CIOT para Todos deve ser feita via integração com o web service disponibilizado pela própria ANTT. A DLL e o executável são destinados exclusivamente ao uso em contingência, ou seja, situações em que a integração com o web service não está disponível. Nesses casos, eles permitem gerar o número do CIOT sem todos os dados da operação, funcionando como solução temporária. No entanto, em até 168 horas, o CIOT deverá ser regularizado pelos meios adequados, conforme o fluxograma abaixo. Existe alguma solução no ACBr para me ajudar a gerar o CIOT? Atualmente o ACBr conta com o componente desenvolvido nativamente para Delphi e Lazarus denominado ACBrCIOT, que realiza a integração com a IPEF eFrete. A integração com novas IPEFs, bem como a disponibilização do CIOT no ACBrMonitorPLUS e na ACBrLib, estão previstas em nosso planejamento para implementação futura. O programa de exemplo do componente ACBrCIOT pode ser encontrado no caminho: ..\trunk2\Exemplos\ACBrDFe\ACBrCIOT onde estão disponíveis versões tanto para Delphi quanto para Lazarus. Onde posso encontrar os manuais das IPEFs? Os manuais de cada IPEF podem ser encontrados no portal respectivo de cada uma. Além disso, nós também os centralizamos em nosso biblioteca do Tools em ...\tools\DFe\CIOT Onde devo preencher o CIOT? O CIOT deve ser informado no Manifesto Eletrônico de Documentos Fiscais (MDF-e), no elemento CIOT, que faz parte do grupo infCIOT presente nas informações da ANTT. A estrutura do XML com essa informação é semelhante a este exemplo: <rodo> <infANTT> <infCIOT> <CIOT>pseudoCIOT</CIOT> <CNPJ>pseudoCNPJ</CNPJ> </infCIOT> </infANTT> </rodo> O campo <CNPJ> ou <CPF> deve ser preenchido com a identificação do responsável pela geração do CIOT. Como preencher o CIOT no MDF-e utilizando o componente ACBrMDFe? Caso utilize componente nativo para Delphi/Lazarus, alimente as propriedades: var lMDFe: TMDFe; lRodo: Trodo; linfCIOT: TinfCIOTCollectionItem; begin lMDFe := ACBrMDFe1.Manifestos.Add.MDFe; lRodo := lMDFe.rodo; linfCIOT := lRodo.infANTT.infCIOT.New; linfCIOT.CIOT := 'pseudoCIOT'; linfCIOT.CNPJCPF := 'pseudoCNPJ'; //Demais informações... end; Caso utilize ACBrMonitorPLUS ou ACBrLibMDFe, alimente em seu arquivo INI: [infCIOT001] CNPJCPF=pseudoCNPJ CIOT=pseudoCIOT O CIOT é exibido no DAMDFe? Não! De acordo com o Manual MDFe Anexo II DAMDFE v3.00a, não há previsão de que o CIOT seja exibido no DAMDFe, portanto sua ausência não indica nenhum problema. Links Úteis e Referências RESOLUÇÃO Nº 3.658, DE 19 DE ABRIL DE 2011 RESOLUÇÃO Nº 5.862, DE 17 DE DEZEMBRO DE 2019 RESOLUÇÃO ANTT Nº 6.078, DE 24 DE MARÇO DE 2026 Lei nº 11.442 de 05 de janeiro de 2007 Perguntas Frequentes - CIOT

Olá comunidade ! Foi publicada a Nota Técnica 2026/001 v1.00 para o MDF-e discorrendo sobre regra de validação para este documento. Alteração A nova NT não traz alterações no leiaute, ela apenas traz uma regra de validação que segue: Datas Implantação Homologação: 21/09/2026 Implantação Produção: 23/11/2026 Vale ressaltar que apesar das datas presentes na NT para a ativação da regra de validação, já existe Resolução que obriga o CIOT no MDF-e. E como fica o ACBr? Alterações no ACBr não são necessárias. Leia a nota técnica na íntegra AQUI.

Olá comunidade ! As novas regras do Código Identificador da Operação de Transporte (CIOT) entraram em vigor neste domingo (24), às 18h, ampliando a obrigatoriedade do cadastro para todas as operações de transporte rodoviário remunerado de cargas. A medida tem como objetivo fortalecer a rastreabilidade das operações, aprimorar a fiscalização e garantir o cumprimento do Piso Mínimo de Frete. Para auxiliar empresas e transportadores na adaptação às novas exigências, a Agência Nacional de Transportes Terrestres (ANTT) disponibilizou a área “CIOT para Todos” em seu portal oficial, com documentos técnicos, orientações e perguntas frequentes sobre o novo modelo. Para mais detalhes, confira: Fonte oficial: Portal da ANTT - CIOT para Todos

Olá comunidade ! Foi publicado no dia 09/04/2026 o DESPACHO Nº 18, de 8 de Abril de 2026 trazendo múltiplos Ajustes Siniefs. Dentre eles temos o Ajuste SINIEF Nº 5, de 6 de Abril de 2026 que altera o Ajuste SINIEF nº 21, de 10 de dezembro de 2010, alterando a redação do § 2º da cláusula terceira de: Para: A nova redação remove os casos de exceção e estabelecendo que deve ser emitido um MDF-e por UF de descarregamento agregando as cargas de cada UF para todos os casos. Essa alteração entra em vigor a partir de 01/06/2026 conforme cláusula segunda do referido ajuste:

Uma empresa que produz e transporta seus produtos em caminhões próprios tem que ter seguro da carga? Ao tentar emitir o MDFe recebo a rejeição: MoRodoviario é obrigatório o seguro da carga.

Olá, comunidade ! Foi publicado no Diário Oficial da União o DESPACHO Nº 33, DE 8 DE OUTUBRO DE 2025, efetivamente adicionando a necessidade da geração de um MDF-e por UF unidade federada. Fazem parte deste Despacho, dentre outros, os Ajustes Sinief relacionados abaixo. O AJUSTE SINIEF Nº 27, de 3 de Outubro de 2025 altera o Altera o Ajuste SINIEF nº 21, de 10 de dezembro de 2010 que institui o MDF-e, modificando a redação do § 2º da cláusula terceira para: Este mesmo ajuste também acrescenta o § 2º-A na mesma cláusula:

Olá pessoal! Foi publicada a primeira nota técnica de 2025 para o MDF-e. Alterações Modificações no leiaute A tag tpCarga do grupo que recebe as informações do produto predominante (prodPred) passa a aceitar também o valor 12 - Granel Pressurizada. Altera a definição da tag nCompra do grupo vale pedágio para "Identificador do vale pedágio obrigatório - IDVPO". Modifica a definição das infPag e Comp do leiaute do modal rodoviário para "Informações do pagamento do contrato" e "Componentes do pagamento do contrato" respectivamente. A tag tppComp do grupo dos componentes de pagamento do contrato passa a aceitar o valor 04-Frete. A tag tpValePed do grupo do Vale Pedágio passa a aceitar os valores 01-TAG e 04-Leitura de placa. Além disso os valores 02 (cupom) e 03(cartão) deixam de ser aceitos. A tag CIOT do grupo infCIOT passa a ser opcional. O leiaute do modal aquaviário ganha o campo Maritime Mobile Service Identify (MMSI) opcional de tamanho 9 aceitando apenas números. Além das modificações de leiaute, os regex também são atualizados nos arquivos de schema para aceitar o CNPJ alfanumérico. Regras de validação Adiciona regras de validação solicitadas pela ANTT para validar: A presença do NCM do produto predominante. A presença das informações de pagamento para carga lotação. O preenchimento dos dados bancários de pagamento para TAC e equiparado a TAC. O preenchimento do CIOT para TAC e equiparado a TAC. Datas Implantação Homologação: 07/2025 Implantação Produção: 10/2025 E como fica o ACBr? As soluções do ACBr serão revisadas e quaisquer modificações necessárias serão disponibilizadas em tempo hábil para que possam realizar testes em homologação. Leia a nota técnica na íntegra AQUI.

Olá pessoal! Foi publicada em 08/05/2025 a Nota Técnica Conjunta 2025/001 para tratar do CNPJ Alfanumérico modificado pela Instrução Normativa 2229 de 15 de outubro de 2024, afetando os ambientes autorizadores da NFe, NFCe, CTe, CTe OS, GTVe, MDFe, BPe, BPe TM, NF3e e NFCom. Nova lei de formação do número do CNPJ O tamanho do CNPJ permanece sendo 14, no entanto, agora as oito primeiras posições que identificam a raiz e as 4 posições seguintes que identificam a ordem do estabelecimento inscrito aceitaram caracteres alfanuméricos (letras e números). Os dois últimos dígitos verificadores permanecerão aceitando somente números. O cálculo dos dois últimos dígitos verificadores também foi alterado para se aceitar as novas possibilidades. Alterações necessárias nos Documentos Fiscais Eletrônicos Campos do tipo CNPJ Os arquivos de schema dos diversos DFes que utilizam o CNPJ já foram atualizados previamente alterando a expressão regular para aceitar letras maiúsculas nas primeiras 12 posições: [A-Z0-9]{12}[0-9]{2} Observação: Algumas letras não devem ser aceitas no CNPJ Alfa, como I, O, U, Q e F, essa exclusão faz parte das solicitações feitas pela equipe técnica do ENCAT para a Receita Federal do Brasil e precisa ser confirmada. Regras de Validação Não se aplicam modificações nas regras de validação relacionadas, considerando que as mesmas visam autenticar a veracidade dos 2 últimos dígitos verificadores do CNPJ. A partir da implementação desta NT, o contribuinte pode considerar que os ambientes autorizadores já estão adequados ao novo cálculo proposto para o DV. Nota aos Autorizadores: As rotinas de validação de CNPJ devem rejeitar CNPJ Alfanuméricos informados anteriores a data de implantação de cada ambiente (homologação e produção), mesmo que seja admitida a informação na validação de schema (já modificado). A rejeição aplicada nesse caso será a de falha no cálculo do Digito verificador. Chave de Acesso ao Documento Fiscal Eletrônico A expressão regular que valida a chave de acesso passa a suportar letras nas 12 primeiras posições da informação correspondente ao CNPJ que compõe a chave. Cálculo do DV da Chave de Acesso Assim como o cálculo do DV para o CNPJ foi alterado, também será necessário modificar o cálculo do DV da chave de acesso seguindo a mesma lógica proposta, a fim de suportar o alfanumérico. Regras de Validação da Chave de Acesso De forma semelhante as regras de validação relacionadas ao CNPJ, a regra de validação da chave de acesso vai validar o DV da chave e portanto o contribuinte pode considerar que o novo cálculo já vai estar sendo utilizado pelos sistemas autorizadores. Nota aos Autorizadores: As rotinas de validação de Chave de acesso devem rejeitar chaves contendo CNPJ Alfanuméricos informados anteriores a data de implantação de cada ambiente (homologação e produção), mesmo que seja admitida a informação na validação de schema (já modificado). A rejeição aplicada nesse caso será a de falha no CNPJ informado na chave de acesso. Padrão do Código de Barras dos Documentos Auxiliares O padrão utilizado atualmente é CODE-128C que suporta apenas números. A sugestão é a adoção de um modelo híbrido, usando o CODE-128C quando houver somente caracteres numéricos e o CODE-128A que aceita letras e números quando houver CNPJ alfanumérico. Datas A previsão de geração dos primeiros CNPJ Alfanuméricos está definida para julho de 2026. E como fica o ACBr? O componente ACBrValidador utilizado em funções para validar o CNPJ alfanumérico já está adequado para aceitar CNPJs Alfanuméricos. Foi criada a #TK-7034 para revisão dos componentes e possíveis adequações que possam vir a ser necessárias. Qualquer novidade será divulgada neste tópico. Leia a nota técnica na íntegra AQUI.

Olá pessoal! Foi publicado o AJUSTE SINIEF Nº 2, DE 11 DE ABRIL DE 2025 que aumenta o prazo em que o fisco deve guardar os documentos fiscais eletrônicos emitidos. Em outras palavras, agora o fisco deve guardar o XML da NF-e, CT-e, MDF-e, NFC-e, BP-e, NF3e, CTe-OS, GTV-e, DC-e, NFCom e todos os seus eventos vinculados por um período de 11 anos. O ajuste entra em vigor na data de sua publicação e produz efeitos a partir do primeiro dia do mês subsequente. Vale mencionar: O prazo de guarda desses documentos pelos contribuintes permanece inalterado conforme artigo 174 da Lei N° 5.172, de Outubro de 1996: Em outras palavras, a Sefaz precisa guardar os XMLs por 11 anos e o contribuinte precisa guardar o XML por 5 anos.

Entendendo o problema. O Manifesto Eletrônico de Documentos Fiscais (MDF-e), conforme seu leiaute, permite que sejam referenciados documentos originários. Estes documentos podem ser CT-es, NF-es ou outros MDF-es. Esta é a regra de validação corresponde a esta rejeição de acordo com o MOC Anexo I - Leiaute e as Regras de Validação: Conforme é possível observar, se você está recebendo está rejeição significa que essas informações não foram encontradas no arquivo XML que foi enviado ao web service. Como resolver? Se você utiliza o componente nativo para Delphi/Lazarus, precisa referenciar o documento conforme exemplo: var LManifesto: TManifesto; LInfMunDescarga: TinfMunDescargaCollectionItem; LInfCTe: TinfCTeCollectionItem; LInfCT: TinfCTCollectionItem; LinfNFe: TinfNFeCollectionItem; LInfMDFeTransp: TinfMDFeTranspCollectionItem; LInfUnidTransp: TinfUnidTranspCollectionItem; Lperi: TPeriCollectionItem; begin LManifesto := ACBrMDFe1.Manifestos.Add; LInfMunDescarga := LManifesto.MDFe.infDoc.infMunDescarga.New; //=============>CT-e<============================= LInfCTe := LInfMunDescarga.infCTe.New; LInfCTe.chCTe := ''; LInfCTe.SegCodBarra := ''; LInfCTe.indReentrega := ''; LInfUnidTransp := LInfCTe.infUnidTransp.New; LinfUnidTransp.tpUnidTransp := utOutros; LinfUnidTransp.idUnidTransp := ''; with LinfUnidTransp.lacUnidTransp.New do nLacre := ''; with LinfUnidTransp.infUnidCarga.New do begin tpUnidCarga := ucOutros; idUnidCarga := ''; with lacUnidCarga.New do nLacre := ''; qtdRat := 0; end; LinfUnidTransp.qtdRat := 0; Lperi := LInfCTe.peri.New; Lperi.nONU := ''; lperi.xNomeAE := ''; Lperi.xClaRisco := ''; Lperi.grEmb := ''; Lperi.qTotProd := ''; Lperi.qVolTipo := ''; LinfCTe.infEntregaParcial.qtdTotal := 0; LinfCTe.infEntregaParcial.qtdParcial := 0; with LinfCTe.infNFePrestParcial.New do chNFe := ''; //=============>CT<============================= LinfCT := LInfMunDescarga.infCT.New; LInfCT.nCT := ''; LInfCT.serie := 0; LinfCT.subser := 0; LinfCT.dEmi := Now; LinfCT.vCarga := 0; LInfUnidTransp := LInfCT.infUnidTransp.New; LinfUnidTransp.tpUnidTransp := utOutros; LinfUnidTransp.idUnidTransp := ''; with LinfUnidTransp.lacUnidTransp.New do nLacre := ''; with LinfUnidTransp.infUnidCarga.New do begin tpUnidCarga := ucOutros; idUnidCarga := ''; with lacUnidCarga.New do nLacre := ''; qtdRat := 0; end; LinfUnidTransp.qtdRat := 0; //=============>NF-e<============================= LinfNFe := LInfMunDescarga.infNFe.New; LinfNFe.chNFe := ''; LinfNFe.SegCodBarra := ''; LinfNFe.indReentrega := ''; LInfUnidTransp := LInfNFe.infUnidTransp.New; LinfUnidTransp.tpUnidTransp := utOutros; LinfUnidTransp.idUnidTransp := ''; with LinfUnidTransp.lacUnidTransp.New do nLacre := ''; with LinfUnidTransp.infUnidCarga.New do begin tpUnidCarga := ucOutros; idUnidCarga := ''; with lacUnidCarga.New do nLacre := ''; qtdRat := 0; end; LinfUnidTransp.qtdRat := 0; Lperi := LInfNFe.peri.New; Lperi.nONU := ''; lperi.xNomeAE := ''; Lperi.xClaRisco := ''; Lperi.grEmb := ''; Lperi.qTotProd := ''; Lperi.qVolTipo := ''; //=============>MDF-e<============================= LInfMDFeTransp := LInfMunDescarga.infMDFeTransp.New; LInfMDFeTransp.chMDFe := ''; LInfMDFeTransp.indReentrega := ''; LInfUnidTransp := LInfMDFeTransp.infUnidTransp.New; LinfUnidTransp.tpUnidTransp := utOutros; LinfUnidTransp.idUnidTransp := ''; with LinfUnidTransp.lacUnidTransp.New do nLacre := ''; with LinfUnidTransp.infUnidCarga.New do begin tpUnidCarga := ucOutros; idUnidCarga := ''; with lacUnidCarga.New do nLacre := ''; qtdRat := 0; end; LinfUnidTransp.qtdRat := 0; Lperi := LInfMDFeTransp.peri.New; Lperi.nONU := ''; lperi.xNomeAE := ''; Lperi.xClaRisco := ''; Lperi.grEmb := ''; Lperi.qTotProd := ''; Lperi.qVolTipo := ''; Caso utilize ACBrMonitorPLUS ou ACBrLib: ; Utilize tags abaixo para Adicionar CTes Relacionados [infCTe001001] chCTe= SegCodBarra= indReentrega= [peri001001001] nONU= xNomeAE= xClaRisco= grEmb= qTotProd= qVolTipo= [infEntregaParcial001001] qtdTotal=0 qtdParcial=0 [infUnidTransp001001001] idUnidTransp= tpUnidTransp= qtdRat= [lacUnidTransp001001001001] nLacre= [infUnidCarga001001001001] idUnidCarga= tpUnidCarga qtdRat= [lacUnidCarga001001001001001] nLacre= ; Utilize tags abaixo para Adicionar NFes Relacionadas [infNFe001001] chNFe= SegCodBarra= indReentrega= [peri001001001] nONU= xNomeAE= xClaRisco= grEmb= qTotProd= qVolTipo= [infUnidTransp001001001] idUnidTransp= tpUnidTransp= qtdRat= [lacUnidTransp001001001001] nLacre= [infUnidCarga001001001001] idUnidCarga= tpUnidCarga qtdRat= [lacUnidCarga001001001001001] nLacre= ; Utilize tags abaixo para Adicionar MDFes Relacionados [infMDFeTransp001001] chMDFe= indReentrega= [peri001001001] nONU= xNomeAE= xClaRisco= grEmb= qTotProd= qVolTipo= [infUnidTransp001001001] idUnidTransp= tpUnidTransp= qtdRat= [lacUnidTransp001001001001] nLacre= [infUnidCarga001001001001] idUnidCarga= tpUnidCarga qtdRat= [lacUnidCarga001001001001001] nLacre= Eu preenchi estas informações, mas mesmo assim elas não foram geradas no meu XML. Para entender isso, primeiro precisamos observar as regras de validação das rejeições 638, 639 e 540: Veja que de acordo com o Tipo do Emitente (tpEmit) que foi preenchido no MDF-e, um determinado tipo de documento não pode ser referenciado. As soluções do ACBr já fazem estas tratativas internamente. Então se, por exemplo, você preencheu o valor 1 para o tpEmit, e preencheu as informações de uma NF-e referenciada, essas informações não serão adicionadas no XML. Você deve corrigir o tpEmit.

Boa tarde, gostaria de saber se o ACBrMonitor já está preparado para encerramendo de MDF-e por terceiro? Pois procurei em https://acbr.sourceforge.io/ACBrMonitor e não encontrei nada referente a encerramento de MDF-e por terceiro.

MDFe.xmlMDFe.xmlBoa tarde, estou migrando o webserviço para o [https://mdfe.svrs.rs.gov.br/ws/MDFeRecepcaoSinc/MDFeRecepcaoSinc.asmx] e esta me retornando esta mensagem: cStat:243 xMotivo:Rejeicao: XML Mal Formado seguem XML em anexo <enviMDFe xmlns="http://www.portalfiscal.inf.br/mdfe" versao="3.00"> <idLote>1</idLote> <MDFe> <infMDFe Id="MDFe52240610903047000119580030000000011000111795" versao="3.00"> <ide> <cUF>52</cUF> <tpAmb>2</tpAmb> <tpEmit>2</tpEmit> <mod>58</mod> <serie>3</serie> <nMDF>1</nMDF> <cMDF>00011179</cMDF> <cDV>5</cDV> <modal>1</modal> <dhEmi>2024-06-29T13:10:08-03:00</dhEmi> <tpEmis>1</tpEmis> <procEmi>0</procEmi> <verProc>BRdata</verProc> <UFIni>GO</UFIni> <UFFim>SC</UFFim> <infMunCarrega> <cMunCarrega>5201504</cMunCarrega> <xMunCarrega>Apore</xMunCarrega> </infMunCarrega> <infPercurso> <UFPer>MS</UFPer> </infPercurso> <infPercurso> <UFPer>SP</UFPer> </infPercurso> <infPercurso> <UFPer>PR</UFPer> </infPercurso> </ide> <emit> <CNPJ>10903047000119</CNPJ> <IE>104533811</IE> <xNome>ICM COMERCIO DE CEREAIS LTDA</xNome> <xFant>ICM COMERCIO DE CEREAIS LTDA</xFant> <enderEmit> <xLgr>AREA RURAL DE RIO VERDE</xLgr> <nro>SN</nro> <xBairro>AREA RURAL DE RIO VERDE</xBairro> <cMun>5218805</cMun> <xMun>RIO VERDE</xMun> <UF>GO</UF> <fone>6436238890</fone> </enderEmit> </emit> <infModal versaoModal="3.00"> <rodo> <infANTT> <RNTRC>51890300</RNTRC> </infANTT> <veicTracao> <placa>RHB7J91</placa> <tara>0</tara> <capKG>0</capKG> <capM3>0</capM3> <condutor> <xNome>VANDERLEI DE ALMEIDA</xNome> <CPF>04262224902</CPF> </condutor> <tpRod>03</tpRod> <tpCar>03</tpCar> <UF>PR</UF> </veicTracao> </rodo> </infModal> <infDoc> <infMunDescarga> <cMunDescarga>4207304</cMunDescarga> <xMunDescarga>IMBITUBA</xMunDescarga> <infNFe> <chNFe>52240210903047000119550010000265991000347062</chNFe> </infNFe> </infMunDescarga> </infDoc> <tot> <qCTe>0</qCTe> <qNFe>1</qNFe> <qMDFe>0</qMDFe> <vCarga>107199.52</vCarga> <cUnid>01</cUnid> <qCarga>54370.0000</qCarga> </tot> </infMDFe> <infMDFeSupl> <qrCodMDFe>https://dfe-portal.svrs.rs.gov.br/mdfe/qrCode?chMDFe=52240610903047000119580030000000011000111795&amp;tpAmb=2</qrCodMDFe> </infMDFeSupl> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <Reference URI="#MDFe52240610903047000119580030000000011000111795"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <DigestValue>/T/Lefg3SF2GhWXliE7SuWiSc8I=</DigestValue> </Reference> </SignedInfo> <SignatureValue>PU9SNe23KiKsUFr1g0+x8AyRnLNP8e6pEfBEfSyYoJuc190mKJs7o+lbPmHE8NmA0WYFYCx/53+SeWRrTo8rqCfESabPqbHMuK8JIT0sUnqgp1xblFuPbZdENpklNQVpd8oIx/cTfO/hz3wzP5cvG0Foqiol2gCEUYfpWuau3ra9SpeUTHbh6gu1TjHmukPQteL4NMg+yyfEslJpq80FriY2JfDD7CctyNuXsnxLjXMltPF1mkKTJxxQJVGZyh8RInuW9sNFC2SaJvTDw+9Wzp5tBdh9Slpsu+mxfdiOfWPBZTKX2oqmgl5Lh5ImpLLwWwKfKHXzUozbxrjW25qf4g==</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>MIIH6DCCBdCgAwIBAgIIRx+5eVi+ox0wDQYJKoZIhvcNAQELBQAwdjELMAkGA1UEBhMCQlIxEzARBgNVBAoTCklDUC1CcmFzaWwxNjA0BgNVBAsTLVNlY3JldGFyaWEgZGEgUmVjZWl0YSBGZWRlcmFsIGRvIEJyYXNpbCAtIFJGQjEaMBgGA1UEAxMRQUMgU0FGRVdFQiBSRkIgdjUwHhcNMjMxMjE0MTgzMDUyWhcNMjQxMjEzMTgzMDUyWjCB/TELMAkGA1UEBhMCQlIxEzARBgNVBAoTCklDUC1CcmFzaWwxCzAJBgNVBAgTAkdPMRIwEAYDVQQHEwlSSU8gVkVSREUxNjA0BgNVBAsTLVNlY3JldGFyaWEgZGEgUmVjZWl0YSBGZWRlcmFsIGRvIEJyYXNpbCAtIFJGQjEWMBQGA1UECxMNUkZCIGUtQ05QSiBBMTEXMBUGA1UECxMOMjI2MjEzNjMwMDAxODcxGTAXBgNVBAsTEHZpZGVvY29uZmVyZW5jaWExNDAyBgNVBAMTK0lDTSBDT01FUkNJTyBERSBDRVJFQUlTIExUREE6MTA5MDMwNDcwMDAxMTkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChxs6hN+yPH93/UNngJt0rKFM5JXNlxDHmt4dM7GpaVGjzCWfmuFyka+tEfNCdb4xxvQtaqiIfBVIokKoCiwkzSVY29AreIf6VjlxOZi3q72mFVymmqiFOnfMhXLH3AMxBs3J7crcXH+5QtJA/QOqQcP65j884l2JiQdSr7FMx/BzX1YH9pRgm5BgSWJNz15kNNs0WLF0TWsoHUIuBLh/q3RbR84oCk6Ch/O1CGZjDKqRGUadbWesF/vzJAryRw4UjKfULDxoULOUfxkXw5xUQbVg24Wo7hk7/asSjUxBfA6tWi29bSBP45ukSwwB1vUmdq5iWG/tfLX6E3csxAb81AgMBAAGjggLwMIIC7DAfBgNVHSMEGDAWgBQpXkvVRky7/hanY8EdxCby3djzBTAOBgNVHQ8BAf8EBAMCBeAwaQYDVR0gBGIwYDBeBgZgTAECATMwVDBSBggrBgEFBQcCARZGaHR0cDovL3JlcG9zaXRvcmlvLmFjc2FmZXdlYi5jb20uYnIvYWMtc2FmZXdlYnJmYi9kcGMtYWNzYWZld2VicmZiLnBkZjCBrgYDVR0fBIGmMIGjME+gTaBLhklodHRwOi8vcmVwb3NpdG9yaW8uYWNzYWZld2ViLmNvbS5ici9hYy1zYWZld2VicmZiL2xjci1hYy1zYWZld2VicmZidjUuY3JsMFCgTqBMhkpodHRwOi8vcmVwb3NpdG9yaW8yLmFjc2FmZXdlYi5jb20uYnIvYWMtc2FmZXdlYnJmYi9sY3ItYWMtc2FmZXdlYnJmYnY1LmNybDCBtwYIKwYBBQUHAQEEgaowgacwUQYIKwYBBQUHMAKGRWh0dHA6Ly9yZXBvc2l0b3Jpby5hY3NhZmV3ZWIuY29tLmJyL2FjLXNhZmV3ZWJyZmIvYWMtc2FmZXdlYnJmYnY1LnA3YjBSBggrBgEFBQcwAoZGaHR0cDovL3JlcG9zaXRvcmlvMi5hY3NhZmV3ZWIuY29tLmJyL2FjLXNhZmV3ZWJyZmIvYWMtc2FmZXdlYnJmYnY1LnA3YjCBuAYDVR0RBIGwMIGtgRhJWkFCRUxCRVJUT05ASE9UTUFJTC5DT02gIwYFYEwBAwKgGhMYSVpBQkVMIENBU1NFUkxFWSBNQVJUSU5ToBkGBWBMAQMDoBATDjEwOTAzMDQ3MDAwMTE5oDgGBWBMAQMEoC8TLTIwMDUxOTc0MDAwMDM3MDM5ODMwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDB6AOEwwwMDAwMDAwMDAwMDAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwDQYJKoZIhvcNAQELBQADggIBADP8cY9EHtHC4euqE2oFSjlQzEcrI+Tg8oN3Xpq3OeZARoX9y+9tvXLD3+18XNKuHRstkUkfTWQ4eUYSvpGZk/QP4aLOCDz1OAn4HupEqv0yDTXIanO7MnaJDUrxS0eD+jdu6H7nLJdpNqjxW+zC1TjVr+KR/A7lDBbPXbRqS+mSD9VhnrgbRRzhqIjgV2UPNLaXeIiDPLGovYJu7lZs5pEn8yMM+sxn5efHR5PT4BDYThuirfhzL21i32AJV67zvJxA5mc7hi1z+XjzQG0ZPiCzjRrMWFKmxHK5uR9REnC62IoqnWygBmEeSkeH3ONMyqxYDmKCF5hHISZVVg+qyWoDfucBBGWlacRdQPzuEKXXMREpnXSSleRUYTNObMOJnmY+e9HJKFKS88dOZuzK1/kG3rS6In7APZAoVlRT9kcKo5LX5tcNeIXXLamBwocfDlnHFBFz6nqXFWudeCoABrmfrVXOmxTmF9ynYH4NcYYQm5a12jIoQ/+cJ4r4FMQdTARnGNIdzmD+Awc3InA6qkqKItDeonbTpCQG1g6FBA2tbpDaExsv2hfRwGVDBtOrEWzhTUk6kQeWlr0o+OdAX8bZ6utdZY6LXdI0RlZYk/KpGJhXUMWmJgoA58BeSIrNO++p/HkGa5xwsvXYiKllH5CuSsyIYERnggxSFGg4xfoJ</X509Certificate> </X509Data> </KeyInfo> </Signature> </MDFe> </enviMDFe>

Olá pessoal! Quando falamos de um Manifesto Eletrônico de Documentos Fiscais (MDF-e), uma dúvida recorrente que pode vir a surgir é a correta maneira de utilizar o evento de encerramento. O que diz o Manual? O Manual de Orientação do Contribuinte Visão Geral, traz a seguinte definição para o evento de encerramento: O que isso quer dizer? Na prática, isso quer dizer que quando terminado o trajeto e também toda vez que houver alteração de carga é necessário encerrar o MDF-e vigente e emitir um novo. Pode dar um exemplo? Vamos considerar como exemplo hipotético uma caminhão que saia de MT para entregar parte de sua carga em SP e o restante em MG. Neste cenário devemos: Emitir um MDF-e com carregamento em MT e descarregamento em SP (aqui toda a carga deve ser incluída) Emitir um segundo MDF-e com carregamento em MT e descarregamento em MG (só com a carga que vai para MG). Os 2 MDF-e podem ser emitidos um em seguida do outro antes mesmo de o caminhão partir de SP. Quando o motorista avisar que toda a carga referente a SP foi entregue, a empresa que esta em MT encerra o primeiro MDF-e. Quando ele avisar que o resto da carga destinada a MG foi entregue, a empresa encerra o segundo MDF-e. Vamos considerar outro exemplo em que um caminhão parte de SP ao RJ com um carga, mas no meio do trajeto, ocorre a quebra do veículo de tração ou de reboque e o mesmo precisa ser trocado. Neste exemplo, o MDF-e emitido originalmente deve ser encerrado e um novo MDF-e com a informação do novo veículo deve ser emitido. Por fim, em um cenário em que um caminhão parte de SP com destino a MG, quando chegar em seu destino e a carga for entregue o MDF-e correspondente deverá ser encerrado. Observações Importantes: Um MDF-e encerrado não pode ser cancelado. Um MDF-e só pode ser cancelado se o caminhão não saiu da empresa para realiza o transporte da carga. Todo MDF-e tem que ser encerrados (exceto os cancelados) quando a carga é descarregada ou quando ocorre alteração conforme já apresentado acima. Dica aos desenvolvedores: Ao treinar o usuário a usar a aplicação de emissão de MDF-e deixe bem claro o conceito de MDF-e Cancelado e MDF-e Encerrado.

Bom dia a todos, alguem poderia me tirar esta dúvida fazendo um favor, Na resolução diz: "3. Suspender, até ulterior Deliberação da ANTT, as obrigações e penalidades relacionadas ao cadastramento da Operação de Transporte, com a consequente geração do CIOT, para as contratações que não envolverem TAC e TAC-Equiparado." 1) Tenho Clientes que utilizam TAC, então nesse caso é obrigatório gerar o ciot pelo E-Frete? 2) Se sim, então o prazo para validar o ciot em produção será apartir de 31/07/2020 ou quando será? 3) Por enquanto somente quando tipo de transportador for ETC e CTC esta suspenso ate nova ordem? Desde já agradeço a quem puder me ajudar com essas duvidas.

Boa tarde pessoal. Ainda não sei o campo correto onde criar tópicos para isto, peço desculpas. Minha dúvida é a seguinte, surgiu um de meus clientes que utilizam o ERP para emissão de NF-e, NFC-e e manifestos... Realizando o MDF-e, cliente me informou que utiliza nosso sistema para emitir os manifestos do mesmo veiculo/placa realizando diversas coletas e criando novos MDF-e mesmo sem mudar a placa do veiculo. Exemplo, (DEVOLUÇÃO EMITIDA PELO FORNECEDOR) irei buscar com meu (CAMINHÃO). Porém nesta busca vou passar por algumas UF's onde também vou buscar mercadorias e realizei manifestos diferentes e no segundo houve esta rejeição. 286->611-Rejeição: Existe MDF-e não encerrado para esta placa, tipo de emitente e UF descarregamento. (Porém visualizei que meu cliente já emitiu MDF-e com os mesmos estados, acrescentando apenas um a mais e autorizou). Algo mudou na legislação? O que devo proceder?

Olá, quando as novas regras estiverem funcionando em julho como devo proceder com relação ao CIOT integrado ao MDF-e. Eu devo digitar algum número para o CIOT ou deixar vazio. Se devo digitar um número serão quantos caracteres? Pois lembro que não aceitava a quantidade de caracteres de um CIOT já aprovado. Estou com dúvida nesse tópico.

boa tarde pessoal, tudo bem? Ao tentar gerar o evento evPagtoOperMDFe do MDF-e está ocorrendo uma rejeição: 630 - Rejeição: Falha no Schema XML específico para o evento. Em anexo está o xml incMDFe42190901724075000188580050000016901006518830.xml Saberiam me dizer o que tem de errado?

Bom dia grupo. Gostaria de saber se alguém esta conseguindo enviar para SEFAZ-RS em ambiente de homologação um MDF-e que tenha o produto predominante. Toda vez que tento enviar direto pra SEFAZ-RS retorna falha de schema. Obrigada pela ajuda.

Alguém esta conseguindo validar um MDF-e com o grupo prodPred? Estou tendo o problema abaixo ao passar o arquivo no validador do site dfe (https://dfe-portal.svrs.rs.gov.br/Mdfe/ValidadorXML The element 'infMDFe' in namespace 'http://www.portalfiscal.inf.br/mdfe' has invalid child element 'prodPred' in namespace 'http://www.portalfiscal.inf.br/mdfe'. List of possible elements expected: 'seg, tot' in namespace 'http://www.portalfiscal.inf.br/mdfe'. Em anexo o xml gerado. 33200303282458000179580750000005011692612317-mdfe.xml

Como todos sabem o emissor gratuito de MDF-e parou de ser atualizado e também seu suporte encerrou. Por isso estou disponibilizando a venda de um emissor pronto onde você já pode disponibilizar a seus clientes. usando o mais simples do Delphi e o FrameWork ACBr com banco Firebird. 100% funcional Como faz para adquirir? Basta clicar no link abaixo e efetuar a compra. após o pagamento ser processado você irá receber no seu e-mail o acesso aos fontes . COMPRAR http://juliomarmarchetti.com.br/blog/2018/10/03/mdf-e-fontes-para-venda/

Boa tarde pessoal. Preciso de ajuda, urgente! Hoje meu cliente foi enviar um MDF-e que retornou a seguinte rejeição: 'Data de emissao MDF-e posterior a data de recebimento'. Notei que o ACBR está montando o XML com o ano de 2020, mesmo a data estando correta no MDF-e, exemplo: 51201213461776000150580010000000011000000051 Se eu mudo a data de emissão para 28/12/2019, ele monta a chave de acesso corretamente no ano de 2019, exemplo: 51191213461776000150580010000000011000000050. Alguém sabe como pode ser resolvido? Testei em várias versões até na 1.3.0.171, e todas acontecem o mesmo.

boa tarde, estava fazendo o mdf-e usando gerar txt e a versao 1...4 e agora baixei a versao 1..62 acrescentei os campos q foram pedidos mas ta dando erro no qr cod, como faco pra informar ao monitor essa opcao? grato e aguardo jerry

Boa tarde, estou tentando emitir o evento de Inclusão de Condutor do MDF-e, porem não esta sendo possível pois estou recebendo uma rejeição referente ao tamanho máximo da tag descEvento, que segundo o manual é de 12 caracteres, porem no próprio manual é dito que a descrição a ser enviada é ‘Inclusão Condutor’, porem a mesma possui 17 caracteres impossibilitando o envio do evento. Dentro do evento TEventoMDFe.GerarXML: Boolean; realizei a seguinte alteração: Gerador.wCampo(tcStr, 'EP02', 'descEvento', 05, 12, 1, Evento.Items[0].InfEvento.DescEvento); Por Gerador.wCampo(tcStr, 'EP02', 'descEvento', 05, 17, 1, Evento.Items[0].InfEvento.DescEvento); Troquei o tamanho máximo de 12 para 17 dessa forma consegui emitir o evento, gostaria de saber se existe algum problema em fazer isso ou se existe uma outra forma de corrigir o problema.

"Rejeição: CNPJ / CPF do proprietário do veículo reboque inválido:" Esta programado para entrar hoje a validação abaixo: Se modal Rodoviário e informado grupo do proprietário do veículo reboque (grupo:veicReboque/prop):Rejeitar se o CPF ou CNPJ informado para o proprietário estiver inválido (dígito de controle, zeros) observação: Verificar em todos os reboques informados* Porém verifiquei o CNPJ e esta tudo certo. CNPJ, RNTRC e PLACA tudo de acordo. Alguém mais esta sofrendo com isso?

Olá Estou implementando a consulta do MDF-e através da chaveMDF-e, no entanto percebi um inconsistência nos dados retornado quando o MDF-e está cancelado, caso o MDF-e esteja autorizado ou encerrado o retorno esta correto, mas quando esta cancelado está havendo inconsistência, segue abaixo exemplificação do problema: Estou pegado os dados da seguinte forma: // DADOS DE AUTORIZAÇÃO DE ENVIO DO MDFE // Aqui é que está o problema, pois quando a consulta é de um MDF-e autorizado ou encerrado, os dados retornando é da Autorização, porem se a consulta é de uma MDF-e cancelado o retorno é do evento de cancelamento e não da autorização de envio Protocolo := ACBrMDFe.WebServices.Consulta.Protocolo; DtAutorizacao := ACBrMDFe.WebServices.Consulta.DhRecbto; // DADOS DE AUTORIZAÇÃO DO EVENTO DO MDFE QUE PODE SER DE ENCERRAMENTO OU CANCELAMENTO DEPENDO DO STATUS // Aqui retorna perfeitamente tanto para MDF-e encerrado quanto para cancelado ProtocoloEvento := ACBrMDFe.WebServices.Consulta.procEventoMDFe.Items[0].RetEventoMDFe.retEvento.Items[0].RetInfEvento.nProt; DtAutorizacaoEvento := ACBrMDFe.WebServices.Consulta.procEventoMDFe.Items[0].RetEventoMDFe.retEvento.Items[0].RetInfEvento.dhRegEvento;Cancelado) Justificativa := ACBrMDFe.WebServices.Consulta.procEventoMDFe.Items[0].RetEventoMDFe.InfEvento.DetEvento.xJust; // Acredito que ficaria mais legível se as propriedades básicas do retorno do evento fossem encapsulados diretamente na consulta, por exemplo "ACBrMDFe.WebServices.Consulta.RetEvento.nProt", caso seja necessário pegar outras informações do evento poderia ser feito por "ACBrMDFe.WebServices.Consulta.DetEvento", porem é só uma sugestão