WINDEL

Estou utilizando o componente ACBrAbecsPinPad para enviar a imagem do QRCode para o PIN PAD. Notei que esse erro ocorre aleatoriamente, em alguns momentos funciona o envio da imagem sem erros e em outras causas o erro aparece. O erro ocorre quando aciono o comando "ACBrAbecsPinPad1.DSI" para enviar imagem ao PIN PAD. Para simular o erro segui os seguintes passos utilizando o aplicativo demo PinPadTest. - Abrir o aplicativo e clicar no botão "Activate" - Ir na aba Multimedia e clicar no botão "Send To PinPad". A imagem aparecerá no visor do Pin Pad, porém ocorrerá um erro de timeout e isso impossibilita a execução dos próximos comandos. Estou utilizando para testes o PIN PAD PPC-930 versão 2.12 e estou com os drivers do fabricante instalados e atualizados. Pode fazer alguns testes com esse equipamento? LogArqPinPad.txt

Bom dia. De onde veio esse e-book?

Não é pra enviar na cAut o código do pix. No outro tópico referente ao assunto, está sendo falado sobre a forma "correta" de envio.

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.

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.

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?

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

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

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

Pelo que vejo aqui, todos estamos no mesmo barco. Todos com dúvidas sobre qual o procedimento correto e enquanto isso, o decreto em vigor. Realmente, uma piada. O que eu acho mais engraçado é que na live ali que teve, tudo parece lindo e maravilhoso, claríssimo, porém, chegamos aqui no tópico e percebemos que existem diversas dúvidas e todas praticamente são as mesmas. Não existe uma possibilidade de a tal AFRAC reunir essas dúvidas apresentadas aqui, que são dúvidas REAIS de softwarehouses e contabilidades e levar isso para a receita, para tentar esclarecer o assunto? Ou até melhor, tentar abordar o assunto da criação de um evento de pagamento em vez desse papo furado de o software emissor criar um código qualquer e informar nos documentos?

Não seria muito mais fácil criar um evento de vinculação de pagamento, aonde as próprias maquininha POS poderiam se responsabilizar por realizar este vínculo? Desta forma, um pouco da responsabilidade também é transferidas para as maquininhas e não somente em cima do software emissor. A minha maior dúvida ainda é referente aos equipamentos POS. Hoje, não existe uma integração entre ERP e maquininha POS. As possíveis soluções que todo mundo fala é que é possível desenvolver a sua aplicação para android e blah blah, só que quem trabalha com delphi, sabe que não é bem assim. Além das inúmeras versões que precisarão ser instaladas para compilar para todos os tipos de android que rodam nas POS, ainda tem o fato de que terá que estar sempre investindo em licenças novas anualmente. Outro ponto que até chegou a ser comentado ali no debate da AFRAC, foi a questão da contingência. Informaram que neste caso, a NFC-e poderia ser emitida em contingência e o pagamento, realizado na POS, e aí isso deveria criar o vínculo com a NFC-e que foi emitida em contigência. Como assim? Se você está com problemas de conexão, como é que vamos comunicar com o WS da POS para capturar os dados de pagamento?

Em resumo, até agora: os decretos e incisos nos dizem uma coisa, os manuais da NFC-e, dizem outra, os auditores fiscais da receita nos respondem de forma contraditória e a AFRAC realiza reuniões fechadas com o fisco e repassam outra informação. Chega ser um descaso.

A própria normativa informa que é possível utilizar equipamento POS, desde que esteja vinculado ao CNPJ do estabelecimento, além de termos respostas aqui neste tópico aonde o auditor da receita informa que pode ser usado, desde que vinculado ao documento através da cAut. Agora com esse comentário, voltamos novamente a estaca 0, aonde é obrigatório a utilização de TEF, assunto que também foi respondido pelo auditor da receita, informando que estamos errados ao afirmar isso. Não faz muito sentido, o fisco vai fazer o que daí? Passar em todos os estabelecimentos do estado recolhendo as POS? E quando não houver conexão de internet no estabelecimento, uma POS poderia muito bem ser utilizada como dispositivo de contingência, visto que o TEF não irá funcionar, aí neste caso se faz o que?

O que pode ser feito, na verdade, é aprovar a transação na POS antes de efetuar a emissão da NFC-e, aí o emissor insere o número da transação gerado pela POS no seu sistema. O sistema então, informa o número de autorização, bandeira, etc, digitados nas tags respectivas as informações de cartão da NFC-e e envia o documento para aprovação. Este processo funcionaria muito bem nos casos em que a transação é efetuada antes ou durante a emissão do documento, porém pelo que entendi, eles estão tentando estudar uma maneira de vincular as transações que são efetuadas após a emissão da nfc-e. Desta forma, o software do emissor geraria um hash lá responsável por criar o vínculo da transação efetuada e a emissão da nota de consumidor. A dúvida que resta é como que essas informações seriam cruzadas. Seria criado alguma exportação? Seriam criados novos campos no sped? Como é que isso seria fiscalizado? Atualmente, podemos inserir qualquer bobagem lá na tag cAut e isso seria considerado o código de interligação entre o documento e o comprovante, porém de que forma eles iriam cruzar esses dados. Pense que podemos informar lá na cAut a string receitafederal e isso passaria a ser considerado como um código de autorização. No meu ponto de vista, não faz sentido. Se a ideia é criar códigos, deveria seguir um padrão com chave de acesso de um documento, entre outras formas, resumindo, um código único para cada documento. Pense quantos códigos 123 irão existir nas NFC-e e como que essas informações serão fiscalizadas. Não faz sentido.

Ótimo apontamento. O problema é argumentar essa solução com a receita. Mal estão respondendo os questionamentos, quem dirá aceitar novas sugestões. Você chegou a enviar essa sua colocação lá no fale conosco da receita, para ver o que o auditor responderia?

A hora que forem fiscalizar, certamente eles vão querer rastrear o código aprovado pela operadora e não o fictício criado pelo seu sistema. Você tem que vincular o gerado pela operadora com o seu código gerado internamente, senão, de nada serve esse código que você está gerando. Em casos de bater os dados do pagamento com o recebido no banco pelo cliente, você nunca terá o NSU real das trasações...

Mas e se o seu cliente fosse receber um pix via QRCode estático, aí não seria utilizado a integração com o TEF. Como você faria nesse caso?

Sim, mas, você está criando um código qualquer e inserindo na NFC-e. Como é que você está vinculando esse código que você está criando para o pix com a autorização real que veio lá do banco? Exemplo: A autorização real gerou o código 321651313212132132145465. Sua aplicação, informou o código 1 na NFC-e. De que forma você está vinculando o seu código 1 com o 321651313212132132145465 gerado pelo banco?

Mas vocês estão vinculando a transação verdadeira com a que vocês geram de que forma?

Por enquanto entendo que nós como software, criaríamos um código qualquer, o qual seria inserido na nfc-e, imprimiríamos um comprovante com os dados solicitados pela legislação que estão destacados no decreto e posteriormente o cliente(emissor) deverá informar no sistema os dados da autorização na POS ou transferência, etc. Desta forma, estaríamos inserindo um código no documento conforme solicitado pela legislação e o registro de vínculo estará no banco de dados do sistema do emissor. Alguns problemas que percebo: Estaríamos utilizando a tag cAut em desacordo com a orientação do manual; A aplicação pode gerar qualquer bobagem lá na tag cAut, desde que tenha no banco de dados o vínculo entre o código gerado e o código real da transação gerada pela maquininha ou qualquer outro meio de pagamento. Imaginem quantas NFC-e seriam emitidas com código 1 na tag cAut. Vai ficar bem bom pra rastrear essas informações; O cliente pode digitar errado o código de autorização, ou, nem sequer digitar; Como seria a fiscalização disso? Será criada uma exportação de dados? Depois que os campos específicos forem criados, novamente teremos de ajustar os softwares.

Bom dia. Sobre essa reunião recente, foi divulgada alguma informação que possa nos ajudar a esclarecer melhor o assunto? Hoje já estamos iniciando as adaptações no sistema com as informações que temos até agora aqui no tópico, apesar de discordar da maioria das indicações dos auditores fiscais e cabe ressaltar que é necessário modificar o próprio componente do ACBr para conseguir enviar a tag solicitada. Se a AFRAC já se reuniu com a SEFAZ, seria de suma importância que as informações obtidas fossem divulgadas de alguma forma a todos.

Da forma como está sendo solicitado, entendo que terá o comprovante da maquininha POS e também um segundo comprovante gerado pelo sistema, o qual seria responsável pelo "vínculo" do pagamento e o documento. Desta forma o emissor teria de digitar os dados da transação no sistema, para que esse segundo comprovante fosse gerado e entregue ao consumidor. Além de não ser um processo prático, não consigo entender como seria a fiscalização disso... Seria muito mais simples eles estenderem novamente a aplicação do decreto e somente aplicá-lo quando o layout contiver os campos determinados.

Você pode criar uma função aonde você passe a sua bandeira como string e a função te retorna TpcnBandeiraCartao. Exemplo: if (pos('visa',pBandeira) = 1) then Result := bcVisa As bandeiras estão na unit pcnConversao

Fui tentar atualizar agora pela manhã e deu erro em um arquivo, movendo-o para a quarentena: Tem certeza absoluta que é um falso positivo? Já geramos alguns executáveis aqui na empresa e estão começando a acusar infecção também, porém não tínhamos percebido que havia sido após atualizar o acbr.

Até o momento sabemos que a exigência da vinculação do pagamento ao documento fiscal somente será aplicada nas operações presenciais, ou seja, quando se tratar de uma tele entrega, aonde o pagamento será realizado posteriormente a emissão do documento fiscal, não seria obrigatório. - "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". Também consta no anexo PFV-226770-L0G3H, que o item "29.5.1.2 - Na hipótese de impressão do DANFE da NFC-e, deve ser utilizado o mesmo equipamento para a impressão do comprovante referido subitem 29.5.1.", está sendo analisado e deverá ser removido da legislação, porém, não há detalhamento de como ou quando isso iria ocorrer. Entrando na parte da solicitação de vinculação do pagamento ao documento fiscal, precisamos primeiramente analisar o Grupo YA. Informações de Pagamento, conforme MOC 7.0 - Anexo I - Leiaute da NF-e/NFC-e (https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=J I v4eN00E=). Atualmente, existe o grupo card, composto pelas tags: YA04a - tpIntegra(Tipo de Integração para pagamento) YA05 - CNPJ(CNPJ da instituição de pagamento) YA06 - tBand(Bandeira da operadora de cartão de crédito e/ou débito) YA07 - cAut(Número de autorização da operação cartão de crédito e/ou débito). Gostaria que atentassem a essa tag principalmente. Lembrando que o tamanho é 1-20. Como o item 29.5.1 do decreto nos diz que praticamente todo tipo de pagamento deva estar ligado a NFC-e, questionamos então a receita sobre de que forma deveria ser feita essa interligação, visto que nosso MOC atual não prevê campos para transferência de recursos, transações eletrônicas do Sistema de Pagamento Instantâneo ou demais instrumentos de pagamento eletrônico e sim campos específicos para operações com cartões de crédito ou débito. Recebemos então a resposta que já imaginávamos, aonde os campos não existem ainda na NFC-e e que em um futuro próximo eles devem ser criados, porém novamente, sem nenhuma previsão. Conforme as outras respostas recebidas, a orientação por parte de receita é de que utilizemos a tag cAut para vincular o pagamento junto da NFC-e, o que nos traz algumas dúvidas: É correto utilizar um campo que está detalhado no layout da NFC-e como uso em operações com cartão de crédito/débito para vincular um pagamento como pix ou transferência bancária? Supondo que informemos o código da autorização da transação na tag cAut, muitas vezes esses códigos ultrapassam o limite de 20 caracteres. Como proceder? Foi comentado sobre a aplicação do cliente gerar um código interno, inserindo esse código gerado na NFC-e e armazenando os detalhes da transação no banco de dados. Como é que a receita iria cruzar essas informações? O sistema do lado do emissor poderia gerar qualquer bobagem lá, apenas respeitando o limite de 20 caracteres... Como isso seria fiscalizado? Nesse primeiro momento, o correto não seria então somente vincular as operações com cartões, desconsiderando PIX e transferências? No caso aonde devêssemos informar os dados de uma transação para o vínculo que ainda não possui campo próprio no layout, não seria mais correto utilizarmos algum outro campo, como exemplo o infAdFisco(campo texto livre de 2000 posições)? Em um caso aonde a NFC-e esteja sendo digitada, a transação é efetuada por uma maquininha POS, vinculada ao CNPJ do emissor, conforme item 1.1 da INSTRUÇÃO NORMATIVA RE Nº 108/22(http://www.legislacao.sefaz.rs.gov.br/Site/Document.aspx?inpKey=292768&inpCodDispositive=&inpDsKeywords=108) e o sistema do emissor abre o campo para digitação, aonde o emissor irá informar o código da autorização recebido pela POS e esse código informado é anexado nas tags próprias da NFC-e, esta operação não estaria correta e não seria muito mais simples cruzar os dados em caso de fiscalização? Supondo que o estabelecimento tenha algum problema com energia elétrica, impossibilitando o uso de um computador, por exemplo, e trabalhando durante um determinado período com uma máquina POS, como seria realizado o vínculo do pagamento com a NFC-e? Visto que o pagamento já tenha ocorrido antes da emissão. Enfim, as informações especificadas na documentação e nas indicações não estão claras e sinceramente, essa história de que o sistema do emissor deva gerar um código e anexar na tag de cartão, não faz sentido. O mais preocupante é que o decreto já entra em vigor daqui 5 dias...