Dércio Luis Zanatta

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

Também tenho interesse 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).

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.

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.

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.

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.

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 ?

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

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)

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

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 !

Bom dia with InfAdic.obsCont.add do begin xCampo := 'txidPIX'; xTexto := 'ValortxidPIX' end; Dessa forma não vai funcionar ?

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

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

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 ?

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.

ACBrTEFAndroidMSitef.pas

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

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

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 ?

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

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 !

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

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 ?