Thiago_Ramos

No MDFe não fiz ainda

arquivos_corrigidos.zip No modal aquaviário, a tag <tpNav> (Tipo de Navegação) é opcional no layout do CT-e — sua ocorrência é 0-1, e não 1-1. Ou seja, o emitente pode legitimamente não informar o tipo de navegação. Comportamento atual: Pelo componente, não há como deixar de gerar a tag: ela sempre sai no XML, no mínimo como <tpNav>0</tpNav> (Interior). Isso porque o tipo aceita apenas dois valores (0/1), sem um estado "não informado" — então a conversão sempre devolve um conteúdo, e a tag acaba sendo sempre escrita. Segue arquivos para consideração do ajuste. Desde já agradeço a atenção.

Registro0040.pasUACBrLCDPR.pas Segue ajuste para consideração. Desde já agradeço.

Tudo certo por aqui, mas o campo continua como inteiro... nos logs não existem modificações disso.

Cliente questionou que no sistema ainda não é possível informar no campo ITR(CAFIR) formato alfanumérico, pois atualmente novos códigos saem nesse padrão. Vi que no leiaute 1.3 do LCDPR esse campo ainda é numerico, mas o validador já foi atualizado no ano passado para aceitar o envio nesse formato. https://netcpa.com.br/noticias/livro-caixa-digital-do-produtor-rural-esta-adaptado-ao-formato-alfanumerico/21759 Observei que isso já foi tratado aqui no fórum: Caracteres Alfanuméricos no CAFIR (Cadastro de Imóveis Rurais) conforme INSTRUÇÃO NORMATIVA RFB Nº 2.203, DE 17 DE JULHO DE 2024 - Outros (ACBrLFD, ACBrSEF2, etc) - Projeto ACBr Porém, os arquivos atualizados não contêm essa modificação.

Certinho Italo, Obrigado!

Prezados, Com base na NT 2025/001 v1.13, identifiquei que: A regra de validação exige a informação da tag <vTotDFe> quando o grupo IBS/CBS estiver presente. O ACBr atualmente não gera a tag quando o valor é 0.00. Isso resulta em Rejeição 360 – Total do DFe de preenchimento obrigatório. Entendimento: A obrigatoriedade está condicionada à existência do grupo IBS/CBS, não ao valor ser maior que zero. Portanto, mesmo com valor 0.00, a tag deve ser gerada. Cenário reproduzido: CT-e de complemento Grupo IBS/CBS informado <vTotDFe> = 0.00 XML gerado sem a tag Rejeição 360 Solicito ajuste para que a tag <vTotDFe> seja gerada sempre que o grupo IBS/CBS estiver informado, independentemente do valor. Segue sugestão de alteração na unit para avaliação. ACBrCTe.XmlWriter.pas

Bom dia! Haverá algum ajuste?

Boa tarde, após procurar com mais calma o motivo, identifiquei a alteração do print abaixo: Para testes, voltei os valores como estavam antes da alteração e voltou a imprimir 3 vias.

Após atualizar o ACBr, ao utilizar o boleto modelo carne no fortes, ao invés de imprimir 3 vias (carnes) está saindo apenas 2. Alguém com o mesmo problema ou ajuda com solução?

Muito obrigado Italo.

Segue unit com ajuste para consideração da correção. ACBrMDFe.XmlWriter.pas

Bom dia! Enfrentei um problema ao realizar a averbação externa de um MDF-e. Ao anexar o documento no sistema da seguradora, foi identificado um erro relacionado à tag <MDFeProc>. Após contato com o suporte, fui informado de que o problema ocorre porque a tag está em letras maiúsculas (<MDFeProc>), enquanto o schema exige que esteja em letras minúsculas (<mdfeProc>). Realizei testes em versões anteriores do ACBr, nas quais a tag é gerada corretamente como <mdfeProc>, conforme as regras da Sefaz. Poderiam, por gentileza, me ajudarem nessa questão? Desde já agradeço.

Vi que a correção foi disponibilizada no SVN ontem dia 21/05 pelo TK-7084. Podem encerrar e obrigado.

Ao gerar o arquivo TXT, o digito 0 no inicio do preenchimento do campo ITR foi desprezado causando erro na transmissão e, ao informar manual no arquivo TXT, foi transmitido sem erros. Procurando entender sobre o problema, verifiquei que o componente utiliza a CAD_ITR como inteiro e, ao fazer o preenchimento do bloco 0040, está fazendo uma conversão para string na linha 328 da UACBrLCDPR.pas. Já que para preencher é utilizado este formato, utilizei a função Format (como é feito no campo COD_IMOVEL) para resolver o problema. Segue arquivo modificado para consideração do ajuste. UACBrLCDPR.pas