Italo Giurizzato Junior

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Danilo, Ainda não foi incluído e mesmo que tivesse ainda não iria funcionar pois o ambiente de homologação só vai estar liberado no dia 22/07/2019 para recepcionar CT-e com a string do QR-Code.

Bom dia Luiz, Lembre-se que só podemos imprimir no DACTE o que consta no XML, se a tag não existe mais, o único jeito é você colocar essa informação no campo de observação. Desta forma será impresso no DACTE com certeza.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde George, Você identou o XML para poder anexar aqui no fórum ou gera ele identado e com quebra de linhas? O XML não pode ter quebra de linhas e muito menos identado.

Boa tarde Asterix, Favor anexar o XML do MDF-e e o seu retorno que contem a rejeição.

George, Como você utiliza o ACBrMonitor, favor anexar o arquivo INI que a sua aplicação gera bem como o XML gerado pelo Monitor. Para que possamos analisar melhor esse problema.

Boa tarde Hélio, Se não me falha a memória no certificado só temos a razão social e o CNPJ.

George, Quando foi essa ultima atualização?

Jeanny, Como lhe disse não trabalho com o Fast Report, a sua alteração foi apenas a inclusão do QR-Code ou você fez mais alterações visando deixa-lo em conformidade com o manual?

Boa tarde Luiz, Tente da seguinte forma: Configuracoes.WebServices.Visualizar := False;

George, Você esta com todos os Schemas do MDF-e atualizados?

Bom dia Jeanny, Toda colaboração é bem vinda. Como não trabalho com o Fast Report vou passar para o pessoal que o conhece para analisar. Desde já muito obrigado pela colaboração.

Bom dia George, O XML que você anexou tem tanto a UF do veiculo quanto do proprietário, o XML é esse mesmo que esta com erro de validação?

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.