Pagamento Unificado

Analista Responsável: Gustavo Henrique Braga Fernandes - Esse documento visa exemplificar o uso da tela de pagamento unificado. Descrevendo os processos para implementação da nova tela em cada módulo do sistema.

• Detalhamento geral - Grupos (Layout)
• Pagamento Unificado - Frente de caixa
• Pagamento Unificado - Venda Touch (balcão)
• Pagamento Unificado - NFCe
• Pagamento Unificado - DTO genérico

Detalhamento geral - Grupos (Layout)

	Projeto/Sistema: PAGAMENTO UNIFICADO	Versão do Template: 1.2
	Processo: Detalhamento geral - Grupos (Layout)	Versão do Documento: 1.0
	Responsável(eis):  Gustavo Fernandes	Data:  14/11/2025

1. Introdução

Este processo visa exemplificar o conceito do pagamento unificado e detalhar os grupos em tela de forma generalizada, sem especificação de módulos.

2. Processo Geral

I - Fluxograma padrão pag unificado, simplificado, geral.

 

Processo	Envolvidos	Dados de Entrada	Dados de Saída
PROC001 - Detalhes gerais da tela - Pagamento Unificado	-	-	-
PROC002 - Resumo da Venda	-	Valores de origem do módulo e do grupo Registrar Recebimento	Resumo destacado em tela
PROC003 - Pagamentos Adicionados	-	Valores preenchidos do grupo Registrar Recebimento e Resumo da Venda	Tabela para organizando as parecelas/infos
PROC004 - Resumo de Pagamentos	-	Valores preenchidos/editados do grupo Registrar Recebimentos, Pagamentos Adicionados e Resumo da Venda	Tela para organizar o totalizador dos pagamentos
PROC005 - Registrar Recebimento	-	Valore de origem do módulo	Campos preenchimento de valores/data, etc.

Processos Relacionados

---

Pagamento Unificado - Frente de caixa

Especificação Funcional

---

PROC001 Detalhes gerais da tela - Pagamento Unificado:

Protótipo de Tela:

Imagem I - Tela geral - Pagamento Unificado

Descrição dos Campos:

Campo	Tipo	Tamanho	Obrig. ?	Máscara	Observações
Data da operação:	Data/hora	-	-	-	Texto dinâmico de acordo com módulo
"X"	Button	-	-	-	-

Regras de Interface:

1. Data de operação: Será dinâmico, o texto mudará de acordo com o módulo de origem. Será específicado no processo de cada módulo.
Exemplo é na NFe de entrada, aonde o campo será chamado "Data da compra:"

2. A tela será uma dialog, aberta apenas quando o usuário "aciona-la" pelo botão "Registrar Pagamentos/Recebimentos". (pode variar dependendo da tela)

3. Por padrão o tipo de pagamento "Dinheiro" deverá vir marcado na dialog.

4. Os avisos, referente as validações de tela, devem ser exibido neste padrão, exemplo:

Regras de Negócio:

1. Os dados deverão ser consultados da tabela referente ao módulo de origem (NFe, NFCe, Pedido de venda, etc) e salvos na mesma.

2. Lógica para puxar a data:
Operação = Venda/NFe, etc.

• • Se a operação estiver sendo feita agora, então puxe a data/hora atual (agora/now).
  • Se a operação for antiga e só agora o usuário decidiu registrar o pagamento, então puxar a data de emissão/criação da operação.

3. O botão "X": deverá apenas fechar a dialog completamente.

3.1 Caso tenha algum pagamento adicionado, fechar dialog, mas, estes dados serão perdidos.

3.2 Caso tenha algum pagamento adicionado, que tenha algum bloqueio, como PIX aprovado (Qrcode - Shipay) ou TEF aprovado, então será necessário um aviso, pode ser algo como:

PROC002 Resumo da Compra/Venda:

Protótipo de Tela:

Imagem II - Grupo - Resumo da Venda

Descrição dos Campos:

Campo	Tipo	Tamanho	Obrig. ?	Máscara	Observações
Total da Compra:	Moeda	-	-	R$	-
Descontos %:	Moeda	-	Não	-	-
Descontos R$:	Moeda	-	Não	R$	-
Acréscimos %:	Moeda	-	Não	R$	-
Acréscimos R$:	Moeda	-	Não	R$	-
Total Líquido da venda:	Moeda	-	-	-	-

Regras de Interface:

1. Descontos e Acréscimos: Por padrão os campos ficarão sempre liberados para edição. Quando o usuário clicar, liberar para preenchimento ou edição do valor.

2. Total da Compra e Total líquido da venda: Campos fixos, não serão editáveis, apenas visualização.

Regras de Negócio:

1. Total da Compra: Valor calculado com base no total daquela operação, basicamente é o valor bruto da operação, sem considerar descontos, acréscimos e qualquer outro valor (frete, impostos) que altere o valor total.

2. Descontos %: Valor referente ao percentual de desconto aplicado sobre o Descontos R$ (Valor base)

2.1 O sistema deverá recalcular automaticamente o percentual sempre que o campo Descontos R$ for alterado.

Cálculo: Descontos % = (Descontos R$ / Valor Base) * 100

2.2 Valor desconto não poderá ser maior do que o valor da operação.

3. Descontos R$: Valor referente ao desconto absoluto.

3.1 Este campo poderá vir de qualquer campo preenchido do módulo de origem que venha a descontar no valor bruto, como descontos, impostos, etc (será especificado em cada módulo). 

3.2 Caso o usuário altere o campo Descontos %, o sistema recalculará automaticamente o valor em reais.

Cálculo: Descontos R$ = (Descontos % / 100) * Valor Base

3.3 Percentual desconto não poderá ser maior do que 100%.
(permite 100% devido bonificação, brinde, etc)

4. Acréscimos %: Valor referente ao percentual de acréscimo aplicado sobre o Acréscimos R$ (Valor base)

4.1 O sistema deverá recalcular automaticamente o percentual sempre que o campo Acréscimos R$ for alterado.

Cálculo: Acréscimos % = (Acréscimos R$ / Valor Base) * 100

5. Acréscimos R$: Valor referente ao acréscimo absoluto.

5.1 Este campo poderá vir de qualquer campo preenchido do módulo de origem que venha a acrescentar no valor bruto, como acréscimos, juros, frete, impostos, etc.

6. Total Líquido da venda: Valor calculado com base no valor bruto calculado (Total da Compra), considerando também os acréscimos(+) e descontos(-), valor líquido da venda, valor real que será cobrado.

PROC003 Pagamentos Adicionados:

Protótipo de Tela:

Imagem III - Grupo - Pagamentos Adicionados

Descrição dos Campos:

Campo	Tipo	Tamanho	Obrig. ?	Máscara	Observações
N° Parcela:	Numero	-	Não	-	-
Forma Pgto	Texto curto	-	Não	-	-
Valor	Moeda	-	Não	R$	-
Data Vencimento	Data	-	Não	DD/MM/AAAA	-
Ações	Ação (Editar/Exclui)	-	Não	-	-

Regras de Interface:

1. Por padrão este grupo deverá ficar assim, quando não há nenhum pagamento adicionado:

2. N° Parcela: Numeração sequêncial, conforme parcelas, iniciando-se em 01, seguindo este padrão, 02, 03, etc.

2.1 Campo não editável, matendo sempre da menor parcela para maior.

2.2 Haverá uma limitação de apenas 03 parcelas, em tela. A partir disto (04 parcelas ou mais), deverá ser exibido uma barra de rolagem ao lado direito, verticalmente, exemplo:

3. Forma Pgto: Ao clicar na ação "Editar" , campo ficará desbloqueado, liberando uma comboBox:

4. Valor: Ao clicar na ação "Editar" , campo ficará desbloqueado para edição:

5. Data Vencimento: Ao clicar na ação "Editar" , campo ficará desbloqueado para edição com máscara "DD/MM/AAAA":

5.1 Data de vencimento padrão "DD/MM/AAAA", haverá um calendário para seleção de data também, caso o usuário não queira digitar.

6. Ações - Editar: Por padrão o ícone de editar deve ser .

6.1 Ao clicar nele para editar a linha, deverá desbloqueá-los, indicando possibilidade de edição nos campos, assim:

6.2 Enquanto o campo estiver sendo editado, o botão de editar, deverá ficar com este ícone de imagem .

7. Ações - Excluir: Por padrão o ícone de exclusão deve ser .

7.1 Ao clicar na ação de excluir, deverá abrir uma dialog perguntando se realmente deseja excluir, com as opções:

 

8. Em caso de pagamento eletrônico vinculado com código de autorização, o elemento na lista deve possuir o botão

pra abrir a Dialog para edição do código de autorização. Comportamento similar ao da tela de Nota Fiscal Eletrônica ao vincular pagamento com código de autorização:

Regras de Negócio:

1. N° Parcela: Ao deletar uma linha pela ação "Excluir", deve-se manter o número da parcela.
Exemplo, tenho a linha 01, 02 e 03, se eu excluir a 02, a parcela 01 continua sendo 01 e 03 continua sendo 03, assim como na tela de Forma de Pagamento da NFe (modelo 55) tem uma lógica já existente (Sem recalcular números).

2 Forma Pgto: A linha deve exibir a forma de pagamento preenchida no campo "Forma de Pagamento" do grupo "Registrar Recebimento".

2.1 Forma Pgto: Ao editar uma linha pela ação "Editar" , deve-se exibir todas as formas de pagamento cadastradas no sistema (Cadastros - Forma de Pagamento) que ainda estão ativas.

2.2 Se o usuário errou no preenchimento do "Cód. Autorização" ou "Bandeira" Referente a TEF não integrado, manual selecionada no grupo "Registrar Recebimento", ele precisará excluir a linha e inserir novamente! Pois, ao editar a linha só exibirá estes campos:
"Forma Pgto", "Valor", "Data Vencimento". 

3. Valor: A linha deve exibir o valor preenchido no campo "Valor Recebido" do grupo "Registrar Recebimento"

3.1 Valor: Ao editar uma linha pela ação "Editar" , deve-se liberar o campo e exibir o valor inserido para edição.

3.1.1 O campo deverá aceitar apenas valores maiores que 0 (zero), ou seja, sem valores negativos/zerados ou nulos.

4. Data Vencimento: A linha deve exibir o valor preenchido no campo "Vencimento" do grupo "Registrar Recebimento"

4.1 Data Vencimento: Ao editar uma linha pela ação "Editar" , deve-se liberar o campo e exibir a data para edição.

4.1.1 O campo deverá aceitar apenas números, sem caracteres especiais, letras e outros.

5. Ações - Editar: Não poderá liberar os campos para edição, no caso de pagamentos adicionados, que tenham vinculo com transações TEF (Integrado) ou PIX DINÂMICO (TEF/SHIPAY) e já esta autorizado! Ficando com ação bloqueada, assim:

6. Ações - Excluir: Não poderá excluir pagamentos adicionados que tenham vinculo com transações TEF (Integrado) e já esta autorizado!

6.1 No caso do cliente precisar cancelar essa transação TEF, ele fará por fora, na tela de "Transações TEF" mesmo, cancelando aquele pagamento pelo TEFHUB (exe da elgin), somente após isto, poderá liberar a linha para ação de exclusão.

6.2 Ação - Excluir - Dialog Confirmação:

• • • • • Ao excluir um pagamento e exibir a dialog de confirmação, ao clicar em "Cancelar" deverá fechar a dialog e não excluir! (Se ficar no "X" também)
        • Ao excluir um pagamento e exibir a dialog de confirmação, clicando en "Sim" deverá excluir a linha!

PROC004 Resumo de Pagamentos:

Protótipo de Tela:

Imagem IV - Grupo - Resumo de Pagamentos

Descrição dos Campos:

Campo	Tipo	Tamanho	Obrig. ?	Máscara	Observações
Total a Pagar:	Moeda	-	-	R$	-
Saldo a Pagar:	Moeda	-	-	R$	-
Pago:	Moeda	-	-	R$	-
Troco:	Moeda	-	-	R$	-

Regras de Interface:

1. Total a Pagar, Saldo a Pagar, Pago e Troco: Campos fixos, não serão editáveis, apenas visualização.

2. Troco: Só deverá aparecer quando tiver, caso não tenha, poderá ficar oculto, assim:

Regras de Negócio:

1. Total a Pagar: Valor calculado será: "Total Líquido da venda" (considerando descontos e acréscimos, etc).

2. Saldo a Pagar: Valor calculado será: "Total a Pagar" - "Pago".

2.1 Regra de exibição:

• • • • • Se o resultado for ≥ 0, exibe normalmente.

        • Se o resultado for < 0, o sistema exibe 0,00 neste campo.

3. Pago: Soma de todas as colunas "Valor" do grupo "Pagamentos Adicionados".

4. Troco: Valor calculado será: "Pago" - "Total a Pagar"

4.1 Regra de exibição:

• • • • • Se o resultado for ≤ 0, exibe 0,00

        • Se o resultado for > 0, exibe o valor como troco.

PROC005 Registrar Recebimento:

Esta parte separei para facilitar o entendimento, pois cada tipo de pagamento tem suas interfaces.

Protótipo de tela - exemplo:

Imagem V - Grupo - Registrar Recebimento - Geral

Protótipo de Tela - Tipo de pagamento:

Imagem VI - Grupo - Registrar Recebimento - Tipo de pagamento

Protótipo de Tela - Adicionar pagamento:

Imagem VII - Grupo - Registrar Recebimento - Tipo de pagamento

Descrição dos Campos:

Campo	Tipo	Tamanho	Obrig. ?	Máscara	Observações
Dinheiro:	Button	-	-	-	Padrão
Crédito:	Button	-	-	-	Pode abrir campos adicionais ou altera-los
Débito:	Button	-	-	-	Pode abrir campos adicionais ou altera-los
Boleto:	Button	-	-	-	Pode abrir campos adicionais ou altera-los
PIX:	Button	-	-	-	Pode abrir campos adicionais ou altera-los
Outros	Button	-	-	-	Pode abrir campos adicionais ou altera-los
Adicionar Pagamento	Button	-	-	-	-
Cancelar	Button	-	-	-
Finalizar Pagamento	Button	-	-	-	Poderá ficar bloqueando, dependendo da regra de negócio

Regras de Interface:

1. Ao selecionar o tipo de pagamento respectivo, deverá mudar o botão para que fique com as cores, neste padrão, exemplo com "Dinheiro", mas serve para todos:

Antes do clique:

Mouse em cima (hover):

Após o clique:

2. Quando o botão "Finalizar Pagamento" estiver bloqueado, a coloração deverá mudar e não poderá ser clicável, assim:

Botão bloqueado:

Botão liberado:

3. Quando o botão "Adicionar Pagamento" estiver bloqueado, a coloração deverá mudar também e não poderá ser clicável, assim:

Botão bloqueado:

 

Botão liberado:

4. Quando selecionar um tipo de pagamento, exemplo, clicando em "Crédito" além de marcar ele como selecionado, terá que desmarcar o outro tipo de pagamento, ou seja, estou com "Dinheiro" marcado, clico em "Crédito", ele marca o "Crédito" e já Desmarca o "Dinheiro" automaticamente, não permitindo dois tipos marcados ao mesmo tempo.

Regras de Negócio:

1. Ao clicar no tipo de pagamento respectivo, deverá carregar os campos referente ao mesmo, que será específicado no subprocesso de cada um a seguir.

2. Botão "Finalizar Pagamento": ficará bloqueado até que seja zerado o valor a pagar, só libera depois.

3. Botão "Cancelar": deverá excluir todos os pagamentos adicionados no grupo "Pagamentos Adicionados", voltando também o Valor para o valor cheio, podendo assim começar novamene a adição.

3.1 Validar ao "Cancelar", para voltar apenas os pagamentos que não tem vínculo com transações TEF (integrado), pois, se houver, o pagamento estará bloqueado para exclusão, ou seja, apenas pagamentos sem bloqueio de exclusão.

4. Botão "Adicionar Pagamento" deverá adicionar o "Valor" preenchido, no grupo "Pagamentos Adicionados"

4.1 O botão deverá ficar bloqueado, após adicionar o todo o valor (valor completo) no grupo "Pagamentos Adicionados" pra que não seja possível o usuário adicionar mais do que tem para receber.

5.1 Registro de Recebimento - Dinheiro

Protótipo de Tela:

Imagem VIII - Grupo - Registrar Recebimento - Dinheiro

Descrição dos Campos:

Campo	Tipo	Tamanho	Obrig. ?	Máscara	Observações
Valor Recebido	Moeda	-	-	R$	-
Receber Dinheiro	Button	-	-	R$	-
Recebimento	Moeda	-	-	R$	-
Troco	Texto	-	-	-	Campo poderá variar, a depender do troco calculado

Regras de Interface:

1. Valor Recebido: deverá ser um campo editável.

2. Receber Dinheiro: Ao selecionar o recebimento respectivo, deverá mudar o botão para que fique com as cores, neste padrão, exemplo com R$100,00, mas serve para todos:

Antes do clique:

Quando clicar, não ficará marcado, apenas um indicativo 'hover' de que clicou e depois volta ao estado inicial:
(Parecido com o que temos no frente de caixa hoje)

3. Recebido: deverá listar os valores recebidos e mostrar o valor calculado no canto superior direito:

3.1 Ao clicar no "X", o valor deverá "sumir"(excluir) da listagem.

4. Troco: deverá ser um campo apenas para visualização, não permitindo edição, apenas para exibir o troco calculado no canto superior direito e sugestões!

4.1 Exemplo prático de sugestão de troco:

Regras de Negócio:

1. Valor Recebido: deverá aceitar apenas valores maiores que 0 (zero).

1.2 Iniciar com valor R$ 0,00, para que o usuário possa digitar o valor recebido.

2. Receber Dinheiro: Ao clicar no botão (cédula/moeda), ele deverá adiciona-lo à lista "Recebido" e o total exibido deverá ser atualizado imediatamente.

3. Recebido: Deverá calcular todas as cédulas/moedas adicionadas, fazer uma soma para calcular o total Recebido do canto superior direito

3.1 Conforme o usuário exclua as cédulas/moedas, recalcular o valor total Recebido do canto superior direito.

4. Troco: Deverá calcular o total de "Troco":

• • • Se valor "Recebido" for igual ou menor que o total a pagar, o troco deverá ficar R$0,00 (zerado)
    • Se valor "Recebido" for maior que o total a pagar, troco deverá ser calculado:
      Troco = Recebido – Total a Pagar.

4.1 Sugestão de troco: O sistema deverá gerar sugestões automáticas utilizando o conceito de “Troco Ótimo”, ou seja:

• • • • • Priorizar a devolução utilizando o menor número possível de cédulas/moedas.

        • Considerar as denominações disponíveis no sistema.

        • Exibir até três opções de combinação, quando existirem.

        • Recalcular a sugestão sempre que o valor recebido for alterado.

4.1.1 Cálculo para exibir as sugestões de troco (Sugestão de cálculo):

• • • • • • D = denominação (o valor da nota ou moeda).
          • Q = quantidade de notas/moedas daquela denominação (D) necessárias para compor o troco.
          • inteiro() = divisão inteira (quantas vezes D cabe no troco)
          • Troco % D = quanto sobra depois de usar as cédulas daquela denominação

Sugestão de troco 1 (Troco ótimo):

Para cada denominação D na lista de denominações (ordem decrescente):

Q = inteiro( Troco / D )  
Se Q > 0, adicionar "Q × D" à combinação  
Troco = Troco % D

Combinação com o menor número possível de cédulas/moedas.

Sugestão de troco 2:

Após identificar a primeira denominação utilizada na Sugestão 1, gerar uma segunda combinação seguindo:

Ignorar a maior denominação usada na Sugestão 1

Aplicar novamente o cálculo:

Q = inteiro( Troco / próxima denominação )  
Troco = Troco % denominação  
Repetir até Troco = 0

Sugestão de troco 3:

Selecionar uma denominação menor (ex.: 20)

Para as denominações <= 20:

Q = inteiro( Troco / D )  
Troco = Troco % D

5.2 Registro de Recebimento - Crédito

Protótipo de Tela:

Imagem IX - Grupo - Registrar Recebimento - Crédito

Descrição dos Campos:

Campo	Tipo	Tamanho	Obrig. ?	Máscara	Observações
Forma de Pagamento	ComboBox	-	-	-	-
Valor	Moeda	-	-	R$	Mesma coisa do campo Valor Recebido (dinheiro)
Data de Vencimento	Data	-	-	-	-
Parcelas	ComboBox	-	-	-	-
Periodicidade	ComboBox	-	-	-	-
Bandeira	ComboBox	-	-	-	-
Cód. Autorização	ComboBox	-	-	-	-
CNPJ Recebedor	Texto	-	-	-	-
CNPJ PSP	Texto	-	-	-	-

Regras de Interface:

1. Forma de Pagamento, Periodicidade e Bandeira: deverão ser liberados para seleção.

2. Data de Vencimento, Parcelas e Cód Autorização: campos liberados para edição.

2.1 Data Vencimento: Opção de calendário também deverá ser liberado para seleção, ao clicar abrir calendário.

2.2 Parcelas: Poderá utilizar o botão de + e - para editar o valor também.

 

3. CNPJ Recebedor: Deve puxar o CNPJ registrado no cadastro da Empresa no Gerencie Aqui. Quando sem preenchimento, deve exibir o Placeholder "Insira o CNPJ"

4. CNPJ PSP: Caso configurado TEF, em Configurações>Documentos Fiscais>Card "Cupom Fiscal Eletrônico", puxar o CNPJ preenchido em "CNPJ credenciadora*". Quando sem preenchimento, d Deve conter o Placeholder "Insira o CNPJ"

Regras de Negócio:

1. Forma de Pagamento: deverá lista todas as formas de pagamento cadastradas (personalizadas) e ativas.

1.1 Caso o usuário não tenha nenhuma forma de pagamento cadastrada, o sistema deverá fazer o cadastro automaticamente, com base no tipo de pagamento que ele selecionou, ao clicar em "Adicionar Recebimento/pagamento" cadastrar assim, exemplos:

Se for Dinheiro, cadastrar:
Nome: "Dinheiro"
Conta Financeira:  "CAIXA"
Forma de Pagamento Fiscal: "Dinheiro"

• • • • Aqui seguimos um padrão, sempre cadastrando o "Nome" com os mesmos caracteres do tipo de pagamento selecionado, a "Conta Financeira" sempre será por padrão a primeira, com ID menor, neste caso foi "CAIXA" e a "Forma de Pagamento Fiscal" sempre colocar aquela que tenha os mesmos caracteres do tipo de pagamento também.
        
        Exceções:
        • Tipo pagamento em tela: "Boleto" - Deverá vincular com a "Forma de Pagamento Fiscal":
          "Boleto Bancário"
        • Tipo pagamento em tela: "PIX" - Deverá vincular com a "Forma de Pagamento Fiscal":
          "PIX - Estático"

2. Data de Vencimento: por padrão deverá puxar a data de hoje.

3. Parcelas: por padrão deverá começar com valor "1"(um).

3.1 Não poderá ser menor do que "1"(um), sendo esse o menor valor possível.
3.2 Ao clicar no + vai acrescentar uma parcela e ao clicar no - vai subtrair uma parcela de 1 em 1.

4. Periodicidade: por padrão deverá começar com valor - "mensal":

4.1 Deverá listar essas opções para escolha: "mensal", "semanal", "quinzenal"

5. Bandeira: por padrão deverá começar com valor - "Visa"

5.1 Deverá listar todas as opções de "Bandeira" que temos hoje no cadastro de forma de pagamento.

6. Cód. Autorização: por padrão deverá começar em branco e não será um campo obrigatório para adicionar Recebimentos!

7. Caso esteja configurado o recebimento por TEF, deve ser chamado o Hub de Pagamentos. Os valores de bandeira e autorização vão retornar após o pagamento.

5.3 Registro de Recebimento - Débito

Protótipo de Tela:

Imagem X - Grupo - Registrar Recebimento - Débito

Regras de Interface:

1. Para este tipo de pagamento, ocultar os campos "Parcelas", "Periodicidade" e "Data de Vencimento"

2. Para os outros campos, as regras serão iguais as do cartão de crédito.

3. CNPJ Recebedor: Deve puxar o CNPJ registrado no cadastro da Empresa no Gerencie Aqui. Quando sem preenchimento, deve exibir o Placeholder "Insira o CNPJ"

4. CNPJ PSP: Caso configurado TEF, em Configurações>Documentos Fiscais>Card "Cupom Fiscal Eletrônico", puxar o CNPJ preenchido em "CNPJ credenciadora*". Quando sem preenchimento, d Deve conter o Placeholder "Insira o CNPJ"

Regras de Negócio:

1. Caso esteja configurado o recebimento por TEF, deve ser chamado o Hub de Pagamentos. Os valores de bandeira e autorização vão retornar após o pagamento.

Descrição dos campos e Regras de Negócios:

Seguir Descrição dos campos, Regras de Negócios iguais as do cartão de crédito.

5.4 Registro de Recebimento - Boleto

Protótipo de Tela:

 

Imagem XI - Grupo - Registrar Recebimento - Boleto

Regras de Interface:

1. Para este tipo de pagamento, ocultar os campos "Bandeira" e "Cód. Autorização"

2. Para os outros campos, as regras serão iguais as do cartão de crédito.

Descrição dos campos e Regras de Negócios:

Seguir Descrição dos campos, Regras de Negócios iguais as do cartão de crédito.

5.5 Registro de Recebimento - PIX Dinâmico

Protótipo de Tela:

Imagem XII - Grupo - Registrar Recebimento - PIX Dinâmico

Descrição dos Campos:

Campo	Tipo	Tamanho	Obrig. ?	Máscara	Observações
Gerar Código Pix	Button	-	-	-	-

Regras de Interface:

1. Para este tipo de pagamento, ocultar os campos "Parcelas", "Periodicidade", "Bandeira".

2. Para os outros campos, as regras serão iguais as do cartão de crédito.

3. Por padrão, antes de gerar o código PIX, deverá ficar desta forma, com o botão "Adicionar Recebimento" bloqueado para o clique (ação).

4. Após ação de "Gerar Código Pix", deverá abrir esta Dialog:

4.1 Seta ao lado de "Recebimento" voltará para dialog anterior, fechando esta, perdendo os dados gerados de QRcode e sendo necessário gerar novamente.

4.2 O "X" ao lado direito, fechará a dialog também, perdendo os dados gerados de QRcode e sendo necessário gerar novamente.

4.3 Botão deverá copiar o "Código Pix".

4.4 Quando for feito a consulta de status, e o pagamento tiver sido efetuado pelo cliente do usuário, retornar em tela:

5. CNPJ Recebedor: Deve puxar o CNPJ registrado no cadastro da Empresa no Gerencie Aqui. Quando sem preenchimento, deve exibir o Placeholder "Insira o CNPJ"

6. CNPJ PSP: Caso configurado TEF, em Configurações>Documentos Fiscais>Card "Cupom Fiscal Eletrônico", puxar o CNPJ preenchido em "CNPJ credenciadora*". Quando sem preenchimento, d Deve conter o Placeholder "Insira o CNPJ"

7. Cód. Autorização: Vai ser preenchido o valor ao retornar o pagamento realizado pelo PIX via TEF.

Regras de Negócio:

1. Estes dados de PIX Dinâmico só deverão ser carregados quando selecionado o tipo "PIX" e no campo "Forma de Pagamento" for selecionado alguma forma que tenha a forma fiscal como "PIX - Dinâmico".

1.2 Por padrão deverá carregar os dados de PIX ESTÁTICO

2. "Forma de Pagamento", "Valor", "Data de Vencimento", segui as mesmas regras já definidas em "cartão de crédito"

3. Dialog do QRCode PIX: Deverá carregar em tela o valor gerado pela consulta API SHIPAY, QRCODE gerado no centro. Dialog é aberta assim que o usuário clicar em "Gerar Código Pix".

3.1 Código Pix: Deverá vir o valor gerado da consulta API SHIPAY, com base nas configurações do usuário.

3.2 O valor carregado em tela, será referente ao que foi preenchido no campo "Valor" da tela anterior.

3.3 Não podera ser gerado o QRCode e seguir para esta dialog, quando não houver um valor válido no campo "Valor", sendo ele maior que 0 (zero).
Podendo gerar apenas se ainda houver valor a ser pago referente a operação.

4. "Verificar Status": Deverá consultar na API da Shipay o Status atual do PIX gerado, para conferir se foi pago, se deu algum problema, etc.

5. Após o pagamento PIX ter sido realizado, tendo ele vinculo com a integração via SHIPAY, deverá ficar bloqueado, assim como é feito para o TEF.

6. Caso esteja configurado o recebimento por TEF, deve ser chamado o Hub de Pagamentos. Os valores de bandeira e autorização vão retornar após o pagamento.

5.6 Registro de Recebimento - Pix Estático

Protótipo de Tela:

Imagem XIII - Grupo - Registrar Recebimento - Pix Estático

Regras de Interface:

1. Para este tipo de pagamento, ocultar os campos "Bandeira", "Cód. Autorização", "Parcelas" e "Periodicidade"

2. Para os outros campos em tela, as regras serão iguais as do "cartão de crédito"

3. CNPJ Recebedor: Deve puxar o CNPJ registrado no cadastro da Empresa no Gerencie Aqui. Quando sem preenchimento, deve exibir o Placeholder "Insira o CNPJ"

4. CNPJ PSP: Caso configurado TEF, em Configurações>Documentos Fiscais>Card "Cupom Fiscal Eletrônico", puxar o CNPJ preenchido em "CNPJ credenciadora*". Quando sem preenchimento, d Deve conter o Placeholder "Insira o CNPJ"

5. Cód. Autorização: Vai ser preenchido o valor ao retornar o pagamento realizado pelo PIX via TEF.

Regras de Negócio:

1. Caso esteja configurado o recebimento por TEF, deve ser chamado o Hub de Pagamentos. Os valores de bandeira e autorização vão retornar após o pagamento.

Descrição dos campos e Regras de Négocios:

1. Por padrão este deverá ser o modelo quando selecionado o tipo de pagamento PIX.

Seguir Descrição dos campos, Regras de Negócios iguais as do cartão de crédito.

5.7 Registro de Recebimento - Outros

Protótipo de Tela:

Imagem XIV - Grupo - Registrar Recebimento - Outros

Regras de Interface:

1. Para este tipo de pagamento, ocultar os campos "Bandeira", "Cód. Autorização", "Parcelas" e "Periodicidade"

2. Forma de pagamento: exibir somente as formas de pagamentos personalizadas e vinculadas com a forma de pagamento fiscal "Outros" e também qualquer outra que não tenha sido específicada como "Cheque", "Cartão da Loja", "Vale alimentação", etc.

3. Para os outros campos em tela, as regras serão iguais as do "cartão de crédito"

4. CNPJ Recebedor: Deve puxar o CNPJ registrado no cadastro da Empresa no Gerencie Aqui. Quando sem preenchimento, deve exibir o Placeholder "Insira o CNPJ"

5. CNPJ PSP: Caso configurado TEF, em Configurações>Documentos Fiscais>Card "Cupom Fiscal Eletrônico", puxar o CNPJ preenchido em "CNPJ credenciadora*". Quando sem preenchimento, d Deve conter o Placeholder "Insira o CNPJ"

6. Cód. Autorização: Vai ser preenchido o valor ao retornar o pagamento realizado pelo PIX via TEF.

Descrição dos campos e Regras de Négocios:

Seguir Descrição dos campos, Regras de Negócios iguais as do cartão de crédito.

Questões Técnicas:

1. Segue o esquema de cores padrão a ser utilizado nos componentes:

GerencieAqui
Campo	Cód. Hexadecimal
Títulos dos cards (grupos):	#044572
Label dos campos:	#044572
Tooltip:	#242424
Botão editar da listagem:	#1974FC
Botão exclusão da listagem:	#DB102B
Botão confirmação listagem:	#31CC48
(Resumo) Saldo a Pagar	#FFA900
(Resumo) Saldo pago	#009966
Título da dialog:	#242424
Título: Informações quando não há pagamento adicionado	#87898B
Texto: Informações quando não há pagamentos adicionado	#191919
Placeholders:	#505050
Span pix gerado:	#31D305
Span dos avisos	#FFB300
Span sugestão de troco:	#0DC1FF
Label das abas:	#626262
Label aba selecionada:	#009997
Inputs e textos nos grids:	#000000

 

AplicativoEmpresarial (destacado em verde o diferencial)
Campo	Cód. Hexadecimal
Títulos dos cards (grupos):	#242424
Label dos campos:	#621FA4
Tooltip:	#242424
Botão editar da listagem:	#1974FC
Botão exclusão da listagem:	#DB102B
Botão confirmação listagem:	#31CC48
(Resumo) Saldo a Pagar	#FFA900
(Resumo) Saldo pago	#009966
Título da dialog:	#242424
Título: Informações quando não há pagamento adicionado	#87898B
Texto: Informações quando não há pagamentos adicionado	#191919
Placeholders:	#505050
Span pix gerado:	#31D305
Span dos avisos	#FFB300
Span sugestão de troco:	#0DC1FF
Label das abas:	#626262
Label aba selecionada:	#009997
Inputs e textos nos grids:	#000000

Exemplo prático AplicativoEmpresarial:

EmissorNota (destacado em verde o diferencial)
Campo	Cód. Hexadecimal
Títulos dos cards (grupos):	#242424
Label dos campos:	#E0650D
Tooltip:	#242424
Botão editar da listagem:	#1974FC
Botão exclusão da listagem:	#DB102B
Botão confirmação listagem:	#31CC48
(Resumo) Saldo a Pagar	#FFA900
(Resumo) Saldo pago	#009966
Título da dialog:	#242424
Título: Informações quando não há pagamento adicionado	#87898B
Texto: Informações quando não há pagamentos adicionado	#191919
Placeholders:	#505050
Span pix gerado:	#31D305
Span dos avisos	#FFB300
Span sugestão de troco:	#0DC1FF
Label das abas:	#626262
Label aba selecionada:	#009997
Inputs e textos nos grids:	#000000

Exemplo prático EmissorNota:

©SOFTEN SISTEMAS 2025

 

 

 

Pagamento Unificado - Frente de caixa

	Projeto/Sistema: GERENCIAMENTO DE PROJETOS	Versão do Template: 1.2
	Processo: Pagamento Unificado - Frente de caixa	Versão do Documento: 1.0
	Responsável(eis):  Gustavo Fernandes	Data:  28/11/2025

1. Introdução

Este processo visa exemplificar as específicações - Frente de caixa com os dados do pagamento unificado.

2. Processo

I - Fluxograma Pag Unificado - Frente de caixa

 

Processo	Envolvidos	Dados de Entrada	Dados de Saída
PROC001 Pagamento Unificado (frente de caixa)	-	Frente de caixa	Dialog - Pag Unificado

Processos Relacionados

---

Detalhamento geral - Grupos (Layout)

Especificação Funcional

---

PROC001 Pagamento Unificado (frente de caixa):

Protótipo de Tela:

Imagem I - Tela Pag Unificado - Frente caixa (vazio)

Descrição dos Campos:

Campo	Tipo	Tamanho	Obrig. ?	Máscara	Observações
CPF/CNPJ	Texto	-	Não	"000.000.000-00"	-
Nome do Cliente	Texto	-	Não	-	-
(+)	Button	-	Não	-	-

Regras de Interface:

1. Esta nova dialog de pagamento unificada deverá ser chamada no lugar da dialog antiga de pagamento, se tratando do frente de caixa, assim que ele clicar em:

2. Deverá exibir por padrão o campo para identificação do CPF/CNPJ para emissão da NFCe no frente de caixa, conforme imagem I.

2.1 Ao começar a pesquisar o CPF/CNPJ, ele deverá exibir a lista conforme ele identifica se tem ou não cadastrado.

2.2 Ao selecionar um CPF/CNPJ ou digitar um, que já tem cadastro, deverá puxar o nome/razão social no campo automaticamente!

2.3 Apesar de poder consultar um CPF/CNPJ já cadastro e até mesmo ter a opção de cadastrar, o cliente poderá simplesmente preencher os dados e finalizar os pagamentos, sem cadastrar nada, esperando assim que saia apenas no XML, no caso de ser uma venda única pra alguém que ele não quer cadastrar.

3. O botão (+) deverá abrir a dialog para cadastro resumido de cliente (já existente no venda touch hoje):

3.1 Após cadastrar o novo cliente e clicar em "SALVAR", já puxar os dados cadastrados na tela do pagUnificado, vinculando já o cliente que acabamos de cadastrar, assim como é no VendaTouch hoje.

4. Fora esta detalhe da identificação do cliente, seguir as outras regras para cada tipo de pagamento e caso, conforme descrito no processo: Detalhamento geral - Grupos (Layout)

Regras de Negócio:

1. Deverá puxar por padrão os campos de "CPF/CNPJ" e "Nome do cliente" em branco para preenchimento.

1.1 "CPF/CNPJ" e "Nome do cliente" não são campos obrigatórios, preenchimento opcional.

2. Consultar dados e salvar dados de identificação de cliente, na tabela do banco - cliente

3. Após acionar o botão "Finalizar", deverá fechar a tela, registrando os pagamentos e enviando assim o cupom (NFCe) para autorização, seguir o fluxo do sistema de hoje.

3.1 Se retornar alguma rejeição/erro, deverá limpar a tela e continuar o fluxo normal, registrando assim a NFCe na tela nova de NFCe para correção posterior.

3.1 Se autorizar, seguir fluxo normal também, gerando contas a receber/recebidas de acordo com o tipo de pagamento.

Questões Técnicas:

1. Dados na tela de pagamento devem ser consultados e salvos na tabela - nfce e nfcecaixa

1.1 Também devem ser salvos e consultados na tabela referente aos dados de cartão - nfcecartao

©SOFTEN SISTEMAS 2025

 

 

 

 

Pagamento Unificado - Venda Touch (balcão)

	Projeto/Sistema: GERENCIAMENTO DE PROJETOS	Versão do Template: 1.2
	Processo: Pagamento Unificado - Venda Touch (balcão)	Versão do Documento: 1.0
	Responsável(eis):  Gustavo Fernandes	Data:  01/12/2025

1. Introdução

Este processo visa exemplificar as específicações - Venda Touch (balcão) com os dados do pagamento unificado.

2. Processo

 

I - Fluxograma Pag Unificado - Venda Touch

Processo	Envolvidos	Dados de Entrada	Dados de Saída
PROC001 Pagamento Unificado (venda touch)	-	Venda Touch (balcão)	Dialog - Pag Unificado

Processos Relacionados

---

Detalhamento geral - Grupos (Layout)

Especificação Funcional

---

PROC001 Pagamento Unificado (venda touch):

Protótipo de Tela:

Imagem I - Tela Pag Unificado - Venda Touch

Descrição dos Campos:

Campo	Tipo	Tamanho	Obrig. ?	Máscara	Observações
CPF/CNPJ	Texto	-	Não	"000.000.000-00"	-
Nome do Cliente	Texto	-	Não	-	-
(+)	Button	-	Não	-	-

Regras de Interface:

1. Esta nova dialog de pagamento unificada deverá ser chamada no lugar da dialog antiga de pagamento, se tratando do venda touch, assim que ele clicar em "FINALIZA COMPRA":

2. Deverá exibir por padrão o campo para identificação do CPF/CNPJ para emissão da venda no venda touch, conforme imagem I.

2.1 Ao começar a pesquisar o CPF/CNPJ, ele deverá exibir a lista conforme ele identifica se tem ou não cadastrado.

2.2 Ao selecionar um CPF/CNPJ ou digitar um, que já tem cadastro, deverá puxar o nome/razão social no campo automaticamente!

2.3 Apesar de poder consultar um CPF/CNPJ já cadastro e até mesmo ter a opção de cadastrar, o cliente poderá simplesmente preencher os dados e finalizar os pagamentos, sem cadastrar nada, esperando assim que saia apenas no CUPOM, no caso de ser uma venda única pra alguém que ele não quer cadastrar.

3. O botão (+) deverá abrir a dialog para cadastro resumido de cliente (já existente no venda touch hoje):

3.1 Após cadastrar o novo cliente e clicar em "SALVAR", já puxar os dados cadastrados na tela do pagUnificado, vinculando já o cliente que acabamos de cadastrar, assim como é no VendaTouch hoje.

4. Fora esta detalhe da identificação do cliente, seguir as outras regras para cada tipo de pagamento e caso, conforme descrito no processo: Detalhamento geral - Grupos (Layout)

Regras de Negócio:

1. Deverá puxar por padrão os campos de "CPF/CNPJ" e "Nome do cliente" em branco para preenchimento.

1.1 "CPF/CNPJ" e "Nome do cliente" não são campos obrigatórios, preenchimento opcional.

2. Consultar dados e salvar dados de identificação de cliente, na tabela do banco - cliente

3. Após acionar o botão "Finalizar", deverá fechar a tela, registrando os pagamentos e gerando o cupom (não fiscal), seguir o fluxo do sistema de hoje.

3.1 Se retornar alguma erro, deverá limpar a tela e continuar o fluxo normal, registrando assim a venda de venda touch (históricos) para ajuste posterior.

3.1 Se der certo, seguir fluxo normal também, gerando contas a receber/recebidas de acordo com o tipo de pagamento.

Questões Técnicas:

1. Dados na tela de pagamento devem ser consultados e salvos na tabela - vendabalcao

1.1 Também devem ser salvos e consultados na tabela referente ao caixa e item - vendabalcaocaixa e vendabalcaoitem

©SOFTEN SISTEMAS 2025

 

 

 

 

Pagamento Unificado - NFCe

	Projeto/Sistema: GERENCIAMENTO DE PROJETOS	Versão do Template: 1.2
	Processo: Pagamento Unificado - NFCe	Versão do Documento: 1.0
	Responsável(eis):  Gustavo Fernandes	Data:  16/12/2025

1. Introdução

Este processo visa exemplificar as específicações - NFCe com os dados do pagamento unificado.

2. Processo

I - Fluxograma Pag Unificado - NFCe

 

Processo	Envolvidos	Dados de Entrada	Dados de Saída
PROC001 Pagamento Unificado (NFCe)	-	NFCe	Dialog - Pag Unificado

Processos Relacionados

---

Detalhamento geral - Grupos (Layout)

Especificação Funcional

---

PROC001 Pagamento Unificado (NFCe):

Protótipo de Tela:

Imagem I - Chamar Tela PagUnificado

Descrição dos Campos:

Campo	Tipo	Tamanho	Obrig. ?	Máscara	Observações
Adicionar Pagamento	Button	-	Não	-	-

Regras de Interface:

1. Adicionar Pagamento: deverá chamar a dialog nova de pagamento unificado!

Regras de Negócio:

1. "Adicionar Pagamento": inicialmente ficará liberado para adição de pagamentos.

1.2 Adição de pagamentos é uma operação opcional, não é obrigatório! logo poderá ficar em vazio, sem movimentação.

2. "Adicionar Pagamento": só voltará a ser exibido na tela, quando todas as parcelas de pagamento que vieram do pagamento unificado (dialog) forem excluidas

2.1 Hávera uma opção de abrir pagametnos quando eles já estiverem na tela da NFCe, pra caso ele queira conferir e ou adicionar novas parcelas, destacado aqui!

PROC001.2 Pagamento Unificado (NFCe):

Protótipo de Tela:

Imagem II - Tela Pagamento Unificado (NFCe)

Descrição dos campos, Regras de Interface e Regras de Negócio:

Referente a tela do PagUnificado - Seguir o padrão definido nas regras gerais do layout aqui: Pag Unificado

Regras de Interface:

1. Após a finalização da tela de pagamento unificado, os registros deverão ser carregados na tela da NFCe:

1.1 Opção deverá abrir a dialog do PagUnificado novamente, para caso o cliente queira conferir na dialog e para caso ele queira inserir novas parcelas!

2. Haverá uma limitação de apenas 03 parcelas, em tela. A partir disto (04 parcelas ou mais), deverá ser exibido uma barra de rolagem ao lado direito, verticalmente, exemplo:

3. Forma Pgto: Ao clicar na ação "Editar" , campo ficará desbloqueado, liberando uma comboBox:

4. Valor: Ao clicar na ação "Editar" , campo ficará desbloqueado para edição:

5. Data Vencimento: Ao clicar na ação "Editar" , campo ficará desbloqueado para edição com máscara "DD/MM/AAAA":

5.1 Data de vencimento padrão "DD/MM/AAAA", haverá um calendário para seleção de data também, caso o usuário não queira digitar.

6. Ações - Editar: Por padrão o ícone de editar deve ser .

6.1 Ao clicar nele para editar a linha, deverá desbloquea-los, indicando possibilidade de edição nos campos, assim:

6.2 Enquanto o campo estiver sendo editado, o botão de editar, deverá ficar com este ícone de imagem .

7. Ações - Excluir: Por padrão o ícone de exclusão deve ser .

7.1 Ao clicar na ação de excluir, deverá abrir uma dialog perguntando se realmente deseja excluir, com as opções:

Regras de Negócio:

1. Após acionar o botão "Finalizar", deverá fechar a tela, registrando os pagamentos no módulo da NFCe.

2. O que for editado na tela da NFCe ou excluído, deverá ser considerado na hora de finalizar a NFCe e enviado para o XML, gerando as tags correspondentes a pagamentos, etc.

Questões Técnicas:

1. Dados na tela de pagamento devem ser consultados e salvos na tabela - nfce, nfcecaixa, nfcefaturas

1.1 Também devem ser salvos e consultados na tabela referente aos dados de cartão - nfcecartao

©SOFTEN SISTEMAS 2025

 

 

 

 

Pagamento Unificado - DTO genérico

	Projeto/Sistema: Pagamento Unificado - Gerencie Aqui	Versão do Template: 1.2
	Processo: Pagamento Unificado - DTO genérico.	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 uma entidade genérica financeira que será utilizado em todo sistema.

2. Processo

 

I - Fluxograma

Processo	Envolvidos	Dados de Entrada	Dados de Saída
PROC001 Pagamento Unificado - DTO genérico	-	-	-

Especificação Funcional

---

PROC001 Pagamento Unificado - DTO genérico:

Regras de Negócio:

1. A tela de pagamento unificado será controlada como uma entidade financeira genérica, responsável por concentrar todas as informações relacionadas ao registro de recebimentos realizadas na interface do sistema.
2. A estrutura genérica será utilizada exclusivamente para controle das informações durante o uso da tela de pagamento. Após a confirmação da operação, os dados vão ser convertidos para a estrutura especifica de acordo com o documento onde o financeiro será gerado.
3. Deve ser mapeado a estrutura genérica com as estruturas especificas.
4. O processo deverá ser realizado tanto para o envio de informações da tela para documento especifico no momento da confirmação da operação; como para carregar informações já existentes do documento financeiro para a tela, quando o usuário abrir ou editar os pagamentos.

Questões Técnicas:

1. Deverá ser criado um DTO genérico de pagamentos com o objetivo de padronizar a comunicação entre a tela de registro de recebimentos e os diferentes módulos do sistema.

A tela deverá manipular exclusivamente esse DTO durante a interação com o usuário.

Para integração com os documentos financeiros específicos do sistema, deverão ser implementados mapeamentos (mappers) responsáveis por:

• • converter os dados do documento financeiro para o DTO genérico no momento da abertura da tela;

  • converter os dados do DTO genérico para a estrutura financeira específica do documento no momento da finalização da operação.

'formaPagamento' deve ser consultada das formas de pagamentos personalizadas cadastradas.

2. ENUMS:

public enum PaymentType {

    DINHEIRO,
    CREDITO,
    DEBITO,
    BOLETO,
    PIX,
    OUTROS

}

public enum PaymentPeriodicity {
    UNICO,        // pagamento único
    SEMANAL,
    QUINZENAL,
    MENSAL,
}

2. Exemplo DTO Principal:

public class PaymentDialogDTO {

    private LocalDateTime dataOperacao;

    // resumo da venda
    private BigDecimal totalCompra;
    private BigDecimal descontoValor;
    private BigDecimal descontoPercentual;
    private BigDecimal acrescimoValor;
    private BigDecimal acrescimoPercentual;
    private BigDecimal totalLiquido;

    // pagamentos adicionados
    private List<PaymentItemDTO> pagamentos;

    // resumo dos pagamentos
    private BigDecimal totalAPagar;
    private BigDecimal saldoAPagar;
    private BigDecimal totalPago;
    private BigDecimal troco;

}

3. Exemplo DTO pagamentos:

public class PaymentItemDTO {
  
    private PaymentType tipoPagamento; 
    // DINHEIRO, CREDITO, DEBITO, BOLETO, PIX, OUTROS   
  
  	private String formaPagamento;
    // ex: Visa, MasterCard, etc B 	
   
	private BigDecimal valorRecebimento;
    
    private LocalDate dataVencimento;
  
  	private Integer numeroParcelas;
  
  	private PaymentPeriodicity periodicidade;
  
  	private String cnpjPSP;
  
   	private String cnpjRecebedor;

    private String idTransacao;

    private String codigoPix;

}

4. Mapeamento exemplo (não está no contexto do sistema):

public class OrdemServicoPaymentMapper {

    public static void mapPaymentsToOrdemServico(
            PaymentDialogDTO dto,
            OrdemServico ordemServico) {

        List<OrdemServicoRecebimento> recebimentos = new ArrayList<>();

        for (PaymentItemDTO item : dto.getPagamentos()) {

            OrdemServicoRecebimento recebimento = new OrdemServicoRecebimento();

            recebimento.setTipoPagamento(item.getTipoPagamento());
            recebimento.setValorRecebido(item.getValorRecebimento());
            recebimento.setVencimento(item.getDataVencimento());
            recebimento.setIdTransacao(item.getIdTransacao());

            recebimentos.add(recebimento);
        }

        ordemServico.setRecebimentos(recebimentos);
    }

}

©SOFTEN SISTEMAS 2026