Informações Gerais

   Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos). 

Objetivo

Converter as telas de listagem, manutenção e detalhamento de requisições/solicitações existentes no módulo de compras/estoque que estão na tecnologia do Adobe Flex para utilizar o novo Framework HTML da TOTVS.

Obs.: Serão contempladas as interfaces referente a essas funcionalidades, do perfil "Requisitante de Estoque" e "Requisitante de Compras".

Definição da Regra de Negócio

As telas que deverão ser convertidas são listadas na sequência.

Exemplo de Aplicação:

• Alguns navegadores deixarão de suportar plug-ins em breve, como é o caso do Flash Player, utilizado para execução das interfaces Flex. Com isso existe a necessidade de migrar as interfaces para uma tecnologia compatível com os navegadores.

Listagem de Requisições

Em flex o layout da tela é o apresentado abaixo. De modo geral, a tela conterá as mesmas informações e funcionalidades.

As diferenças principais serão em função dos padrões definidos para interfaces HTML e a junção de informações referente aos papéis de "Requisitante de Estoque" e "Requisitante de Compras".

A interface do "Requisitante de Estoque" tem esse layout atual, que apresenta apenas requisições de estoque. O "Requisitante de Compras" visualiza a tela com alguns parâmetros a mais, que são apresentados na sequência e visualiza solicitações de compra e solicitações de cotação.

Parâmetros extras do papel de "Requisitante de Compras":

Para a interface HTML, a ideia é unir esses dois "perfis" em uma única tela, pois a execução não é por "perfil", como existia no Flex.

• Neste caso a listagem deverá tratar requisições de estoque, solicitações de compra e solicitações de cotação, sendo que terá parâmetros para filtrar pelas situações;
• Por padrão o usuário visualizará todas as solicitações/requisições que forem de sua responsabilidade, mas terá parâmetros para visualizar requisições de outros usuários;
• Outra diferença é que a interface permitirá a visualização de requisições/solicitação em qualquer situação (sendo que por padrão mostrariam as requisições que estão “em andamento” – Abertas ou Incompletas);
• A data a ser sugerida para visualização inicial das requisições também seguirá a mesma regra do Flex, ou seja, apresentará as requisições do último mês;
• Deverá ser respeitada a segurança por estabelecimento para apresentação das requisições;
• Deverá existir paginação para apresentação dos registros (de 50 registros);
• Outro grande diferencial é que o usuário terá duas opções para visualizar as informações nesta interface: a visão por requisição e também a visão por itens de requisição. Os filtros para busca permanecerão os mesmos nas duas visões.

A tela deverá ter o seguinte layout (quando estiver na visão por requisição):

E quando estiver na visão por item de requisição, o seguinte layout:

Através das cores será possível identificar o tipo de requisição.

A pesquisa rápida permitirá que o usuário informe os seguintes dados:

• Número da requisição: será buscado sempre por igualdade
• Item: será buscado sempre por "inicia com"
• Descrição do Item: será buscado sempre por "inicia com"

Obs.: Se usuário informou "001" na pesquisa simples, se houverem requisições com o código de item iniciando por "001" serão apresentadas, se houver requisições que a descrição do item seja "00100198", também será apresentado.

A ordenação deverá possibilitar as seguintes opções:

• Por requisição;
• Por item (somente mostrar essa opção para visualização por item);
• Por estabelecimento;
• Por tipo;
  
• Por data de requisição
• Por data de entrega (somente mostrar essa opção para visualização por item);

Através do filtro avançado o usuário terá as opções conforme protótipo abaixo:

Botão de configuração (para alternar entre as visões de requisições e itens de requisição):

Obs.: Inicialmente a tela será aberta no modo de visualização por requisição, se o usuário desejar alterar para Itens, poderá acessar essa opção através das configurações da página. Uma vez alterada, essa informação ficará nas preferências do usuário, para que dá próxima vez que acesse, a tela já seja aberta com esse modo de visualização.

Sobre as ações da interface (visão requisição):

• Adicionar requisição;

• Pesquisa simples;

• Pesquisa avançada;

• Configurar página;

• Ordenar;

• Remoção de filtros aplicados;

• Detalhar requisição;

• Alterar requisição (Usuário somente poderá alterar se tiver permissão CD1700, e se a requisição não estiver não as situações "Fechada" ou "Com Ordem");

• Eliminar requisição (Usuário somente poderá eliminar se tiver permissão CD1700, e se a requisição não estiver não as situações "Fechada" ou "Com Ordem");

• Visualizar detalhes (comentários) da solicitação;

• Follow-up da solicitação;

• Adicionar item da solicitação;

• Copiar itens de requisição;

• Visualizar mais resultados (inicialmente são apresentados só os 50 primeiros);

Mapa de funcionalidades, partindo da listagem por requisições:

Follow-up

A rotina de follow-up, deverá ser desenvolvida, de acordo com a tela existente atualmente, com a diferença que ao invés de um grid, no HTML teremos uma listagem.

A lista em cima, mostra os registros de folow-up, e os comentários de cada registro, poderão ser vistos através da opção de "Exibir detalhes", como é feito nas listagens.

O adicionar, permitirá incluir um novo follow-up.

Obs.: é importante que essa tela seja genérica, para que possa ser utilizada futuramente nos documentos de ordem de compra, pedido, etc.

Consulta de Requisições

Com o objetivo de permitir que usuários tenham acesso apenas às consultas de requisições, sem poder manuteni-las, a listagem poderá ser aberta pelo menu também no formato de consulta.

Neste caso, somente poderão ser feitas as buscas de requisições e detalhamentos, nenhuma outra ação estará permitida.

Obs.: Com a listagem em modo de consulta liberada, temos também o "Histórico de requisições" liberado para HTML.

Consultar Requisição e item

A tela de detalhe de requisições em Flex tem o layout abaixo, sendo apenas o detalhe do cabeçalho da mesma. 

O detalhamento de cada item é feito em uma tela separada com navegação.

Para as interfaces de HTML, o protótipo da tela é apresentado na sequência, além do cabeçalho da requisição ela  apresentará a listagem dos itens da mesma.

Sobre as ações que a tela disponibilizará: 

Obs.: No título já será indicado o tipo de requisição que está será sendo detalhada ou consultada.

Mapa de funcionalidades, partindo da consulta de requisições:

Observações:

• Quando for uma requisição de estoque junto com a data de entrega deverá ser apresentada a hora, neste caso o label deve ser Data/Hora Entrega;
• Os itens serão paginados de 50 em 50 registros;
• O botão de Editar só poderá estar habilitado caso o usuário tenha permissão para alterar requisição (CD1700), e ela não esteja com situação de fechada ou com ordem. O mesmo ocorre para os botões de Adicionar item, copiar itens e editar item.

A tela de detalhamento de item de requisição deverá ter o protótipo conforme abaixo:

Nesta tela será permitido voltar (que irá voltar para a tela chamadora) e editar que abrirá a tela para edição do item de requisição.

No título deverá ser apresentado o tipo de requisição ou solicitação para ser identificada facilmente: ex. Item da Requisição de Estoque 777, Item da Solicitação de Compra 888.

Quando se tratar de uma requisição de estoque junto com a data deverá ser apresentada a hora de entrega, neste caso o label deve ser Data/Hora Entrega.

O botão de Editar só poderá estar habilitado caso o usuário tenha permissão para alterar requisição (CD1700), e ela não esteja com situação de fechada ou com ordem.

Com essa tela construída, deve-ser colocar a chamada da mesma através de consulta de ordem de compra (onde há o detalhe de requisições).

Mapa de funcionalidades, partindo da consulta de item de requisições:

Manutenção de Requisições

A tela de manutenção de requisições em Flex tem o layout abaixo, sendo que possui duas visualizações, uma para o perfil de requisitante de estoque e outra para requisitante de compras (que possui a opção de selecionar o tipo de requisição: compra ou cotação).

Em HTML essa interface de inclusão/alteração de requisição/solicitação deverá ser desenvolvida conforme protótipo definido abaixo. Ela deverá englobar a inclusão de todos os tipos:

• Requisição de estoque;
• Solicitação de Compra;
• Solicitação de Cotação.

Obs.: Neste ponto é importante lembrar que se o tipo de uma requisição/solicitação for alterado é necessário re-gerar as pendências de aprovação.

O zoom de estabelecimento, assim como no Flex, deve respeitar a segurança por estabelecimento.

Na inclusão, apenas serão apresentadas as informações do cabeçalho da solicitação, já em modo de alteração, será apresentada a listagem dos itens logo abaixo do cabeçalho, com as respectivas ações para que o usuário possa manutenir os itens.

Obs: O botão de exibir detalhes mostrará a descrição complementar do item.

Para a listagem de itens deve ser utilizado o mesmo componente utilizado na consulta de requisição, com a diferença que neste caso haverá o botão para Excluir o Item.

As ações disponíveis na interface serão as seguintes:

• Salvar: Efetiva as informações da requisição no banco de dados;
• Cancelar: Cancela a ação que está sendo realizada (e volta para a tela anterior, de listagem ou nenhuma - caso chamado diretamente do menu)

Itens:

• Adicionar: Abre a tela para inclusão de item
• Copiar Itens: Abre a tela para cópia de itens
• Detalhar item: Abre a tela de consulta de item de requisição
• Editar: Abre a tela de edição de item de requisição
• Excluir: Exclui o item de requisição

As sugestões de dados para tela, e questões de habilitar/desabilitar campos de tela seguirão as mesmas regras já estabelecidas para as interfaces Flex. As validações de inclusão, alteração e eliminação de registro também serão mantidas as mesmas já existentes.

Após finalizar a inclusão do cabeçalho da requisição, caso não ocorram erros, deve-se abrir a tela de inclusão de inclusão de item de requisição. Se for uma alteração, a tela deve ser fechada e retornar a tela anterior (de listagem).

Mapa de funcionalidades, partindo da inclusão de requisições:

Mapa de funcionalidades, partindo da alteração de requisições:

Manutenção de Item de Requisição:

A tela de manutenção de item de requisição no Flex tem o layout apresentado na sequência.

Para a conversão em HTML serão mantidos os mesmos campos e regras já existentes para sugestão dos dados e habilitar/desabilitar campos.

O campo de hora de entrega deverá ser visível somente para requisições de estoque.

Dessa forma a tela seguirá o protótipo abaixo. As primeiras informações a serem apresentadas são as informações da requisição (número, situação e se está aprovada).

As unidades de negócio serão validadas juntamente com as demais informações do item, assim como é feito atualmente no Flex.

As ações disponíveis na interface serão as seguintes:

• Salvar: Efetiva as informações do item da requisição no banco de dados;
• Salvar e Continuar: Efetiva as informações do item da requisição no banco de dados e prepara a tela para inclusão de um novo item. Obs.: Esse botão só estará habilitado na inclusão, na alteração deve ser desabilitado;
• Cancelar: Cancela a ação que está sendo realizada (e volta para a tela anterior, de consulta ou alteração de requisição).

Cópia de Itens de Requisição

A tela de cópia de itens de requisição que no Flex é definida conforme imagem abaixo, no HTML terá basicamente a mesma estrutura.

• No cabeçalho aparecerá o número da requisição de destino (que foi selecionada para cópia);
• Será possível informar/selecionar a requisição origem (da qual os itens serão copiados) - Esse campo terá o mesmo mesmo que a consulta de requisição;
• Será possível detalhar o item através do link existente;
• Os campos "editáveis" (quantidade, UM e data de entrega), deverão ser implementados com o componente a ser definido pelo framework para edição de campos em listagens;
• A hora de entrega só deverá ficar visível para requisições de estoque;
• O componente para seleção de cada item da listagem e selecionar todos, também deverá ser desenvolvido conforme padrões a serem definidos pelo framework.
• O link de Exibir detalhes... possibilita ao usuário visualizar a descrição complementar do item de requisição.

Mapa de funcionalidades, partindo da cópia de itens de requisições:

Protótipo de Tela

 Apresentados juntamente com a regra de negócio.

Diagrama de Ação

As telas desenvolvidas nesta especificação deverão ficar dentro do ear do módulo de compras (mcc). Essa parte das requisições ficará em um agrupador/diretório, chamado de "request".

As telas deverão utilizar os padrões do novo framework, prevendo traduções e também chamadas para tratamento de epc. Deverão haver pontos padrões de forma que seja possível por exemplo, alterar o conteúdo de um campo, criar novos ou eliminar algum.

Os campos deverão estar formatados conforme o formato definido no banco de dados.

Em todas as temp-tables que for possível, acrescentar o "epc-value" para seja possível customizar.

Listagem de requisições/itens de requisição:

A tela de requisições deverá ser construída com o nome de request.list.html.

Campos da Listagem (requisição):

Número da solicitação: requisicao.nr-requisicao
Tipo da solicitação: requisicao.tp-requis (descrição - {ininc/i03in385.i})
Estabelecimento: requisicao.cod-estabel
Data: requisicao.dt-requisicao
Aprovada: requisicao.estado (descrição - {ininc/i02in385.i})
Situação: requisicao.situacao (descrição - {ininc/i01in385.i} )
Comentários: requisicao.narrativa

Campos da Listagem (item):

Item: it-requisicao.it-codigo
Sequência: it-requisica.sequencia
Solicitação: it-requisicao.nr-requisicao
Urgente: it-requisicao.log-1
Descrição do item: item.desc-item
Situação: it-requisicao.situacao (descrição - {ininc/i01in385.i})
Requisitante: it-requisicao.nome-abrev
Aprovado: it-requisicao.estado (1 = Sim, 2 = Não)
Quantidade: it-requisicao.qt-requisitada
UM: it-requisicao.un
Data Entrega: it-requisicao.dt-entrega
Descrição complementar: it-requisicao.narrativa
Narrativa do item: item.narrativa

Filtro simples:

Requisição: requisicao.nr-requisicao (igualdade)
Estabelecimento: requisicao.cod-estabel (igualdade)
Item: it-requisicao.it-codigo (inicia com - begins)
Descrição do item: item.desc-item (inicia com - begins)

Ordenação

Requisição: requisicao.nr-requisicao
Item: it-requisicao.it-codigo
Estabelecimento: requisicao.cod-estabel
Tipo: requisicao.tp-requis

Data requisição: requisicao.dt-requisicao

Data de entrega: it-requisicao.dt-entrega

Pesquisa avançada:

Situação:
Se Se visão por requisição requisicao.situacao
Se visão por item it-requisicao.situacao
(1- Aberta, 2 - Fechada, 3 - Incompleta, 4 Com Ordem)

Aprovada:
Se visão por requisição requisicao.estado (1 = Sim, 2 = Não)
Se visão por item it-requisicao.estado (1 = Sim, 2 = Não)

Tipo: requisicao.tp-requis (1 - estoque, 2 - compras, 3 - Cotação)
Data: requisicao.dt-requisicao
Número: requisicao.nr-requisicao/it-requisicao.nr-requisicao
Estabelecimento: requisicao.cod-estabel

Requisitante:
Se visão por requisição requisicao.nome-abrev
Se visão por item it-requisicao.nome-abrev

Comentário/Descrição complementar:
Se visão por requisição requisicao.narrativa
Se visão por item it-requisicao.narrativa

Item:
Código: it-requisicao.it-codigo
Descrição: item.desc-item
Código Complementar: item.codigo-refer
Informação Complementar: item.inform-compl

Para gravação/Obtenção da configuração do usuário (se a abertura deve ser por item ou requisição) deve-se utilizar o serviço disponibilizado pelo framework.

Para saber se o usuário pode alterar requisições de outros usuários verificar: Buscar usuar-mater:  usuar-mater.cod-usuario = <usuário logado>

Se substring(usuar-mater.char-1,10,01) = "Y" tem permissão, caso contrário, não tem.

Para a segurança por estabelecimentos, deve definir no início do programa o seguinte:

&scoped-define TTONLY YES
{include/i-estab-security.i}

Dessa forma a leitura deverá ser feita (sempre considerando a tabela de estabelecimentos como tabela pai): 

FOR EACH {&ESTAB-SEC-TT} NO-LOCK:
        FOR EACH requisicao WHERE requisicao.cod-estabel = {&ESTAB-SEC-TT-FIELD}  <demais condições> NO-LOCK:
               (...)
        END.
END.

De modo geral a procedure de retorno das informações da listagem deverá receber como parâmetro:

• Informação do filtro simples;
• Qual a visão da tela: Se é por item ou requisição;
• Informações do filtro avançado (sugestão: criar uma temp-table para receber todos os campos;
• Informações de ordenação - campo de ordenação e se é ascendente/descendente (sugestão: colocar na mesma temp-table de filtro avançado);

Ela deverá retornar:

• As informações a serem apresentadas na listagem;
• Se o usuário tem permissão para alteração requisição de outros usuários;
• RowErrors.

Considerações para leituras/implementações:

• Para retorno para listagem, utilizar a mesma temp-table (com campos de ambas as listagens, preenchendo o que for necessário);
• Somente utilizar os campos de busca, se realmente foram alterados;
• Não realizar leituras à nível de "filhos" se não for necessário (Ex.: se não for utilizados filtros a nível de item para a visão por requisição, não ler a it-requisicao e item);

Incluir pontos de epc progress conforme as informações da tabela abaixo. Para a parte HTML, incluir os pontos necessários que manipular o preenchimento de campos existentes e também novos (exemplos em: http://tdn.totvs.com.br/pages/viewpage.action?pageId=185738044).

Follow-up:

A tela de follow-up deverá ser genérica, para ser utilizada através de vários tipos de documentos, por isso, ela deverá receber como parâmetro:

• Tipo do documento;
• Número do documento;
• Código do item;
• Sequência do item;
• Código do fornecedor;
• Sequência da cotação;
  
  

Criar essa interface em um diretório separado das demais funcionalidades (Ex. followup).

No caso das requisições, o tipo será o próprio tipo da requisição, o número do documento será o número da requisição, código do item, será o código do item (se estiver posicionado em algum, senão passar em branco), sequência, será a sequência do item (se estiver posicionado em algum, senão passar 0), código do emitente e sequência da cotação, passar 0.

Para buscar/gravar os dados no progress, deverá ser adapatada a procedure utilizada hoje (boin638.p - buscaTextoFollowUp) e dividir em duas ações (busca dos registros de follow-up e gravação do registro de follow-up. As novas procedures deverão ser criadas na mesma BO.

Sobre a apresentação dos campos em tela:

Origem: ttFollowUp.origem
Número: ttFollowUp.numero
Responsável: ttFollowUp.responsavel
Data: ttFollowUp.data
Hora: ttFollowUp.hora
Fornecedor: ttFollowUp.fornecedor
Item: ttFollowUp.item
Comentários: ttFollowUp.comentario

Incluir pontos de epc progress conforme as informações da tabela abaixo. Para a parte HTML, incluir os pontos necessários que manipular o preenchimento de campos existentes e também novos (exemplos em: http://tdn.totvs.com.br/pages/viewpage.action?pageId=185738044).

Consultar Requisição e Item:

A tela responsável pela consulta de requisição e detalhe de item deverá ficar dentro do diretório "request/detail", com o nome de "request.detail.html" e "request.detail.item.html", respectivamente. 

Para a parte Progress deverá ser criada uma nova API (ccp/ccapi354.p) para contemplar o retorno dos dados necessário para as consultas.

Sobre o preenchimento dos campos da requisição, deverá ser construída uma procedure (requestDetails) muito semelhante a "getDetailRequest" da fch/fchmat/fchmatdetailrequests.p:

• A diferença é que para o HTML não vamos precisar da parte de navegação existente nesta procedure;
• Também deverá ser incluso o tratamento de erros, com retorno da RowErrors quando for informado uma requisição inexistente;
• A procedure somente precisará receber como parâmetro o número da requisição e retornar a ttRequest (que terá os mesmos campos do programa citado);
  
• Para preenchimento das descrições trocar a forma como é feito do programa citado, por FOR FIRST com cláusula FIELDS.
• Além das informações da requição a procedure deverá retornar também se a requisição pode ser editada ou não (para saber se o botão editar deve ser desabilitado). Para saber, verificar o boin385fx.p (validateBtUpdateRequest), ao invés das mensagens de erro alimentar a variável lógica para habilitar ou não. Obs.: Criar uma procedure separada para conter essa lógica, pois será utilizada em outros locais.

Sobre os campos a serem apresentados em tela:

Tipo (título): tp-requis-desc
Número: nr-requisicao
Situação: situacao-desc
Aprovada: estado-desc
Requisitante: nome-abrev e nome-abrev-desc
Local Entrega: loc-entrega
Comentários: narrativa

Para buscar os itens de requsição, deverá ser realizada uma uma nova busca, para que seja possível paginar o retorno dos dados. Criar uma procedure "requestItems", que faça a utilização da BO inbo/boin168nafx.p (procedure setConstraintItemsOfRequest e openQueryItemsOfRequest) para obter os dados. Para paginação será necessário utilizar o getBatchRecords da BO (paginar por 50 registros) e depois de obter os dados preencher os campos de descrições nas procedure requestItems. É importante que esse componente de itens seja um HTML separado, pois será utilizado posteriormente na edição de requisição também (criar como requestitems.detail.html).

Para os itens, é importante retornar também é permitida a edição ou não, para desabilitar os botões de inclusão, cópia e edição.

Itens (criar ttRequesItem):

 Mostrar quantidade total retornada do getBatchRecords;

Sequência - código do item: sequencia, it-codigo
Descrição do item: item.desc-item (buscar pelo item.it-codigo = it-requisicao.it-codigo)
Referência: cod-refer
UN: un
Quantidade: qt-requisitada
Data Entrega: dt-entrega, hra-entrega (quando for de estoque mostrar hora também)
Situação: situacao-desc (verificar como preencher na procedure getRequestItem da fch/fchmat/fchmatdetailrequests.p)
Urgente: log-1
Aprovado: estado-desc (verificar como preencher na procedure getRequestItem da fch/fchmat/fchmatdetailrequests.p)
Descrição Complementar: narrativa

Narrativa do item: item.narrativa

Sobre o preenchimento dos campos de detalhe de item de requisição, deverá ser construída uma procedure (requestItemDetails) muito semelhante a "getRequestItem" da fch/fchmat/fchmatdetailrequests.p:

• A diferença é que para o HTML não vamos precisar da parte de navegação existente nesta procedure;
• Também deverá ser incluso o tratamento de erros, com retorno da RowErrors quando for informado um item de requisição inexistente;
• A procedure precisará receber como parâmetro o número da requisição, a sequência do item, e código do item;
  
• Deverá retornar um DataSet com a temp-table com os campos da ttRequestItem e ttBusUnitRequest;
• Para preenchimento das descrições trocar a forma como é feito do programa citado, por FOR FIRST com cláusula FIELDS.

Para a leitura da tabela principal utilizar it-requisicao, com it-requisicao.sequencia = <sequência> e it-requisicao.it-codigo = <código item> e it-requisicao.nr-requisicao = <número requisição>.

Para leitura das unidades de negócio usar: unid-neg-requis, com unid-neg-requis.nr-requisicao = <número requsição> e unid-neg-requis.sequencia = <sequencia> e unid-neg-requis.it-codigo = <código do item>.

Se não houver nenhum registro a ser preenchido com essa leitura, criar um registro manualmente na temp-table se o campo "cod-unid-negoc" tiver valor diferente de branco, verificar lógica de preenchimento no programa.

Sobre os campos a serem apresentados em tela (Utilizando como base a definição da ttRequestItem do programa de exemplo):

Tipo e número no título: Será necessário incluir os campos " tp-requis" e "tp-requis-desc" (localizar a requisição para preenchê-los). Número: nr-requisicao
Sequência: sequencia
Requisitante: nome-abrev e nome-abrev-desc (esse último será necessário criar e preencher também)
Situação: situacao-desc
Aprovada: estado-desc

Item (código e descrição): it-codigo e desc-item

Referência: cod-refer e cod-refer-desc

Quantidade: qt-a-atender
Un: un e un-desc
Preço Unitário: preco-unit
Data Entrega e Hora: dt-entrega e hra-entrega
Descrição Complementar: narrativa

Narrativa do item: item.narrativa

Ordem Investimento: num-ord-inv
Empresa (código e descrição): ep-codigo e ep-codigo-desc

Código de Utilização (código e descrição): utilizationCode e utilizationCodeDesc (Esses são os nomes da temp-table atual, sugriro colocar cod-utilizacao e cod-utilizacao-desc
Conta (código e descrição): ct-codigo e ct-codigo-desc
Centro de custo (código e descrição): sc-codigo e sc-codigo-desc

Urgente: log-1
Homologa Fornecedor: log-2
Afeta Qualidade: impactsQuality (Esse é o nome na temp-table atual, sugro colcoar afeta-qualidade)
Prioridade Aprovação: prioridade-aprov-desc

Quantidade Atendida: qt-atendida
Quantidade Devolvida: qt-devolvida
Quantidade a Atender: qt-a-atender
Quantidade a Devolver: qt-a-devolver

Preço Total: val-item

Data Atendimento: dt-atend

Depósito (código e descrição): cod-depos e cod-depos-desc
Localização (código e descrição): cod-localiz e cod-localiz-desc
Lote e Série: lote

Ordem de compra: numero-ordem

Unidade (código e descrição): cod_unid_negoc e des-unid-negoc
Percentual: perc-unid-neg

Incluir pontos de epc progress conforme as informações da tabela abaixo. Para a parte HTML, incluir os pontos necessários que manipular o preenchimento de campos existentes e também novos (exemplos em: http://tdn.totvs.com.br/pages/viewpage.action?pageId=185738044)

Manutenção de Requisições:

A tela responsável pela inclusão/alteração de requisição deverá ficar dentro do diretório "request/edit", com o nome de "request.edit.html".

Para sugestão dos dados iniciais para inclusão da requisição utilizar a procedure "setDefaults" da fch/fchmat/fchmatenterrequests.p. 

Para inclusão (primeira vez que que os dados são apresentados), passar "create" para o parâmetro "pType", deixar em branco o valor para o parâmetro "pFieldName", e passar YES para o campo "pConsideraRequisEstoque". Para a ttRequest neste caso não é preciso passar as informações, a ttRequestDefault conterá os campos a serem apresentados em tela (conforme informações abaixo). A ttEnableFields conterá os campos que possuem alguma regra para habilitar os desabilitar em tela (nr-requisicao, cod-estabel, tp-requis). Utilizar essa informação para habilitar ou não ou campos.

Sobre os campos:

Requisição: nr-requisicao (Campo obrigatório)
Situação: situacao-desc
Aprovada: estado-desc
Estabelecimento: cod-estabel (Campo obrigatório) (Utilizar o zoom já existente). Além do zoom, sugerir as informações na digitação do usuário (pelos campos de cod-estabel e nome).

Requisitante: nome-abrev (Campo obrigatório) (Zoom requisitante, Campos: requisitante.nome-abrev, requisitante.nome, requisitante.limite-requis, requisitante.limite-solic, moeda.descricao, requisitante.tp-preco - campo indicativo, mostrar descrição, requisitante.sc-codigo, requisitante.telefone - mostrar primeiro campo do extent, requisitante.ramal -  mostrar primeiro campo do extent, Filtros: requisitante.nome-abrev, requisitante.nome). Além do zoom, sugerir as informações na digitação do usuário (pelos campos de nome e nome-abrev).

Data Requisição: dt-requisicao (Campo obrigatório)
Local de Entrega: loc-entrega
Tipo: tp-requis (1 - Requição estoque, 2 - Solicitação Compra, 3 - Solicitação Cotação) (Campo obrigatório)
Comentários: narrativa

Na alteração de requisição deverá ser chamada uma procedure para buscar os dados da requisição (getRequest da mesma fachada) e logo em seguida a setDefaults, passando o tipo como "update". Neste caso criar uma procedure na API com o nome de getRequestToUpdate que deverá executar a chamada das duas procedures junto. Neste caso evitamos fazer duas chamadas distintas ao appserver. Lembrando que a procedure setDefaults neste caso deverá receber os dados da ttRequest retornada pela procedure getRequest.

Para salvar o registro, deve-se utilizar o método createUpdateRequest da mesma fachada, passando o tipo ("CREATE" para criação e "UPDATE" para atualização), será retornada a RowErrors no caso de ocorrência de erros na criação ou atualização. Quando for uma inclusão de registro, ao finalizar, se não ocorreu nenhum erro, deve ser aberta a tela de inclusão de item de requisição.

Quando for a alteração de um registro, caso tenha sido alterado o tipo de requisição/solicitação da mesma, será necessário após chamar os métodos para salvar o registro, executar as lógicas para gerar as pendências de aprovação. Neste caso a sugestão é que para salvar, seja criada uma procedure que irá englobar essas chamadas.

A lógica para executar a geração de pendências de aprovação, pode ser verificada na "pi-aprovacao" do cdp/cd1406a-v01.w.

Incluir pontos de epc progress conforme as informações da tabela abaixo. Para a parte HTML, incluir os pontos necessários que manipular o preenchimento de campos existentes e também novos, assim como permitir gravar valores novos da interface (exemplos em: http://tdn.totvs.com.br/pages/viewpage.action?pageId=185738044)

Manutenção de Item de Requisição:

A tela de inclusão/alteração de item de requisição ficará no mesmo diretório que de manutenção de requisição, com o nome de "request.edit.item.html".

Para sugestão dos dados iniciais para inclusão do item da requisição deverá ser criada uma nova procedure que englobe a execução/retornos das seguintes rotinas:

• Procedure "getRequest" da fch/fchmat/fchmatenterrequests.p (para trazer os dados da requisição - cabeçalho);
• Procedure, "getIntegrationAccountCostCenterFilter" da fch/fchmat/fchmatintegrationaccountcostcenter.p para obter os "filtros" para conta/centro de custo. Na temp-table de entrada preencher o campo "site" com ttRequest.cod-estabel e o campo "module" com "CEP". Providenciar o retorno até a interface do HTML, pois essa informações serão necessárias para chamar o zoom de conta e centro de custo posteriormente.
• Procedure, "setItemDefaults" da fch/fchmat/fchmatenterrequests.p (Esse método funciona da mesma forma que o setDefaults do cabeçalho, inicialmente passar como campo o "it-codigo");
• Procedure "enableCostCenter" da fch/fchmat/fchmatintegrationaccountcostcenter.p, com o retorno dessa procedure será necessário criar um registro na ttEnableFields com as seguintes informações:
  ttEnableFields.tabela = "it-requisicao"
  ttEnableFields.campo = "sc-codigo"
  ttEnableFields.habilitado = <retorno da procedure acima>.
  
  Caso não o centro de custo não deva ser habilitado, deve-se limpar o código do mesmo também: ttRequestItemDefault.sc-codigo = "".

• Procedure "getCostCenter" da fch/fchmat/fchmatintegrationaccountcostcenter.p passando ttRequest.cod-estabel e ttRequestItemDefault.ct-codigo, o retorno deve ser atualizado em ttRequestItemDefault.sc-codigo

• Procedure "getVisibleBusinessUnit" da fch/fchmat/fchmatenterrequests.p (para saber se as informações de Unidade de negócio devem estar visíveis em tela ou não).

Sobre os campos:

Utilizar o tipo no título: Será necessário incluir os campos " ttRequest.tp-requis" e "ttRequest.tp-requis-desc"
preenchê-los).

Número: ttRequest.nr-requisicao
Situação: ttRequest.situacao-desc
Aprovada: ttRequest.estado-desc

ttRequestItem

Sequência: sequencia
Item: it-codigo (Utilizar o zoom criado pela equipe de Materiais)
Referência: cod-refer (Zoom referencia, Campos: cod-refer, descricao, subproduto, Filtro: cod-refer, descricao, subproduto (campo lógico)) - Utilizar BO. Além do zoom, sugerir as informações na digitação do usuário (pelos campos de cod-refer e descricao).
Quantidade: qt-requisitada
Un: un (Zoom tab-unidade, Campos: un e descricao, Filtro: un e descricao) - Utilizar BO. Além do zoom, sugerir as informações na digitação do usuário (pelos campos de un e descricao).
Data Entrega e Hora: dt-entrega e hra-entrega
Preço Unitário: preco-unit
Descrição Complementar: narrativa
Ordem Investimento: num-ord-inv (Zoom sub-div-ordem, Campos: sub-div-ordem.cod-est-exec, sub-div-ordem.num-projeto, proj-inv.descricao, sub-div-ordem.num-secao, secao-inv.descricao, sub-div-ordem.ep-codigo, sub-div-ordem.num-ordem, ordem-inv.descricao, sub-div-ordem.cod-sub-espec, sub-espec.descricao, sub-div-ordem.vl-estimado, sub-div-ordem.usuario-atu, sub-div-ordem.cod-id-solum, sub-div-ordem.vl-reestimado, sub-div-ordem.num-ord-magnus, sub-div-ordem.cod-especialidade, especialidade.descricao, sub-div-ordem.prazo-pagto, sub-div-ordem.cod-origem, sub-div-ordem.dt-atualizacao, sub-div-ordem.observacao, sub-div-ordem.tempo-pagto Filtros: sub-div-ordem.cod-est-exec, sub-div-ordem.num-projeto, sub-div-ordem.num-secao, sub-div-ordem.ep-codigo, sub-div-ordem.num-ordem, sub-div-ordem.cod-sub-espec, sub-div-ordem.usuario-atu, sub-div-ordem.cod-id-solum, sub-div-ordem.num-ord-magnus, sub-div-ordem.cod-especialidade, sub-div-ordem.prazo-pagto, sub-div-ordem.cod-origem, sub-div-ordem.observacao)
Empresa (código e descrição): sub-div-ordem.ep-codigo (Depende do zoom)
Código de Utilização: utilizationCode (Zoom utilizacao-mater, Campos: cod-utiliz, des-utiliz, Filtro: cod-utiliz, des-utiliz) - Utilizar BO. Além do zoom, sugerir as informações na digitação do usuário (pelos campos de cod-utiliz e des-utiliz).
Conta: ct-codigo (Utilizar o zoom a ser criado pela equipe de Finanças) - Atentar para os parâmetros que será necessário passar o zoom
Centro de custo: sc-codigo (Utilizar o zoom a ser criado pela equipe de Finanças) - Atentar para os parâmetros que será necessário passar o zoom
Urgente: log-1
Homologa Fornecedor: log-2
Afeta Qualidade: impactsQuality
Prioridade Aprovação: prioridade-aprov-desc

ttrequestItemBusUnit

Unidade: cod_unid_negoc e des-unid-negoc
Percentual: perc-unid-neg

Para saber as Unidades de negócio que podem ser selecionadas pelo usuário utilizar a procedure "getBusinessUnits" da fch/fchmat/fchmatenterrequests.p.

No leave dos campos definidos abaixo deve-se executar o método "setItemDefaults", passando a ação (criação, alteração), o campo que sofreu o leave, e as temp-tables atualizadas com os valores de tela. O retorno deverá atualizar os dados das temp-tables em tela novamente e também executar a lógica para habilitar/desabilitar campos. Os Campos que devem executar o leave:

• Item;
• Ordem de Investimento;
• Código de Utilização;
• Conta; 
• Centro de Custo;
  
  

Obs.: A chamada do método não deverá ser realizada diretamente, deverá ter uma procedure para fazer essa chamada, pois após a chamada do "setItemDefaults" deverá ser chamada também o "enableCostCenter" da fch/fchmat/fchmatintegrationaccountcostcenter.p, com o mesmo tratamento feito para a criação. Se for uma criação, executar também o "getCostCenter" da mesma forma que na criação para sugestão dos dados.

Na alteração de item de requisção deverá ser criada uma procedure para englobar as seguintes rotinas:

• Procedure "getRequest" da fch/fchmat/fchmatenterrequests.p (para trazer os dados da requisição - cabeçalho);
• Procedure, "getIntegrationAccountCostCenterFilter" da fch/fchmat/fchmatintegrationaccountcostcenter.p para obter os "filtros" para conta/centro de custo. Na temp-table de entrada preencher o campo "site" com ttRequest.cod-estabel e o campo "module" com "CEP". Providenciar o retorno até a interface do HTML, pois essa informações serão necessárias para chamar o zoom de conta e centro de custo posteriormente.
• Procedure "getRequestItem" da fch/fchmat/fchmatenterrequests.p (Para trazer os dados do item da requisição e unidades de negócio);
• Procedure "setItemDefaults" da fch/fchmat/fchmatenterrequests.p (Esse método funciona da mesma forma que o setDefaults do cabeçalho);
• Procedure "enableCostCenter" da fch/fchmat/fchmatintegrationaccountcostcenter.p, com o retorno dessa procedure será necessário criar um registro na ttEnableFields com as seguintes informações:
  ttEnableFields.tabela = "it-requisicao"
  ttEnableFields.campo = "sc-codigo"
  ttEnableFields.habilitado = <retorno da procedure acima>.
  
  Caso não o centro de custo não deva ser habilitado, deve-se limpar o código do mesmo também: ttRequestItemDefault.sc-codigo = "".

• Procedure "getCostCenter" da fch/fchmat/fchmatintegrationaccountcostcenter.p passando ttRequest.cod-estabel e ttRequestItemDefault.ct-codigo, o retorno deve ser atualizado em ttRequestItemDefault.sc-codigo

• Procedure "getVisibleBusinessUnit" da fch/fchmat/fchmatenterrequests.p (para saber se as informações de Unidade de negócio devem estar visíveis em tela ou não).
  
  

Para salvar o registro, deve-se utilizar o método createUpdateRequestItem da mesma fachada, passando o tipo ("CREATE" para criação e "UPDATE" para atualização), será retornada a RowErrors no caso de ocorrência de erros na criação ou atualização.

Quando for uma inclusão de registro, ao finalizar com sucesso, no caso de "Salvar e Continuar", deverá ser aberta a tela para inclusão de um novo registro. No caso de salvar, deverá retornar para a tela chamadora.

Quando cancelar a inclusão de um registro, caso já tenha sido incluído (salvo) um item antes, ou seja, é o cancelar após a utilização do "Salvar e Continuar", será necessário, chamar o método "updatePurchaseMlaPendence" e "totalEletronicApproval" da fch/fchmat/fchmatenterrequests.p para atualizar as informações de aprovação (neste caso, criar uma procedure para englobar as duas chamadas).

Ao fechar a tela após "Salvar" com sucesso, deverá ser chamada a rotina para executar a aprovação por total. Para esse caso chamar a procedure "totalEletronicApproval" da fch/fchmat/fchmatenterrequests.p.

Incluir pontos de epc progress conforme as informações da tabela abaixo. Para a parte HTML, incluir os pontos necessários que manipular o preenchimento de campos existentes e também novos, assim como permitir gravar valores novos da interface (exemplos em: http://tdn.totvs.com.br/pages/viewpage.action?pageId=185738044)

Cópia de Itens de Requisição

A tela responsável pela cópia de itens de requisição  deverá ficar dentro do diretório "request/edit", com o nome de "request.copy.item.html". 

Para carregar os itens da requisição, utilizar a procedure "getSummaryRequestItem" da fch/fchmat/fchmatenterrequests.p.

Sobre os campos:

Item: it-codigo
Descrição do Item: desc-item
Quantidade: qt-requisitada
UM: un
Data Entrega: dt-entrega

Hora: hra-entrega
Conta: ct-codigo
Centro Custo: sc-codigo
Descrição Complementar: narrativa

Para efetivar a cópia para a requisição destino utilizar a procedure "copyItemRequest" da fch/fchmat/fchmatenterrequests.p, passando apenas os itens que foram selecionados em tela, com as informações de tela (caso tenham sido alteradas).

Opcional

Fluxo do Processo

 Abaixo é apresentado o mapa de ações disponíveis através das interfaces desenvolvidas.

Opcional

Dicionário de Dados

Não se aplica.

Estrutura de Menu

Procedimentos

Para que seja possível incluir os programas nos menus de compras e estoque, as entradas de menu serão duplicadas, conforme definição abaixo.  

Obs.: Internamente será chamado o mesmo programa. 

Programas

Cadastro de Papéis

Não se aplica.