Painel de líderes

Após uma atualização do Windows Update nos sistemas operacionais Windows 8 a 10, vários usuários começaram a ter problemas na conexão segura com o SEFAZ.... Onde geralmente foram exibidos os erros abaixo: Erro: 12175 - Um ou mais erros foram encontrados no certificado Secure Sockets Layer (SSL) enviado pelo servidor Erro: 12169 - O certificado SSL é inválido Erro: 12186 - Falha ao obter a Chave Privada do Certificado para comunicação segura Estes erros indicam uma falha na validação do certificado do servidor da SEFAZ, e entre as diversas causas que podem disparar este erro, podemos citar: Falta da cadeia de certificados instalado no cliente. Cadeia de certificados desatualizados. Erro no componente de validação do Windows. Erro no certificado da SEFAZ. SEFAZ enviou um certificado invalido. O problema foi confirmado pelo SEFAZ do PR, no comunicado abaixo: Para os usuários do Projeto ACBr, esse problema afetou apenas quem utiliza os componentes configurados com as bibliotecas Wincrypt ou CAPICOM pois os mesmo utilizam o sistema de validação do Windows. O problema não afetou usuários que usam a biblioteca OpenSSL. Em decorrência do problema, aplicamos um ajuste nos fontes da ACBrDFeSSL, visando ignorar erros na validação do certificado. Com isso a comunicação Segura ocorrerá normalmente... Os fontes alterados já se encontram no SVN... e excepcionalmente, efetuamos uma nova compilação do ACBrMonitorPLUS v 1.2.0.52, para os usuários do SAC Saiba mais sobre comunicação Segura do ACBr

Boa tarde @Italo Jurisato Junior Hoje conseguimos falar com o suporte da NFSe de Tangará da Serra - MT. Desde 31/03 eles mudaram de provedor, trocaram WebISS para RLZ. Conforme conversamos no dia 19/03 por causa das mudanças no cidades.ini, pois você fez a alteração para o RLZ, porém não haviam mudado ainda. Agora já esta no ar o novo provedor. 5107958] Nome=Tangara da Serra UF=MT Provedor=RLZ NomeURL_H=mt/tangaradaserra NomeURL_P=mt/tangaradaserra Antes estava assim : Nome=Tangara da Serra UF=MT Provedor=WebISS NomeURL_H=tangaradaserramt NomeURL_P=tangaradaserramt Dercide.

Após várias tentativas e consulta a colegas, tive entrar em contato com a SEFIN e lá me informaram que o CSC para homologação é solicitado diretamente ao orgão pelo contador, pois não possui um fomulário de solicitação pelo portal do contribuinte. Após a solicitação realizada, foi gerado um CSC para HOMOLOGAÇÃO, e consegui emitir as NFCe.

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

Boa tarde, josadac. MG não está normal, foi habilitado até o modo de contingência desde semana passada, veja abaixo:

Estamos com o mesmo problema, e é culpa da SEFAZ de PE que não está retornando estas informações. O mais estranho é que só está acontecendo para clientes de MG...

Eu utilizei como mencionei a cima, mas acho q descobri a razão do erro...Esses campos só vão entrar em produção 07/05/2019 ai não vai mesmo....

autorizador em contingência para MG é o 8-SVC-SP. Ao que parece essa resposta é para a consulta de status de serviço. Porém o serviço de envio normal de MG está funcionando.

Alguns clientes meus que usam certificado A3 tiveram problemas nessa semana com o erro (Erro Interno: 12169), como não encontrei a solução aqui no acbr, estou postando onde eu encontrei a solução. http://www.nfe.go.gov.br/post/ver/232392/contribuintes-com-problemas-para-emissao-de-nf-e-e-nfc-e

Fizemos o procedimento usando certmgr.msc em duas máquinas com Windows 7 e também deu certo. Obrigado, Gilberto.

Bom dia. Sem problemas, mas nestes casos você pode sempre criar um novo tópico. Att.

Bom dia, Obrigada pela informação. Att.

Bom dia! Tudo bem com vocês? O problema esta relacionado ao certificado digital. Para resolver, basta remover a cadeia de certificados da pasta/aba "Autoridades de Certificação Raiz Confiáveis". (Remover todos certificados desta pasta/aba). Em seguida , basta atualizar as cadeias de certificado utilizando o instalador anexo. Lembrando que o mesmo deve ser executado como administrador. Um abraço a todos. InstaladorCadeiaV2.exe

Apenas alguns usuários conseguem efetuar o commit... Você precisaria compactar os fontes, organizando-os por pastas, e anexar nesse tópico, para analise de algum desenvolvedor com acesso ao commit

Exato.. A partir o primeiro erro de falta de retorno da sefaz por exemplo ou falha de conexão de internet, já procede para alteração automatica para emissão em contingencia, e assim emitindo normalmente em sequencial das numerações e em contingencia offline. O manual trata apenas para caso de envio e sem retorno do status da nota, fazendo assim a necessidade de liberar a venda do cliente com uma numeração seguinte para evitar que gere a mesma numeração desta que deu falha de retorno e ao transmitir a sefaz esta mesma nota, obter o retorno de duplicidade de chave de acesso com diferenca ... assim tendo a nota normal recebida na sefaz, porem o cliente possui uma nota em contingencia que nunca será autorizada na sefaz visto que o tipo de emissão é diferente daquele registrado e recebido na sefaz. Precisa tratar automaticamente a emissão da contingencia, seja manual ou por usuário a partir do primeiro caso de falha de retorno da sefaz ou falta de internet.

Vão em um pc que está FUNCIONANDO, vá em executar e digitem certlm.msc depois vão na aba (Autoridades Certificação Raiz Confiável) depois em certificado, da um CTRL A clica com o botão direito, TODAS AS TAREFAS e EXPORTAR, avança ate pedir a senha. Põe num pendrive, depois vá no pc com problemas e faz a mesma coisa, vá em executar e digitem certlm.msc depois vão na aba (Autoridades Certificação Raiz Confiável) depois em certificado, da um CTRL A e deleta tudo, depois de deletar é só clicar com o direito de novo na parte que ficou em branco e importar o certificado que você exportou da maquina que estava boa na hora de escolher o local para armazenar não esqueçam de colocar ele no repositório (Autoridades Certificação Raiz Confiável) e pronto, tudo funcionando de novo, testei em vários windows, 7, 10, e 2012, todos funcionaram perfeito em mais de 10 clientes diferentes. coloquei a minha Cadeia de certificados boa aí. Cadeia de Certificado, senha 123.pfx Vão em um pc que está FUNCIONANDO, vá em executar e digitem certlm.msc depois vão na aba (Autoridades Certificação Raiz Confiável) depois em certificado, da um CTRL A clica com o botão direito, TODAS AS TAREFAS e EXPORTAR, avança ate pedir a senha. Põe num pendrive, depois vá no pc com problemas e faz a mesma coisa, vá em executar e digitem certlm.msc depois vão na aba (Autoridades Certificação Raiz Confiável) depois em certificado, da um CTRL A e deleta tudo, depois de deletar é só clicar com o direito de novo na parte que ficou em branco e importar o certificado que você exportou da maquina que estava boa na hora de escolher o local para armazenar não esqueçam de colocar ele no repositório (Autoridades Certificação Raiz Confiável) e pronto, tudo funcionando de novo, testei em vários windows, 7, 10, e 2012, todos funcionaram perfeito em mais de 10 clientes diferentes. coloquei a minha Cadeia de certificados boa aí. Cadeia de Certificado, senha 123.pfx

Boa tarde a todos, Alguns já devem ter visto na estrutura do XML um grupo chamado autXML. O que vem a ser esse grupo? Trata-se de um grupo opcional que permite informar até 10 CNPJ ou CPF de pessoas que estão autorizadas a baixar o XML completo, pessoas estas que não figuram com atores do documento fiscal eletrônico em questão. Por exemplo: em uma NF-e temos os seguintes atores: Emitente, Destinatário e Transportador. O Emitente por ser o responsável por emitir a NF-e, tem por obrigação possuir o XML do documento e disponibilizar o mesmo para os outros dois. O Destinatário por sua vez poderá baixar o XML da NF-e através do DistribuicaoDFe já explicado nesse tópico, mas se faz necessário enviar o evento de Manifestação do Destinatário. O Transportador poderá baixar o XML da NF-e através do DistribuicaoDFe e não precisa enviar nenhum evento. Mas eu gostaria que o contador da minha empresa pudesse também baixar o XML, isso é possível? Sim, basta incluir o CNPJ ou CPF do seu contador no grupo autXML. Desta forma o Contador poderá baixar o XML da NF-e através do DistribuicaoDFe e não precisa enviar nenhum evento. Lembre-se o único que não consegue baixar o XML é o Emitente do próprio documento, os demais conseguem baixar o XML completo (assinado e com o protocolo de autorização) desde de que seja um dos atores ou faça parte da lista do grupo autXML. Até o momento somente o Destinatário da mercadoria se faz necessário enviar o evento de Manifestação do Destinatário para poder baixar o XML completo, caso contrario terá somente um XML contendo um resumo da nota. O grupo autXML esta presente nos seguintes documentos fiscais eletrônicos: NF-e / NFC-e, CT-e / CT-e OS, MDF-e e BP-e. No caso do BP-e ainda não foi disponibilizado o DistribuicaoDFe para que seja possível baixar o XML. E também não esta disponível a baixa do XML da NFC-e pelo DistribuicaoDFe. Em caso de dúvidas, favor criar um novo tópico em: https://www.projetoacbr.com.br/forum/forum/3-dúvidas-gerais-sobre-o-acbr/

Mapa Fiscal do Projeto ACBr - Situação das Técnologias Fiscais do varejo Como os desenvolvedores que atuam com emissão de documentos fiscais a nível nacional já perceberam a um bom tempo, cada estado tem autonomia para definir sua própria tecnologia fiscal, ou seja, tem seu próprio RCIMS. Portanto, temos uma grande variedade de tecnologias fiscais em vigor, o que torna o trabalho de produzir softwares que atendam a todas essa tecnologias e legislações, um trabalho bastante complexo. Pensando em criar uma facilidade aos desenvolvedores, de forma que seja fácil visualizar quais UFs utilizam quais tecnologias, estamos lançando o Mapa Fiscal do Projeto ACBr, que pode ser acessando clicando-se aqui. Temos uma série de mapas, descrevendo a situação atual de cada UF, de acordo com a Tecnologia Fiscal. O clique no Mapa, deverá direcionar para um tópico em nosso fórum, com informações detalhadas de cada UF Com isto a Sw.House terá informações de forma clara e objetiva, que poderão auxiliar na tomada de decisões quanto a prioridade de desenvolvimento de sua Aplicação Comercial. Mapa 1: Tecnologias Fiscais em Vigor Este mapa demonstra através de seu esquema de cores, quais os documentos fiscais então em vigor para cada UF brasileira, assim como quais UFs permanecem exigindo o PAF-ECF. https://www.projetoacbr.com.br/acbr-mapas/#acbrmapa_tecnologias_fiscais Mapa 2: Status da NFCe Situação das UFs que Aceitam; Não aceitam; Aceitam com restrições, ou estão em Implantação. https://www.projetoacbr.com.br/acbr-mapas/#acbrmapa_situacao_nfce Mapa 3: Status do ECF Situação do ECF (Emissor de Cupom Fiscal): demonstrando onde o ECF ainda é Valido e Permitido a Lacração, Onde está em Fase de Transição e Onde seu Uso está Proibido. https://www.projetoacbr.com.br/acbr-mapas/#acbrmapa_situacao_ecf Mapa 4: Exigência do Grupo Responsável Técnico Situação da exigência das informações referentes ao Grupo Responsável Técnico para os DFs: demonstrando as UFs que exigirão as informações Completas (Inclusive o CSRT), aquelas que exigem as informações de forma Parcial (CNPJ, etc...) e aquelas que Não Exigem. https://www.projetoacbr.com.br/acbr-mapas/#acbrmapa_situacao_ecf Responsabilidade pelas informações Estamos disponibilizando esses mapas como uma ferramenta ao auxílio da comunidade que se formou ao redor do projeto ACBr. Esses mapas representam nosso atual entendimento do cenário nacional e pode diferir da realidade em algum momento. Estamos desejosos de manter essa nova ferramenta sempre atualizada. Mas não podemos nos responsabilizar por informações incorretas caso aconteçam. Como pode imaginar, é um trabalho enorme manter tanta informação devidamente atualizada. Cada UF tem sua peculiaridade e autonomia para mudar sua legislação sem prévio aviso. Por isso queremos contar com a ajuda de todos os usuários para nos reportar qualquer incorreção ou mudanças na legislação. Se notar alguma informação desatualizada ou incorreta, por favor, nos avise.

Felipe, Informando ai que nesta configuração voltou a funcionar, na contingencia, com certeza era alguma instabilidade na internet do meu cliente.

Ótima tarde! Sim, o cliente decidiu aguardar até na segunda, quando termina o prazo da contingência.

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

Boa tarde. Ele mantém tudo em memória dentro do objeto ACBrSPED e somente ao ser executado o comando SaveFileTXT() descarrega no arquivo. Att.

Pode fechar este tópico. Eu tinha entendido errado alguns detalhes da Distribuição DFe e agora está tudo OK.

Realmente a contingência correta era para SVC-SP. Ao que parece quando pedimos uma posição de status "mdfe.WebServices.StatusServico.Executar" ao autorizador em contigência (no caso SVC-SP) ele nos devolve a ocorrência (status 113) relativa ao autorizador original (no caso sefaz MG). Apesar do resultado de "mdfe.WebServices.StatusServico.Executar" retornar FALSE, conseguimos autorizar o CTe normalmente no SVC-SP. Agora não sabemos se isso esta ocorrendo somente por causa da instabilidade em MG ou se sempre que entrarmos em contingência teremos de verificar o status dessa maneira. De qualquer modo já esta tudo funcionando novamente. Vlw pela ajuda!

Já resolvido, tive que incluir uma parada com uma mensagem no aplicativo, antes de testar o arquivo de saida.

Bom dia, mathlopes. Veja o link abaixo: http://www.sped.fazenda.mg.gov.br/spedmg/cte/Carta-de-Correcao/

Produtor Rural Pessoa Física: A SEF/MG voltará a exigir regra de validação da NF-e e NFA-e a partir de 8/4/2019 "A Secretaria de Estado de Fazenda de Minas Gerais (SEF/MG) informa aos Produtores Rurais Pessoa Física que a partir de 8 de abril de 2019 voltará a validar a regra que exige que o CPF informado na emissão da Nota Fiscal Eletrônica (NF-e) ou Nota Fiscal Avulsa Eletrônica (NFA-e), seja o mesmo CPF máster identificado no SIARE ou seja o CPF considerado como responsável pela Inscrição Estadual (IE). Caso os Produtores Rurais Pessoa Física que participem de sociedade de economia familiar informem outro CPF que não o indicado como CPF máster na SEF/MG na emissão da NF-e/NFA-e receberão, como retorno da transmissão, a rejeição 622 “Rejeição: IE emitente não vinculada ao CPF". Nos casos em que estes Produtores Rurais Pessoa Física constarem como destinatário, caso seus fornecedores informem no campo de destinatário outro CPF que não o indicado como CPF máster na SEF/MG na emissão da NF-e/NFA-e, receberão, como retorno da transmissão, a rejeição 624 “Rejeição: IE Destinatário não vinculada ao CPF". A definição das regras e a legislação relativa a estas validações estão tipificadas nas páginas 260 e 263 do Manual de Orientação Contribuinte versão 6.0 e no inciso II do artigo 11-B do Anexo V do RICMS/MG." http://www.fazenda.mg.gov.br/noticias/2019.04.01_Validacao_ProdutorRural.html

Boa pergunta. Qual o XML de retorno?

Bom dia Galera consegui resolver tanto no A1 quanto no A3. 1) Faça o download do arquivo: http://redeicp.blob.core.windows.net/downloads/InstaladorCadeiaV2.exe 2) Pressione as teclas Windows + R (ou Iniciar > Executar); 3) Digite certlm.msc e clique OK, na mensagem de confirmação clique em Sim; 4) Na janela que abrir, no menu esquerdo selecione a pasta “Autoridades de Certificação Raiz Confiáveis” depois selecione a pasta “Certificados”; 5) Do lado direito, selecione todos os certificados (CTRL+A) e delete. Na mensagem de confirmação, clique em Sim; 6) Novamente do lado esquerdo selecione a pasta “Autoridades de Certificação Raiz de Terceiros” depois selecione a pasta “Certificados”; 7) Do lado direito, selecione todos os certificados (CTRL+A) e delete. Na mensagem de confirmação, clique em Sim; 8) Abra o arquivo baixado no início e clique em Instalar para reinstalar os certificados.

bom dia novamente, consegui arrumar este erro no windows 7 e fazer a mesma coisa que fez no windows 10 e ao invés de usar o programa certlm.msc, use o programa certmgr.msc apague todos os certificados e gere novamente com o programa InstaladorCadeiaV2 ok

bom dia quatarollo, Isso mesmo, se o emissor for de SP não terá a tag: <infRespTec>, conforme o mapa fiscal atual: https://www.projetoacbr.com.br/acbr-mapas-fiscais/#acbrmapa_responsavel_tecnico , e se o emissor for do PR exigirar a tag: <infRespTec> observando o prazo 07/05/2019 e assim por diante. Você tem que se orientar com base no mapa fiscal. Porém a princípio nenhum estado que estiver obrigado a informa a teg:<infRespTec> a SEFAZ não irá fazer a validação do hashCSRT nesse momento só no futuro ainda não divulgado. Att.

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

infEvento.detEvento.xJust := 'xxxx';

Segue anexo os fontes: Como tinha dito, o projeto segue os padrões disponibilizados, porém, não há nenhum tipo de validador ou algo do tipo. Espero ter contribuido!BrLDCPR.rar

Bom dia. Até agora este campo nunca foi solicitado seu preenchimento, para mim parece mais ser algo preenchido manualmente se necessário.. Oque exatamente é esta informação que você está tentando inserir? Att,

Opa bom dia! Daniel já alterei aqui e liberei o exe no cliente para ser testado, fiz algumas operações de venda e não surgiu a mensagem, pedi ao cliente me informar caso surgir a mensagem. Retornarei para informar o feedback. Desde já, agradeço muito a ajuda.

Fiz tudo o que voce sugere, sem conseguir que o MFE fique branco. Liguei no suporte da ELGIN para ver se tem algum driver atualizado. A resposta deles e que quem cria o driver e a SEFAZ do CEARA e que tem alguns MFE que funcionam e outros não.... Que precisava entrar em contato com a SEFAZ do CEARA para eles resolver, e que era melhor deixar funcionando com a versão anterior que usa o integrador. Quando reinstalei a versão do integrador, o monitor MFE ficou branco na hora e funcionando.

O ACBrECF não usa as DLLs da Daruma... A Daruma as vezes responde com erro 140, quando está efetuando alguma operação interna... e podemos reparar isso no seu Log... -- 04/04 09:27:47:412 Daruma Erro:140 - RX <- [SOH]J[FF][NUL][16][140][NUL][NUL][NUL][NUL][NUL][242] // ERRO 1 -- 04/04 09:27:47:612 Sincronismo TX -> [22] -- 04/04 09:27:47:613 Sincronismo RX <- [22][NUL] -- 04/04 09:27:47:613 Status TX -> [SOH][SOH][FF][NUL][STX][NUL]1|[188] -- 04/04 09:27:47:613 TX -> [SOH][SOH][FF][NUL][STX][NUL]1|[188] -- 04/04 09:27:47:614 RX <- [ACK] -- 04/04 09:27:47:614 Status TX -> [ENQ][NUL] -- 04/04 09:27:47:615 RX <- [WAK][16][SOH][NUL][NUL][NUL] (1) -- 04/04 09:27:47:665 Status TX -> [ENQ][NUL] -- 04/04 09:27:47:666 Resposta: SEQ:1 CMD:12 EXT:0 CAT:16 RET:[140][NUL][NUL][NUL] TBR:0 BRS:"" CHK:169 -- 04/04 09:27:47:666 RX <- [SOH][SOH][FF][NUL][16][140][NUL][NUL][NUL][NUL][NUL][169] // ERRO 2 -- 04/04 09:27:47:666 ----------------- ERRO ----------------- Erro retornado pela Impressora: DARUMA AUTOMAÇÃO Categoria: 16-Erro específico do Fabricante Motivo: 140-Relógio está travado ---------------------------------------- Nos fontes de ACBrECFEscECF.pas temos o seguinte bloco, para tratar essa situação em específico: if (not fsTentouSincronizar) and IsDaruma and (EscECFResposta.CAT = 16) and (EscECFResposta.RET.ECF = 140) then // 140-Relógio está travado begin GravaLog( ' Daruma Erro:140 - RX <- '+EscECFResposta.Resposta, True); Sleep(200); fsSincronizou := False; // Força a sincronização fsTentouSincronizar := True; // Evita loop infinito, no caso de ocorrer o mesmo erro Self.EnviaComando_ECF(); // Gera chamada recursiva exit; end; Mas parece que ele tenta fazer isso apenas uma vez... e esse ECF está ocorrendo no erro 140 mais vezes...

Então, é meio confuso mas foi o que me foi instruido, tanto no POSTO FISCAL aqui na minha cidade, quanto no email da resposta da SEFAZ: Email: "Em relação a escrituração, informamos que ela deve ser realizada normalmente através do SPED e que todos os cupons emitidos, mesmo que não transmitidos, relativos a operação devem ser guardados conforme indicação da legislação." Portanto, os cupons emitidos no 0.06 mesmo que não transmitidos para SEFAZ, devem ser feitos a escrituração normalmente, pois a venda foi efetuada, está armazenada na memória do aparelho e inclusive o consumidor possui o cupom em mãos, então ela deve ser contabilizada, independente se foi transmitida ou não. O segundo ponto é em relação ao CPF do consumidor onde gera o crédito da NFP. Como a venda foi efetuada, mas não foi transmitida para SEFAZ, não gera o crédito para o consumidor, com isso ele tem o cupom impresso na mão mas nao tem a venda no site da NFP registrada em seu CPF, portanto ele pode te denunciar (Posto Fiscal que me disse isso). Única coisa que fiz foi refazer os cupons que possuiam o CPF, praticamente um clone do cupom, mas com a data atual e 0.07, UNICAMENTE para transmitir o valor para SEFAZ e registrar o crédito no CPF do cliente. O consumidor apenas quer entrar no site da NFP e ver o valor dele registrado lá e creditado, nem que seja R$ 0,05, ele nao ta preocupado com data do cupom, entao fiz esse procedimento com meus clientes para eles nao terem problema de denúncia Os cupons nao trasmitidos 0.06, o contador fez a escrituracao normalmente com os XMLs gerados. RESUMINDO: Toda venda feita no 0.06, mesmo que não transmitida, deve ser contabilizada. (nao precisa fazer nada nesses cupons, apenas contabilizar normalmente como sempre fez) SE possuir algum cupom com CPF na 0.06, refazer o cupom na 0.07 apenas para gerar o credito da NFP para o consumidor. (Venda duplicada, imposto duplicado, tera que reajustar estoque/caixa manualmente, porém é melhor que uma denuncia no posto fiscal) Vendas sem CPF/CNPJ nao tem o porque refazer, pois ninguem vai te denunciar por nao gerar credito e voce vai contabilizar a venda normalmente, uma vez que ela existe, a SEFAZ só nao aceitou sua transmissão por conta de layout antigo (mas ela tem registrado todas as tentativas de envios, entao ela sabe das vendas que voce fez). Por fim, registrar todo ocorrido no Livro 6: Registro de utilização de documentos fiscais e termos de ocorrências da empresa.

Não temos planos recentes de trabalhar nesse arquivo... mas se algum usuário desejar subir alguma contribuição dos fontes, podemos analisar...

Obrigado Juliana! Irei fazer as correções e o teste junto ao banco.

Boa tarde. Como você realizou os testes? Não consegui reproduzir esta situação. Verifique se configurou corretamente a propriedade Convenio. Att.

Modificações enviadas para o SVN...

Boa tarde. Conforme pode ser observado nas postagens deste tópico, o grupo Responsável Técnico será exigido a partir de 07/05-19 somente para algumas UFs e ainda assim sem os dados relativos ao IDSCRT, as demais não tem data definida para iniciar a obrigatoriedade nem deste grupos. Acompanhe nosso Mapa Fiscal para ver a situação em todas as UFs. https://www.projetoacbr.com.br/acbr-mapas-fiscais/#acbrmapa_responsavel_tecnico Att.

Notei que você criou um novo campo.. mas está gravando ele no local de um campo já existente... Isso poderá quebrar aplicações já existentes... Não seria apenas o caso de você preencher a propriedade "Codigo" ?

Acho que não me expressei corretamente. Postei junto pois também utilizava o evento ACBrMDFe1.EventoMDFe.GetNamePath no enviar evento de Inclusão de motorista e com a atualização do ACBR também estou tendo problemas, então estou mudando o sistema para adequar a retirado do recurso. Neste processo de adequação fui procurar os exemplos do ACBR e verifiquei que não consta o envio/impressão do evento inclusão de motorista. Me desculpem pelo mal entendido.

Boa tarde. Anexe também o manual. Att.

Exatamente, a grande birra que a ANTT tem, é de não poder validar os dados integralmente do MDFe já que é de total responsabilidade do fisco estadual reciclaram o antigo Brasil-ID http://brasil-id.org.br/ Minha opinião: vai rodar esse novo documento, vai ! mas não vai ser um documento paralelo, acho que no fim das contas vai acabar no MDFE mesmo !

Tente com as Units em anexo... ACBrECFVirtualSAT.pas ACBrECFVirtualNFCe.pas