5. Fluxos da Automação Comercial

5.1 Transação de Venda simples

Uma transação de Venda simples (com uma única forma de pagamento) segue o fluxo abaixo, para uma solução integrada com Impressora Fiscal:
AC

1698

As próximas seções contêm informações importantes relacionadas a etapas específicas do fluxo acima.

5.2 Interrupção da transação

Não existe tempo máximo para a Automação Comercial aguardar o arquivo Resp\intpos.001 gerado pelo TEF, pelos motivos seguintes:

→ Devido a mecanismos de tolerância a falha configurados dinamicamente pela Rede Adquirente (quantidade de tentativas e tempo máximo de espera), o processo de conexão à Rede Adquirente para autorização da transação não tem tempo máximo definido.

→ Devido à interação com o usuário, o fluxo de telas para captura das informações da transação também não tem tempo máximo definido. (Existe um tempo máximo de ociosidade, porém é reiniciado a cada ação do usuário.)

Por esses motivos, a Automação Comercial não deve permitir que uma operação de TEF seja interrompida após o recebimento do arquivo Resp\intpos.sts. Além disso, tal possibilidade poderia quebrar o sincronismo entre as aplicações e por consequência a integridade da transação.
No entanto, em caso de situação inesperada na qual o TEF deixaria de responder à solicitação da Automação Comercial, aceita-se que a Automação Comercial forneça um mecanismo para abortar a operação de TEF, desde que o acesso a este recurso seja protegido por uma senha de divulgação restrita.

5.3 Impressão

O processo de impressão dos comprovantes é crítico, pois dele depende o status final da transação, se esta será confirmada ou cancelada. Um tratamento incorreto pode resultar em quebra da integridade da transação, ficando indevidamente efetivada ou cancelada, sem o conhecimento do operador e do Cliente.

Em caso de falha no processo de impressão, a Automação Comercial deve avisar o usuário e perguntar se deseja realizar uma nova tentativa de impressão (dando a oportunidade de verificar o estado e as conexões da impressora), repetidamente a cada tentativa. O resultado da impressão somente deve ser considerado falho (para geração do arquivo de resposta ao PayGo) após o operador confirmar a desistência.

O sucesso da impressão deve ser determinado pela Automação Comercial, através de comunicação direta com a Impressora Fiscal, nunca deve ser determinado pelo operador.

Caso seja determinada falha na impressão e o operador desiste de novas tentativas, a Automação Comercial deve avisar claramente o usuário que a transação de TEF foi cancelada, apresentando a mensagem de erro abaixo definida para esta situação.

🚧

Importante:

→ Algumas transações, mesmo bem-sucedidas e gerando comprovantes, podem não requerer confirmação. Esta situação é identificada pela Automação Comercial através do campo 729-000. Há duas causas possíveis para esta situação:

• A transação não tem impacto para o estabelecimento ou para o Cliente (por exemplo, consulta de saldo); ou

• Mesmo tendo impacto, a transação já está confirmada, e a Rede Adquirente não permite desfazê-la.

→ As definições aqui realizadas não substituem e não invalidam nenhum ponto da lei fiscal vigente, com a qual a Automação Comercial deve estar em pleno acordo.

5.3.1 Definição das vias a serem impressas

O fluxo abaixo deve ser utilizado para determinar quais vias do comprovante devem ser impressas:

1508

5.4 Queda de energia

Em caso de queda de energia durante uma operação de TEF, ao ser reiniciada, a Automação Comercial deve verificar a presença do Resp\intpos.001. Caso presente, indica que a operação de TEF foi efetuada, porém a impressão não foi finalizada. Nesta situação, deve ser adotado o mesmo procedimento acima descrito para uma falha na impressão:

→ Avisar o usuário do ocorrido;

→ Perguntar para o usuário se deseja efetuar uma nova tentativa de impressão ou se deseja cancelar a operação de TEF;

→ Nunca deixar o operador determinar o status final da operação.

5.5 Mensagens de erro

Em caso de erro na operação de TEF, a mensagem apresentada para o usuário deve ser condizente com a situação ocorrida. O fluxo em “5.1.Transação de Venda simples” destaca as seguintes situações:

1064

Observação: após apresentação da mensagem, a Automação Comercial deve aguardar uma confirmação de leitura do usuário (botão “OK”, por exemplo).

5.6 Transação Administrativa

O fluxo de uma transação Administrativa é muito similar ao da Venda simples:

1496

5.7 Transação de Cancelamento

O cancelamento de uma venda pode ser realizado através de uma transação Administrativa, com digitação das informações da venda no fluxo da operação. A transação de Cancelamento (comando “CNC”) permite um acesso direto a esta mesma operação, referenciando uma transação de Venda realizada anteriormente.

O fluxo da operação segue exatamente o mesmo de uma transação Administrativa, como acima detalhado. Somente deve se lembrar, caso necessário, de também cancelar o cupom fiscal correspondente.

A implementação da transação de Cancelamento pela Automação Comercial é opcional.

5.8 Transação de Venda com outras formas de pagamento

Caso seja utilizada uma ou mais formas de pagamento além do pagamento via TEF (cheque, dinheiro, etc.), estas formas de pagamento devem ser registradas antes de acionar o TEF. O valor da transação de Venda informado pela Automação Comercial ao TEF deve sempre ser o valor total ainda não pago, finalizando desta forma a venda após aprovação da transação pelo TEF, e confirmação pela Automação Comercial.

5.9 Transação de Venda com múltiplos cartões

Devido à necessidade de confirmar cada transação antes de iniciar a próxima, o pagamento de uma mesma Venda através de mais de uma operação de TEF não é suportado de maneira direta. A funcionalidade pode ser implementada, opcionalmente, pela Automação Comercial, porém requer tratamentos adicionais, abaixo descritos.

As regras são as seguintes:

→ Cada operação de TEF que não seja a última deve ser confirmada imediatamente para o PayGo (comando “CNF”), e os comprovantes devem ser armazenados em memória não volátil para futura impressão.

→ Após aprovação da última operação de TEF, o cupom fiscal deve ser fechado e todos os comprovantes impressos, respeitando a ordem na qual foram realizadas as transações. Após impressão com sucesso dos comprovantes da última operação de TEF, deve então ser confirmada a última transação (comando “CNF”).

→ Caso, por qualquer motivo, o pagamento não possa ser completado via TEF, todas as operações de TEF realizadas devem ser canceladas:

• A última operação ainda não confirmada é cancelada simplesmente através do comando “NCN”.
• As demais operações de TEF já confirmadas devem ser canceladas através de uma transação de Cancelamento (comando “CNC”).

→ A transação de cancelamento não é imediata e requer diversas ações do usuário (leitura do cartão, digitação de informações da operação de TEF original, etc.), que dependem da Rede Adquirente utilizada. Além disso, pode não ser bem-sucedida, devido a erros na digitação, falhas de comunicação, etc. A transação de cancelamento somente deve ser considerada como efetuada pela Automação Comercial após aprovação pelo PayGo, impressão dos comprovantes com sucesso e envio da confirmação (comando “CNF”) ao PayGo.

→ Uma vez iniciado o fluxo de pagamento com múltiplos cartões, este não pode ser interrompido até ser finalizado com sucesso (todas as transações confirmadas) ou falha (todas as transações canceladas com sucesso).

→ Quedas de energia durante o fluxo de pagamento devem ser tratadas da mesma forma de uma transação simples, ainda recuperando o estado das transações já realizadas e pendentes de impressão, podendo o usuário optar por prosseguir com o fluxo, ou iniciar a sequência de cancelamentos.

→ Em caso de queda de energia durante o fluxo de cancelamento, ao ser reiniciada, a Automação Comercial deve automaticamente prosseguir com este, sem fornecer opção para o usuário interromper este.

O diagrama abaixo ilustra o fluxo seguido pela Automação Comercial:

1562

📘

Observações:

→ No fluxo acima, para maior clareza, os controles efetuados nos arquivos trocados com o PayGo foram omitidos, porém permanecem idênticos ao fluxo de venda simples.

→ A transação de cancelamento (comando “CNC”) deve ser confirmada após a impressão dos comprovantes, como qualquer transação administrativa.

5.10 Verificação da atividade do PayGo

Para verificar se o PayGo está ativo, a Automação Comercial deve:

→ Apagar o conteúdo da pasta Resp;

→ Gerar um arquivo Req\intpos.001, com campo 000-000 = ATV;

→ Aguardar até 7 segundos pela geração do arquivo Resp\intpos.sts;

Considerar que o PayGo está ativo se o arquivo for gerado.

Seguem observações importantes para compatibilidade com futuras versões dos produtos:

→ A Automação Comercial somente deve utilizar este mecanismo, nunca deve verificar a presença de determinado arquivo em disco ou janela/processo em memória para este fim.

→ Caso o PayGo esteja inativo, por qualquer motivo que seja, o usuário deverá acioná-lo manualmente. A Automação Comercial deve avisar o usuário, porém não deve tentar acionar automaticamente o PayGo. No entanto, como exceção, caso a Automação Comercial utilize o diretório C:\TEF_Dial ou C:\TEF_Disc para troca de arquivos, esta poderá executar o arquivo correspondente ao módulo “Gerenciador Padrão” (C:\TEF_Dial\tef_dial.exe ou C:\TEF_Disc\tef_disc.exe).

→ O PayGo é ativado automaticamente pelo Windows, para qualquer usuário da máquina. Caso a ativação automática deixe de funcionar em determinado Estabelecimento, deverá ser acionado o suporte ao produto para verificar a instalação e corrigir o problema.

5.11 Outras considerações referentes à troca de arquivos

5.11.1 Gravação de arquivo

Para evitar conflitos de acesso a arquivos, a Automação Comercial sempre deve:

→ Gravar arquivos na pasta Req com um nome temporário (por exemplo, “intpos.tmp”);
→ Esvaziar o cache (flush) imediatamente antes de fechar o arquivo;
→ Por último, renomear o arquivo para o nome especificado (“intpos.001”).

5.11.2 Acesso a arquivos existentes

Aplicativos legítimos residentes no equipamento, que monitorem acesso a arquivos (principalmente antivírus), podem causar falha de acesso quando a Automação Comercial tentar abrir um arquivo existente (“intpos.001” ou “intpos.sts”). Por isso, é importante que a Automação Comercial identifique e trate esta situação específica, tentando novamente várias vezes o acesso ao arquivo, com intervalos de fração de segundos, antes de reportar o erro para o usuário.

Para mais informações: http://support.microsoft.com/kb/316609/pt-br.

5.11.3 Liberação do processador
Enquanto aguarda um arquivo de resposta do TEF, é importante que a Automação Comercial faça um uso mínimo do processador, para não prejudicar o funcionamento do computador e do aplicativo de TEF.

Recomenda-se que a presença do arquivo seja verificada no máximo 4 vezes por segundo, por exemplo efetuando uma pausa de 250 ms após cada verificação.

5.12 Tratamento de troco, desconto, valor devido e valor ajustado

Esta especificação prevê que, em uma transação de Venda, o valor da transação inicialmente informado pela Automação Comercial possa ser alterado durante a operação de TEF, devido a:

→ Uma retirada em dinheiro (saque) em conjunto com a Venda, por opção do cliente; → Um desconto concedido pela Rede Adquirente;

→ A aprovação parcial do valor da Venda pelo emissor do cartão, devido à insuficiência do saldo do cartão; e/ou

→ Uma alteração do valor (reajuste para mais ou para menos) devido a acordos contratuais entre o estabelecimento e a Rede Adquirente.

A Automação Comercial deve atentar-se a atualizar corretamente seus registros internos da transação com estas informações, assim como os registros fiscais correspondentes.

No caso do uso de uma Impressora Fiscal, recomenda-se registrar as formas de pagamento e eventuais descontos concedidos pelo estabelecimento somente após a realização da operação de TEF, convivendo assim com as restrições de determinados modelos de equipamentos que não permitem:

→ Registrar um desconto após ter registrado uma forma de pagamento (tipicamente, dinheiro);

→ Registrar mais de um desconto.

5.13 Emissão de documento fiscal eletrônico

Para Estabelecimentos que emitam um documento fiscal eletrônico (NF-e, NFC-e, SAT, etc.) ao invés de um Cupom Fiscal através de uma Impressora Fiscal:

→ Para garantir a integridade da transação, os passos referentes à impressão do comprovante no fluxo da transação detalhado anteriormente devem ser substituídos pelo registro fiscal eletrônico. Ou seja, caso a comunicação com o dispositivo ou serviço fiscal falhe e não possa ser recuperado, a operação de TEF deve ser desfeita.

→ Dependendo do modo de operação do Estabelecimento, os comprovantes de TEF podem ser emitidos:

• Em uma impressora não fiscal (neste caso, uma falha na impressão não desfaz a operação de TEF, conforme “5.14. Impressora não fiscal”);

• Dentro do DANFE, em campo adequado para este uso, de acordo com a legislação vigente.
A figura abaixo ilustra o final do fluxo de uma Transação de Venda:

1318

5.14 Impressora não fiscal

Para Estabelecimentos que não tenham a obrigação de utilizar uma Impressora Fiscal, soluções de Automação Comercial podem realizar a impressão dos comprovantes em impressoras não fiscais.

Nesta situação exclusivamente, não existe a necessidade de a Automação Comercial verificar o status da impressão dos comprovantes para confirmar a transação ao PayGo.

A figura abaixo ilustra o final do fluxo de uma Transação de Venda:

584

📘

Observações:

→ Caso a impressão tenha falhado, a solução PayGo permite a reimpressão do comprovante através de uma Transação Administrativa.

→ Caso a Automação Comercial esteja integrada com um equipamento para o qual a integridade da transação precise ser mantida (por exemplo, liberação automática de uma mercadoria após o pagamento), o mesmo tratamento realizado para a impressão numa Impressora Fiscal poderá ser adotado: a Automação Comercial deverá confirmar ou cancelar a transação de acordo com o sucesso ou a falha da operação no equipamento acoplado.

5.15 Captura de dado pessoal no pinpad

O PayGo disponibiliza um comando específico (CDP) para captura de um dado pessoal do Cliente no pinpad utilizado pela solução, favorecendo a operação (evitando erros de digitação) e preservando a confidencialidade da informação.

Este dado pode ser:

→ O código CPF do Cliente; ou

→ Um identificador numérico qualquer, de 4 a 12 dígitos.

Ao receber este comando, o PayGo solicita imediatamente a captura do dado no pinpad. Por uma característica do equipamento pinad, o dado é mascarado durante sua digitação e, para evitar erros de digitação, o PayGo apresenta no pinpad a informação em claro para ser confirmada pelo Cliente, antes de retorná-la para a Automação Comercial e finalizar o comando.

Observações:

→ No caso de um CPF, o código é validado pelo PayGo antes de ser retornado para a Automação Comercial.

→ Este comando não permite a digitação de um código CNPJ, por o pinpad não permitir a captura de um dado com mais de 12 dígitos.

→ Alguns equipamentos pinpad podem não suportar esta funcionalidade, em qual caso o PayGo retornará erro. Por isso é importante que, independentemente de ter implementado este comando, a Automação Comercial também permita a captura do dado através de sua própria interface com o usuário.

→ O comando CDP não gera comprovante e a Automação Comercial não deve gerar um arquivo de confirmação.

→ Este comando está desvinculado de uma operação de TEF, e pode ser utilizado também para vendas com forma de pagamento não tratada pelo PayGo (tipicamente, dinheiro).

→ Caso este comando seja seguido por uma operação de TEF, o PayGo não utilizará automaticamente a informação capturada. Para que o CPF digitado seja utilizado pelo PayGo (por exemplo, para pontuação de programa de fidelização), este deve ser informado no arquivo correspondente ao comando CRT ou ADM. Isso permite que sejam utilizados CPF distintos na venda e na fidelização.