Regras Valor mínimo

De GeoSales
Revisão de 20h27min de 31 de outubro de 2016 por 10.0.0.236 (discussão) (Criou página com '== 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...')
(dif) ← Edição anterior | Revisão atual (dif) | Versão posterior → (dif)
Ir para navegação Ir para pesquisar

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.