Dércio Luis Zanatta

7 Fevereiro

Bom dia.

Estou enfrentando um problema aqui e gostaria de saber se alguém já achou alguma solução para ele..

A impressão da Danfe NFCe pelo componente do ACBr para Fortes Report está cortando quando a página atinge 30 cm.

Já atualizei o FortesCe e o ACbr tb.. Já tentei diversas configurações de página e nada funciona. Em impressoras de outras marcas funciona perfeitamentem somente nessa Epson é que isso ocorre..

13 Setembro, 2023

2 minutos atrás, PbNew_Sistemas disse:

olá pessoal, alguém sabe se o evento de ontem (12/09/23) da Afrac ficou gravado?

Também tenho interesse nisso !

16 Agosto, 2023

1 minuto atrás, dalves25 disse:

Obrigado pelas dicas. Vou estudar a situação. Cliente pequeno, vai ser difícil investir nisso.

Realmente essa questão é bem complicada ... Se por um lado fazer emissão da NFCe já integrando o pagamento com TEF, vai facilitar a vida do cliente, pois ele já terá o documento fiscal integrado a sua base de dados e também todas as transações TEF (feitas na loja ou não), tudo num só lugar, o que facilita a conscliação. Quanto ao custo, o investimento não é tão baixo... Vale o cliente analisar a questão do custo/benefício.

Uma observação: Tenho um pensamento um pouco diferente em relação ao conceito de "entrega a domicílio".. No meu entendimento, entrega a domicílio é quando o cliente compra a mercadoria e vai pagar no momento em que ela for entregue juntamente com a NFCe em seu domicílio . Nesses casos onde a venda será efetivada em outro local que não seja o local físico do emitente a venda é presencial (na minha humilde opinião).

15 Agosto, 2023

8 horas atrás, dalves25 disse:

Boa Noite, Alguém que tenha uma situação parecida:

Lojista vai participar de um evento externo, vai levar alguns produtos e vender neste evento. Lá não irá levar PC nem o TEF. Somente a POS. Na volta emite as NFCe, porem não dá para colocar pcEntregaDomicilio porque não ira pegar os dados do comprador (obrigatórios nesta modalidade). E se colocar como pcPresencial estaria obrigado a usar o TEF.

Como procedo nesse caso? Lembrando que o NFCe só aceita essas duas modalidades de "indPres".

Bom dia amigo.

Nós temos essa situação em alguns clientes.. Nesse caso desenvolvemos uma aplicação Android e embutimos nos aparelhos Gertec GPOS 700x. Essa aplicação faz a NFce comunicando com uma API Horse que também desenvolvemos. A operação com TEF é integrada com o SitefExpress usando o M-Sitef no aparelho.

5 Julho, 2023

3 minutos atrás, Lucas Camargo disse:

Bom dia!
Neste caso a operação é considerada delivery e não está coberta pela obrigação da legislação, não precisa ser informada a vinculação na NFC-e, ao menos por enquanto.
Precisa indicar na emissão desta NFC-e que se trata de uma operação não presencial.
Essa foi uma das perguntas que surgiu na live da AFRAC realizada no dia 14/06/2023, logo mais vou trazer aqui um material que anotei sobre a live.

Tem razão... não existe obrigatoriedade dessa integração hoje, porém os clientes (ao menos os meus) estão vendo uma facilidade em fazer tudo na hora da entrega.. Não precisam mais gerenciar isso na retaguarda, lembrar em fazer a nfce quando voltam pra empresa, fica tudo pronto na hora.. Vejo isso como uma ótima oportunidade de oferecer um produto para esse ramo de negócio que vai facilitar os processos deles.

5 Julho, 2023

10 horas atrás, dalves25 disse:

Boa Noite! Como fica quando o entregador sai para fazer a entrega e leva junto com ele a maquina POS, e na volta faz a NFCe? Alguem tem essa situação e sabe como proceder?

Bom dia

Vai ter que oferecer um Smart POS onde vc possa embarcar um app Android que faça a NFCe e o pagamento integrado com TEF. POS não integrado não pode ser mais utilizado. Nós aqui da empresa desenvolvemos um app Android e estamos utilizando o Gertec GPOS 700x para atender uma gama de clientes que tem essa necessidade.

4 Julho, 2023

10 minutos atrás, claudiomiguelmuller disse:

Eu mando o NSU registro 012-000 do PayGO para o cAut, até onde entendi era este pra mandar. Abra um tópico novo deste problema e não neste post que discute apenas a lei em si. E eu também estou com problemas com Vero quando tentamos usar BANRICARD, no POS passa normal, pelo PayGO diz produto inexistente. A PayGO disse que era com a Vero a Vero diz que é com a PayGO.

Bom dia

Existem dois retornos nas transações TEF.. O número do NSU e o código da transação. A tag do Xml da NFCe se chama Caut - Código da autorização, logo entendo que deve-se jogar o código da autorização nessa tag e não o NSU.

3 Julho, 2023

Boa tarde

O autorizador VERO não está retornando o código de autorização da transação (tipocampo=135 do Sitef). Já entrei em contato com o suporte da Softwareexpress e os mesmos me informaram que não estão recebendo essa informação da VERO e que tem que entrar em contato com eles para repassar o problema. Estou a tarde toda tentando falar com alguém da VERO, já tentei 5 canais diferentes e em nenhum deles os atendentes sabem o que é TEF !! Por hora estou passando o NSU no lugar do código da autorização para não ficar em branco a tag Caut do xml.

Alguém já se deu conta desse problema ?

29 Junho, 2023

6 minutos atrás, yurizampeze disse:

Certo, entendi.
Mas isso não cobre todas as possibilidades, aqui no RS eu sei que tem muita gente que faz a compra no crediário e depois fica pagando a parcela via PIX, sem ir presencialmente na loja, o que resultaria em um pagamento não fiscal sem TEF. Complicado.

O pagamento com PIX só é obrigatório ser integrado com a NFCe quando feito por QrCode Dinâmico.. senão está fora da regra..

29 Junho, 2023

43 minutos atrás, yurizampeze disse:

Esse recebimento de crediário ainda é um mistério pra mim, alguém tem mais alguma informação sobre isso?

Na teoria é relativamente simples.. Deve-se fazer uma NFCe com um ítem de CST 90(para regime normal) ou CST 900(para Simples) e CFOP 5949. Na tag CAut dessa NFCe deve-se informar o código de autorização obtida na transação TEF. O problema é que na prática a SEFAZ-RS ainda não está aceitando esse CST para NFCe, o que já deveria estar fazendo (em homologação)

29 Junho, 2023

19 minutos atrás, claudiomiguelmuller disse:

NCM=00 não vai deixar nunca, tem que ter um NCM válido.

Eu também tenho dúvida: interliguei meu sistema ao PayGo via Projeto Acbr. Funcionando Ok.

Porém pode falhar, como por exemplo teve um dia que a Vero parou de funcionar pela PayGO e funcionou só por POS.

E não tem como, por POS é manual e não vai os dados do cartão na NFC-e/XML. E vocês sabem, PayGO pode ficar instável, internet pode ficar instável e aí só resta POS via Chip e não tenho sistema que interligue isto.

Segundo o pessoal da SEFAZ-RS, deve-se fazer integração com Smart POS.. Isso tinha que ser fácil como falar ehehhee

29 Junho, 2023

2 minutos atrás, GustavoLI disse:

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),?

A NT já está em vigor no ambiente de homologação desde o dia 05/06/2023, mas só na teoria, pq na prática se vc enviar uma nfce com CFOP 5949 e CST 90, recebe rejeição do CST inválido para NFCe !

28 Junho, 2023

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 ?

22 Junho, 2023

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

20 Junho, 2023

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)

16 Junho, 2023

Boa tarde

Estou tantando fazer a certificação do meu aplicativo e recebi o seguinte retorno:

1 - Não está sendo enviado o cnpj da automação, somente o do cliente, segue o parâmetro abaixo para envio do cnpj da automação

cnpj_automacao - CNPJ da empresa que desenvolveu a automação comercial.

exemplo:

i.putExtra("cnpj_automacao", "12345678912345");

Estou passando o parâmetro:

ACBrTEFAndroid1.DadosAutomacao.CNPJSoftwareHouse := Meu_CNPJ ;

Acredito que isso não esteja sendo sendo passado (i.putExtra("cnpj_automacao", "12345678912345");

Tentei ver aqui no fonte da classe, mas não achei como mandar isso..

Alguém pode me ajudar ?

15 Junho, 2023

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.

9 Junho, 2023

Em 07/06/2023 at 18:03, Daniel Simoes disse:

Obrigado pela analise...

Pode por favor, anexar as Units modificadas, para fazermos o merge ?

ACBrTEFAndroidMSitef.pas

7 Junho, 2023

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

Boa tarde

Notei um problema aqui...

Quando faço ACBrTEFAndroid1.EfetuarAdministrativa(IdentificadorTransacao) ;

o parâmetro TACBrTEFAndroidMSitefClass( ACBrTEFAndroid1.TEF ).TransacoesHabilitadas:='7;8;16;17;18;26;27;28;29;30;40;3020;3289' ;

é jogado nulo, mesmo preenchendo a propriedade..

Isso somente quando chama ADM, quando faz uma transação joga normal

Acho que encontrei o problema..

Faltou:

PA.ValueInfo[PWOPER_RESTRICOES] := fRestricoes;
PA.ValueInfo[PWOPER_TRANSHABILITADA] := fTransacoesHabilitadas;
na function TACBrTEFAndroidMSitefClass.EfetuarAdministrativa(const CodOperacaoAdm: string = ''): Boolean;

do ACBRTEFAndroidMSitef.pas.

Inclui essas linhas e agora funcionou ...

7 Junho, 2023

Boa tarde

Notei um problema aqui...

Quando faço ACBrTEFAndroid1.EfetuarAdministrativa(IdentificadorTransacao) ;

o parâmetro TACBrTEFAndroidMSitefClass( ACBrTEFAndroid1.TEF ).TransacoesHabilitadas:='7;8;16;17;18;26;27;28;29;30;40;3020;3289' ;

é jogado nulo, mesmo preenchendo a propriedade..

Isso somente quando chama ADM, quando faz uma transação joga normal

7 Junho, 2023

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 ?

7 Junho, 2023

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

6 Junho, 2023

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 !

6 Junho, 2023

2 horas atrás, Daniel Simoes disse:

Estude o Demo do ACBr....

Veja o método: procedure TFrTEFDemoAndroid.AplicarConfiguracaoTransacao;

  if ACBrTEFAndroid1.TEF is TACBrTEFAndroidMSitefClass then
  begin
    with TACBrTEFAndroidMSitefClass( ACBrTEFAndroid1.TEF ) do
    begin
      ComExterna     := '0';//opcional: 0 – Sem (apenas para SiTef dedicado); 1 – TLS Software Express; 2 – TLS WNB Comnect; 3 – TLS Gsurf
      Restricoes     := '';  // <------------------------------ AQUI ------------------------
      TransacoesHabilitadas := ''; //opcional : controle de transação
      ValidacaoDupla := '0'; //opcional : 0 – Para validação simples; 1 – Para validação dupla ***Obrigatório para empresa que usam /TLS ComExterna= 1, 2, 3
      CodigoOTP      := ''; //opcional : Código obrigatório quando é utilizada comunicação(ComExterna) com TLS GSurf.
      AcessibilidadeVisual := 0;//opcional: Campo para definir se a acessibilidade visual deve ser habilitada: 0 – Para desabilitar (valor padrão) 1 – Para habilitar
      //TipoPinpad     := TTipoPinpad.pUsb;//opcional : ANDROID_USB – Tenta obter conexão apenas com pinpad´s USB; ANDROID_BT – Tenta obter conexão apenas com pinpad´s Bluetooth.
    end;
  end;

Era isso que não estava encontrando.. Valeu ai Daniel !!

6 Junho, 2023

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

Bom dia

Segundo o pessoal da Softwareexpress, para habilitar a transação com cartão de crédito digitado, teria que habilitar isso na chamada da função de pagamento, incluindo o parâmetro ("restricoes", "TransacoesHabilitadas=29")

Não sei como isso foi feito no componente, mas pelo que vi, isso deveria ser passada em ACBrTEFAndroid1.EfetuarPagamento.. Ou foi criado de alguma outra forma ?

Sou meio inexperiente quando se trata de debugar os fontes do ACBR, mas andei dando uma "fuçada" aqui e encontrei isso.. Pelo que pude entender, as transações habilitadas estão sendo passadas sempre em branco.. Talvez teria que criar uma Propriedade na inicialização para passas esses códigos ?

Entrar

Sobre nós...

Blocks

Notes ACBrLibNFe

Fóruns

Downloads

Calendário

Posts postados por Dércio Luis Zanatta

Sobre nós...

Informação Importante