Gerencie Vendas - G.V.
1. Filtros Avançados
PROC001 Filtros Avançados
| Projeto/Sistema: GERENCIAMENTO DE PROJETOS |
Versão do Template: 1.2 |
| Processo: Descrição Processo |
Versão do Documento: 1.0 |
| Responsável(eis): Luís Leite |
Data: 05/01/2026 |
1. Introdução
Este processo visa exemplificar a criação de filtros avançados para o GerencieVendas.
|
Processo |
Envolvidos |
Dados de Entrada |
Dados de Saída |
|
PROC001 Filtros Avançados |
- |
- |
- |
Especificação Funcional
PROC001 Filtros Avançados:
Protótipo de Tela:
Imagem I - Tela de vendas com filtros avançados
Imagem II - Filtros Avançados
Descrição dos Campos:
|
Campo |
Tipo |
Tamanho |
Obrig. ? |
Máscara |
Observações |
|
Filtros Avançados |
Botão |
- |
- |
- |
- |
|
Data Início |
Data |
- |
Sim |
__/__/____ |
- |
|
Data Fim |
Data |
- |
Sim |
__/__/____ |
- |
|
Status de Exportação |
Botão |
- |
- |
- |
Opções: Exportados; Não Exportados |
|
Limpar Filtros |
Botão |
- |
- |
- |
- |
|
Filtrar |
Botão |
- |
- |
- |
- |
Regras de Interface:
1. Filtros Avançados: Deve abrir a Dialog para filtros avançados.
2. Dialog Filtros:
2.1 Data Início: Sempre deve inicializar com a data atual. Não deve permitir valor zerado/sem preenchimento.
2.2 Data Fim: Sempre deve inicializar com a data atual. Não deve permitir valor zerado/sem preenchimento.
2.3 Status de Exportação: Deve conter 3 opções ou botões que devem funcionar como 'radiobutton', ao selecionar uma opção, as outras devem ser desmarcadas. Por padrão deve ser "Todos".
2.4 Limpar Filtros: Deve restaurar o estado dos filtros para o estado padrão.
2.5 Filtrar: Se possível realizar o filtro, a tela/Dialog deve ser encerrada e o filtro aplicado na listagem. Caso não seja possível deve ser retornado em tela o aviso:
Atenção
Confira o preenchimento das Datas.
3. Ao acessar a tela de Vendas ou Orçamentos, o sistema deve:
- Exibir os registros da data atual.
- Iniciar a tela com campo de busca vazio e nenhum filtro aplicado.
- Manter comportamento de busca durante digitação e atualização dinâmica pela busca.
- Exibir até 10 registros mais recentes.
- Paginar caso existam mais de 10 resultados.
- Ordenar os registros por data de criação decrescente.
Regras de Negócio:
1. O sistema deve permitir múltiplas aplicações simultâneas de filtros. Combinações possíveis:
- Busca
- Período
- Status
- Busca + período
- Busca + status
- Período + status
- Busca + período + status
2. Não haverá persistência dos filtros, funcionarão apenas em tela durante o uso.
©SOFTEN SISTEMAS 2026
2. Envio de Lote
Nova Página
| Projeto/Sistema: GERENCIAMENTO DE PROJETOS |
Versão do Template: 1.2 |
| Processo: Descrição Processo |
Versão do Documento: 1.0 |
| Responsável(eis): - |
Data: 05/01/2026 |
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 Envio e Recepção de Lotes:
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:
Regras de Negócio:
1. Ao ser exportado um produto com lote e validade no GerencieAqui, deve ser enviado ao serviço intermediário as informações respectivas.
2. Somente devem ser enviados lotes e validades que estejam ativos no cadastro do produto.
Questões Técnicas:
1. Estrutura do JSON de envio das informações de lote e validade para o serviço intermediário:
{
"originId": "998877",
"description": "PRODUTO COM LOTE",
"unit": "UN",
"price": 42.00,
"stock": null,
"categoryOriginId": 1001,
"sku": "",
"barCode": "",
"variations": [
{
"productOriginId": 998877,
"originId": 301,
"description": "QUEIJO PARMESÃO TRADICIONAL",
"stock": 150,
"sku": "QJ-PARM-01",
"barCode": "7891000100011",
"price": 42.00
},
{
"productOriginId": 998877,
"originId": 302,
"description": "QUEIJO MUSSARELA PEÇA",
"stock": 80,
"sku": "QJ-MUSS-01",
"barCode": "7891000100028",
"price": 35.00
}
],
"complements": [],
"batch": [
{
"productOriginId": 998877,
"originId": 501,
"batch": "ABC1010",
"mfgDate": "2025-12-01",
"expDate": "2026-12-01",
"variationId": 301
},
{
"productOriginId": 998877,
"originId": 502,
"batch": "1234",
"mfgDate": "2024-11-01",
"expDate": "2027-02-28",
"variationId": 301
},
{
"productOriginId": 998877,
"originId": 503,
"batch": "XYZ999",
"mfgDate": "2024-05-15",
"expDate": "2025-05-15",
"variationId": 302
}
],
"priceTables": null,
"image": "data:image/png;base64,..."
}1. Tabela para cadastro dos lotes na base de dados do App GerencieVendas:
CREATE TABLE batches (
originId INTEGER PRIMARY KEY,
productOriginId INTEGER,
description TEXT,
batch TEXT,
mfgDate TEXT,
expDate TEXT,
variationId INTEGER
);PROC002 Controle de Lote no GerencieVendas:
Protótipo de Tela:
Imagem I - Listagem de Produtos para inserção em Venda.
Imagem II - Seleção de Variação
Imagem III - Seleção de Lote.
Descrição dos Campos:
|
Campo |
Tipo |
Tamanho |
Obrig. ? |
Máscara |
Observações |
|
Campo |
Texto |
100 |
Sim |
- |
- |
Regras de Interface:
1. Se o produto possuir mais de um Lote, deve ser aberta a tela de seleção do Lote a ser utilizado. Possuindo apenas um lote, a seleção não deve ocorrer.
2. Produtos que possuam Variação devem solicitar a Variação primeiro, então os lotes vinculados a variação. Caso apenas um lote na variação, não deve abrir seleção de lotes. (Imagem II)
3. Devem ser listados os lotes mais antigos cadastrados para os mais novos cadastrados.
4. O produto selecionado deve ser listado na Venda/Orçamento da seguinte forma; {Nome_Produto} - {Nome_Variação} - {lote} - {Dt. vencimento}
Regras de Negócio:
1. A prioridade dos fluxos de seleção de dados é: Variação → Lote.
2. Será "settado" automaticamente o lote caso o produto tenha somente UM lote vinculado.
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 2026
3. Envio cód. autorização
PROC001 Controle de Pagamentos Eletrônicos - NFCe
| Projeto/Sistema: GerencieVendas |
Versão do Template: 1.2 |
| Processo: PROC001 Controle de Pagamentos Eletrônicos |
Versão do Documento: 1.0 |
| Responsável(eis): Luís Leite |
Data: 23/03/2026 |
1. Introdução
Esta documentação tem por objetivo descrever as mudanças para satisfazer a necessidade de vincular as informações de pagamento eletrônico vindas do GerencieVendas, para uso na autorização de documento fiscal.
2. Processo(s)
|
Processo |
Envolvidos |
Dados de Entrada |
Dados de Saída |
|
PROC001 Controle de Pagamentos Eletrônicos |
GA-GV |
- |
- |
Especificação Funcional
PROC001 Controle de Pagamentos Eletrônicos:
Regras de Negócio:
1. Deverá ser utilizado uma tabela intermediaria para todos pagamentos eletrônicos. Essa tabela vai servir pra armazenar os dados de código de autorização e demais informações de pagamento eletrônico. isso visa dois fluxos, (1) as vendas feitas no APP que não tem vínculo com NFC-e e as (2) vendas que são solicitadas NFC-e.
1 Emissão sem NFCe:
-
-
-
- As informações vão ficar salvas na tabela intermediaria pagamentosdigitais (antiga nfcecartao), tendo vínculo com a venda.
- A emissão de NFCe posterior no GerencieAqui deve consultar essa tabela para ter acesso aos dados de autorização. Víncular as informações do registro dessa tabela na nfcefaturas.
-
-
1.2 Emissão com NFCe: Com a emissão da NFCe, deve ser enviado a venda + informações dos pagamentos para o GerencieAqui, para possibilitar que o serviço faça a autorização com os dados de autorização já vinculados ao documento fiscal. As informações ainda deverão preencher a tabela pagamentosdifigitais (antiga nfcecartao).
1.3 Emissão somente NFCe: Visando suprir o fluxo de uma venda feita somente pela NFCe no retaguarda, deve ser criado um vínculo com a pagamentosdigitais para víncular o pagamento eletrônico com a emissão somente da NFCe.
2. Pagamentos originados no app como venda podem posteriormente ser vinculados a uma NFC-e. Nesse caso, o sistema deve atualizar o registro existente, preenchendo o nfceId. Não deve ser criado um novo pagamento para a mesma transação TEF.
3. A tabela nfcefaturas deve continuar referenciando pagamentosdigitais. Para cada fatura com pagamento eletrônico, deve existir um vínculo válido.
Questões Técnicas:
1. No GerencieAqui Deve ser alterado o nome da tabela 'nfcecartao' para 'pagamentosdigitais'.
1.1 Devem ser adicionados campos referentes a informações de pagamento eletrônico.
1.2 Deve ser adicionado "Enum" pra controle de origem do pagamento eletrônico.
ALTER TABLE nfcecartao RENAME TO pagamentosdigitais;
ALTER TABLE pagamentosdigitais
ADD COLUMN meioPagamento VARCHAR(50) DEFAULT NULL,
ADD COLUMN nsu VARCHAR(50) NOT NULL,
ADD COLUMN nsuSitef VARCHAR(50),
ADD COLUMN nsuHost VARCHAR(50),
ADD COLUMN vendaId BIGINT(20),
ADD COLUMN nfceId BIGINT(20),
ADD COLUMN origemPgto INT(2), -- "01 - Cielo; 02 - Rede; 03 - MercadoPago; 04 - ELGIN"
ADD COLUMN statusTef BIT(1) -- 0 ativo, 1 cancelado
;3. Deve ser alterada a rotina de inserção das informações na tabela 'pagamentosdigitais' pra que seja inserido apenas 1 Registro por transação eletrônica. Esse registro é vinculado com a 'nfcefaturas' por chave estrangeira, ou seja, caso tenham mais de um registro na 'nfcefaturas' eles terão referência do único registro de transação no 'pagamentosdigitais'.
4. JSON dos envios das informações de venda e pagamento:
{
"id": "16405573-81cc-4ece-a065-0d0087b84f1c",
"appId": 2,
"customerOriginId": 3864,
"customerUuid": "2626ad47-a019-4dad-b652-e857730ad0d6",
"customerName": "CONSUMIDOR",
"customerDocument": "27565866000104",
"sellerOriginId": 349,
"sellerName": "VENDEDOR",
"paymentMethodOriginId": 1,
"paymentMethodName": "Crédito",
"date": "2026-02-25",
"creationDate": "2026-02-25T15:38:10",
"discountPercent": 0,
"discountValue": 0,
"increases": 0,
"shipping": 0,
"totalProducts": 51.4,
"total": 51.4,
"notes": "",
"quotationId": null,
"quotationAppId": null,
"items": [
{
"originId": "7912",
"description": "SUCO NATURAL JARRA 1L",
"quantity": 1,
"price": 12,
"totalPrice": 12,
"variationOriginId": 275,
"variationDescription": "Laranja",
"complementsPrice": 0
},
{
"originId": "121981",
"description": "ÁGUA GASEIFICADA H2OH LIMONETO 500ML",
"quantity": 1,
"price": 6.5,
"totalPrice": 6.5,
"variationOriginId": null,
"variationDescription": null,
"complements": [
{
"step": "COPO",
"type": "SINGLE_CHOICE",
"price": 0,
"originId": 752,
"quantity": null,
"saleItemId": 5,
"description": "Copo com limão e gelo",
"id": 12
}
],
"complementsPrice": 0
},
{
"originId": "121979",
"description": "TEMAKI HOT ROLL",
"quantity": 1,
"price": 32.9,
"totalPrice": 32.9,
"variationOriginId": null,
"variationDescription": null,
"complementsPrice": 0
}
],
"payments": [
{
"originId": 0,
"paymentMethodName": "Dinheiro",
"date": "2026-02-25",
"value": 10,
"paid": false,
"cieloSaleId": null,
"redeNsu": null,
"mercadoPagoId": null
},
{
"originId": 60,
"paymentMethodName": "Débito",
"date": "2026-02-25",
"value": 20,
"paid": true,
"cieloSaleId": null,
"redeNsu": "160645",
"ElginNsu": "16555"
"mercadoPagoId": null,
"elginTefID": "1"
},
{
"originId": 1,
"paymentMethodName": "Crédito",
"date": "2026-02-25",
"value": 21.4,
"paid": true,
"cieloSaleId": null,
"redeNsu": "160648",
"ElginNsu": "16555"
"mercadoPagoId": null,
"elginId": "1"
}
]
}5. JSON de envio das informações de pagamento, adicionado informação da bandeira em 'cardBrand':
[
{
"createdAt": "2026-02-25T15:37:21",
"nsu": "160645",
"sitefNsu": "160645", --opcional
"hostNsu": "160645", --opcional
"installments": 0,
"type": "Débito",
"operationType": "Débito à vista",
"amount": 20,
"paymentStatus": "AUTHORIZED",
"saleId": "16405573-81cc-4ece-a065-0d0087b84f1c",
"cardBrand": "master"
},
{
"createdAt": "2026-02-25T15:38:06",
"nsu": "160648",
"sitefNsu": "160645", --opcional
"hostNsu": "160645", --opcional
"installments": 2,
"type": "Crédito",
"operationType": "Crédito parcelado sem juros",
"amount": 21.4,
"paymentStatus": "AUTHORIZED",
"saleId": "16405573-81cc-4ece-a065-0d0087b84f1c"
"cardBrand": "visa"
}
]
©SOFTEN SISTEMAS 2026