Histórico da Página

Informações Gerais

Objetivo

 Permitir ao usuário maior agilidade na alocação de atendentes, lançamentos das manutenções de agenda e consulta das situações no dia ou período.

Definição da Regra de Negócio

Processo de movimentação ágil será representado por um conjuntos de funções e ações a partir de uma janela para consulta de agendas de um atendente em um determinado dia. A janela de consulta será conforme o protótipo 01.

 O objetivo é identificar o status do dia do funcionário e as alocações existentes para permitir ou controlar os futuros lançamentos, como exemplo falta, reciclagem, folga, entre outros.

 Outras funcionalidades serão desenvolvidas para proporcionar uma visão completa das alocações e postos vagos. Essas funcionalidades são: consulta de postos vagos, consulta de agendas (período), visualizar controle de dias de direito (férias programadas), visualizar ausências (afastamentos como exemplo licença não remunerada e INSS) e visualizar o cadastro de atendente.

Outro recurso que será oferecido é uma interface para inclusão de reforço sem a necessidade de acessar diretamente o orçamento de serviços e criar o item manualmente. Para tanto será oferecido no menu a opção Adicionar Reforço e vinculado a esta opção uma interface onde será possível definir as informações do reforço para criar o posto para alocação dos reforços.

 A seguir a lista de atividades possíveis a partir das novas interfaces e rotinas de consulta.

Movimentação (função TECA335)

Tem o objetivo de fornecer ao usuário a identificação da situação do atendente no dia e baseado nessa informação, se há a possibilidade de movimentá-lo entre postos ou executar a alocação em posto vago, fazer um lançamento de folga, entre outras operações.

A janela para esta interface é o protótipo 01. Nela o usuário irá digitar ou selecionar a seguintes informações básicas: data da movimentação, filial do atendente e código do atendente.

Ao digitar estes dados o status do atendente no dia será carregado, este status pode ser: Desligado, Férias, Afastamento (que inclui licenças de quaisquer tipos como INSS, maternidade e não remunerada por exemplo), Suspensão, Reciclagem, Curso, Falta, Folga, Dia de Trabalho.

Após identificar o status do atendente as opções de consulta e respectivas ações disponíveis são:

1. Atendente Restrito no RH por férias
   1. Visualizar a rotina de Controle de Dias de Direito (acionando a visualização da função GPEA050 do módulo de Recursos Humanos, vide protótipo 04).
2. Atendente Restrito no RH por afastamento
   
   1. Visualizar a rotina de Ausências (acionando a visualização da função GPEA240 do módulo de Recursos Humanos, vide protótipo 05)
3. Atendente Suspenso
   1. Sem ação ao menos que a disciplina encerre ou seja desfeita.
4. Atendente em Folga ou Falta
   
   1. Atendente disponível para sofrer alguma movimentação.
5. Atendente em dia de Trabalho – alocado em posto
   1. Atendente disponível para sofrer alguma manutenção ou movimentação.
6. Atendente em dia de Trabalho – reserva
   1. Atendente disponível para sofrer alguma movimentação ou manutenção.
7. Atendente em Reciclagem ou Curso
   
   1. Atendente será bloqueado para a movimentação. A movimentação só poderá ser feita depois que for realizada a exclusão ou alteração do período do Curso ou Reciclagem.

O botão outras ações terá as seguintes opções:

                Carregar agendas (também disponível através da tecla de função <F5>), esta ação irá preencher as agendas do dia escolhido para o atendente digitado.

                Movimentar (disponível através da tecla de função <F6>), ação descrita em detalhes a seguir.

                Consulta de Agendas (período), ação descrita em detalhes a seguir.

                Consulta de Posto Vago, ação descrita em detalhes a seguir.

                Visualizar Cadastro do Atendente, ação descrita em detalhes a seguir.

                Visualizar Controle de Dias de Direito, ação descrita em detalhes a seguir.

                Visualizar Ausências, ação descrita em detalhes a seguir.

                Editar Parâmetros, ação descrita em detalhes a seguir.

Opção movimentar (função TECA336)

Esta será a rotina responsável por executar a alocação dos atendentes nos postos para torná-los efetivos, folguistas de postos ou executar a cobertura em um determinado dia.

A interface deverá ser conforme o protótipo 02 e terá seu comportamento definido a partir do código de situação inserido. Cada código de situação irá liberar um conjunto de informação para ser digitada pelo usuário, por exemplo quando digitado o código para Atraso somente a data e horário inicial da agenda poderá ser editado pelo usuário ou quando inserido código para Implantar Reforço somente as informações de posto de reforço serão aceitas para informação da alocação onde o atendente irá atuar.

Além dos pontos de entrada padrões das rotinas MVC, nesta rotina será liberado outro no seguinte momento:

AT335WHE: Avaliação dos campos a serem liberados para edição conforme a situação digitada pelo usuário. Deverá ser chamado dentro da função que fará a avaliação e liberação/bloqueio de todos os campos (deve ser chamado dentro da função interna At335when).

A interface foi dividida por conjuntos de informação e as categorias são:

Ação: onde o usuário irá digitar o código da situação a ser aplicada para o atendente.

A descrição da situação será carregada conforme o preenchimento e não poderá ser editada.

A quantidade de dias só poderá ser editável quando a situação corresponder a Curso ou Reciclagem. Este campo irá disparar aviso ao usuário quando um valor superior a 5 for inserido.

O campo com a data final não será editável pelo usuário e o preenchimento acontecerá pelo sistema considerando a data da movimentação inserida pelo usuário na janela anterior e a quantidade de dias preenchido no campo anterior.

Cobertura: onde o usuário irá digitar/selecionar o atendente que irá realizar a cobertura do horário ou posto no dia.

Este conjunto de informações só ficará disponível quando alguma situação que indique a ausência do atendente alocado originalmente na agenda seja utilizado. Exemplo dessas situações são: Falta, Saída Antecipada e Folga.

Os campos filial e código do substituto poderão ser preenchidos manualmente pelo usuário ou o conteúdo poderá ser selecionado pela interface de seleção de atendente substituto (protótipo 06). A janela ficará disponível na opção outras ações da janela para movimentar (função TECA560) e na ação de F3 do campo código do substituto.

O nome do atendente substituto será preenchido pelo sistema.

Item Alocação: conjunto de informações para identificar qual o item da escala e agrupamento o atendente está ou irá atender. Este conjunto de informação só ficará editável quando uma situação de implantação for utilizada ou uma folga trabalhada for ser lançada.

Os campos chave neste grupo de informações são: item RH Alocação, item escala e grupo. Estas informações são utilizadas para identificar exatamente o item de alocação e contar a quantidade de pessoas alocadas no posto para cada dia.

As demais informações serão utilizadas para filtrar os itens de escalas possíveis para seleção, portanto os campos cliente e local não serão informações obrigatórias, mas poderão ser preenchidas para otimizar a busca dos itens de escala para alocação.

A consulta padrão do campo item escala (pode ser acionada via F3) deverá ser semelhante ao protótipo 11, mas só precisará ser utilizada quando o campo Item RH Alocação for digitado manualmente.

Rota Almocista: campo em que o usuário irá digitar o código da rota de almocista.

Este conjunto de informação só ficará disponível quando o usuário selecionar a situação Implantar Almocista, por exemplo.

A consulta padrão irá exibir todas as rotas ativas e indicará quais estão com atendentes vinculados e quais não possuem atendentes associados. A janela da consulta deverá ser conforme o protótipo 07.

Motivo: conjunto de informação para registrar o motivo da alteração de situação do atendente original.

O campo de motivo ficará habilitado após o preenchimento da situação.

Os motivos são definidos previamente e resumidos em uma lista. Todos os motivos possíveis são: Posto Vago, Treinamento, Cortesia, Reforço, Serviço Extra, Troca de funcionário, Cobertura de Falta, Cobertura de Férias, Cobertura de Reciclagem, Cobertura de Folga, Cobertura de Suspensão, Cobertura de Saída Antecipada, Cobertura de Atraso, Cob. de Licença não Remunerada, Autorização Coordenação, Autorização Gerência, Extra Faturado, SDF e Dobra.

Existirá validação para não permitir motivos em situação que não tenham sentido, por exemplo situação Falta e motivo Extra Faturado.

Os motivos serão gravados no sistema assim como os demais dados da movimentação para consultas e futuros relatórios.

Os motivos Autorização Coordenação e Autorização Gerência serão permitidos para seleção independente da situação utilizada para movimentação do atendente.

Informações Agenda: onde o usuário irá consulta ou alterar as informações dos horários das agendas.

Será exibido no formato de grid para que tenha todas as agendas do dia de um atendente. A alteração ficará habilitada quando for acionada alguma manutenção que envolva a alteração de horários, como exemplo Atraso e Saída Antecipada.

Cada situação terá o seu conjunto de informações que serão habilitadas para edição, em função deste comportamento a seguir foi realizada uma lista com as ações esperadas do sistema para cada situação escolhida.

Implantar Efetivo

Grupos de informação habilitados: Item Alocação e Motivo.

Qualquer item de escala que não tenha efetivo associado poderá ser selecionado.

Os motivos que poderão ser selecionados são: Posto Vago e Cobertura de Férias.

Implantar Folguista

Grupos de informação habilitados: Item Alocação e Motivo.

Qualquer item de escala onde tenha configuração de folguista e não tenha folguista associado.

Os motivos possíveis de seleção são: Posto Vago e Cobertura de Férias.

Implantar Almocista

Grupos de informação habilitados: Rota Almocista e Motivo.

Poderão ser selecionadas todas as rotas configuradas para a filial do atendente que não tenham atendentes já definidos para realizá-las.

Os motivos que ficarão disponíveis para seleção são: Posto Vago e Cobertura de Férias.

Falta

Grupos de informação habilitados: Cobertura e Motivo.

A cobertura será habilitada para seleção de atendentes que estejam na reserva, folga ou sejam efetivos em rotas de almoço no dia de lançamento de falta.

O motivo que ficará disponível é: Cobertura de Falta.

Retorno de Falta

Grupo de informação habilitado: nenhum.

Esta situação irá retornar o atendente para a agenda que ele “deveria” atender, revertendo a situação de falta gerada no dia, caso ele esteja em reserva voltará para a reserva.

Folga

Grupo de informação habilitado: Cobertura e Motivo.

Os atendentes disponíveis para seleção serão os que estão associados em reserva, folga ou sejam efetivos em rotas de almocistas.

O motivo a ser permitido neste caso é: Cobertura de Folga.

Folga Trabalhada

Grupos de informação habilitados: Item Alocação e Motivo.

Os itens de escala que ficarão disponíveis para alocação são os “postos vagos”, ou seja, aqueles itens de escala que não estão sendo atendidos em sua totalidade (como por exemplo, 2 pessoas alocadas sendo que por contrato deveriam ser 3).

Os motivos disponíveis com esta situação são: Cobertura de Falta, Cobertura de Férias, Cobertura de Reciclagem, Cobertura de Folga, Cobertura de Suspensão, Cobertura de Saída Antecipada, Cob. de Licença não Remunerada, Folga Convocação e Dobra.

Folga Convocação

Mesmo comportamento que a situação Folga Trabalhada.

Saída Antecipada

Grupos de informação habilitados: Informações Agenda, Cobertura e Motivo.

O campo de hora final ficará habilitado para edição e nos casos em que existir mais que uma agenda no dia, somente uma das agendas poderá ser alterada.

Motivo permitido para seleção: Cobertura de Saída Antecipada.

Caso seja selecionado um atendente para cobertura ele irá assumir o tempo restante de agenda e o horário inicial da agenda deverá ser igual ao horário final do atendente substituído.

Atraso

Grupos de informação habilitados: Informações Agenda, Cobertura e Motivo.

O campo de hora inicial ficará habilitado para edição e nos casos em que existir mais que uma agenda no dia, somente uma das agendas poderá ser alterada.

Nenhum outro motivo além das Autorizações de Gerência e Coordenação serão permitidos.

Caso seja selecionado um atendente substituto ele irá atender somente a quantidade de horas de atraso do atendente original e a hora final não poderá ser superior ao novo valor de hora inicial do atendente original.

Hora Extra

Grupos de informação habilitados: Informações Agenda e Motivo.

Com esta situação as informações das agendas que podem sofrer alteração serão a hora inicial e final de uma única agenda do dia.

O motivo permitido para definição é: Extra Faturado. Importante ressaltar que este motivo não será utilizado para identificação do que deve ou não ser faturado do cliente. Para esta classificação o sistema utiliza o Tipo de Alocação que é incluído na agenda do atendente.

Implantar Reforço

Grupos de informação habilitados: Item Alocação e Motivo.

Os itens de alocação disponíveis para seleção quando esta situação for acionada serão aqueles que forem criados para reforço.

Os motivos permitidos para associação são: Reforço.

Implantar Serviço Extra

Grupos de informação habilitados: Item Alocação e Motivo.

Os itens de alocação que ficarão disponíveis para seleção serão os criados como item extra no contrato e que são faturados via pedido de venda sem o vínculo com a medição do contrato.

Os motivos permitidos para uso nesta situação são: Serviço Extra.

Implantar Cortesia

Grupos de informação habilitados: Item Alocação e Motivo.

Os itens de alocação que ficarão disponíveis para seleção serão os criados como item extra e não possuem definido valor de cobrança.

Os motivos permitidos para este caso serão: Cortesia.

Reciclagem

Grupo de informação habilitado: Ação.

Somente o campo quantidade de dias ficará disponível para edição. Caso o usuário insira um valor maior que 5 será emitido aviso sobre a quantidade de dias de ausência ser maior que 5. O valor limite será considerado 5 em função do tempo de duração “padrão” da reciclagem e cursos.

Curso

Mesmo comportamento que a Reciclagem.

Recolhimento

Grupos de informação habilitados: Cobertura e Motivo.

O atendente substituto só poderá ser um atendente de reserva ou almocista.

Somente os motivos de autorização (coordenação e gerência) serão permitidos, mas o campo não será de preenchimento obrigatório.

O atendente recolhido deverá ser adicionado ao posto de reserva padrão configurado para a filial. Vide mais detalhes rotina para configuração de parâmetros.

Troca de Funcionário

Grupos de informação habilitados: Cobertura e Motivo.

O atendente substituto só poderá ser um atendente efetivo de outro posto. A troca irá corresponder a uma troca entre os efetivos de dois postos que daquele dia da movimentação em diante irão assumir estes novos postos para atender.

O motivo permitido para seleção será: Troca de Funcionário.

A consulta padrão/lookup do campo Item RH Alocação será específica e deverá considerar as informações do perfil do atendente (função, turno, sequência de turno e cargo) e o conteúdo dos campos código cliente e local para filtrar os registros que serão apresentados, o filtro deve acontecer para otimizar a busca de informações pelo usuário. A interface da consulta deverá ser conforme o protótipo 10. O conteúdo no campo Item Escala será preenchido conforme o item selecionado na consulta. Para as situações que o usuário digitar o valor no campo Item RH Contrato (não acontecendo pela consulta) será necessário exibir uma janela para a seleção do item da escala que o atendente ficará alocado (vide protótipo 11). O item da escala corresponde ao turno e sequência de trabalho que o atendente deve praticar durante os dias naquela escala, por isso a obrigatoriedade da escolha/seleção.

Importante ressaltar que todas as alterações que exigirem a geração de agendas terá ao final uma pergunta para que o usuário selecione o Tipo de Alocação que será associado a(s) essa(s) nova(s) agenda(s), a janela sera conforme o protótipo 12. Quando acontecer a geração de uma agenda para substituição (cobertura) caso o usuário selecione algum tipo de alocação que tenha configuração de faturamento diferente da agenda original, ele será questionado duas vezes sobre a mudança do faturamento da agenda. As informações adicionais sobre o tipo de alocação está no tópico a seguir.

Tipo de Alocação

O cadastro do tipo de alocação irá contar com mais um campo “Cobra Alocação?” que irá determinar quais alocações e agendas devem ser consideradas para cobrança ou não.

Os tipos padrões serão alterados para que o campo seja preenchido com a configuração de cobrança adequada.

Um novo tipo será criado código igual a 008 e descrição como “Cobertura Não Cobrada”. O objetivo é ter um tipo padrão que possa ser utilizado na geração de agendas na substituição que mantenha o conceito de cobrança dos tipos de alocação Cortesia e Excedente (que não cobram alocação).

Perfil de Alocação

O perfil de alocação irá determinar quais informações serão utilizadas do atendente para filtro dos postos para alocação, portanto estas informações deverão ser carregadas quando o botão movimentar for acionado (ou a opção <F6>).

O perfil de alocação do atendente deve ser composto pelas informações que podem ser preenchidas no orçamento de serviços para o item de recursos humanos que são: função, turno, sequência de turno e cargo. A interface deverá ser conforme o protótipo 03 e poderá ser visualizada/editada a partir da janela “movimentar” dentro do botão outras ações.

Por padrão somente a função deve vir ativada. Uma situação especial é caso o usuário na configuração do perfil desative a opção de turno mas mantenha ativa a opção da sequência, nesta situação será necessário não utilizar a sequência quando os postos forem filtrados, pois a sequência é dependente do turno e não possui valor sem que o turno também esteja ativo.

Consulta de agendas (período)

Na janela inicial da movimentação do atendente ficará disponível esta ação para visualizar as agendas realizadas ou programadas para um atendentes. Ficará disponível a partir do botão outras ações.

A opção ficará na janela inicial da consulta para movimentação (protótipo 01) e irá exibir um parâmetro para as opções de: data inicial e data final. As informações de filial e código do atendente serão utilizadas da janela anterior para a seleção dos dados.

A interface da consulta será conforme o protótipo 08.

Consulta de posto vago

O relatório ficará disponível a partir do menu de relatórios em Relatórios / Alocação / Posto Vago. Uma chamada para este relatório será adicionada a janela inicial de movimentação dentro do botão Outra Ações.

A organização das informações no relatório deverá ser conforme o protótipo 13.

Os parâmetros para este relatório serão:

1. Data, quando o relatório for chamado via janela de movimentação este campo será preenchido com a data preenchida na janela para movimentar e consultar.
2. Cliente De.
3. Loja De.
4. Cliente Até.
5. Loja Até.
6. Local De.
7. Local Até.
8. Contrato De.
9. Contrato Até.
10. Funcao.

Visualizar cadastro de atendente

A opção ficará dentro do botão Outras Ações na janela inicial de movimentação. A ação será exibir no formato de visualização o cadastro do atendente escolhido para movimentação, caso a filial e código do atendente ainda não tenha sido digitada uma mensagem exigindo o preenchimento antes do acionamento do botão/ação será exibida no sistema.

A janela de visualização do cadastro de atendente é o protótipo 14.

Visualizar controles de dias de direito (programação de férias)

A opção ficará dentro do botão Outras Ações na janela inicial de movimentação. A ação será exibir o cadastro de controle dos dias de direito para visualização pelo usuário. O conteúdo a ser exibido é o do atendente escolhido para movimentação, caso o campo filial e atendente ainda não tenham sido preenchidos uma mensagem sobre a obrigação do preenchimento para acionamento da visualização será exibida no sistema.

A interface para visualização das informações das programções de férias dos funcionários será conforme o protótipo 04.

Visualizar ausências (afastamentos)

A opção ficará dentro do botão Outras Ações na janela inicial de movimentação. A ação será exibir o cadastro de ausências do módulo do RH para visualização pelo usuário. O conteúdo a ser exibido é o do atendente escolhido para movimentação, caso o campo filial e atendente ainda não tenham sido preenchidos uma mensagem sobre a obrigação do preenchimento para acionamento da visualização será exibida no sistema.

A interface para visualização das informações das ausências dos funcionários será conforme o protótipo 05.

Consulta de horários realizados x planejados/vendidos

A opção ficará disponível dentro do botão Outras Ações e acionará a rotina relatório Escalas x Cliente e Contrato GCT (função de menu TECR610). O relatório tem o formato apresentado no protótipo 15.

Adicionar reforço - TECA740G

A rotina será a responsável por criar novos itens para alocação.

Estes itens de alocação estarão vinculados a itens originais de contrato mas terão sua cobrança realizada por fora do contrato via pedido de venda (assim como acontece com os itens extras) e serão caracterizados como reforços dos itens originais. A diferença entre os itens extras e o reforço será que os itens extras serão adicionados utilizando a rotina de orçamento de serviços como já é realizado no sistema, já os reforços serão adicionados por uma nova rotina (TECA740G) que além de adicionar vai associar o reforço a um item de RH do contrato.

Nesta nova rotina o usuário não fará a definição do valor e irá preencher somente algumas informações, como exemplo na adição de um reforço o item de rh que tenha a configuração a seguir:

Código item RH [050], Função [Aux. Limpeza], Escala [6x1 Manhã], valor [100/h], valor reforço [150/h] e Código RH Reforço [ ]

, as informações serão carregadas para o reforço assim:

Código item RH [200], Função [Aux. Limpeza], Escala [6x1 Manhã], valor [150/h], valor reforço [0/h] e Código RH Original  [050].

Com esta organização torna possível identificar de qual item original do contrato o reforço foi exigido e poderá servir para futuros relatórios e consultas.

O processo para incluir a solicitação de reforço será um pergunte com filtros para cliente, local e contrato, a janela conforme o protótipo 17 para seleção do item que receberá o reforço e a última janela conforme o protótipo 16 para finalizar o preenchimento das informações do reforço. As regras para preenchimento são:

- Os campos do conjunto de informação “Cópia do Original” não poderão ser alterados, portanto os dados de função, cargo, calendário e o valor a ser cobrado pelo reforço serão herdados do item original. O valor a ser utilizado será do campo “valor reforço” do item original que será preenchido na formação do Orçamento de Serviços para o Contrato.

- O Turno/Sequência ou Escala poderão ser editável pelo usuário e poderá ser definido algum dos dois para o reforço. A definição de um turno ou escala diferente do original irá emitir um alerta avisando sobre a ocorrência e se o usuário deseja prosseguir.  Este aviso será emitido para alertar ao usuário que está usando uma informação não inclusa na definição de valor do item original e que poderá trazer custo maior.

- Outra informação do reforço a ser definida é o período e dias de execução. Será permitida uma configuração avançada onde o usuário poderá indicar quais dias específicos da semana que o reforço irá acontecer (por exemplo todas segundas e terças, todos os finais de semana, somente às sextas) ou então se acontecerá todos os dias do período. Estas informações serão combinadas com o turno/escala do reforço para montar os dias de trabalho que o posto de reforço terá dentro do período. O período de execução do reforço poderá ser com fim determinado ou não, portanto a data final não deve ser um campo de preenchimento obrigatório.

Configuração de parâmetros

Esta janela será apresentada sempre que não for identificada movimentação de atendentes através da nova rotina de movimentação. A interface será conforme o protótipo 09 e somente irá preencher os parâmetros do módulo.

A rotina deve ser construída no fonte TECA000 e também ficará acessível depois a partir da opção Editar Parâmetro no botão outras ações na rotina de inicial da movimentação (protótipo 01) e no menu em Atualizações / Cadastro / Parâmetros gestão de serviços.

Os parâmetros disponíveis para edição através desta rotina são:

• MV_TECXRH = Integração com RH
• MV_RHMUBCO = Integração via EAI habilitada – Utilizado na rotina de conflito de alocação para filtrar de forma diferenciada o afastamento do funcionário.
• MV_TECINTR = Define a quantidade de horas para inclusão automática de intervalo para cálculo de intrajornada
• MV_ATMTCAN = Parâmetro para motivo de cancelamento
• *MV_ATMTFAL = Parâmetro para motivo de falta
• *MV_ATMTSAN = Parâmetro para motivo de saída antecipada
• *MV_ATMTATR = Parâmetro para motivo de atraso
• MV_OCOGCT = Ocorrência padrão para a geração de atendimentos
• MV_GSLOCOC = Ocorrência para geração de Ordem de Serviço para Inspeção de Locação de Equipamentos
• MV_ORCPRC = Tabela de precificação nova
• MV_ATOMCALC = Cálculo automático dos campos da precificação
• MV_MULVIST = Permite múltiplas vistorias
• MV_ATBLTOT = Indica se o campo de preço unitário dos itens de recursos humanos ficará bloqueado para edição direta pelo usuário
• MV_ATONCLC = Define se a cada campo editado irá acontecer o recálculo de todos os campos no orçamento com precificação
• MV_TECPCON = Parâmetro para indicar controle de permissões da área de contrato
• MV_TECPRMF = Controla se o usuário tem permissão de manipular os filtros de alocação
• MV_TECURL = URL para verificação de c.a. de fornecedor (cadastro de coletes)
• MV_TECGUIA = Armazena a URL para emissao da guia de trafego
• MV_TECXML = Diretório onde serão gravados os arquivos Gesp XML
• MV_CNBTEXC = Define se o GCT irá permitir a medição de excendentes (configuração utilizada na medição de horas extras)
• *MV_ATPRES = Define o posto de reserva padrão para alocação dos atendentes para a filial, terá o código de item de alocação do posto de reserva.

Os parâmetros identificados pelo asterisco (*) são os criados para este requisito. Todos esses parâmetros estão vinculados com o processo de gestão de serviços terceirizados e locação de equipamentos do módulo Gestão de Serviços (SIGATEC).

Geração de Agenda Automática

Esta rotina será a responsável por gerar diariamente as agendas dos atendentes.

A rotina irá selecionar todos os atendentes que precisarão ter suas agendas geradas e identificar em qual situação cada um desses atendentes se encaixa para executar as rotinas que efetivamente criarão as agendas. As situações ao qual um atendente pode estar são férias, afastamentos, curso, reciclagem, por exemplo.

Esta rotina estará preparada para ser configurada para execução automática diariamente através do schedule ou poderá ser ativada manualmente a partir do menu em Miscelânea / Processamento / Alocação Diária (Gestão de Escala).

Esta rotina irá gerar arquivo de log registrando os possíveis problemas e incidências como atendentes em falta, atendentes em férias ou afastamentos, por exemplo para ser consultado e antecipar situações sejam lançadas por outras áreas que afetem as agendas dos atendente como férias e afastamentos (RH) ou suspensão (disciplina).

Definição Técnica

Neste tópico serão abordados os detalhes técnicos do desenvolvimento do requisito, como modelo de construção das rotinas, formato regras de preenchimento dos dados na interface e tabelas no banco de dados, condições para exibição e validação de informações e ações, entre outros detalhes.

Job geração diária de agenda

Esta rotina será a responsável por gerar diariamente as agendas dos atendentes. O fonte a ser utilizado é TECM330 que irá gerar as informações para todos os atendentes ativos de todas as filiais.

A rotina deve selecionar todos os atendentes (tabela AA1) que precisarão ter suas agendas geradas e identificar em qual situação cada um desses atendentes se encaixa para executar as rotinas que efetivamente criarão as agendas.

A ordem de avaliação deve ser a seguinte:

Atendentes efetivos de postos

A identificação deve acontecer utilizando as informações da tabela TGY. As condições para identificação são:

• TGY_CODTEC igual ao código do atendente em avaliação pela consulta campo AA1_CODTEC.
• Data da geração da agenda entre as informações nos campos TGY_DTINI e TGY_DTFIM.
• Na tabela ABS o campo ABS_RESTEC precisa ser diferente de "1"

Atendentes em postos de reserva

A identificação deve acontecer utilizando as informações da tabela TGY. As condições para identificação são:

• TGY_CODTEC igual ao código do atendente em avaliação.
• Data da geração da agenda entre as informações nos campos TGY_DTINI e TGY_DTFIM.
• Na tabela ABS o campo ABS_RESTEC precisa ser igual a "1".
  
  

Atendentes em rota de almocista

A identificação deve acontecer utilizando as informações da tabela TW0 (Rota de Almocista) e TGZ (Cobertura de Postos). As condições para identificação são:

• TW0_ATEND igual ao código do atendente em avaliação.
• Data da geração da agenda entre as informações nos campos TGZ_DTINI e TGZ_DTFIM. O relacionamento com a TGZ deverá ser realizado utilizando os campos TGZ_CODTW0 e TW0_COD, além da filial do sistema.

Atendentes em cobertura (não almocistas)

A identificação desta situação deverá utilizar os seguintes critérios:

• TGZ_CODTEC igual ao código de atendente em avaliação.
• Data da geração da agenda entre as informações nos campos TGZ_DTINI e TGZ_DTFIM.
• Campo TGZ_ROTA estar vazio, pois a avaliação das rotas de cobertura é executada em um passo antes.

Os atendentes remanescentes, ou seja aqueles que não foram identificados a nenhuma situação das anteriores, precisarão ser adicionados ao posto de reserva padrão. O posto de reserva padrão deve ser configurado no parâmetro MV_ATPRES.

A adição ao posto de reserva deve ser realizado pela própria rotina do job antes de avaliar se os atendentes possuem bloqueios que impedem a geração da agenda. Isso é importante para evitar situações que o atendente não esteja vinculado a posto ou reserva e aconteça de não ter suas agendas geradas. Esta adição deve ser executada utilizando o modelo de dados do fonte TECA580E.

Neste modelo de dados deverá ser adicionada uma linha no grid TGYDETAIL e o atendente deverá ser adicionado para o Grupo que tiver menos atendentes vinculados e partir do dia do sistema em que o job está sendo executado. Em resumo o conteúdo dos campos na nova linha no grid serão:

TGY_ATEND = atendente em avaliação.

TGY_DTINI = data de execução do job.

TGY_DTFIM = vazio, sem previsão de encerramento da alocação.

TGY_GRUPO = código de grupo com menor quantidade de atendentes associados.

Importante ressaltar que existem itens que o atendente pode estar associado como posto de Reforço, Serviço Extra ou Cobertura de Folga que não possui execução no dia em que a rotina está gerando as informações, nessas situações os atendentes deverão ter suas agendas geradas para o posto de reserva padrão.

Mesmo após ter realizada a identificação das situações para agenda de todos os atendentes é necessário executar uma avaliação da aptidão dos atendentes para o trabalho. Essa verificação consultará as informações de Programação de Férias (tabela SRF), Lançamento de Ausências (tabela SR8), Demissão (campo RA_DEMISSA na tabela SRA), Suspensão (tabela TIT) e os lançamentos de ausências do Gestão de Serviços na tabela TW5 para os casos de curso, reciclagem, folga e falta. A condição é a mesma descrita para identificação do “status” do atendente na janela inicial do processo de movimentação, portanto utilize o mesmo padrão de avaliação descrito no tópico “Movimentação (função TECA335)”.

Essa rotina deverá gerar um arquivo de log no servidor no caminho a partir do servidor “/gestaodeservicos/alocacaodiaria/” com o titulo do arquivo igual a AAAAMMDD.log, por exemplo ‘20150901.log’. Esse arquivo terá o registro de todas as incidências que precisam de atenção do usuário. Essas incidências serão:

1. Não geração de agendas por restrição no RH (casos de férias, afastamentos e demissão);
2. Não geração de agendas por suspensão;
3. Não geração de agendas por curso, reciclagem ou folga no dia;
4. Geração de agenda e manutenção automática por falta em função do atendente ainda estar “em falta” (não ter acontecido a movimentação com a situação “Retorno de Falta”, este item será detalhado no tópico “Opção Movimentar (função TECA336)”;
5. Inclusão de atendente no posto de reserva padrão.

O formato das informações do log deverão ser assim:

==========início===============

Restritos no módulo Recursos Humanos

Técnico: cod001 – Nome Tecnico / motivo: férias / período: diaIni - diaFim

Técnico: cod050 – Nome Tecnico / motivo: licença maternidade / período: diaIni – diaFim

=============================

Suspensos

Técnico: cod013 – Nome Tecnico / motivo: cod-desc. disciplina / período: diaIni - diaFim

=============================

Restritos no módulo Gestão de Serviços

Técnico: cod019 – Nome Tecnico / motivo: folga / período: diaIni – diaFim

Técnico: cod029 – Nome Tecnico / motivo: curso / período: diaIni – diaFim

Técnico: cod051 – Nome Tecnico / motivo: reciclagem / período: diaIni - diaFim

=============================

Atendentes em Falta –manutenção gerada automaticamente

Técnico: cod007 – Nome Tecnico / período: diaIni / total dias = n

=============================

Atendentes movidos para Reserva = %codigo do posto% & Contrato = %numero contrato%

Técnico: cod100 – Nome Tecnico

Técnico: cod011 – Nome Tecnico

============fim===============

Com essas informações no log o usuário poderá conferir os atendentes ou agendas que geraram alguma observação e realizar alguma ação posterior para correção. Isto é importante para antecipar movimentos necessários para ajuste de agendas.

A geração das agendas deverá acontecer conforme as funções padrões já utilizadas quando a geração acontece pela rotina de interface da Gestão de Escala, portanto para a geração das agendas dos atendentes em reserva e dos efetivos será necessário utilizar a função At330AloAut que irá realizar para cada filial a geração das agendas utilizando as informações configuradas na gestão de escalas (conjunto de fontes TECA580). Os atendentes que estiverem em falta precisarão sofrer manutenção de agenda com o tipo de falta conforme o motivo preenchido no parâmetro MV_ATMTFAL. A manutenção deve ser executada utilizando o modelo de dados do fonte TECA550.

Os casos em que os atendentes estão em Curso ou Reciclagem no dia as agendas precisam ser geradas com o horário que tem configurado para o posto de reserva padrão, mas não podem ficar vinculadas a reserva. Portanto nesses casos a agenda será gerada sem preencher o campo com o id da configuração de alocação (campo ABB_IDCFAL).

Um resumo do processamento a ser executado pelo job é: 1. Selecionar todos os atendentes ativos; 2. Verificar para estes atendente quais os postos para gerar as agendas; 3. Associar a reserva os atendentes que não possuem postos vinculados; 4. Executar a alocação; 5. Gerar manutenção de falta dos atendentes em falta; 6. Gerar o arquivo de log com as incidências na geração das agendas.

Movimentação (função TECA335)

A janela deverá ser construída utilizando mvc e as estruturas básicas da interface serão da seguinte forma: fields/enchoice com os campos criados manualmente, o grid com as informações da tabela ABB e a estrutura para informações da escala também sendo criada manualmente.

A organização das informações deve ser conforme o protótipo 01. Nele os únicos campos editáveis pelo usuário são: data, filial e código do atendente, todos os demais deverão ser auto-preenchidos conforme o preenchimento destes campos. O campo função deverá ser carregado a partir do cadastro de atendente (tabela AA1), enquanto o campo cargo precisa ser identificado a partir do cadastro de funcionários do módulo de recursos humanos (tabela SRA).

O grid só deverá ser preenchido quando acionada o botão <F5> ou opção Carregar Agendas no botão Outras Ações. Para a carga das agendas do dia digitado os campos data, filial e código do atendente precisam estar preenchidos, caso a carga dos dados seja acionada mas algum destes campos ainda não tenham sido preenchidos deve ser exibida mensagem ao usuário informando qual o campo precisa ser preenchido para que os dados sejam pesquisados.

As informações da terceira estrutura (informações da escala) deverão ser exibidas conforme o item posicionado no grid, portanto caso o atendente tenha agendas num mesmo dia de diferente escalas, elas serão exibidas conforme o item selecionado no grid pelo usuário.

A instrução <F5> deve receber a ação de carga das agendas e enquanto o usuário estiver nesta interface deverá realizar a busca de agendas conforme o preenchimento dos campos Data, Filial e Código do Atendente. Todas as agendas que atenderem ao seguinte critério deverão ser exibidas quando a busca acontecer:

1. Campo ABB_FILIAL = filial informada pelo usuário.
2. Campo ABB_CODTEC = código informado pelo usuário.
3. Campo TDV_DTREF = data informada pelo usuário. Para identificar o registro relacionado da tabela ABB com a tabela TDV é necessário utilizar o relacionamento entre os campos ABB_CODIGO e TDV_CODABB.

A situação do atendente deverá ser identificada pelo sistema considerando as informações do RH (férias, afastamentos e demissões) e outras situações providas pelo gestão de serviços como suspensão, falta e curso. A ordem de identificação e a forma de identificação dessas situações são detalhadas a seguir:

Demissão: avaliação pelo campo RA_DEMISSA. Quando a data de movimentação for superior a data de demissão a situação do atendente deverá ser indicada como demissão. [ data >= RA_DEMISSA ]

A função At570ChkDm já executa esta consulta, os parâmetros esperados na função são: filial do funcionário, matrícula do funcionário, data e data).

Afastamento: avaliação pelos registros na tabela SR8. Quando identificada que a data de movimentação está entre algum dos períodos lançados de afastamento para o funcionário deverá ser exibida a situação como afastamento. [ R8_DATAINI <= data E ( data <= R8_DATAFIM OU R8_DATAFIM = ' ' ) ]

A função At570ChkAf já executa esta consulta, os parâmetros esperados na função são: filial do funcionário, matrícula do funcionário, data e data).

Férias: avaliação pelos registros na tabela SRF. Quando identificada que a data da movimentação está entre algum período de férias programado para o funcionário deverá ser exibida a situação como férias. [ data ENTRE RF_DATAINI e RF_DATAINI + RF_DFEPRO1 OU data ENTRE RF_DATAIN2 e RF_DATAIN2 + RF_DFEPRO2 OU data ENTRE RF_DATAIN3 e RF_DATAIN3 + RF_DFEPRO3 ]

A função At570ChkFe já executa esta consulta, os parâmetros esperados na função são: filial do funcionário, matrícula do funcionário, data e data).

Suspensão: avaliação pelos registros na tabela TIT. Quando identificado que a data de movimentação está entre o período de suspensão por disciplina, a situação deverá ser exibida como supensão. [ TIT_CODTEC = código atendente E TIT_AFAST = '1' E data ENTRE TIT_DATA e ( TIT_DATA + TIT_QTDDIA ) ].

Necessário criar função para realizar a captura desta informação.

1. Reciclagem: avaliação pelos registros na tabela TW5. Quando identificado que a data de movimentação do atendente está dentro do período de lançamento de reciclagem. [ TW5_TPLANC = '2' E data ENTRE TW5_DTINI e TW5_DTFIM ]
2. Curso: avalição pelos registros na tabela TW5. Quando identificado que a data de movimentação está entre o período de ausência para realização de curso. [ TW5_TPLANC = '3' E data ENTRE TW5_DTINI e TW5_DTFIM ]
3. Falta: avaliação pelos registros na tabela TW5. Quando identificado que a data de movimentação está entre o período de falta do atendente, a situação falta deve ser indicada para o dia. [ TW5_TPLANC = '1' E ( TW5_DTINI <= data E ( TW5_DTFIM = ' ' OU TW5_DTFIM >= data ) ) ]
4. Folga: avaliação combinada entre o resultado da função CriaCalend e os registros na tabela TW5. Será necessário considerar o resultado de ambos utilizando primeiro a verificação na tabela e depois o resultado da construção do calendário para o atendente. A avaliação na tabela deve considerar as seguintes condições [ TW5_TPLANC = '4' E data ENTRE TW5_DTINI e TW5_DTFIM ]. Já a avaliação no resultado da função criaCalend deverá considerar a posição CALEND_POS_TIPO_DIA (06) no array retornado pela função, para o dia ser folga o conteúdo deve ser diferente de "S=Trabalhado”.
5. Dia de trabalho: será indicado quando nenhuma das situações anteriores for identificada.

O conteúdo na tabela TW5 será inserido pela nova rotina de movimentação dos atendentes quando códigos específicos de situações para movimentações forem escolhidos, esse tópico será abordado com mais detalhes adiante quando a opção de movimentação detalhada.

Algumas opções precisam ser adicionadas a essa interface. Essas opções deverão ser acessadas a partir do botão “outras ações” criado por padrão pelo componente mvc. As opções a serem adicionadas são:

Carregar agendas:

Essa ação deve utilizar as informações preenchidas pelo usuário para a carga das agendas, como já mencionado anteriormente. Essa opção também deve ficar disponível quando usuário acionar a tecla <F5>, portanto a carga das agendas para o dia no grid poderá acontecer com o acionamento do botão ou pressionamento da tecla.

Os dados a serem consultados são da tabela ABB e todas as agendas do dia deverão ser exibidas. As colunas com a indicação de serem agendas ativas (campo ABB_ATIVO) ou que receberam manutenção (ABB_MANUT) deverão estar visíveis para que o usuário consiga identificar de forma simples essas situações.

As agendas a serem exibidas precisam respeitar o seguinte critério:

ABB_FILIAL igual a fllial do atendente.

ABB_CODTEC igual ao código do atendente digitado na interface.

TDV_DTREF igual a data da movimentação digitada pelo usuário. A tabela TDV deve ser relacionada com a tabela ABB utilizando campo TDV_CODABB e ABB_CODIGO, além da filial corrente no sistema.

Movimentar:

Essa ação deverá verificar qual a situação para o dia do atendente e caso seja permitida qualquer movimentação a interface para movimentação deverá ser exibida. A rotina para movimentação é detalhada mais adiante nessa especificação.

Consulta de Agendas (período):

Essa opção irá realizar a busca em uma faixa de datas e exibir as agendas do atendente neste período.

O pergunte a ser utilizado é TECA335A que irá exibir os campos: data inicial, data final, filial do atendente e código do atendente. Os dois últimos campos do pergunte precisam ser previamente preenchidos com os valores escolhidos ainda na interface de consulta pelo usuário.

A janela para visualização das informações deve ser conforme o protótipo 08 e construída em mvc. A estrutura principal deverá ter seus campos construídos manualmente e o grid deve ser baseado nos campos da tabela ABB (Agendas dos Atendentes).

A carregamento das agendas deve acontecer utilizando as seguintes condições:

1. 1. ABB_FILIAL igual a filial do atendente.
   2. ABB_CODTEC igual ao código do atendente.
   3. TDV_DTREF entre as datas inicial e final do parâmetro.
   4. TFJ_CODENT e TFJ_LOJA estar entre os códigos de cliente e loja inseridos no parâmetro.
   5. TFF_CONTRT estar entre os códigos de contrato preenchidos no parâmetro.
   6. TFF_FUNCAO ser igual ao preenchido no parâmetro.

O relacionamento para identificação da tabela TDV é com os campos TDV_CODABB e ABB_CODIGO, além da filial corrente do sistema.

O relacionamento para identificação da tabela TFF deve utilizar a tabela ABQ. Para identificação do registro na tabela ABQ é necessário utilizar o campo ABB_IDCFAL e os campos ABQ_CONTRT + ABQ_ITEM + ABQ_ORIGEM. Para o relacionamento ente ABQ e TFF é necessário utilizar ABQ_FILTFF = TFF_FILIAL, ABQ_CODTFF = TFF_COD e mais a filial corrente do sistema para identificar corretamente o registro na ABQ.

O relacionamento para posicionamento na tabela TFJ (orçamento de serviços) deve utilizar a tabela TFL (locais do orçamento) como intermediária e portanto deve ser: TFF_CODPAI igual a TFL_CODIGO e TFJ_CODIGO = TFL_CODPAI além da filial corrente do sistema.

Consulta de Posto Vago:

Essa opção irá realizar a impressão de um relatório utilizando o fonte TECR331 e exibirá a lista dos postos vagos conforme os parâmetros escolhidos pelo usuário. Os postos serão identificados a partir das informações geradas pelo formato do gestão de escalas.

Para identificação de posto vago é necessário cruzar informações da tabelas ABB (agendas dos atendentes) e a TFF (itens de recursos humanos). O posto deve ser considerado vago quando a quantidade de agendas ativas (ABB_ATIVO = "1") para o dia em avaliação não corresponder a quantidade de agendas que deveriam existir ativas conforme a quantidade de recursos definidos no item de recurso humano (campo TFF_QTDVEN).

As informações preenchidas no pergunte deverão filtrar o resultado da seguinte forma:

1. 1. Data, deverá verificar as agendas que tenham a data de referência conforme o valor preenchido no parâmetro. A comparação é com o campo TDV_DTREF.
   2. Cliente e Loja, deve utilizar para filtrar os itens de recursos humanos a serem avaliados. A comparação deve acontecer com o campo TFJ_CODENT e TFJ_LOJA.
   3. Local, deve utilizar para filtrar os itens de recursos humanos a serem avaliados. A comparação deve acontecer com o campo TFF_LOCAL.
   4. Contrato, também para filtrar e otimizar a avaliação e pesquisa dos postos. A comparação deve acontecer com o campo TFF_CONTRT.

O relacionamento para identificação da tabela TDV é com os campos TDV_CODABB e ABB_CODIGO, além da filial corrente do sistema.

O relacionamento para identificação da tabela TFF deve utilizar a tabela ABQ. Para identificação do registro na tabela ABQ é necessário utilizar o campo ABB_IDCFAL e os campos ABQ_CONTRT || ABQ_ITEM || ABQ_ORIGEM. Para o relacionamento ente ABQ e TFF é necessário utilizar ABQ_FILTFF = TFF_FILIAL, ABQ_CODTFF = TFF_COD e mais a filial corrente do sistema para identificar corretamente o registro na ABQ.

O relacionamento para posicionamento na tabela TFJ (orçamento de serviços) deve utilizar a tabela TFL (locais do orçamento) como intermediária e portanto deve ser: TFF_CODPAI igual a TFL_CODIGO e TFJ_CODIGO = TFL_CODPAI além da filial corrente do sistema.

Visualizar Cadastro do Atendente:

Essa opção deve exibir o cadastro de atendentes com a opção de visualização. Para isso deverá ser executada a função FwExecView com a opção de visualização do fonte TECA020, antes de realizar esta chamada é necessário garantir que o atendente posicionado na tabela AA1 é o atendente escolhido pelo usuário na interface.

Visualizar Controle de Dias de Direito:

Essa opção deve exibir o cadastro de programação de férias do módulo de Recursos Humanos. Para isso deverá executar a função FwExecView da rotina GPEA050 com a opção de visualização. Para exibir corretamente as informações do funcionário/atendente é necessário realizar o posicionamento corretamente nas tabelas AA1 (atendentes) e SRA (funcionários) conforme a filial e código de atendente preenchidos previamente na interface.

Visualizar Ausências:

Essa opção deve exibir o lançamento de ausências do módulo de Recursos Humanos. Para isso deverá executar a função FwExecView da rotina GPEA240 com a opção de visualização. Para exibir corretamente as informações do funcionário/atendente é necessário realizar o posicionamento corretamente nas tabelas AA1 (atendentes) e SRA (funcionários) conforme a filial e código de atendente preenchidos previamente na interface.

Editar Parâmetros:

Essa opção irá exibir interface para facilitar a configuração dos parâmetros do sistema (itens mv_ da tabela de dicionário SX6). A função a ser utilizada é TECA000 e o desenvolvimento desta rotina será tratado com mais detalhes em tópico próprio nesta especificação. Somente os parâmetros que influenciam diretamente o comportamento do Gestão de Serviços serão disponibilizados para edição por esta rotina.

Opção Movimentar (função TECA336)

Essa opção ficará disponível a partir da rotina de incial de movimentação e poderá ser acionada pelo botão em outras ações ou através da tecla <F6>. A interface desta rotina deve ser semelhante ao protótipo 02.

Cada movimentação realizada pelo usuário será gravada na tabela TW3 em uma forma de manter um log das atualizações realizadas pelos usuários.

A seguir alguns aspectos específicos do desenvolvimento e comportamento da interface serão abordados.

Códigos de Situação e Motivos de Movimentação

Esses códigos serão carregados juntamente com a tabela SX5 (tabelas genéricas).

A lista dos códigos disponíveis para cada uma das duas tabelas são:

Tabela T40.

Tabela T41.

As validações e gatilhos serão executados considerando especificamente estes códigos. O sistema poderá ser personalizado e novos códigos adicionados, entretanto as validações e avaliações para liberação dos campos na janela para movimentar os atendentes precisarão ser desenvolvidos para estes novos códigos pelo próprio usuário que está realizando esta personalização.

É importante deixar funções para seleção, listagem e captura de descrição das situações e motivos de movimentação preparadas para serem chamadas pela rotina de execução das movimentações.

Construção do modelo e interface

Como citado a interface deve ser semelhante ao protótipo 02 e será construída utilizando dois modelos de dados: o primeiro baseado na tabela TW3 e o segundo na tabela ABB.

Os campos a existirem na primeira estrutura são:

• Situação (TW3_SITCOD)
• Descrição (TW3_SITDES)
• Qtde dias (TW3_QTDIAS)
• Data Final (TW3_ADTFIM)
• Cod. Substituto (TW3_TECSUB)
• Nome Substituto (TW3_TECSNM)
• Hora Inicial (TW3_SUBINI)
• Cliente (TE3_CLICOD)
• Local (TW3_LOCCOD)
• Descrição do Local (TW3_LOCCOD)
• Item Rh Contrato (TW3_ITRHCT)
• Item Escala (TW3_TRSQES)
• Grupo (TW3_GRPESC)
• Rota (TW3_RTACOD)
• Descrição (rota) (TW3_RTADES)
• Motivo (TW3_MOTCOD)
• Descrição (motivo) (TW3_MOTDES) (até aqui os campos exibidos na interface)
• Código Atendente (TW3_ATDCOD)
• Data Movimentação (TW3_DTMOV)
• Data Execução (TW3_DTEXEC)
• Usuário Execução (TW3_USEXEC)

Os campos a existirem na segunda estrutura são:

• Data Inicial (ABB_DTINI)
• Hora Inicial (ABB_HRINI)
• Hora Final (ABB_HRFIM) (até aqui exibidos na interface)
• Código da agenda (ABB_CODIGO)
• Filial (ABB_FILIAL)
• Id Config. Alocação (ABB_IDCFAL)
• Atendente (ABB_CODTEC)
• Manutenção (ABB_MANUT)
• Ativo? (ABB_ATIVO)

A janela deve ser aberta como inclusão de registro para que todas as movimentações preenchidas pelos usuários fiquem registradas,  semelhante a um log. A estrutura da tabela ABB deverá montar um grid e este grid não poderá permitir a inclusão ou exclusão de linhas.

Para mais detalhes sobre os campos que serão gravados fisicamente e quais serão virtuais consulte o tópico de dicionário de dados.

Mecânica e comportamento interno

A interface irá permitir inicialmente somente a edição do campo “Situação” e conforme o código inserido algumas partes serão desbloqueadas e permitirão a edição. As regras com quais partes da interface são desbloqueadas conforme o código de situação inserido estão descritas no tópico “Opção Movimentar” da Regra de Negócio.

O bloqueio e desbloqueio deve acontecer através da função At335when() a ser atribuída ao when de todos os campos e que proporcionará o ponto de entrada AT335WHE para qualquer eventual validação adicional ou personalização da avaliação pelos clientes.

As alterações devem ser processadas quando pressionado o botão “Salvar” e as movimentações acontecerão utilizando as rotinas automáticas já existentes no sistema. Essas movimentações serão detalhadas a seguir para cada situação que o usuário pode utilizar.

• Implantar Efetivo

Irá realizar a inclusão de um atendente efetivo na relação de posto x funcionário. Para tanto irá utilizar o modelo de dados da rotina TECA580E e incluir um novo atendente a partir do dia em que a movimentação está acontecendo.

O usuário irá digitar ou selecionar as informações nos campos Item de Rh Alocação, Item da Escala (corresponde ao Turno e Sequência na configuração da escala) e o Grupo e serão estes dados que determinarão qual posto o funcionário deverá ser associado.

Importante validar na inserção das informações no campo Item da Escala digitado exista para a escala utilizada no posto e que no campo Grupo tenha disponibilidade para alocação, caso não haja disponibilidade (ou seja, não existe vaga no posto) o usuário deverá selecionar qual atendente atual irá ser removido do posto para que este novo atendente assuma.

• Implantar Folguista

Irá realizar a inclusão de um atendente de cobertura em item para folguista. Para executar este processo é necessário utilizar o modelo de dados do fonte TECA580E e associar o atendente com algum dos itens do tipo Folguista nas coberturas disponíveis para a Escala do posto. Portanto o Item da Escala nessa situação deve ser algum dos itens do tipo folguista que foi configurado para a escala.

Para esta situação não terá Grupo ao qual o atendente será vinculado, pois mesmo que existam mais que um item do tipo folguista para a escala o controle não é pelo formato de grupo e sim diretamente pelo item de folguista. Desta forma o código da tabela TGX (conteúdo vem do campo TGX_COD).

• Implantar Almocista

Irá realizar a associação de um atendente com a rota de almocista. Para executar esta associação é necessário utilizar a função At581Efet. Esta função espera os seguintes parâmetros 1º Código da Rota, 2º Código Atendente e 3º Data, é importante ressaltar que caso algum atendente este atualmente na rota ele terá sua associação removida.

• Falta

Irá inserir um registro na tabela TW5 indicando o início das faltas do atendente. Esta opção não irá exigir preenchimento de qualquer outro campo.

A data a ser considerada na falta é a data utilizada para movimentação na janela anterior. Quando existir agenda gerada para o dia em que a falta está sendo lançada é necessário realizar a manutenção de agenda com o tipo inserido no parâmetro MV_ATMTFAL, para a manutenção de agenda é necessário utilizar o modelo de dados do fonte TECA550.

• Retorno de Falta

Irá complementar o registro de falta em aberto (ou seja, que não possui a data de encerramento preenchida). Esta opção também não irá exigir o preenchimento de qualquer outro campo.

A data a ser inserida como data de retorno é o dia anterior ao dia utilizado na movimentação.

Caso o usuário realize um Retorno de Falta no mesmo dia em que ela foi lançada (como um erro de lançamento por exemplo), a situação deverá ser indicada ao usuário através de uma mensagem na tela exigindo a decisão se deve remover a falta lançada anteriormente e continuar o processo ou se deve cancelar (não realizar) o restante do processamento da rotina. Quando usuário optar excluir a falta anterior é necessário verificar se há e remover a manutenção de agenda de falta, para tanto é necessário utilizar o modelo de dados do programa TECA550.

• Folga

Irá realizar a inclusão de um registro na tabela TW5. Esta opção não deve esperar o preenchimento de qualquer outro campo na interface. O registro a ser incluído deve ter a data inicial e final preenchida com a data da movimentação digitada pelo usuário no início do processo.

É necessário realizar o cancelamento da agenda atual do atendente utilizando o modelo de dados do programa TECA550 e o conteúdo do parâmetro MV_ATMTCAN como o motivo de manutenção (cancelando as agendas atuais dos atendentes).

• Folga Trabalhada

Irá realizar a geração de agenda para o atendente no dia utilizado para movimentação. As informações nos campos Item RH Alocação, Item Escala e Grupo são de preenchimento obrigatório para identificar se de fato é um posto vago (sem a alocação completa) e obter as informações necessárias para gerar a(s) agenda(s).

• Folga Convocação

Irá realizar a geração de agenda para o atendente no dia utilizado para movimentação. As informações nos campos Item RH Alocação, Item Escala e Grupo são de preenchimento obrigatório para identificar se de fato é um posto vago (sem a alocação completa) e obter as informações necessárias para gerar a(s) agenda(s).

• Saída Antecipada

Irá permitir a edição do horário final das agendas identificadas para o dia da movimentação e só pode ser utilizado quando existem agendas para o atendente no dia.

Para esta situação é necessário que aconteça alteração na hora final e estas alterações serão replicadas utilizando a rotina de manutenção de agendas do modelo de dados TECA550. O motivo da manutenção a ser utilizado precisa ser do tipo de saída antecipada e deve ser identificado pelo conteúdo do parâmetro MV_ATMTSAN.

• Atraso

Irá permitir a edição do horário inicial das agendas identificadas para o dia da movimentação e só pode ser utilizado quando existirem agendas para o dia.

Para esta situação é necessário que aconteça a alteração na hora final de alguma agenda e para esta alteração ser efetivada a rotina de manutenção de agenda TECA550 precisa ser utilizada, realizando uma manutenção com o tipo de atraso. O código sendo identificado através do parâmetro MV_ATMTATR.

• Hora Extra

Irá permitir a edição dos horários iniciais e finais das agendas identificadas para o dia da movimentação e só poderá ser utilizado quando existirem agendas no dia selecionado para movimentação.

Para esta movimentação após o usuário confirmar será exibida janela pop up para seleção do motivo de manutenção de hora extra a ser utilizado na manutenção da agenda e ajuste do horário. A manutenção da agenda deve acontecer utilizando o modelo de dados do fonte TECA550.

• Implantar Reforço

Irá realizar a associação de um atendente ao cadastro de posto x funcionário para um posto que seja do tipo reforço. Estes postos são identificados pelos campos TFF_ORIREF contendo o conteúdo do código do item de TFF que originiou a solicitação do reforço e o campo TFF_COBCTR = '2' que indica a cobrança fora do contrato.

A associação acontecerá utilizando as informações dos campos Item RH Alocação, Item da Escala e Grupo do posto do reforço, o modelo de dados para realizar estas atualizações é o TECA580E.

• Implantar Serviço Extra

Irá realizar a associação do atendente ao cadastro de posto x funcionário para um posto que seja do tipo serviço extra. Estes postos identificados pelos campos TFF_ORIREF sem conteúdo e o campo TFF_COBCTR = '2' do item de recurso humano para alocação.

A associação acontecerá utilizando as informações dos campos Item RH Alocação, Item da Escala e Grupo do posto do reforço, o modelo de dados para realizar estas atualizações é o TECA580E.

• Implantar Cortesia

Irá realizar a associação do atendente ao cadastro de posto x funcionário para um posto que seja do tipo cortesia. Estes postos identificados pelos campos TFF_PRCVEN igual a zero e o campo TFF_COBCTR = '2' do item de recurso humano para alocação.

A associação acontecerá utilizando as informações dos campos Item RH Alocação, Item da Escala e Grupo do posto do reforço, o modelo de dados para realizar estas atualizações é o TECA580E.

• Reciclagem

Deve realizar a inclusão de um registro na tabela TW5 para indicar o período que o atendente está em reciclagem. Esta opção irá esperar que o usuário digite a quantidade de dias que durará a reciclagem no campo “Qtde dias”, o valor no campo “Data Final” será preenchido considerando a data inicial utilizada para movimentação e a quantidade de dias preenchida e não poderá ser editado diretamente pelo usuário sendo bloqueado para edição.

Caso existam agendas para o atendente no período elas deverão ser canceladas utilizando a rotina de manutenção de agendas TECA550 com o motivo de manutenção preenchido no parâmetro MV_ATMTCAN. Nestes casos também é importante deixar o campo para preenchimento do atendente substituto aberto para escolha do atendente que fará a substituição no primeiro dia ou no período.

• Curso

Deve realizar a inclusão de um registro na tabela TW5 para indicar o período que o atendente está em curso. Esta opção irá esperar que o usuário digite a quantidade de dias que durará a reciclagem no campo “Qtde dias”, o valor no campo “Data Final” será preenchido considerando a data inicial utilizada para movimentação mais a quantidade de dias preenchida e não poderá ser editado diretamente pelo usuário sendo bloqueado para edição.

Caso existam agendas para o atendente no período elas deverão ser canceladas utilizando a rotina de manutenção de agendas TECA550 com o motivo de manutenção preenchido no parâmetro MV_ATMTCAN. Nestes casos também é importante deixar o campo para preenchimento da filial e código do atendente substituto aberto para escolha do atendente que fará a substituição no primeiro dia ou no período (essa pergunta deve ser exibida em forma de janela pop up para que o usuário selecione a opção que deseja). Quando usuário selecionar o período as agendas para aquele período deverão ser geradas para o atendente substituto.

• Recolhimento

Irá executar a remoção de um atendente efetivo do posto ao qual está vinculado. Portanto deverá executar o cancelamento das agendas já geradas a partir do dia em que a movimentação está acontecendo, por exemplo uma movimentação de recolhimento sendo lançada no dia 10 deverá cancelar todas as agendas já geradas do próprio dia 10 e superior ao dia 10. Este cancelamento deve acontecer utilizando a rotina TECA550 e o motivo de manutenção para cancelamento que está preenchido no parâmetro MV_ATMTCAN. A data de fim da associação como efetivo no posto deve ser o dia anterior a data da movimentação escolhida pelo usuário no início do processo de movimentação.

Deverá estar habilitado para edição os campos filial e código do atendente substituto para que o usuário possa executar a substituição e ao preencher este campo será exibido ao usuário janela pop up para indicar se a substituição será permanente ou somente no primeiro dia. Caso o usuário marque a opção para substituição permanente este atendente deve ser associado como efetivo exatamente com as mesmas configurações que o atendente recolhido era efetivo (item de escala e grupo) e a partir da data atual da movimentação.

• Troca de Funcionário

Irá realizar a troca de posto entre dois funcionários efetivos. Portanto deverá abrir a digitação de filial e código do atendente para a troca, importante que neste caso só poderá ser um atendente efetivo de algum outro posto. As agendas já geradas deverão ser invertidas entre os atendentes, fazendo com que um assuma as agendas do dia movimentação e futuros um do outro.

A associação entre os atendentes e o postos deverá ser alterada considerando até o dia anterior a data da movimentação no posto antigo e a partir data da movimentação no novo posto, esta alteração deve acontecer utilizando o modelo de dados do fonte TECA580E.

Importante que sejam criadas funções para executar os processos que se repetem como exemplo cancelamento de agendas, para melhor leitura do código e também facilitar futuras novas implementações no processo ou ajustes.

Quando uma cobertura é selecionada o dia da movimentação poderá ter o horário inicial da agenda alterado, assim é necessário consultar o campo TW3_SUBINI e caso tenha conteúdo é necessário inserir como hora início o valor informado pelo usuário sendo que a carga horária deve mantida, por exemplo a entrada do efetivo seria as 8h e saída as 20h mas houve a cobertura e o horário da cobertura é inserido para 9h a saída deverá acontecer as 21h.

Quando as ações de implantação forem executadas é necessário realizar a geração da agenda do atendente para o dia da movimentação e para a agenda que o atendente já possuía no dia é necessário realizar o cancelamento.

Consultas Padrões e Validações dos Campos

Campo: Situação

Será uma consulta padrão nova baseada na tabela SX5 nos itens de chave igual a T40. O código da novo consulta deve ser SX5T40.

Deve obrigatoriamente ser alguma das situações cadastradas na tabela SX5 e chave T40.

Campo: Filial Substituto

Será a consulta SM0 já existente no sistema e só pode ser obrigatoriamente alguma dos códigos do sistema.

Campo: Cód. Substituto

Será uma consulta específica pois deve variar conforme o código de situação utilizado pelo usuário. O código dela deve ser AA1MOV para indicar que é utilizada na interface de movimentação.

Por via de regra deve utilizar as informações do posto para restringir os atendentes que poderão realizar a cobertura e esta busca deverá considerar os atendentes sem alocação e os atendetes que estejam associados a posto de reserva.  As exceções são com as situações: Troca de Funcionário, Falta, Implantar Reforço, Implantar Serviço Extra e Implantar Cortesia. Para esses casos especiais as condições de filtro são:

Troca de Funcionário: o atendente substituto será o atendente com o qual o posto de efetivo será trocado, portanto a consulta deverá considerar que os atendentes efetivos de posto ao invés dos disponíveis (sem alocação ou em reserva). Portanto as condições são atendente efetivo em um posto (TGY_DTFIM >= data da movimentação e AA1_FUNCAO igual a do outro atendente da troca).

Falta, Implantar Reforço, Serviço Extra e Cortesia: para estes casos é necessário permitir e exibir na lista dos atendentes para serem substitutos os almocistas efetivos em rotas de cobertura de almoço.

Importante considerar a filial a ser utilizada para filtrar os atendentes é a filial preenchida anteriormente no campo filial do substituto.

Campo: Cliente

Deve utilizar a consulta padrão SA1CLI, que não possui filtro algum e retorna somente o código do cliente sem a loja. O código deve existir na tabela SA1.

Campo: Local

Utilizar uma nova consulta ABSCLI que deverá ser específica e deve utilizar uma variável private cABS_CODIGO para filtrar os locais conforme o código do cliente inserido anteriormente. Para que funcione adequadamente é necessário adicionar um gatilho no campo de cliente para preencher esta variável. Mais detalhes sobre a consulta

Campo: Item RH Alocação

Utilizar uma consulta específica que utilize as informações do perfil de alocação do atendente (TECA337) para restringir o resultados dos postos de alocação. Isto é necessário para a validação e para a realizar o filtro pela função que é exercida pelo atendente. Quando o código do posto for digitado diretamente pelo usuário é necessário verificar se a função do posto e a do atendente que está sendo movimentado são as mesmas, caso não seja é necessário exibir mensagem ao usuário informando a situação da seguinte forma:

“Função configurada para o posto é diferente da função do atendente. Posto: “0001 / descrição” e Atendente: “0003 / descrição. Deseja continuar mesmo assim? [sim] [não]”.

Esta consistência é importante para avisar a equipe de movimentação dos atendentes de quando estiver escalando alguma pessoa em posto que talvez não esteja completamente capacitada.

Essa nova consulta deverá ter o código TFFMOV.

Campo: Item Escala

Utilizar uma nova consulta que para exibir os dados deverá ter preenchido antes o campo Item RH Alocação, pois a lista de itens de escala será feita baseando-se na escala vinculada ao item de Rh (escala do posto). Caso a consulta seja utilizada ou conteúdo inserido no campo deverá exibir mensagem informando que o campo Item Rh Alocação precisa ser preenchido.

O código dessa consulta deverá ser TDXMOV.

Campo: Grupo

Utilizar uma nova consulta para verificar quais grupos estão disponíveis e exibi-los para seleção pelo usuário. Para essa avalição é necessário que os campos Item RH Alocação e Item Escala estejam preenchidos.

A consulta deverá ser específica e criar a interface e o grid com os dados manualmente. O código para ela deve ser TGYGRU.

Campo: Rota

Utilizar uma nova consulta padrão utilizando a tabela TW0. A consulta deverá ter o código TW0MOV.

Ela deverá filtrar somente as rotas que não tenham atendente vinculados, ou seja, campo TW0_ATEND igual a vazio (TW0_ATEND = ' ').

Campo: Motivo

Será uma consulta padrão nova baseada na tabela SX5 nos itens de chave igual a T41. O código da novo consulta deve ser SX5T41.

Deve obrigatoriamente ser algum dos motivos cadastrados na tabela SX5 e chave T41.

Perfil de Alocação

Deve ser desenvolvido utilizando o fonte TECA337 e a interface deve ser semelhante ao protótipo 03.

A rotina ficará disponível para visualização e configuração a partir da janela de movimentação no botão outras ações e esta configuração servirá de base para a pesquisa do itens de Rh para alocação.

Por padrão somente a validação de turno deverá ser carregada para validar, os demais devem ser carregados para não validar. O texto a exibir para indicar ao usuário deve ser “usa função” para quando estiver habilitado e “não usa função” quando não estiver habilitado.

A rotina deve ser construída em MVC e utilizando estrutura criada manualmente. Os dados não serão gravados em momento algum somente deverão ser mantidos em memória para os momentos de pesquisa dos postos para alocação (seja postos normais ou rotas para almocistas).

Parâmetro MV_ATPRES: Posto de Reserva Padrão

No momento de efetivação de uma revisão de contrato no Gestão de Serviços será necessário verificar se o orçamento possui algum posto de reserva vinculado e se algum dos postos de reserva está configurado no parâmetro MV_ATPRES, quando identificar esta situação o conteúdo no parâmetro precisa ser alterado para conter o valor do novo código do posto (campo TFF_COD).

Essa avaliação deverá considerar o campo TFF_COD e o conteúdo do parâmetro, mas o novo valor será o conteúdo do campo TFF_COD do registro que não estiver com conteúdo no campo TFF_CODSUB. Este campo (TFF_CODSUB) só é preenchido quando o item foi substituído em função de uma revisão e seu conteúdo indica qual o novo código do item da TFF que é válido, por isso é necessário identificar qual o valor do parâmetro e se este campo está preenchido no registro do posto que está preenchido no parâmetro, caso esteja realizar uma nova pesquisa até que identifique o registro sem que o campo TFF_CODSUB esteja preenchido.

Este parâmetro deve ser criado por filial, pois os postos de reserva possuem por padrão o nível de filial já que está vinculados a um contrato.

Configuração de parâmetros

Deverá ser desenvolvida utilizando o programa fonte TECA000 e disponibilizada a partir do menu em Atualizações / Cadastros / Parâmetros Gestão de Serviços. Somente os usuário que possuírem acesso ao módulo do Configurador (SIGACFG) poderão realizar a alteração dos parâmetros a partir desta rotina.

A rotina deve ser construída em mvc e a interface deve ser organizada conforme o protótipo 09. Portanto a estrutura deve ser do tipo fields/enchoice com todos os campos virtuais e construídos inseridos manualmente na estrutura por não ser uma estrtura baseada em dicionário, em função disso a gravação não poderá ser a padrão do mvc e deve ser construída especialmente para esta rotina.

Na inclusão dos campos alguns pontos precisarão de atenção:

1. O título e código do campo deverá ser o nome do parâmetro;

2. O help desses campos na interface devem ser as linhas de descrição do parâmetro na tabela de dicionário SX6;

3. Quando o parâmetro possuir sua configuração por filial o valor a ser carregado/gravado deverá ser conforme filial corrente em uso no sistema (utilizando a variável pública cFilAnt para identificar) e;

4. Os campos na interface precisam ter o mesmo tipo (numérico, caracter, lógico, etc) que o indicado no dicionário para eles.

Os parâmetros disponíveis para edição através desta rotina são:

• MV_TECXRH = Integração com RH
• MV_RHMUBCO = Integração via EAI habilitada – Utilizado na rotina de conflito de alocação para filtrar de forma diferenciada o afastamento do funcionário.
• MV_TECINTR = Define a quantidade de horas para inclusão automática de intervalo para cálculo de intrajornada
• MV_ATMTCAN = Parâmetro para motivo de cancelamento
• *MV_ATMTFAL = Parâmetro para motivo de falta
• *MV_ATMTSAN = Parâmetro para motivo de saída antecipada
• *MV_ATMTATR = Parâmetro para motivo de atraso
• MV_OCOGCT = Ocorrência padrão para a geração de atendimentos
• MV_GSLOCOC = Ocorrência para geração de Ordem de Serviço para Inspeção de Locação de Equipamentos
• MV_ORCPRC = Tabela de precificação nova
• MV_ATOMCALC = Cálculo automático dos campos da precificação
• MV_MULVIST = Permite múltiplas vistorias
• MV_ATBLTOT = Indica se o campo de preço unitário dos itens de recursos humanos ficará bloqueado para edição direta pelo usuário
• MV_ATONCLC = Define se a cada campo editado irá acontecer o recálculo de todos os campos no orçamento com precificação
• MV_TECPCON = Parâmetro para indicar controle de permissões da área de contrato
• MV_TECPRMF = Controla se o usuário tem permissão de manipular os filtros de alocação
• MV_TECURL = URL para verificação de c.a. de fornecedor (cadastro de coletes)
• MV_TECGUIA = Armazena a URL para emissao da guia de trafego
• MV_TECXML = Diretório onde serão gravados os arquivos Gesp XML
• MV_CNBTEXC = Define se o GCT irá permitir a medição de excendentes (configuração utilizada na medição de horas extras)
• *MV_ATPRES = Define o posto de reserva padrão para alocação dos atendentes

Os parâmetros identificados pelo asterisco (*) são os criados para este requisito. Todos esses parâmetros estão vinculados com o processo de gestão de serviços terceirizados e locação de equipamentos do módulo Gestão de Serviços (SIGATEC).

Inclusão de reforço

A rotina deve ser desenvolvida utilizando o fonte TECA740G. O processo será em duas janelas conforme os protótipos 16 e 17, mas antes da primeira janela deve ser apresentado o pergunte de código TECA740G. Este pergunte irá exibir os seguinte campos para filtro dos itens Rh que serão exibidos na janela seguinte:

1. Código de Cliente (comparar com o campo TFJ_CODENT)
2. Loja do Cliente (comparar com o campo TFJ_LOJA)
3. Código Local (comparar com o campo TFF_LOCAL)
4. Contrato (comparar com o campo TFF_CONTRT)

A primeira janela será o protótipo 17 (fonte TECA740G) onde o usuário irá selecionar para qual item de contrato que o reforço irá acontecer e a segunda será o protótipo 16 (fonte TECA740G1) onde definirá as condições de execução (turno ou escala, dias e frequência de execução).

Ambas rotinas devem ser construídas em MVC. A primeira janela precisará ser construída com estrutura baseada na tabela TFF para o grid e esta estrutura deve ser somente para consulta, mas o item selecionado pelo usuário deve ser utilizado como base para as informações da segunda interface (protótipo 16). O campo para indicar marcação na estrutura do grid deverá ser adicionado manualmente como tipo lógico para que possa simular um markbrowse.

As colunas a serem apresentadas ao usuário para avaliação do item para seleção são:

1. Código da alocação (TFF_COD);
2. Produto (TFF_PRODUT);
3. Descrição do produto (TFF_DESCRI);
4. Valor Hora Reforço (TFF_REFVLR);
5. Função (TFF_FUNCAO);
6. Desc. Função (TFF_DFUNC);
7. Escala (TFF_ESCALA);
8. Desc. Escala (TFF_NOMESC);
9. Calendário (TFF_CALEND);
10. Desc. Calendário (TFF_DSCALE);

Os dados a serem carregados nesta interface (protótipo 17) precisam ser resultado de uma consulta no banco de dados filtrando somente os registros que atenderem a configuração preenchida pelo usuário anteriormente no pergunte TECA740G. Este grid não poderá permitir a inclusão ou exclusão de linhas e a única alteração a ser permitida é a marcação/desmarcação do campo que irá indicar o item selecionado.

Na segunda interface os dados devem ser carregados utilizando o registro da tabela TFF selecionado pelo usuário, portanto a estrutura também deverá ser baseada na tabela TFF, mas dessa vez deve ser exibido um field/enchoice e não grid. Nesta janela as informações do agrupamento “Cópia do Original” não poderão ser alteradas e o conteúdo do campo “Valor” deve ser o campo TFF_REFVLR (do item escolhido) que deverá indicar que se trata do valor por hora do recurso, portanto o campo TFF_PRCVEN do item de reforço a ser inserido deverá ser preenchido com o valor do campo TFF_REFVLR conforme o item referência para o reforço. A forma de execução do reforço será registrado na tabela TW4 e essa configuração ficará vinculada ao item do reforço através do campo TFF_CODTW4 que receberá o conteúdo do campo TW4_COD, portanto o campo de combo com o conceito dos dias para execução e os campos para seleção dos dias serão construídos a partir da estrutura da tabela TW4.

A definição dos dias precisa seguir a seguinte regra:

1. O campo “dias de execução” deve ter por padrão o preenchimento com a opção “Todos os dias”;
2. O campo “dias de execução” precisará ter um gatilho para executar a marcação dos campos de domingo a sábado e feriado quando as opções 1=Todos os dias, 2= Dias Semana ou 3=SDF (sab, dom, fer) forem selecionadas conforme o descrito para cada item e os campos com os dias da semana não poderão ser editados.
3. Quando a opção 4=Dias específicos semana for selecionada os campos dos dias da semana devem ficar habilitados para marcação e assim o usuário poderá definir em quais dias irá acontecer.

Os campos de data inicial e final serão correspondente aos campos TFF_PERINI e TFF_PERFIM e somente a data inicial é de preenchimento obrigatório a data final poderá ficar sem preenchimento e nesse caso irá indicar que o item só terá seu fim quando o item original também for finalizado. Nos casos que o item original tiver a data final preenchida o item de reforço não poderá ter sua data de fim maior que a do item original, portanto o reforço sempre acontecerá dentro ou no mesmo período que o item original de alocação.

No item do reforço o campo TFF_ORIREF deverá ser preenchido com o código do item original (campo TFF_COD) e o campo TFF_COBCTR deverá ter o conteúdo '2' indicando que a cobrança será realizada via pedido de venda fora do contrato.

Alterações Orçamentos de Serviços (TECA740 e TECA740F)

As rotinas de orçamento de serviços precisam ser alteradas para não exibir os novos campos na tabela TFF (TFF_CODTW4 e TFF_REFORI) e exibir o campo para receber o valor a ser cobrado hora de trabalho de reforços (TFF_REFVLR).

A remoção dos campos deve acontecer na view da estrutura da tabela TFF e deve se aplicar também aos casos de inclusão de Cortesia e Serviço Extra. Estes últimos dois casos (Cortesia e Serviço Extra) também não deverão exibir o campo para preenchimento do valor da hora extra (TFF_REFVLR).

O campo para o valor da hora do reforço (TFF_REFVLR) deverá ser adicionado logo após o campo de valor total do recurso humano (TFF_TOTAL) para que seja de fácil visualização e alteração pelo usuário. Este campo receberá o conteúdo por gatilho a partir de dois campos: preço unitário (TFF_PRCVEN) e data final (TFF_PERFIM). O cálculo deverá levar em consideração se o contrato é com fim indeterminado ou não para o cálculo e por isso estes dois campos estarão envolvidos no cálculo e irão disparar. A forma do cálculo é:

1. Contrato determinado (data final preenchida ou TFF_PERFIM diferente de vazio [' '])
   1. Utilizar o valor informado no campo de preço unitário dividir pela diferença de dias entre a data inicial e final, dividir o resultado por 8 e então multiplicar por 1,5. Assim chegará no valor aproximado da hora de um recurso acrescido de 50%.
   2. Fórmula = [((( FwFldGet('TFF_PRCVEN') / (FwFldGet('TFF_PERFIM')-FwFldGet('TFF_PERINI')+1) ) / 8 ) * 1.5) ].
      
      
2. Contrato indeterminado (data final não preenchida ou TFF_PERFIM igual a vazio [' '])
   
   1. Utilizar o valor informado no campo do preço unitário dividir por 30 (quantidade de dias em um mês) e dividir o resultado novamente por 8 (quantidade média de horas trabalhadas), após multiplicar por 1,5. Assim chegará no valor de uma hora mensal normal acrescida em 50%.
   2. Fórmula = [((( FwFldGet('TFF_PRCVEN') / 30 ) / 8 ) * 1.5) ].

Observação: o gatilho só deverá ser disparado quando não tiver valor no campo TFF_REFVLR, caso algum valor já exista não deve acontecer sobreposição do conteúdo.

Tipo de Alocação

O cadastro do tipo de alocação irá contar com mais um campo “Cobra Alocação?” (campo TCU_COBALO) que irá determinar quais alocações e agendas poderão ser consideradas para cobrança ou não.

Os tipos padrões serão alterados para que o campo seja preenchido com a configuração de cobrança adequada. Para não executar a atualização a cada acesso a rotina de cadastro do tipo de alocação deve ser alterada a função At690Unit para considerar se o campo TCU_COBALO está preenchido e caso esteja, não deverá atualizar o cadastro do tipo.

Os tipos padrões serão configurados da seguinte maneira:

Um novo tipo será criado código igual a 008 e descrição como “Cobertura Não Cobrada”. O objetivo é ter um tipo padrão que possa ser utilizado na geração de agendas na substituição que mantenha o conceito de cobrança dos tipos de alocação Cortesia e Excedente (que não cobram alocação).

Apuração e Medição (TECA930)

A alteração deve acontecer na medição dos itens extras que deverá incluir os itens de reforço na apuração e medição.

Estes itens serão identificados por terem os campos TFF_ORIREF e TFF_CODTW4 preenchidos e para estes itens o valor para cobrança deverá ser calculado considerando a quantidade de horas realizada neles multiplicando com o valor inserido para a hora do reforço no campo TFF_PRCVEN.

Funções Específicas

Algumas funções de validação precisarão ter comportamentos específicos

At336CanAt() – Validação Atendente Substituto

Essa função precisa validar o atendente selecionado para cobertura conforme a situação utilizada. Por exemplo para cobertura em função de falta podem ser utilizados atendente de reserva ou efetivos em rota de cobertura, portanto é necessário considerar os atendentes que não tem agendas, que estejam em posto de reserva ou que estejam em rotas de cobertura.

O atendente da cobertura também precisa passar pela validação de bloqueio operacional. Para isso deve ser utilizada a função At012Blq que receberá por parâmetro os seguintes dados: Código do Atendente, Data Inicial, Data Final, Código do Local de Atendimento da Alocação. Quando o atendente não tiver restrições será retornado falso (.F.) nessa função.

At336ItOk() – Validação Item Rh Alocação

Essa função deverá validar se o Item Rh de Alocação está de fato disponível seleção considerar as condições descritas no tópico de Consultas Padrões e Validação dos Campos no item de campo Item Rh Alocação lá está detalhada a validação necessária ao campo.

At336ItEsc() – Validação Item de Escala

Essa função deverá validar se o item da escala está devidamente disponível para vínculo de atendente. Mais detalhes sobre essa validação devem ser conferidos no tópico de Consultas Padrões e Validação dos Campos no item de campo Item Escala.

At336RtOk() – Validação de Rota

Essa função deverá validar se a rota preenchida está devidamente disponível para associação com o atendente. Mais detalhes desta validação devem ser verificados no tópico Consultas Padrões e Validações dos Campos no item de campo Rota.

At740RefVl() – Gatilho para preencher valor de reforço

Essa função estará associada com os gatilhos para preenchimento do campo TFF_REFVLR no orçamento de serviços. A função deverá avaliar o preenchimento do campo TFF_PERFIM para executar a fórmula conforme mencionado no tópico “Inclusão de Reforço”.

At336FT40() – Filtro Consulta Padrão de Situação para movimentação

Filtro da consulta padrão na sx5 para restringir as situações conforme o status do dia do atendente.

At336FT41() – Filtro Consulta Padrão de Motivo de movimentação

Filtro da consulta padrão na sx5 para restringir os motivos conforme a situação inserida para o atendente.

At336StxMt() – Gatilho para campo Motivo

Gatilho do código do motivo conforme a situação inserida para o atendente. No detalhamento da regra de negócio algumas situações possuem somente um motivo podendo ser associado nestes casos, este único motivo associado precisa ser gatilhado para o campo com o código do motivo.

AtABSCliLj() – Filtro Consulta de Locais de Atendimento

Filtrar os locais conforme cliente e loja preenchidos na variável cABSCliLj. Esta variável deverá ser private e preenchida pelas rotinas que desejarem ou tiverem necessidade de filtrar os locais pelos clientes.

AtTFFMovF3() e AtTFFMovRt() – Consulta Específicas dos itens Rh Alocação

Construir a consulta específica utilizando estas funções para realizar a criação da janela e retorno do conteúdo para a associação com o campo para os itens de alocação.

AtTGYGruF3() e AtTGYGruRt() – Consulta Específica Grupo de Alocação

Construir a consulta específica utilizando estas funções para realizar a criação da janela e retorno do conteúdo para a associação com o campo para o identificador do grupo.

AtAA1MovF3() e AtAA1MovRt() - Consulta Específica

Construir a consulta específica utilizando estas funções para realizar a criação da janela e retorno do conteúdo para a associação com o campo para o código do atendente cobertura.

Tabelas Utilizadas

• AA1 – Cadastro de Atendentes
• ABB – Agendas de Alocação
• TFF – Itens de Recursos Humanos
• ABQ – Configuração de Alocação dos Contratos
• ABS – Local de Atendimento
• ABR – Manutenção de Agenda
• TW3 – Log de Movimentação
• TW4 – Dias de Execução Serviço
• TW5 – Ausências Gestão de Serviços

Protótipo de Tela

Protótipo 01

Protótipo 02

Protótipo 03

Protótipo 04

Protótipo 05

Protótipo 06

Protótipo 07

Protótipo 08

Protótipo 09

Protótipo 10

Protótipo 11

Protótipo 12

Protótipo 13

Protótipo 14

Protótipo 15

Protótipo 16

Protótipo 17

Dicionário de Dados

Arquivo: TCU – Tipo de Alocação

Arquivo: TFF - Item Rh Alocação

Arquivo: TW3 - Log de movimentação

Arquivo: TAB – Nome da Tabela

Arquivo: TAB – Nome da Tabela

Campo

Tipo

Tamanho

Valor Inicial

Mandatório

Sim (  ) Não (  )

Descrição

Título

Picture

Help de Campo

Grupo de Perguntas

Nome: FINSRF2

Consulta Padrão

Consulta: AMB