Mudanças entre as edições de "Regras Valor mínimo"

@@ Linha 1: / Linha 1: @@
 == 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:
-{|class="wikitable"
-!colspan="6"|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:
-<pre>
-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
-</pre>
-=== 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.

Mudanças entre as edições de "Regras Valor mínimo"

Edição atual tal como às 20h35min de 31 de outubro de 2016

Índice

Necessidade

Atual

Solução declarativa

Pré-detalhes da informação imperativa

Menu de navegação

Pesquisa