Histórico da Página

Informações Gerais

Objetivo

<Nesta etapa informar o objetivo da especificação do requisito, ou seja, o que a funcionalidade deve fazer. Exemplo: Permitir que o usuário defina o percentual mínimo em espécie (dinheiro), a referência mínima para calculo dos débitos do aluno e o período de validade do parâmetro de negociação>.

(Obrigatório)

Salvar as marcações no HCM mesmo que o TSA não tenha encontrado um usuário e papel crachá para associar esta marcação.

Definição da Regra de Negócio

<Regra de negócio é o que define a forma de fazer o negócio, o processo definido e/ou as regras que devem ser contempladas. Devem ser descritas restrições, validações, condições e exceções do processo. Caso necessário, incluir neste capítulo também regras de integridade que devem ser observadas no momento do desenvolvimento>.

<Na tabela abaixo informe quais são as rotinas envolvidas, o tipo de operação, a opção de menu e se necessário uma breve descrição das regras de negócio relacionadas a rotina>.

Exemplo de Aplicação:

• Criar o campo “% Mínimo Espécie” (AAA_PERESP) onde o usuário informará o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação.
• Criar o campo “Referência Mínima para Cálculo” (AAA_REFCAL) onde o usuário informará um dos 4 valores disponíveis para pagamento das mensalidades  como a referência mínima para calcular o débito total do aluno.
• Criar o parâmetro MV_ACPARNE que definirá se as informações de “% Mínimo Espécie” e “Referência Mínima para Cálculo” serão obrigatórias.
• O parâmetro MV_ACPARNE deve ter as seguintes opções: 1=Obrigatório e 2=Opcional. Deve ser inicializado como opcional>.

Tabelas Utilizadas

• SE2 – Cadastro de Contas a Pagar
• FI9 – Controle de Emissão de DARF>.

Opcional

Protótipo de Tela

<Caso necessário inclua protótipos de telas com o objetivo de facilitar o entendimento do requisito, apresentar conceitos e funcionalidades do software>.

Protótipo 01

 Image Removed

Opcional

Fluxo do Processo

<Nesta etapa incluir representações gráficas que descrevam o problema a ser resolvido e o sistema a ser desenvolvido. Exemplo: Diagrama - Caso de Uso, Diagrama de Atividades, Diagrama de Classes, Diagrama de Entidade e Relacionamento e Diagrama de Sequência>. 

Opcional

Dicionário de Dados

Arquivo ou Código do Script: AAA – Negociação Financeira / *Versao=CP.2014.12_03*/

(Opcional)

Grupo de Perguntas

<Informações utilizadas na linha Protheus>.

Nome: FINSRF2

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

Consulta: AMB

Hoje a integração busca um usuário pelo PIS e que tenha um papel/crachá ativo para a data em que a marcação foi feita. Em caso de não encontrar, a marcação é descartada, gerando possíveis problemas no cálculo de ponto deste funcionário no sistema externo.

Para contornar isso e obrigar o TSA gravar a marcação no sistema externo, serão adicionadas duas regras ao invés de descartar a marcação:

- Em caso de encontrar um usuário para o respectivo PIS, porém sem crachá ativo:

                    - Salvar a marcação para o último papel/crachá, mesmo o papel/crachá não estando ativo;

                    - E salvar a marcação no sistema externo.

- Caso não encontre nenhum usuário para o PIS:

                    - Deve criar um usuário, propriamente chamado de usuário desconhecido, com papel/crachá e pessoa física. Somente cria os registros na primeira ocorrência, após a primeira ocorrência deve-se reutilizar este registro;

                    - Salvar a marcação no sistema externo com o PIS original retornado pelo dispositivo e não com o PIS do usuário desconhecido.

                    - O CNPJ da marcação que deve ser utilizado para o campo COD_ID_FEDER é o CNPJ do dispositivo.

Há a obrigação de salvar no TSA a marcação pois a identificação primária da tabela MSA_CONTROL_MARCAC é a coluna VAL_CONTROL_MARCAC, que é alimentada pelo TSA com o ID da tabela MARK. Sendo uma referência para a marcação no TSA.

As alterações devem contemplar todos os dispositivos REP homologados.

Para validar, deve-se considerar três cenários:

- O primeiro, para um usuário que o sistema não encontre o PIS, pode ser feita uma duplicação de PIS, onde o primeiro usuário já tenha sido enviado para o REP. Ou ainda, uma alteração de PIS, com marcações já feitas no equipamento e ainda não integradas com o TSA;

- O segundo teste deve considerar um usuário com o PIS correto, porém já demitido ou apenas com todos os crachás encerrados;

- O último teste deve apenas considerar um usuário sem crachá.

O resultado esperado em todas as situações é que a marcação seja integrada na tabela do sistema externo.

(Opcional)

Estrutura de Menu

<Informações utilizadas na linha Datasul>.

Procedimentos

Programas

Cadastro de Papéis

<O cadastro de papéis é obrigatório para os projetos de desenvolvimento FLEX a partir do Datasul 10>.

<Lembrete: o nome dos papeis em inglês descrito neste ponto do documento, devem ser homologados pela equipe de tradução>.