Financeiro
- Contas a Receber
- Tela de listagem de receitas a receber
- Tela nova receita
- Tela de visualização da receita
- Tela de edição da receita
- Tela de recebimento
- Nova ação: Cancelar Receita
- Contas a Pagar
- Tela de listagem de contas a pagar
- Tela Nova Despesa
- Tela de visualização da despesa
- Tela de edição da despesa
- Tela de pagamento
- 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
- Contas a Pagar
Contas a Receber
Tela de listagem de receitas a receber
| Projeto/Sistema: |
Versão do Template: 1.1 |
| Processo: Tela de listagem de receitas a receber |
Versão do Documento: 1.0 |
| Responsável(eis): Jalile Cornachioni |
Data: 08/08/2025 |
1. Objetivo geral:
2. Impacto previsto:
3. Descrição das alterações
#1. Tela de listagem de receitas a receber
- Tornar a experiência mais intuitiva e eficiente.
- Expor indicadores financeiros de forma clara e visual.
- Facilitar buscas com filtro dinâmico multi-coluna.
- Destacar acesso rápido a ações relevantes (recebimento, remessa, retorno).
- Reduzir o número de cliques para ações rotineiras.
3.1 Header:
Deve apresentar o título da tela, caminho acessado e botão de nova receita [funcionalidade existente - manter]
3.2 Cards com indicadores financeiros que servem de filtro [funcionalidade nova]
-
-
- Vencidas – vermelho (#DB102B) – ícone de alerta.
- A Vencer – amarelo (#FFB300) – ícone de relógio.
- Recebidas – verde (#009966) – ícone de check.
- Total Geral – azul (#044572) – ícone de cifrão.
-
-
-
- Estado inicial (dependente da data de vencimento padrão)
- O sistema deve considerar a data de vencimento vinda do filtro como referência (por padrão, data atual do sistema – today).
- Se existirem registros para o período filtrado:
- Todos os cards correspondentes aos status encontrados são carregados selecionados e coloridos.
- A grid exibe os registros de todos os cards selecionados.
- Se não existirem registros para um status na data filtrada:
- O card é carregado desmarcado e exibido em cinza (estilo “desabilitado”).
- A grid não exibe registros desse status.
- Caso nenhum card tenha registros para a data filtrada (ex.: domingo sem títulos):
- Todos os cards carregam em cinza/desabilitado.
- A grid permanece vazia.
-
Interação: Cada card funciona como um checkbox visual:
- Selecionado: cor ativa e registros exibidos na grid.
- Desmarcado: cor cinza e registros ocultos.
- É possível selecionar ou desmarcar múltiplos cards simultaneamente para refinar a exibição.
- Ao alterar o período de vencimento no filtro e aplicar, O sistema recalcula quais cards têm registros.
- Aplica automaticamente o estado colorido/ativo ou cinza/inativo.
- Atualiza a grid em tempo real.
3.3 Sessão de filtros [funcionalidade existente - manter conforme protótipo]
- Tipo data = Vencimento
- Campo “Data inicial”: pré-preenchido com data atual do sistema (today).
- Campo “Data final”: pré-preenchido com data atual do sistema (today).
- Validação: data final não pode ser anterior à inicial.
- Conta (dropdown) - Valor padrão: “Todas”.
- Filtro de Informações: Campo de texto = vazio por padrão.
- Dropdown lateral: valor padrão “Cliente”.
- Botão de busca (ícone lupa) dispara aplicação dos filtros.
3.4 Grid de listagem de registros
- Receber – Ação para registrar recebimento de títulos. Estado inicial: desabilitado e habilita quando o usuário selecionar ao menos um título.
- Remessa – Geração de arquivo de remessa bancária. Estado inicial: desabilitado e habilita quando o usuário selecionar ao menos um título.
- Retorno – Importação de arquivo de retorno bancário. Abre dialog para importação de arquivo.
- Relatórios – Acesso rápido a relatórios financeiros. Abre dialog com lista de relatórios existentes.
- Ações em Lote – Dropdown com múltiplas ações aplicáveis aos registros selecionados. Estado inicial: desabilitado e habilita quando o usuário selecionar ao menos um título.
- Filtros – Botão para expandir/contrair painel de filtros.
- Estado inicial: todos os filtros selecionados, caso deseje, o usuário poderá desmarcar.
- Filtros são combináveis entre si (ex.: “Com anexos” + “Registrados” + "Sem Registros).
- Exibição – Mostra quais colunas da grid o usuário pode exibir ou ocultar.
- Estado inicial: Colunas ocultas por padrão: "Juros/Receita", "Transferências" e "Categoria/Plano"
- A ordem das opções deve seguir a ordem das colunas.
3.5 Coluna situações:
-
- Registros: opções Registrados (azul) / Não registrados (cinza)
- Anexos: opções Com anexos (azul) / Sem anexos (cinza)
- Todos os títulos devem possuir ambos ícones (papelzinho e clips) com o padrão de de cores azul para situação ativa e cinza para a negativa.
- Manter o comportamento de permitir apenas 1 anexo. Caso o usuário deseje importar outro anexo, o primeiro será sobrescrito.
- Ícones ativos possuem a cor correspondente e exibem tooltip ao passar o mouse (por exemplo: "Agendado", "Com anexos", "Registrado").
3.6 Footer
Descrição: Localizado na parte inferior da tabela Lista de Contas a Receber. Deve exibir itens por página com opções pré-definidas 15, 50 e 100 registros, Paginação numérica para navegar entre as páginas. O valor 15 está definido como padrão de carregamento inicial.
Função: Controlar quantos registros são exibidos simultaneamente na grid, permitir navegação entre páginas de forma sequencial ou direta (selecionando um número da paginação), otimizar o carregamento e a performance da tela, evitando que todos os registros sejam carregados de uma só vez.
Comportamento:
-
Quantidade de registros
-
Por padrão, a grid carrega 15 registros por página.
-
Ao selecionar 50 ou 100, o sistema recarrega a grid exibindo mais linhas sem alterar o estado dos filtros ou dos cards.
-
-
Rolagem da tela inteira
-
A grid não possui scroll interno; a rolagem é aplicada à tela inteira.
-
Isso significa que, ao rolar para baixo, o usuário perde de vista o header com os filtros e os cards, dificultando a referência visual.
-
4. Link do Protótipo
5. Telas
©SOFTEN SISTEMAS 2025
Tela nova receita
| Projeto/Sistema: |
Versão do Template: 1.1 |
| Processo: Tela nova receita |
Versão do Documento: 1.0 |
| Responsável(eis): Jalile Cornachioni |
Data: 14/08/2025 |
1. Objetivo geral:
2. Impacto previsto:
3. Descrição das alterações
#2 - Tela de nova receita
A tela de Nova Receita tem como objetivo permitir que o usuário cadastre rapidamente um novo lançamento no Contas a Receber, informando os dados essenciais. Reposicionamos os campos obrigatórios e mais utilizados para o topo da tela, facilitando o acesso e acelerando o preenchimento. Embora a funcionalidade em si não tenha mudado, o layout foi modernizado para melhorar a experiência do usuário e reduzir o tempo de operação.
3.1 Header – Informações da Receita
-
Título: Nova Receita - Identificação visual da área de cadastro da receita.
-
Campos obrigatórios e prioritários: Cliente, Número do Documento, Descrição, Conta, Categoria, Data de Vencimento, Forma de Pagamento e Valor da Receita.
-
Valores default: Conta = "Caixa Fìsico" e Forma de Pagamento = "Dinheiro".
-
Indicador de status: Selo “A Vencer” posicionado no topo direito, em amarelo (#FFB300).
3.2. Grid – Repetição de Lançamentos
-
Campos de configuração: Quantidade de lançamentos e período de repetição (ex.: mensal).
-
Tabela de parcelas: Lista com número da parcela e respectiva data de lançamento.
-
Controles de expansão/retração: Permitem ocultar ou exibir detalhes dessa seção.
3.3. Rodapé – Informações Adicionais e Ações
-
Campo de observação: Área livre para comentários e detalhes adicionais.
-
Upload de comprovante: Botão “Adicionar Comprovante” com instruções de formato e tamanho de arquivo.
-
Botões de ação: “Salvar e Fechar” e “Salvar e Receber”, posicionados para finalização rápida da operação.
3.4 Comportamento geral da tela:
No estado inicial, a sessão "informações da receita" deve estar no estado expanded (aberto) e os demais accordions renderizados em estado collapsed (fechados), exibindo apenas o header de cada seção. O usuário pode expandir ou retrair cada accordion de forma independente, conforme sua necessidade.
4. Link do Protótipo
5. Telas
©SOFTEN SISTEMAS 2025
Tela de visualização da receita
| Projeto/Sistema: |
Versão do Template: 1.1 |
| Processo: Tela de visualização da receita |
Versão do Documento: 1.0 |
| Responsável(eis): Jalile Cornachioni |
Data: 08/08/2025 |
1. Objetivo geral:
2. Impacto previsto:
3. Descrição das alterações
#3. Tela de visualização da receita
O objetivo da criação desta nova tela de detalhes da receita é centralizar a visualização completa das informações de um título no Contas a Receber em um formato não editável por padrão, garantindo mais segurança contra alterações acidentais, padronizando o fluxo de consulta e edição conforme o status do título e as permissões do usuário.
Além disso, ela permite acesso rápido a anexos, histórico e dados complementares, servindo como um ponto único de consulta antes de qualquer ação de edição ou recebimento, reduzindo erros operacionais e aumentando a rastreabilidade das mudanças.
3.1 Detalhes da tela
3.1.1 Header (Cabeçalho)
Objetivo: Apresentar de forma clara a identificação do título, status e ações principais.
- Título da página: Label: "Receita [Número da Receita]" (ex.: Receita 12345-1/3)
- Ícone indicando registro e anexo: Icon de boletinho para indicar registro e clips para títulos com anexo.
- Status do título: Label: "À vencer", "Vencido", "Recebido"
- Informações de criação: Label: "Criado em [Data] por [Usuário]"
- Botões de ação: Editar (ícone de lápis), Receber (ícone de confirmação/pagamento),
- Ações: (menu dropdown com opções adicionais.)
Obs.: O botão "receber" muda para "estornar" quando o status do título for "recebido".
O dropdown deve oferecer ações de acordo com a regras de status já existentes, adicionar ação de "excluir" e "baixa como perda" - estes status devem estar ativos/inativos conforme permissão do usuário.
3.2.2. Grid (Corpo da tela)
Objetivo: Exibir todos os dados da receita de forma organizada em blocos de informação.
Bloco 1:
- Cliente: Label: "Cliente" – valor: nome do cliente
- Número Documento: Label: "Número Documento" – código ou número de referência
- Descrição:
- Conta: Label: "Conta" – conta bancária vinculada
- Categoria: Label: "Categoria" – categoria da receita (ex.: Alimentício)
- Forma de Pagamento: Label: "Forma de Pagamento" – ex.: Dinheiro, Pix, Cartão etc.
- Data de Vencimento: Label: "Data de Vencimento" – valor formatado (DD/MM/AAAA)
- Valor da Receita: Label: "Valor da Receita" – valor em moeda
OBS.: em alguns casos exibir o campo: "Juros adicional do boleto", de acordo com a configuração da conta selecionada.
Bloco 2
- Alterações de Valores: área de texto exibindo campos que alteram o valor, seja por juros, desconto, etc.
- Valor Original; Juros/Multa; Desconto; Valor
Bloco 3 e 4
- Informações Adicionais: área de texto exibindo a descrição ou observações complementares
- Anexos: Miniatura/listagem de anexos: com botão "Abrir anexo"
3.2 Comportamento geral e regras da tela
A tela de visualização de receita deve ser exibida em modal sempre que o usuário clicar em qualquer registro da listagem do contas a receber.
Todos os botões devem estar habilitados para interação, independente do status do título.
Esta tela não deve permitir edição, a não ser que o usuário clique no botão "editar". Ao clicar em "editar" deve-se aplicar regras conforme os seguintes cenários:
Regras mandatórias:
- Usuário super_admin:
- Permissão de usuário "Financeiro > Contas a Receber":
- Permissão de usuário "Financeiro > Alterar Contas A Receber":
- Permissão de usuário "Financeiro > Alterar Valor A Receber":
Cenário 1 – Títulos vencidos e a vencer : Abrir diretamente no modo edição.
Cenário 2 – Títulos abertos, porém registrados: Abrir tela de visualização e executar as seguintes validações:
-
-
Se usuário Admin → edição completa, sem restrições.
-
Se usuário Não-admin com todas as permissões → edição de tudo, exceto valores.
-
Se usuário Não-admin com permissões parciais → respeitar restrições de acordo com o módulo financeiro.
-
Se usuário Sem permissão → exibir mensagem de bloqueio: "Este título já está registrado. Caso precise modificar informações bloqueadas, entre em contato com um administrador."
-
Cenário 3 – Títulos recebidos:
- Permitir apenas visualização;
- Sessão: Informações do recebimento
- Valor recebido, Data de pagamento, Juros, Multa.
- ao clicar em "editar", o sistema deve exibir aviso sobre necessidade de estorno: "Não é possível alterar o vencimento ou valor de um título já recebido. Para prosseguir, realize o estorno do recebimento e tente novamente."
3.3 Registro em Log
Para garantir rastreabilidade e auditoria das ações realizadas no sistema, toda operação de alteração em títulos deve gerar um registro em log contendo, no mínimo, os seguintes campos:
-
Data/Hora da ação – momento exato em que a alteração foi realizada.
-
Usuário – identificação única do usuário (ID) e nome completo responsável pela ação.
-
Status anterior e novo do título – somente quando houver alteração de status.
-
Lista de campos alterados – exibição dos campos modificados com seus respectivos valores antes e depois da edição.
4. Link do Protótipo
5. Telas
©SOFTEN SISTEMAS 2025
Tela de edição da receita
| Projeto/Sistema: GERENCIAMENTO DE PROJETOS |
Versão do Template: 1.1 |
| Processo: Tela de edição da receita |
Versão do Documento: 1.1 |
| Responsável(eis): Jalile Cornachioni |
Data: 20/08/2025 |
1. Objetivo geral:
2. Impacto previsto:
3. Descrição das alterações
#4 - Tela de edição da receita
O objetivo da nova tela de edição da receita é restringir a alteração de campos sensíveis, garantindo maior segurança dos dados financeiros e evitando inconsistências em relatórios. Diferente do modelo atual, que permite editar todas as informações, a edição passa a respeitar o status do título (à vencer, vencido, recebido e perdido) e as permissões do usuário, permitindo apenas ajustes realmente necessários, como observações, comprovantes ou variações de valores autorizadas. Essa mudança fortalece a confiabilidade do sistema e cria a base para o novo fluxo de baixa por perda, assegurando rastreabilidade entre títulos recebidos, em aberto e insolventes.
3.1 Detalhes da tela
3.1.1 Header (Cabeçalho)
Objetivo: Apresentar de forma clara a identificação do título, status e ações principais.
- Título da página: Editar Receita [Número da Receita]" (ex.: Receita 12345-1/3)
- Ícone indicando registro e anexo: Icon de boletinho para indicar registro e clips para títulos com anexo.
- Status do título: Label: "À vencer", "Vencido", "Recebido"
- Informações de criação: Label: "Criado em [Data] por [Usuário]"
3.1.2 Informações da Receita
-
Cliente (campo bloqueado, apenas visualização).
-
Número do Documento e Descrição.
-
Conta, Categoria, Forma de Pagamento.
-
Data de Vencimento.
-
Valor da Receita (com validações de edição).
- Acréscimo de boleto (respeitando a configuração da conta seleiconada"
3.1.3 Alterações de valores
-
Valor Original (bloqueado).
-
Juros/Multa (editável conforme status).
-
Desconto (editável conforme status).
-
Valor da Receita final (cálculo automático com destaque).
3.1.4 Informações adicionais
-
Observação (texto livre).
-
Comprovantes: upload de arquivos (limite de tamanho, extensões permitidas, múltiplos anexos).
3.1.5 Botões de ação:
- Salvar e Fechar: Salva alterações e fecha a tela voltando para a tela de listagem de receitas
- Salvar e Receber: Salva alterações e abre tela de recebimento
4. Link do Protótipo
5. Telas
©SOFTEN SISTEMAS 2025
Tela de recebimento
| Projeto/Sistema: |
Versão do Template: 1.1 |
| Processo: Recebimento |
Versão do Documento: 1.0 |
| Responsável(eis): Jalile Cornachioni |
Data: 20/08/2025 |
1. Objetivo geral:
2. Impacto previsto:
3. Descrição das alterações
3.1 Detalhes da tela
3.1.1 Header (Cabeçalho)
- Título: “Receber Conta”
3.1.2. Dados de Recebimento
- Data Recebimento (campo obrigatório): campo de data com calendário para seleção.
- Conta: lista suspensa para escolha da conta de destino (ex.: Caixa, Banco).
- Categoria: campo de seleção para classificação do recebimento (vinculado ao plano de contas).
3.1.3. Referente a estes pagamentos (Tabela de Títulos)
- Tabela listando os títulos selecionados para recebimento, com as seguintes colunas:
- Desc./Cliente: identificação do cliente ou descrição da receita.
- Nº Documento: número do título/documento.
- Vencimento: data de vencimento do título.
- Valor Original: valor principal do título.
- Multa: campo editável para inserção de multa.
- Juros: campo editável para juros aplicados.
- Desconto: campo editável para descontos concedidos.
- Acréscimo: campo editável para acréscimos manuais.
- Valor a Receber: cálculo automático do valor final considerando os ajustes.
3.1.4. Ações do Rodapé
- Cancelar: retorna para a tela anterior sem efetivar o recebimento.
- Receber: confirma a operação de baixa, aplicando os valores informados.
3.2 Comportamento geral da tela:
A tela deve abrir em modo edição com os campos:
- Data recebimento deve ser atribuído data atual e respeitar a configuração FInanceiro > Proibir lançamentos com data retroativa", ou seja, habilitar somente se este campo estiver desmarcado na configuração adicional do sistema.
- Todos os demais campos dever estar habilitados para edição, respeitando as configurações de usuário.
- Ao imputar valor nos campos de acréscimo, juros/multa e/ou desconto o sistema deve recalcular o valor no campo "Valor a receber" (manter o funcionamento atual)
4. Link do Protótipo
5. Telas
Nova ação: Cancelar Receita
| Projeto/Sistema: Evolução do Produto GA - Interno |
Versão do Template: 1.1 |
| Processo: Nova ação: Cancelar Receita |
Versão do Documento: 1.1 |
| Responsável(eis): Jalile Cornachioni |
Data: 20/082/2025 |
1. Introdução
A funcionalidade de Receita Cancelada tem como objetivo permitir que títulos inadimplentes/insolventes sejam removidos da visão do cliente, sem exclusão, preservando o histórico para auditoria. A ação pode ser aplicada de forma individual ou em lote, sempre de forma controlada por permissões.
2. Processo
-
Usuário acessa um título registrado.
-
Clica em Cancelar Receita.
-
Sistema abre modal de confirmação (informativo + detalhes do título).
-
Usuário preenche o campo Justificativa informando o Motivo do Cancelamento (obrigatório).
-
Confirma ação clicando em Cancelar Título.
-
Sistema:
-
Zera valor da receita.
-
Mantém data de vencimento e demais informações originais.
-
Registra log/auditoria da ação.
-
-
Exibe mensagem de sucesso:
“Cancelamento registrado com sucesso.”
Especificação Funcional
Protótipo de Tela:
Descrição dos Campos:
-
-
Título da tela: Cancelar Receita.
-
Dados exibidos (somente leitura): Cliente, Número do Documento, Conta, Forma de Pagamento, Data de Vencimento, Descrição, Categoria, Valor da Receita.
-
Data do cancelamento: preenchida automaticamente com a data atual do sistema (não editável).
-
Usuário responsável: preenchido automaticamente com o usuário logado (não editável).
-
Campo Justificativa (obrigatório):
-
Tipo: Texto.
-
Limite sugerido: 500 caracteres.
-
Validação: não permitir salvar sem preenchimento.
-
-
Regras de Interface:
-
Mensagem exibida no modal, antes do botão confirmar:
Atenção: esta ação irá zerar o valor do título. Esta operação não poderá ser desfeita.
- Botões
- Cancelar Título (ação positiva, cor destacada). Fechar modal e exibir mensagem de sucesso: “Cancelamento registrado com sucesso.”
- Cancelar (fecha modal sem alterações).
Regras de Negócio:
- Cancelar Receita
- Ao clicar em "Cancelar Receita", o sistema deve:
-
Alterar o valor do título para
0,00. - Solicitar o motivo do cancelamento em campo de texto aberto (obrigatório).
-
- Ao clicar em "Cancelar Receita", o sistema deve:
- Relatórios e consultas
- Não entram em relatórios de valores em aberto/recebidos por padrão.
- Verificar possibilidade de Filtro adicional: Incluir títulos cancelados (zerados).
-
Log/Auditoria
-
Registrar:
-
Data/hora da ação.
-
Usuário responsável.
-
Ação: “Cancelamento de título”.
-
Motivo informado.
-
-
Questões Técnicas:
-
Criar o processo de cancelamento de receita para atualizar campos:
-
valor = 0.00
-
-
Criar entrada em log (pode ser tabela existente ou nova tabela de auditoria).
-
Ajustar relatórios/dashboards para:
-
Excluir títulos com valor
0,00por padrão. -
Disponibilizar filtro “Incluir títulos cancelados (zerados)”.
-
-
Permissões de Usuário
-
Nova permissão: Permite cancelar título.
-
Local: Configurações > Usuários e permissões > Financeiro.
-
Default: desmarcado.
-
-
Relatório de Títulos Cancelados (verificar possibilidade de crair)
-
Acesso restrito a usuários com permissão contábil/financeira.
-
Exibir sempre valor zerado e vencimento original.
-
Não alterar dados originais no banco (apenas zerar valor).
-
Disponibilizar exportação (CSV, XLSX, PDF).
-
©SOFTEN SISTEMAS 2025
Contas a Pagar
Tela de listagem de contas a pagar
| Projeto/Sistema: EVOLUÇÃO DO PRODUTO GA |
Versão do Template: 1.2 |
| Processo: Tela de listagem de contas a pagar |
Versão do Documento: 1.0 |
| Responsável(eis): Jalile Cornachioni |
Data: 25/08/2025 |
1. Objetivo geral:
2. Impacto previsto:
3. Descrição das alterações
#1 - Tela de listagem de despesas
- Tornar a experiência mais intuitiva e eficiente.
- Expor indicadores financeiros de forma clara e visual.
- Facilitar buscas com filtro dinâmico multi-coluna.
- Destacar acesso rápido a ações relevantes (recebimento, remessa, retorno).
- Reduzir o número de cliques para ações rotineiras.
3.1 Header:
Deve apresentar o título da tela, caminho acessado e botão de nova despesa [funcionalidade existente - manter]
3.2 Cards com indicadores financeiros que servem de filtro [funcionalidade nova]
-
-
- Vencidas – vermelho (#DB102B) – ícone de alerta.
- A Vencer – amarelo (#FFB300) – ícone de relógio.
- A Pagar - azul claro (#044572) - icóne de relógio. - este valor é a soma dos titulos Vencidos e À Vencer
- Pagos– verde (#009966) – ícone de check.
- Total Geral – azul (#044572) – ícone de cifrão.
-
- Os Cards "A Pagar" e o "Total Geral" não devem se comportar como filtro.
-
- Estado inicial (dependente da data de vencimento padrão)
- O sistema deve considerar a data de vencimento vinda do filtro como referência (por padrão, data atual do sistema – today).
- Se existirem registros para o período filtrado:
- Todos os cards correspondentes aos status encontrados são carregados selecionados e coloridos.
- A grid exibe os registros de todos os cards selecionados.
- Se não existirem registros para um status na data filtrada:
- O card é carregado desmarcado e exibido em cinza (estilo “desabilitado”).
- A grid não exibe registros desse status.
- Caso nenhum card tenha registros para a data filtrada (ex.: domingo sem títulos):
- Todos os cards carregam em cinza/desabilitado.
- A grid permanece vazia.
-
3.3 Sessão de filtros [funcionalidade existente - manter conforme protótipo]
- Tipo data = Vencimento
- Campo “Data inicial”: pré-preenchido com data atual do sistema (today).
- Campo “Data final”: pré-preenchido com data atual do sistema (today).
- Validação: data final não pode ser anterior à inicial.
- Conta (dropdown) - Valor padrão: “Todas”.
- Filtro de Informações: Campo de texto = vazio por padrão.
- Dropdown lateral: valor padrão “Cliente”.
- Botão de busca (ícone lupa) dispara aplicação dos filtros.
3.4 Grid de listagem de registros
- Pagar– Ação para registrar pagamento de títulos. Estado inicial: desabilitado e habilita quando o usuário selecionar ao menos um título.
- Importar cnab240– Importação de arquivos de pagamentos; sempre habilitado, e não depende de seleção de registros na grid.
- Relatórios - Acesso rápido a relatórios financeiros do contas a pagar.
- Ações em Lote – Dropdown com múltiplas ações aplicáveis aos registros selecionados. Estado inicial: desabilitado e habilita quando o usuário selecionar ao menos um título.
- Filtros – Botão para expandir/contrair painel de filtros.
- Estado inicial: todos os filtros selecionados, caso deseje, o usuário poderá desmarcar.
- Filtros são combináveis entre si (ex.: “Com anexos” + “Registrados” + "Sem Registros).
- Exibição – Mostra quais colunas da grid o usuário pode exibir ou ocultar.
- Estado inicial: Colunas ocultas por padrão: "Transferências".
- A ordem das opções deve seguir a ordem das colunas.
3.5 Coluna situações:
-
- Registros: títulos Registrados (azul) / Não registrados (cinza)
- Agendado: títulos agendados (azul), Não agendados (cinza)
- Anexos: títulos Com anexos (azul) / Sem anexos (cinza)
- Todos os títulos devem possuir ambos ícones (papelzinho, relógioe clips) com o padrão de de cores azul para situação ativa e cinza para a negativa.
- O sistema passará aceitar 2 anexos para o contas a pagar e deve validar o campo novo "fatura_boleto" na tb"despesa" para marcar o ícone de agendamento como azul.
- Ícones ativos possuem a cor correspondente e exibem tooltip ao passar o mouse (por exemplo: "Agendado", "Com anexos", "Registrado").
3.6 Footer
Comportamento:
-
Quantidade de registros
-
Por padrão, a grid carrega 15 registros por página.
-
Ao selecionar 50 ou 100, o sistema recarrega a grid exibindo mais linhas sem alterar o estado dos filtros ou dos cards.
-
-
Rolagem da tela inteira
-
A grid não possui scroll interno; a rolagem é aplicada à tela inteira.
-
Isso significa que, ao rolar para baixo, o usuário perde de vista o header com os filtros e os cards, dificultando a referência visual.
-
4. Link do Protótipo / Telas
©SOFTEN SISTEMAS 2025
Tela Nova Despesa
| Projeto/Sistema: |
Versão do Template: 1.1 |
| Processo: Tela nova despesa |
Versão do Documento: 1.0 |
| Responsável(eis): Jalile Cornachioni |
Data: 25/08/2025 |
1. Objetivo geral:
2. Impacto previsto:
3. Descrição das alterações
#2 - Tela de nova despesa
A tela de Nova Despesa tem como objetivo permitir que o usuário cadastre rapidamente um novo lançamento no Contas a Pagar, informando os dados essenciais. Reposicionamos os campos obrigatórios e mais utilizados para o topo da tela, facilitando o acesso e acelerando o preenchimento. Embora a funcionalidade em si não tenha mudado, o layout foi modernizado para melhorar a experiência do usuário e reduzir o tempo de operação.
3.1 Header – Informações da Despesa
-
Título: Nova Despesa - Identificação visual da área de cadastro da despesa.
- Preenchimento Automático via IA - Área para importação de arquivo para preenchimento da despesa de forma automatizada, deita por IA.
-
Campos obrigatórios e prioritários: Fornecedor, Número do Documento, Descrição, Conta, Categoria, Forma de Pagamento, Data de Vencimento, e Valor da Despesa.
- Pagamento Agendado: Toggle Switch para marcar o título como agendado ou não.
- Linha digitável: Campo texto reservado para linha digitável do boleto.
-
Valores default: Conta = "Caixa Fìsico" e Forma de Pagamento = "Dinheiro".
-
Indicador de status: Selo “A Vencer” posicionado no topo direito, em amarelo (#FFB300).
3.2. Grid – Repetição de Lançamentos
-
Campos de configuração: Quantidade de lançamentos e período de repetição (ex.: mensal).
-
Tabela de parcelas: Lista com número da parcela e respectiva data de lançamento.
-
Controles de expansão/retração: Permitem ocultar ou exibir detalhes dessa seção.
3.3. Rodapé – Informações Adicionais e Ações
-
Campo de observação: Área livre para comentários e detalhes adicionais.
- Upload de fatura/boleto: Deve ser utilizado para anexar uma cópia da fatura.
-
Upload de comprovante: Botão “Adicionar Comprovante” com instruções de formato e tamanho de arquivo.
-
Botões de ação: “Salvar e Fechar” e “Salvar e Pagar”, posicionados para finalização rápida da operação.
3.4 Comportamento geral da tela:
No estado inicial, a sessão "informações da Despesa" deve estar no estado expanded (aberto) e os demais accordions renderizados em estado collapsed (fechados), exibindo apenas o header de cada seção. O usuário pode expandir ou retrair cada accordion de forma independente, conforme sua necessidade.
4. Link do Protótipo / Telas
©SOFTEN SISTEMAS 2025
Tela de visualização da despesa
| Projeto/Sistema: GERENCIAMENTO DE PROJETOS |
Versão do Template: 1.2 |
| Processo: Tela de visualização da despesa |
Versão do Documento: 1.0 |
| Responsável(eis): Jalile Cornachioni |
Data: 18/08/2025 |
1. Objetivo geral:
2. Impacto previsto:
3. Descrição das alterações
#3. Tela de visualização da despesa
O objetivo da criação desta nova tela de detalhes da Despesa é centralizar a visualização completa das informações de um título pago no Contas a Pagar em um formato não editável por padrão, garantindo mais segurança contra alterações acidentais, padronizando o fluxo de consulta e edição conforme o status do título e as permissões do usuário.
Além disso, ela permite acesso rápido a anexos, histórico e dados complementares, servindo como um ponto único de consulta antes de qualquer ação de edição ou pagamento, reduzindo erros operacionais e aumentando a rastreabilidade das mudanças.
3.1 Detalhes da tela
3.1.1 Header (Cabeçalho)
Objetivo: Apresentar de forma clara a identificação do título, status e ações principais.
- Título da página: Label: "Despesa [Número da Despesa ]" (ex.: Despesa 12345-1/3)
- Ícone indicando registro e anexo: Icon de reloginho para indicar título agendado e clips para títulos com anexo.
- Status do título: Label: ""Pago" (em verde #009966)
- Informações de criação: Label: "Criado em [Data] por [Usuário]"
- Botões de ação: Editar (ícone de lápis), Pagar(ícone de confirmação/pagamento),
- Ações: (menu dropdown com opções adicionais.)
Obs.: O botão "Pagar" muda para "estornar" quando o status do título for "Pago".
O dropdown deve oferecer ações de acordo com a regras de status já existentes, adicionar ação de "excluir" e "baixa como perda" - estes status devem estar ativos/inativos conforme permissão do usuário.
3.2.2. Grid (Corpo da tela)
Objetivo: Exibir todos os dados da despesa de forma organizada em blocos de informação.
Bloco 1: Informações do pagamento
- Valor pago
- Data do pagamento
- Juros
- Multa
Bloco 2: Informações da despesa
- Cliente: Label: "Cliente" – valor: nome do cliente
- Número Documento: Label: "Número Documento" – código ou número de referência
- Descrição:
- Conta: Label: "Conta" – conta bancária vinculada
- Categoria: Label: "Categoria" – categoria da despesa (ex.: Alimentício)
- Forma de Pagamento: Label: "Forma de Pagamento" – ex.: Dinheiro, Pix, Cartão etc.
- Data de Vencimento: Label: "Data de Vencimento" – valor formatado (DD/MM/AAAA)
- Valor da Despesa: Label: "Valor da Despesa" – valor em moeda
OBS.: em alguns casos exibir o campo: "Juros adicional do boleto", de acordo com a configuração da conta selecionada.
Bloco 3: Alterações de valores
- Alterações de Valores: área de texto exibindo campos que alteram o valor, seja por juros, desconto, etc.
- Valor Original; Juros/Multa; Desconto; Valor
Bloco 4 e 5: Observações e anexos
- Informações Adicionais: área de texto exibindo a descrição ou observações complementares
- Anexos: Miniatura/listagem de anexos: com botão "Abrir anexo"
3.2 Comportamento geral e regras da tela
- A tela de visualização de despesa deve ser exibida em modal sempre que o usuário clicar em títulos pagos
- Todos os botões devem estar habilitados para interação, independente do status do título.
- ao clicar em "editar", o sistema deve exibir aviso sobre necessidade de estorno: "Não é possível alterar o vencimento ou valor de um título já recebido. Para prosseguir, realize o estorno do recebimento e tente novamente."
- Esta tela não deve permitir edição apenas para títulos pagos, a não ser que o usuário clique no botão "editar". Ao clicar em "editar" deve-se aplicar regras conforme abaixo:
Regras mandatórias:
- Usuário super_admin
- Permissão de usuário "Financeiro > Contas a Pagar"
- Permissão de usuário "Financeiro > Alterar Contas A Pagar"
3.3 Registro em Log
Para garantir rastreabilidade e auditoria das ações realizadas no sistema, toda operação de alteração em títulos deve gerar um registro em log contendo, no mínimo, os seguintes campos:
-
Data/Hora da ação – momento exato em que a alteração foi realizada.
-
Usuário – identificação única do usuário (ID) e nome completo responsável pela ação.
-
Status anterior e novo do título – somente quando houver alteração de status.
-
Lista de campos alterados – exibição dos campos modificados com seus respectivos valores antes e depois da edição.
4. Link do Protótipo
©SOFTEN SISTEMAS 2025
Tela de edição da despesa
| Projeto/Sistema: GERENCIAMENTO DE PROJETOS |
Versão do Template: 1.2 |
| Processo: Tela de edição da despesa |
Versão do Documento: 1.0 |
| Responsável(eis): Jalile Cornachioni |
Data: 25/08/2025 |
1. Objetivo geral:
2. Impacto previsto:
3. Descrição das alterações
#4 - Tela de edição da despesa
O objetivo da mudança é modernizar o layout da tela de edição de despesa, tornando a experiência do usuário mais clara, intuitiva e alinhada ao padrão visual atualizado do sistema.
3.1 Detalhes da tela
3.1.1 Header (Cabeçalho)
Objetivo: Apresentar de forma clara a identificação do título, status e ações principais.
- Título da página: Editar despesa [Número da despesa]" (ex.: despesa 12345-1/3)
- Ícone indicando registro e anexo: Icon de relógio para indicar agendado e clips para títulos com anexo.
- Status do título: Label: "À vencer", "Vencido"
- Informações de criação: Label: "Criado em [Data] por [Usuário]"
3.1.2 Informações da Despesa
-
Fornecedor(campo bloqueado, apenas visualização).
-
Número do Documento e Descrição.
-
Conta, Categoria, Forma de Pagamento.
-
Data de Vencimento.
-
Valor da Despesa(com validações de edição).
- Pagamento Agendado
- Linha digitável
3.1.3 Alterações de valores
-
Valor Original (bloqueado).
-
Juros/Multa (editável conforme status).
-
Desconto (editável conforme status).
-
Valor da Despesa final (cálculo automático com destaque).
3.1.4 Informações adicionais
-
Observação (texto livre).
-
Comprovantes: upload de arquivos (limite de tamanho, extensões permitidas, múltiplos anexos).
3.1.5 Botões de ação:
- Salvar e Fechar: Salva alterações e fecha a tela voltando para a tela de listagem de despesas
- Salvar e Pagar : Salva alterações e abre tela de pagamento
4. Link do Protótipo
5. Telas
©SOFTEN SISTEMAS 2025
Tela de pagamento
| Projeto/Sistema: |
Versão do Template: 1.1 |
| Processo: Pagamento da despesa |
Versão do Documento: 1.0 |
| Responsável(eis): Jalile Cornachioni |
Data: 25/08/2025 |
1. Objetivo geral:
2. Impacto previsto:
3. Descrição das alterações
3.1 Detalhes da tela
3.1.1 Header (Cabeçalho)
- Título: “Pagamento Conta”
3.1.2. Dados de Recebimento
- Data pagamento (campo obrigatório): campo de data com calendário para seleção.
- Conta: lista suspensa para escolha da conta de destino (ex.: Caixa, Banco).
- Total a pagar: Valor fixo baseado na soma do valor original dos títulos selecionados.
- Total pago: Valor a pagar, considerando juros e acréscimos.
3.1.3. Referente a estes pagamentos (Tabela de Títulos)
- Tabela listando os títulos selecionados para recebimento, com as seguintes colunas:
- Desc./Fornecedor: identificação do cliente ou descrição da despesa.
- Nº Documento: número do título/documento.
- Vencimento: data de vencimento do título.
- Valor Original: valor principal do título.
- Multa: campo editável para inserção de multa.
- Juros: campo editável para juros aplicados.
- Desconto: campo editável para descontos concedidos.
- Acréscimo: campo editável para acréscimos manuais.
- Valor a Pagmento: cálculo automático do valor final considerando os ajustes.
3.1.4. Ações do Rodapé
- Cancelar: retorna para a tela anterior sem efetivar o recebimento.
- Pagar: confirma a operação de baixa, aplicando os valores informados.
3.2 Comportamento geral da tela:
A tela deve abrir em modo edição com os campos:
- Data pagamento deve ser atribuído data atual e respeitar a configuração FInanceiro > Proibir lançamentos com data retroativa", ou seja, habilitar somente se este campo estiver desmarcado na configuração adicional do sistema.
- Todos os demais campos dever estar habilitados para edição, respeitando as configurações de usuário.
- Ao imputar valor nos campos de acréscimo, juros/multa e/ou desconto o sistema deve recalcular o valor no campo "Valor pagamento" (manter o funcionamento atual)
4. Link do Protótipo
5. Telas
Pagamento Unificado
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
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
--- Fluxograma de abertura do modal de pagamento unificado ---
---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
-
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
-
-
-
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:
- 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.
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
-
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:
©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.
Regras para mensagens e validações
- 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. -
descontoeacrescimo: 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_maximoquando 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
idedescricao, 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:
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
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:
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
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:
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
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:
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
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:
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