Pagamento Unificado

Pagamento Unificado
PROC001 – Aplicar desconto/acréscimo
PROC002 – Registro de Pagamento em Dinheiro
PROC003 – Registro de Pagamento em Cartão de Crédito
PROC004 – Registro de Pagamento em Cartão de Débito
PROC005 – Registro de Pagamento em Boleto
PROC006 – Registro de Pagamento via PIX
PROC007 – Registro de Pagamento em Outros Métodos
PROC008 – Adicionar múltiplas formas de pagamento
PROC012 – Finalizar Pagamento

Pagamento Unificado

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

2. Fluxograma Geral

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

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

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)

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)

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é)

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)

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

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

Regras de Negócio:

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

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

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.
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

PROC001 – Aplicar desconto/acréscimo

Projeto/Sistema:
GERENCIAMENTO DE PROJETOS

Versão do Template:
1.2

Processo:
PROC001 – Aplicar desconto/acréscimo

Versão do Documento:
1.0

Responsável(eis):
Jalile Cornachioni

Data:

10/11/2025

1. Introdução

Definir o comportamento padrão para aplicação de desconto ou acréscimo durante o fluxo de pagamento unificado, considerando regras de interface, regras de negócio e impactos técnicos.

2. Processo (adicionar fluxograma exemplo)

-- Fluxograma PROC001 - Aplicar desconto/acréscimo --

Processo	Envolvidos	Dados de Entrada	Dados de Saída
PROC001 - Aplicar desconto/acréscimo	Frente de caixa / API Pagamento Unificado	Valor total, tipo de ajuste, origem da ação	Valor ajustado, log de alteração
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

Processos Relacionados

Especificação Funcional

PROC001 EXEMPLO:

Protótipo de Tela:

Descrição dos Campos:

Campo	Tipo	Tamanho	Obrig. ?	Máscara	Observações
Total da Compra	Numérico	10,2	Sim	R$	Herdado da tela de origem. Não inclui frete, impostos, descontos e acréscimos. Valor confiável enviado pela origem. Somente leitura.
Descontos	Numérico	10,2	Não	R$	Valor monetário. Campo editável. Não aceita sinal + ou -. Não pode exceder o Total da Compra. Pode zerar o total líquido.
Acréscimos	Numérico	10,2	Não	R$	Valor monetário. Campo editável. Não aceita sinal + ou -. Respeita limite máximo configurado, se existir.
Total Líquido da Venda	Numérico	10,2	Sim	R$	Calculado: Total da Compra - Desconto + Acréscimo. Somente leitura.

Regras de Interface:

O sistema deve exibir Total da Compra e Total Líquido como somente leitura.
O sistema deve apresentar Desconto e Acréscimo como campos monetários sempre habilitados para digitação.
O sistema não deve permitir caracteres inválidos, letras, símbolos, ou sinais negativo/positivo.
O sistema deve recalcular automaticamente o Total Líquido a cada alteração de Desconto ou Acréscimo.
O sistema deve aceitar valor zero em qualquer um dos campos.
O sistema deve impedir que Desconto seja maior que o Total da Compra.
O sistema deve impedir que Acréscimo ultrapasse o valor máximo configurado, quando existir.
O sistema deve seguir a regra global de arredondamento vigente no sistema (quando configurada).
O sistema não deve exibir frete, impostos ou outros totais no modal.

Regras de Negócio:

O sistema deve receber Total da Compra, Desconto e Acréscimo da tela de origem.
O sistema deve confiar integralmente nos valores enviados pela origem sem recálculo interno desses componentes.
O sistema deve considerar que o campo Desconto exibido no Pagamento Unificado representa somente o valor monetário de desconto enviado pela tela de origem, não deve carregar valores percentuais.
O sistema deve considerar que o campo Acréscimo exibido no Pagamento Unificado representa o valor monetário de acréscimos enviado pela origem, incluindo acréscimos derivados de frete, seguro, impostos ou outros itens adicionais.
O sistema deve assumir que qualquer valor de frete, seguro, impostos ou taxas já foi previamente aplicado e consolidado no Total da Compra ou permanecerá restrito à tela origem conforme regra dessa tela.
O sistema não deve recalcular nem agregar frete, impostos, seguros, taxas ou outros valores ao Desconto ou ao Acréscimo 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.
O sistema não deve permitir que os campos de desconto e acréscimo sejam carregados com valores nulos ou zerados quando a tela anterior já possuir totais definidos.
O sistema deve permitir que o usuário altere Descontos e Acréscimos diretamente na tela de pagamento.
O sistema deve validar que Desconto não excede o Total da Compra.
O sistema deve validar Acréscimo conforme configuração de limite máximo.
O sistema deve impedir Total Líquido negativo.
O sistema deve recalcular exclusivamente o Total Líquido, usando apenas: Total Líquido = Total da Compra - Desconto + Acréscimo.
Se o pagamento for finalizado, os valores atualizados de Desconto e Acréscimo devem retornar à tela de origem.
Se o pagamento for cancelado, nenhum valor deve retornar; a tela de origem deve permanecer inalterada.
O sistema não deve permitir divergência entre o valor final exibido no pagamento unificado e o valor final exibido na tela anterior após retorno.
O sistema deve registrar log seguindo o padrão global já existente, incluindo: usuário, horário, valores antes/depois e origem da ação.

Desconto maior que o total → "O desconto não pode exceder o valor da venda." Bloquear salvamento.
Acréscimo acima do limite → "O acréscimo informado ultrapassa o limite permitido." Impedir continuação.
Valor não numérico → "Digite apenas valores numéricos." Limpar entrada e manter foco.
Total Líquido negativo → "O valor final não pode ser negativo." Reverter último valor digitado.

Questões Técnicas:

Composição de valores
- total_compra: vem 100% da origem. Não inclui frete, impostos, seguros, descontos, acréscimos.
- desconto e acrescimo: monetários. Sem sinal. Percentual não existe no modal.
- total_liquido = total_compra - desconto + acrescimo.
Limites
- desconto ≤ total_compra. Pode zerar. Não pode exceder.
- acrescimo ≤ acrescimo_maximo quando existir.
- total_liquido ≥ 0.

©SOFTEN SISTEMAS 2025

PROC002 – Registro de Pagamento em Dinheiro

Projeto/Sistema:
GERENCIAMENTO DE PROJETOS

Versão do Template:
1.2

Processo:
PROC002 – Registro de Pagamento em Dinheiro

Versão do Documento:
1.0

Responsável(eis):
Jalile Cornachioni

Data:

11/11/2025

1. Introdução

Este documento especifica o comportamento da tela Registrar Pagamento quando a Forma de Pagamento for Dinheiro. Define campos, fluxo, regras de interface, regras de negócio e questões técnicas. Dinheiro é a forma default e o modal não pode abrir sem uma forma selecionada.

2. Processo (adicionar fluxograma exemplo)

-- Fluxograma PROC002 – Registro de Pagamento em Dinheiro --

Processo	Envolvidos	Dados de Entrada	Dados de Saída
PROC002 - Registro de Pagamento em Dinheiro	Operador do caixa	Valor recebido	Troco calculado, valor quitado e parcela registrada
PROC001 -Aplicar desconto/acréscimo	Operador do caixa	Valor do desconto ou acréscimo	Total líquido recalculado e resumo atualizado
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

Processos Relacionados

Especificação Funcional

PROC001 EXEMPLO:

Protótipo de Tela:

Descrição dos Campos:

Campo	Tipo	Tamanho	Obrig. ?	Máscara	Observações
Forma de Pagamento	Enum (Dinheiro, Crédito, Débito, Boleto, PIX, Outros	100	Sim	-	Default obrigatório: Dinheiro
Valor Recebido	Moeda (2 casas, ≥0)		Sim		Valor a ser pago, atribuir o valor total, foco inicia neste campo, usuário pode editar para realizar pagamento parcial
Troco	Moeda (2 casas)		Não		Somente leitura. Calculado em tempo real
Total Líquido da Venda	Moeda		-		Valor base da venda
Resumo de Pagamentos (Total a Pagar, Saldo a Pagar, Pago, Troco)	Moeda		-		Soma dos valores imputados
Vencimento	Data		Sim

Regras de Interface:

O sistema deve abrir o modal com Dinheiro já selecionado.
O sistema deve posicionar o foco em Valor Recebido ao abrir.
O sistema deve renderizar a seção condicional quando Dinheiro estiver selecionado, exibindo Valor Recebido e Troco.
O sistema deve habilitar o botão Adicionar Pagamento somente quando Valor Recebido > 0.
O sistema deve habilitar o botão Finalizar Pagamento somente quando Saldo a Pagar = 0.
O sistema deve exibir Vencimento preenchido com data atual.
O sistema não deve permitir abrir o modal sem uma forma de pagamento selecionada.

Regras de Negócio:

O sistema deve calcular o troco em tempo real.
O sistema deve atualizar o Saldo a Pagar e o Resumo de Pagamentos após cada inclusão/edição/exclusão.
O sistema deve espelhar o troco do lancamento ao Troco exibido no resumo.
O sistema deve aceitar múltiplos lançamentos de Dinheiro na mesma venda.
O sistema não deve aceitar Valor Recebido ≤ 0.
O sistema não deve permitir alterar a data de vencimento.
O sistema não deve permitir valores negativos.
O sistema deve rejeitar caracteres não numéricos, exceto separadores válidos.
O sistema deve impedir finalização com saldo pendente.
O sistema deve considerar possíveis falhas e retornar mensagem tratada ao usuário:
- “Existem valores pendentes. Finalize somente após quitar o saldo.”
- “Valor inválido. O valor não pode ser negativo.”
- “Falha ao registrar o pagamento. Tente novamente.”

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.

©SOFTEN SISTEMAS 2025

PROC003 – Registro de Pagamento em Cartão de Crédito

Projeto/Sistema:
GERENCIAMENTO DE PROJETOS

Versão do Template:
1.2

Processo:
PROC003 – Registro de Pagamento em Cartão de Crédito

Versão do Documento:
1.0

Responsável(eis):
Jalile Cornachioni

Data:

11/11/2025

1. Introdução

Este documento tem como objetivo detalhar o comportamento da interface e as regras de negócio referentes ao processo de Recebimento via Cartão de Crédito dentro do fluxo de Pagamento Unificado detalhando, confirmação da transação e registro do recebimento.

2. Processo (adicionar fluxograma exemplo)

-- Fluxograma PROC003 – Registro de Pagamento em Cartão de Crédito --

Usuário acessa a tela Registrar Pagamento.
Seleciona Crédito como forma de pagamento.
O sistema renderiza os campos condicionais de Crédito.
Usuário preenche valor, parcelas, vencimento, bandeira, código de autorização (quando manual) e CNPJ da credenciadora.
Se o ambiente estiver integrado ao TEF:
- O sistema envia a solicitação ao terminal.
- Se aprovado, retorna dados da transação e pré-preenche o código de autorização.
- Se recusado, o sistema bloqueia a inclusão.
- Se falhar a comunicação, o sistema exibe o modal:
  “Falha na comunicação com o terminal. Deseja registrar manualmente?”
- Se o usuário optar por registro manual, segue para o passo 6.
Usuário confirma Adicionar Pagamento.
O sistema valida regras de negócio e gera uma linha por parcela em “Pagamentos Adicionados”.
Usuário pode editar ou excluir parcelas individualmente.
Se houver pagamento em Dinheiro, o sistema renderiza o campo Troco, permitindo sua edição e atualização conforme diferença.
Usuário pode repetir o processo para adicionar outros cartões ou demais formas de pagamento.
Ao finalizar, o sistema valida soma total e libera a conclusão da operação.

Processo	Envolvidos	Dados de Entrada	Dados de Saída
PROC001 - Aplicar desconto/acréscimo	Frente de caixa / API Pagamento Unificado	Valor total, tipo de ajuste, origem da ação	Valor ajustado, log de alteração
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

Processos Relacionados

Especificação Funcional

PROC001 EXEMPLO:

Protótipo de Tela:

Descrição dos Campos:

Campo	Tipo	Tamanho	Obrig. ?	Máscara	Observações
Forma de Pagamento (personalizado)	Texto / Seleção	-	Sim	—	Renderizado apenas quando “Crédito” é selecionado.
Valor	Numérico	-	Sim	R$ 0.000,00	> 0. Aceita decimal. Pode vir pré-preenchido com saldo.
Parcelas	Inteiro	-	Sim	-	≥ 1. Sem limite, a menos que exista política global.
1º Vencimento	Data	-	Sim	DD/MM/AAAA	Default = hoje. Retroativo conforme configuração global.
Bandeira	Seleção	-	Sim	-	Lista carregada da tabela `bandeira_cartao`.
Código de Autorização	Texto	-	Sim (manual)	-	Obrigatório quando não houver TEF. Identificador da transação.
CNPJ Credenciadora	Texto	14	Sim	99.999.999/9999-99	Validação de CNPJ. Usado quando a captura exige conciliação/envio fiscal.

Regras de Interface:

O sistema deve:

Renderizar todos os campos condicionais ao selecionar Crédito, ou seja, parcelas, primeiro vencimento, bandeira, cod. autorização e CNPJ da credenciadora.
O campo bandeira deve oferecer uma lista das bandeiras mais utilizadas no país.
Habilitar o botão Adicionar Pagamento somente quando todos os campos obrigatórios estiverem preenchidos.
Criar uma linha por parcela na seção “Pagamentos Adicionados”.
Permitir edição e exclusão individual de cada parcela.
Renderizar o campo Troco somente quando existir pelo menos um pagamento em Dinheiro adicionado.
Permitir edição do valor de Troco apenas quando houver pagamento em Dinheiro.
Atualizar o Troco conforme a diferença entre o valor pago em Dinheiro e o saldo da venda.
Permitir inclusão de múltiplos cartões na mesma venda (multi-cartão).
Aplicar máscaras de valor, data e CNPJ conforme o padrão da aplicação.
Exibir aviso de duplicidade quando detectar combinação idêntica de valor + parcelas + vencimento + bandeira.
Exibir modal de contingência em caso de falha TEF:
“Falha na comunicação com o terminal. Deseja registrar manualmente?”.

O sistema não deve:

Permitir clique em Adicionar Pagamento com campos obrigatórios vazios.
Exibir o campo Troco quando não existir pagamento em Dinheiro.
Bloquear inclusão de múltiplos cartões em uma mesma venda.
Permitir finalização caso a soma dos pagamentos ultrapasse o valor total da venda.

Regras de Negócio:

O sistema deve validar que o Valor informado seja numérico e maior que zero.
Validar que Parcelas seja inteiro ≥ 1, respeitando limite configurado (se existir).
Definir 1º Vencimento como a data atual por padrão.
Permitir vencimento retroativo apenas se a configuração e permissões de usuário correspondente estiver ativa.
Garantir que o somatório das parcelas feche exatamente o valor total calculado.
O sistema deve recuperar o código da autorização da transação do TEF e vincular ao pedido quando o TEF retornar status Aprovado.
Exigir Código de Autorização quando o pagamento for registrado manualmente (sem TEF).
O sistema não deve aceitar pagamento manual sem Código de Autorização.
Em caso de Recusado, o sistema não deve permitir o fechamento do caixa com aquele lançamento.
Após confirmação, o botão Finalizar Pagamento deve ser exibido para conclusão do fluxo de pagamento.
Validar formato do CNPJ da Credenciadora.
O sistema não deve finalizar a venda quando houver inconsistências de soma, bandeira inválida ou CNPJ inválido
Permitir múltiplas inclusões de pagamentos em crédito (multi-cartão).
Bloquear finalização caso a soma dos pagamentos ultrapasse o valor da venda..

Questões Técnicas:

Integração com módulo TEF (API externa).
Logar toda tentativa, inclusive timeouts de comunicação TEF.
Em ambiente offline, bloquear operação com TEF.
O sistema deve criar uma tabela para armazenar as bandeiras de cartão, contendo apenas os campos id e descricao, seguindo o modelo abaixo:

CREATE TABLE bandeira_cartao (
id INT PRIMARY KEY,
descricao VARCHAR(60) NOT NULL
);

INSERT INTO bandeira_cartao (id, descricao) VALUES
(1, 'Visa'),
(2, 'Mastercard'),
(3, 'American Express'),
(4, 'Hipercard'),
(5, 'Elo');

©SOFTEN SISTEMAS 2025

PROC004 – Registro de Pagamento em Cartão de Débito

Projeto/Sistema:
GERENCIAMENTO DE PROJETOS

Versão do Template:
1.2

Processo:
PROC004 – Registro de Pagamento em Cartão de Débito

Versão do Documento:
1.0

Responsável(eis):
Jalile Cornachioni

Data:

10/11/2025

1. Introdução

Este processo visa exemplificar a documentação padrão

2. Processo (adicionar fluxograma exemplo)

I - Fluxograma Exemplo

Processo	Envolvidos	Dados de Entrada	Dados de Saída
Processo	N/A	N/A	N/A

Processos Relacionados

Documentação Exemplo 1

Documentação Exemplo 2

Especificação Funcional

PROC001 EXEMPLO:

Protótipo de Tela:

Descrição dos Campos:

Campo	Tipo	Tamanho	Obrig. ?	Máscara	Observações
Campo	Texto	100	Sim	-	-

Regras de Interface:

1. Exemplo de regras do campo:
Descrição das regras de interface ou de tela. Eventos em campos ou botões, bloqueios ou desbloqueios e outras alterações.

Regras de Negócio:

1. Exemplo de regras de negócio (Exemplo de calculo imposto):
Descrição das regras de negócio envolvendo o processo, como cálculos, ações em botões e outras regras envolvendo a lógica por trás do processo.

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.

©SOFTEN SISTEMAS 2025

PROC005 – Registro de Pagamento em Boleto

Projeto/Sistema:
GERENCIAMENTO DE PROJETOS

Versão do Template:
1.2

Processo:
Descrição Processo

Versão do Documento:
1.0

Responsável(eis):
Jalile Cornachioni

Data:

10/11/2025

1. Introdução

Este processo visa exemplificar a documentação padrão

2. Processo (adicionar fluxograma exemplo)

I - Fluxograma Exemplo

Processo	Envolvidos	Dados de Entrada	Dados de Saída
Processo	N/A	N/A	N/A

Processos Relacionados

Documentação Exemplo 1

Documentação Exemplo 2

Especificação Funcional

PROC001 EXEMPLO:

Protótipo de Tela:

Descrição dos Campos:

Campo	Tipo	Tamanho	Obrig. ?	Máscara	Observações
Campo	Texto	100	Sim	-	-

Regras de Interface:

1. Exemplo de regras do campo:
Descrição das regras de interface ou de tela. Eventos em campos ou botões, bloqueios ou desbloqueios e outras alterações.

Regras de Negócio:

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.

©SOFTEN SISTEMAS 2025

PROC006 – Registro de Pagamento via PIX

Projeto/Sistema:
GERENCIAMENTO DE PROJETOS

Versão do Template:
1.2

Processo:
Descrição Processo

Versão do Documento:
1.0

Responsável(eis):
Jalile Cornachioni

Data:

10/11/2025

1. Introdução

Este processo visa exemplificar a documentação padrão

2. Processo (adicionar fluxograma exemplo)

I - Fluxograma Exemplo

Processo	Envolvidos	Dados de Entrada	Dados de Saída
Processo	N/A	N/A	N/A

Processos Relacionados

Documentação Exemplo 1

Documentação Exemplo 2

Especificação Funcional

PROC001 EXEMPLO:

Protótipo de Tela:

Descrição dos Campos:

Campo	Tipo	Tamanho	Obrig. ?	Máscara	Observações
Campo	Texto	100	Sim	-	-

Regras de Interface:

1. Exemplo de regras do campo:
Descrição das regras de interface ou de tela. Eventos em campos ou botões, bloqueios ou desbloqueios e outras alterações.

Regras de Negócio:

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.

PROC007 – Registro de Pagamento em Outros Métodos

Projeto/Sistema:
GERENCIAMENTO DE PROJETOS

Versão do Template:
1.2

Processo:
PROC007 – Registro de Pagamento em Outros Métodos

Versão do Documento:
1.0

Responsável(eis):
Jalile Cornachioni

Data:

10/11/2025

1. Introdução

Este processo visa exemplificar a documentação padrão

2. Processo (adicionar fluxograma exemplo)

I - Fluxograma Exemplo

Processo	Envolvidos	Dados de Entrada	Dados de Saída
Processo	N/A	N/A	N/A

Processos Relacionados

Documentação Exemplo 1

Documentação Exemplo 2

Especificação Funcional

PROC001 EXEMPLO:

Protótipo de Tela:

Descrição dos Campos:

Campo	Tipo	Tamanho	Obrig. ?	Máscara	Observações
Campo	Texto	100	Sim	-	-

Regras de Interface:

1. Exemplo de regras do campo:
Descrição das regras de interface ou de tela. Eventos em campos ou botões, bloqueios ou desbloqueios e outras alterações.

Regras de Negócio:

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.

PROC008 – Adicionar múltiplas formas de pagamento

Projeto/Sistema:
GERENCIAMENTO DE PROJETOS

Versão do Template:
1.2

Processo:
PROC008 – Adicionar múltiplas formas de pagamento

Versão do Documento:
1.0

Responsável(eis):
Jalile Cornachioni

Data:

10/11/2025

1. Introdução

Este processo visa exemplificar a documentação padrão

2. Processo (adicionar fluxograma exemplo)

I - Fluxograma Exemplo

Processo	Envolvidos	Dados de Entrada	Dados de Saída
Processo	N/A	N/A	N/A

Processos Relacionados

Documentação Exemplo 1

Documentação Exemplo 2

Especificação Funcional

PROC001 EXEMPLO:

Protótipo de Tela:

Descrição dos Campos:

Campo	Tipo	Tamanho	Obrig. ?	Máscara	Observações
Campo	Texto	100	Sim	-	-

Regras de Interface:

1. Exemplo de regras do campo:
Descrição das regras de interface ou de tela. Eventos em campos ou botões, bloqueios ou desbloqueios e outras alterações.

Regras de Negócio:

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.

PROC012 – Finalizar Pagamento

Projeto/Sistema:
GERENCIAMENTO DE PROJETOS

Versão do Template:
1.2

Processo:

PROC012 – Finalizar Pagamento

Versão do Documento:
1.0

Responsável(eis):
Jalile Cornachioni

Data:

10/11/2025

1. Introdução

Este processo visa exemplificar a documentação padrão

2. Processo (adicionar fluxograma exemplo)

I - Fluxograma Exemplo

Processo	Envolvidos	Dados de Entrada	Dados de Saída
Processo	N/A	N/A	N/A

Processos Relacionados

Documentação Exemplo 1

Documentação Exemplo 2

Especificação Funcional

PROC001 EXEMPLO:

Protótipo de Tela:

Descrição dos Campos:

Campo	Tipo	Tamanho	Obrig. ?	Máscara	Observações
Campo	Texto	100	Sim	-	-

Regras de Interface:

1. Exemplo de regras do campo:
Descrição das regras de interface ou de tela. Eventos em campos ou botões, bloqueios ou desbloqueios e outras alterações.

Regras de Negócio:

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.

Pagamento Unificado

Pagamento Unificado

1. Introdução

2. Fluxograma Geral

Processos Relacionados

Cabeçalho

Resumo da Venda (lado esquerdo)

Pagamentos Adicionados (lado esquerdo)

Resumo de Pagamentos (lado esquerdo – rodapé)

Forma de Pagamento (lado direito)

Campos Variáveis por Forma de Pagamento

Dinheiro

Cartão de Crédito

Cartão de Débito

Boleto

PIX

Outros

Ações Principais

Especificação Funcional

Regras de Interface:

1. Estrutura Geral

2. Resumo da Venda

3. Pagamentos Adicionados

4. Indicadores Financeiros

5. Formas de Pagamento (painel direito)

6. Campos Dinâmicos

7. Ações Principais

8. Mensagens e Validações

9. Responsividade

10. Comportamento do Modal

Regras de Negócio:

Regras para o modal de pagamento unificado baseado nos formulários de telas origem

Questões Técnicas:

Fluxos que Disparam o Pagamento Unificado

Implementações de gatilho nos outros módulos

Protótipo:

PROC001 – Aplicar desconto/acréscimo

1. Introdução

2. Processo (adicionar fluxograma exemplo)

Processos Relacionados

Especificação Funcional

PROC001 EXEMPLO:

Protótipo de Tela:

Descrição dos Campos:

Regras de Interface:

Regras de Negócio:

Regras para mensagens e validações

Questões Técnicas:

PROC002 – Registro de Pagamento em Dinheiro

1. Introdução

2. Processo (adicionar fluxograma exemplo)

Processos Relacionados

Especificação Funcional

PROC001 EXEMPLO:

Protótipo de Tela:

Descrição dos Campos:

Regras de Interface:

Regras de Negócio:

Questões Técnicas:

PROC003 – Registro de Pagamento em Cartão de Crédito

1. Introdução

2. Processo (adicionar fluxograma exemplo)

Processos Relacionados

Especificação Funcional

PROC001 EXEMPLO:

Protótipo de Tela:

Descrição dos Campos:

Regras de Interface:

Regras de Negócio:

Questões Técnicas:

PROC004 – Registro de Pagamento em Cartão de Débito

1. Introdução

2. Processo (adicionar fluxograma exemplo)

Processos Relacionados

Especificação Funcional

PROC001 EXEMPLO:

Protótipo de Tela:

Descrição dos Campos:

Regras de Interface:

Regras de Negócio: