Pesquisar na Comunidade
Showing results for tags 'CTe'.
Encontrado 395 registros
-
Atualizadas as cadeias de certificado da Sefaz de Minas Gerais
um tópico no fórum postou Diego Foliene Notícias do ACBr
Olá comunidade ! A Sefaz de MG atualizou as cadeias de certificado opcionais que podem ser instaladas em caso de problema. Elas foram atualizadas no dia 14/04/2026 às 9h. O download pode ser feito: Para BPe AQUI; Para CTe AQUI; Para CTeOS AQUI; Para NFAg AQUI; Para NFeABI AQUI; Para NFe AQUI; Para NFCe AQUI; Para NFGas AQUI; Para NF3e AQUI; Para NFCom AQUI;-
- 2
-
-
- cadeia de certificados
- mg
- (e 11 mais)
-
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º 4, de 6 de Abril de 2026 que altera Ajuste SINIEF nº 9, de 25 de outubro de 2007 incluindo os §§ 3º e 4º ficam acrescidos à cláusula terceira-B do referido ajuste: A modificação estabelece que a correção de valores no CT-e Simplificado deverá ser feita via CT-e de Substituição e dispensando a necessidade de evento de CT-e em desacordo no caso em questão. Essa alteração entra em vigor a partir de 01/06/2026 conforme cláusula segunda do mesmo ajuste:
-
- 3
-
-
- ajuste sinief
- cte
- (e 4 mais)
-
Publicada novas cadeias de certificado pela Sefaz de Minas Gerais.
um tópico no fórum postou Diego Foliene Notícias do ACBr
Olá comunidade ! A Sefaz de MG atualizou as cadeias de certificado opcionais que podem ser instaladas em caso de problema. Elas foram atualizadas dia 20/3/2026 às 9h e são válidas até 14/06/2026. O download pode ser efetuado: Para NFC-e AQUI; Para NF-e AQUI; Para CT-e AQUI; Para BP-e AQUI; -
Problema ao compilar para 64 bits utilizando ACBRNFe
um tópico no fórum postou Everton M Gava ACBrNFe
Senhores, boa tarde. Estamos migrando alguns sistemas que utilizam o componente ACBrNFe de 32 para 64 bits, utilizando o Delphi 10.2. Pois bem, estou utilizando uma versão do ACBr baixada do repositório hoje (26/04/2018). O componente está configurado da seguinte maneira: o arquivo ACBr.inc está configurado da seguinte maneira: Quando efetuo a compilação para 64bits o meu sistema acusa o seguinte erro (Ao que me parece, não estão sendo carregadas as DLL's do OpenSSL): Quando efetuo a compilação em 32bits, a compilação transcorre sem nenhum problema, sendo efetuada a transmissão normalmente. Alguem pode me dar alguma dica com relação à isso? Obs: já li todo o conteúdo relacionado nos tópicos abaixo e não consegui resolver o meu problema: -
Publicado Ajuste Sinief removendo critérios para impressão do DACTe.
um tópico no fórum postou Diego Foliene Notícias do ACBr
Olá comunidade ! Foi publicado no Diário Oficial da União o Despacho Nº 42, de 8 de Dezembro de 2025. A publicação traz diversos Ajustes Sinief, incluindo o Ajuste SINIEF Nº 35, de 5 de Dezembro de 2025 que revoga os §§ 7º e 8º da cláusula décima primeira do Ajuste SINIEF nº 9, de 25 de outubro de 2007: Efetivamente removendo critérios para impressão do DACTe. Conforme cláusula segunda esta alteração entra em vigor a partir de 01/02/2026. -
Olá Devido a mudança de units para reforma tributaria, notamos que foi adicionado uma validação nos campos de CNPJ do CT-e que não é obrigatória, por exemplo quando o "Destinatário" é de outro país(Paraguai). Gostaria de solicitar um ajuste para essa situação. A versão nova esta da seguinte forma: ACBrCTe.XmlWriter.pas function TCTeXmlWriter.Gerar_Dest: TACBrXmlNode; ... if CTe.Exped.EnderExped.cPais = 1058 then Result.AppendChild(AddNodeCNPJCPF('#039', '#040', CTe.Exped.CNPJCPF)) else Result.AppendChild(AddNodeCNPJ('#039', '00000000000000', CODIGO_BRASIL, True)) ... Obs: dentro do método "AddNodeCNPJ", esta fazendo uma validação do CNPJ, porque foi passado a constante "CODIGO_BRASIL" nos parâmetros. Sendo que a antiga não validava esse campo quando o pais é diferente de 1058: pcteCTeW.pas procedure TCTeW.GerarDest; ... if CTe.Dest.EnderDest.cPais = 1058 then Gerador.wCampoCNPJCPF('#179', '#180', CTe.Dest.CNPJCPF) else Gerador.wCampo(tcStr, '#179', 'CNPJ', 00, 14, 1, '00000000000000', DSC_CNPJ); ... Todas as seguintes procedures foram adicionadas a mesma validação: TCTeW.GerarReceb -> TCTeXmlWriter.Gerar_Receb TCTeW.GerarExped -> TCTeXmlWriter.Gerar_Exped TCTeW.GerarRem -> TCTeXmlWriter.Gerar_Rem TCTeW.GerarDest -> TCTeXmlWriter.Gerar_Dest
-
Para mais detalhes confira o tópico: Nota Técnica 2025/001 - CT-e/GTVe/CTeOS - Reforma Tributária do Consumo.
-
Documentos afetados pela Reforma Tributária e suas respectivas soluções ACBr.
um tópico no fórum postou Diego Foliene Notícias do ACBr
Introdução Não há como negar que a Reforma Tributária, como uma onda, já afetou e continuará afetando todo o cenário de emissão de documentos fiscais eletrônicos no Brasil pelo menos até 2032. Trata-se de um verdadeiro chacoalhão para desenvolvedores e empresas, trazendo novos campos, grupos e regras de validação que precisam ser observados atentamente. As soluções do Projeto ACBr vêm sendo constantemente atualizadas conforme cada novidade publicada, permitindo que os desenvolvedores as utilizem para facilitar o processo de emissão desses documentos sem grandes dores de cabeça. O objetivo deste tópico é centralizar quais são os documentos fiscais impactados e apresentar como está a situação das respectivas soluções do Projeto ACBr diante das mudanças Documentos afetados Nota Fiscal Eletrônica / Nota Fiscal de Consumidor Eletrônica Última atualização dessas informações: 24/11/2025; Abreviação: NF-e / NFC-e; Modelo: 55 / 65; Solução nativa: ACBrNFe Implementada no ACBrMonitorPLUS: Possui ACBrLib: Ultima Nota Técnica da Reforma Tributária: Nota Técnica 2025/002 v1.31 Adequado a última nota técnica: Observação: Novos eventos estão sendo implementados gradativamente. Nota Fiscal de Serviços Eletrônica Última atualização dessas informações: 24/11/2025; Abreviação: NFS-e Modelo: -- Solução nativa: ACBrNFSeX Implementada no ACBrMonitorPLUS: Possui ACBrLib: Ultima Nota Técnica da Reforma Tributária: Nota Técnica 005 - v1.00 Adequado a última nota técnica: Observação: Os novos campos foram adicionados, mas os arquivos de schema ainda não foram disponibilizados e o ambiente de homologação não foi liberado. Nota Fiscal de Fatura de Serviços de Comunicação Eletrônica Última atualização dessas informações: 24/11/2025; Abreviação: NFCom Modelo: 62 Solução nativa: ACBrNFCom Implementada no ACBrMonitorPLUS: Possui ACBrLib: Ultima Nota Técnica da Reforma Tributária: Nota Técnica 2025/001 v1.10 Adequado a última nota técnica: Observação: -- Nota Fiscal de Serviços de Energia Elétrica Última atualização dessas informações: 24/11/2025; Abreviação: NF3e Modelo: 66 Solução nativa: ACBrNF3e Implementada no ACBrMonitorPLUS: Possui ACBrLib: Ultima Nota Técnica da Reforma Tributária: Nota Técnica 2025/001 v1.10 Adequado a última nota técnica: Observação: -- Bilhete de Passagem Eletrônico / Bilhete de Passagem Eletrônico Transporte Metropolitano Última atualização dessas informações: 24/11/2025; Abreviação: BP-e / BP-e TM Modelo: 63 Solução nativa: ACBrBPe Implementada no ACBrMonitorPLUS: Possui ACBrLib: Ultima Nota Técnica da Reforma Tributária: Nota Técnica 2025/001 v1.10 Adequado a última nota técnica: Observação: Bilhete de Passagem Eletrônico para Transporte Aéreo (BP-e TA) ainda não implementado. Conhecimento de Transporte Eletrônico / Guia de Valores de Transporte Eletrônico / Conhecimento de Transporte Eletrônico Outros Serviços Última atualização dessas informações: 24/11/2025; Abreviação: CT-e / GTV-e / CT-e OS Modelo: 57 / 64 / 67 Solução nativa: ACBrCTe Implementada no ACBrMonitorPLUS: Possui ACBrLib: Ultima Nota Técnica da Reforma Tributária: Nota Técnica 2025/001 v1.10 Adequado a última nota técnica: Observação: -- Nota Fiscal da Água e Saneamento Última atualização dessas informações: 24/11/2025; Abreviação: NFAg Modelo: 75 Solução nativa: -- Implementada no ACBrMonitorPLUS: Possui ACBrLib: Ultima Nota Técnica da Reforma Tributária: -- Adequado a última nota técnica: Observação: Documento publicado apenas em formato de minuta, sem publicação definitiva. -
Version 1.3.6.374
2.463 downloads
ACBrCTe - Biblioteca para emissão e impressão de Conhecimento de Transporte Eletrônico Faça Download pelo SVN, dos Demos de uso da ACBrLibCTe 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 -
Em versões anteriores era: ACBrCTe.DACTe.ExibirCampoFixo := True; ACBrCTe.DACTe.CampoFixo.Nome := 'USO EXCLUSIVO DO EMISSOR DO CT-E'; ACBrCTe.DACTe.CampoFixo.Valor := 'Texto que você deseja imprimir aqui'; E essa informação não ia para o XML. Como fazer agora?
-
Aviso de Migração de Infraestrutura! - SEFAZ RS
um tópico no fórum postou Daniel InfoCotidiano Notícias do ACBr
No dia 31 de agosto de 2025, das 07:00 às 09:00, devido a uma manutenção no datacenter poderá ocorrer alguma instabilidade nos sistemas de autorização de documentos fiscais eletrônicos devido a migração defintiva para ambiente em nuvem. A indisponibilidade pode gerar intermitência ou parada da autorização nos sistemas de CTe, BPe, NF3e, NFCom, NFF, ONE, SVD e MDFe, afetando tanto os contribuintes do RS quanto os contribuintes das UF participantes da SVRS. Durante este período, estará disponível a Sefaz Virtual de Contingência de SP (SVC-SP), para CTe. Para os demais documentos, poderá ser utilizado processo de emissão em contingência off-line. IMPORTANTE: NFe e NFCe não serão afetadas pela manutenção! IMPORTANTE 2: A alteração de infraestrutura para nuvem irá modificar os endereços IP que respondem por todos os serviços destes documentos, é fundamental que as empresas estejam obtendo o endereço IP dos serviços de forma dinâmica sem fixar endereços e com baixo tempo de retenção de cache. IMPORTANTE 3: Quem utiliza Java em sua solução deve buscar estar com os componentes atualizados, evitando problemas de conexão em razão do protocolo de segurança TLS. Link da noticia na integra: https://dfe-portal.svrs.rs.gov.br/CTE/Avisos/2953-
- 4
-
-
- manutenção
- migração
- (e 11 mais)
-
simplificado Impressão do Frete no CTe Simplificado
um tópico no fórum postou Daianne Renasoft ACBrCTe
Boa Tarde! Estou emitindo um CTe Simplificado com a tag <det nItem> se repetindo 3 vezes, dentro dessa tag fica também a tag <vPrest> referente ao valor da prestação de serviço. Devido a tag constar 3 vezes no XML quando impresso a DACT no formato fortes report o valor do frete também repete 3 vezes. Neste caso o ideal seria enviar a tag <vPrest> preenchida somente uma vez e as demais ficarem zeradas ou precisamos fazer outro tipo de correção para que a impressão fique correta?
-
Olá bom dia! Após receber feedback de empresa ATM que recusou o XML do CTe gerado, verifiquei o seguinte: No final do arquivo dentro das tags <protCTe versao="4.00">, <infProt> O campo que deveria ser <chCTe> estava como <chBPe>, mesmo o documento estando no modelo correto, 57. Analisando o fluxo, percebi que o retorno do envio o campo com a chave correta <chCTe>. Porém ao realizar uma consulta deste CTe, o XML é recriado e o novo XML agora está com a chave <chBPe> Verifiquei que o componente ACBrCTe.XmlWriter dentro da function TCTeXmlWriter.Gerar_ProtCTe está definindo a tag como <chBPe> Realizei a alteração do arquivo corrigindo para <chCTe>, e o meu problema foi resolvido. Estou abrindo o tópico para esclarecer com vocês se isto que verifiquei é realmente um erro dentro do componente ACBrCTe.XmlWriter, ou se existe algum fluxo ou nova regra que altera a definição dessa tag
-
Implementação da Nota Técnica 2025/001 versão 1.07 Reforma Tributária - CTe\CTeOS\GTVe - HOMOLOGAÇÃO
um evento no calendário postou Diego Foliene Prazos SEFAZ
Para mais detalhes confira o tópico: Nota Técnica 2025/001 - CT-e/GTVe/CTeOS - Reforma Tributária do Consumo. -
Olá pessoal! Foi publicado o Ato Diat Nº031/2025 estabelecendo o procedimento, as condições e os prazos para o pedido de cancelamento extemporâneo para o Conhecimento de Transporte Eletrônico (CTe). Vale lembrar, que os documentos fiscais eletrônicos, possuem um prazo estabelecido em legislação para que possam ser cancelados, quando esse prazo é extrapolado e mesmo assim é necessário o cancelamento do documento, é necessário realizar um pedido junto a Sefaz para realizar um cancelamento fora do prazo, ou seja, um cancelamento extemporâneo. O artigo 2º estabelece que: O pedido de cancelamento extemporâneo deve ser feito pelo emitente no aplicativo do Sistema de Administração Tributária (S@T). O pedido deve ser feito no prazo de 45 dias contados da data de emissão do CTe. Cada pedido vai corresponder a um único documento. O registro do pedido gera Documento de Arrecadação de Receitas Estaduais (DARE) automaticamente e seu pagamento deve ser feito para o processamento do mesmo. O artigo 3º estabelece que é vedado o cancelamento extemporâneo quando: CTe emitido em contingência. Oassado 60 dias a partir da data de emissão do CTe. For constatado fato gerador de imposto relativo ao serviço de transporte para o CTe. Sendo considerado fato gerador: Registro de passagem. Escrituração do CTe pelo Tomador. Eventos ou documentos vinculados ao CTe, como por exemplo: CCe, CTe Complementar, CTe Substituto, Prestação em Desacordo, MDFe ou Comprovante de Entrega. Indício de geração através de cruzamento de informações. O artigo 4º estabelece que após o pedido de cancelamento extemporâneo for finalizado, o envio do evento de cancelamento deve ser feito em: até 15 dias contados a partir do registro do pedido de cancelamento. até 60 dias contados a partir da emissão do CTe. Leia a o Ato Diat Nº031/2025 na íntegra AQUI.
-
Boa tarde, Estamos desenvolvendo uma rotina para registrar o evento de desacordo na CTe. Temos 2 versões desse método, um que é feito a leitura do XML, esse está 100%. E outra que seria apenas informado a chave da CTe, justificativa e UF. Porem percebemos que ele retorna a mensagem de "UF não pode ser vazia.". Debugando o código, percebi que a chCTe esta sumindo no meio do caminho. Em dado momento ele tenta obter a UF, com essa função function ExtrairUFChaveAcesso(const AChave: string): Integer; begin Result := StrToIntDef(Copy(OnlyNumber(AChave),1,2), 0); end; Como a chave chegou ali em branco ele acaba não conseguindo obter a UF. Código da minha função: procedure PrestacaoServicoDesacordoCTe(xObs, UFTomador, CNPJTomador, Chave : string); var iLote: Integer; obCteSefaz : TCteSefaz; begin obCteSefaz := TCteSefaz.Create; with obCTeSefaz do begin ACBrCTe.Conhecimentos.Clear; ACBrCTe.EventoCTe.Evento.Clear; with ACBrCTe.EventoCTe.Evento.Add do begin infEvento.nSeqEvento := 1; // Devemos informar a UF do Emitente do CT-e InfEvento.cOrgao := UFtoCUF(UFTomador); infEvento.chCTe := Chave; infEvento.CNPJ := RemoverCaracteresEspeciais(CNPJTomador); infEvento.dhEvento := now; infEvento.tpEvento := tePrestDesacordo; infEvento.detEvento.xOBS := xObs; end; iLote := 1; // Numero do Lote do Evento ACBrCTe.EnviarEvento(iLote); ACBrCTe.Free; end; obCTeSefaz.Free; end; Tem mais um print em anexo, nele podemos ver que o xml gerado não tem a chave, e podemos ver que na lista de watchList, a variável com chave está devidamente preenchida. Que no caso seria essa: 43250634046620000183570000000000241025021119-cte.xml apenas com os números. Em outros tópicos (já fechados) sobre esse assunto, é dito que não há necessidade de carregar o XML para emitir esse tipo de evento.
-
Publicada Nota Técnica Conjunta sobre o CNPJ Alfanumérico.
um tópico no fórum postou Diego Foliene Notícias do ACBr
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.
-
- 9
-
-
- cnpj
- alfanumerico
- (e 17 mais)
-
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.
-
Pessoa boa noite, estou tentando enviar um cancelamento para a sefaz, o formato que estou enviando para homologação esta abaixo da mensgem, e o retorno esta sendo cstat: 243, XML mal formado, para Eventos não existe a necessidade de transformar em base64 correto? ja estou enviando a assinatura correta, pois a comunicação funciona para recepcao. quando envio no validador da SEFAZ não tem apontamentos <?xml version="1.0" encoding="UTF-8"?> <eventoCTe xmlns="http://www.portalfiscal.inf.br/cte" versao="4.00"> <infEvento Id="ID11011135241232071658000143571019876543211123456785111"> <cOrgao>35</cOrgao> <tpAmb>2</tpAmb> <CNPJ>valor ocultado</CNPJ> <chCTe>35241241054338000166571019876543211123456785</chCTe> <dhEvento>2025-01-04T00:01:53-00:00</dhEvento> <tpEvento>110111</tpEvento> <nSeqEvento>111</nSeqEvento> <detEvento versaoEvento="4.00"> <evCancCTe> <descEvento>Cancelamento</descEvento> <nProt>123456789012345</nProt> <xJust>justificativa de cancelamento</xJust> </evCancCTe> </detEvento> <infPAA> <CNPJPAA>valor ocultado</CNPJPAA> <PAASignature> <SignatureValue> valor ocultado</SignatureValue> <RSAKeyValue> <Modulus> valor ocultado</Modulus> <Exponent>valor ocultado</Exponent> </RSAKeyValue> </PAASignature> </infPAA> </infEvento> <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="#ID11011135241242078658000166571019876543211123456785111"> <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>VWotwxAf6RNFfgqGXvMeA78M7eA=</DigestValue> </Reference> </SignedInfo> <SignatureValue> valor ocultado</SignatureValue> <KeyInfo> <X509Data> <X509Certificate> valor ocultado</X509Certificate> </X509Data> </KeyInfo> </Signature> </eventoCTe>
-
Nota Técnica 2024/001 - DF-e: Projeto Reforma Tributária do Consumo Adequação DFe
um tópico no fórum postou Diego Foliene Notícias do ACBr
Olá pessoal! Foi publicado no dia 31/07/2024 a Nota Técnica 2024/001 abrangendo múltiplos DFes com o objetivo de adequá-los as modificações propostas pela Reforma Tributária. Introdução O PLP 68 estabelece que os estados, o distrito federal e os municípios devem padronizar seus sistemas autorizadores de documentos fiscais para permitir aos contribuintes que informem os dados relativos ao Imposto sobre Bens e Serviços (IBS), Contribuição sobre Bens e Serviços (CBS) e Imposto Seletivo (IS). Esta nota técnica, a princípio, trata em conjunto os seguintes documentos: Conhecimento de Transporte Eletrônico (modelo 57). Conhecimento de Transporte Eletrônico para Outros Serviços (modelo 67). Bilhete de Passagem Eletrônico (modelo 63). Nota Fiscal de Energia Elétrica (modelo 66). Nota Fiscal Fatura de Serviço de Comunicação Eletrônica (modelo 62). A versão final desta NT vai gerar NTs específicas para cada documento acima referido. A Nota Fiscal Eletrônica (modelo 55) junto da Nota Fiscal de Consumidor Eletrônica (modelo 65) vão ser tratadas em NT específica. Alterações Alteração do leiaute dos DFe Adiciona grupo para informação do IBS/CBS Adiciona no layout dos documentos mencionados o Grupo de Informações da Tributação IBS/CBS (IBSCBS) que fará parte do grupo imposto/imp, deverá ser adicionado em cada item nos documentos que apresentarem itens (NF3e/NFCom) ou diretamente no corpo do documento caso ele não possua itens (CTe/BPe). O IBSCBS é composto por um elemento para informação do Código da Situação Tributária do IBS/CBS (CST), um elemento para informação do Código da Classificação Tributária do IBS/CBS (cClassTrib) e um Grupo para as Informações Específicas do IBS/CBS (gIBSCBS), este último possuindo seus próprios elementos e subgrupos. Considerando apenas os elementos, o grupo IBSCBS adiciona um total de 48 novas informações a serem preenchidas no arquivo. O arquivo DFeTiposBasicos_v1.00.xsd adicionado ao pacote de schemas que compõe o DFe trás os referidos campos. Adiciona grupo para totalização do IBS/CBS Para a NF3e, NFCom e BPe TM também deverá ser adicionado no grupo total do respectivo documento um grupo para totalizar as informações do IBS/CBS (IBSCBSTot). Para CTe, CTe Simplificado, CTeOS e BPe não será criado. Adiciona campo para totalização do documento acrescida do IBS/CBS Na NF3e, NFCom e BPe TM adiciona no grupo total o campo vTotDFe que deverá receber o valor correspondente a (vNF/vTPrest + total do IBS + total da CBS). No CTe, CTe Simplificado, CTe OS e BPe a referida Tag será adicionada no grupo imp. Código Situação Tributária e Classificação da Tributação Será disponibilizado no portal dos respectivos documentos tabelas relacionando o CST x cClassTrib para o correto preenchimento das informações. Regras de Validação Esta nota técnica adiciona regras de validação que verificam dentre outras coisas se: Foi informado CST correto para o IBS/CBS Foi informado classificação tributária correta para o IBS/CBS. O grupo IBS/CBS foi preenchido quando não deveria. O grupo IBS/CBS não foi preenchido quando deveria. Os valores informados nos campos foram preenchidos corretamente. Os valores referentes a crédito presumido foram preenchidos nas situações em que são obrigatórios. Os valores referentes a desoneração foram preenchidos nas situações em que são obrigatórios. Os totalizadores correspondem a soma dos valores individuais. Datas Implantação Homologação: 01/09/2025 Implantação Produção: 31/10/2025 Vale ressaltar que como as discussões referentes a reforma tributária ainda estão em curso, a NT pode ser ajustada ao longo do processo. E como fica o ACBr? Serão necessários ajustes nos fontes do ACBr e novas compilações do Monitor e da Lib. Foi criada a #TK-5814 em nosso backlog para alteração dos fontes. Vale ressaltar que a NT é recente e existe um período expressivo até que seja liberada a homologação. Leia a NT na íntegra AQUI.- 1 reply
-
- 5
-
-
- nt
- nota tecnica
- (e 12 mais)
-
Publicada a versão 1.05 da Nota Técnica 2015/002 para o CT-e.
um tópico no fórum postou Diego Foliene Notícias do ACBr
Olá pessoal! No dia 13/11/2024 foi publicada a versão 1.05 da Nota Técnica 2015/002 para o CT-e. Esta nota técnica trata sobre o web service de Distribuição de DF-e para o CT-e. A nova versão adiciona o CT-e Simplificado como um documento a ser devolvido pela distribuição, para o Tomador e também para Terceiros. Com esta nova versão, o CT-e, CTe-OS, GTV-e e agora o CT-e Simplificado são devolvidos para os participantes de acordo com o quadro abaixo: Datas As datas tanto do ambiente de homologação quanto do ambiente de produção estão como 21/10/2024, dando a entender que a NT já está em vigor em ambos os ambientes. Vale lembrar: A solução ACBr já implementa o processo de Distribuição DFe para o CT-e. Leia a versão 1.05 da Nota Técnica na íntegra AQUI.
-
Boa tarde! Alguem já possui alguma atualização sobre o modelo da DACTE do Simplificado?
-
Correção da informação do valor do ModeloDF para o CT-e para Lib.
um tópico no fórum postou Diego Foliene Notícias do ACBr
Olá pessoal! Foi detectado a necessidade de uma correção na informação do ModeloDF para a Lib do CT-e. Atualmente na documentação consta da seguinte forma: No entanto, a Lib faz uso do enumerado nativo do componente e o mesmo possui a seguinte estrutura: TModeloCTe = (moCTe, moGTVe, moCTeOS); Portanto, a correta relação de conversão é: A informação foi corrigida na documentação e será atualizada em compilação posterior. Para quem utiliza as classes de alto nível do C#, o enumerado corrigido já foi disponibilizado no SVN e o pacote Core disponível no nuget foi atualizado. -
Parada programada para a Sefaz do estado do Mato Grosso no dia 10/08/2024
um tópico no fórum postou Diego Foliene Notícias do ACBr
Olá pessoal! No site da secretária do estado do Mato Grosso, consta uma NOTÍCIA informando que a Sefaz do Mato Grosso realizará no dia 10/08/2024 uma parada programada para atualização da versão do banco de dados utilizado. A manutenção está prevista para iniciar às 15h00 e ser concluída até às 22h00 do mesmo dia. Os ambientes autorizadores da NF-e, NFC-e e NF3-e já foram atualizados. A previsão é de que o ambiente autorizador do CT-e será afetado e durante este período a contingência SVC seja ativada. Para utilizar as soluções ACBr em contingência, siga as orientações deste tópico:-
- 1
-
-
- contingência
- contingencia cte
- (e 3 mais)
-
Boa tarde. Estou tentando conciliar um CT-e emitido via EPEC, no ambiente de Homologação da Sefaz MT, só que sempre está retornando a rejeição a seguir: “402 - Rejeicao : XML da area de dados com codificacao diferente de UTF-8.” Já verifiquei o XML, inclusive no Validador de Mensagens do Projeto CT-e, e não acusa erro. - Ao tentar emitir um documento com os mesmos dados, mas forma de emissão 1 – Normal, é autorizado normalmente. - Ao tentar emitir um evento EPEC, o mesmo é criado normalmente. - Ao tentar conciliar o CT-e (com tpEmiss = 4) referente a EPEC anterior, sempre é retornada a rejeição 402. Entrei em contato com o atendimento da Sefaz MT, mas não responderam mais. Expliquei a situação, pedindo para verificarem também se poderia ser algo relacionado ao ambiente, conforme e-mail abaixo: Analisei até o código-fonte (\Fontes\ACBrDFe\ACBrCTe\ACBrCTe.pas linha 338 em diante) e não percebi nada diferente: // Passo 2 calcular o SHA-1 da string idCTe se o Tipo de Emissão for EPEC ou FSDA if TipoEmissao in [teDPEC, teFSDA] then begin // Tipo de Emissão em Contingência SSL.CarregarCertificadoSeNecessario; sign := SSL.CalcHash(idCTe, dgstSHA1, outBase64, True); Passo2 := '&sign=' + sign; sEntrada := sEntrada + Passo2; end; Result := urlUF + sEntrada; Em anexo XMLs: CT-e com emissão Normal: 51240706137422000190570010000000311680036048-cte-normal.xml Evento EPEC: 11011351240706137422000190570010000000254289813233001-procEventoCTe.xml CT-e com tipo de emissão EPEC: 51240706137422000190570010000000254289813233-cte-epec.xml Envio do lote: 25-env-lot.xml e 25-env-lot-decodado.xml Rejeição retornada: 25-pro-lot.xml Caso alguém tenha passado por essa situação e possa contribuir com algo, fico grato, mas acredito não ter algo a ver com o ACBr, já que utilizamos a emissão e conciliação de EPEC normalmente em ambiente de Produção, pelo menos até o momento.
.jpg.84cf1b52f63337422c66f213f4c51146.jpg)
.jpg.d58696759f5cafdb09e77c7d311ab370.jpg)
.jpg.4268e2b23c337a0fc15a7299bb281cf9.jpg)
