Tela Receber Pagamento

	Projeto/Sistema: GERENCIAMENTO DE PROJETOS	Versão do Template: 1.2
	Processo: Tela receber pagamento	Versão do Documento: 1.2
	Responsável(eis):  Jalile Cornachioni e Gustavo Evaristo	Data:  04/09/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, PDV/Caixa, restaurante). 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, mas deveriam ser processados de forma unificada.

O comportamento desejado é centralizar todos os pagamentos imediatos (dinheiro, cartão, PIX) em uma tela única (modal de Pagamento Unificado), reaproveitável por todos os módulos do GA. Assim, a experiência do usuário será padronizada e a manutenção simplificada. Os pagamentos a prazo (boleto ou parcelamento) permanecerão sendo tratados nos campos próprios de cada módulo, sem uso do modal.

 

2. Processo (adicionar fluxograma exemplo)

 

 

I - Fluxograma Exemplo

 

Processo	Envolvidos	Dados de Entrada	Dados de Saída
Aplicar desconto/acréscimo	Operador do caixa	Opção de forma de pagamento (Dinheiro, Crédito, Débito, Boleto, PIX, Outros)	Exibição dos campos correspondentes à forma escolhida
Registro de Pagamento em Dinheiro	Operador do caixa	Valor recebido	Cálculo automático do troco e valor quitado
Registro de Pagamento em Cartão de Crédito	Operador do caixa, Cliente	Valor, Quantidade de parcelas, Bandeira (opcional)	Registro do pagamento parcelado e integração futura com TEF/API
Registro de Pagamento em Cartão de Débito	Operador do caixa, Cliente	Valor, Bandeira (opcional)	Registro do pagamento à vista via débito, integração futura com TEF/API
Registro de Pagamento em Boleto	Operador do caixa, Cliente	Valor, Data de vencimento	Geração do boleto (simulação/mock) e status pendente até confirmação
Registro de Pagamento via PIX	Operador do caixa, Cliente	Valor (auto-preenchido ou manual), QR Code/Chave PIX	Status do pagamento (Aguardando, Pago, Expirado)
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
Gerenciamento de Pagamentos	Operador do caixa	Pagamentos já registrados	Listagem, edição e exclusão de pagamentos
Resumo de Pagamentos e Finalização	Operador do caixa	Total bruto, descontos, acréscimos, saldo restante	Exibição do resumo, liberação do botão "Finalizar Pagamento" apenas quando saldo quitado

Especificação Funcional

---

PROC001 Aplicar desconto/acréscimo:

Protótipo de Tela:

Descrição dos Campos:

Campo	Tipo	Tamanho	Obrig. ?	Máscara	Observações
Total da compra	Texto	100	Sim	-	-
Desconto
Acréscimo
Total líquido da Venda

Regras de Interface:

1. Resumo da Venda

• Exibir valor total da compra, descontos, acréscimos e total final.
• Deve ser atualizado automaticamente conforme os pagamentos forem registrados.

2. Formas de Pagamento

São apresentadas em botões rápidos: - Dinheiro - Cartão de Crédito - Cartão de Débito - Boleto - PIX -
Outros (Vale, Ticket, Fidelidade, etc.)

3. Variações de Campos por Forma de Pagamento

• Dinheiro
  • Campo: Valor recebido (input numérico).
  • Campo: Troco (calculado automaticamente).
• Cartão de Crédito
  • Campo: Valor (input numérico).
  • Campo: Quantidade de parcelas (select – mínimo 1x, máximo configurável).
  • Campo: Bandeira do cartão (combobox que permita seleção das bandeiras aceitas pelo governo).
  • Campo: CNPJ da Credenciadora (cadastrado na forma de pagamento e exibido na tela de pagamento).
  • Campo: Código da Transação (retornado durante a transação e edeve ser enviado para o governo).
• Cartão de Débito
  • Campo: Valor (input numérico).
  • Campo: Bandeira do cartão (combobox que permita seleção das bandeiras aceitas pelo governo).
  • Campo: CNPJ da Credenciadora (cadastrado na forma de pagamento e exibido na tela de pagamento).
  • Campo: Código da Transação (retornado durante a transação e edeve ser enviado para o governo).
• Boleto
  • Campo: Valor (input numérico).
  • Campo: Data de vencimento (date picker).
  • Botão extra: Gerar boleto.
• PIX
  • Campo: Valor (input numérico, pode ser auto-preenchido com saldo restante).
  • Geração automática de QR Code/Chave PIX.
  • Campo: Status (Aguardando, Pago, Expirado).
  • Botão extra: Copiar chave PIX.
• Outros (Vale Alimentação, Ticket, Fidelidade etc.)
  • Campo: Tipo de pagamento (select).
  • Campo: Valor (input numérico).
  • Campo opcional: Código de autorização / voucher.
• Pagamentos Adicionados
  • Listagem dos pagamentos já inseridos.
  • Ações disponíveis: Editar, Excluir.
• Resumo de Pagamentos
  • Exibir subtotal bruto, descontos, acréscimos e valor líquido.
  • Mostrar saldo restante caso não esteja totalmente quitado.
• Ações Principais
  • Adicionar Pagamento → Insere o pagamento na lista.
  • Quitar Restante → Preenche automaticamente o saldo pendente com a forma de pagamento
    selecionada.
  • Finalizar Pagamento → Conclui a venda se não houver saldo pendente.
  • Cancelar → Descarta a operação atual.

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.

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.

 

 

Processos Relacionados

---

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.

Possíveis implementações de gatilho:

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.

3. Botões separados (menos recomendado):

   • Um botão “Pagar agora” (dinheiro/cartão/PIX) → chama modal.

   • Um botão “Gerar cobrança” (boleto/parcelado) → habilita campos.

   • Essa opção pode deixar a interface poluída e menos intuitiva.

 

 

Protótipo:

Receber pagamento

 

©SOFTEN SISTEMAS 2025