Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico.  

Especificação de Requisitos

 

Projeto/Versão: 12.1.7

Requisito/Módulo: SIGAGCT – Gestão de Contratos

Sub-Requisito/Função: Contrato Recorrente

Tarefa/Chamado: ?

País: All

Data Especificação: 15/07/2015

Rotinas Envolvidas

 

 

Rotina

Tipo de Operação

Opção de Menu

CNTA300 – Manutenção

Alteração

Atualizações -> Contratos -> Manutenção

CNTA230 – Tipos de Planilha

Alteração

Atualizações -> Cadastros -> Tipos -> Planilhas

CNTA120 – Medições

Alteração

Atualizações -> Contratos -> Medições


Estratégia de Desenvolvimento e Liberação

 

Produto

Protheus

Release que está sendo desenvolvido

12.1.6

Possui Réplica?

( )Sim (X)Não

Qual a versão?

P12

 

Objetivo

Visando atender as necessidades de um contrato de serviços, será criado o tipo de planilha recorrente no cadastro de tipos de planilha e Contrato.
A rotina de manutenção de contrato será adequada para que na planilha seja possível definir todas as regras de um contrato recorrente, assim fazendo desnecessário o uso de um cronograma financeiro/ fixo.
Será disponibilizada a possibilidade de fazer uma provisão financeira dos contratos recorrentes, bem como a definição de auto-alimentação dessa provisão, se a cada medição ou a cada reajuste.
A medição de um contrato recorrente prefencialmente será feita de forma automática, entretanto o usuário poderá faze-la manualmente antes do processo automático.

Definição da Regra de Negócio

 

Regras

Rotina

  1. Adicionar campos às tabelas de tipo de planilha, cabeçalho de planilha, itens de planilha e cabeçalho de medição conforme sessão de dicionário de dados.

Configurador

  1. Criar parâmetros para disponibilizar provisão financeira conforme sessão de dicionário de dados.

Configurador

  1. Alterar a função de validação do campo Medição Eventual (Cn230GtPlan) para executar o preenchimento automático dos campos abaixo quando for escolhida medição eventual "Recorrente", para atender às regras especificadas e bloquear a edição após o preenchimento:
  • Medição automática => "Sim";
  • Contrato Fixo => "Sim";
  • Cronograma Físico/Financeiro => "Não";
  • Cronograma Contábil => "Não";
  • Previsão Financeira => "Não".

CNTA230

  1. Alterar a função de validação do modelo (CNT230PVld) chamada antes da gravação (pós-valid) para atender às seguintes regras quando for selecionada medição eventual "Recorrente":
  • Medição automática = "Sim";
  • Fixo = "Sim";
  • Cronograma Físico/Financeiro e Contábil = "Não";
  • Previsão Financeira = "Não".
    Se as regras não forem atendidas apresentar aviso e não permitir a gravação.

CNTA230

  1. Desenvolver a função CN300VLREC para verificar se o tipo de planilha é recorrente, que será usada na validação de campos conforme sessão de dicionários de dados.

CNTA300

  1. Desenvolver a função CN300ENREC para verificar se o tipo de planilha é recorrente, que será usada no modo de edição de campos conforme sessão de dicionário de dados.

CNTA300

  1. Alterar as funções que tratam o valor da planilha (CNTA300VlIn, CN300VldPlan, CN300PlnGr, CN300PItPre) para atender à seguinte regra:
    A composição do valor de cada planilha é o valor correspondente a um período de recorrência (uma semana, uma quinzena, um mês, etc.) e este valor é soma dos seus itens ativos.

CNTA300

  1. Na confirmação da gravação do contrato devem ser verificado se para cada linha de planilha informada com tipo Recorrente, os campos relacionados abaixo estão preenchidos tanto no cabeçalho quanto nos itens. Nenhum cronograma deve existir para as respectivas planilhas. Manter as validações já existentes.

    Campos que devem estar preenchidos:
  • CNA_PERIOD
  • CNA_QTDREC
  • CNA_DIASEM
  • CNA_DIAMES
  • CNB_ATIVO

CNTA300

  1. Ao mudar a situação de um contrato do tipo recorrente para "Vigente" serão gerados títulos provisórios para cada planilha e para cada recorrência, assim será possível administrar os valores que serão recebidos ou pagos por um período de tempo previamente definido.

    Para esta operação ser realizada, os itens abaixos deverão ser considerados:
  • Campo CNA_QTDRED – quantidade de períodos de provisionamento;
  • MV_CNTPPP – parâmetro que definirá quando os contratos recorrentes serão provisionados, obedecendo os comportamentos abaixo:
  • Quando o parâmetro for 1, a cada medição gerar mais um período substituindo o período medido.

    Ex: Foram provisionados 12 periodos, ao incluir o primeiro período (medição) a provisão correspondente a ele será excluída e conforme configurado neste exemplo será incluído o 13º período.
  • Quando o parâmetro for 2, sempre que for feita uma revisão de contrato que altere o valor do contrato.

    Serão excluídas todas a provisões previamente geradas independente do número disponível e recriadas conforme a quantidade do campo CNA_QTDRED.
  • Quando o parâmetro for 0 (Zero), valor padrão, os dois casos acima descritos serão executados.
  • Os campos CNA_DTINI e CNA_DTFIM deverão ser considerados para o cálculo da quantidade de recorrências para a periodicidade informada. A quantidade de parcelas de títulos provisórios será a menor quantidade ao comparar a quantidade de recorrências calculada e a informada no campo CNA_QTDREC.
    Funções envolvidas: CN100CTit e CN100ETit.

CNTA300/ CNTA100/ CNTA120

  1. Ao tornar vigente um contrato, além da contabilização pelo valor do montante do contrato, também deverá ser feita contabilização pelo valor total de cada planilha.

    Se a planilha é do tipo recorrente, o valor total da planilha a ser contabilizado é o resultado do valor total dos itens ativos multiplicado pela quantidade de recorrências (menor quantidade ao comparar a quantidade calculada e a informada no campo CNA_QTDREC).
    Para os demais tipos de contratos, o valor total de cada planilha é do campo CNA_TOTAL.
    Será criado um novo código de lançamento padrão para ser usado com esta forma de contabilização. As funções envolvidas são CN100SitCh e CN100Contab.

 

  1. Identificar os fontes que fazem referência ao campo CNL_MEDEVE e corrigir onde for necessário para não ocorrerem defeitos na execução das rotinas.

 

  1. A rotina de medição automática será adequada para considerar somente as medições previstas na coluna "Proxima Medição" dos contratos do tipo recorrente.

CNTA120

  1. A medição deve considerar os item inativos com quantidade zero, ou seja, não irá medir os mesmos.

CNTA120

  1. Para medições pró-rata, o campo CNB_PRORAT deverá ser avaliado, se for diferente de zero será aplicado o percentual que consta no campo ao valor total do item.

CNTA120

  1. Sempre que for feita uma medição os campos e tabelas abaixo deverão ser atualizados:

    CND – Cabeçalho de Medições
  • CND_RECMED -> gravar o conteúdo do campo CNA_RECMED (número da última medição);
  • CND_ULTMED -> gravar o conteúdo do campo CNA_ULTMED (data da última medição).

    CNA – Cabeçalho de Planilhas
  • CNA_MEDEFE -> deve ser incrementado;
  • CNA_ULTMED -> data da medição (atual);
  • CNA_PROMED -> data da próxima medição, calculado em relação à data de referência considerando periodicidade, dia da semana e dia do mês;
  • CNA_RECMED -> numero da última medição (atual).

    CNB – Itens de Planilhas
  • CNB_PRIMED -> data da primeira medição (se for pró-rata).

CNTA120

  1. Alterar a rotina de cancelamento / estorno de medições. Estas operações com medições de contratos recorrentes serão permitidas na ordem inversa da que foram incluídas, a partir da última medição. A condição de permissão de cancelamento / estorno é a seguinte:

    Conteúdo do campo CND_NUMMED = conteúdo do campo CNA_RECMED. Se a condição for atendida, na tabela CNA deverão ser atualizados os seguintes campos:
  • CNA_MEDEFE -> deve ser decrementado;
  • CNA_PROMED -> conteúdo do campo CNA_ULTMED;
  • CNA_ULTMED -> conteúdo do campo CND_ULTMED;
  • CNA_RECMED -> conteúdo do campo CND_RECMED.

CNTA120






Tabelas Utilizadas e Rotina envolvida

CNL

Tipos de Planilhas

CNTA230

CNA

Cabeçalho de Planilhas

CNTA300 / CNTA100

CNB

Itens de Planilhas

CNTA300 / CNTA100

CND

Cabeçalho de Medições

CNTA120 / CNTA130

CNE

Itens de Medições

CNTA120 / CNTA130

 

Release Notes

 

Módulo

SIGAGCT – Gestão de Contratos

Função

Visando atender as necessidades de um contrato de serviços, será criado o tipo de planilha recorrente no cadastro de tipos de planilha e Contrato. Será possível definir na planilha todas as regras de um contrato recorrente, tornando desnecessário o uso de um cronograma financeiro / fixo. Será possível fazer a provisão financeira dos contratos recorrentes, bem como a definição de auto-alimentação dessa provisão, se a cada medição ou a cada reajuste.





(Opcional)

Fluxo do Processo


<Pode ser detalhado em básico, alternativo ou de exceção.
Para customização: caso nenhum dos fluxos abaixo atenda, poderá optar por outro tipo de fluxo, que melhor atenda a necessidade do cliente>.
(Opcional)

  1. Diagrama – Casos de Uso

<Descreva a interação entre o usuário e o sistema, ou mesmo parte do sistema ou de outro sistema com o mesmo. Em um sistema de locadora, descrevemos três casos de uso: o cliente reserva um filme, o cliente aluga um filme e o cliente devolve um filme>
Exemplo de Aplicação:

(Opcional)

  1. Diagrama – Atividades

<O diagrama de atividade descreve regras de negocio de alto nível, incluindo fluxo de dados. Neste exemplo, o diagrama descreve o processo inicial da locação, onde é verificado o registro do cliente, e a locação é aprovada ou recusada.>
Exemplo de Aplicação:



(Opcional)

  1. Diagrama de Classes

<O diagrama de classe mostra uma coleção de objetos estáticos com seus tipos e relacionamentos. Neste modelo omitimos os métodos. Cada entidade real do sistema é representada por um diagrama, ou seja, uma classe. Nesta são apresentadas os atributos, ou características, de cada objeto.>
Exemplo de Aplicação:

(Opcional)

  1. Diagrama de Entidade e Relacionamento

<O DER descreve a diagramação dos dados armazenados do sistema em alto nível de abstração. É uma importante ferramenta, pois ela realça os relacionamentos entre os depósitos de dados de um DFD.>
Exemplo de Aplicação:



(Opcional)

  1. Diagrama de Seqüência

<Consiste em um diagrama que tem o objetivo de mostrar como as mensagens entre os objetos são trocadas no decorrer do tempo para a realização de uma operação>
Exemplo de Aplicação:

Dicionário de Dados

Arquivo: CNL

Campo

CNL_MEDEVE

Tipo

C

Tamanho

1

Descrição

Medição Eventual

Título

Med Eventual

Picture

 

Help de Campo

Incluir help da opção 3 – Recorrente.

Lista de Opções

0=Conforme Contrato;1=Sim;2=Não;3=Recorrente

Val. Sistema

Pertence("0123") .And. Cn230GtPlan("CNL_MEDEVE",FwFldGet("CNL_MEDEVE"))


Arquivo: CNA
Incluir os campos:

Campo

CNA_PERIOD

Tipo

C

Tamanho

1

Descrição

Periodicidade

Título

Periodicid.

Picture

 

Contexto

Real

Propriedade

Alterar

Help de Campo

Indica a periodicidade da medição do contrato, sendo:
1=Diaria, 2=Semanal, 3=Quinzenal, 4=Mensal, 5=Bimestral, 6=Trimestral, 7=Quadrimestral, 8=Semestral e 9=Anual.

Lista de Opções

1=Diaria;2=Semanal;3=Quinzenal;4=Mensal;5=Bimestral;6=Trimestral;7=Quadrimestral;8=Semestral;9=Anual

Val. Sistema

CN300VLREC() .And. Pertence("123456789")

Modo de Edição

CN300ENREC()

Inicializador Padrão

" "

Campo

CNA_QTDREC

Tipo

N

Tamanho

4

Descrição

Quantidade de Recorrências

Título

Qtd. Recorr.

Picture

9999

Contexto

Real

Propriedade

Alterar

Help de Campo

Indica a quantidade de recorrências da planilha a serem medidas.

Val. Sistema

FWFldGet("CNA_QTDREC") >= 0 .And. CN300VLREC()

Modo de Edição

CN300ENREC()

Inicializador Padrão

0

Campo

CNA_DIASEM

Tipo

C

Tamanho

1

Descrição

Dia Preferencial Semana

Título

Dia Semana

Picture

 

Contexto

Real

Propriedade

Alterar

Help de Campo

Indica o dia preferencial da semana para geração da medição, sendo:
1=Indiferente, 2=Segunda, 3=Terça, 4=Quarta, 5=Quinta e 6=Sexta.

Lista de Opções

1=Indiferente;2=Segunda;3=Terça;4=Quarta;5=Quinta;6=Sexta

Val. Sistema

CN300VLREC() .And. Pertence("123456")

Modo de Edição

CN300ENREC()

Inicializador Padrão

"1"

Campo

CNA_DIAMES

Tipo

N

Tamanho

2

Descrição

Dia Preferencial Mês

Título

Dia do Mês

Picture

99

Contexto

Real

Propriedade

Alterar

Help de Campo

Indica o dia de preferência para geração da medição.
Se for indiferente, deixar vazio, ou informe o dia no intervalo de 01 a 31.

Val. Sistema

CN300VLREC() .And. FwFldGet("CNA_DIAMES") >=0 .And. FwFldGet("CNA_DIAMES") <= 31

Modo de Edição

CN300ENREC()

Inicializador Padrão

0

Campo

CNA_ULTMED

Tipo

D

Tamanho

8

Descrição

Última Medição

Título

Últ. Med.

Picture

@E

Contexto

Real

Propriedade

Visualizar

Help de Campo

Indica a data da última medição gerada.
Gravado automaticamente pelo sistema pela rotina de medição.

Campo

CNA_PROMED

Tipo

D

Tamanho

8

Descrição

Próxima Medição

Título

Próx. Med.

Picture

@E

Contexto

Real

Propriedade

Visualizar

Help de Campo

Indica a data da próxima medição a ser gerada.
Calculado automaticamente pelo sistema pela rotina de medição.

Campo

CNA_MEDEFE

Tipo

N

Tamanho

4

Descrição

Medições Efetuadas

Título

Med.Efetuada

Picture

9999

Contexto

Real

Propriedade

Visualizar

Help de Campo

Indica a quantidade de medições já efetuadas para a planilha.
Calculado automaticamente pelo sistema pela rotina de medição.

Campo

CNA_RECMED

Tipo

C

Tamanho

6

Descrição

Nr.Últ. Med.

Título

Número Última Medição Rec

Picture

 

Contexto

Real

Propriedade

Visualizar

Help de Campo

Indica o número da última medição efetuada


Arquivo: CNB
Incluir os campos:

Campo

CNB_ATIVO

Tipo

C

Tamanho

1

Descrição

Ativo

Título

Item Ativo

Picture

 

Contexto

Real

Propriedade

Alterar

Help de Campo

Indica se o item da planilha faz parte da recorrência atual, sendo:
1=Sim e 2=Não.

Lista de Opções

1=Sim;2=Não

Val. Sistema

Vazio() .Or. (CN300VLREC() .And. Pertence("12"))

Modo de Edição

CN300ENREC()

Campo

CNB_PRORAT

Tipo

N

Tamanho

6

Decimais

2

Descrição

Perc. Pró-Rata

Título

Pró-Rata

Picture

@E 999.99

Contexto

Real

Propriedade

Alterar

Help de Campo

Indica o percentual pró-rata que será aplicado ao valor total do item na primeira medição

Lista de Opções

 

Val. Sistema

CN300VLREC() .and. FWFldGet("CNB_PRORAT") >= 0 .And. FWFldGet("CNB_PRORAT") <= 100

Modo de Edição

CN300ENREC()

Campo

CNB_PRIMED

Tipo

D

Tamanho

8

Descrição

Data Primeira Medição

Título

Dt.Prim.Med.

Picture

 

Contexto

Real

Propriedade

Visualizar

Help de Campo

Data da primeira medição realizada. Atualizado automaticamente pelo sistema quando ocorrer a primeira medição e a mesma for pró-rata.

Lista de Opções

 

Val. Sistema

 

Modo de Edição

 


Arquivo: CND
Incluir os campos:

Campo

CND_ULTMED

Tipo

D

Tamanho

8

Descrição

Última Medição

Título

Últ. Med.

Picture

 

Contexto

Real

Propriedade

Visualizar

Help de Campo

Indica a data da medição anterior.
Gravado automaticamente pelo sistema pela rotina de medição.

Campo

CND_RECMED

Tipo

C

Tamanho

6

Descrição

Número Medição Anterior

Título

Nr. Últ. Med.

Picture

 

Contexto

Real

Propriedade

Visualizar

Help de Campo

Indica o número da medição anterior.
Gravado automaticamente pelo sistema pela rotina de medição.

 

 

Nome da Variável

MV_GCTTPPP

Tipo

C

Descrição

Indica quando será reprovisionado, se 1 para medição, 2 para revisão ou 0 (Zero) para ambos.





Obrigatório

Casos de Testes


<Para projeto padrão é obrigatório a identificação dos CTs>
Um caso de teste contém informações gerais que determinam como testes anteriormente especificado pelo Plano de Testes devem ser conduzidos. Geralmente, eles são agrupados por requisito. Entretanto, é possível agrupar casos de teste por conjunto de requisitos, caso os testes estejam verificando integradamente os requisitos que pertencem a esse conjunto.
Os casos de testes mencionados abaixo devem ser executados para garantir a qualidade do produto, atendendo a finalidade do projeto e os resultados esperados.

(Obrigatório)

<O preenchimento desta seção é obrigatório quando existirem casos de testes de rotinas existentes que podem ser reutilizados nesta rotina especificada.>

  1. Caso(s) de Testes Reusável(is)


Neste tópico deverão ser identificados os Casos de Testes Reusáveis, isto é, casos de testes existentes para outras rotinas e que podem ser executados nesta rotina. Esta é apenas uma identificação. O detalhamento dos novos casos, assim como a revisão destes deve ser realizado no template Casos de Testes.>

Caso de Testes

<Identifique o caso de testes. Inclua o nome do caso de testes que está armazenado no TFS>

Armazenamento

<Local onde está armazenado no TFS este caso de testes>

Procedimentos/Cenários de Testes

<Informe os nomes dos procedimentos e as condições que devem executados>

Estimativas

<Transportar a quantidade de horas estimadas no CT armazenado no TFS, somando as pré-condições, inicializações e finalizações correspondentes aos cenários que serão executados>

Finalidade Testes

<Exemplo: Garantir que as alterações realizadas por este projeto não afetaram a rotina nos releases comerciais>

Recomendações

<Informe particularidades que devem ser consideradas neste caso de testes. Exemplo: executar esse caso de testes duas vezes, um com a versão atual da rotina e outra com a versão desse desenvolvimento para garantir que não ocorram diferenças além das solicitadas por este desenvolvimento>

Integrações entre produtos

<Quando houver integração entre produtos, informe a referência para os casos de testes da outra linha de produto>



(Opcional)

  1. Caso(s) de Testes Específico(s) do Projeto


<Neste tópico deverão ser identificados os Casos de Testes Não Reusáveis, isto é, testes que serão executados somente neste projeto, exemplo: teste de interface. Esta é apenas uma identificação. O detalhamento dos casos de testes devem ser feitos na própria especificação.

Caso de Testes

<Informe o nome do caso de testes>

 

 

Finalidade Testes

<Defina qual será a finalidade deste caso de teste >

Estimativas

<Informar o valor total para execução deste caso de teste, considerando o tempo das pré-condições e pós-condições descritas abaixo>

Teste do Programador

( ) Sim ( ) Não

Recomendações

<Informe particularidades que devem ser consideradas neste caso de testes. Exemplo: executar esse caso de testes duas vezes, um com a versão atual da rotina e outra com a versão desse desenvolvimento para garantir que não ocorram diferenças além das solicitadas por este desenvolvimento>

Pré-condições

<Relacione os requisitos que devem ser consideradas quando este caso de teste for executado>

Pós-condições

<Relacione as saídas do caso de teste que devem ser consideradas após a execução dos testes>

Como verificar os resultados

<Detalhe como deverão ser verificados os resultados dos testes>

Procedimentos

Resultados Esperados

<Relacione os passos que devem ser executados para a realização dos testes >

<Relacione o comportamento esperado do passo >