Mudanças entre as edições de "Meios de pagamento"
(25 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
Linha 40: | Linha 40: | ||
[[arquivo: MPGTO.png]] | [[arquivo: MPGTO.png]] | ||
− | A tela de CRUD deverá possuir botão de pesquisa, a fim de que o usuário possa procurar por acessos existentes. Ao listar todos os cadastros, deverá ser possível ao usuário editar os cadastros existentes, além de ter a opção de deixar tais cadastros ativos ou não. | + | A tela de CRUD deverá possuir botão de pesquisa, a fim de que o usuário possa procurar por acessos existentes. Ao listar todos os cadastros, deverá ser possível ao usuário editar os cadastros existentes, além de ter a opção de deixar tais cadastros ativos ou não. Esta função será parametrizada por meio da criação de uma coluna chamada ID_ATIVO na tabela MEIO_PGTO. |
− | Após a inserção dos dados, um código de meio de pagamento será gerado. Dependendo da origem do dado (inserção de dados via plataforma GeoSales ou por meio de integração), será utilizado um sinal para diferenciar a origem do codigo. Portanto, para o dado originado pelo ERP, o código será gerado com sinal positivo (ou sem sinal aparente), e dados originados pelo usuário dentro da plataforma deverão ser apresentados com sinal negativo. | + | Após a inserção dos dados, um código de meio de pagamento será gerado. Dependendo da origem do dado (inserção de dados via plataforma GeoSales ou por meio de integração), será utilizado um sinal para diferenciar a origem do codigo. Portanto, para o dado originado pelo ERP, o código será gerado com sinal positivo (ou sem sinal aparente), e dados originados pelo usuário dentro da plataforma (tabela MEIO_PAGAMENTO, coluna CD_MEIO_PGTO) deverão ser apresentados com sinal negativo. |
== Cenários == | == Cenários == | ||
+ | |||
+ | Para compor as movimentações do cenário, consideremos a tabela MEIO_PAGAMENTO: | ||
+ | |||
+ | {| class="wikitable" | ||
+ | ! CD_MEIO_PGTO | ||
+ | ! DS_MEIO_PGTO | ||
+ | ! CD_MEIO_PGTO_REFERENCIA | ||
+ | |- | ||
+ | | 1 || Boleto à vista || NULL | ||
+ | |- | ||
+ | | 2 || Débito automático || NULL | ||
+ | |- | ||
+ | |} | ||
+ | |||
+ | Na tabela, percebemos que dois meios de pagamento já estão disponibilizados: boleto à vista e débito automático. Percebemos que os códigos de meios de pagamento são positivos (ou não possuem sinal negativo), indicando que tais meios foram importados diretamente do ERP. | ||
=== 1. Criação de um Novo Meio de Pagamento === | === 1. Criação de um Novo Meio de Pagamento === | ||
− | * | + | * O usuário acessa o portal e realiza a abertura de um meio de pagamento novo, ainda não existente no cadastro. Ele pede a criação de um novo meio de pagamento, inserindo no campo 'descrição do meio de pagamento' a informação 'Crédito', salvando em seguida. |
− | + | ||
− | + | * A informação será salva e os dados popularão a tabela conforme abaixo: | |
− | * | + | |
− | * | + | {| class="wikitable" |
− | + | ! CD_MEIO_PGTO | |
− | + | ! DS_MEIO_PGTO | |
− | + | ! CD_MEIO_PGTO_REFERENCIA | |
− | + | |- | |
+ | | 1 || Boleto à vista || NULL | ||
+ | |- | ||
+ | | 2 || Débito automático || NULL | ||
+ | |- | ||
+ | | -1 || Crédito || NULL | ||
+ | |- | ||
+ | |} | ||
+ | |||
+ | * A seguir o usuário faz novo cadastro, agora com a descrição 'Pix'. Um terceiro cadastro é realizado, com a descrição 'Boleto para 10 dias', A tabela atualizada ficará assim representada: | ||
+ | |||
+ | |||
+ | {| class="wikitable" | ||
+ | ! CD_MEIO_PGTO | ||
+ | ! DS_MEIO_PGTO | ||
+ | ! CD_MEIO_PGTO_REFERENCIA | ||
+ | |- | ||
+ | | 1 || Boleto à vista || NULL | ||
+ | |- | ||
+ | | 2 || Débito automático || NULL | ||
+ | |- | ||
+ | | -1 || Crédito || NULL | ||
+ | |- | ||
+ | | -2 || Pix || NULL | ||
+ | |- | ||
+ | | -3 || Boleto para 10 dias || NULL | ||
+ | |- | ||
+ | |} | ||
=== 2. Criação de um Novo Meio de Pagamento (com repetição de cadastro) === | === 2. Criação de um Novo Meio de Pagamento (com repetição de cadastro) === | ||
− | + | Consideremos a tabela MEIO_PAGAMENTO: | |
− | + | ||
− | + | ||
− | + | ||
− | + | {| class="wikitable" | |
− | + | ! CD_MEIO_PGTO | |
− | + | ! DS_MEIO_PGTO | |
− | + | ! CD_MEIO_PGTO_REFERENCIA | |
− | * | + | |- |
− | * | + | | 1 || Boleto à vista || NULL |
+ | |- | ||
+ | | 2 || Débito automático || NULL | ||
+ | |- | ||
+ | | -1 || Crédito || NULL | ||
+ | |- | ||
+ | | -2 || Pix || NULL | ||
+ | |- | ||
+ | | -3 || Boleto para 10 dias || NULL | ||
+ | |- | ||
+ | |} | ||
+ | |||
+ | |||
+ | * Para este cenário, tentaremos criar um novo meio de pagamento, chamado 'Pix'. Percebam que já existe um meio com este parâmetro. | ||
+ | * Neste cenário será disparado um aviso ao usuário de que já existe este meio no Banco de Dados, e retornará para a tela para que o usuário escolha outra descrição de meio de pagamento, ou cancele a abertura deste cadastro. | ||
=== 3. Edição de um Meio de Pagamento existente === | === 3. Edição de um Meio de Pagamento existente === | ||
− | * | + | * Vamos imaginar um cenário onde o cliente cadastrou um meio de pagamento 'debito' mas, acidentalmente, digitou 'debto', ou que tenha cadastrado boleto para 10 dias, mas era pra ser 20 dias. Para a correção, ele poderá editar seu cadastro. |
− | + | ||
− | + | * Quando selecionar o botão 'pesquisar', surgirá a lista de meios de pagamento já cadastrados anteriormente. Ao selecionar o ícone correspondente à edição do cadastro, a tela de cadastro estará disponível para que o texto da descrição seja corrigido. Neste exemplo, a descrição de meio de pagamento boleto para 10 dias foi substituído para boleto para 20 dias. | |
− | + | ||
− | *Quando selecionar o botão 'pesquisar' | + | |
− | + | {| class="wikitable" | |
− | + | ! CD_MEIO_PGTO | |
− | + | ! DS_MEIO_PGTO | |
− | + | ! CD_MEIO_PGTO_REFERENCIA | |
− | + | |- | |
− | + | | 1 || Boleto à vista || NULL | |
+ | |- | ||
+ | | 2 || Débito automático || NULL | ||
+ | |- | ||
+ | | -1 || Crédito || NULL | ||
+ | |- | ||
+ | | -2 || Pix || NULL | ||
+ | |- | ||
+ | | -3 || Boleto para 20 dias || NULL | ||
+ | |- | ||
+ | |} | ||
=== 4. Edição de um Meio de Pagamento existente (com repetição de cadastro) === | === 4. Edição de um Meio de Pagamento existente (com repetição de cadastro) === | ||
− | * | + | * Nesta ocasião, o usuário tenta modificar a descrição de seu meio de pagamento, mas a entrada digitada coincide com uma outra entrada, já existente no banco de dados. |
− | + | ||
− | + | * Então será disparado um aviso ao usuário de que já existe este meio no Banco de Dados, e retornará para a tela para que o usuário escolha outra descrição de meio de pagamento, ou cancele a edição deste cadastro. | |
− | |||
− | |||
− | |||
− | *Então | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | ''' Não há cenário para alteração de dados provenientes do ERP.''' | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Protótipos == | == Protótipos == | ||
Linha 122: | Linha 168: | ||
'''[RN1] - ''' Não poderá ser possível o cadastro de uma mesma entrada com descrição de meio de pagamento diferentes, mas com codigo de meio de pagamento e codigo de meio de pagamento referencia iguais. Essa rotina será considerada como duplicidade de cadastro. | '''[RN1] - ''' Não poderá ser possível o cadastro de uma mesma entrada com descrição de meio de pagamento diferentes, mas com codigo de meio de pagamento e codigo de meio de pagamento referencia iguais. Essa rotina será considerada como duplicidade de cadastro. | ||
− | '''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra poderá ser sobreposta; | + | '''[RN2] - ''' Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra não poderá ser sobreposta; |
'''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO; | '''[RN3] - ''' Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO; | ||
Linha 130: | Linha 176: | ||
'''[RN5] - ''' Uma vez que o cadastro foi integrado à ERP, este não poderá mais sofrer quaisquer alterações por parte do usuário. | '''[RN5] - ''' Uma vez que o cadastro foi integrado à ERP, este não poderá mais sofrer quaisquer alterações por parte do usuário. | ||
− | '''[RN6] - ''' Caso o | + | '''[RN6] - ''' Caso o campo referente ao ID de ativo da tabela MEIO_PGTO (que será implementada nesta demanda) esteja com status 'null', ele deve ser considerado ativo. |
<!--=== Protótipos === | <!--=== Protótipos === |
Edição atual tal como às 18h09min de 14 de maio de 2021
Histórico de Alterações
Data | Quem | Comentários |
---|---|---|
07/05/2021 | João Ramon | Criação do documento |
Necessidade
Existem tabelas dedicadas a Meios de pagamento no Banco de Dados da GeoSales, mas estas tabelas não podem ser parametrizadas pelo cliente, porque não há interface criada na plataforma GeoSales para esta funcão. Tal funcionalidade necessita ser implementada dentro da plataforma, a fim de que o usuário consiga fazer essas parametrizações.
Solução
Criação de um CRUD para possibilitar as parametrizações de meio de pagamento, utilizando a tabela homônima, contendo os campos 'Código do Meio de Pagamento', 'Descrição do Meio de Pagamento' e 'Código do Meio de Pagamento de Referência'. O usuário deverá, por meio destes campos, criar, editar ou excluir os meios de pagamento que ele julgar necessários dentro da plataforma, utilizando as tabelas já fornecida no Banco de dados.
Implementação
A tabela de pagamento possui as seguintes vinculações: CD_MEIO_PGTO, DS_MEIO_PGTO e CD_MEIO_PGTO_REFERENCIA, todas em formato varchar e suas respectivas parametrizações.
Column_name | Type | Lenght | Nullable |
---|---|---|---|
CD_MEIO_PGTO | varchar | 15 | no |
DS_MEIO_PGTO | varchar | 30 | no |
CD_MEIO_PGTO_REFERENCIA | varchar | 30 | yes |
A interface do cliente com a plataforma se dará por meio de um CRUD, que será alocado no módulo 'Cenário de Vendas'.
A sequência operacional do CRUD seguirá conforme o modelo abaixo:
A tela de CRUD deverá possuir botão de pesquisa, a fim de que o usuário possa procurar por acessos existentes. Ao listar todos os cadastros, deverá ser possível ao usuário editar os cadastros existentes, além de ter a opção de deixar tais cadastros ativos ou não. Esta função será parametrizada por meio da criação de uma coluna chamada ID_ATIVO na tabela MEIO_PGTO.
Após a inserção dos dados, um código de meio de pagamento será gerado. Dependendo da origem do dado (inserção de dados via plataforma GeoSales ou por meio de integração), será utilizado um sinal para diferenciar a origem do codigo. Portanto, para o dado originado pelo ERP, o código será gerado com sinal positivo (ou sem sinal aparente), e dados originados pelo usuário dentro da plataforma (tabela MEIO_PAGAMENTO, coluna CD_MEIO_PGTO) deverão ser apresentados com sinal negativo.
Cenários
Para compor as movimentações do cenário, consideremos a tabela MEIO_PAGAMENTO:
CD_MEIO_PGTO | DS_MEIO_PGTO | CD_MEIO_PGTO_REFERENCIA |
---|---|---|
1 | Boleto à vista | NULL |
2 | Débito automático | NULL |
Na tabela, percebemos que dois meios de pagamento já estão disponibilizados: boleto à vista e débito automático. Percebemos que os códigos de meios de pagamento são positivos (ou não possuem sinal negativo), indicando que tais meios foram importados diretamente do ERP.
1. Criação de um Novo Meio de Pagamento
- O usuário acessa o portal e realiza a abertura de um meio de pagamento novo, ainda não existente no cadastro. Ele pede a criação de um novo meio de pagamento, inserindo no campo 'descrição do meio de pagamento' a informação 'Crédito', salvando em seguida.
- A informação será salva e os dados popularão a tabela conforme abaixo:
CD_MEIO_PGTO | DS_MEIO_PGTO | CD_MEIO_PGTO_REFERENCIA |
---|---|---|
1 | Boleto à vista | NULL |
2 | Débito automático | NULL |
-1 | Crédito | NULL |
- A seguir o usuário faz novo cadastro, agora com a descrição 'Pix'. Um terceiro cadastro é realizado, com a descrição 'Boleto para 10 dias', A tabela atualizada ficará assim representada:
CD_MEIO_PGTO | DS_MEIO_PGTO | CD_MEIO_PGTO_REFERENCIA |
---|---|---|
1 | Boleto à vista | NULL |
2 | Débito automático | NULL |
-1 | Crédito | NULL |
-2 | Pix | NULL |
-3 | Boleto para 10 dias | NULL |
2. Criação de um Novo Meio de Pagamento (com repetição de cadastro)
Consideremos a tabela MEIO_PAGAMENTO:
CD_MEIO_PGTO | DS_MEIO_PGTO | CD_MEIO_PGTO_REFERENCIA |
---|---|---|
1 | Boleto à vista | NULL |
2 | Débito automático | NULL |
-1 | Crédito | NULL |
-2 | Pix | NULL |
-3 | Boleto para 10 dias | NULL |
- Para este cenário, tentaremos criar um novo meio de pagamento, chamado 'Pix'. Percebam que já existe um meio com este parâmetro.
- Neste cenário será disparado um aviso ao usuário de que já existe este meio no Banco de Dados, e retornará para a tela para que o usuário escolha outra descrição de meio de pagamento, ou cancele a abertura deste cadastro.
3. Edição de um Meio de Pagamento existente
- Vamos imaginar um cenário onde o cliente cadastrou um meio de pagamento 'debito' mas, acidentalmente, digitou 'debto', ou que tenha cadastrado boleto para 10 dias, mas era pra ser 20 dias. Para a correção, ele poderá editar seu cadastro.
- Quando selecionar o botão 'pesquisar', surgirá a lista de meios de pagamento já cadastrados anteriormente. Ao selecionar o ícone correspondente à edição do cadastro, a tela de cadastro estará disponível para que o texto da descrição seja corrigido. Neste exemplo, a descrição de meio de pagamento boleto para 10 dias foi substituído para boleto para 20 dias.
CD_MEIO_PGTO | DS_MEIO_PGTO | CD_MEIO_PGTO_REFERENCIA |
---|---|---|
1 | Boleto à vista | NULL |
2 | Débito automático | NULL |
-1 | Crédito | NULL |
-2 | Pix | NULL |
-3 | Boleto para 20 dias | NULL |
4. Edição de um Meio de Pagamento existente (com repetição de cadastro)
- Nesta ocasião, o usuário tenta modificar a descrição de seu meio de pagamento, mas a entrada digitada coincide com uma outra entrada, já existente no banco de dados.
- Então será disparado um aviso ao usuário de que já existe este meio no Banco de Dados, e retornará para a tela para que o usuário escolha outra descrição de meio de pagamento, ou cancele a edição deste cadastro.
Não há cenário para alteração de dados provenientes do ERP.
Protótipos
Regras de Negócios
[RN1] - Não poderá ser possível o cadastro de uma mesma entrada com descrição de meio de pagamento diferentes, mas com codigo de meio de pagamento e codigo de meio de pagamento referencia iguais. Essa rotina será considerada como duplicidade de cadastro.
[RN2] - Não deverá haver sobreposição de cadastros, e sim edição deste cadastro. Caso o usuário tente cadastrar o mesmo cenário mais de uma vez, a plataforma irá alertar informando que já existe uma regra, e que essa regra não poderá ser sobreposta;
[RN3] - Essa funcionalidade será desenvolvida exclusivamente no GeoSales EVO;
[RN4] - Visto que as parametrizações poderão ocorrer tanto via GeoSales como por meio da ERP, deve ser necessário diferenciar a origem destas entradas, tratando os dados inseridos na CD_MEIO_PGTO com sinal negativo, no caso de origem via GeoSales, e com sinal positivo, no caso se origem via ERP;
[RN5] - Uma vez que o cadastro foi integrado à ERP, este não poderá mais sofrer quaisquer alterações por parte do usuário.
[RN6] - Caso o campo referente ao ID de ativo da tabela MEIO_PGTO (que será implementada nesta demanda) esteja com status 'null', ele deve ser considerado ativo.
Aprovação
Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.
GeoSales
Setor | Aprovado Por | Data |
---|---|---|
Desenvolvimento - GeoSales | Pessoa que aprovou | 00/00/0000 |
Integração - GeoSales | Pessoa que aprovou | 00/00/0000 |
Configurações - GeoSales | Pessoa que aprovou | 00/00/0000 |
Empresa solicitante
Setor | Aprovado Por | Data | Assinatura |
---|---|---|---|
Gerente TI - Cliente | Pessoa que aprovou | 00/00/0000 | |
Gerente de Projeto - Cliente | Pessoa que aprovou | 00/00/0000 | |
Gerente Comercial - Cliente | Pessoa que aprovou | 00/00/0000 |