Ir para conteúdo
  • Cadastre-se

Painel de líderes

Conteúdo popular

Showing content with the highest reputation on 16-07-2019 em Posts

  1. 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.
    4 pontos
  2. 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.
    4 pontos
  3. 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/
    3 pontos
  4. De fato, É uma boa notícia. segue link: https://www.confaz.fazenda.gov.br/legislacao/ajustes/2019/ajuste-sinief-11-19
    3 pontos
  5. 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.
    2 pontos
  6. 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.
    2 pontos
  7. 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=
    1 ponto
  8. 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.
    1 ponto
  9. Boa Tarde! Fiz a implementação do tipo CAEPF no AcbrValidador. Se julgarem interessante segue... ACBrValidador.rar
    1 ponto
  10. 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.
    1 ponto
  11. Prezados, problemas identificado. resumindo: - os cadastros do RNTRC do emitente tem que está válido. - o emitente que não tem RNTRC, informar somente o RNTRC do veiculo/condutor como ja dito por alguns. Obrigada a todos!
    1 ponto
  12. Na impressão do boleto usando Fast Report (unit ACBrBoletoFCFR), a logo do banco é carregada sempre pelo diretório de logos, através do método ImprimeLogoMarca. Anexei a unit com as alterações para chamar o método CarregaLogo da TACBrBoletoFCClass no ImprimeLogoMarca, com o objetivo de disparar primeiro o evento OnObterLogo e, se não tratado, daí carregar a imagem do diretório de logos. Olhei os fontes da impressão usando Fortes Report e lá é usado o CarregaLogo. ACBrBoletoFCFR.pas
    1 ponto
  13. 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.
    1 ponto
  14. Identifiquei o erro: um dos produtos estava indo com um valor na tag: vOutro com: 0.01 centavos.
    1 ponto
  15. 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...
    1 ponto
  16. No Painel de Monitoramento http://www.nfce.se.gov.br/portal/painelMonitor.jsp consta como Serviço Paralisado Temporariamente, na SEFAZ Virtual, está instável sim, desde manhã
    1 ponto
  17. 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.
    1 ponto
  18. 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;
    1 ponto
  19. 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.
    1 ponto
  20. 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 .
    1 ponto
  21. 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 .
    1 ponto
  22. 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.
    1 ponto
  23. Bom dia a todos, Além de atualizar os fontes, reinstalou os componentes?
    1 ponto
  24. 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.
    1 ponto
  25. 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.
    1 ponto
  26. bom dia.. tem como mandar os xml anexado aqui para analise. valeu
    1 ponto
  27. Muito Obrigado, Entendi a Sintaxe e consegui sanar o problema, fiz vários testes e deu certo. Att.,
    1 ponto
  28. 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
    1 ponto
  29. 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.
    1 ponto
  30. 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.
    1 ponto
  31. Boa tarde. Obrigada por compartilhar a informação. Att.
    1 ponto
  32. Boa tarde Luis, Por favor leia a noticia abaixo que publiquei a um mês.
    1 ponto
  33. Boa tarde a todos, Tenham em mente que se tratando de MDF-e só existe uma SEFAZ-Autorizadora, ou seja SVRS - SEFAZ-Virtual do RS. Não interessa de qual UF é o emitente do MDF-e, todos os MDF-e de todos os Estados brasileiros são enviados para a SVRS.
    1 ponto
  34. Boa Tarde José! Obrigado pelo Retorno! Resolvido conforme sua orientação. Muito Obrigado!
    1 ponto
  35. 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.
    1 ponto
  36. Boa Tarde, a Todos Também estava com esse problema, mas resolvi da seguinte forma: rodo.infANTT.RNTRC := 'numero RNTRC' ; desta forma não deu mais esta rejeição. Abraços
    1 ponto
  37. 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.
    1 ponto
  38. Implantação da versão 3.00a em Homologação Foi implantada a versão 3.00a do MDF-e na SVRS no ambiente de homologação às 13h30min do dia 14/06/2019. A versão de produção deverá ser implantada no dia 15 de julho de 2019. O componente ACBrMDFe já contempla essa nova versão. Esta faltando fazer o novo DAMDFE que vai conter além do código de barras o QR-Code, mas o novo DAMDFE só vai passar a ser exigido a partir de outubro de 2019. Comunicado sobre as datas de implantação da versão 3.00a Comunicamos que foi publicado a versão 3.00a do Manual de Orientação do Contribuinte do MDF-e e seus anexos. Reforçamos que esta nova versão prevista para entrar em homologação a partir do dia 14 de junho de 2019 e em produção a partir do dia 15 de julho de 2019, contempla a atualização do schema do MDF-e dentre outras modificações. Relativamente à definição dos padrões do QRCode previstos no arquivo XML do MDF-e, cuja especificação das configurações para impressão no DAMDFE estão detalhadas no Anexo II – Manual de Especificações Técnicas do DAMDFE, serão implementadas a partir de 07 de Outubro de 2019, quando entrará em vigor a obrigatoriedade de exibição do QRCode no layout do DAMDFE. Da mesma forma, as RV (regras de validação) G096 a G101 passarão a ser aplicadas em 01/07/2019 no ambiente de homologação e somente em 07 de Outubro de 2019 no ambiente de produção. Em nossa biblioteca você encontram os 3 Manuais (Visão Geral, Layout e DAMDFE) da versão 3.00a clique aqui para ter acesso.
    1 ponto
  39. 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.
    1 ponto
  40. Estamos nos organizando por aqui... devemos ter novidades, ainda essa semana...
    1 ponto
  41. 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
    1 ponto
  42. É a configuração dos dados da porta serial. Geralmente esta balança a configuração é : BAUD=9600 DATA=7 PARITY=E STOP=2 Arquivo de Log: -------------------------------------------------------------------------------- ATIVAR - 11/07/19 15:29:45:566 - Modelo: Toledo 9091 - Porta: COM1 Device: BAUD=9600 DATA=7 PARITY=E STOP=2 HANDSHAKE= MAXBANDWIDTH=0 SENDBYTESCOUNT=0 SENDBYTESINTERVAL=0 -------------------------------------------------------------------------------- - 15:29:45:775 RX <- [STX]+p`000068000000[CR] UltimoPesoLido: 6,8 - Resposta: [STX]+p`000068000000[CR]
    1 ponto
  43. 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.
    1 ponto
  44. Boa tarde. Alteração disponível no svn. Att.
    1 ponto
  45. Bom dia! Experimente ir em configuração. Opção DFe - Impressão - NFC-e Aonde aparece Margens: Inferior - Superior - Direita - Esquerda - Largura [ ] <<-- Experimente aqui colocar tamanhos entre 280 a 300 e vai ajustando. Veja se muda alguma coisa.
    1 ponto
  46. Gilvano, Muito obrigado pela colaboração, já enviei para o repositório.
    1 ponto
  47. 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.
    1 ponto
  48. 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)
    1 ponto
  49. 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" ??
    1 ponto
  50. Boa tarde! Veja se a opção [v] Salvar Arquivos Enviados/Recebidos p/WebServices está setada.
    1 ponto
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.