deverá respeitar o tempo máximo de consulta de status de pagamento, segundo o parâmetro "Timeout consulta pagamento". Quando o tempo de requisição de pagamento ultrapassar o tempo definido no campo de timeout, o usuário será notificado: "Pedido finalizado com sucesso! Entretanto, o pagamento precisa ser aprovado para que o pedido seja devidamente encaminhado para faturamento". Dessa forma, o pedido será finalizado e o status de pagamento permanecerá como PENDENTE. Caso a resposta não seja bem sucedida, por qualquer motivo o sistema deverá notificar o usuário: "Pagamento não pôde ser criado no servidor do {nome do plugin}, cuja resposta foi: ${resposta da requisição}." Caso não houver mensagem, o sistema deverá exibir: "Pagamento não pôde ser consultado no servidor do {nome do plugin}." Após a mensagem, o sistema deverá: - Substituir a label "PIX aguardando pagamento" por "Pagamento não confirmado"
- O texto "O pedido será finalizado quando o pagamento for confirmado" para "Clique em finalizar para pagamento posterior"
O sistema exibirá o botão "Cancelar", que, ao clicado, deverá exibir mensagem de confirmação para o usuário: "A ação irá cancelar o QR Code, que não poderá mais ser pago. Deseja prosseguir?" Sim/não. Se sim, disparar uma requisição de cancelamento do QR Code para o servidor do TPI. - Requisição GET para a rota ${"Cadastro de plugin TPI"."Configurações do Pentaho"."URL"}/kettle/executeJob?rep=COMMON_SERVICES&job=COMMONS_Bloco_TPICANCELPAYMENT&codigotransacao=${pedidopagamento.tokentransacao}
- Autenticação básica com {"Cadastro de plugin TPI"."Configurações do Pentaho"."Usuário"} e {"Cadastro de plugin TPI"."Configurações do Pentaho"."Senha"}
- O retorno da rota será:
- status: retorno.status
- Os possíveis valores da resposta serão:
Caso a resposta seja bem sucedida, o sistema deverá notificar o usuário: "Pagamento cancelado com sucesso. Finalize o pedido novamente para gerar um novo pagamento". Dessa forma, o pedido não será finalizado, e o status de pagamento deverá ser atualizado para cancelado(sgl CAN). Caso a resposta não seja bem sucedida, o sistema deverá notificar o usuário: "Pagamento não pode ser cancelado no servidor do {nome do plugin}, cuja resposta foi: ${resposta da requisição}.". Caso não houver mensagem de retorno, o sistema deverá exibir: "Pagamento não pode ser cancelado no servidor do {nome do plugin}. Tente novamente mais tarde ou entre em contato com o suporte técnico" O sistema exibirá o botão "Finalizar", que, ao clicado, deverá notificar o usuário: "Pedido finalizado com ressalva! O pedido precisa ter seu pagamento aprovado para ser encaminhado para faturamento. Você será notificado automaticamente das atualizações, porém pode consultar instantaneamente o status do pagamento pela tela de pagamentos do pedido". Dessa forma, o pedido será finalizado e o status de pagamento permanecerá como PENDENTE (sgl PEND).
Consulta de status de pagamento de maneira agendadaPara evitar que pedidos fiquem travados no fluxo de integração com o ERP por falta de consulta do usuário, mesmo tendo sido pagos, o serviço de integração deverá consultar, com frequência definida baseado no recurso infra estrutural do servidor, os status dos pagamentos de transações com status de PENDENTE, para que, ao aprovado, o sistema possa atualizar os status dos pagamentos de maneira ativa, e quando o fizer, notificar o usuário, via notificação PUSH, que o pagamento do pedido foi aprovado/cancelado/expirado. Portanto, o sistema de integração deve consultar os pagamentos que estão com status pendente de pagamento através da consulta a seguir: /* CONSULTA_PAGAMENTOS_PENDENTES
select pp.tokentransacao from pedido p
inner join pedidopagamento pp on pp.idpedido = p.idpedido
inner join tiposituacaopagamento tsp on tsp.idstiposituacaopagamento = pp.idstiposituacaopagamento
where tsp.sgltiposituacaopagamento = 'PEND'
*/
|
Com os tokens retornados, o sistema de integração deverá consultar na api da transformação COMMONS_Bloco_TPIGETSTATUS, e verificar qual é o status atualizado do pagamento a partir do retorno "status". Com o status do pagamento em memória, o sistema de integração deverá atualizar a coluna pedidopagamento.idstiposituacaopagamento, conforme o seguinte de-para: Status do retorno | sgltiposituacaopagamento |
|---|
| pending | PEND | | approved | APR | | expired | EXP | | refunded | REEMB | | cancelled | CAN |
Se houve alteração de status, o sistema de integração deverá inserir novo registro na tabela observacaopagamento, segundo o seguinte de-para: PARA | DE |
|---|
PARA | DE |
|---|
| idobservacaopagamento | nextval('seqpkobservacaopagamento') | | observacao | "O status do pagamento foi atualizado para ${retorno.status > tiposituacaopagamento.descricao}" | | idpedidopagamento | CONSULTA_PAGAMENTOS_PENDENTES.tokentransacao | | idtiposituacaopagamento | retorno.status > tiposituacaopagamento.idtiposituacaopagamento | | idusuario | lookup para tabela usuario where login = 'admin' | | datahora | current_timestamp |
Sincronização de pedido instantaneamente durante operações de pagamentoPara que não exista risco de um pedido já pago permaneça no android sem ser sincronizado, o sistema disponibiliza função de "Sincronização instantânea" via função de "envio de dados" da Sincronização para processos online como o processo de geração de pagamento. O envio de dados acontecerá de maneira síncrona nos gatilhos abaixo, enviando apenas os dados (DATS) de pedido e suas dependências. A sincronização instantânea será realizada nas etapas de: - Inicio do processo de finalização, enviando o pedido gravado, antes da chamada da criação do pagamento.
- Após recebimento do QR Code, enviando o registro da tabela de pagamentos do pedido.
- Após recebimento da atualização do status de pagamento, enviando o registro da tabela de pagamentos do pedido.
- Após recebimento da confirmação do cancelamento do pedido, enviando o registro da tabela de pagamentos do pedido
- Após a finalização do pedido, sendo ele pago, ou selecionado para cobrança posterior, atualizando o registro de status do pedido para PENDENTE.
- Geração de novo pagamento, enviando o registro da tabela de pagamentos do pedido
Dessa forma, o pedido devidamente pago, seja atualizado pela integração, de maneira, agendada, ou seja atualizado instantaneamente, via consulta de pagamentos, fará com que o pedido esteja em condições de ser exportado na próxima execução da integração. Filtragem de exportação de pedidos sem pagamento aprovado com tipos de cobrança associados ao pluginCaso o plugin de integração da TPI estiver ativo, a integração padrão deverá aguardar o envio do pedido pedido para o ERP segundo as restrições a seguir: - Pedido estar associado à tipos de cobrança que estão configurados no plugin de integração, pelo campo "Tipos de cobrança"
- Pedido precisa conter 1 pagamento com status APROVADO
OBS: Anteriormente, no Android, pedidos que haviam sido finalizados ainda continuavam editáveis até a sincronização. Agora, esses pedidos que já foram transmitidos ao servidor não serão mais editáveis, como acontece na Web, por exemplo. |
