Pesquisar na Comunidade

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.

Olá pessoal, boa tarde! Estou com a seguinte rejeição ao tentar enviar uma CCe do CTe em C# utilizando o fontes. Já atualizamos o schema cte e também não obtivemos sucesso. Rejeição: Carta de correção inválida (campo/grupo “[refNF:nro]” informado não existe no schema do CT-e ou não existe no grupo informado). Segue em anexo o XML da tentativa de emissão e também o arquivo INI do evento. 851-ped-eve.xmlIniFile.txt

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?

Ao tentar emitir o conhecimento ocorre o seguinte erro na estrutura do xml: Não foi possível gerar o CT-e. Validação do CT-e assinado: Falha na validação dos dados do Conhecimento: 73739 --> 1871 - Element '{http://www.portalfiscal.inf.br/cte}infCarga': This element is not expected. Expected is ( {http://www.portalfiscal.inf.br/cte}toma ). CTe_FOR - F - 73739.XML

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.

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:

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.

Boa tarde. Ao informar Unidades de Transporte no grupo de Outros Documentos (infOutros), e tentar carregar o XML no componente novamente, através do LoadFromFile, é disparada uma exception "EConvertError", como na mensagem de erro abaixo: Exception class EConvertError with message ''15,000</qtdRat></infUnidTransp>' is not a valid floating point value'. No XML está assim por exemplo: <infUnidTransp> <tpUnidTransp>1</tpUnidTransp> <idUnidTransp>1251</idUnidTransp> <lacUnidTransp> <nLacre>54541</nLacre> </lacUnidTransp> <qtdRat>15.000</qtdRat> </infUnidTransp> Olhando o código fonte da unit "\ACBr\Fontes\ACBrDFe\ACBrCTe\PCNCTe\pcteCTeR.pas" nas linhas 1026 e 1032 percebi que está um pouco diferente das declarações para os grupos anteriores acima (InfNF e InfNFe). Na linha 1026 a atribuição a variável "len" está comentada. Na linha 1032 está sendo passada a variável "pos3" como argumento no lugar de "len". //... // len := pos3 - pos2; (Linha 1026) // if (pos1 = 0) and (pos2 = 0) and (pos3 = 0) or (pos1 > pos3) then // qtdRat_UnidTransp := 0.0; if (pos1 < pos3) then qtdRat_UnidTransp := StringToFloatDef(Copy(sAux, pos2 + 8, pos3 -8), 0) // (Linha 1032) else qtdRat_UnidTransp := 0.0; //... Realizei um teste, removendo o comentário na linha 1026 e substituindo a variável "pos03" por "len" como argumento e parou de dar a exceção, além de que o valor ser atribuído corretamente na variável "qtdRat_UnidTransp" (antes ficava zerada). Tem algum motivo das declarações nesse bloco do InfOutros estar diferente do outros grupos (InfNF e InfNFe)? Obs.: Revisão do ACBr utilizada = 34383 Segue em anexo unit modificada com a qual fiz o teste. Obrigado pcteCTeR.pas

Iniciei testes para o CTe 4.0, e ao transmitir tive a rejeição abaixo: <?xml version="1.0" encoding="UTF-8"?> <retCTe xmlns="http://www.portalfiscal.inf.br/cte" versao="4.00"> <tpAmb>2</tpAmb> <cUF>50</cUF> <verAplic>MS_0.0.126</verAplic> <cStat>649</cStat> <xMotivo>Rejeicao: CTe emitido em ambiente de homologacao com Razao Social do destinatario diferente de CTE EMITIDO EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL</xMotivo> </retCTe> Conferindo no anexo I do MOC4.0, realmente está diferente, sem o hífen no "CTE": No MOC da versão 3.0 já é com o hífen: Para conseguir prosseguir com os testes eu alterei a constante "xRazao" lá na unit "pcteConsts", deixando conforme o layout do 4.0 espera: Eu não fiz alteração para anexar aqui, pois nesse caso deve ser pensado em relação à versão 3.0, pois ela também deve ser mantida para compatibilidade. Então deve ser pensada uma maneira melhor para implementação, aqui nessa unit não há acesso à versão do componente que está sendo utilizada para chavear isso, então seria melhor criar outra constante, algo como "XRazao_3" e "xRazao_4"? Implementar direto na escrita do XML e conferir lá a versão?

Bom Dia, Fiz a atualização do AcBr na última sexta-feira 05/04/2024 para a adequação da Sefaz que entraria em vigor na segunda 08/04/2024 e ao rodar meu projeto com o AcBr atualizado, me deparo com o erro '1871 - Element '{http://www.portalfiscal.inf.br/cte}CTe': Missing child element(s). Expected is ( {http://www.w3.org/2000/09/xmldsig#}Signature ).' ao tentar autorizar o CTe. Debugando a aplicação no método Assinar (ACBrCTe.Conhecimentos.Assinar), verifico que até certo momento dentro do método Assinar eu tenho um XML Assinado com todas as tags da assinatura, desde "<Signature> até <KeyInfo> com DigestValue, SignatureValue e X509Certificate porém, eu outro momento, ainda dentro do método, o XML fica sem as assinaturas, finalizando nas tag "</infCTeSupl> </CTe>" e, passando do método Assinar sem erro e, retornando o erro mencionado acima, indo para o método Validar, gerando um XML com erro (segue em anexo). Fico no aguardo de alguma ajuda. Desde já, Obrigado! 50240407811984000130570010000000121000000128-cte.xml

Boa tarde, tentei enviar um cancelamento do evento de insucesso de entrega porém me retornou um erro de preenchimento de UF (Imagem 1), ao checar a lógica de funcionamento, no método DefinirURL da ACBrCTeWebServices, a definição desse campo UF é feita pela lógica considerando a chave do CTe no evento, contudo, o evento de cancelamento do insucesso de entrega não aceita esse atributo (Imagem 2). (Revisão 32096 de 24/01/2024) Atualizei para a revisão 32736 (04/03/2024) e agora retornou erro de "Valor string inválido para TModeloCTe" (Imagem 3), por conta do mesmo método mas ao preencher a propriedade Modelo com base na chCTe, que não é prevista para esse evento, consequentemente iria acabar no primeiro erro se não disparasse a exceção. Seria válido uma correção ou há alguma coisa que estou ignorando ignorando ? Imagem 1 Imagem 2 Imagem 3 Método:

Erro Interno: 0 Erro HTTP: 404 URL: https://homologacao.cte.fazenda.pr.gov.br/cte/CteRetRecepcao <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> <head> <title>Object not found!</title> <link rev="made" href="mailto:%5bno%20address%20given%5d" /> <style type="text/css"><!--/*--><![CDATA[/*><!--*/ body { color: #000000; background-color: #FFFFFF; } a:link { color: #0000CC; } p, address {margin-left: 3em;} span {font-size: smaller;} /*]]>*/--></style> </head> <body> <h1>Object not found!</h1> <p> The requested URL was not found on this server. If you entered the URL manually please check your spelling and try again. </p> <p> If you think this is a server error, please contact the <a href="mailto:%5bno%20address%20given%5d">webmaster</a>. </p> <h2>Error 404</h2> <address> <a href="/">homologacao.cte.fazenda.pr.gov.br</a><br /> <span>Apache</span> </address> </body> </html>

Ao emitir um CT-e ou CT-e OS no XML consta como se estive autorizado o uso, porém estamos recebendo o seguinte retorno "Elemento cteCabecMsg inexistente no SOAP Header", caso eu verifique a situação do documento ele retorna como se estivesse autorizado o uso.

Ao emitir um CT-e está retornando o seguinte erro "Valor string inválido para TLayOutCTe: URL-QRCode".

Bom dia, tudo bem ? Gostaria de saber se já está em desenvolvimento o implemento das novas Tags Valor de ICMS de Desoneração (vICMSDeson) e Código do Benefício Fiscal (cBenef) para envio de CT-e/CTe OS segundo Nota Técnica 2024.001. CTe_Nota_Tecnica_2024_001_v1.01.pdf

Bom dia!! Na versão 4.0 ao realizar a emissão de um CTe para o exterior, é retornado o seguinte erro: 1824 - Element '{http://www.portalfiscal.inf.br/cte}nro': '53' is not a valid value of the local atomic type. A tag(Nro) informada no erro se trata do Numero do endereço do destinatário, na mensagem acima é possível ver que o numero é 53 esta preenchendo a tag nro, e é acusado o erro tentei informar S/N(Sem numero) tentei nullo más a tag não aceita. Consegui realizar a emissão informando 4 dígitos (0053), Por ser uma emissão para o exterior a quantidade de dígito é diferente de uma emissão interna? Geziel Santos.

Bom dia, tudo bom? Estou realizando testes de emissão do CT-e em homologação informando na IE do remetente ISENTO só que não está gerando a tag IE no XML quando informado o literal, somente está gerando quando informamos números, segue print em anexo:

Quando consulto um CTE(autorizado ou estornado) pela chave, recebo o arquivo XML correto, com as tags ordenadas, poarrém após efetiv o Evento da CC-e (que funciona, pois consultando a chave na SEFAZ de Homologação, está vinculado o evento) não recebo o XML corretamento, recebo ele com extensão correta (.xml), mas em formato de texto e sem as tags do XML... A função utilizada é a mesma, inclusive os parametros.. ACBrCte.WebServices.Consulta.Executar, isso retorno como se tivesse dado certo nas duas ocasiões, e o que ACBrCte.WebServices.Consulta.RetWS retorna está sempre correto, só quando o componente vai gravar no disco, se perde. segue retorno da consulta, antes e depois da carta de correção CTE:139 Segue exemplo de outro CTE, sem CC-e mas que foi estornado, usando a mesma função grava corretamente CTE: 136 Aguardo retorno, do motivo de um XML de CCe está gravando deste jeito... 43231111228860000101570000000001391440678540CCE.xml 43231111228860000101570000000001391440678540Original.xml 43231111228860000101570000000001361625013062-sit.xml

Olá, estava verificando os modelos disponiveis de Dactes disponiveis, DACTE_EVENTOS.fr3, DACTE_INUTILIZACAO.fr3, DACTE_OS.fr3, DACTE_PAISAGEM.fr3, DACTE_Retrato.fr3, DACTE2em1A4.fr3 e DACTE2Vias.fr3, nenhum pdf exibiu a chave de acesso do CT-e anterior, ou qualquer outra info de identificação dele. Tambem verifiquei abrindo os fr3 pelo componente FrxReport do Fast Report e não localizei o campo do CT- anterior Existe alguma opção disponivel? ou um modelo ?

Boa tarde, tag dup em desacordo com o MOC. Não aceita mais de um registro. Alterações na classe CobrCTe.cs. dup alterado para lista public List<DupCTe> dup { get; set; } = new List<DupCTe>(); Alterações na classe CT-e.cs: Método WriteToIni for (var i = 0; i < GrupoInformacoesNormalSubstituto.cobr.dup.Count; i++) { var dup = GrupoInformacoesNormalSubstituto.cobr.dup[i]; iniData.WriteToIni(dup, $"dup{i + 1:000}"); } Método ReadFromIni var r = 0; DupCTe dup; do { r++; dup = iniData.ReadFromIni<DupCTe>($"dup{r:000}"); if (dup != null) GrupoInformacoesNormalSubstituto.cobr.dup.Add(dup); } while (dup != null); CobrCTe.cs

Boa tarde, estou com outra situação referente a classe CTe.cs. using (DFeCTe dfe = new DFeCTe()) { dfe.ConfigurarComponente(GlobalVariables.ConfigEstacao.CodConfig); \\ Carrego meu XML no componente dfe.ACBrCTe.CarregarXML("C:\\SGBR\\Master\\Arquivos CTe\\XML\\17089484000190\\202307\\CTe\\42230717089484000190570020000007411944582580-cte.xml"); \\ Carrego o INI do CT-e na minha var string strINI = dfe.ACBrCTe.ObterIni(0); \\ Carrego a classe com base no INI ACBrLib.CTe.CTe CTe = ACBrLib.CTe.CTe.Load(strINI); *Faço algumas alterações no CTe* \\ Carrego a minha classe com algumas alterações como um novo índice dfe.ACBrCTe.CarregarINI(CTe.ToString()); \\ Somente para conferir o retorno da classe string strCTe = CTe.ToString(); \\ Carrega o INI do CTe com as alterações strINI = dfe.ACBrCTe.ObterIni(1); \\ Grava o meu XML com as alterações dfe.ACBrCTe.GravarXml(1, "testelindomar-cte.xml", "C:\\SGBR\\Master\\Arquivos CTe\\XML\\17089484000190\\202307\\CTe\\"); } string strINI - Em um primeiro momento, quando eu obtenho o arquivo INI do meu CTe (Index 0), a tag protCTe está presente no INI(Arquivo em anexo). ACBrLib.CTe.CTe CTe CT-e - Carregando a classe, a classe ProtCTe também está presente (https://prnt.sc/GOR5B7WdibsS). strCTe - Convertendo a classe para string(apenas para verificar se está gerando tudo certo), a classe ProtCTe também está presente. (Arquivo em anexo). strINI(Último).txt - strINI - Obtendo o INI do índice 1, que é o meu CT-e com as alterações carregadas, a tag procCTe não está mais preenchida da forma devida por algum motivo, consequentemente gerando sem a tag no XML, ao utilizar o .GravarXML(). (Arquivo em anexo). Algumas observações a serem feitas: * Todos os arquivos em anexo. * A classe protCTe foi feita por mim, se observarem até no strCTe tem algumas outras classes que fiz para atender nosso desenvolvimento, que vou disponibiliza-las também. * Classe protCTe em anexo. Alterações minhas na classe CTe.cs. Construtor da classe CTe, apenas cria a propriedade ProtCTe: Propriedade declarada: Método WriteToIni() Método ReadFromIni() strCTe.txt strINI(Último).txt strINI.txt 42230717089484000190570020000007411944582580-cte.xml ProtCTe.cs

campo IE do <DocAnt> <emiDocAnt> IE vazio pelo fato do emitente ser pessoa física.

Boa tarde, estou alimentando a classe corretamente, porém ao carregar o INI não está alimentando a classe infCteComp, causando rejeição na hora de enviar(Caso precisem do INI, posso fazer envio por e-mail). Favor, desconsiderar as sections a mais que tem no ini, são aquelas classes que irei repassar para rev para possível implementação, assim que todos os testes com a emissão ocorrerem de forma correta aqui em nosso aplicativo. Libs e fontes do ACBr todas atualizadas. Rejeição no .Validar() Falha na validação dos dados do Conhecimento: 781 TAG:<infCteComp> ID:#411/chCTe(Chave do CTe) - Conte�do inv�lido. TAG:<infCteComp> ID:#411/chCTe(Chave do CTe) - Nenhum valor informado. --> 1839 - Element '{http://www.portalfiscal.inf.br/cte}chCTe': [facet 'pattern'] The value '' is not accepted by the pattern '[0-9]{44}'.