Regras Valor mínimo
Necessidade
Existem empresas que tem vendedores em fuso horário diferentes daquele do servidor de dados (UTC-3, eu creio), por exemplo Manaus (UTC-4). Devido a isso, a hora de uso do sistema para o vendedor DH_SISTEMA chega como se fosse uma hora no futuro, e isso gera encrencas.
Tais empresas precisam que o dado de DH_SISTEMA chegue corretamente para as versões atuais deles.
Atual
O campo DH_VALIDADE funciona para informar ao sistema o tempo esperado de expiração dos dados. Após esse instante, os dados do sistema precisarão de uma atualização para serem revalidados. Muitas vezes, precisa-se dessa data de validade para garantir que o vendedor não efetue uma operação com dados antigos, que já foram suplantados por uma nova importação de dados.
O campo DH_SISTEMA existe para identificar se o vendedor por acaso colocou o dispositivo para um tempo anterior e, assim, falsificar a validade do sistema. Assim, DH_SISTEMA é o marcador do último momento em que o sistema foi utilizado.
Como, a priori, carregar os dados da hora do dispositivo não é confiável, das opções à mão, foi escolhido começar como limite de último uso o instante do servidor, garantindo assim um limite minimamente confiável.
Solução declarativa
Todo vendedor sempre está vinculado a um fuso horário. Na hora do sincronismo, o banco irá converter a informação da hora atual (e da hora de validade final) para o fuso adequado ao vendedor.
Pré-detalhes da informação imperativa
Em DADOS_VENDEDOR, a coluna ID_FUSO_HORARIO fará o vínculo do vendedor com o fuso horário em que ele está. Essa coluna é não nula, tendo por padrão o vínculo com o fuso horário de São Paulo (caso a empresa precise usar outro fuso horário padronizado, pode-se criar a coluna com outro valor padrão).
A estrutura do fuso horário
A tabela fuso horário tem os seguintes campos:
FUSO_HORARIO | |||||
---|---|---|---|---|---|
ID_FUSO_HORARIO | DS_FUSO_HORARIO | UTC | UTC2 | DT_UTC2_INI | DT_UTC2_END |
Chave cega | Descrição do fuso horário | Qual a zona que eu uso? | Qual a zona que eu uso no fuso alternativo? | Date em que começa o fuso horário alternativo | Date em que termina o fuso horário alternativo |
1 | São paulo | -3 | -2 | 2016-10-19 | 2017-01-19 |
Na tabela, a primeira linha corresponde ao nome das colunas, a primeira linha corresponde ao campo, a segunda, à semântica dele e a terceira, um exemplo.
Acesso à informação dos fusos
A tabela do fuso horário fica no bd_ssm_adm, porém com view em cada banco de dados para fácil visualização.
Como no Brasil o horário de verão é algo meio aleatório definido por lei a cada ano, vamos atualizar o início e o fim do horário de verão todo ano.
Alternativa para lugares sem horário de verão
Em locais onde não se usa horário de verão, a saída mais rápida é colocar as colunas UTC e UTC2 com os mesmos valores.
Mudança de consulta no XML
Basicamente, para tornar o tempo adequado para o fuso horário do vendedor, no lugar de se usar a função GETDATE() do SQLServer, deve-se usar o GETUTCDATE(). A adequação para o fuso é aplicar a diferença de fuso da tabela de fuso. Por exemplo:
SELECT GETUTCDATE() + F.UTC/24.0 FROM DADOS_VENDEDOR DV INNER JOIN FUSO_HORARIO F ON (F.ID_FUSO_HORARIO = DV.ID_FUSO_HORARIO) WHERE DV.CD_VENDEDOR = @cd_vendedor
Vínculo do vendedor ao fuso horário
Em um primeiro momento, esse vínculo será feito diretamente no banco através de um feioso update.
No próximo momento, na tela de cadastro de vendedor, terá uma combo box com as opções de fuso que existem na nossa base de fusos que não pode ficar vazio em hipótese alguma.