Este manual irá explicar como realizar o travamento de datas, preparando o profissional que irá realizar as configurações da Data Limite pelo browser, bem como mostrar as possibilidades de configuração no sistema.
As validações dos limites sempre levam em consideração a data mais recente e restritiva na hierarquia de classes. As duas formas de travamento é informando uma data limite na propriedade da classe em questão, ou informando um limite em dias para alteração.
No primeiro caso, as operações anteriores à data informada não poderão ser alteradas. No segundo caso, as operações anteriores a Data Atual menos o Limite em Dias informado não poderão ser alteradas. Entendendo melhor: Se a data de hoje é 15/03 e o limite em dias é 2, significa que operações com datas inferiores ao dia 13/03 não poderão ser mais modificadas.
Entretanto, se tiver informado a data limite 28/02, o limite em dias com 2, a data de hoje for 15/03 e a operação está com data 10/03, como essas informações serão tratadas?
A prioridade de análise é sempre a data que for mais recente. Se formos analisar separadamente ficaria assim: Hoje (15/03), data limite (28/02) e data da operação (10/03) pode ser alterado; Hoje (15/03), limite em dias (2) e data da operação (10/03) -> não pode ser alterado pois esta condição limita alterações para (13/03). Dessa forma o resultado da situação apresentada é a IMPOSSIBILIDADE de alteração devido ao limite em dias imposto.
this.campoBaseParaDataLimite = propriedade do x-class de operações que determina qual o campo da tabela será a base para a verificação da Data de Limite.
this.camposBaseParaValidarLimite = propriedade do x-class de operações que determina quais os campos da tabela serão utilizados para pesquisa da data limite em vigor da operação.
Os limites (limite e limite em dias) devem ser definidos nas configurações de permissão dos grupos e usuários. A regra continua a mesma: a data mais restritiva é a data de limite vigente. Por exemplo: os campos definidos para a pesquisa são CLASSE e LOCESCRITU, e os limites em dias para cada um são 3 e 2 respectivamente. A data mais restritiva na comparação entre os campos é o limite em dias imposto pelo LOCEESCRITU, 2 dias.
Logo, a data limite em questão será calculada com base na limite em dias de 2 dias. Contudo, se for definido uma exceção para um usuário onde o limite em dias é 4 e 5, respectivamente. Neste caso a verificação se dará da seguinte forma: entre o limite imposto para classe de 3 dias e a exceção de 4 dias, qual o menos restritivo? A resposta é 4 dias.
Entre o limite para o local de escrituração de 2 dias e 5 dias, o menos restritivo é 5 dias. Agora comparando os limites entre os campos, 4 dias para classe e 5 dias para o local de escrituração, o mais restritivo é 4 dias. De modo que, na situação descrita, a data limite a ser levada em consideração é a data calculada a partir do limite em dias de 4 dias.
Exemplo descrevendo uma situação hipotética para pedidos:
x-class de Pedidos ou Provisões: this.campoBaseParaDataLimite = "EMISSAO"
x-class de V Adq Terc p Consumo: this.camposBaseParaValidarLimite = "CLASSE;LOCESCRITU"
Pedido com emissao: 01/05/2005
Data do Fechamento: 05/05/2005
Data do dia corrente: 13/05/2005
Usuario: Joaquim - Grupo: Everyone
Permissões:
Nas classes "V Adq Terc p Consumo" e "Locais de Escrituração" o grupo "Everyone" possui data de limite 05/05/2005, logo todas as operaçoes de Pedido com Local de Escrituração e da classe acima informada estão bloqueadas para alterações até a data assinalada.
Entretanto, faz-se necessário que seja liberado para o usuário Joaquim realizar uma alteração em um pedido do dia 01/05/2005 cujo local de escrituração pertence a classe "LE Matriz".
O que tem a ser feito é: na classe "V Adq Terc p Consumo" deve ser criado uma permissão específica para o usuário com data de limite 30/04/2005. Desta forma o usuário Joaquim tem permissão até o dia 13/05/2005 às 12:00 para realizar a devida alteração.
Os campos que devem ser alterados nas Permissões: "Data de Limite para Alterações", "Limite Automático em Dias".