Painel de líderes

@leomcl Creio que o ideal seria aguardar os schemas atualizados, pois devem estar aptos aos cnpjs alfanuméricos. Vi que disponibilizaram dia 10/07, vou fazer um teste aqui. Att.

DANFe Simplificado Tipo 2: Sefaz publica as Notas Técnicas 2026/002 e 2026/003 e muda a impressão de NF-e e NFC-e A Sefaz definiu o leiaute e as regras operacionais do novo DANFe Simplificado Tipo 2. Entenda o que muda, os prazos de implantação e por que o mercado ainda precisa ficar atento antes de sair adequando os sistemas. Atenção! Aqui vale um alerta importante: embora o desenvolvimento esteja avançando, há diversos relatos na comunidade de que os ambientes da Sefaz ainda não estão aceitando de forma consistente o novo modelo de impressão para emissão de notas fiscais. Isso é comum em mudanças de leiaute recém-publicadas — a homologação e o comportamento do ambiente de produção das Secretarias de Fazenda estaduais costumam levar um tempo para acompanhar a própria nota técnica. Na prática, isso significa que testar o novo layout agora não substitui o acompanhamento contínuo do assunto até que a aceitação esteja de fato estabilizada. Resumo rápido A Nota Técnica 2026/003 v1.00 define o leiaute técnico e operacional do DANFe Simplificado Tipo 2, instituído pelo Ajuste SINIEF nº 13, de 6 de abril de 2026. A Nota Técnica 2026/002 v1.00 trata das regras de uso desse novo DANFe em operações presenciais e não presenciais, atendendo aos Ajustes SINIEF nº 32/25 e nº 13/26. O novo documento passa a cobrir com NF-e operações que hoje tipicamente usam NFC-e — mas o XML continua sendo o documento fiscal válido; o DANFe é só a representação impressa. Implantação em teste a partir de 01/07/2026 e em produção a partir de 03/08/2026 para a maior parte das mudanças (algumas regras têm cronograma próprio — veja a tabela abaixo). A implementação nas soluções ACBr já está em andamento, mas relatos da comunidade indicam que o ambiente da Sefaz ainda não está aceitando de forma consistente o novo modelo de impressão — ou seja, calma antes de sair trocando tudo em produção. O que é o DANFe Simplificado Tipo 2? O DANFe Simplificado Tipo 2 é um novo documento fiscal auxiliar, criado para padronizar a emissão de NF-e em operações que normalmente seriam cobertas por NFC-e. Assim como os demais modelos de DANFe já conhecidos pelo mercado, ele segue algumas regras básicas: É apenas a representação simplificada da operação — o XML continua sendo o documento fiscal de fato. A impressão é feita pelo próprio sistema do contribuinte, em impressora comum (não fiscal), com base nos dados do XML. Ele não pode conter nenhuma informação que não esteja no XML da NF-e correspondente. O leiaute definido pela NT 2026/003 organiza o documento em blocos que vão desde o cabeçalho e os itens da nota até a consulta por chave de acesso ou QR Code, informações do consumidor, dados de autorização e as novas informações de IBS/CBS, além do aviso exigido pela Lei Federal nº 12.741/2012 (a "lei da transparência fiscal"). O que muda na prática com a NT 2026/002 Enquanto a NT 2026/003 cuida do layout, a NT 2026/002 regulamenta como e quando esse novo DANFe pode ser usado. Os principais pontos: Alerta em vez de rejeição: é criado o novo cStat 120 – "Autorizado o uso da NF-e com alerta". Ele permite que a Sefaz autorize o documento mesmo diante de alguma inconsistência, sinalizando o problema em vez de simplesmente rejeitar a nota. Por enquanto, esse cStat vale só para NFC-e. Alerta de CNPJ irregular: passa a haver um aviso na emissão de NFC-e quando o destinatário for identificado por CNPJ em situação irregular. Vedação de referência cruzada: NF-e de saída não pode mais referenciar NFC-e ou CF-e, exceto quando se tratar de NF-e complementar. Contingência off-line regulamentada para a NF-e emitida com DANFe Simplificado Tipo 2. Regras que hoje valem só para a NFC-e (modelo 65) passam a valer também para a NF-e (modelo 55) — por exemplo, verificação de data de entrada/saída, tipo de operação e se a operação é interestadual ou com o exterior. O limite de R$ 10.000,00 para emissão de NFC-e sem identificação do destinatário continua valendo por padrão, mas a Sefaz vai publicar uma tabela com valores específicos por UF. No campo técnico, a NT também altera valores de campos já conhecidos do leiaute: o tpImp ganha o valor 6 (DANFe Simplificado Tipo 2), o indPres tem a descrição do valor 4 ajustada, e o tpEmis tem a descrição do valor 9 atualizada para contemplar a contingência off-line desse novo modelo. Cronograma de implantação Mudança Teste Produção Leiaute do DANFe Simplificado Tipo 2 (NT 2026/003) 01/07/2026 03/08/2026 Regra de emissão de NFC-e sem identificação do destinatário 01/06/2026 15/06/2026 Regras de validação para NF-e e rejeição de referência aos modelos 65/59 01/07/2026 03/08/2026 Estrutura de autorização com alertas e demais regras de validação 01/09/2026 05/10/2026 Vale reparar que as datas não são únicas: a mudança chega em ondas, o que dá algum fôlego para adequação — mas também exige atenção redobrada, já que cada regra entra em vigor em um momento diferente. O ACBr já está pronto? E a Sefaz? Do lado do desenvolvimento, o novo leiaute já está sendo trabalhado nas soluções ACBr — a NT 2026/003 está sendo acompanhada internamente pela tarefa ACBR-9424, e as mudanças da NT 2026/002 pela tarefa ACBR-9423. Quem utiliza os componentes de NF-e e NFC-e do ACBr deve acompanhar essas atualizações, já que a implementação do DANFe Simplificado Tipo 2 tende a chegar como parte natural da evolução desses componentes. Como se preparar Acompanhe os tópicos oficiais da NT 2026/002 e da NT 2026/003 no fórum do ACBr para novidades sobre a implementação. Não migre sistemas para produção com o novo layout sem antes validar o comportamento no ambiente de testes da Sefaz do seu estado. Fique atento às datas de cada regra — a rejeição de NF-e referenciando modelos 65/59 e as novas regras de validação chegam em momentos diferentes do leiaute do DANFe em si. Se seu sistema opera perto do limite de R$ 10.000,00 para NFC-e sem identificação do destinatário, monitore a publicação da tabela de valores por UF. Revise processos de contingência off-line, já que a NT 2026/002 regulamenta especificamente esse cenário para o novo modelo. Fonte oficial Informações baseadas nas publicações da comunidade do Projeto ACBr no fórum "Notícias do ACBr": Nota Técnica 2026/003 v1.00 — DANFe Simplificado Tipo 2 (Ajuste SINIEF nº 13/2026): Publicada NT que define leiaute do DANFe Simplificado Tipo 2 Nota Técnica 2026/002 v1.00 — Operações presenciais e não presenciais com DANFe Simplificado Tipo 2 (Ajustes SINIEF nº 32/25 e nº 13/26): Publicada Nota Técnica que cria NF-e "sabor" NFC-e Quer se antecipar a essas mudanças fiscais? Ficar por dentro de cada nota técnica é só o primeiro passo — o desafio real é manter seu sistema emissor sempre atualizado sem virar um projeto interminável. Conheça o ACBr PRO e simplifique a adequação da emissão de NF-e, NFC-e e dos demais documentos fiscais eletrônicos do seu sistema.

NFS-e Via: nova API permite consultar alíquotas de ISS por trecho e data A Secretaria-Executiva do Comitê Gestor da NFS-e ampliou as ferramentas de transparência do sistema NFS-e Via. Entenda o que muda para as Administrações Tributárias Municipais e onde a comunidade pode ajudar a levar essa novidade também para o ecossistema ACBr. Resumo da novidade: Foi publicada a versão 1.1 do Anexo V – Guia para Utilização das APIs, destinada às Administrações Tributárias Municipais do sistema NFS-e Via; A principal novidade é a API de consulta de alíquotas de ISS por trecho e data; Os municípios passam a acessar o histórico e a vigência das alíquotas aplicadas em trechos de concessões rodoviárias; A resposta traz percentual de participação de cada município, alíquota base, alíquota efetiva municipal e alíquota efetiva total do trecho; O objetivo declarado é aumentar a transparência e facilitar a validação do rateio do ISSQN entre os entes federados; A documentação técnica e os ambientes de teste já estão disponíveis para integração. O que mudou na NFS-e Via O NFS-e Via é a frente do sistema nacional da Nota Fiscal de Serviço eletrônica voltada às concessionárias de exploração de vias — o modelo usado para emitir a nota fiscal referente à cobrança de pedágio. Como o trecho de uma concessão costuma atravessar mais de um município, o ISS arrecadado precisa ser rateado entre eles, de acordo com a extensão da rodovia em cada território e a alíquota vigente em cada localidade. Até então, o Anexo V – Guia para Utilização das APIs descrevia apenas o método ObterDocumentos, usado pelos municípios para baixar os XMLs de NFS-e Via e de eventos de cancelamento por NSU, além da consulta de alíquotas por município. Com a versão 1.1, publicada em julho de 2026, o guia passa a contemplar também a consulta de alíquotas por trecho em uma data específica. Como funciona a nova consulta de alíquotas O novo endpoint, GetAliquotasTrecho, é acessado via GET /Aliquotas/trecho/{codigoTrecho}/dataReferencia/{dataReferencia} e retorna, para um trecho e uma data de referência informados, a lista completa de municípios envolvidos no rateio, com: extensão do trecho em cada município e o percentual correspondente; alíquota de ISS informada e a alíquota efetiva aplicada por município; a alíquota efetiva total do trecho, já consolidada. Essa informação se soma à consulta já existente por município (GetAliquotasMunicipioPorTrecho), que lista todos os trechos associados a um determinado código de município. Na prática, o município passa a poder conferir não só "quais trechos me afetam", mas também "qual era a alíquota vigente em uma data específica" — algo essencial para auditar cobranças passadas ou resolver divergências de repasse. Todas as comunicações continuam seguindo o padrão já estabelecido para o NFS-e Via: API REST síncrona, mensagens em JSON, documentos fiscais em XML 1.0/UTF-8, e autenticação mútua via certificado digital ICP-Brasil (TLS 1.0 a 1.2). Os ambientes de homologação, produção restrita e produção continuam disponíveis para testes de integração, com Swagger publicado para cada um deles. Por que isso importa para os municípios O rateio do ISS entre municípios cortados por uma mesma via é, por natureza, uma operação sensível: pequenas diferenças de alíquota ou de data de vigência mudam o valor final que cada prefeitura recebe. Ao expor essa informação via API — e não apenas em relatórios estáticos —, o Comitê Gestor da NFS-e permite que cada Administração Tributária Municipal audite o cálculo por conta própria, comparando o valor recebido com a alíquota que realmente estava vigente na data da cobrança do pedágio. Isso é particularmente relevante em disputas ou revisões de rateio: em vez de depender de uma consulta manual à concessionária, o município consulta diretamente o Ambiente Nacional da NFS-e Via e obtém o dado oficial. Onde ainda faltam ferramentas — um convite à comunidade Documentos fiscais eletrônicos como o NFS-e Via costumam ganhar, com o tempo, componentes prontos que facilitam a integração para quem desenvolve sistemas — é o caso de vários documentos já cobertos pelo ecossistema ACBr. Essa API específica de alíquotas do NFS-e Via, no entanto, ainda não tem um componente ACBr dedicado. A criação desse suporte está no roadmap do projeto, mas ainda sem previsão específica de entrega. É justamente aí que a comunidade pode fazer a diferença: quem já trabalha com integrações para concessionárias de vias ou tem interesse no tema pode contribuir com o desenvolvimento desse componente, ajudando a antecipar essa entrega para quem depende dela no dia a dia. Onde acessar a documentação A documentação técnica completa — incluindo os endpoints de obtenção de documentos e as duas consultas de alíquotas — está disponível no Anexo V – Guia para Utilização das APIs, com ambientes de homologação, produção restrita e produção liberados para testes de integração. Se você desenvolve integrações fiscais e quer ajudar a preencher essa lacuna no ecossistema ACBr — seja com o componente do NFS-e Via, seja com a consulta de alíquotas por trecho —, essa é uma boa oportunidade de contribuir com o projeto e com quem depende dele. Conheça as APIs do projeto ACBr e veja como participar do desenvolvimento junto com a comunidade. Fonte oficial: Secretaria-Executiva do Comitê Gestor da NFS-e — NFS-e Via: Publicada nova API para consulta de alíquotas do ISS, publicada em 10/07/2026.

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

pode me chamar no whatsapp 51985175256

Boa tarde Gostaria de solicitar a atualização do arquivo "PadraoNacional.GravarXml.pas", da pasta "\Fontes\ACBrDFe\ACBrNFSeX\Provedores", para o Trunk do projeto A mudança consiste em mover o bloco responsável pela escrita da tag "tpRetPisCofins", parte da hierarquia "NFSe/infNFSe/DPS/infDPS/valores/trib/tribFed/piscofins/" Para fora da condição "if not (NFSe.Servico.Valores.tribFed.CST in [cst00, cst08, cst09]) then", resultando em: Isso se deve em função de cenários específicos em que há PIS e COFINS retidos. Mais especificamente, são situações em que é preciso indicar o valor das retenções de PIS/COFINS/CSLL na tag "vRetCSLL" que como indicado na versão 1.03.00 do Anexo VI da NFSe, ele representa a soma das retenções de acordo com o indicado na tag "tpRetPisCofins". Por exemplo, quando utiliza-se o tipo "3 - PIS/COFINS/CSLL" retidos, torna-se necessário indicar a tag "tpRetPisCofins" com o valor "3" e o campo "CST" com o valor "00 - Nenhum" pois não há um valor de PIS e COFINS de apuração própria para ser usado o CST "01 - Operação Tributável com Alíquota Básica" e preenchidos os demais campos (vBCPisCofins, pAliqPis, pAliqCofins, vPis e vCofins) O entendimento de que os campos "vPis" e "vCofins" não devem ser usados em casos de retenção, vem do texto que faz parte da Nota Técnica SE/CGNFS-e nº 007 (https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica/rtc/nt-007-se-cgnfse-v1-0.pdf), transcrito abaixo e que indica claramente a distinção entre os valores de PIS e COFINS retidos e de apuração própria Então ao manter a geração da tag "pRetPisCofins" como parte da condição "if not (NFSe.Servico.Valores.tribFed.CST in [cst00, cst08, cst09]) then" isso impede que seja usada a retenção de PIS e COFINS com o CST "00 - Nenhum" para o PIS/COFINS Abaixo está a imagem do anexo VI da NFSe (versão 1.03.00 atualizado pela Nota Técnica SE/CGNFS-e nº 007) para facilitar a correlação com as tags que descrevi nos dois parágrafos acima Eu realizei essa alteração que descrevi e pude autorizar uma nota em ambiente de produção do serviço nacional, então posso confirmar que, no presente momento, ela é permitida. Em anexo está o arquivo fonte alterado a partir da revisão 47144, mas se preferir alterar manualmente, basta fazer a cópia da linha referente ao "tpRetPisCofins" que descrevi no começo do tópico PadraoNacional.GravarXml.pas

Boa tarde, Foi criada a tarefa ACBR-9637 para avaliação. Obrigada pela contribuição!

Muito obrigado @marcosvillatore... @Daniel InfoCotidiano, acho que você está com essa tarefa, correto ?

Bom dia, Eu não utilizo o AcbrMonitor, então inspeciono o retorno do provedor. Se a tag <DescricaoProcesso> presente no XML de retorno (prop <acbrNfseX>.WebService.Emite.XmlRetorno) contém "Requisicao finalizada. Favor aguardar o retorno da Sefin/ADN para impressao da NFS-e: xxxx" presumo que foi autorizada. O provedor demanda alguns segundos (ou minutos) para integrar com o Ambiente Nacional, e somente uma consulta posterior para obter o XML completo, contendo número e chave da NFSe Nacional.

Tarefa ACBR-9423 concluída e no SVN.

Tarefa ACBR-9423 já no SVN.

Passo a passo para a integração Realize o pré-cadastrado no site Dev.eFrete. Após o preenchimento do e-mail, você vai receber um e-mail da eFrete que deve ser respondido com CNPJ da empresa e Nome fantasia do sistema, ERP ou TMS. Depois de enviar essas informações, você receberá as credências de acesso ao ambiente de homologação e os dados aceitos no ambiente. Obs: Devido ao aumento repentino no volume de integrações temos recebido relatos de que esse processo pode levar um tempo para ser concluído. Particularidades e dicas extras Operações com certificado x Login sem certificado Login sem certificado: Para qualquer operação sem o certificado digital no eFrete é preciso de um token de autenticação que é gerado ao realizar a operação de Login. A operação de Login é feita utilizando o hash, usuário, senha e não devem ser preenchidos os dados do certificado no componente, conforme exemplo: ACBrCIOT.Configuracoes.Certificados.ArquivoPFX := ''; ACBrCIOT.Configuracoes.Certificados.Senha := ''; ACBrCIOT.Configuracoes.Certificados.NumeroSerie := ''; // Atenção, desabilitar essa propriedade ACBrCIOT.SSL.UseCertificateHTTP := False; ACBrCIOT.Configuracoes.Geral.Usuario := 'usuario do eFrete'; ACBrCIOT.Configuracoes.Geral.Senha := 'senha do eFrete'; ACBrCIOT.Configuracoes.Geral.HashIntegrador := 'HashIntegrador do eFrete'; A operação de login irá gerar um token que deverá ser preenchido nas demais operações, conforme exemplo: with ACBrCIOT.Contratos.Add.CIOT do begin // Só é necessário se usar usuario e senha e não o certificado Integradora.Token := 'token recebido na operação de login'; end; Operações com certificado: Para as operações com o certificado digital no eFrete, o login não é necessário pois não será utilizado o token, bastando preencher os dados do certificado, conforme exemplo: // Não preencher o ArquivoPFX se preencher o NumeroSerie ACBrCIOT.Configuracoes.Certificados.ArquivoPFX := 'arquivo. pfx'; ACBrCIOT.Configuracoes.Certificados.Senha := 'senha do certificado'; // Não preencher o NumeroSerie se preencher o ArquivoPFX ACBrCIOT.Configuracoes.Certificados.NumeroSerie := 'número de série do certificado'; // Atenção, habilitar essa propriedade ACBrCIOT.SSL.UseCertificateHTTP := True; ACBrCIOT.Configuracoes.Geral.Usuario := ''; ACBrCIOT.Configuracoes.Geral.Senha := ''; ACBrCIOT.Configuracoes.Geral.HashIntegrador := ''; Campos de mesmo nome com valores diferentes Dada a relação com o MDF-e, alguns campos podem receber a mesma informação. É importante lembrar, no entanto, que cada documento tem seu próprio conjunto de valores aceitos. Um exemplo é o campo TipoRodado no eFrete e o campo tpRod no MDF-e. Ambos recebem a informação do tipo de rodado, mas cada documento aceita um conjunto de valores diferente: MDF-e: 01 - Truck; 02 - Toco; 03 - Cavalo Mecânico; 04 - VAN; 05 - Utilitário; 06 - Outros. eFrete: NaoAplicavel; Truck; Toco; Cavalo. Exemplo de preenchimento do tipo Rodado para o eFrete no ACBrCIOT: var lCIOT: TCIOT; begin lCIOT := ACBrCIOT.Contratos.Add.CIOT; lCIOT.Integradora.Operacao := opGravarVeiculo; //Valores válidos são trNaoAplicavel, trTruck, trToco, trCavalo lCIOT.GravarVeiculo.TipoRodado := trNaoAplicavel; //Demais informações... end; Valores e informações específicos para o ambiente de homologação O ambiente de homologação por padrão solicita o envio de um certificado digital, mas seu envio não é obrigatório. Em ambiente de homologação apenas os Integradores são cadastrados, informe seu próprio, CNPJ como MatrizCNPJ e como Contratante do Frete nas requisições relacionadas. Exemplo de preenchimento de MatrizCNPJ e Cnpj do contratente no ACBrCIOT para o eFrete: var lCIOT: TCIOT; begin lCIOT := ACBrCIOT.Contratos.Add.CIOT; lCIOT.Integradora.Operacao := opAdicionar; lCIOT.AdicionarOperacao.MatrizCNPJ := 'pseudoCNPJ'; lCIOT.AdicionarOperacao.Contratante.CpfOuCnpj := 'mesmopseudoCNPJ'; //Demais informações... end; Web Service Soap x API Rest A integradora eFrete disponibiliza tanto um web service SOAP que comunica com arquivos XMLs quanto uma API Rest que recebe arquivos JSON. O componente ACBrCIOT se comunica com o web service SOAP. Caso enfrente algum problema ou erro inesperado, é válido realizar um teste para a mesma operação na API Rest e conferir se o retorno diverge. Você pode utilizar uma ferramenta de IA para converter o XML gerado pelo componente no JSON correspondente e fazer o envio. Leia o manual do eFrete na integra AQUI.