Roteiro pré-homologação sequência 16 Clisitef

[Dev Comercial]

Boa tarde, também estamos com o mesmo problema reportado pelo JGuto que segue no link 

o que devemos fazer para contornar esse incidente?

Agradeço a atenção e colaboração de todos.

[Juliomar Marchetti]

Boa noite

viu ele pedem pra desligar e retiram o cartão do pin-pad!

então acho que está se preocupando.

pede pra eles fazerem uma pré-homologação

[Daniel Simoes]

Enquanto o fluxo do SiTef não terminar, a transação ainda não existe... por isso o ACBrTEFD não tem como salvar um Backup... simplesmente porque o a CliSiTef ainda não devolveu a resposta da transação...

[tdpsistemas]

Boa tarde a todos,

Ainda no caso acima da sequencia 16, estou refazendo a homologação para NFC-e e SAT, pelo que vi o arquivo só é gerado no diretório padrão no método:

TACBrTEFDCliSiTef.ContinuarRequisicao;

 

E só é chamado o método para geração do arquivo, quando a variavel TipoCampo, estiver atribuída a: 121, 122, 133, 952;

Vendo o requisito pensei na seguinte solução: (Me desculpe se estiver equivocado!)

Dentro do case ProximoComando of

Na sequencia 3: Podemos implementar a criação do arquivo caso o retorno da mensagem seja "TRANSACAO ACEITA".

Ex:

If AnsiUpperCase(Mensagem) ='TRANSACAO ACEITA' Then

   fArqBackUp := CopiarResposta;

Dessa forma mesmo que o cartão não seja retirado da leitora, a maquina seja finalizada (ou a aplicação) ao iniciar novamente o sistema iremos ter o retorno da transação.

Se foi OK e precisa fazer a reimpressão ou reter o cupom.

Estou errado no meu modo de pensar?

Obrigado pela atenção.

 

[Daniel Simoes]

Não é bom fazer algo baseado em Strings hardcoded, se eles modificarem a String no SiTef, para de funcionar...

[Daniel Simoes]

Observe que o mesmo tratamento é feito, quando NSU do SiTef é retornado (campo 133)... Isso significa que temos como achar a transação no SiTEF, ou seja, ela já existe...

                        133, 952:
                        begin
                          fArqBackUp := CopiarResposta;
                        end;   

Então a princípio, a implementação atual do SVN parece correta

[tdpsistemas]

Boa tarde Daniel,

Primeiramente Obrigado pelo Retorno,

Sim, verifiquei a linha explanada acima.

Mas o problema é que se não tirar o cartão não temos o retorno, mas no pinpad aparece transação OK, se reiniciarmos a aplicação ou a maquina antes de tirar o cartão da Leitora, no retorno da aplicação como não existe o arquivo gerado, não há verificação se existe algo pendente ou não.

 

Apenas para teste coloquei o processo de geração do arquivo a cada mensagem processada na tela:

 

Sequencia 3 do case que destaquei acima. Dessa forma a cada mensagem gerada para o usuário é gerado o arquivo com o retorno atualizado. Dessa forma mesmo que não tire o cartão da leitora e faça a sequencia 16 do processo de homologação, ao entrar na aplicação novamente o arquivo é validado.

Mas nesse caso tem a problemática de gerar um arquivo para cada mensagem que é processada, e não sei qual seria a influência dessa mudança.

Fiz alguns testes, dessa forma deu certo. (Sem colocar "Strings hardcoded").

3 :
                   begin
                     MensagemOperador := ProcessaMensagemTela( Mensagem );
                     fArqBackUp := CopiarResposta;
                     MensagemCliente  := MensagemOperador;
                     DoExibeMsg( opmExibirMsgOperador, MensagemOperador, (TipoCampo=5005) ) ;
                     DoExibeMsg( opmExibirMsgCliente, MensagemCliente, (TipoCampo=5005) ) ;
                   end ;

Você acha que existe problema com essa implementação Daniel? Ou você tem outra solução para esse caso?

Obrigado mais uma vez pela atenção

 

 

[Daniel Simoes]

Humm.. não sei, não me parece a coisa certa a fazer..

Se o cliente ainda não tirou o cartão da máquina, a transação já existe no SiTef ?

Quem tem que nos confirmar se a transação já existe ou não, é o SiTEF, e ele deve fazer isso, nos informando o NSU

[tdpsistemas]

No momento que aparece no Pinpad: "TRANSACAO ACEITA" e logo em seguida pede para remover o cartão, se olharmos no Relatório de Transações do SiTef, a Transação ainda está Pendente. 

Mas da forma que implementei acima, fazendo o processo de homologação seq 16, ao abrir novamente a aplicação, o retorno é:

"Transação TEF efetuada.

Favor reimprimir último Cupom.

(Para Cielo utilizar os 6 últimos dígitos.)"

Hoje existe algum método ACBrTEFDCliSiTef, que valida a última transação sem a existência do arquivo *.tef?

[Daniel Simoes]

Não..  mas isso existe na DLL da CliSiTef... portanto se você usa a CliSiTef, pode checar se há transações pendentes chamando o método:

function TACBrTEFDCliSiTef.ObtemQuantidadeTransacoesPendentes(Data:TDateTime;
  CupomFiscal: AnsiString): Integer;

 

[tdpsistemas]

Bom dia Daniel,

 

Novamente obrigado pelo retorno. 

 

Tentei utilizar o método que você passou.

Citar

function TACBrTEFDCliSiTef.ObtemQuantidadeTransacoesPendentes(Data:TDateTime;
  CupomFiscal: AnsiString): Integer;

Mas fazendo os testes a DLL não retorna valor algum, sempre retorna zero!

Mas no Relatório de Transações do SiTef  a transação consta como PENDENTE.

Vendo esse problema entrei em contato com a Software Express e recebi o seguinte retorno do suporte:

Citar

Bom dia Alan

Sobre a sequência 16 da clisitef v14 pode desconsiderar, porque e necessário alguns ajustes nesse teste no simulado e então pode seguir a sequência sem problemas.

Att

Pensando nisso podemos desconsiderar a minha duvida e minha sugestão.

Obrigado mais uma vez pelo auxilio.

[Daniel Simoes]

Obrigado pelo retorno...

Que falta de profissionalismo da Software Express... porque já não alteram o roteiro, removendo o teste... 

[tdpsistemas]

Pensei da mesma forma e questionei o suporte, a posição foi que o mesmo será ajustado para realidade do SAT e NFC-e.

Nos resta aguardar os ajustes.

kkkkkkk

Obrigado pelo auxílio Daniel.