Painel de líderes

Foi detectado um problema com a configuração fgtSempre caso informada diretamente no componente via object inspector, problema resolvido ontem mesmo na revisão 17317. Se a sua revisão está anterior a essa, atualize novamente os fontes. Configurando via código como você deixou entender, não deveria acontecer, entretanto. Então atualize novamente os fontes e teste, se ainda tiver problemas informe o passo a passo para reprodução.

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 utilizando a consulta publica de RNTRC verifiquei que o CNPJ do cliente não estava vinculado ao RNTRC. Testei com outro CNPJ do mesmo cliente que estava vinculado e a emissão funcionou normalmente. https://consultapublica.antt.gov.br/Site/ConsultaRNTRC.aspx/ConsultaPublica/

Bom dia @José M. S. Junior fiz conforme me orientou e retirei o O, está funcionado corretamente agora, Obrigado a aquipe ACBr.

Pessoal, Existem diversas regras de validação que são aplicadas pela SVRS dependendo se o emitente for Transportadora ou Transportador de Carga Própria, se o veiculo é do emitente ou de terceiros e assim vai. A minha sugestão é que vocês acessem a nossa biblioteca e baixe se desejar os manuais mais recentes do MDF-e. http://svn.code.sf.net/p/acbr/code/tools/DFe/MDFe/Manuais/ As regras de validação se encontram no: Manual MDFe Visao Geral v3.00a O layout do XML do MDFe no: Manual MDFe Anexo I Leiaute v3.00a No que se refere ao numero do RNTRC, leiam o texto abaixo que consta logo abaixo as regras de validação contidas no manual (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 o texto se refere é a SVRS - SEFAZ-Virtual do Rio Grande do Sul.

Bom dia, foi adicionado mais um parâmetro para envio no modo Síncrono está em fase de homologação, Não envie o ultimo parâmetro como 0 por enquanto. Este parâmetro vai realizar o envio Síncrono... MDFE.ENVIARMDFe(nXMLMDFe, [nLote], [nAssinar],[nImprimi],[nImpressora], [bAssincrono] )

Boa tarde, Veja neste tópico do @Italo Jurisato Junior que a impressão do QRCode será exigida somente em outubro/2019. Att.

De fato, É uma boa notícia. segue link: https://www.confaz.fazenda.gov.br/legislacao/ajustes/2019/ajuste-sinief-11-19

Vejam se ajuda. Observem que o CNPJ é da Transportadora emitente e não é informado seu RN TRC, apenas o de terceiro, ou seja, Se o veiculo for da transportadora voce informa os dados da mesma com seu RNTRC, se ela aluga veiculo de terceiros para o transportes voce deve informar os dados do proprietário do veiculo que pode ser física ou jurídica. Ontem tive este problema porque estavam com o RNTRC vencido ou usando de outros, fiz assim e resolveu.

Boa tarde @BigWings, fiz a atualização novamente tirei a configuração do componente via object inspector de "fgthomologacao" e coloquei "fgtSempre" pra fazer o teste e funcionou normalmente. Revisão 17322. Foi feito a atualização via SVN update e reinstalei os componentes via Instalador ACBr, parece esta tudo em ordem agora. Muito Obrigado pela ajuda.

Realmente acabei anexando o XML incorreto, peço desculpas... amanhã irei verificar remotamente em meu Cliente e averiguarei sobre a questão do Ambiente. Independente do resultado, comunico aos senhores. Desde já obrigado.

16/07/2019 - ATENÇÃO: Publicada a versão 1.10 da NT 2019.001 Publicada a versão 1.10 da NT 2019.001, que divulga novas regras de validação e atualiza regras existentes da NF-e/NFC-e versão 4.0, com os seguintes objetivos: Criação/Alteração de regras de validação referentes a CST e a 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. Assinado por: Coordenação Técnica do ENCAT Link: http://www.nfe.fazenda.gov.br/portal/informe.aspx?ehCTG=false&Informe=ScmzxWjpJe8=

Olá pessoal, Quem atualizou os fontes e reinstalou a Suite ACBr, pode ser que esteja recebendo essa mensagem de erro no momento que vai gerar a NF-e / CT-e / MDF-e / BP-e. Porque esta mensagem esta aparecendo para alguns e para outros não? Simples, quando o XML é gerado com base em alguns dados do documento fiscal é gerado a chave do mesmo. Essa mensagem de erro é devido a uma validação que foi implementada na função que gera a chave. Essa validação visa garantir que a sua Nota (por exemplo) não seja rejeitada pela regra de validação B03-10 que consta na Nota Técnica 2019/001. Como vocês podem ver na imagem acima, a aplicação dessa regra é obrigatória, ou seja, todas as SEFAZ-Autorizadoras devem implementar essa regra. Ela será implementada no dia 01/07/2019 no ambiente de Homologação e no dia 02/09/2019 no ambiente de Produção. A validação que foi implementada ao gerar a chave é exatamente a descrita na regra, ou seja, o valor de cNF não pode ser igual a nNF e a nenhum dos números listados na regra. Por curiosidade resolvi pegar o Manual da NF-e mais antigo que tenho (Março de 2009) veja o que esta escrito na definição do campo cNF: O Manual deixa claro que o numero atribuído a cNF tem que ser um numero aleatório. Portanto quem costuma atribuir a cNF o mesmo numero atribuído a nNF esta fazendo errado e agora não vai ter perdão, pois se insistir a SEFAZ não vai aceitar a nota. Mas a regra B03-10 da Nota Técnica 2019/001 não se refere apenas a NF-e / NFC-e? Sim, mas tenham certeza que essa regra de validação em breve vai ser implementada para os demais DF-e - Documentos Fiscais Eletrônicos. Alguém duvida disso? O que devo fazer para que a minha aplicação não pare com a mensagem de erro: Código Numérico inválido, Chave não Gerada ? Muito simples, vou dar como exemplo o fragmento de código da minha aplicação: Como é hoje, note que eu já gerava o código como sendo um numero aleatório: NotaFiscalVenda := (DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := Random(99999999) + 1; // +1 para garantir que não seja zero Como vai passar a ser, para ter uma garantia maior ainda: NotaFiscalVenda : =(DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := GerarCodigoDFe(NotaFiscalVenda); A função GerarCodigoDFe esta definida na Unit ACBrDFeUtil, logo você vai ter informar essa Unit em Uses do seu Form. Note que ela recebe como parâmetro o numero da nota, pois a função vai gerar o código aleatoriamente e vai validar o mesmo e pela regra o código não pode ser igual ao numero da nota. De forma semelhante você terão que fazer o mesmo nas suas aplicações que emitem CT-e, MDF-e e BP-e. É preferível fazer essa correção na aplicação agora do que receber dezenas ou até centenas de ligações de clientes que não estão conseguindo autorizar os seus documentos na SEFAZ. Fica ai a dica.

Boa Tarde! Fiz a implementação do tipo CAEPF no AcbrValidador. Se julgarem interessante segue... ACBrValidador.rar

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Fiz algumas alterações porque o arquivo parecia que não estava atualizado e porque o tipo enumerado estava sendo adicionado no meio. Sempre é melhor adicionar no final. Subi as alterações para o SVN na Revisão 17325. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Muito obrigado pela contribuição. Subi as alterações para o SVN na Revisão 17324. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Identifiquei o erro: um dos produtos estava indo com um valor na tag: vOutro com: 0.01 centavos.

Teoricamente, todas as UFs deveriam informar isso no site do ENCAT aqui http://nfce.encat.org/desenvolvedor/regras-de-validacao/ Mas nem sempre essa tabela está atualizada. Por isso você deve se informar em cada UF que você atende...

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

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.

Se não me engano quando a configuração Arquivos.EmissaoPathNFe está False o ACBr usa a data atual da máquina para determinar a pasta a salvar. Então se a data do PC estava em Julho isso seria possível.

bom dia.. tem como mandar os xml anexado aqui para analise. valeu

Transportadora Italo, pelo que estou entendendo é : MDFe sera REJEITADO QUANDO : - CÓDIGO RNTRC da Transportadora emitente de MDFe não estiver associado ao CNPJ da mesma. - PLACA veiculo terceiro contratado : Dados informados no quadro do proprietário do veículo. No quadro do proprietário do veículo, informado o nro RNTRC e o CPF do condutor não associado ira rejeitar. CODIGO RNTRC do proprietario deve estar devidamente associado ao CPF ou CNPJ . Isso pode ser verificado no site da ANTT, no link https://consultapublica.antt.gov.br/Site/ConsultaRNTRC.aspx/consultapublica OU PELO FONE 166 O que vocês devem fazer é informar o RNTRC vinculado ao CPF do proprietário do veículo ou CNPJ do proprietário do veiculo. REFORÇANDO AGORA, Antt do proprietário , tem que estar de acordo com o registro da ANTT para que seja autorizado MDFe, inclusive se informar o CPF de um condutor que não pertencer ao proprietário do veiculo como funcionário registrado , o SEFAZ ja informou que pode atuar como transporte irregular. se for carga própria, retire a tag infANTT, mas vc nao pode definir o tipo do transportador qdo carga propria

Está selecionando para realizar a instalação completa ao instalar o ACBrMonitor? está versão 1.2.0.70 já deve atualizar atualizar a URL no arquivo ACBrMDFeServicos.ini

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Muito Obrigado, Entendi a Sintaxe e consegui sanar o problema, fiz vários testes e deu certo. Att.,

Já que o veiculo não é do emitente do MDF-e, informe os dados do proprietário do mesmo e não informe o RNTRC em infANTT.

Boa tarde Italo, Consegui identificar o erro, o RNTRC do emitente estava vencido, e estava sendo informado o do proprietário do veiculo no lugar. Muito obrigado

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 a todos, recebi um comunicado de um contador hoje falando sobre algumas mudanças que saíram no DOU do dia 12/07. No site da confaz, procurem os ajustes sinief de 10 a 14 de 2019, teremos alterações entre outras coisas, pelo que eu entendi, o fim do CSOSN, foram criados novos códigos CST do icms para atender o simples nacional.

Boa tarde. Obrigada por compartilhar a informação. Att.

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

Ok. Agora passou e não ocorreu o erro. Mas não imprimiu o QR Code, seria para imprimir?

Ok. Agora sim, imprimindo diretamente.

Boa Tarde José! Obrigado pelo Retorno! Resolvido conforme sua orientação. Muito Obrigado!

Aqui utilizamos apenas o nosso numero gerado pelo nosso software. Desconsideramos totalmente o dígito validador. Deve ser o caso que o @Dercide Alvarez explanou. O dígito é mera formalidade.

Favor realizar testes com a versão 1.2.0.70.

Boa tarde a todos, O componente ACBrCTe tem uma propriedade de configuração chamada: GerarInfCTeSupl que pode receber os seguintes valores: fgtNunca = não vai gerar no XML o grupo InfCTeSupl que contem a string do QR-Code; fgtSomenteProducao = só gera se o componente estiver configurado para o ambiente de Produção; fgtSomenteHomologacao = só gera se estiver configurado para o ambiente de Homologação fgtSempre = vai gerar no XML o grupo InfCTeSupl. O valor padrão é fgtNunca, mas a partir do dia 22/07/2019 para realizar testes no ambiente de homologação essa propriedade deve estar com o valor fgtSomenteHomologacao. E a partir do dia 26/08/2019 para o envio em ambiente de produção a propriedade devera esta com o valor fgtSomenteProducao ou fgtSempre. Quando se tornar obrigatório em ambos ambientes iremos remover essa propriedade de configuração do componente.

Boa tarde a todos, O componente ACBrMDFe tem uma propriedade de configuração chamada: GerarInfMDFeSupl que pode receber os seguintes valores: fgtNunca = não vai gerar no XML o grupo InfMDFeSupl que contem a string do QR-Code; fgtSomenteProducao = só gera se o componente estiver configurado para o ambiente de Produção; fgtSomenteHomologacao = só gera se estiver configurado para o ambiente de Homologação fgtSempre = vai gerar no XML o grupo InfMDFeSupl. Essa propriedade em breve vai deixar de existir, uma vez que a exigência em ambos os ambientes já foi ativada pela SEFAZ.

Estamos nos organizando por aqui... devemos ter novidades, ainda essa semana...

Inicio do post estava pedindo qual os modelos das DATAREGIS IF 375-ep e if 4000 - ep que funciona perfeitamente no acbr usava ele para testes antes de entrar as MFD

Boa tarde! Muito obrigado a todos pela ajuda. BigWings, sua ajuda bateu na trave, mas sem ela, eu não teria conseguido. Eu desmarquei a opção "Use designer guidelines" e os componentes pararam de se movimentar ao clicar. Obrigado, Rogério.

Boa tarde. Alteração disponível no svn. Att.

Gilvano, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia! Não conseguirá porque o XML não estará autorizado com o retorno 105. (Não tem protocolo de autorização). Após uma consulta e autorizado (retorno status 100), ai sim o XML estará com a autorização.

Na maioria dos casos este erro é devolvido quando a informação do CSC ou do IdCSC está incorreta. Ao receber esta rejeição o primeiro passo é verificar se os valores informados para o IdCSC e CSC estão corretos, coincidindo com os valores fornecidos pela SEFAZ respeitando traços, acentuações e caracteres tanto maiúsculos quanto minúsculos. Lembrando que existem valores diferentes para cada ambiente(homologação/produção). Então se estiver usando o CSC fornecido para homologação no ambiente de produção, também vai receber esta rejeição. No ACBrNFe, informe: ACBrNFe1.Configuracoes.Geral.IdCSC := IdCSC; ACBrNFe1Configuracoes.Geral.CSC := CSC; ACBrMonitorPLUS, informe: NFe.SetIdCSC(IdCSC, CSC)

E nesta pasta "c:\ACBrMonitorPLUS\Logs" vc verificou se o xml (ainda não autorizado) se encontra ai? Na resposta do comando do ACBrMonitorPLUS não aparece algo assim "OK: c:\ACBrMonitorPLUS\Logs\chavedasuanota-nfe.xml" ??