Dércio Luis Zanatta

Boa tarde Estou precisando implementar recebimentos com TEF pelo Sitef no aparelho da Gertec GPOS700x (pin pad interno). Funciona através do componente ?

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...

Essa é a melhor notícia que vi a respeito desse assunto !!

Ai fala de Tele entrega, não fala nada sobre recebimentos não fiscais.. Acredito que isso deveria ficar mais claro no decreto..

Está escrito no Decreto que não está previsto recebimentos não fiscais ? Poderia me mostrar onde ?

"Isso não tem nessa Lei." Nesse caso sos clientes deverão continuar fazendo as transações de forma não integrada ?

OU seja, continua as dúvidas... 1 - Como faz com PIX ? 2 - Como faz com recebimentos não fiscais ? (contas, crediário, etc...) ??

Bom dia.. Eu sinceramente não vejo outra foram de atender ao decreto sem TEF !

Bom dia Bruno.. Concordo com vc que é uma mudança bem brusca que estão implantando, mas não tem volta cara.. A Receita quer evitar ao máximo fazer transações de pagamentos eletrônicos não integrados ao documento fiscal.. Ao meu ver, máquinas POS não integrada não será mais possível utilizar.. a empresa vai ter que ter TEF integrado no sistema de automação comercial, isso é fato.. Além disso vai ter que compartilhar uma conexão de celular (3G,4G ou 5G) em sua rede de PDVs.. A Receita não aceita mais a desculpa de usar o POS não integrado como forma de contingência quando não tem internet na loja.. Se o POS consegue fazer as transações pela REDE móvel, então os PDVS tb devem conseguir.. Para isso será necessário algum investimento por parte dos lojistas... Tem duas questões que ainda vão ter que ser clareadas.. 1 - PIX 2 - Recebimentos não fiscais (Recarga de Celular, pagamento de contas, Recebimento de crediário, etc...) Esses dois pontos, nem a SEFAZ sabe ainda como regular... Fora isso, acho que está bem claro o que deve ser providenciado pelos lojistas... Da parte das SoftwareHouses, apenas deve disponibilizar TEF no Sistema. A conexão é problema do lojista, na minha humilde opinião.

Bom dia pessoal... Pelo menos para mim ficou claro que a SEFAZ não quer permitir digitação de dados entre o sistema de emissão de NFCe e as máquinas POS, apesar de se contradizerem em algumas respostas. Acho que deveriam esclarecer esse ponto de uma vez por todas. Caso fique claro que não se poderá digitar nada, acho que deveriam envolver os fabricantes de POS para desenvolver alguma forma de integração automática, coisa que hoje não existe !

Sem nenhuma dúvida é um grande progresso que o pessoal da Receita esteja aberto a ouvir a comunidade.. acho isso um avanço enorme.. De minha parte tenho dúvida em dois pontos chaves (que já postei aqui anteriormente). No momento em que alguém me disser como fazer em relação a esses dois pontos (de forma direta e clara), acho que ficará esclarecido totalmente..

Assisti a Live agora e para mim , além de não esclarecer como fazer, ainda geraram mais dúvidas... 1 - No caso de usar um POS para casos de contingência (onde não é possível usar TEF naquele momento). Pelo que está na Live, deve-se integrar o pagamento feito no pos com o sistema de frente de caixa sem intevenção humana, ou seja, não é permitido que a entrada dos dados seja feita de forma manual. Alguém sabe como capturar os dados do comprovante feito no POS ? Isso já existe hoje ? 2 - Nos casos de pagamento de parcelas (carnês), a solução sugerida pelo pessoal da receita, seria fazer uma NFCe com um ítem contendo o CFOP 5949. Atualmente esse CFOP é rejeitado na NFCe, só aceito na NFe. Além disso, esse ítem seria registrado com qual NCM ?

Bom dia Para atender a legislação de pagamentos com Transferência eletrônica de Fundos no Rio Grande do Sul, se torna necessário o preenchimento da tag cAut para formas de pagamento que não sejam com cartão de crédito ou débito. Para pagamentos com a forma 05-Crédito Loja, será necessário preencher essa tag cAut com um código de autorização aleatório. Caso o pagamento dessa nfce seja feito futuramente com cartão de crédito ou débito, esse código aleatório deverá ser impresso no comprovante da transação TEF. Como sugestão, para ficar bem flexível, não deveria se condicionar a tag cAut a uma ou outra forma de pagamento. Fica a critério do sistema, preencher a tag quando necessário, independente da forma de pagamento utilizada e, sempre que a tag for preenchida, gerar a mesma no xml e imprimir junto a forma de pagamento da Danfe.

Saiu alguma atualização da NT onde informe claramente que NINGUÉM MAIS PODERÁ USAR MAQUININHAS POS, e que todos terão obrigatoriamente implementar TEF em suas aplicações ? e até quando ? Pergunto isso, pois o próprio auditor da Receita, deixa bem claro em suas respostas o contrário disso !

Não.. Nas maquininhas POS atuais, não existe possiblidade de digitar código nenhum.. Acredito que nenhuma administradora fez nada nesse sentido. Esse questionamento eu fiz par ao auditor da SEFAZ-RS, mas fiquei no vácuo, sem resposta !

Isso contradiz o que o próprio auditor da SEFAZ-RS respondeu : "A respeito dessa questão, precisamos esclarecer que o Decreto 56,670 não veda a utilização de máquinas POS, e também não torna obrigatória a utilização do sistema TEF> Isso é um engano." Será que estão perdidos ?

Bom dia. Foi exatamente o que eu questionei com relação ao POS. Se querem permitir o uso de POS, vão ter que mexer no software básico das maquininhas... Ai não respondem mais ! Acho que viram que não tem como atender a regra que criaram e estão estudando uma solução (eu espero)

Mas que sentido tem isso ? guardar códigos aleatórios nos bancos de dados dos clientes ? Ai quando vão auditar vão achar o código 123 no Caut de uma NFCe !! e ai ?? que relevância tem essa informação ? Vão procura o comprovante impresso com esse número para ver se ele realmente existe ?? Totalmente fora do meu entendimento isso ai ...

Aiii que eu me refiro !! Esse negócio de gerar um código de controle para vincular a NFCe ao comprovante não faz sentido !! O Auditor da SEFAZ-RS inclusive cita que é possível fazer a NFCe antes de fazer a transação no POS... Segundo ele nesse caso deve-se gerar um número de controle e imprimir isso no comprovante ! Como vou imprimir algo no comprovante do POS ?? !! E o pior ... ninguém esclarece nada !! cada um está fazendo conforme seu próprio entendimento e não existe uma regra clara !

Boa tarde... a confusão continua e a SEFAZ-RS nem responde mais.. nesse seu caso, quando a operação é feita no POS, o cliente sairá da loja com dois comprovantes ? um da operadora e outro do "controle interno" ? O que não entendo é como a SEFAZ-RS vai auditar isso ? onde eles vão ver essa transação do cartão através do "controle interno" ?

Recebi agora as seguintes respostas por parte da SEFAZ: Bom dia, Respondo seus questionamentos abaixo. 1 - Nos casos em que o comprovante for impresso no POS, como devo proceder o preenchimento dos dados da transação nas tags do xml da NFCe? Devo solicitar que o usuário digite o número do NSU (código de autorização) gerado pelo autorizador e impresso no comprovante do POS e preencher a tag Caut do xml com esse código ? é obrigatório somente o NSU ? ou será obrigatório também o preenchimento do código do autorizador, código da bandeira e tipo de transação (Crédito, débito ou voucher) ? A Normativa determina que um código da operação deve ser gerado, e que esse código seja informado no comprovante de pagamento e na nota fiscal. O objetivo é que seja possível relacionar especificamente qual pagamento corresponde a qual nota fiscal. Porém, a Normativa não determina nenhum método específico elo qual o código deva ser gerado e informado. a empresa pode usar o método que achar mais conveniente. Se a empresa utiliza sistemas de pagamento e de emissão de nota fiscal que se conectem, então o sistema da empresa provavelmente vai gerar um código da operação e informar nos 2 documentos de forma automática,, sem necessidade de interação com o usuário. E no caso de pequenos comércios nos quais o sistema de pagamento e de emissão de nota fiscal não sejam integrados, então o código provavelmente seria gerado por um sistema e digitado no outro. Temos recebemos alguns questionamentos se isso não iria inviabilizar o pequeno comércio. Não, não iria. Atualmente, quando o pequeno comercio recebe um pagamento em cartão, ele já tem que digitar o valor da operação no equipamento. Com essa operação, ele teria que digitar o valor da operação e mas um número. Trata-se no máximo de uma inconveniência, mas não de algo que vá impactar no negócio. Quanto à gestão sobre ter que informar tipo de transação (crédito, débito ou voucher), isso não é nenhuma novidade. Isso já estava sendo feito antes da Normativa. Na NFC-e, existe o campo "Meio de pagamento" (tag "tPag", no arquivo XML. Esse campo informa se o pagamento está sendo feito om cartão de crédito, cartão de débito, ou outra forma diferente. Trata-se de um campo de preenchimento obrigatório na NFC-e. Esse campo já existia antes, e não foi criado agora. Terei que imprimir outro comprovante após a impressão da DANFe NFCe, já que o texto da lei diz que o comprovante deverá ser impresso no mesmo equipamento da DANFE ?. Se sim, o que devo imprimir nesse comprovante ? tem que ser um duas vias ? o Cliente vai sair da loja com dois comprovantes nesses casos ? Novamente, não se trata de uma novidade. Muitas empresas já estão fazendo isso antes da Normativa. Se você for em um restaurante e fizer o pagamento com catão, então o restaurante provavelmente vai lhe dar 2 documentos, uma NFC-e e um comprovante de pagamento. O item da lei que diz que a impressão deve ser feita no mesmo equipamento está em revisão e provavelmente deverá ser removido. 2 - Como existe um número grande de autorizadores no mercado e um número maior ainda de bandeiras e o número do NSU/código de autorização normalmente contém vários dígitos, existe uma possibilidade enorme de erro de digitação por partes dos usuários durante o processo de digitação. De quem será a responsabilidade caso as informações sejam inseridas de forma errada ? Como regra geral, para qualquer campo que tenha sido preenchido de forma incorreta na NFC-e, a responsabilidade é da empresa emitente. Da mesma forma que, por exemplo, se a empresa cometer um erro de digitação ao informar o valor da operação. A responsabilidade será da empresa emitente. Existem procedimentos previstos na legislação para tratar erros de preenchimento na nota fiscal. O procedimento exato a ser seguido pode variar, de acordo com a natureza específica do erro. Se a empresa cometer um erro da digitação na nota fiscal e não souber qual é o procedimento para corrigir, então a empresa pode entrar em contato conosco e daremos a orientação. 3 -As transações PIX podem gerar um código de autorização com mais de 20 caracteres. Como preencher a tag Caut nesses casos, já que o tamanho máximo previsto dessa tag é 20 ? Vocês estão supondo que esse código gerado pela transação PIX é necessariamente o mesmo código que deve ser informado na nota fiscal. Trata-se de um engano. Conforme mencionado abaixo, a Normativa não define um método específico para gerar o código. A empresa pode gerar o código da forma que achar mais conveniente. O código da operação não precisa ser esse que foi gerado pela transação PIX, pode ser outro código. O importante é que um código seja gerado e informado nos 2 documentos. Além disso, há casos em que as empresas PRIMEIRO emitem a nota fiscal, e DEPOIS recebe o pagamento. Nesses casos, o código gerado pelo PIX não poderia ser usado de qualquer forma, independente do número de dígitos. Ele não poderia ser usado porque ele somente vai ser gerado depois da emissão de nota fiscal. Assim, esqueçam esse código gerado pelo PIX. Não é esse código que deve ser informado. Ao invés disso, gerem um novo código no sistema da empresa, e informem esse código nos 2 documentos. 4 - Quando um cliente quiser pagar um título de crediário com cartão de crédito/débito ou pix. Como proceder nesses casos, já que não haverá NFCe envolvida nessa transação ? Na verdade, há sim uma NFC-e envolvida na transação. A NFC-e é emitida no momento da venda. O que vocês querem dizer é que o pagamento é feito posteriormente, e não há emissão de NFC-e no momento do pagamento. O código da operação deve ser gerado no momento da transação do pagamento eletrônico, ou então no momento de emissão da nota fiscal, o que vier antes. Uma regra simples que várias empresas estão adotando, é que o código de integração seja gerado pelo sistema que for usado antes. Depois, o mesmo código é informado no outro documento. Ou seja: Se a empresa PRIMEIRO receber o pagamento, e DEPOIS emitir a nota fiscal, então o código de integração é gerado pelo sistema de pagamento, no momento da transação do pagamento. Depois, o mesmo código é informado na nota fiscal. Por outro lado, se a empresa PRIMEIRO emitir a nota fiscal, e DEPOIS receber o pagamento, então o código de integração é gerado pelo sistema emissor da nota, no momento da emissão. Depois, o mesmo código é informado no comprovante de pagamento. A respeito dos casos em que a empresa faz a venda, e o pagamento é feito posteriormente. Nesse caso, quando o documento fiscal for emitido, então o sistema da empresa deverá gerar o código de identificação da operação, e informar esse código no campo específico da nota fiscal (tag "cAut", no arquivo XML). Esse código ficaria registrado no sistema da empresa, para consulta posterior. Mais tarde, quando o cliente realizar o pagamento, o sistema poderia verificar qual é a nota fiscal que está sendo paga, consultar qual é o código de identificação correspondente, e informar esse mesmo código no comprovante de pagamento. Pelo que entendi, nos casos de equipamentos POS, o tal do "código de integração" deverá ser gerado no sistema que fizer a operação primeiro, ou seja.. Se fizer o pagamento no POS e depois fizer a NFCe, então digita-se o NSU gerado pelo POS na NFCe e informa na tag Caut. Se a NFCe for feita primeiro, o Sistema de automação comercial deverá gera um código de integração qualquer(aleatório), informar esse código na tag Caut da NFCe e posteriormente INFORMAR ESSE CÓDIGO NO POS QUANDO FOR FAZER A TRANSAÇÃO DO PAGAMENTO. Até onde eu sei, não existe nenhum campo atualmente no Software básico da NFCe onde se possa informar alguma coisa durante a transação.. Para isso os fabricantes de POS vão ter que altera seus Softwares básicos para atender o decreto ? Fiz esse questionamento ao auditor e estou aguardando resposta. No caso de pagamento de título de crediário, acho que ele ainda não entendeu do que se trata.. No momento da emissão da NFCe a forma de pagamento é CRÉDITO LOJA, isso gera um título no contas a receber da empresa que posteriormente poderá ser pago com cartão de débito. Nesse caso, não vai ser possível informar o código de integração no momento da emissão da NFCe, pois ainda não se sabe se o cliente vai ou não pagar com cartão posteriormente. Sinceramente, acho que deveriam repensar esse Decreto e na confusão que estão causando no comércio do RS atualmente. Fica claro que não sabem como as transações de pagamento funciona atualmente. Vamos aguardar cenas dos próximos capítulos !

Boa noite. Enviei os seguintes questionamentos para a SEFAZ-RS.. Acredito que minhas dúvidas são as mesmas de muita gente. Procurei ser o mais resumido e claro possível, na esperança que as respostas também sejam: Boa noite. Sou desenvolvedor de Sistema de automação comercial e tenho alguma dúvidas com relação a nova lei que obriga a vinculação de NFCe ao pagamento com cartões de crédito ou qualquer outro meio eletrônico de pagamento. Recentemente li algumas respostas desse canal a outras pessoas e nelas me chamou a atenção o fato de que as transações eletrônicas poderão continuar sendo autorizadas com POS(maquininha de cartões). Nesse ponto gostaria de alguns esclarecimentos: 1 - Nos casos em que o comprovante for impresso no POS, como devo proceder o preenchimento dos dados da transação nas tags do xml da NFCe? Devo solicitar que o usuário digite o número do NSU (código de autorização) gerado pelo autorizador e impresso no comprovante do POS e preencher a tag Caut do xml com esse código ? é obrigatório somente o NSU ? ou será obrigatório também o preenchimento do código do autorizador, código da bandeira e tipo de transação (Crédito, débito ou voucher) ? Terei que imprimir outro comprovante após a impressão da DANFe NFCe, já que o texto da lei diz que o comprovante deverá ser impresso no mesmo equipamento da DANFE ?. Se sim, o que devo imprimir nesse comprovante ? tem que ser um duas vias ? o Cliente vai sair da loja com dois comprovantes nesses casos ? 2 - Como existe um número grande de autorizadores no mercado e um número maior ainda de bandeiras e o número do NSU/código de autorização normalmente contém vários dígitos, existe uma possibilidade enorme de erro de digitação por partes dos usuários durante o processo de digitação. De quem será a responsabilidade caso as informações sejam inseridas de forma errada ? 3 -As transações PIX podem gerar um código de autorização com mais de 20 caracteres. Como preencher a tag Caut nesses casos, já que o tamanho máximo previsto dessa tag é 20 ? 4 - Quando um cliente quiser pagar um título de crediário com cartão de crédito/débito ou pix. Como proceder nesses casos, já que não haverá NFCe envolvida nessa transação ? Sem mais, aguardo retorno de minhas dúvidas para que possamos orientar nossos clientes e atender a lei de forma clara e correta. Muito obrigado. Assim que receber alguma resposta, posto aqui.. abraços..

Sim, claro... Nesse caso, vou precisar instalar o certificado .pfx e passar o número de série para o componente .. certo ?

Bom dia Ítalo o Problema ocorre tanto no Delphi 7 (meu sistema) quanto no Delphi 10.4 (Aplicativo exemplo). Utilizo libOpensSSL Sim, o valor do SSLType é LT_TLSv1_2

Bom dia Estou enfrentando um problema com o provedor IPM, cidade de Gravatai - RS. Se enviar 3 notas em sequencia, na terceira nota, retorna o erro HTTP 401 no acesso a URL do webservice. Para simular o problema no exemplo do ACBR, basta configurar um emissor de uma cidade que usa IPM e enviar 3 notas em sequencia. Somente depois de fechar o exemplo e abrir novamente é que volta a funcionar. OBS: Para contornar o problema estou dando um free no componente e criando ele novamente a cada envio. Assim o problema não ocorre.