Dércio Luis Zanatta

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 ?

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 ?

Boa tarde Só para constar, entre em contato com o suporte da Softwareexpress, eles solicitaram os .dmp das transações testes que fiz e afirmam que a automação está enviando o comando de confirmação da transação e que se esse comando não for enviado, a transação fica pendente, o comportamento é o mesmo da Clisitef, segundo eles...

Boa tarde @warquia No fluxo de transações não aparece a opção "Digitado" quando selecionado "Crédito". O roteiro de pré homologação da Softwarexpress existe que se faça uma transação de Crédito "digitada".. Existe alguma configuração no componente para habilitar isso ?

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

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

Arriscado é.. mas me parece necessário confirmar somente no encerramento da NFCe.. e caso seja cancelada deve ser enviado desfazimento... Existem vários outros controles que devem ser feitos para evitar que as transações fiquem pendentes, mas acredito que vai dar menos dor de cabeça do que ter que ficar cancelando depois.. ainda mais com pdvs móveis..

Certo.. Vou tentar conversar com eles a respeito.. Esse recurso de deixar a transação pendente até a finalização da NFCe se torna necessário nas transações com múltiplas formas de pagamento.. Exemplo: O usuário faz uma NFCe de 10,00.. Efetua um pagamento de 6,00 com TEF.. A NFCe vai ficar aberta aguardando o pagamento do saldo restante.. Se o usuário cancelar a NFCe nesse momento, a transação TEF pode ser desfeita, caso ainda não esteja confirmada, porém se estiver confirmada, terá que ser cancelada e o Cancelamento de uma transação no M-Sitef vai exigir que digite um monte de informações, com nsu, valor, etc... Isso o usuário não vai ter acesso, pois nem comprovante a transação tem ainda...

Boa tarde OBS: Infelizmente o Sitef é um mal necessário... Atualmente não existe uma solução TEF mais completa no mercado.. mas vamos lá Notei outro problema aqui em meus testes.. Mesmo configurando ConfirmarTransacaoAutomaticamente := False as transações estão sendo confirmadas automaticamente...

Se achar necessário, posso te enviar o SitDemo também

Boa tarde Não sei se é isso exatamente que vc precisa... m-SiTef | Guia de Integração (softwareexpress.com.br)

Com todo o prazer.. Estou fazendo testes com o SitDemo aqui.. No que puder colaborar, estou a disposição.

Bom dia Estou dando sequencia nos testes aqui, utilizando MSitef e o componente ACBRTEFAndroid e estou com algumas dúvidas sobre as respostas. 1 - RespostaTEF.CodigoBandeiraPadrao está retornando em branco 2 - RespostaTEF.Parcelas[0].Vencimento está retornando 29/01/1900 nas transações parceladas.

Daniel.. Encontrei esse trecho de código na unit ACBrPosPrinterGEDI. procedure TACBrPosPrinterGEDI.Configurar; begin fpPosPrinter.Porta := 'NULL'; fpPosPrinter.OnEnviarStringDevice := ImprimirGEDI; {$IFDEF __G800__} fpPosPrinter.PaginaDeCodigo := TACBrPosPaginaCodigo.pc1252; {$ELSE} //fpPosPrinter.PaginaDeCodigo := TACBrPosPaginaCodigo.pcUTF8; fpPosPrinter.PaginaDeCodigo := TACBrPosPaginaCodigo.pc1252 ; {$ENDIF} end; Não entendi direito, mas parece que estava sendo passado o pcUTF8 de forma fixa.. Alterei para pc1252 e agora está imprimindo corretamente.. Esse parâmetro não deveria pegar do que foi configurado no componente AcbrPosPrinter, propriedade PaginaDeCodigo ?

Em Delphi eles tem somente para o GPOS700 .. para o GPOS700x, somente em java

Já tentei isso.. Eles tem a versão 1.16.8, mas mesmo assim não funciona a configuração de página de código...

Outro problema que estou enfrentando é quando a impressão nesse GerTec.. Configurei o componente como lib externa igual a fGEDIPrinter. A impressão sai com problemas nos caracteres acentuados, ç, etc... Já tentei todas as opções de página de código do componente e sempre imprime do mesmo jeito.. Tema alguma outra coisa que deve ser configurado ?