Sergio Tucano Clemente Da Silva Filho

Recebi isso, hoje, da SEFAZ RJ : Sobre as séries exclusivas para NFC-e, em está em discussão nacional a prorrogação desta exigência atribuída pelo Ajuste, inclusive ainda não há uma data para a inclusão desta regra no ambiente de homologação nem produção. Atenciosamente, Coordenadoria de Documentos Fiscais Eletrônicos Secretaria de Estado de Fazenda e Planejamento do Rio de Janeiro As dúvidas esclarecidas por meio desta mensagem têm caráter de simples orientação, não produzindo os efeitos do instituto denominado Consulta Tributária, definido pelos artigos 150 a 165 do Regulamento do Processo Administrativo Tributário, Decreto Estadual nº 2.473/79.

Só para deixar um feedback , recebi esta resposta da SEFAZ RJ: Prezado, sobre a a NFC-e com chave de acesso 33190331366231000147650120002407191002407198 encontra-se cancelada, basta clicar em "Consulta Completa", note o evento "Cancelamento por substituição" na linha de "Eventos da NF-e". Sobre as séries exclusivas para NFC-e, em está em discussão nacional a prorrogação desta exigência atribuída pelo Ajuste, inclusive ainda não há uma data para a inclusão desta regra no ambiente de homologação nem produção. Atenciosamente, Coordenadoria de Documentos Fiscais Eletrônicos Secretaria de Estado de Fazenda e Planejamento do Rio de Janeiro As dúvidas esclarecidas por meio desta mensagem têm caráter de simples orientação, não produzindo os efeitos do instituto denominado Consulta Tributária, definido pelos artigos 150 a 165 do Regulamento do Processo Administrativo Tributário, Decreto Estadual nº 2.473/79.

pois é. enviei um e-mail e vamos aguardar a resposta. Mas se alguém já souber de algo, pode postar aqui... A propósito, segue o retorno do evento. inf_evento.xml

Bom, aparentemente, resolvi o erro da rejeição 920. Corrigi para ele pegar a chave corretamente da NFC-e referenciada, este era o problema do 920. Só que agora, ele me retorna 135, porém, ao consultar na sefaz do RJ a nota não consta como cancelada. Estou enviando o xml da nota que foi cancelada e da nota de contingencia que foi enviada. nota_canc.xml nota_off.xml

Fiz isso. Emiti a NFC-e 1 deu erro de webservice. Emiti a NFC-e 2 offline. Retornou webservice. Enviei a NFC-e 2. Cancelei a NFC-e 1 passando a chave da 2. Retornou erro 920.

Boa ! Estou tendo o retorno 920: Rejeição : Tipo de Emissão inválido no cancelamento por substituição. O que encontrei no fórum a respeito não me ajudou a resolver o problema, alguém poderia me dar uma luz? 1 : Emito a nota de contingência em ambiente offline. 2 : Após o retorno da comunicação cancelo a nota (aqui entram as modificações da nova norma técnica para cancelamento). 3: Envio uma nova nota substituindo a nota cancelada. O retorno é sempre o 920. Valeu!

Boa ! Notei que ao realizar uma venda com acréscimo o Acréscimo sobre SubTotal está sendo impresso com sinal de negativo - . Fiz a correção no .pas e estou enviando para vocês. Valeu ! ACBrSATExtratoESCPOS.pas

Resolvido aqui. Erro meu.

Boa ! Foi não Italo... o ACBREFDBLOCOS está assim : /// Versão do Leiaute do arquivo - TRegistro0000 TACBrCodVer = (vlVersao100, // Código 001 - Versão 100 Ato COTEPE 01/01/2008 vlVersao101, // Código 002 - Versão 101 Ato COTEPE 01/01/2009 vlVersao102, // Código 003 - Versão 102 Ato COTEPE 01/01/2010 vlVersao103, // Código 004 - Versão 103 Ato COTEPE 01/01/2011 vlVersao104, // Código 005 - Versão 104 Ato COTEPE 01/07/2012 vlVersao105, // Código 006 - Versão 105 Ato COTEPE 01/07/2012 vlVersao106, // Código 007 - Versão 106 Ato COTEPE 01/07/2013 vlVersao107, // Código 008 - Versão 107 Ato COTEPE 01/07/2014 vlVersao108, // Código 009 - Versão 108 Ato COTEPE 01/07/2015 vlVersao109, // Código 010 - Versão 109 Ato COTEPE 01/07/2016 vlVersao110, // Código 011 - Versão 110 Ato COTEPE 01/01/2017 vlVersao111 // Código 012 - Versão 111 Ato COTEPE 01/01/2018 ); TACBrVersaoLeiaute = TACBrCodVer;

Boa ! Deu um update aqui nos fontes e TACBrCodVer não consta o novo layout 1.4, ´ultimo é o do inicio de 2018 ...

Ambiente de homologação do RJ começou a dar erro, a partir de 01/10, na versão do QRCODE 100. Mudar no componente compila com erro, no codigo como o André indicou com veqr200, foi.

Certo, entendi esta parte. inclusive tentei alterar no fonte do ACBr para ele enviar com mais casas decimais e o SAT retornou erro. Enfim, o que você quer dizer é que para esses casos a solução é mesmo eu tratar a qCom antes de enviar ao ACBr, certo?

Não sei se não estou conseguindo me fazer entender. Preço 9,654 (3 decimais) Qtd (5,1792) (4 decimais truncados) Este valor nunca terá como resultado 50,00 Para ser 50, a quantidade deveria ser 5,179200331468821 ( o que é impossível de passar já que o ACBr trata para 4 decimais e as regras tanto de arredondamento quanto truncamento colocam 5,1792). A única forma que encontrei, mas é POG, é incrementar o último decimal até chegar no valor total correto e enviar para o ACBr e este para o SAT.

5,179200331468821 x 9,654 = 50 Para o Prod.qCom eu passo 5,179200331468821 , mas ele vai colocar uma máscara de 4 decimais, ficando 5,1792 o que vai ocasionar no erro do valor total. Em outras palavras, não estou conseguindo passar para o sat o valor 5,179200331468821 para que o valor seja calculado corretamente.

Pelo que expus acima fico pensando que pode ser algo interno do sat, o que acham? Já que passo apenas valores e quantidade para que ele realize os cálculos.

Então. Prod1 valor = 5,179200331468821 , chegando em Prod.qcom com 5,1792 vl item = 9,654 Usando a tag ehCombustivel = True e Prod.indRegra = irTruncamento Total = 49,9999968 O Truncamento será 49,99 . Acham que pode ser calculo interno do SAT ?

Está passando nome, cpf/cnpj e se o cliente é isento, contribuinte ou não contribuinte ? No servidor do RJ passa dessa forma...

Boa ! Estamos passando pelo seguinte problema: Prod1 valor = 5,1790 lit vl item = 9,654 Total = 49,9980 Neste caso o total calculado pelo ACBrSat não deveria ser 50,00 , com o arredondamento da abnt ? Acontece que ele está imprimindo no extrato 49,99 e gerando um troco de 0,01. Não tínhamos este problema quando estávamos no Trunk 1 . Somente após migrar para o trunk 2. Gostaria de saber se houve alguma modificação no ACBrSat neste sentido, se faltou alguma configuração, ou coisa do gênero. Valeu!

OW! Possibilidade de rolar algum tipo de live stream ?

Seguindo o manual de boas praticas, não se deve alterar o tipo de transmissão quando houver tentativa de envio e o webservice estiver indisponível. Ai deve-se criar uma nova nota já em modo de contingência e após retorno do webservice enviar ambas. A primeira deverá ser cancelada ou inutilizada. Enfim, após o retorno da comunicação do webservice se ao enviar a nota 1 retornar rejeição 704 eu estou inutilizando a numeração, creio ser este, realmente, o modo correto.

Mas ela nunca estará na base da SEFAZ, já que no momento da transmissão o webservice retornou erro de comunicação. Veja que a SEFAZ diz para fazer : Transmissão Superado o problema técnico, a NFC-e n°21 é transmitida para obtenção da autorização de uso. Se vier a ser rejeitada, gerar novamente o arquivo com a mesma numeração e série, sanando a irregularidade e transmitir novamente. Para aquela que ficou pendente de retorno (a nota n° 20 desse exemplo):  inutilizar a numeração, se não autorizada; ou  cancelar, se autorizada.

Fiz um teste e alterei a data de geração somente do XML que será cancelado, a primeira NFC-e emitida, a SEFAZ validou e não retornou erro. Ficando assim: NFCE 1 - geração 00:10:00 (Cancelada) NFCE 2 - geração 00:01:00 (Emitida off-line como contingencia da NFC-e 1) NFCE 3 - geração 00:02:00 (Emitida off-line). A Sefaz não deveria ter retornado erro por ter uma NFC-e com numeração anterior e dt/hr de geração posterior as outras ? OBS ! SEFAZ RJ.

Boa! Pessoal, estou com o seguinte problema: Tentativa de transmissão da NFC-e 1. Webservice retorna erro de comunicação. Cria NFC-e 2 em modo off-line. Webservice somente volta a ter comunicação após 30 minutos. Ao enviar NFC-e 1 para posteior Cancelamento ou Inutilização a SEFAZ retorna o erro "NFC-e com Data-Hora de emissão atrasada". Nesse momento o que eu posso fazer ? Não é razoável modificar o XML para colocar que ele foi emitido off-line, já que o processo de emitir uma segunda NFC-e já foi realizado. A não ser que eu não emita a segunda e já modifique o xml para modo offline (em teoria estaria em desacordo com os manuais e normas técnicas). Se eu modificar o XML e alterar a dtEmiss, todos os outros movimentos deverão ser alterados, gerando uma diferença no que foi impresso em contingência e a dt/hr em banco. O que vocês têm feito para contornar este problema?

Dando um UP no tópico já que ele está sem resposta.... Pessoal, estou com o seguinte problema: Tentativa de transmissão da NFC-e 1 . Webservice retorna erro de comunicação. Cria NFC-e 2 em modo off-line. Webservice somente volta a ter comunicação após 30 minutos. Ao enviar NFC-e 1 para posteior Cancelamento ou Inutilização a sefaz retorna o erro "NFC-e com Data-Hora de emissão atrasada". Nesse momento o que eu posso fazer ? Não é razoável modificar o XML para colocar que ele foi emitido off-line, já que o processo de emitir uma segunda NFC-e já foi realizado. A não ser que eu não emita a segunda e já modifique o xml para modo offline (em teoria estaria em desacordo com os manuais e normas técnicas). Se eu modificar o XML e alterar a dtEmiss, todos os outros movimentos deverão ser alterados, gerando uma diferença no que foi impresso em contingência e a dt/hr em banco. O que vocês têm feito para contornar este problema?

Como tópico citado pelo @RicardoVoigt está fechado... Tivemos problemas e aqui se resolveu da seguinte maneira : Caso o produto seja um dos códigos ANPs especificados na norma técnica passamos a tag <ICMSST> , caso contrário passamos <ICMS60> Em ambos os casos com as tags : <orig> <CST> <vBCSTRet> <pST> <vICMSSTRet> <vBCFCPSTRet> <pFCPSTRet> <vFCPSTRet> Caso seja usada a TAG <ICMS60> passamos, também, a <ICMSST> com os valores : <orig> <CST> <vBCSTRet> <vICMSSTRet> <vBCSTDest> <vICMSSTDest>