Skip to main content

Pagamento Unificado


image-1762776253666.png

 Projeto/Sistema:
GERENCIAMENTO DE PROJETOS		 Versão do Template:
1.2
Processo:

Pagamento Unificado – GA (GerencieAqui)

 Versão do Documento:
2,0
Responsável(eis): 
Jalile Cornachioni

Data: 

10/11/2025
1. Introdução

Atualmente, o GA possui múltiplos módulos que geram pagamentos (ex.: emissão de nota fiscal, ordem de serviço, pedido de venda, NF-e, NFC-e etc). Cada módulo trata pagamentos de forma isolada, o que gera duplicidade de lógica, inconsistência na experiência do usuário e maior dificuldade de manutenção.

Hoje, todos pagamentos são registrados diretamente nas telas de cada módulo, criando títulos ou parcelas futuras no financeiro, que só são baixados após vencimento ou conciliação. Os pagamentos imediatos (dinheiro, cartão, PIX) também seguem fluxos individuais em cada módulo.

O Pagamento Unificado centraliza, em um único modal, o registro de pagamentos imediatos e parcelados utilizados em diversos módulos do GerencieAqui.
Atualmente, cada módulo (NF-e, Pedido de Venda, Ordem de Serviço etc.) possui lógica própria de pagamento, o que gera inconsistências, retrabalho e manutenção complexa.

O objetivo é padronizar o fluxo garantindo:

  • coerência fiscal e financeira

  • interface única

  • menor carga de suporte

  • integração facilitada com TEF, SmartPOS e PIX

  • redução de divergências entre módulos

O modal deve ser aberto a partir de qualquer tela que necessite registrar pagamentos exceto: caixa, PDV, restaurante e venda garçom (verificar se essa regra será mantida em todas as UF e módulos?)

2. Fluxograma Geral

pagamento unificadoV2.jpg

--- Fluxograma de abertura do modal de pagamento unificado ---

image-1758910084512.png

 ---Exemplo do fluxo completo ---

Processos Relacionados

Processo

Envolvidos

Dados de Entrada

Dados de Saída
PROC001 -Aplicar desconto/acréscimo Operador do caixa Valor do desconto ou acréscimo Total líquido recalculado e resumo atualizado
PROC002 - Registro de Pagamento em Dinheiro Operador do caixa Valor recebido Troco calculado, valor quitado e parcela registrada
PROC003 -Registro de Pagamento em Cartão de Crédito Operador do caixa, Cliente Valor, quantidade de parcelas, bandeira, CNPJ da credenciadora, código de autorização Pagamento parcelado registrado e transação gerada (quando integrado ao TEF/API)
PROC004 - Registro de Pagamento em Cartão de Débito Operador do caixa, Cliente Valor, bandeira, CNPJ da credenciadora, código de autorização Pagamento registrado e transação gerada (quando integrado ao TEF/API)
PROC005 - Registro de Pagamento em Boleto Operador do caixa, Cliente Valor, Data de vencimento Boleto gerado e título criado com status pendente
PROC006 - Registro de Pagamento via PIX Operador do caixa, Cliente Valor (manual ou auto-preenchido), chave PIX/QR Code Status do pagamento (Aguardando, Pago, Expirado) e registro do pagamento
PROC007 - Registro de Pagamento em Outros Métodos Operador do caixa, Cliente Tipo de pagamento (vale, ticket, fidelidade), Valor, Código de autorização (opcional) Registro da transação alternativa
PROC008 - Adicionar múltiplas formas de pagamento Operador do caixa Lista de pagamentos inseridos Pagamentos registrados, saldo recalculado e acordeons atualizados
PROC009 - Editar pagamento já lançado Operador do caixa Dados do pagamento selecionado (valor, vencimento, parcelas etc.) Pagamento atualizado e saldo recalculado
PROC010- Excluir pagamento já lançado Operador do caixa Identificação do pagamento selecionado Pagamento removido e saldo recalculado
PROC011 - Quitar Restante Operador do caixa Saldo pendente e forma de pagamento selecionada Campo preenchido automaticamente com o valor restante
PROC012 - Finalizar Pagamento Operador do caixa Todos os pagamentos registrados e saldo zerado Venda concluída e registros financeiros emitidos
PROC013 - Cancelar Operador do caixa Ação do usuário Modal fechado sem registrar alterações

Descrição dos Campos:

Cabeçalho

Modelo 151.png

  • Registrar Pagamento → título da tela.

  • Data da venda→ indica a data e horário em que a venda foi realizada.

Resumo da Venda (lado esquerdo)

image-1761179732045.png

  • Total da Compra: → valor bruto da venda antes de descontos ou acréscimos.

  • Descontos: - R$ 0,00 → abatimento aplicado ao pedido.

  • Acréscimos: + R$ 0,00 → juros, taxas ou adicionais aplicados.

  • Total Líquido da venda: → valor final a ser pago, já considerando descontos e acréscimos.

  • O valor deve se atualizar automaticamente conforme os pagamentos são inseridos ou editados.

Pagamentos Adicionados (lado esquerdo)

image-1761179753260.png

Tabela com os pagamentos já registrados pelo usuário:

  • Nº Parcela → número sequencial da parcela.

  • Parcelas → quantidade total de parcelas.

  • Forma Pgtº → método escolhido (ex: cartão de crédito, boleto, etc.).

  • Valor → valor de cada parcela ou lançamento.

  • Data Vencimento → quando a parcela deve ser paga.

  • Ações → botões para excluir ou editar o pagamento.

 

Resumo de Pagamentos (lado esquerdo – rodapé)

image-1761179779525.png

  • Devedor: → valor que ainda não foi quitado.

  • Pago: → valor já registrado como pago.

  • Saldo a Pagar: → diferença pendente para concluir o pagamento.

  • Recebido: → valor efetivamente recebido em caixa.

  • Troco:  → valor a devolver ao cliente, se pago em dinheiro com valor maior.

Forma de Pagamento (lado direito)

image-1761179804555.png

Opções para escolha do método de pagamento:

  • Dinheiro

  • Crédito

  • Débito

  • Boleto

  • PIX

  • Outros (vale, ticket, fidelidade etc.)

Campos Variáveis por Forma de Pagamento
Dinheiro

  • Valor recebido (input)

  • Troco (calculado)

Cartão de Crédito

  • Valor

  • Quantidade de parcelas

  • Bandeira

  • CNPJ da credenciadora

  • Código de autorização

GAP: confirmar se o código de autorização é obrigatório em todas integrações TEF e todas UF (?)

Cartão de Débito

  • Valor

  • Bandeira

  • CNPJ da credenciadora

  • Código de autorização

Boleto

  • Valor

  • Data de vencimento

  • Botão “Gerar Boleto”
    GAP: boleto será gerado internamente ou via integração futura (?)

PIX

  • Valor

  • QR Code / chave PIX

  • Status: Aguardando, Pago ou Expirado

  • Botão “Copiar chave PIX”

GAP: pagamento pode ser finalizado antes da confirmação do PIX? (?)

Outros

  • Tipo de pagamento

  • Valor

  • Código de autorização (opcional)

Ações Principais

    image-1761179862711.png

    • Quitar Restante → ajusta o pagamento para liquidar o saldo total da venda automaticamente.

    • Adicionar Pagamento → insere o pagamento configurado na lista de "Pagamentos Adicionados".

    • Finalizar Pagamento → conclui a operação e fecha a venda.

    • Cancelar → interrompe o processo sem salvar.

     

    Especificação Funcional

    Regras de Interface:
    1. Estrutura Geral

    • A tela é dividida em dois grandes blocos:
      lado esquerdo (resumo e pagamentos adicionados) e lado direito (formas de pagamento e campos dinâmicos).

    • O layout deve ser responsivo e manter proporcionalidade entre colunas.

    2. Resumo da Venda

    • Sempre visível no topo do lado esquerdo.

    • Valores devem se recalcular automaticamente ao adicionar, editar ou excluir pagamentos.

    • Total Líquido deve refletir descontos e acréscimos em tempo real.

    3. Pagamentos Adicionados

    • Todos os pagamentos registrados devem ser exibidos em uma grid única, onde cada linha representa um lançamento individual — seja pagamento à vista, parcelado ou de qualquer forma de pagamento disponível.

    • A grid deve conter as colunas fixas:

      • Nº Parcela

      • Forma Pgtº

      • Valor

      • Data de Vencimento

      • Ações (Editar / Excluir)

    • Pagamentos parcelados (ex.: cartão de crédito) devem gerar uma linha por parcela, numeradas corretamente.

    • Pagamentos à vista devem gerar uma única linha.

    • Os ícones de edição e exclusão devem permanecer alinhados à direita da grid.

    • A grid deve recalcular os indicadores (Devedor, Pago, Saldo a Pagar) sempre que:

      • um pagamento for adicionado

      • editado

      • excluído

    • A ordenação da grid deve respeitar a ordem de inserção dos pagamentos.

    4. Indicadores Financeiros

    • Devedor, Pago, Saldo a Pagar, Recebido e Troco aparecem no footer do lado esquerdo.

    • Valores mudam conforme o usuário interage com a tela.

    • Troco só aparece quando a forma de pagamento ativa for "Dinheiro".

    5. Formas de Pagamento (painel direito)

    • Botões de seleção devem ter estado ativo/inativo bem definido.

    • Ao clicar em uma forma, exibem-se apenas os campos pertencentes àquela forma.

    • Mudança de forma limpa os campos preenchidos anteriormente (?)

    6. Campos Dinâmicos

    • Inputs numéricos devem aceitar apenas números válidos.

    • Data picker para vencimento deve respeitar bloqueios de datas inválidas (ex.: datas passadas?) (?)

    • Combobox/bandeiras carregados conforme cadastro prévio no sistema.

    7. Ações Principais

    • Adicionar Pagamento: sempre habilitado quando houver valores válidos preenchidos.

    • Quitar Restante: sugere automaticamente o valor faltante com a forma selecionada.

    • Finalizar Pagamento: habilitado somente quando Saldo a Pagar = 0.

    • Cancelar: fecha modal sem salvar.

    8. Mensagens e Validações

    • Alertas de erro devem aparecer inline abaixo do campo correspondente.

    • O sistema não deve permitir:

      • valores zero

      • valores negativos

      • parcelas sem valor

      • vencimentos inválidos

    • Quando o TEF/PIX estiver pendente, status deve aparecer destacado.

    9. Responsividade

    • O layout deve se adaptar para uso em telas menores, mantendo o agrupamento por colunas.

    • Acordeons devem se comportar como listas empilhadas no mobile.

    10. Comportamento do Modal

        • Modal deve bloquear ações externas enquanto ativo.

        • Fechamento por “X” ou “Cancelar” sempre descarta alterações.

        • Modal deve ser centralizado e com largura máxima definida para evitar poluição visual.

    Regras de Negócio:
    1. Não é permitido finalizar pagamento se houver saldo pendente.
    2. Pagamentos parciais podem ser feitos com diferentes formas de pagamento.
    3. O sistema deve validar valores inseridos (não permitir valor 0 ou negativo).
    4. No caso de PIX e boleto, o sistema deve aguardar confirmação do pagamento antes de marcar como quitado (quando integrado com gateway/banco).
    5. Para cartões de crédito/débito, deve ser gerada transação vinculada a TEF/API de pagamento quando disponível.
    6. O usuário deve conseguir registrar pagamentos múltiplos em diferentes formas.
    7. O sistema deve calcular automaticamente o saldo restante.
    8. Botão Finalizar Pagamento deve ficar disponível apenas quando o saldo for quitado.
    9. Tela deve estar responsiva e com boa usabilidade.
    Regras para o modal de pagamento unificado baseado nos formulários de telas origem

    • O sistema não deve exibir campos de Frete e Impostos no modal do Pagamento Unificado.

    • O sistema deve considerar Frete e Impostos no cálculo do Total da Compra somente se esses valores já fizerem parte do total enviado pela tela de origem.

    • O sistema não deve tentar carregar, exibir ou permitir edição de Frete ou Impostos dentro do modal.

    • Caso o usuário precise alterar Frete ou Impostos, ele deve cancelar o Pagamento Unificado, ajustar esses valores na tela de origem e, só então, reabrir o modal.

    • Ao reabrir o Pagamento Unificado, o sistema deve receber o total já recalculado na origem, incluindo Frete e Impostos quando aplicável.

    • Nenhum comportamento de UI referente a Frete ou Impostos será implementado no modal. Total Líquido será calculado apenas em cima do valor total recebido da origem, Descontos e Acréscimos.

    GAP: definir se a recusa do TEF cancela automaticamente o item no modal (?)

    Questões Técnicas:

    1. Descrição de mudanças na base de dados, ou integração de API, ou arquivo que deva ser gerado.

     

    Fluxos que Disparam o Pagamento Unificado

    Comercial

    • Orçamento → Permite registrar intenção de venda; caso seja convertido em venda com pagamento imediato, chamará o modal.

    • Pedido de Venda → Passa a acionar o modal para pagamentos à vista (dinheiro, cartão, PIX).

    • Ordem de Serviço → Chamará o modal quando o cliente pagar serviços à vista; mantém fluxo próprio em caso de parcelamento/boleto.

    • Pré-venda (?) → Deve ser avaliado se há necessidade de registrar pagamentos; se sim, pode usar o modal.

    • Venda Touch (?) → Se trabalhar com pagamento imediato no ponto de venda, integrará diretamente com o modal.

    Fiscal

    • NF-e → Ao registrar pagamento, deve indicar se é à vista ou a prazo; pagamentos à vista chamam o modal.

    • NFC-e → Funciona como frente de caixa; sempre que houver pagamento à vista, chamará o modal.

    • SAT (?) → Se integrado como emissão fiscal no PDV, deve acionar o modal para pagamentos imediatos.

    • NFS-e → Emissão de nota de serviço, chamará o modal quando o cliente pagar à vista.

    • CT-e → Precisa indicar se é à vista ou a prazo; pagamentos imediatos usam o modal.

    • Frente de Caixa (?) → Funcionalidade de vendas rápidas; integrará diretamente com o modal para dinheiro, cartão e PIX.

    Financeiro

      • Contas a Receber (receber) → Recebe os lançamentos originados dos pagamentos processados no modal (baixa imediata) e dos boletos/parcelamentos (baixa futura).

      • Contas a Pagar (pagar) → Embora não envolva o modal, deve ser avaliado para manter consistência no fluxo de caixa.

      • Movimento Financeiro (novo lançamento) → Atualizado automaticamente com registros vindos do modal de Pagamento Unificado, garantindo conciliação.

    Implementações de gatilho nos outros módulos

    1. Substituir as labels de pagamento em cada tela por Botão único de “Registrar Pagamento”:

      • Ao clicar, o sistema verifica a forma de pagamento selecionada.

      • Caso seja imediato, abre o modal.

      • Caso seja a prazo, carrega os campos da própria tela.

    2. Manter as labels e, na escolha da forma de pagamento o usuário já dá o gatilho.

        • Se selecionar Dinheiro, Cartão ou PIX → o sistema automaticamente abre o modal de Pagamento Unificado.

        • Se selecionar Boleto ou Parcelamento → o sistema mantém a tela atual e habilita os campos próprios do módulo.

    Protótipo:

    Receber pagamento

     

    ©SOFTEN SISTEMAS 2025

     

     

     

     

    No Comments
    Back to top