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

Deu certo Juliomar, muito obrigado

Boa tarde, necessito de um auxílio referente ao campo "Número de sequencial do item" (nSeqAdic), no MOC 7 está com 3 dígitos, porém a NT 2020_005 V1.21 o altera para 5 dígitos - conforme imagens abaixo: Avaliando o componente, identifiquei estes locais que hora pega 3 dígitos, hora pega 5 dígitos: Alguém com a mesma situação? Pois ao informar o campo com mais de 3 dígitos, ocorre erro de schema e falha de pré-visualização do documento.

Boa tarde! Estado MG. A última atualização foi no dia 23/03/24, porém descobri o problema e por algum motivo a diferenciação de CPF/CNPJ da propriedade a ser consultada no componente parou de ser realizada de forma automática, porque antes usávamos a propriedade CPF sem diferenciação de CNPJ/CPF. Para correção, somente passamos a diferenciar essa propriedade, enviando agora ACBrNFeConsulta.WebServices.ConsultaCadastro.CNPJ e ACBrNFeConsulta.WebServices.ConsultaCadastro.CPF. Agradeço a atenção.

Alguém com esse mesmo problema?

Boa tarde, após atualização dos fontes e instalação do acbr, estou tendo problemas na consulta com o seguinte retorno: Falha no esquema XML. Alguém mais com esse problema?