Número NSU de uma transação TEF

[Intelliware]

Boa tarde pessoal,

Estamos com a seguinte situação utilizando o SitDemo 6.0.0.3, segue: Quando efetuamos uma transação, obtemos o NSU da mesma utilizando o comando:

ACBrTEFD.RespostasPendentes[pred(ACBrTEFD.RespostasPendentes.Count)].NSU

Esse valor é gravado em banco. No nosso caso, fica, por exemplo: 000010020

Quando é executado o comando:

ACBrTEFD.CNC(cdsGetMovCxTEFREDE.AsString,
             cdsGetMovCxTEFNSU.AsString,
             cdsGetMovCxTEFDATAHORAHOST.asDateTime,
             cdsGetMovCxTEFVALORFINAL.AsCurrency);

Não é aceito o número do documento acima, retornado em cdsGetMovCxTEFNSU.AsString. Olhando no comprovante do TEF, temos:

DOC=010020

Então, neste caso, o operador precisa apagar os três primeiros zeros para conseguir o cancelamento do cupom e da transação, gerando um certo transtorno na fila.

Analisando o documento Especificação Técnica – Interface com os meios de pagamento do SiTef   Bibliotecas CliSiTefI e CliSiTef  Versão 172, temos na página 24 que:

133 - Contém o NSU do SiTef (6 posições)
134 - Contém o NSU do Host autorizador (20 posições no máximo)

Analisando a unit ACBrTEFDCliSiTef.pas linha 376, temos:

134 : fpNSU := LinStr;

Acredito que neste caso, do comando CNC do CliSiTEF eu não poderia assumir o tamanho do campo como sendo 6 e preencher com zeros a esquerda ou poderia?

Gostaria de saber, se existe uma padronização para o tamanho deste campo ou se estamos efetuando algum procedimento incorreto. 

Desde já agradeço a opinião de vocês.

[Daniel Simoes]

Não consegui compreender o problema...

Tudo que o ACBrTEFD faz, é capturar as informações do Log de retorno do Gerenciador da Transação TEF  e interpretá-lo...

Ative o Log detalhado em ACBrTEFD "LogDebug := True"...Verifique no Log gerado, como é o retorno do gerenciador TEF ao ACBrTEFD

[Intelliware]

Bom dia Daniel,

Na verdade, não seria realmente um problema, somente uma divergência entre a quantidade de zeros a esquerda no número do documento. No caso, no banco de dados fica gravado 000010020  e no documento impresso 010020. Com isso, no momento de cancelar o operador precisa retirar os zeros sobrando a esquerda para poder efetuar o cancelamento do cupom. No caso acima:  000010020 - 000 =  010020

Vou ver se consigo mais informações utilizando o comando de debug acima. Agradeço.

[Daniel Simoes]

Isso pode ser respondido em: procedure TACBrTEFDRespCliSiTef.ConteudoToProperty;

       133 : fpCodigoAutorizacaoTransacao  := Linha.Informacao.AsInteger;
       134 : fpNSU                         := LinStr;   

E segundo o manual do SiTef, página 27

133  Contém o NSU do SiTef (6 posições)
134  Contém o NSU do Host autorizador (15 posições no máximo)

 

[Intelliware]

Exatamente Daniel, acabei encontrando aqui.

Pelo que pude observar, acredito que na procedure ACBrTEFD.CNC, o NSU pedido é o do SiTEF(6 posições) que corresponde ao campo 133. Seria isso mesmo? Uma vez que a diferença entre o NSU do SiTEF e o NSU do Host autorizador é exatamente a diferença de zeros em questão.

[Daniel Simoes]

Somente ligando na Sw.Express para confirmar... mas crio que o 133 seja algo de controle interno deles... para cancelar a operação na Operadora, seria necessário o NSU do Host

[Intelliware]

Entendi. Vou entrar em contato com eles para confirmar esta informação. Agradeço.