Pesquisar na Comunidade

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.

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

Precisei emitir uma MDFe com dados do Seguro, porem apesar dos dados constarem no XML, notei que não estavam sendo apresentados na impressão do DAMDFe. Referência: https://svn.code.sf.net/p/acbr/code/trunk2/Exemplos/ACBrDFe/ACBrMDFe/Delphi/Report/DAMDFe_Retrato.fr3 Fiz os ajustes baseado na estrutura já utilizada: Adicionado conjunto de dados: Seg Adicionado novo SubReport "SBSeg" em "SBModalRodoviario" Alinhamento / Posicionamento dos componentes Textos utilizando mesma Fonte (Nome, tipo e tamanho) Uso de MasterData para considerar múltiplos seguros Segue em anexo arquivo de impressão fastreport alterado para contribuição e atualização dos fontes: DAMDFe_Retrato-ComDadosDoSeguro.zip

Enviei um MDFe para a Sefaz e não consigo encerrá-lo. Ao tentar recebo a seguinte rejeição: TfrmMDFe.ActionEncerrarExecute -> Não existe MDFe com a chave [2626031117258400107580010000028871000026773] carregado. O problema é que consigo consultá-lo na SEFAZ, fiz o download através do portal, inclusive, no portal ele aparece como não encerrado e apesar disso, não consigo encerrá-lo.

Ao enviar o xml do MDFe para a SEFAZ, recebo a rejeição: erro na preparação de relatório. Submeti o XML ao validador da SEFAZ e recebi a seguinte mensagem: PARSER XML: OK TIPO DE MENSAGEM: Tipo de Schema não tratado: procNFe Como resolver.

Olá comunidade ! Foi publicada a Resolução ANTT nº 6.078/2026, que altera a Resolução ANTT nº 5.862/2019, responsável por regulamentar o cadastro da Operação de Transporte necessário para a geração do Código Identificador da Operação de Transporte (CIOT). Com essa publicação, a partir de 24/05/2026, passa a ser obrigatória a geração e vinculação do CIOT ao MDF-e em todas as operações de transporte, exceto quando o valor do frete estiver em desacordo com o piso mínimo aplicável. Detalhando melhor, a nova norma é composta por quatro artigos, trazendo alterações de redação, revogações e definição de datas de vigência. Entre os pontos mais relevantes, destaca-se a nova redação incluída pelo Art. 1º, que estabelece: Outras disposições Art. 2º: estabelece valores de multas para determinadas infrações. Art. 3º: revoga o § 1º do art. 5º e o art. 8º da Resolução ANTT nº 5.862/2019. Art. 4º: define que a resolução entra em vigor em 24/05/2026.

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:

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:

Contexto Esta rejeição foi adicionada pela Nota Técnica 2025/001 e obriga o preenchimento das informações de pagamento no MDFe quando for realizado carga de lotação. O que é carga lotação? Carga lotação, as vezes chamada de carga fechada, é a operação em que o transporte das mercadorias de um único remetente ocupa toda a capacidade do veículo. Resolução Se você estiver recebendo esta rejeição ao tentar emitir o MDFe, você deve gerar o grupo InfPag que possui as informações de pagamento em seu arquivo XML. Caso utilize componente nativo para Delphi/Lazarus: uses ACBrMDFe.Classes; var lMDFe: TMDFe; lInfPag: TinfPagCollectionItem; lComp: TCompCollectionItem; lInfPrazo: TInfPrazoCollectionItem; begin lMDFe := ACBrMDFe.Manifestos.Add; //Preenchimento das demais informações do MDFe. lInfPag := lMDFe.rodo.infANTT.infPag.New; lInfPag.xNome := //String; lInfPag.idEstrangeiro := //String; lInfPag.CNPJCPF := //String; lInfPag.vContrato := //Double; lInfPag.indAltoDesemp := //TIndicador = (tiSim, tiNao); lInfPag.indPag := //TIndPag = (ipVista, ipPrazo); lInfPag.vAdiant := //Double; lInfPag.indAntecipaAdiant := //TIndicador = (tiSim, tiNao); lInfPag.tpAntecip := // TtpAntecip = (taNenhum, taNaoPermiteAntecipar, taPermiteAntecipar, taPermiteAnteciparComConfirmacao); lInfPag.InfBanc.codBanco := //String; lInfPag.InfBanc.codAgencia := //String; lInfPag.InfBanc.CNPJIPEF := //String; lInfPag.InfBanc.PIX := //String; lComp := lInfPag.Comp.New; lComp.tpComp := //TComp = (tcValePedagio, tcImpostos, tcDespesas, tcFrete, tcOutros); lComp.vComp := //Double; lComp.xComp := //String; lInfPrazo := lInfPag.infPrazo.New; lInfPrazo.nParcela := //Integer; lInfPrazo.dVenc := //TDateTime; lInfPrazo.vParcela := //Double; end; Caso utilize ACBrMonitorPLUS ou ACBrLib: [infPag001] CNPJCPF= xNome= idEstrangeiro= vContrato= indAltoDesemp= indPag= vAdiant= indAntecipaAdiant= tpAntecip= [Comp001001] tpComp= vComp= xComp= [infPrazo001001] nParcela= dVenc= vParcela= [infBanc001] CNPJIPEF= codBanco= codAgencia=

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á, estou emitindo MDFe, e retorna o seguinte erro "699: Rejeição: Dados do seguro de carga incompletos para o modal rodoviario", porém todos os campos da seguradora estão valorizados, segue o xml para analise. 41250553034459000172580010000000171088569094-mdfe.xml

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.

Olá a todos. Estou tentando imprimir eventos do MDFe, uso o mesmo padrão tanto no NFe, NFCe, CTe e todos funcionam porém ao tentar com o MDFe ele retorna vazio com mensagem de "cancelamento" mesmo sendo um evento de encerramento. Se eu uso o método auxM.EventoMDFe.LerXML funciona perfeitamente, mas se uso o auxM.EventoMDFe.LerXMLFromString não funciona. Acabei de zerar o ACBr e o Lazarus do me PC e continua da mesma forma, estou desde sedo procurando nos tópicos e não achei nada que resolvesse. var auxXML: string; auxM: TACBrMDFe; auxI: TACBrMDFeDAMDFeRL; begin DataModulo.OpenSQL('SELECT XML FROM MDF_EVENTOS WHERE ID = 1); auxXML := DataModulo.Query.FieldByName('XML').AsString; try auxM := TACBrMDFe.Create(nil); auxM.EventoMDFe.LerXMLFromString(auxXML); try auxI := TACBrMDFeDAMDFeRL.Create(nil); auxM.DAMDFE := auxI; auxM.ImprimirEvento; finally FreeAndNil(auxI); end; finally FreeAndNil(auxM); end; end;

Olá pessoal, Estamos de volta para informar que as prateleiras de programas de exemplo do ACBr ganharam mais itens, pois foram disponibilizados na Rev-35855 os programas de exemplo em PHP, Singlethread e Multithread utilizando a ACBrLibMDFe. ..\ACBr\Projetos\ACBrLib\Demos\PHP\MDFe\ACBrMDFeDemoST.php ..\ACBr\Projetos\ACBrLib\Demos\PHP\MDFe\ACBrMDFeDemoMT.php Vale lembrar que os programas de exemploem php utilizam a ACBrComum.php que contém métodos em comum entre os modos (ST e MT) e para todas as libs. ..\ACBr\Projetos\ACBrLib\Demos\PHP\ACBrComum\ACBrComum.php Baixem as atualizações do SVN e aproveitem a novidade. Até mais!!!

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.

ACBrLibMDFe Visulizar Arquivo ACBrLibMDFe - BIblioteca para emissão e impressão de Manifesto de Documentos Fiscais Eletrônicos Faça Download pelo SVN, dos Demos de uso da ACBrLibMDFe em diversas linguagens, usando o endereço: http://svn.code.sf.net/p/acbr/code/trunk2/Projetos/ACBrLib/Demos/ Manual On-Line: https://acbr.sourceforge.io/ACBrLib/ACBrLib.html Autor Daniel Simoes Enviado 18-11-2019 Categoria ACBrLib - PRO  

Ao realizar o envio de um MDFe em ambiente de homologação, está retornando erro interno. Alguém está passando por esse problema também? Retorno: Erro Interno: 12007 Erro HTTP: 0 URL: https: //mdfe-homologacao.svrs.rs.gov.br/ws/mdfeconsulta/MDFeConsulta.asmx Erro: 12007 - O nome do servidor não pode ser resolvido Qualquer url disponibilizada no https://dfe-portal.svrs.rs.gov.br/Mdfe/Servicos#SEFAZ Virtual Rio Grande do Sul (SVRS)-Homologação, não consigo acesso.

Nos últimos dias muitos usuários estão com problemas na emissão das Nfe e NFCe. Não sabe o que está acontecendo? Se quiser saber mais, veja esse tópico de notícias e todos os posts dele. Por causa desses problemas, os servidores de contingência foram ativados pela SEFAZ. Como resolver? Primeiramente precisamos entender que a forma de emissão que é de acordo com os modelos: NFe (Modelo 55) a forma de emissão deve ser contingência: Basicamente alterar 2 propriedades: (Componente: FormaEmissao e na Alimentação da Nfe: tpEmis ), para uma explicação mais detalhada Clique Aqui. NFCe (Modelo 65) a forma de emissão deve ser OFF-LINE e depois ser transmitida, conforme MOC, página 05: Se você é membro ACBr PRO, você tem acesso aos cursos disponibilizados pelo ACBr. Um deles é o Implementando a Contingência Offline da NFCe. Nesse curso tem não só a explicação em detalhes do processo, mas até um código fonte para tornar seu aplicativo apto para fazer a contingência da NFCe automaticamente. MDFe(Manifesto Eletrônico de Documentos Fiscais, modelo 58) a forma de emissão deve ser OFF-LINE e depois ser transmitida quando cessar o problema, conforme MOC, página 79 e Cartilha MDFe Nacional, página 17: Veja no tópico "Como emitir um MDF-e em contingência" orientações de como alterar no componente MDFe para fazer gerar o XML corretamente. Onde obter mais informações? Para mais informações sobre a situação, acompanhe nossa área de notícias: https://www.projetoacbr.com.br/forum/forum/35-notícias-do-acbr/

Olá pessoal. Estamos no AM nossa empresa é de software enão temos Insc estadual. Acontece que pra emissão de teste homologação pra NF-e usamos Isento, pra NFC-e usamos 99999990 e ambas passam. Pra MDFe fui testar e nenhuma funciona pois sefaz retorna que precisamos IE quando ponho isento, ou que ie de teste (99999990 ) ai não casa com CNPJ da empresa. Ligue pra lá mas eles nem entendem pelo jeito e disseram pra usar usar Certificado do cliente, absurdo isso pra mim. Como é no estado de vocês tem algum tipo de saída? Grato desde já friends. Ivanilson Ribeiro Delphi Developer

Olá. Na Nota Técnica 2023.002, altera o retorno do WebService de Consulta Situação para MDFe que passa a vir no retorno o grupo procInfraSA. Estou com duvida no que fazer com esse retorno. Devo começar a exibir ele quando usuário consultar o MDFe? Ou é usado para outras funcionalidades onde devo persistir esses valores? OBS.: Atualmente o nosso sistema gera e transmite o MDFe. Desde já agradeço.

Boa tarde. Pessoal já tenho o MDFe desenvolvido e funcionando a algum tempo, a partir do componente do ACBr... porém hoje em um determinado cliente deu a seguinte rejeição ao transmitir um MDFe 606 - Rejeição: Segundo Código de Barras deve ser informado para NF-e em contingência seguido desta mensagem ele da uma das chaves das NFes anexadas ao MDFe, quando consulto essa chave, na receita ta normal, autorizada em ambiente normal... não compreendi por que da mensagem de contingência.

Olá, a logo da DACTE e DAMDFE não esta aparecendo. Estou informando a imagem seguindo os exemplos do acbr sobre o CTe e MDFe, segue abaixo: // MDFE ACBrMDFe1.DAMDFe.Logo := sDir + logoJPG; // CTE ACBrCTe1.DACTE.Logo := sDir + logoJPG; Como tambem, tentei informar a logo pelo componente dacte, como possui um campo chamado logo, resolvi testar (apenas no caso do CTe):ACBrCTeDACTEFR.Logo := sDir + logoJPG; Para NF-e, consegui homologar as imagens JPG de 100x100 ate 600x600 seguindo esse exemplo (ACBrCTe1.DACTE.Logo := sDir + logoJPG;) Alguma informação de como proceder nesse caso? Algo esta faltando?