Pesquisar na Comunidade

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>

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! 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?

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

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!! 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.

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 ?

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

Bom dia Pessoal, Estou com dúvidas em saber qual UF usar no Campo do cOrgao do evento de desacordo. Minha duvida é qual uf deve mandar a do que esta no emitente do Cte ou de quem esta emitindo o evento ? Exemplo : A Transportador é do PR e envio um Cte a mim que sou de SP, qual será o valor informado ?

Olá, pessoal, após emissão DE CTE em contingência SVRS ontem (26/06/2023), não estou conseguindo cancelar o CTE pelo ACBrMonitorPLUS versão 1.4.0.161 32bits, é retornado o erro em "<chaveCTe>-resp.txt": "ERRO: Nao foi possivel consultar o numero de Protocolo para a Chave: 35230657296543000115570010000435037000631461" Pesquisando vi algumas soluções: "Isso ocorre quando o protocolo do campo nProt difere do protocolo de autorização do CTe. Para resolver esse problema é preciso informar o número de protocolo de autorização correto durante o cancelamento" O problema é que o comando CTE.CancelarCTe só aceita como parâmetros: nChaveCTe: Chave do CTe a ser cancelado nDados: informar Texto de justificativa de cancelamento nCNPJ: Passar esse parâmetro caso queira o CNPJ da empresa quando o cancelamento for por evento! (Opcional) Desde já, obrigado por qualquer ajuda.

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

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

Bom dia, estou tendo alguns problemas quando vou testar a versão 4.00 do CT-e no sefaz de SP. Segue a mensagem de retorno: Alguém passou pelo mesmo problema? Aqui é um exemplo utilizando o link de status do serviço, porém pra emissão está retornando o mesmo erro.

Boa noite! Tenho um Cte que preciso inserir um CTS-60 na Situacao Tributária. Pelo que li no manual isto não é possivel, pois os testes que fiz confirmaram isto. Mas a empresa tomadora, diz que isto é possível e até me enviaram um ct-e, montado assim, cuja imagem esta em anexo. A que puder ajudar, desde meus agradecimentos.

Bom dia estou com este erro ao fazer carta de correção do cte alguém pode me explicar o motivo do erro, e como corrigir??