DATAC

Ok. Agora sim, imprimindo diretamente.

Na verdade citei o ambiente de homologação. Só percebi na homologação mesmo, em produção a principio não ocorreu essa exigência ainda, que deverá ser em 07/10/2019. Mas gostaria que fosse disponibilizada a atualização no Monitor para que possamos fazer testes.

Boa dia. Hoje ao emitir um MDF-e em homologação ocorreu uma rejeição no ACBrMonitor: [Retorno] CStat=480 CUF=43 ChMDFe= MotivoMDFe= Msg=Manifesto(s) não confirmado(s): 51->480-Rejeição: O QR Code do MDF-e deve ser informado NProt= NRec=439000007000516 TpAmb=2 VerAplic=RS20190715104004 Versao=RS20190715104004 XMotivo=Rejeição: O QR Code do MDF-e deve ser informado Minha versão está atualizada é a 1.2.0.69. O que precisaria ser feito? Alguma configuração no Monitor?

Sim. Na versão 1.2.0.60 funcionava normalmente.

Bom dia. Ao emitir um MDF-e, não está mandando para a impressora padrão por default como sempre fez nas versões anteriores do Monitor. Mesmo deixando em branco o local para definir a impressora padrão, antes a impressão era diretamente encaminhada para padrão do Windows até esta atualização da versão. (Imagem anexada). Sempre que é enviado uma impressão de um DAMDFe, fica parado em uma tela aguardando selecionar a impressora em uma janela de seleção por trás do aplicativo, isso não ocorria em versões anteriores. Versão atual usada : ACBrMonitor PLUS 1.2.0.69.

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. Fonte:https://dfe-portal.svrs.rs.gov.br/Mdfe/Avisos/137

Em relação ao Leiaute do MDF-e, pelo que observei no manual não haverá nenhuma mudança para se fazer no arquivo .INI que é enviado ao ACBrMonitor, correto?

Mais informações sobre o CT-e em :

Certo, isto já ajudaria bastante. Obrigado.

Boa tarde. No caso não teria como fazer essa distinção no momento, porque o comando que utilizamos para todas as notas é de envio já com impressão: "NFe.EnviarNFe(c:\acbrnfe\nfe\43190593274700000071550000001161651750395482-nfe.xml,116165,1,1,Printer)" Neste caso agradeço se puder verificar com o pessoal a possibilidade de existir uma propriedade forçando a Mensagem, com você citou. Obrigado.

Bom dia. Notei que de algum tempo para cá as NF-es que foram denegadas na Sefaz estão sendo impressas após serem enviadas, o que não ocorria anteriormente se não me engano. Neste caso é indicada a mensagem "NF-e DENEGADA" no topo da nota em cima do código de barras e somente naquele local tem esta distinção (anexo imagem). Acredito que esta mensagem de denegada poderia ser mais destacada ou colocada sobrepondo todo corpo da nota de forma bem visível ou também ter opção de não imprimir a Danfe nesse caso, para não gerar engano ou algum erro e a Danfe ser entregue ao cliente erradamente.

Olá. Está ok. Funcionou corretamente nesta versão. Obrigado.

Boa tarde. Um adendo ao tópico. O mesmo problema ocorre para o comando de impressão do evento Carta de Correção: NFe.ImprimirEvento(C:\NE\201905\1101104319050017748300010255000000000000181532972701-ProcEventoNFe.xml,C:\NE\201905\43190500177483000102550000000000001815329727-nfe.xml) No aguardo.

Já atualizado no RS em produção, funcionando ok.

Certo. No log do ACBrMonitor ficou assim: NFe.ImprimirEvento(C:\NE\201905\1101114319059327478500017155000000003107195093927001-ProcEventoNFe.xml,C:\NE\201905\43190593274785000171550000000031071950939270-nfe.xml) OK: Evento Impresso com sucesso ACBr MonitorPLUS Ver.1.2.0.57 Aguardando comandos ACBr *Observo novamente que até a última versão que estava usando aqui (1.2.0.19) o comando era o mesmo e não ocorria o problema.

Bom dia. Ao imprimir um evento para NF-e, como por exemplo um cancelamento, não está mandando par a impressora padrão por default como nas versões anteriores do Monitor. Mesmo deixando em branco o local para definir a impressora padrão, antes a impressão era diretamente encaminhada para padrão do windows até esta atualização da versão. (Imagem anexada). Sempre que é enviado uma impressão de evento de cancelamento por exemplo, fica aguardando selecionar a impressora em uma janela de seleção por trás do aplicativo, isso não ocorria em versões anteriores. Versão atual usada : ACBrMonitor PLUS 1.2.0.57.

Bom dia. Este problema não está diretamente ligado à atualização da versão do ACBr mas sim porque a Sefaz está fazendo valer uma regra já existente a algum tempo na NT 2016.002. Essa regra começou a ser aplicada no ambiente de homologação no dia 22/04, e vai ser aplicada no ambiente de produção a partir do dia 20/05. Essa regra de validação é opcional por estado. Isso significa que cada estado pode decidir se aplica ou não essa regra de validação. Como já foi visto aqui no tópico a última compilação do ACBrMonitor PLUS já está correta de acordo com as regras, só teria que atualizar para esta última versão. Ou alterar o arquivo ACBrNFeServicos.ini com os endereços corretos.

Certo, portanto a próxima versão do ACBrMonitor Plus do SAC já estará com essas mudanças?

Bom dia. Segundo essa informação do Daniel já tem prazo:

Bom dia. Este "novo" prazo para validação em produção (20/05/2019) saiu em alguma nota técnica? Está divulgado no site da Sefaz?

Boa tarde. Em produção está funcionando sem nenhuma alteração (no RS), seria um caos se essa validação fosse aplicada em produção (toda emissão de NFC-e iria parar). Não tem cabimento a Sefaz cobrar esse tipo de validação, até porque até hoje estava tudo certo, se não é para ir o "http" no endereço teria que cobrar desde o inicio na NT lá em 2018.

Boa tarde. Só alterei nesta chave "[NFCe_RS_H]" e funcionou em homologação. [NFCe_RS_H] ... URL-ConsultaNFCe_2.00=www.sefaz.rs.gov.br/nfce/consulta Apenas tenho dúvida se isto irá ficar assim mesmo e também se vai alterar na produção ou se irá voltar o endereço anterior?

Seria somente para homologação? Para o ambiente de produção continua como antes? Até porque não está dando erro em produção até o momento.

Certo. Aqui no RS em função do Decreto 54.308 isto está ainda muito confuso. A principio pensei que fosse preciso informar sempre tais tags mas aparentemente até o momento não.

Ok. entendi, como não são exigidas as tags não são geradas. Como elas estava sendo geradas em versão anterior, pensei que teria algum problema nesta versão. Mas agora, acredito que esteja coreto, seguindo as regras de validação.