Edição das 15h40min de 10 de março de 2014

Padrões das telas do sistema

Todas as telas do sistema sem exceção, independente do volume de dados (no banco ou exibido na tela/grid), deverá ser carregada em até 4 segundos no máximo (com base na velocidade mínima de internet descrita nos requisitos do sistema).

Básicas com grid (com lucene/sem lucene ou com filtros de consulta/pesquisa)

1. Todas as colunas devem possuir opção de ordenação crescente/decrescente salvo exceções pontuadas pelo analista(kardex por exemplo). O sistema deverá salvar, por usuário, a ordenação utilizada em cada grid.
2. O grid deve permitir que o usuário redimensione e reposicione colunas.
3. O cabeçalho do grid deverá permanecer fixo, independente da quantidade de linhas configurada e/ou movimento da barra de rolagem vertical.
4. O grid poderá ser paginado, ou seja, ao atingir a quantidade máxima de linhas configuradas os demais registros deverão ser exibidos em uma nova página do grid. Por padrão os grids deverão ser configurados com uma quantidade de linhas que não gere barra de rolagem vertical no browser.
5. Grids que não são paginados deverão possuir barra de rolagem própria quando a quantidade de registros ultrapassar a quantidade de linhas configurada para exibição.
6. Deverá haver no canto superior direito do grid um botão de configuração com as seguintes funcionalidades:
   • Máximo de linhas: Quantidade máxima de linhas que o grid exibirá por página.
   • Colunas fixas: Quantidade de colunas (da esquerda para a direita começando da primeira) que ficarão fixas, ou seja, ficarão sempre visíveis independente da barra de rolagem horizontal do grid.
   • Colunas: Neste campo poderão ser marcadas/desmarcadas as colunas que serão exibidas no grid.
   • Salvar configurações: Quando acionado, salva as configurações realizadas e atualiza o grid por usuário.
7. A última coluna do grid que apresenta as opções de alterar, visualizar e excluir deverá permanecer sempre fixa, ou seja, independente da barra de rolagem horizontal do grid ela ficará sempre visível.
8. Os títulos das colunas deverão ser sempre alinhados ao centro (vertical e horizontal) das mesmas e escritos em CAIXA ALTA e em negrito.
9. O conteúdo das colunas deverá ser alinhado com base nas seguintes regras:
   • Largura fixa: Dados que possuem largura fixa (ex: Data, código de cliente, código de produto e etc) deverão ser centralizados em sua respectiva coluna do grid.
   • Largura variável: Dados cujo tamanho é variável (ex: Endereços, nomes de clientes e etc) deverão ser alinhados à esquerda em sua respectiva coluna no grid.
   • Números: Valores numéricos (ex: Estoque, valor monetário, número de pedidos, quantidades e etc) deverão ser alinhados à direita em sua respectiva coluna no grid.
   • Icones: Ícones, imagens ou atalhos deverão ser alinhados ao centro de sua respectiva coluna no grid.
10. As colunas deverão possuir uma espécie de separador entre uma e outra para facilitar a visualização do conteúdo do grid.
11. Os grids nunca poderão gerar barra de rolagem vertical no browser a não ser que a quantidade de linhas visíveis configurada seja superior ao valor padrão.
12. Colunas que exibem estoque de itens deverão mostrar estes valores com três casas decimais, independente se os mesmos são fracionados ou inteiros.
13. Colunas que exibem quantidade de itens deverão mostrar estes valores com duas casas decimais, independente se são inteiras ou fracionadas. Caso uma determinada quantidade tenha de fato mais que duas casas o sistema fará o arredondamento.

Funcionalidades

1. Todos os grid do sistema que apresentarem documentos do tipo 55 - PDV, 51 - NF ou 56 - CUPOM deverão apresentar nas quatro primeiras colunas ícones que simbolizem cada tipo de documento que, quando acionados, permitam a visualização dos mesmos (pedido, cupom ou DANFE). Documentos de entrada ou devoluções também poderão ser exibidos, mas serão casos específicos pontuados/solicitados pelo analista.
2. Para entrar em modo de consulta em um determinado registro, o usuário poderá clicar sobre a lupa na última coluna ou simplesmente clicar em qualquer parte da linha do mesmo.
3. Registros de devoluções e documentos em atraso (com juros/multa) deverão ser apresentados na cor vermelha.

Tela inicial das rotinas

• Devem conter (salvo exceções) uma tabela mostrando os dados contidos no banco de dados
• Botões para acionar os comandos de inclusão e tela inicial.
• Botões para os comandos de alteração, visualização e exclusão do item.

Usabilidade das telas

FUNCIONALIDADE DA TECLA <Enter>: Sempre que a tecla <Enter> for pressionada o sistema deverá acionar a funcionalidade de submit da tela que está ativa, ou seja, a tecla <Enter> terá o mesmo efeito do clique do usuário nos botões <OK>, <Salvar>, <Gravar> e etc. Para toda tela ou campo de pesquisa, o sistema deverá ignorar a case do texto para listar os registros encontrados.

Método de entrada de dados no sistema

• Toda e qualquer alimentação de dados que o usuário fizer no sistema deverá ser convertida para CAIXA ALTA (quando necessário) assim que o foco sair do campo.

Padrões de usabilidade (botões, mensagens, layout, etc)

Botões

Rodapé

• Botões responsáveis por executar ações (exemplo: Salvar, Confirmar, Faturamento rápido, Finalizar, Emitir nota, e etc) deverão seguir o modelo do botão Salvar nas imagens abaixo.
• Botões responsáveis por abortar ações (exemplo: Cancelar) deverão seguir o modelo do botão Cancelar nas imagens abaixo.
• Botões que retornam à telas anteriores ou que retornam a tela a seu estado inicial (exemplo: Limpar, voltar e etc...) deverão seguir o modelo do botão Limpar nas imagens abaixo.

Consultas

Em abas de consulta, o botão Consultar deverá seguir o modelo do botão Salvar nas imagens abaixo. O botão Limpar deverá seguir seu respectivo modelo.

Telas de manutenção

Em telas de manutenção (exemplo: PDV, Liquidações e etc...) botões que executam ações intermediárias (exemplo:Inserir itens, Pesquisar, Filtrar, Adicionar e etc... ) deverão seguir o modelo do botão Filtrar dentre as imagens abaixo.

• 

  Botão Salvar

• 

  Botão Cancelar

• 

  Botão Limpar

• 

  Botão Filtrar

Mensagens

Toda e qualquer comunicação do sistema com o usuário deverá ser padronizada em um tipo único de mensagem. Este tipo único de mensagem deverá utilizar o componente rich notify da biblioteca RichFaces.

Este componente deverá ter as seguintes características:

• Sua aparência deverá seguir os padrões do sistema.
• Todos os botões <Cancelar> do sistema deverão, antes de abortar qualquer evento, emitir uma mensagem de confirmação ao usuário.
• Mensagens informativas:
  • O título da mensagem deverá ser “Notificação”.
  • O conteúdo da mensagem deverá informar que o sistema executou alguma ação solicitada, exemplo: “Segmento de mercado cadastrado com sucesso!”.

    Para cadastros que possuem código, o sistema deverá exibir na mensagem a informação do objeto cadastrado, exemplos: 
    “Cliente 00001247 – Divino Felix cadastrado com sucesso!”.
    “Fornecedor 00016577 – ATS Informática cadastrado com sucesso!”.
    “Transportadora 798744431 – Translap cadastrada com sucesso!”.
    “Produto 00014547 – iPhone 3GS cadastrado com sucesso!”.
    “Matéria prima 00026578 – Farinha de trigo cadastrada com sucesso!”.

• Mensagens de alerta:
  • O título da mensagem deverá ser “Atenção”.
  • A solução para que o alerta não seja exibido novamente deverá ser exibida em forma de sugestão.
  • Caso a mensagem exiba o caminho de uma determinada rotina no menu o sistema deverá estar preparado para que o caminho seja exibido de acordo com o módulo utilizado, pois os caminhos podem ser diferentes para uma mesma rotina dependendo do módulo.
  • Todas as mensagens de alerta do sistema devem descrever claramente o motivo do alerta e dar ao usuário instruções sobre como evitar que este alerta seja exibido novamente, exemplo: Alguém tenta cadastrar um usuário no sistema, mas não existe nenhum perfil de acesso cadastrado ainda. Neste caso o sistema deveria exibir uma mensagem conforme modelo abaixo.

    Para cadastrar um usuário é necessário que antes seja criado pelo menos um perfil de acesso para o mesmo.
    Sugestão: Acesse “Menu > Utilitários > Controle de Acesso > Perfil de acesso” e cadastre um perfil de acesso.

Listboxes

• Filiais: Todos os listboxes de filiais, independente da tela em que vão ser utilizados, deverão possuir as seguintes características:
  • Exibir a quantidade de 5 registros (filiais), gerando barra de rolagem vertical para os demais.
  • Para cada registro exibir a quantidade máxima de 33 caracteres. Se um determinado registro possuir mais de 33 caracteres então a partir do trigésimo caractere o sistema deverá substituir o restante por reticencias.
  • Possuir botões que possibilitem marcar e desmarcar todos os registros do listbox.
  • Possuir três colunas, sendo uma para marcar/desmarcar o registro, uma que exibirá o código e outra a descrição.
  • Filiais inativas ou filiais cujo usuário logado não possui acesso não deverão ser listadas.
  • Em telas de relatórios e consultas, a filial logada já deverá aparecer marcada ao acessar a rotina.
  • Quando houver apenas uma filial cadastrada ou apenas uma filial visível/accessível para o usuário logado, ao invés do listbox deverá ser exibido um checkbox com o nome da filial em questão já selecionado.
• Operações: Todos os listboxes de operações, independente da tela em que vão ser utilizados, deverão possuir as seguintes características:
  • Exibir a quantidade de 5 registros (operações), gerando barra de rolagem vertical para os demais.
  • Para cada registro exibir a quantidade máxima de 23 caracteres. Se um determinado registro possuir mais de 23 caracteres então a partir do vigésimo caractere o sistema deverá substituir o restante por reticencias.
  • Possuir botões que possibilitem marcar e desmarcar todos os registros do listbox.
  • Operações inativas ou operações cujo usuário logado não tem acesso não deverão ser listadas.

Campos de data/período

Os campos de data (individual ou de período), terão as seguintes características:

1. Em todas as rotinas do sistema onde forem exibidos os campos de período (data inicial e data final) os mesmos deverão ser preenchidos por padrão com o primeiro e último dia do mês corrente (com base na data de login).
2. Sempre que um período for utilizado o sistema não permitirá que data inicial seja maior que a data final.
3. O usuário poderá clicar no ícone à direita do campo e selecionar uma data no calendário.
4. Caso usuário digite uma data, o sistema deverá formatá-la automaticamente à medida que é digitada.
5. Se o usuário informar um dia, mês ou ano inválido o sistema deverá emitir um alerta com a não conformidade e limpar o campo quando o mesmo perder o foco.
6. Caso usuário informe apenas o dia e mude o foco para outro campo, o sistema deverá preencher automaticamente o mês e ano correntes (com base na data de login). Caso usuário informe o dia e mês, a mesma lógica deverá ocorrer com o ano.

Campos de valor monetário

Em todos os campos do sistema onde são manipulados valores monetários não será permitida a utilização de valore negativos. Este tratamento deverá ser realizado em cada campo, não permitindo sequer que o usuário digite o "-".

Campos desabilitados

Para todos os campos do sistema que ficarem desabilitados na tela, deverá ser justificado na documentação da rotina (wiki) o motivo pelo qual o mesmo está desabilitado. Por padrão campos que não serão habilitados/utilizados via parâmetro não deverão ficar visíveis na tela (salvo exceções).

Campos obrigatórios

Todos os campos obrigatórios do sistema deverão seguir o seguinte padrão:

• À direita do campo deverá ser exibido um asterisco (*) que indicará sua obrigatoriedade.
• Ao verificar que um ou mais campos obrigatórios não foram preenchidos, o sistema deverá destaca-los colocando a sua borda em vermelho e em seguida posicionando o foco sobre o campo de menor tab order.

Componentes que utilizam consultas ajax

Campos onde são digitados códigos que fazem consultas diretas ao banco (via ajax) para verificar a existência do código informado também deverão ser validados (campos de código e descrição de produto por exemplo), independente de serem obrigatórios ou não.

Caso código informado não seja encontrado ou não seja válido, o campo deverá ser destacado com um contorno na cor laranja e um balão deverá aparecer sobre mesmo informando que o código informado não é válido. Caso seja informado um código cujo cadastro está marcado como inativo, no balão deverá aparecer a informação de que o código informado foi desativado.

Enquanto um código válido/ativo não for informado ou enquanto o conteúdo do campo não for limpo, o contorno laranja e o balão continuarão sendo exibidos.

Campos de CPF/CNPJ não fazem consultas ao banco para validar o dado informado, porem os CPF/CNPJ informados também deverão ser validados nas condições propostas acima.

Comboboxes

1. Todos os comboboxes deverão exibir os itens de sua lista ordenados alfabeticamente ou em ordem crescente.
2. O combobox cuja lista possuir um único registro deverá exibir o mesmo já selecionado por padrão quando a tela for carregada. Caso o combobox seja dependente de outro combobox (grupo e subgrupo por exemplo), esta regra só é válida quando no combobox pai for selecionado um item que tenha no combobox filho um único registro correspondente.
3. O combobox cuja lista possuir um único item deverá exibir além do registro único um registro em branco/vazio que possibilite o usuário não selecionar a única opção existente.
4. O combobox cuja lista possuir um item que é marcado como padrão em seu cadastro, deverá apresentar o item padrão já selecionado quando a tela for carregada.
5. O comboboxes cuja lista possui mais de um item e/ou cuja lista não possui nenhum item marcado como padrão em seu cadastro deverão ser apresentados em tela sem nenhum item previamente selecionado, independente de sua informação ser obrigatória ou não.
6. Com a lista do combobox fechada e com um item cuja descrição foi abreviada selecionado, ao posicionar o mouse sobre o combobox deverá ser exibido um hint com a descrição completa deste item.
7. Quando a lista do combobox for aberta ela deverá ter sua largura ajustada (somente a lista) ao item de maior descrição, ou seja, não haverão cortes nem abreviações nas descrições dos itens enquanto a lista estiver aberta.
8. Quando se tratar de um combobox de filiais (tela de login por exemplo), na descrição da filial deverá ser concatenado seu código.
9. Em comboboxes que são conjugados com edit´s, à medida que um código é digitado no edit o respectivo item deve ser selecionado na lista do combobox (enquanto fechada). Os códigos digitados nos edit´s devem ser automaticamente completados com zeros à esquerda quando necessário.
10. Itens que estão inativos ou itens cujo usuário logado não tem acesso não deverão ser listados nos comboboxes.
11. Todos os comboboxes enquanto vazios, deverão ocupar o espaço equivalente à quantidade de caracteres a ser exibida conforme regras abaixo.

Operações (Entrada, saída, liquidação e etc), BANCOS, CONDIÇÃO DE PAGAMENTO.

Por padrão os comboboxes deverão, independente da rotina onde são utilizados, exibir a quantidade máxima de 30 caracteres (incluindo espaços) enquanto sua lista está fechada. Caso a descrição de um determinado item selecionado ultrapasse 30 caracteres, a partir do caractere 27 o restante da descrição deverá ser substituída por reticencias (...).

Planos (telefonia)

Por padrão os comboboxes que exibem planos de venda de telefonia deverão, independente da rotina onde são utilizados, exibir a quantidade máxima de 40 caracteres (incluindo espaços) enquanto sua lista está fechada. Caso a descrição de um determinado plano selecionado ultrapasse 40 caracteres, a partir do caractere 37 o restante da descrição deverá ser substituído por reticencias (...).

Cidades

Por padrão os comboboxes que exibem cidades deverão, independente da rotina onde são utilizados, exibir a quantidade máxima de 40 caracteres (incluindo espaços) enquanto sua lista está fechada. Caso a descrição de uma determinada cidade selecionada ultrapasse 40 caracteres, a partir do caractere 37 o restante da descrição deverá ser substituído por reticencias (...).

O combobox de cidades deverá ser preenchido somente após uma UF ser selecionada. Sendo assim serão listadas somente as cidades que possuem vinculo com a UF em questão.

Perfil de imposto

Por padrão os comboboxes deverão, independente da rotina onde são utilizados, exibir a quantidade máxima de caracteres que ocupem a largura máxima de 193px (do combobox) enquanto sua lista está fechada. Caso o limite de caracteres informados ultrapassem a largura de 193px, os últimos 3 caracteres da descrição do item selecionado (com a lista do combo fechada) deverá ser substituída por reticencias (...). Excepcionalmente, o analista poderá solicitar que a largura do combobox em questão seja alterada, mas mantendo a regra acima.

Controle de acesso

Por padrão, as funcionalidades não permitidas para um determinado usuário não poderão ficar visíveis para o mesmo, exemplo:

• Se um usuário não possui acesso a uma determinada rotina, estão não deverá sequer estar accessível no menu.
• Se um usuário possui acesso a uma determinada rotina, mas com restrições, o sistema deverá tratar cada restrição pontualmente, exemplo:
  • Se o usuário não pode incluir, então os botões/funcionalidades de inclusão das rotinas não poderão ser visíveis para o mesmo.
  • Se o usuário não pode alterar, então os botões/funcionalidades de alteração das rotinas não poderão ser visíveis para o mesmo.
  • Se o usuário não pode excluir, então os botões/funcionalidades de exclusão das rotinas não poderão ser visíveis para o mesmo.

A permissão “Consulta/Acesso” a uma determinada rotina também implica se a mesma estará visível ou não no menu do sistema para determinado usuário (ver regra de negócio RN01 do caso de uso 51).

As sub-rotinas de parâmetros e configurações só poderão ser accessíveis para usuários que possuem marcada em seu cadastro a opção “Acesso total”.

Filiais cujo usuário não possui acesso não deverão estar visíveis em telas onde é possível marcar/desmarcar filiais, como as telas de relatórios e consultas por exemplo. Só devem ser listadas as filiais que o usuário logado tem permissão para acessar.

Se o usuário possuir acesso total a uma determinada rotina então todas as funcionalidades deverão estar disponíveis.

Para acessar as telas de movimento como “Liquidação de documento a pagar” e “Estorno de liquidação a pagar” o usuário deverá ter marcado pelo menos uma permissão de acesso na rotina, lembrando que o sistema deverá marcar automaticamente a opção “Consulta/Acesso” caso qualquer outra opção de acesso seja ativada.

Campos de CPF/CNPJ

Os campos onde são digitados CPF/CNPJ deverão realizar as validações quanto aos dados informados quando o foco sair do campo. Se alguma não conformidade for encontrada o sistema deverá:

• Emitir uma mensagem de alerta ao usuário (dentro dos padrões deste documento).
• Manter o foco sobre o campo em questão.
• Circular o campo de vermelho.

Localidades/Pessoa

Nas rotinas de cadastro de pessoas (cliente, fornecedor e etc) o sistema deverá controlar a localização com os possíveis fluxos:

Fluxo principal:

1. Usuário informa o CEP da pessoa.
2. Sistema verifica se o CEP informado está cadastrado.
3. Se o CEP informado for válido e estiver cadastrado serão preenchidos automaticamente logradouro, bairro, país, UF e cidade.
4. Se o CEP for válido, mas não estiver cadastrado, quando o foco sair do campo CEP o sistema não preencherá os campos logradouro, bairro, país, UF e cidade e o cadastro procede normalmente.

Fluxo alternativo:

1. Usuário informa país e UF.
2. Sistema preenche o combobox de cidades com as cidades vinculadas à UF informada.
3. Usuário seleciona uma cidade e em seguida informa manualmente logradouro, número, complemento, bairro, país, UF e CEP.
4. Quando o CEP for informado o sistema verifica que uma cidade já está informada e faz as seguintes validações:
5. Se o CEP informado for válido e estiver cadastrado será verificado se mesmo pertence à cidade selecionada. Se sim o cadastro procede normalmente. Se não, o sistema emite uma mensagem alertando que o CEP digitado não pertence à cidade selecionada, circula o campo CEP de vermelho e mantem o foco sobre o mesmo.
6. Se o CEP informado for válido, mas não estiver cadastrado, o sistema procede com o cadastro normalmente utilizando os dados de localidade informados manualmente.

Para dados informados manualmente o ideal é que:

1. Seja informado um país.
2. O combobox de UF seja preenchido de acordo com o país selecionado.
3. O combobox de cidades seja preenchido de acordo com país e UF selecionados.

Layout e diagramação

Nomes de campos, componentes e etc

Os nomes, palavras ou frases deverão ser sempre iniciados por letras maiúsculas e terminarem com letra minúscula. Não poderão haver letras maiúsculas no meio do nome, palavra ou frase a não ser em caso de nomes próprios.

Exemplo errado: “Cadastro de Situação Tributária”

Exemplo correto: “Cadastro de situação tributária”

Pesquisas

Pesquisas em geral Em telas onde há filtro de período, caso o mesmo seja deixado em branco e a pesquisa/consulta seja acionada, o sistema deverá preenchê-los automaticamente com datas inicial e final que compreendam o mês corrente e considerar estes dados na busca.

Ao informar filtros para realizar pesquisas e consultas de qualquer tipo o sistema deverá ignorar a case dos mesmos, ou seja, independente se o filtro foi informado em minúsculo ou maiúsculo o sistema buscará e listará todos os registros encontrados e correspondentes.

Pesquisa de produtos Ao pesquisar produtos por código ou descrição o sistema deverá realizar a busca dos mesmos considerando o código, referência e referência de fabricante. À medida que o usuário digita a informação no campo de descrição o sistema deverá listar os produtos que possuem código, referência ou referência de fabricantes equivalentes ao dado informado. Se para o dado informado no campo de código houver mais de um produto cujo código, referência ou referência de fabricante sejam equivalentes, estes deverão ser listados para que o usuário escolha o produto desejado a exemplo de como ocorre no campo de descrição.

O sistema deverá buscar os produtos correspondentes ignorando a case do dado digitado, ou seja, serão listadas as relevâncias independente se o usuário digitou em maiúsculo ou minúsculo.

Foco

Por padrão o foco deverá navegar entre os componentes da tela da esquerda para a direita e de cima para baixo salvo exceções. Telas que necessitarem de uma ordem de foco específica deverão ser discriminadas e documentadas pelo analista.

O foco não deverá passar sobre ícones (à frente do nome das rotinas e etc), atalhos (para pesquisas, cadastros e etc) e campos desabilitados.

Ao passar por componentes diferentes de campos e botões (exemplo: checkboxes), o foco deverá ser claramente perceptível e manipulado pelo usuário.

Em nenhum momento o foco poderá sair do sistema e passar por campos e botões do navegador.

Funções de inclusão/alteração/exclusão

As funcionalidades em questão deverão ter o seguinte comportamento:

Inclusão: Sempre que uma rotina que possuir funcionalidade de inclusão for acessada será apresentado ao usuário um grid com os registros já existentes.

O usuário poderá, a qualquer momento, acionar o botão de inclusão (cujo nome varia de rotina para rotina). Uma vez que este botão foi acionado será exibida a tela de cadastro da rotina.

Após o usuário inserir os dados do registro que deseja incluir e acionar o botão <Salvar>, o sistema emitirá uma mensagem notificando-o que o registro foi gravado com sucesso. A mensagem será exibida por um determinado tempo e desaparecerá automaticamente.

Após a gravação do registro, o sistema permanecerá na tela de cadastro.

Alteração:Poderá ser feita de duas maneiras:

1. No grid da tela inicial da rotina o usuário aciona, para um determinado registro, o botão de alteração que é apresentado no grid. Logo em seguida o sistema exibe a tela de cadastro já com os dados do registro em questão preenchidos e habilitados para serem alterados (salvo exceções). Após o usuário alterar os dados e clicar no botão <Salvar> o sistema retornará a tela inicial da rotina onde é exibido o grid com os registros existentes. Nenhuma mensagem será exibida.
2. No grid da tela inicial o usuário aciona, para um determinado registro, o botão de consulta que é apresentado no grid. Logo em seguida o sistema exibe a tela de cadastro já com os dados do registro em questão preenchidos e desabilitados (somente leitura). Na sequência usuário aciona o botão <Alterar> que é exibido na tela de cadastro habilitando os campos da tela para alteração. Após o usuário alterar os dados e clicar no botão <Salvar> o sistema retornará a tela inicial da rotina onde é exibido o grid com os registros existentes. Nenhuma mensagem será exibida.

Exclusão: A exemplo da alteração, poderá ocorrer de duas maneiras:

1. No grid da tela inicial o usuário aciona, para um determinado registro, o botão de exclusão que é apresentado no grid. Na sequência o sistema emite uma mensagem de confirmação perguntando ao usuário se ele deseja realmente excluir o registro. Caso usuário clique em <Sim> na mensagem e caso registro possa ser excluído, o sistema excluirá permanentemente o registro e atualizará o grid.
2. No grid da tela inicial o usuário aciona, para um determinado registro, o botão de consulta que é apresentado no grid. Na sequencia o sistema exibe a tela de cadastro com os dados do registro em questão preenchidos e desabilitados (somente leitura). Na tela de cadastro o usuário aciona o botão <Excluir>. Na sequencia o sistema emite uma mensagem de confirmação perguntando ao usuário se ele deseja realmente excluir o registro. Caso usuário clique em <Sim> na mensagem e caso registro possa ser excluído, o sistema o excluirá permanentemente e retornará ao grid da tela inicial. Tanto no primeiro quanto no segundo caso, caso usuário clique em <Não> na mensagem de confirmação o movimento de exclusão deverá ser abortado.

Registros ativos/inativos e bloqueados

Em todos os cadastros do sistema deverá existir a opção Ativo que permitirá marcar um determinado registro como ativo ou não no sistema. Em alguns cadastros em específico poderá existir a opção Bloqueado, como produto acabado e fornecedor por exemplo. O sistema deverá tratar os parâmetros Ativo e Bloqueado conforme descrito abaixo:

Consultas e relatórios

• Registro inativo: Um registro inativo poderá ser utilizado normalmente, mas assim que for informado, o sistema deverá emitir uma mensagem ao usuário informando que o mesmo poderá ser utilizado, mas está marcado como inativo em seu cadastro.
• Registro bloqueado: Um registro bloqueado poderá ser utilizado normalmente, mas assim que for informado, o sistema deverá emitir uma mensagem ao usuário informando que o mesmo poderá ser utilizado, mas está marcado como bloqueado em seu cadastro.

Demais rotinas

• Registro inativo
  • Caso um registro inativo seja informado através de seu código o sistema deverá proceder conforme item 3.5 - Componentes que utilizam consultas ajax desta página.
  • Caso um registro inativo seja informado através de sua descrição, o sistema deverá proceder como se o mesmo não existisse.
• Registro bloqueado: Caso um registro bloqueado seja informado através de seu código ou descrição o sistema deverá preencher os dados do mesmo em seu respectivo campo, emitir ao usuário uma mensagem de alerta informando que o registro em questão está bloqueado para uso e manter o foco no campo. Caso usuário retire o foco do campo com <Tab> ou clicando em outro campo a mensagem não será exibida novamente, mas quando botões do tipo <OK>, <Salvar>, <Adicionar> e etc forem acionados esta validação deverá ser feita novamente e impedir que a movimentação seja concluída.

Teclas de atalho

Para todas as rotinas do sistema (salvo exceções) determinadas funcionalidades do sistema deverão ser acessíveis para o usuário através de teclas de atalho conforme descrito abaixo:

Sempre que o usuário manter pressionada a tecla Alt o sistema deverá exibir junto da descrição funcionalidade/botão a sua respectiva tecla de atalho.

Atalhos para cadastros

Em todas as telas do sistema em que existir possibilidade de selecionar algum item que possua seu próprio cadastro, no componente/campo de seleção/informação do item em questão deverá haver um ícone que quando acionado abrirá o cadastro do mesmo em uma nova aba.

    - Em telas de consulta e relatório o ícone que abre a nova aba não é necessário.
    - Ao abrir a nova aba o sistema deverá respeitar o controle de acesso, verificando as permissões 
      do usuário logado quanto à rotina exibida na nova aba.
    - Para rotinas de cadastros, todos os campos que possuírem cadastro deverão apresentar o atalho.
    - Para rotinas de movimento, o analista da tarefa deverá definir quais campos apresentarão atalho.

Impressão de relatórios e consultas

Por padrão a impressão dos dados de relatórios e consultas deverão estar disponíveis nos formatos DOC, PDF, Excel e Impressão direta.

Os relatórios no formato Excel deverão ser gerados a partir de um template base com as seguintes características:

1. Logomarca da filial que emitiu o relatório no cabeçalho à esquerda.
2. Nome do relatório centralizado no cabeçalho.
3. Abaixo do nome do relatório deverão ser listados a data e hora de emissão, usuário, sistema e versão do sistema.
4. À direita do cabeçalho deverá ser exibida a logomarca da ATS.
5. O cabeçalho e os títulos das colunas deverão ser fixos, permitindo com que a barra de rolagem movimente apenas os dados.
6. Os filtros utilizados serão listados em uma segunda aba.
7. Na aba onde são exibidos os dados, as linhas deverão ser zebradas para facilitar o entendimento.

Baixe aqui o template base para o relatório em Excel.

Tipos de dados do sistema (tela e banco de dados)

Sempre que determinados campos forem utilizados nas telas do sistema eles deverão respeitar mascaras, formatações e ter devidamente criados no banco de dados os respectivos campos conforme tabela abaixo: