DECRETO Nº 56.670 - Estado do Rio Grande do Sul

[Dércio Luis Zanatta]

3 minutos atrás, jcaset disse:

Eu entendi, lendo outras respostas vindas da SEFAZ, que este "código do sistema" não necessariamente deve estar no comprovante do cartão, mas que deveríamos criar um novo comprovante, a ser impresso junto a NFCe, onde conste este código do sistema. Ou seja, o cliente receberia: NFCe + comprovante do sistema com este código + comprovante do cartão (que é mais ou menos o que é entregue qnd o cliente tem TEF).

Nesta resposta que o Fabio colocou acima, pra mim fica entendível que, numa eventual fiscalização, solicitariam para que o contribuinte mostrasse as informações registradas tão somente no sistema, sem que haja necessariamente uma ligação entre o código que o sistema gerou e o pagamento realizado.

Agora volto naquela questão que o Windel levantou... Hoje dizem que pode ser o código gerado pelo sistema e que não precisaria ter uma ligação com o pagamento, mas é algo que não me parece ter muita lógica.

Não tem nenhuma lógica !!  Como que o cliente vai levar dois comprovantes do pagamento ?  E se depois de fazer a nfce com esse código não fizer o pagamento no cartão ?  ou se tentar fazer e a transação for negada ?   faz o que com a NFCe que tem o código inventado ?  

[JOEL LUIS]

Coincidencia ou não... tudo leva a solução que o Banrisul esta oferecendo.... Banrisul é banco do Estado, e o Estado determina regras.... kkkkkkk deviam estar se preparando a mais tempo

vero.pdf

[WINDEL]

Em 07/06/2023 at 15:17, jcaset disse:

Eu entendi, lendo outras respostas vindas da SEFAZ, que este "código do sistema" não necessariamente deve estar no comprovante do cartão, mas que deveríamos criar um novo comprovante, a ser impresso junto a NFCe, onde conste este código do sistema. Ou seja, o cliente receberia: NFCe + comprovante do sistema com este código + comprovante do cartão (que é mais ou menos o que é entregue qnd o cliente tem TEF).

Nesta resposta que o Fabio colocou acima, pra mim fica entendível que, numa eventual fiscalização, solicitariam para que o contribuinte mostrasse as informações registradas tão somente no sistema, sem que haja necessariamente uma ligação entre o código que o sistema gerou e o pagamento realizado.

Agora volto naquela questão que o Windel levantou... Hoje dizem que pode ser o código gerado pelo sistema e que não precisaria ter uma ligação com o pagamento, mas é algo que não me parece ter muita lógica.

Acredito que eles vão querer comparar as informações com os dados bancários das empresas sim.

Não concordo com essa prerrogativa de que o software deva gerar um código de transação, anexar no documento fiscal e armazenar o registro dessa informação, com a vinculação do pagamento real, que foi para o banco. É uma responsabilidade que não é nossa.

O correto aí, seria que modificassem o layout da nota, para que a tag aceite mais caracteres e então somente informemos os códigos de autorização que são gerados pelas instituições de pagamento, que aí sim tem alguma validade.

É muita responsabilidade ter essa informação local, no banco de dados do cliente. Sabemos que muitos não tem o mínimo cuidado com os dados e ocasionalmente, acabam perdendo tudo. Aí nesses casos, seriam perdidos todos registros e rastreamento com as operações que o estabelecimento tenha realizado, referente aos pagamentos.

De momento, integramos o TEF a nossa aplicação e iremos trabalhar informando na tag somente quando forem operações envolvendo cartões, utilizando o próprio código que vem lá da autorizadora (um código real).

[Ramiro Ganesa]

1 hora atrás, WINDEL disse:

Acredito que eles vão querer comparar as informações com os dados bancários das empresas sim.

Não concordo com essa prerrogativa de que o software deva gerar um código de transação, anexar no documento fiscal e armazenar o registro dessa informação, com a vinculação do pagamento real, que foi para o banco. É uma responsabilidade que não é nossa.

O correto aí, seria que modificassem o layout da nota, para que a tag aceite mais caracteres e então somente informemos os códigos de autorização que são gerados pelas instituições de pagamento, que aí sim tem alguma validade.

É muita responsabilidade ter essa informação local, no banco de dados do cliente. Sabemos que muitos não tem o mínimo cuidado com os dados e ocasionalmente, acabam perdendo tudo. Aí nesses casos, seriam perdidos todos registros e rastreamento com as operações que o estabelecimento tenha realizado, referente aos pagamentos.

De momento, integramos o TEF a nossa aplicação e iremos trabalhar informando na tag somente quando forem operações envolvendo cartões, utilizando o próprio código que vem lá da autorizadora (um código real).

Concordo com o colega. 

Fica claro que a Sefaz quer cruzar os dados entre as adquirentes e a emissão da NFCe, nao faz sentido algum o sistema gerar um numero e preencher lá... como a Sefaz vai relacionar isso? Vai tirar a responsabilidade da adquirente e colocar nos softwares? Sendo que as adquirentes ja disponibilizam isso a eles, nao faz sentido algum.

Não tem caminho facil, se não for prorrogado ou revogado esse decreto, o caminho é os contribuinte integrarem com o TEF via PINPAD ou ter as soluções integradas a SmartPOS e outras tecnologias que automatizem o pagamento digitais e de cartão.

Lembrando, que para PIX nao existe nada estipulado ainda, ainda vai passar muita agua por essa ponte.

[DOCFABIO]

No Fecomércio Debate, no dia 14/06, vamos discutir o impacto do Decreto 56.670 e esclarecer todas as suas dúvidas sobre a vinculação das máquinas de cartões à Nota Fiscal ao Consumidor eletrônica.
Evento híbrido:
Presencial, na sede do Sistema Fecomércio-RS/Sesc/Senac
 On-line, no YouTube da Fecomércio
Inscreva-se e não perca a oportunidade de ficar por dentro das obrigações e garantir o sucesso do seu empreendimento!

 

[Dércio Luis Zanatta]

23 horas atrás, DOCFABIO disse:

No Fecomércio Debate, no dia 14/06, vamos discutir o impacto do Decreto 56.670 e esclarecer todas as suas dúvidas sobre a vinculação das máquinas de cartões à Nota Fiscal ao Consumidor eletrônica.
Evento híbrido:
Presencial, na sede do Sistema Fecomércio-RS/Sesc/Senac
 On-line, no YouTube da Fecomércio
Inscreva-se e não perca a oportunidade de ficar por dentro das obrigações e garantir o sucesso do seu empreendimento!

 

Muito obrigado por compartilhar a informação...  Assisti o evento ontem e esclareceram muita coisa mesmo. Pessoal da SEFAZ-RS assumiu publicamente que foi um erro terem informado que o sistema pode gerar um código aleatório para vincular na tag cAut.  Pediram desculpas publicamente.. Isso esclarece de uma vez por todas que o código que deve ser vinculado na tag cAut é o NSU da transação e não um código gerado aleatoriamente pelo sistema.

Quanto ao pix, até onde eu entendi, somente será considerado integrado quando é com QrCode dinâmico, e nesses casos  deve ser inserida na tag xCampo com o valor "txidPIX" e a tag xTexto com o número da autorização da transação, já que em alguns casos, o número de autorizado PIX ultrapassa os 20 caracteres que é o máximo aceito na tag cAut.  Qualquer outra forma de recebimento com Pix que não seja com QrCode dinâmico, deve ser tratado como dinheiro.

Quanto aos recebimentos feitos em operações não fiscais (recebimento de crediário, por exemplo), a orientação é fazer uma NFCe com um ítem com CFOP 5949. A SEFAZ-RS se comprometeu a lançar um documento com orientações dos dados que deverão ser informados nessa NFCe (ncm, CST de icms, etc...) "em breve"..

Acredito que com esses esclarecimentos tenhamos um rumo a seguir agora..  No meu entendimento a implementação de TEF é primordial, apesar de a SEFAZ-RS afirmar que não é obrigatório. Existe ainda a possibilidade de integrar com a nova geração de POS onde é possível capturar as informações via Wi-fi ou blue Tooth, mas isso vai demandar um trabalho grande por parte das Sofwarehouses que teriam que desenvolver essa integração com cada adquerinte separadamente e nem todas disponibilizam essa integração ainda..

Resumindo, receber com cartão no RS é com TEF, seguindo as orientações da SEFAZ-RS

Um ótimo trabalho a todos.

[Wiliam Dutra]

1 hour ago, Dércio Luis Zanatta said:

Muito obrigado por compartilhar a informação...  Assisti o evento ontem e esclareceram muita coisa mesmo. Pessoal da SEFAZ-RS assumiu publicamente que foi um erro terem informado que o sistema pode gerar um código aleatório para vincular na tag cAut.  Pediram desculpas publicamente.. Isso esclarece de uma vez por todas que o código que deve ser vinculado na tag cAut é o NSU da transação e não um código gerado aleatoriamente pelo sistema.

Quanto ao pix, até onde eu entendi, somente será considerado integrado quando é com QrCode dinâmico, e nesses casos  deve ser inserida na tag xCampo com o valor "txidPIX" e a tag xTexto com o número da autorização da transação, já que em alguns casos, o número de autorizado PIX ultrapassa os 20 caracteres que é o máximo aceito na tag cAut.  Qualquer outra forma de recebimento com Pix que não seja com QrCode dinâmico, deve ser tratado como dinheiro.

Quanto aos recebimentos feitos em operações não fiscais (recebimento de crediário, por exemplo), a orientação é fazer uma NFCe com um ítem com CFOP 5949. A SEFAZ-RS se comprometeu a lançar um documento com orientações dos dados que deverão ser informados nessa NFCe (ncm, CST de icms, etc...) "em breve"..

Acredito que com esses esclarecimentos tenhamos um rumo a seguir agora..  No meu entendimento a implementação de TEF é primordial, apesar de a SEFAZ-RS afirmar que não é obrigatório. Existe ainda a possibilidade de integrar com a nova geração de POS onde é possível capturar as informações via Wi-fi ou blue Tooth, mas isso vai demandar um trabalho grande por parte das Sofwarehouses que teriam que desenvolver essa integração com cada adquerinte separadamente e nem todas disponibilizam essa integração ainda..

Resumindo, receber com cartão no RS é com TEF, seguindo as orientações da SEFAZ-RS

Um ótimo trabalho a todos.

Bom Dia!! Será que essa orientação do recebimento de crediario, vai demorar, pois tenho muitos clientes ainda com essa duvida.

[Ramiro Ganesa]

1 hora atrás, Dércio Luis Zanatta disse:

Muito obrigado por compartilhar a informação...  Assisti o evento ontem e esclareceram muita coisa mesmo. Pessoal da SEFAZ-RS assumiu publicamente que foi um erro terem informado que o sistema pode gerar um código aleatório para vincular na tag cAut.  Pediram desculpas publicamente.. Isso esclarece de uma vez por todas que o código que deve ser vinculado na tag cAut é o NSU da transação e não um código gerado aleatoriamente pelo sistema.

Quanto ao pix, até onde eu entendi, somente será considerado integrado quando é com QrCode dinâmico, e nesses casos  deve ser inserida na tag xCampo com o valor "txidPIX" e a tag xTexto com o número da autorização da transação, já que em alguns casos, o número de autorizado PIX ultrapassa os 20 caracteres que é o máximo aceito na tag cAut.  Qualquer outra forma de recebimento com Pix que não seja com QrCode dinâmico, deve ser tratado como dinheiro.

Quanto aos recebimentos feitos em operações não fiscais (recebimento de crediário, por exemplo), a orientação é fazer uma NFCe com um ítem com CFOP 5949. A SEFAZ-RS se comprometeu a lançar um documento com orientações dos dados que deverão ser informados nessa NFCe (ncm, CST de icms, etc...) "em breve"..

Acredito que com esses esclarecimentos tenhamos um rumo a seguir agora..  No meu entendimento a implementação de TEF é primordial, apesar de a SEFAZ-RS afirmar que não é obrigatório. Existe ainda a possibilidade de integrar com a nova geração de POS onde é possível capturar as informações via Wi-fi ou blue Tooth, mas isso vai demandar um trabalho grande por parte das Sofwarehouses que teriam que desenvolver essa integração com cada adquerinte separadamente e nem todas disponibilizam essa integração ainda..

Resumindo, receber com cartão no RS é com TEF, seguindo as orientações da SEFAZ-RS

Um ótimo trabalho a todos.

Perfeito meu caro. 

quando a tag cAut, me parece que é o código de autorização que precisa ser preenchido e nao o NSU.

[Vinicius L. Azevedo]

Sobre o evento, é triste de ver o quanto eles se perdem quando confrontados com a realidade do comércio brasileiro. Faltam respostas, inventam gambiarras pra tapar buracos e geram novos buracos. "Vamos ter que pensar" foi a principal resposta, e ainda assim o prazo pra implantação está estourado e os clientes das software houses estão preocupados. A cara de pau é maior quando eles dizem que não querem atrapalhar o mercado, quando na verdade qualquer um sabe que é basicamente a única função do governo. Claramente percebe-se que estes burocratas não entendem da realidade brasileira e ainda recebem a bênção da AFRAC.

[guilhermekm]

11 minutos atrás, Vinicius L. Azevedo disse:

Sobre o evento, é triste de ver o quanto eles se perdem quando confrontados com a realidade do comércio brasileiro. Faltam respostas, inventam gambiarras pra tapar buracos e geram novos buracos. "Vamos ter que pensar" foi a principal resposta, e ainda assim o prazo pra implantação está estourado e os clientes das software houses estão preocupados. A cara de pau é maior quando eles dizem que não querem atrapalhar o mercado, quando na verdade qualquer um sabe que é basicamente a única função do governo. Claramente percebe-se que estes burocratas não entendem da realidade brasileira e ainda recebem a bênção da AFRAC.

Sim, eu estou pensando, como o lojista vai dizer dizer ao cliente que a nota emitida (NFC-e CFOP 5949) para o recebimento do crediário/parcela é um documento fiscal que "não tem valor"... vai reclamar que não aparecerá na nota fiscal gaúcha? Ou aparecerá? Eu estou assustado com essa gambiarra nível governamental!

[WINDEL]

15 minutos atrás, Vinicius L. Azevedo disse:

Sobre o evento, é triste de ver o quanto eles se perdem quando confrontados com a realidade do comércio brasileiro. Faltam respostas, inventam gambiarras pra tapar buracos e geram novos buracos. "Vamos ter que pensar" foi a principal resposta, e ainda assim o prazo pra implantação está estourado e os clientes das software houses estão preocupados. A cara de pau é maior quando eles dizem que não querem atrapalhar o mercado, quando na verdade qualquer um sabe que é basicamente a única função do governo. Claramente percebe-se que estes burocratas não entendem da realidade brasileira e ainda recebem a bênção da AFRAC.

Concordo 100% com seus apontamentos. Faz um certo tempo que já desacreditei da AFRAC. Ao invés de se posicionarem defendendo as SW e os consumidores, ficou bem claro que estão puxando é pro lado da receita...

[RicardoVoigt]

3 horas atrás, Wiliam Dutra disse:

Bom Dia!! Será que essa orientação do recebimento de crediario, vai demorar, pois tenho muitos clientes ainda com essa duvida.

Bom dia, sobre o CFOP 5949 já saiu a Nota Técnica 2023.003

Pelo que entendi, no ato da venda continua saindo a NFC-e normal, com pagamento tipo 05=Crédito loja, (a prazo) e com as parcelas/duplicatas. O sistema guardaria essas parcelas num "contas a receber" e quando o cliente voltasse na loja para pagar cada parcela, e esse pagamento for no cartão (já pensaram que o TEF pode ser integrado também ao CR?), dai sim emite essa outra NFC-e com CFOP 5949 (1 item apenas).

(Eu ACHO que essa NFC-e com 5949 não precisaria nem mesmo ser impressa, o cliente não precisaria nem ver esse documento...)

OBS: removendo a "besteira" que escrevi acima, a treta também envolve justamente a impressão do comprovante do pagamento...

Foi perguntado também na live se essa NFC-e posterior de pagamento teria que referenciar a original da venda, se não me engano teria q se ajustar a regra de validação para aceitar a refNFe na NFC-e. Imagino que, no mínimo, o sistema pode inserir essa referencia da NFC-e e parcela nas Obs complementares e tal...

 

Att

Ricardo

Editado 15 Junho, 2023 por RicardoVoigt
obs...

[virtualsys]

É pessoal, chega ser deprimente essa apresentação, AFRAC animadíssimos e sempre do lado dos fabricantes e provedores de TEF.

O Sefaz não se deu conta dos problemas que estão criando com essa Nfce 5.949.

O que impede dos comerciantes usarem este tipo de nota indiscriminadamente para os recebimentos em cartões e somente fazer a nota real posteriormente ou agrupando várias vendas como fazem hoje?

"Venda fora dos estabelecimento é só usar opção 4" (dizem eles), porém eles não lembram que para fazer nfce com indicador de presença 4 é necessário informar os dados completos do cliente (com endereço) e do transportador. 

Vamos em frente, e TEF goela abaixo!

 

[Bruno Schneider - SS]

Uma dúvida

 

na impressão da nfc-e o comprovante do tef precisa ser completo com aqueles montes de linhas retornado pelo tef

ou pode ser resumido com as 3 infos que vão na nfc, cAut, card e cnpj?

 

[Dércio Luis Zanatta]

10 horas atrás, Bruno Schneider - SS disse:

Uma dúvida

 

na impressão da nfc-e o comprovante do tef precisa ser completo com aqueles montes de linhas retornado pelo tef

ou pode ser resumido com as 3 infos que vão na nfc, cAut, card e cnpj?

 

Bom dia

No caso da via do cliente existe uma forma de configurar para sair de forma reduzida (pelo menos no Sitef)

 

[Cássio Elias Da Silva]

Pessoal, realizei a leitura de todas as discussões até aqui, vejo que alguns pontos em relação ao código da autorização ou identificação do pedido são duvidas, especialmente o primeiro tópico desse link onde é decretado a seguinte ação "o sistema da empresa deverá gerar um código de identificação da operação".

Buscamos esclarecimentos  sobre esse assunto junto ao NAVi e recebemos o seguinte como resposta:
Com relação às orientações que estão no link https://atendimento.receita.rs.gov.br/integracao-entre-nfce-e-meios-de-pagamento-eletronicos , notamos que elas realmente não estão deixando claro que o código de integração deve ser gerado pelo sistema de pagamento. Já contatamos a equipe responsável pelo site, e solicitamos que o texto seja alterado para deixar esse ponto mais claro. Em particular, a expressão "sistema da empresa" deverá ser substituída por "sistema de pagamento". 
  
O procedimento que deve ser seguido é aquele que mencionamos no email anterior. Repito:
 
O sistema de pagamento vai gerar um código de identificação da transação. O sistema emissor de NFC-e deve pegar esse código e inserir de forma automática na tag cAut do arquivo XML. A integração se dará dessa forma.
 
Vocês podem usar qualquer solução técnica que execute o procedimento acima.

Agora está claro, pelo menos para nós, que é a empresa que efetiva os pagamentos que deverá gerar o código de integração e não as nossas empresas (softwarehouses) como estava sendo discutido.

[WINDEL]

Na live, comentaram sobre como proceder quando o pagamento envolvesse PIX.

Alguém sabe se já foi disponibilizado algum documento que regulamente a operação que apresentaram?

[Dércio Luis Zanatta]

Boa tarde amigos..

A respeito da Nota Técnica 2023.003 que altera as regras de validações para permitir CFOP 5949 e CST de Icms 90 na NFCe emitida no RS...

Na NT diz que estaria disponível em homologação a partir de 05/06/2023. Fui fazer um teste hj e está rejeitando o CST 90..

Fiz um questionamento no fale conosco da SEFAZ-RS a respeito disso e veja o que me foi respondido :

"Prezado(a) contribuinte:

Conforme informado, pelo próprio programador, a NFC-e (65) permite apenas os seguintes CST: 00, 20, 40, 41 e 60.

A NFC-e foi concebida para consumidor final, ou seja, compreende apenas as transações em que não ocorrerão mais direito a crédito ao destinatário. Isso significa que toda a tributação ou já se encerrou ou se encerra nessa etapa em que se emite a NFC-e.

Caso o objetivo seja utilizar o CST 51 e se permitido pela legislação, deve-se emitir NF-e (modelo 55)."

Ou seja, 

Parece que nem o próprio suporte da SEFAZ-RS tem conhecimento dessa NT, apesar de ela já estar em vigor em homologação desde o dia 05/06/2023.

A SEFAZ-RS está se tornando uma carreta carregada de aço morro abaixo sem ninguém na direção !!  Salve-se quem puder !!

 

 

[Nícolas Dörr]

Em 22/06/2023 at 13:30, WINDEL disse:

Na live, comentaram sobre como proceder quando o pagamento envolvesse PIX.

Alguém sabe se já foi disponibilizado algum documento que regulamente a operação que apresentaram?

Boa tarde Windel, estava com a mesma dúvida.

Encontrei essa explicação disponível naquela página de orientação sobre o decreto, segue link: https://atendimento.receita.rs.gov.br/integracao-entre-nfce-e-meios-de-pagamento-eletronicos

[WINDEL]

18 horas atrás, Nícolas Dörr disse:

Boa tarde Windel, estava com a mesma dúvida.

Encontrei essa explicação disponível naquela página de orientação sobre o decreto, segue link: https://atendimento.receita.rs.gov.br/integracao-entre-nfce-e-meios-de-pagamento-eletronicos

Obrigado por contribuir, @Nícolas Dörr.

Entendo que então devemos informar esses campos pertencentes ao Grupo Z. Informações Adicionais da NF-e, concordam?

A tag ObsCont, que é de uso livre do contribuinte, possui ocorrência 0-10 e pelo que olhei por cima, o componente hoje está limitado a somente 1 ocorrência. Talvez seja necessário o ajuste no componente do ACBr, para que caso alguém pague com mais de 1 pix, consigamos enviar a informação referente aos 2 pagamentos efetuados.

[Juliana Tamizou]

Bom dia pessoal,

A NT que abriu  a possibilidade da NFCe com 5949 foi devido a um pedido da SEFAZ-RS, porém eles ainda não fizeram os ajustes ou regulamentaram internamente seu uso, por conta disso a resposta obtida no Fale Conosco.

At.

[Nícolas Dörr]

9 minutos atrás, WINDEL disse:

Obrigado por contribuir, @Nícolas Dörr.

Entendo que então devemos informar esses campos pertencentes ao Grupo Z. Informações Adicionais da NF-e, concordam?

A tag ObsCont, que é de uso livre do contribuinte, possui ocorrência 0-10 e pelo que olhei por cima, o componente hoje está limitado a somente 1 ocorrência. Talvez seja necessário o ajuste no componente do ACBr, para que caso alguém pague com mais de 1 pix, consigamos enviar a informação referente aos 2 pagamentos efetuados.

No ACBr está permitindo mais de uma ocorrência @WINDEL. Eu fiz a implementação e é só usar conforme abaixo:

with InfAdic.obsCont.New do
begin
  xCampo := 'txidPIX';
  xTexto := 'ValortxidPIX'
end;

Desta maneira você consegue incluir quantas vezes quiser. Eu ainda inclui uma outra validação caso o pagamento seja feito com mais de 10 Pix (Acho improvável mas pode acontecer) para evitar erro na hora de validar a NFC-e. 

[Dércio Luis Zanatta]

2 minutos atrás, Nícolas Dörr disse:

No ACBr está permitindo mais de uma ocorrência @WINDEL. Eu fiz a implementação e é só usar conforme abaixo:

with InfAdic.obsCont.New do
begin
  xCampo := 'txidPIX';
  xTexto := 'ValortxidPIX'
end;

Desta maneira você consegue incluir quantas vezes quiser. Eu ainda inclui uma outra validação caso o pagamento seja feito com mais de 10 Pix (Acho improvável mas pode acontecer) para evitar erro na hora de validar a NFC-e. 

Bom dia

with InfAdic.obsCont.add do
begin
  xCampo := 'txidPIX';
  xTexto := 'ValortxidPIX'
end;

Dessa forma não vai funcionar ?

 

[WINDEL]

Na verdade, acredito que estamos com as units desatualizadas. Vamos atualizar e testar. Se já existe o add aí para vocês, já deve funcionar normalmente.

[GustavoLI]

Já saiu a orientação de SEFAZ de como emitir a NFC-e 5949 para recebimentos feitos em operações não fiscais (recebimento de crediário, por exemplo),?