DECRETO Nº 56.670 - Estado do Rio Grande do Sul

[Ramiro Ganesa]

1 hora atrás, JOEL LUIS disse:

Mandei mensagem até para colunista da Gaucha.... recebi algumas informações ...kkkk

 

https://gauchazh.clicrbs.com.br/colunistas/giane-guerra/noticia/2023/05/varejo-pede-adiamento-de-mudanca-na-nota-fiscal-no-rs-clh6nygs1007i015bl7zk48xo.html

Consegue a noticia na integra... ter quer assinar a zh é osso...

[JOEL LUIS]

BOM DIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA!!!

ESPERO QUE QUANDO O FORUM TIVER NOTICIAS BOAS TAMBEM COLOQUEM AQUI...KKKKKKK

 

 

INSTRUÇÃO NORMATIVA RE Nº 037/23

1. Com fundamento no Convênio ICMS 134/16, de 9 de dezembro de 2016, publicado no Diário Oficial da União de 15 de dezembro de 2016, no Título I, Capítulo XI, no subitem 29.5.1, é dada nova redação às alíneas "a" e "b" e
ficam acrescentadas as alíneas "c" e "d", e fica acrescentado o subitem 29.5.1.4, conforme segue:

29.5 - ...( 29.5 - Vinculação do comprovante de pagamento eletrônico com a NFC-e (RICMS, Livro II, art. 178)

29.5.1 - ...( 29.5.1 - A emissão do comprovante de transação ou intermediação de vendas ou serviços, realizados de forma presencial, efetuada com cartões de débito, de crédito, de loja ("private label"), transferência de recursos, transações eletrônicas do Sistema de Pagamento Instantâneo e demais instrumentos de pagamento eletrônico, deve estar vinculada à NFC-e emitida na operação ou prestação, mediante interligação com o programa emissor do documento fiscal, a partir de)

a) 01/04/23, para estabelecimentos cuja atividade econômica esteja enquadrada no CGC/TE nas classes 4711-3 e 4712-1 da CNAE, tais como supermercados, hipermercados e minimercados e cujo faturamento da empresa no ano de 2022 tenha sido superior a R$ 1.800.000,00;

b) 01/07/23, para estabelecimentos cujo faturamento da empresa no ano de 2022 tenha sido superior a R$ 720.000,00;

c) 01/10/23, para estabelecimentos cujo faturamento da empresa no ano de 2022 tenha sido superior a R$ 360.000,00;

d) 01/01/24, para os demais estabelecimentos.

...
29.5.1.4 - Para efeitos do disposto nas alíneas "a" a "c" do subitem 29.5.1, serão consideradas:

 
      a)a soma do faturamento de todos os estabelecimentos do contribuinte localizados no Estado;
     b) para o contribuinte que iniciou suas atividades no ano de 2022, a proporcionalidade dos valores de faturamento ao número de meses ou fração de mês de atividades no ano.

[Dércio Luis Zanatta]

10 minutos atrás, JOEL LUIS disse:

BOM DIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA!!!

ESPERO QUE QUANDO O FORUM TIVER NOTICIAS BOAS TAMBEM COLOQUEM AQUI...KKKKKKK

 

 

INSTRUÇÃO NORMATIVA RE Nº 037/23

1. Com fundamento no Convênio ICMS 134/16, de 9 de dezembro de 2016, publicado no Diário Oficial da União de 15 de dezembro de 2016, no Título I, Capítulo XI, no subitem 29.5.1, é dada nova redação às alíneas "a" e "b" e
ficam acrescentadas as alíneas "c" e "d", e fica acrescentado o subitem 29.5.1.4, conforme segue:

29.5 - ...( 29.5 - Vinculação do comprovante de pagamento eletrônico com a NFC-e (RICMS, Livro II, art. 178)

29.5.1 - ...( 29.5.1 - A emissão do comprovante de transação ou intermediação de vendas ou serviços, realizados de forma presencial, efetuada com cartões de débito, de crédito, de loja ("private label"), transferência de recursos, transações eletrônicas do Sistema de Pagamento Instantâneo e demais instrumentos de pagamento eletrônico, deve estar vinculada à NFC-e emitida na operação ou prestação, mediante interligação com o programa emissor do documento fiscal, a partir de)

a) 01/04/23, para estabelecimentos cuja atividade econômica esteja enquadrada no CGC/TE nas classes 4711-3 e 4712-1 da CNAE, tais como supermercados, hipermercados e minimercados e cujo faturamento da empresa no ano de 2022 tenha sido superior a R$ 1.800.000,00;

b) 01/07/23, para estabelecimentos cujo faturamento da empresa no ano de 2022 tenha sido superior a R$ 720.000,00;

c) 01/10/23, para estabelecimentos cujo faturamento da empresa no ano de 2022 tenha sido superior a R$ 360.000,00;

d) 01/01/24, para os demais estabelecimentos.

...
29.5.1.4 - Para efeitos do disposto nas alíneas "a" a "c" do subitem 29.5.1, serão consideradas:

 
      a)a soma do faturamento de todos os estabelecimentos do contribuinte localizados no Estado;
     b) para o contribuinte que iniciou suas atividades no ano de 2022, a proporcionalidade dos valores de faturamento ao número de meses ou fração de mês de atividades no ano.

Na realidade não vai mudar muita coisa...

1.200.000 de faturamento anual , representa um faturamento médio mensal de 150.000, ou 5000 diário..

A maioria dos mercados de porte médio e até mesmo considerados "pequenos" faturam isso...

Acho que a urgência seria esclarecer como deve funcionar o pagamento com PIX e recebimentos não fiscais.. que até hoje ainda não tem uma solução clara por parte da SEFAZ.

Recebimentos com cartões de crédito e débito para mim está bem claro: Deve ser feito por TEF e acabou a conversa...

[Ramiro Ganesa]

4 horas atrás, JOEL LUIS disse:

BOM DIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA!!!

ESPERO QUE QUANDO O FORUM TIVER NOTICIAS BOAS TAMBEM COLOQUEM AQUI...KKKKKKK

 

 

INSTRUÇÃO NORMATIVA RE Nº 037/23

1. Com fundamento no Convênio ICMS 134/16, de 9 de dezembro de 2016, publicado no Diário Oficial da União de 15 de dezembro de 2016, no Título I, Capítulo XI, no subitem 29.5.1, é dada nova redação às alíneas "a" e "b" e
ficam acrescentadas as alíneas "c" e "d", e fica acrescentado o subitem 29.5.1.4, conforme segue:

29.5 - ...( 29.5 - Vinculação do comprovante de pagamento eletrônico com a NFC-e (RICMS, Livro II, art. 178)

29.5.1 - ...( 29.5.1 - A emissão do comprovante de transação ou intermediação de vendas ou serviços, realizados de forma presencial, efetuada com cartões de débito, de crédito, de loja ("private label"), transferência de recursos, transações eletrônicas do Sistema de Pagamento Instantâneo e demais instrumentos de pagamento eletrônico, deve estar vinculada à NFC-e emitida na operação ou prestação, mediante interligação com o programa emissor do documento fiscal, a partir de)

a) 01/04/23, para estabelecimentos cuja atividade econômica esteja enquadrada no CGC/TE nas classes 4711-3 e 4712-1 da CNAE, tais como supermercados, hipermercados e minimercados e cujo faturamento da empresa no ano de 2022 tenha sido superior a R$ 1.800.000,00;

b) 01/07/23, para estabelecimentos cujo faturamento da empresa no ano de 2022 tenha sido superior a R$ 720.000,00;

c) 01/10/23, para estabelecimentos cujo faturamento da empresa no ano de 2022 tenha sido superior a R$ 360.000,00;

d) 01/01/24, para os demais estabelecimentos.

...
29.5.1.4 - Para efeitos do disposto nas alíneas "a" a "c" do subitem 29.5.1, serão consideradas:

 
      a)a soma do faturamento de todos os estabelecimentos do contribuinte localizados no Estado;
     b) para o contribuinte que iniciou suas atividades no ano de 2022, a proporcionalidade dos valores de faturamento ao número de meses ou fração de mês de atividades no ano.

Os ites A, B e C é referente os CNAEs de  4711-3 e 4712-1 da CNAE, tais como supermercados, hipermercados e minimercados, correto?

o item D seria todos os demais segmentos, ou seja, prorrogado para 01.01.2024.

Voces tem o mesmo entedimento?

[PbNew_Sistemas]

40 minutos atrás, Ramiro Ganesa disse:

Os ites A, B e C é referente os CNAEs de  4711-3 e 4712-1 da CNAE, tais como supermercados, hipermercados e minimercados, correto?

o item D seria todos os demais segmentos, ou seja, prorrogado para 01.01.2024.

Voces tem o mesmo entedimento?

No meu entendimento só o item A é referente a supermercados

Editado 16 Maio, 2023 por PbNew_Sistemas

[Marcelo SimplesVet]

Opa pessoal, tudo certo?

Vou resumir o que entendi até então sobre o tema e peço que me ajudem a corrigir as interpretações incorretas.

O objetivo do decreto é ter as informações de pagamento associadas ao XML da NFC-e. E isto, é o que será cobrado da empresa neste momento inicial.

A normativa em si, não especifica nada relacionado a como deve ocorrer a interligação entre o meio de pagamento e a emissão da nota. Tal como não especifica como deverá ser o código a ser utilizado para identificação dessa integração.

Porém, a Sefaz inseriu nos FAQs e também em suas comunicações mais atuais (lives, Navi, etc) os viéses de como resolver a demanda da normativa. Como por exemplo:

• O código a ser utilizado para a integração PRECISA ser gerado pelo sistema da empresa
• A interligação entre o meio de pagamento e o sistema emissor de nota NÃO poderá ser feita manualmente, mas sim, de forma automática.

O fato é que, cumprir estes requisitos informados pela Sefaz parece envolver um esforço maior, pois as Software Houses precisariam caminhar para a oferta do TEF ou algum outro tipo de integração com os POS`s atuais. 

Pensando em atender a NORMATIVA e ao que está sendo cobrado nesse momento, estou entendendo que usar o NSU gerado pelos POS's, ainda que integrado manualmente ao sistema de emissão, pode ser um bom caminho. Outros membros trouxeram essa solução também.

Realizando pesquisas, vi um artigo de suporte do sistema Conta azul, que é uma referência de Software e, em princípio, pelo que pude entender do artigo, eles também foram por um caminho similar: https://ajuda.contaazul.com/hc/pt-br/articles/360023352911-Obrigatoriedade-do-TEF-nas-emissões-de-Nota-Fiscal-de-Consumidor-Eletrônica.
Caso minha interpretação de solução da Conta azul tenha sido errada, peço que me corrijam, por favor.

Alguém mais está indo por caminhos similares?

[Dércio Luis Zanatta]

4 minutos atrás, Marcelo SimplesVet disse:

Opa pessoal, tudo certo?

Vou resumir o que entendi até então sobre o tema e peço que me ajudem a corrigir as interpretações incorretas.

O objetivo do decreto é ter as informações de pagamento associadas ao XML da NFC-e. E isto, é o que será cobrado da empresa neste momento inicial.

A normativa em si, não especifica nada relacionado a como deve ocorrer a interligação entre o meio de pagamento e a emissão da nota. Tal como não especifica como deverá ser o código a ser utilizado para identificação dessa integração.

Porém, a Sefaz inseriu nos FAQs e também em suas comunicações mais atuais (lives, Navi, etc) os viéses de como resolver a demanda da normativa. Como por exemplo:

• O código a ser utilizado para a integração PRECISA ser gerado pelo sistema da empresa
• A interligação entre o meio de pagamento e o sistema emissor de nota NÃO poderá ser feita manualmente, mas sim, de forma automática.

O fato é que, cumprir estes requisitos informados pela Sefaz parece envolver um esforço maior, pois as Software Houses precisariam caminhar para a oferta do TEF ou algum outro tipo de integração com os POS`s atuais. 

Pensando em atender a NORMATIVA e ao que está sendo cobrado nesse momento, estou entendendo que usar o NSU gerado pelos POS's, ainda que integrado manualmente ao sistema de emissão, pode ser um bom caminho. Outros membros trouxeram essa solução também.

Realizando pesquisas, vi um artigo de suporte do sistema Conta azul, que é uma referência de Software e, em princípio, pelo que pude entender do artigo, eles também foram por um caminho similar: https://ajuda.contaazul.com/hc/pt-br/articles/360023352911-Obrigatoriedade-do-TEF-nas-emissões-de-Nota-Fiscal-de-Consumidor-Eletrônica.
Caso minha interpretação de solução da Conta azul tenha sido errada, peço que me corrijam, por favor.

Alguém mais está indo por caminhos similares?

Bom dia

Aqui no RS, deixaram bem claro, que não será permitido qualquer forma de integração manual.. No meu entendimento não tem como atender com POS, a única forma de atender é com TEF, ficando ainda por responder as duas questões que ainda não estão esclarecidas:

1 - Pagamento com TEF em operações não fiscais (Recebimento por crediário, por exemplo)

2 - Pagamento com PIX, onde não existem tags no xml da nfce para inserir os dados do PIX

 

Fora esses dois pontos, é implantar TEF que estará atendendo o decreto

[Ramiro Ganesa]

38 minutos atrás, Dércio Luis Zanatta disse:

Bom dia

Aqui no RS, deixaram bem claro, que não será permitido qualquer forma de integração manual.. No meu entendimento não tem como atender com POS, a única forma de atender é com TEF, ficando ainda por responder as duas questões que ainda não estão esclarecidas:

1 - Pagamento com TEF em operações não fiscais (Recebimento por crediário, por exemplo)

2 - Pagamento com PIX, onde não existem tags no xml da nfce para inserir os dados do PIX

 

Fora esses dois pontos, é implantar TEF que estará atendendo o decreto

Tenho o mesmo entendimento que o seu.

Após muita pesquisa, vi alguns sistemas com integração a POS. Onde é gerado uma forma de integração, que ao solicitar pagamento a POS recebe o valor, autoriza pagamento e devolve para o ERP a autorização.

Segue aqui:

https://youtu.be/DUdvGBjXK-Y

A Skytef tem uma solução tb, chamada APOS SKYTEF. 

Verifiquem.

At.,

[Dércio Luis Zanatta]

1 hora atrás, Ramiro Ganesa disse:

Tenho o mesmo entendimento que o seu.

Após muita pesquisa, vi alguns sistemas com integração a POS. Onde é gerado uma forma de integração, que ao solicitar pagamento a POS recebe o valor, autoriza pagamento e devolve para o ERP a autorização.

Segue aqui:

https://youtu.be/DUdvGBjXK-Y

A Skytef tem uma solução tb, chamada APOS SKYTEF. 

Verifiquem.

At.,

Bem interessante essa forma de integração, mas ao meu ver, fica bem mais simples implantar TEF do que essa integração...  Além do mais isso ainda não soluciona os dois itens que citei anteriormente..

[Sidnei de Souza]

1 hora atrás, Ramiro Ganesa disse:

Tenho o mesmo entendimento que o seu.

Após muita pesquisa, vi alguns sistemas com integração a POS. Onde é gerado uma forma de integração, que ao solicitar pagamento a POS recebe o valor, autoriza pagamento e devolve para o ERP a autorização.

Segue aqui:

https://youtu.be/DUdvGBjXK-Y

A Skytef tem uma solução tb, chamada APOS SKYTEF. 

Verifiquem.

At.,

Ola amigos, tudo certo?

Se seus clientes nao tem algo fluxo de vendas e nao querem pagar os valores do TEF, tem a opção que eles chamam de POS Smart, eu tenho essa opção também em meu sistema, segue alguns links das APIs:

https://connect-v2.stone.com.br/reference/criar-pedido

https://developers.sejavero.com.br/pages/v1.1p/apis_vero_desenvolvedor.html

https://dev.pagseguro.uol.com.br/v1/docs/plugpag-introducao

Video do tempo que é levado para fazer o pedido via POS.

https://chatoindo-v2.s3-sa-east-1.amazonaws.com/3/3ABF59DCF0FB4FE36A34.mp4

 

[Marcelo SimplesVet]

1 hora atrás, Sidnei de Souza disse:

Ola amigos, tudo certo?

Se seus clientes nao tem algo fluxo de vendas e nao querem pagar os valores do TEF, tem a opção que eles chamam de POS Smart, eu tenho essa opção também em meu sistema, segue alguns links das APIs:

https://connect-v2.stone.com.br/reference/criar-pedido

https://developers.sejavero.com.br/pages/v1.1p/apis_vero_desenvolvedor.html

https://dev.pagseguro.uol.com.br/v1/docs/plugpag-introducao

Video do tempo que é levado para fazer o pedido via POS.

https://chatoindo-v2.s3-sa-east-1.amazonaws.com/3/3ABF59DCF0FB4FE36A34.mp4

 

Bacana Sidnei! Sou de software house e oferecemos integração com o POS de uma adquirente. E de fato essa solução resolve e atende aos requisitos solicitados pela normativa. 

Porém, apenas uma parcela dos nossos clientes utilizam a mesma adquirente a qual temos integração. Sugerir essa mudança para o cliente parece ser um caminho que pode gerar atritos com eles. A maior parte já deve trabalhar com outros adquirente e já possuem suas taxas negociadas, relacionamento com adquirente, etc. É um processo delicado.

[Eliandro Justo]

23 horas atrás, Marcelo SimplesVet disse:

Opa pessoal, tudo certo?

Vou resumir o que entendi até então sobre o tema e peço que me ajudem a corrigir as interpretações incorretas.

O objetivo do decreto é ter as informações de pagamento associadas ao XML da NFC-e. E isto, é o que será cobrado da empresa neste momento inicial.

A normativa em si, não especifica nada relacionado a como deve ocorrer a interligação entre o meio de pagamento e a emissão da nota. Tal como não especifica como deverá ser o código a ser utilizado para identificação dessa integração.

Porém, a Sefaz inseriu nos FAQs e também em suas comunicações mais atuais (lives, Navi, etc) os viéses de como resolver a demanda da normativa. Como por exemplo:

• O código a ser utilizado para a integração PRECISA ser gerado pelo sistema da empresa
• A interligação entre o meio de pagamento e o sistema emissor de nota NÃO poderá ser feita manualmente, mas sim, de forma automática.

O fato é que, cumprir estes requisitos informados pela Sefaz parece envolver um esforço maior, pois as Software Houses precisariam caminhar para a oferta do TEF ou algum outro tipo de integração com os POS`s atuais. 

Pensando em atender a NORMATIVA e ao que está sendo cobrado nesse momento, estou entendendo que usar o NSU gerado pelos POS's, ainda que integrado manualmente ao sistema de emissão, pode ser um bom caminho. Outros membros trouxeram essa solução também.

Realizando pesquisas, vi um artigo de suporte do sistema Conta azul, que é uma referência de Software e, em princípio, pelo que pude entender do artigo, eles também foram por um caminho similar: https://ajuda.contaazul.com/hc/pt-br/articles/360023352911-Obrigatoriedade-do-TEF-nas-emissões-de-Nota-Fiscal-de-Consumidor-Eletrônica.
Caso minha interpretação de solução da Conta azul tenha sido errada, peço que me corrijam, por favor.

Alguém mais está indo por caminhos similares?

Eu também apliquei semelhante ao que o sistema da Conta Azul fez, pelo lado de atender o que está escrito no Decreto vejo que atende, pois o objetivo é vincular o pagamento eletrônico (TEF) com a NFC-e para rastreio. Porém, também entendo que há muitas informações "espalhadas"  da SEFAZ/RS que deixam dúbia a interpretação.  
Mesmo assim, neste primeiro momento resolvi seguir assim pela questão da viabilidade.

Editado 31 Maio, 2023 por Eliandro Justo

[jcaset]

Bom dia, pessoal!

Li todo o tópico até aqui e queria ver se vocês acham que a ideia abaixo atenderia.

Pelo que pude entender até então, a normativa diz que não necessariamente o código NSU é o que deve constar no cAut da NFCe. Ou seja, o software pode gerar qualquer código desde que este conste na NFCe (o que pra mim, como para muitos, é estranho).

No meu caso, ao realizar um pagamento eu gero um código de movimentação financeira (ex.: 1300) e penso que seria possível usar este código na tag cAut, pois atenderia esta vínculo solicitado pela SEFAZ. Aí faltaria somente gerar mais um recibo para o cliente com este código.

Neste caso, o registro da informação é automático como sugere a normativa.

Esta minha forma de pensar está errada?

[DOCFABIO]

Em 01/06/2023 at 08:38, jcaset disse:

Bom dia, pessoal!

Li todo o tópico até aqui e queria ver se vocês acham que a ideia abaixo atenderia.

Pelo que pude entender até então, a normativa diz que não necessariamente o código NSU é o que deve constar no cAut da NFCe. Ou seja, o software pode gerar qualquer código desde que este conste na NFCe (o que pra mim, como para muitos, é estranho).

No meu caso, ao realizar um pagamento eu gero um código de movimentação financeira (ex.: 1300) e penso que seria possível usar este código na tag cAut, pois atenderia esta vínculo solicitado pela SEFAZ. Aí faltaria somente gerar mais um recibo para o cliente com este código.

Neste caso, o registro da informação é automático como sugere a normativa.

Esta minha forma de pensar está errada?

[DOCFABIO]

Estamos fazendo exatamente isso acima. 
Também pelos documentos que postei nos posts anteriores, da sefaz rs e da Fecomercio.
E agora as mesmas orientações estão no site da Sefaz rs:
https://atendimento.receita.rs.gov.br/integracao-entre-nfce-e-meios-de-pagamento-eletronicos
Estamos fazendo assim desde de 01/04 e os clientes, contadores e consultorias concordaram que no momento é só isso mesmo.
Está muito claro nas normativas que o uso do TEF não é obrigatório, que podem continuar usando as POS, que deve-se criar um código novo via sistema próprio, que não pode preencher o código manulmente.
Não tem isso de "rastreio", pelo menos no momento. Muitas coisas eles preveem colocar, e alterar, mas no momento é só isso.
È claro que na prática, colocamos as 2 opçoes para nosso cliente, fazer assim, ou integrar total com TEF, e deixamos pro cliente escolher.

 

 

[JOEL LUIS]

18 minutos atrás, DOCFABIO disse:

Estamos fazendo exatamente isso acima. 
Também pelos documentos que postei nos posts anteriores, da sefaz rs e da Fecomercio.
E agora as mesmas orientações estão no site da Sefaz rs:
https://atendimento.receita.rs.gov.br/integracao-entre-nfce-e-meios-de-pagamento-eletronicos
Estamos fazendo assim desde de 01/04 e os clientes, contadores e consultorias concordaram que no momento é só isso mesmo.
Está muito claro nas normativas que o uso do TEF não é obrigatório, que podem continuar usando as POS, que deve-se criar um código novo via sistema próprio, que não pode preencher o código manulmente.
Não tem isso de "rastreio", pelo menos no momento. Muitas coisas eles preveem colocar, e alterar, mas no momento é só isso.
È claro que na prática, colocamos as 2 opçoes para nosso cliente, fazer assim, ou integrar total com TEF, e deixamos pro cliente escolher.

 

 

A integração entre a NFC-e e o meio de pagamento eletrônico pode ser feita de forma manual?

Não. A troca de informações entre o sistema emissor de NFC-e e o sistema referente ao meio de pagamento deve ser feita de automática. Caso não haja uma integração direta entre os 2 sistemas (como ocorre nos sistemas TEF), então a integração pode ser feita utilizando outra tecnologia (como wi-fi, bluetooth, etc).

 

 

[WINDEL]

Em 01/06/2023 at 08:38, jcaset disse:

Bom dia, pessoal!

Li todo o tópico até aqui e queria ver se vocês acham que a ideia abaixo atenderia.

Pelo que pude entender até então, a normativa diz que não necessariamente o código NSU é o que deve constar no cAut da NFCe. Ou seja, o software pode gerar qualquer código desde que este conste na NFCe (o que pra mim, como para muitos, é estranho).

No meu caso, ao realizar um pagamento eu gero um código de movimentação financeira (ex.: 1300) e penso que seria possível usar este código na tag cAut, pois atenderia esta vínculo solicitado pela SEFAZ. Aí faltaria somente gerar mais um recibo para o cliente com este código.

Neste caso, o registro da informação é automático como sugere a normativa.

Esta minha forma de pensar está errada?

Sim, você pode criar qualquer bobagem lá na cAut, que vai aprovar, agora, não vá pensando que mais pra frente não vai ser fiscalizado isso. De alguma forma, eles vão querer rastrear sim a sua movimentação de número 1300 e ela vai ter que estar vinculada de alguma forma com o pagamento que foi recebido lá pelo banco.

Vejo que alguns colegas estão criando numerações fictícias e ficando por assim mesmo, porém, de que adianta gerar um número aleatório, sem ter o registro da transação original vinculada? Tem algum sentido pra você? Imagine a fiscalização no estabelecimento, olhando que tem o codigo 1 na nfc-e, mas no teu sistema, não está ligando a nada...

[Otávio Bogoni]

Boa tarde, pessoal!

Segue a minha pergunta e resposta obtida da SEFAZ-RS sobre algumas das dúvidas abordadas aqui no tópico:

Pergunta:

Olá, Sou desenvolvedor e tenho dúvidas sobre as modificações necessárias para adequar meu software de automação comercial ao decreto nº 56.670. Meu software já possui TEF integrado (cartão e pix), emitindo a NFC-e com código de autorização das transações ( para transações com cartão, no campo "cAut", como previsto no manual da NF-e) e também imprimo comprovante com os dados da transação junto com a nota. Ou seja, após o pagamento o cliente recebe dois papeis: a NFC-e e um comprovante TEF, ambos impressos pelo mesmo sistema e equipamento. Contudo, ao ler a seção de perguntas frequentes do site sobre esse tema, vi que é necessário incluir campos a mais no comprovante, como um código identificador gerado por mim (diferente do código de autorização ou NSU referentes a transação TEF). O problema é que, atualmente, a integração de TEF (SiTef) que utilizo não permite a edição do comprovante de pagamento impresso. Nesse caso, seria necessário implementar a impressão de um terceiro papel como comprovante que teria esse código identificador? Ou o fato de vincular o código da autorização da transação TEF, que é impresso no comprovante atual, com o XML da nota já basta para cumprir as exigências do Fisco? Se for o caso da última pergunta, como ficaria a situação do PIX, visto que não existem campos específicos no XML para informar os dados da transação na nota fiscal? Agradeço desde já.

Resposta:

Está havendo neste momento uma reavaliação dos procedimentos a serem tomados em questões similares a essa. Daremos um retorno sobre essa questão assim que o procedimento estiver definido.

Eduardo S. Benazzi
Auditor Fiscal da Receita Estadual
NAVi  -  Núcleo  de  Atendimento  Virtual
Receita Estadual – RS

Parece que agora estão mudando o posicionamento. O jeito é esperar... Se me retonarem eu posto aqui a resposta.

Editado 6 Junho, 2023 por Otávio Bogoni

[Dércio Luis Zanatta]

3 horas atrás, Otávio Bogoni disse:

Boa tarde, pessoal!

Segue a minha pergunta e resposta obtida da SEFAZ-RS sobre algumas das dúvidas abordadas aqui no tópico:

Pergunta:

Olá, Sou desenvolvedor e tenho dúvidas sobre as modificações necessárias para adequar meu software de automação comercial ao decreto nº 56.670. Meu software já possui TEF integrado (cartão e pix), emitindo a NFC-e com código de autorização das transações ( para transações com cartão, no campo "cAut", como previsto no manual da NF-e) e também imprimo comprovante com os dados da transação junto com a nota. Ou seja, após o pagamento o cliente recebe dois papeis: a NFC-e e um comprovante TEF, ambos impressos pelo mesmo sistema e equipamento. Contudo, ao ler a seção de perguntas frequentes do site sobre esse tema, vi que é necessário incluir campos a mais no comprovante, como um código identificador gerado por mim (diferente do código de autorização ou NSU referentes a transação TEF). O problema é que, atualmente, a integração de TEF (SiTef) que utilizo não permite a edição do comprovante de pagamento impresso. Nesse caso, seria necessário implementar a impressão de um terceiro papel como comprovante que teria esse código identificador? Ou o fato de vincular o código da autorização da transação TEF, que é impresso no comprovante atual, com o XML da nota já basta para cumprir as exigências do Fisco? Se for o caso da última pergunta, como ficaria a situação do PIX, visto que não existem campos específicos no XML para informar os dados da transação na nota fiscal? Agradeço desde já.

Resposta:

Está havendo neste momento uma reavaliação dos procedimentos a serem tomados em questões similares a essa. Daremos um retorno sobre essa questão assim que o procedimento estiver definido.

Eduardo S. Benazzi
Auditor Fiscal da Receita Estadual
NAVi  -  Núcleo  de  Atendimento  Virtual
Receita Estadual – RS

Parece que agora estão mudando o posicionamento. O jeito é esperar... Se me retonarem eu posto aqui a resposta.

Problema é que estão reavaliando um monte de coisas com o decreto já em vigor por mais de 30 dias para alguns clientes... Isso gera muita tensão por parte dos clientes. Como se isso não bastasse, já soube de casos em que estão fiscalizando e multando alguns estabelecimentos por não cumprirem as regras (que agora eles estão reavaliando)..  Realmente lamentável !

[DOCFABIO]

Apenas para colaborar:
Não sei se perceberam a alteração no Decreto:

b) número da autorização junto à instituição de pagamento;

Agora assim:
b) código da autorização ou identificação do pedido;

http://www.legislacao.sefaz.rs.gov.br/Site/Document.aspx?inpKey=292768&inpCodDispositive=&inpDsKeywords=

 

[jcaset]

9 minutos atrás, DOCFABIO disse:

Apenas para colaborar:
Não sei se perceberam a alteração no Decreto:

b) número da autorização junto à instituição de pagamento;

Agora assim:
b) código da autorização ou identificação do pedido;

http://www.legislacao.sefaz.rs.gov.br/Site/Document.aspx?inpKey=292768&inpCodDispositive=&inpDsKeywords=

 

Poderiam eles serem mais claros com relação a como isso poderá ser fiscalizado (o que querem efetivamente ver), pq realmente somente colocar na NFCe um código do nosso sistema, a princípio não liga nada a coisa alguma.

Se eles chegarem no estabelecimento com uma relação de códigos e pedirem: "olha, abre teu sistema aí e me mostre as movimentações financeiras com estes códigos" e se satisfazerem somente com as informações do sistema (valores e formas de pagamento), aí tudo certo. Mas, duvido muito que seria assim tão simplista.

Concordo com o Windel que agora dizem que é "só criar um código do próprio sistema", mas depois podem acabar solicitando o vínculo entre o pagamento e este "código do sistema".

[DOCFABIO]

Pois é, tem razão.
Com certeza depois irão ir mais a fundo, acho que no momento eles querem que o pessoal vá se acostumando. Muitos, mas muitos pequenos comércios não informam a forma de pgto, colocam apenas dinheiro, ou crédito loja. Assim esses vão se acostumando a informar a forma de pgto correta pelo menos.
 

 

[DOCFABIO]

Resposta enviada por [email protected]
Quando perguntado sobre o comprovante do PIX que teria 36 caracteres.
Mas se encaixa também no que estamos tratando.

Assunto: RE: NFC-e - Nota Fiscal ao Consumidor Eletrônica: PFV-228141-G5N8G

Bom dia,

Seu questionamento contém um equívoco.

Vocês estão supondo errado que esse código de 36 caracteres é necessariamente o código que deve ser usado na integração. Só que não é assim. 

Esqueçam esse código de 36 caracteres. Não é esse código que deve ser usado na integração.

A legislação determina que a o sistema da empresa deve gerar um código de identificação da operação, e que esse código deve ser impresso no comprovante de pagamento e também informado no campo "cAut" da nota fiscal.

Porém, a legislação não coloca nenhuma determinação sobre a forma pela qual p código deve ser gerado. A empresa é livre para gerar o código que quiser, da forma que achar mais conveniente.

Esqueçam esse código de 36 caracteres. Não é esse código que deve ser usado na integração.

Ao invés disso, gerem um novo código, e usem esse novo código para a integração. Isso é o que deve ser feito.

Precisamos ressaltar que há muitas operações nas quais o pagamento é feito posteriormente. Nessas operações, a empresa PPRIMEIRO emite a nota fiscal, e DEPOIS recebe o pagamento.

Nessas operações, o código de 36 caracteres não pode ser usado de qualquer forma, independente do número de caracteres. Esse código não pode ser usado porque ele somente vai ser gerado depois da emissão da nota fiscal.

A orientação para esses casos é a mesma. Esqueçam esse código de 36 caracteres. Ao invés disso, gerem um novo código, e usem esse novo código para a integração.

[Dércio Luis Zanatta]

3 minutos atrás, DOCFABIO disse:

Resposta enviada por [email protected]
Quando perguntado sobre o comprovante do PIX que teria 36 caracteres.
Mas se encaixa também no que estamos tratando.

Assunto: RE: NFC-e - Nota Fiscal ao Consumidor Eletrônica: PFV-228141-G5N8G

Bom dia,

Seu questionamento contém um equívoco.

Vocês estão supondo errado que esse código de 36 caracteres é necessariamente o código que deve ser usado na integração. Só que não é assim. 

Esqueçam esse código de 36 caracteres. Não é esse código que deve ser usado na integração.

A legislação determina que a o sistema da empresa deve gerar um código de identificação da operação, e que esse código deve ser impresso no comprovante de pagamento e também informado no campo "cAut" da nota fiscal.

Porém, a legislação não coloca nenhuma determinação sobre a forma pela qual p código deve ser gerado. A empresa é livre para gerar o código que quiser, da forma que achar mais conveniente.

Esqueçam esse código de 36 caracteres. Não é esse código que deve ser usado na integração.

Ao invés disso, gerem um novo código, e usem esse novo código para a integração. Isso é o que deve ser feito.

Precisamos ressaltar que há muitas operações nas quais o pagamento é feito posteriormente. Nessas operações, a empresa PPRIMEIRO emite a nota fiscal, e DEPOIS recebe o pagamento.

Nessas operações, o código de 36 caracteres não pode ser usado de qualquer forma, independente do número de caracteres. Esse código não pode ser usado porque ele somente vai ser gerado depois da emissão da nota fiscal.

A orientação para esses casos é a mesma. Esqueçam esse código de 36 caracteres. Ao invés disso, gerem um novo código, e usem esse novo código para a integração.

Mas vai integrar com que esse código que foi inventado ??  Vai ter que imprimir no comprovante ? De que jeito se o texto do comprovante já vem pronto da operadora !  é uma sucessão de desinformação esse decreto que vai entrar para o livro do recordes !!

[jcaset]

3 minutos atrás, Dércio Luis Zanatta disse:

Mas vai integrar com que esse código que foi inventado ??  Vai ter que imprimir no comprovante ? De que jeito se o texto do comprovante já vem pronto da operadora !  é uma sucessão de desinformação esse decreto que vai entrar para o livro do recordes !!

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.