Italo Giurizzato Junior

Bom dia a todos, Já esta disponível em nossa biblioteca a Nota Técnica 2019/001 versão 1.10 que trata sobre novas regras de validação. Essa nova versão é uma complementação da anterior que inclusive o seu resumo se encontra aqui. Resumo da NT:  • Criação/Alteração de regras de validação referentes a CST e Código de Benefício Fiscal, corrigindo algumas regras da versão anterior. • Criação de regra de validação correspondente rejeição 927, para informar os números dos itens em ordem sequencial. • Define que a regra de validação referente ao valor máximo da base de cálculo é por modelo de DF-e. Datas previstas para entrada em vigor: 22/07/2019 - Ambiente de Homologação; 02/09/2019 - Ambiente de Produção. Alterações no componente: Nenhuma, visto que essa NT trata de novas regras de validação a serem implementadas pelas SEFAZ-Autorizadoras. Alterações na aplicação do desenvolvedor: Por conta da regra H02-10, a aplicação ao atribuir o numero do item ao campo: Prod.nItem, este tem que ser um numero sequencial, consecutivo e iniciado por 1. Para quem utiliza o ACBrMonitor, não precisa se preocupar, pois o mesmo utiliza um numero sequencial, consecutivo e iniciado por 1 para o numero do item. Novas Regras de Validação: Criada a Regra de Validação H02-10, com o objetivo de informar os números do item em ordem sequencial. Criadas regras de validação a Tributo - ICMS:  Criada a Regra de Validação N12-86, impedindo que se informe o código de benefício fiscal para CST de benefício fiscal, a critério da unidade federada. Rejeição 928: Informado código de benefício fiscal para CST sem benefício fiscal (campo cBenef) [nItem: nnn] Se informado CST e informado código de benefício fiscal: - Verificar se CST possui código de benefício fiscal, conforme tabela de código de benefício fiscal por UF. Observação 1: Implementação a critério da UF e por modelo de DF-e. Observação 2: Tabela de código de benefício fiscal por UF publicada no Portal Nacional da NF-e. Regras que tiveram seu (Campo-Seq) alterado bem como a sua redação: Regra N07-10 agora é N12-97. Rejeição 929: Informado CST de diferimento sem as informações de diferimento [nItem: nnn] Nova Redação: Não informados campos de valores do CST 51 (Diferimento): - modBC (id: N13), pRedBC (id: N14), vBC (id: N15), pICMS (id: N16), vICMSOp (id: N16a), pDif (id: N16b), vICMSDif (id: N16c), vICMS (id: N17). Observações: Implementação a critério da UF. Regra N12-84 agora é N12-85. Rejeição 930: CST com benefício fiscal e não informado o código de benefício fiscal (campo: cBenef) [nItem: nnn] Nova redação: Se informado CST e não informado código de benefício fiscal: - Verificar se CST exige código de benefício fiscal (tag: cBenef), conforme tabela de código de benefício fiscal por UF. Observação 1: Implementação a critério da UF, por modelo de DF-e e por CST. Observação 2: Tabela de código de benefício fiscal por UF publicada no Portal Nacional da NF-e Regra N12-88 agora é N12-94. Rejeição 931: Informado código de benefício fiscal (campo: cBenef) incompatível com CST e UF [nItem: nnn] Nova Redação: Se informado CST e informado código de benefício fiscal: - Verificar código de benefício fiscal está vigente e corresponde ao CST informado, conforme tabela de código de benefício fiscal por UF. Observação1: Tabela de código de benefício fiscal (cBenef) publicada no Portal Nacional da NF-e. Nota: Para itens sem benefício fiscal, a UF poderá exigir a informação da literal “SEM CBENEF” para alguns CST, vide tabela publicada no Portal Nacional da NF-e.

Boa tarde Luiz, Antes o componente vinha com o valor padrão fgtNunca para a propriedade GerarInfMDFeSupl, agora ela vem com o valor fgtSempre como padrão. Isso explica não ser necessário incluir a respectiva linha. Alias essa propriedade vai ser removida do componente até o final deste mês.

Boa tarde Eduardo, Não estamos mais utilizando o array: TpcnTpEventoString.

Boa tarde Emanuel, O evento em questão ainda não foi implementado.

Boa tarde Allan, Os seus schemas estão desatualizados dai o motivo da mensagem de erro. Por outro lado essa imagem não tem nada haver com o seu problema, ou tem?

Rejeição 688: RNTRC deve ser informado para Prestador de Serviço de Transporte. A rejeição ocorre quando o modal é rodoviário, operação interestadual e tipo de emitente for Prestador de Serviço de Transporte (tpEmit=1) ou Globalizado (tpEmit=3) e o RNTRC não foi informado. Solução: informar o RNTRC. Para quem usa o ACBrMonitor: [infANTT] RNTRC= Registro Nacional de Transportadores Rodoviários de Carga Para quem usa o componente: rodo.infANTT.RNTRC := sRNTRC; // Registro Nacional de Transportadores Rodoviários de Carga

Rejeição 687: RNTRC deve estar associado ao transportador indicado. A rejeição ocorre quando o modal é rodoviário e informado um RNTRC e o mesmo não esta associado ao transportador, a verificação é feita pelo CNPJ-Base. Solução: Informar corretamente o RNTRC associado ao CNPJ-Base do transportador indicado.

Rejeição 684: CIOT obrigatório para RNTRC informado. A rejeição ocorre quando o modal é rodoviário, UF Carregamento e Descarregamento forem diferentes de Exterior e informado RNTRC e este exige o CIOT. Solução: Informar o CIOT. Para quem usa o ACBrMonitor: [infCIOTxxx] onde xxx pode variar de 001 até 999 CNPJCPF= CNPJ ou CPF do responsável pela geração do CIOT CIOT= Código Identificador da Operação de Transporte Para quem usa o componente: for i := 1 to xxx do // onde xxx pode variar de 001 até 999 begin with rodo.infANTT.infCIOT.New do begin CNPJCPF := sCNPJCPF[ i ]; // CNPJ ou CPF do responsável pela geração do CIOT CIOT := sCIOT[ i ]; // Código Identificador da Operação de Transporte end; end;

Rejeição 683: Placa do veículo de tração não vinculada ao RNTRC informado. A rejeição é bem clara, ou o numero do RNTRC não é do veículo informado, ou foi informado a placa de outro veiculo. Solução: corrigir a placa ou o numero do RNTRC.

Rejeição 682: RNTRC situação inválida. Essa rejeição ocorre quando o modal é rodoviário e foi informado um RNTRC e o mesmo pode estar vencido. Solução: Entre em contato com a ANTT nos canais de atendimento para solucionar as pendências. As regras serão aplicadas aos RNTRC do transportador emitente do MDF-e e ao RNTRC do proprietário quando o veículo não pertencer ao emitente do MDF-e .

Rejeição 681: RNTRC informado inexistente. Essa rejeição ocorre quando o modal é rodoviário e foi informado um RNTRC errado. Solução: Informar o numero do RNTRC correto, caso tenha duvidas entre em contato com a ANTT nos canais de atendimento para solucionar as pendências. As regras serão aplicadas aos RNTRC do transportador emitente do MDF-e e ao RNTRC do proprietário quando o veículo não pertencer ao emitente do MDF-e .

Olá pessoal, As validações da ANTT são aplicadas com base na integração entre os sistemas da agência e do ambiente autorizador do MDF-e, em caso de indisponibilidade do serviço de integração, as regras serão desabilitadas até a normalização. Em caso de rejeição, entre em contato com a ANTT nos canais de atendimento para solucionar as pendências. As regras serão aplicadas aos RNTRC do transportador emitente do MDF-e e ao RNTRC do proprietário quando o veículo não pertencer ao emitente do MDF-e O ambiente autorizador do MDF-e que o primeiro paragrafo se refere é a SVRS - SEFAZ-Virtual do Rio Grande do Sul. Só existe uma SEFAZ-Autorizadora, ou seja, responsável por recepcionar e autorizar o MDF-e. Logo todos os MDF-e (não importa a UF do emitente) são enviados para a SVRS.

Bom dia Adilson, Note que a mensagem de erro se refere a uma DLL, é bem provável que a versão da mesma seja antiga logo esta ocorrendo esse erro.

Bom dia a todos, Além de atualizar os fontes, reinstalou os componentes?

Bom dia Christiano, Veja o valor que você atribuiu a CRT. Este campo será obrigatoriamente preenchido com: 1 – Simples Nacional; 2 – Simples Nacional – excesso de sublimite de receita bruta; 3 – Regime Normal. Você informou o valor 1, logo ele vai gerar o grupo ICMSSN, para gerar o grupo ICMS00 o valor de CRT tem que ser 2 ou 3.

Bom dia Emmerson, A tag nova que você se refere é o grupo infMDFeSupl que contem a tag qrCodMDFe, cujo manual foi publicado abril/2019. Fiz as alterações necessárias no componente para que o mesmo gerasse o grupo e a tag conforme orientação contida no manual. Postei uma noticia no dia 14/06/2019 alertando que o ambiente de homologação já estava aceitando o XML com o grupo mencionado acima e que a data para o ambiente de produção passar a aceitar era 15/07/2019. As noticias não ficam na área SAC e sim na área aberta onde todos podem ler. Quem esta passando por problemas de QR-Code tanto em ambiente de homologação quanto de produção é porque não atualiza os componentes com frequência e só entra no fórum quando tem problema, se entra-se para saber se existe alguma noticia nova teria descoberto a novidade e se preparado para realizar os testes em ambiente de homologação e estaria pronto para quando fosse exigido em produção. Agora quanto ao numero do RNTRC consta no manual o seguinte (grifo meu): "As validações da ANTT são aplicadas com base na integração entre os sistemas da agência e do ambiente autorizador do MDF-e, em caso de indisponibilidade do serviço de integração, as regras serão desabilitadas até a normalização. Em caso de rejeição, entre em contato com a ANTT nos canais de atendimento para solucionar as pendências. As regras serão aplicadas aos RNTRC do transportador emitente do MDF-e e ao RNTRC do proprietário quando o veículo não pertencer ao emitente do MDF-e." O ambiente autorizador do MDF-e que se refere ao texto acima é a SVRS - SEFAZ-Virtual do Rio Grande do Sul.

Boa tarde a todos, Na verdade BigWings, quem decide se vai implementar ou não é a SEFAZ-Virtual do RS, pois ela é a única que recepciona todos os MDF-e de todas as UFs.

Boa tarde Luis, Por favor leia a noticia abaixo que publiquei a um mês.

Boa tarde André, O veiculo é do emitente do MDF-e? Se sim, porque você informou o proprietário? Agora se o veiculo não é do emitente do MDF-e, você não deve informar o RNTRC em infANTT, pois este RNTRC é do emitente.