NT 2015/002 E NT 2015/003 - Codigo de autorização da operação de Credito e Debito

[Márcio Túllio]

Bom Dia

Dentro do pacote de validações programadas para 01.04.2016 tem essa regra do codigo de autorização da operação de credito e debito , como os amigos estão fazendo , estão lendo diretamente do retorno do TEF , existe um padrão para a leitura deste retorno , ja que ele volta no texto da autorização e não e um campo especifico.

 

• Para pagamentos relacionados a transação de débito e crédito, a aplicação necessita estar preparada para informar os seguintes dados:
  • CNPJ do credenciador do Cartão;

  • Código referente a bandeira da operadora;

  • Código de autorização da operação de crédito e débito;

  • Tipo de integração do sistema de vendas (integrado com o TEF ou POS).
    *Fica a critério de cada UF, a obrigatoriedade ou não da exigência dessas informações.

[Daniel Simoes]

o ideal é ter integração com TEF... e capturar o NSU da transação...

[Márcio Túllio]

Voce tem algum trecho de codigo com essa captura , voce ja usa assim na aplicação comercial ?

[Daniel Simoes]

Na nossa aplicação incentivamos muito o uso de TEF dedicado e integrado... com o ACBrTEFD é relativamente simples, capturar qualquer retorno do TEF, sendo que os principais campos são mapeados para propriedades do componente... Mas infelizmente o  ACBrTEFD não é possível de ser implementado no ACBrMonitorPLUS

Segue em anexo, um "Log", do que é retornado em uma transação SITEF, através do ACBrTEFD... é necessário compreensão dos retorno da CliSitef, para saber o significado dos campos...

 

CliSiTef.log

[marcio-carneiro]

Para quem usa POS, isto  é, não integrado, basta fazer o código abaixo(nas vendas com cartão)?

tPag :=  fpCartaoCredito;
   tpIntegra := tiPagNaoIntegrado;

Sinceramente, é tanta mudança/prorrogação que fiquei confuso...

 

[Márcio Túllio]

no retorno vem estes campos o campo do NSU em alguns comprovantes não e impresso , não seria a autorização conforme fala na regra não.

destes campos o 012 e nsu , mas estou em duvidas se devo ou não usar ele 

 

000-000 = CRT
001-000 = 344927
002-000 = 0
003-000 = 14400
004-000 = 0
009-000 = 0
010-000 = REDECARD
011-000 = 10
012-000 = 300002111111
015-000 = 3003131016
022-000 = 30032016
023-000 = 131016
027-000 = 300316000000300002RD10
028-000 = 30

[Daniel Simoes]

Vai depender muito, de qual Gerenciador TEF você está usando... melhor se basear na documentação do Integradora

[Márcio Túllio]

Tem de todo , Tipo , Linx , Authar , Redecard , Cielo , mas todos são não dedicado , o NSU com voce sugeriu e o 012-000 , mas ao olhar o comprovante impresso , sem ser o de teste do TEF , o comprovante atual das lojas o NSU não e impresso e geralmente tem o campo AUTO:XXXXX ou AUTE:XXXXXX , que "talvez" possa ser os 6 primeiros do NSU.

[Alberto.Leal]

Em 22/03/2016 at 18:09, Daniel Simoes disse:

Na nossa aplicação incentivamos muito o uso de TEF dedicado e integrado... com o ACBrTEFD é relativamente simples, capturar qualquer retorno do TEF, sendo que os principais campos são mapeados para propriedades do componente... Mas infelizmente o  ACBrTEFD não é possível de ser implementado no ACBrMonitorPLUS

Segue em anexo, um "Log", do que é retornado em uma transação SITEF, através do ACBrTEFD... é necessário compreensão dos retorno da CliSitef, para saber o significado dos campos...

 

CliSiTef.log

Bom dia
Ein Daniel uma duvida.. porque nao é possivel o uso do ACBrTEFD no AcbrMonitorPlus ?

[Daniel Simoes]

O componente ACBrTEFD é baseado em eventos... ou seja, é ele quem solicita informações a aplicação, ou solicita ações da aplicação, como Imprimir, exibir msgs, etc...

Seria impossível fazer isso via ACBrMonitor