Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|
Especificação | |||
Produto | Datasul | Módulo | Compras/Estoque |
Segmento Executor | Manufatura | ||
Projeto1 | D_MAN_COM001 | IRM1 | PCREQ-518 |
Requisito1 | PCREQ-5561 | Subtarefa1 | PDRMAN-4079 |
Chamado2 |
| ||
Release de Entrega Planejada | 12.1.9 | Réplica | Não |
País | ( X ) Brasil ( ) Argentina ( ) Mexico ( ) Chile ( ) Paraguai ( ) Equador ( ) USA ( ) Colombia ( ) Outro _____________. | ||
Outros | Não se aplica |
Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos).
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".
As telas que deverão ser convertidas são listadas na sequência.
Rotina | Tipo de Operação | Opção de Menu | Regras de Negócio |
Requisições Compra/Estoque | Criação | Logística -> Compras -> Tarefas | - |
Requisições Compra/Estoque | Criação | Logística -> Estoque -> Tarefas | - |
Consulta Requisições/Solicitações | Criação | Logística -> Compras -> Consultas | - |
Consulta Requisições/Solicitações | Criação | Logística -> Estoque -> Consultas | - |
Exemplo de Aplicação:
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.
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:
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:
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:
Sobre as ações da interface (visão de itens de requisição):
Mapa de funcionalidades, partindo da listagem por itens de 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:
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:
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:
Itens:
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:
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.
Mapa de funcionalidades, partindo da cópia de itens de requisições:
Apresentados juntamente com a regra de negócio.
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:
Ela deverá retornar:
Considerações para leituras/implementações:
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).
Nome do Evento | Onde deve ser colocado | Parâmetro | Valor do Parâmetro |
---|---|---|---|
afterLoadList | Após o preenchimento da lista | Handle_ttRequestList | Handle da temp-table ttRequestList |
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:
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).
Nome do Evento | Onde deve ser colocado | Parâmetro | Valor do Parâmetro |
---|---|---|---|
afterLoadList | Após o preenchimento da lista de registros de follow-up | Handle_ttFollowUp | Handle da temp-table ttFollowUp |
afterSaveRequisicao | Depois de salvar dos dados da requisição | Rowid_requisicao | Rowid do registro criado/atualizado |
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:
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:
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)
Nome do Evento | Onde deve ser colocado | Parâmetro | Valor do Parâmetro |
---|---|---|---|
afterLoadRequisicao | Após o preenchimento dos dados da requisição (tela de consulta de requisição) | Handle_ttRequest | Handle da temp-table ttRequest |
afterLoadItemsRequisicao | Após o preenchimento dos itens da requisição (tela de consulta de requisição) | Handle_ttItRequisicaoResumida | Handle da temp-table ttItRequisicaoResumida |
afterLoadItRequisicao | Após o preenchimento do item de requisição e unidades de negócio | Handle_ttRequesItem | Handle da temp-table ttRequesItem |
Handle_ttBusUnitRequest | Handle da temp-table ttBusUnitRequest |
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)
Nome do Evento | Onde deve ser colocado | Parâmetro | Valor do Parâmetro |
---|---|---|---|
afterLoadRequisicao | Após o preenchimento dos dados da requisição | Handle_ttRequestDefault | Handle da temp-table ttRequestDefault |
afterLoadItemsRequisicao | Após o preenchimento dos itens da requisição | Handle_ttItRequisicaoResumida | Handle da temp-table ttItRequisicaoResumida |
beforeSaveRequisicao | Antes de salvar dos dados da requisição | Handle_ttRequest | Handle da temp-table ttRequest |
afterSaveRequisicao | Depois de salvar dos dados da requisição | Rowid_requisicao | Rowid do registro criado/atualizado |
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 "getCostCenter" da fch/fchmat/fchmatintegrationaccountcostcenter.p passando ttRequest.cod-estabel e ttRequestItemDefault.ct-codigo, o retorno deve ser atualizado em ttRequestItemDefault.sc-codigo
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:
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 "getCostCenter" da fch/fchmat/fchmatintegrationaccountcostcenter.p passando ttRequest.cod-estabel e ttRequestItemDefault.ct-codigo, o retorno deve ser atualizado em ttRequestItemDefault.sc-codigo
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)
Nome do Evento | Onde deve ser colocado | Parâmetro | Valor do Parâmetro |
---|---|---|---|
afterLoadItRequisicao | Após o preenchimento dos dados do item da requisição | Handle_ttRequestItemDefault | Handle da temp-table ttRequestItemDefault |
Handle_ttGenericBusinessUnit | Hanlde da temp-table ttGenericBusinessUnit | ||
beforeSaveItRequisicao | Antes de salvar dos dados do item da requisição | Handle_ttRequestItemOriginal | Handle da temp-table ttRequestItemOriginal |
Handle_ttGenericBusinessUnit | Handle da temp-table ttGenericBusinessUnit | ||
afterSaveItRequisicao | Depois de salvar dos dados do item da requisição | Rowid_it-requisicao | Rowid do registro criado/atualizado |
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).
Abaixo é apresentado o mapa de ações disponíveis através das interfaces desenvolvidas.
Não se aplica.
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.
Procedimento | html.mcc.cd1406 | html.mce.cd1406 | html.mcc.cd1420 | html.mce.cd1420 |
Descrição | Requisições de Compra/Estoque | Requisições de Compra/Estoque | Consulta de Requisições Compras/Estoque | Consulta de Requisições Compras/Estoque |
Módulo | mcc | mce | mcc | mce |
Programa base | html.mcc.cd1406 | html.mce.cd1406 | html.mcc.cd1420 | html.mce.cd1420 |
Nome Menu | Requisições Compra/Estoque | Requisições Compra/Estoque | Consulta Requisições Compras/Estoque | Consulta Requisições Compras/Estoque |
Interface | WEB | WEB | WEB | WEB |
Registro padrão | Sim | Sim | Sim | Sim |
Visualiza Menu | Sim | Sim | Sim | Sim |
Release de Liberação | 12.1.8 | 12.1.8 | 12.1.8 | 12.1.8 |
Programas
Programa | html.mcc.cd1406 | html.mce.cd1406 | html.mcc.cd1420 | html.mce.cd1420 |
Descrição | Requisições de Compra/Estoque | Requisições de Compra/Estoque | Consulta de Requisições/Solicitações | Consulta de Requisições/Solicitações |
Nome Externo | mcc/request | mcc/request | mcc/request/search | mcc/request/search |
Nome Menu/Programa | Requisições Compra/Estoque | Requisições Compra/Estoque | Consulta Requisições/Solicitações | Consulta Requisições/Solicitações |
Nome Verbalizado[1] | Manter Requisições Compra/Estoque | Manter Requisições Compra/Estoque | Consultar Requisições/Solicitações | Consultar Requisições/Solicitações |
Procedimento | html.mcc.cd1406 | html.mce.cd1406 | html.mcc.cd1420 | html.mce.cd1420 |
Template | Programa HTML | Programa HTML | Programa HTML | Programa HTML |
Tipo[2] | Tarefas | Tarefas | Consulta | Consulta |
Interface | WEB | WEB | WEB | WEB |
Categoria[3] | - | - | - | - |
Executa via RPC | Não | Não | Não | Não |
Registro padrão | Sim | Sim | Sim | Sim |
Outro Produto | Não | Não | Não | Não |
Visualiza Menu | Sim | Sim | Sim | Sim |
Query on-line | Não | Não | Não | Não |
Log Exec. | Não | Não | Não | Não |
Rotina (EMS) | - | - | - | - |
Sub-Rotina (EMS) | - | - | - | - |
Localização dentro da Sub Rotina (EMS) | - | - | - | - |
Compact[4] | - | - | - | - |
Home[5] | - | - | - | - |
Posição do Portlet[6] | - | - | - | - |
Informar os papeis com os quais o programa deve ser vinculado | - | - | - | - |
Cadastro de Papéis
Não se aplica.
[1] Nome Verbalizado é obrigatório para desenvolvimentos no Datasul 10 em diante.
[2] Tipo é obrigatório para desenvolvimento no Datasul 10 em diante
[3] Categorias são obrigatórias para os programas FLEX.
[4] Obrigatório quando o projeto for FLEX
[5] Obrigatório quando o projeto for FLEX
[6] Obrigatório quando o projeto for FLEX
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|