(Obrigatório)

Informações Gerais

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

(Obrigatório)

Objetivo

• Desenvolver a tela de atendimento de solicitações de compra/cotações em HTML.
  

Requisitos:

• Listar solicitações pendentes de atendimento pelo comprador;
• Permitir que na listagem itens de requisição seja visualizado e filtrado por prioridade de aprovação além do campo urgente (Origem do chamado TUYMCK);
• Gerar ordens de compra com base em requisições pré-selecionadas;
• Permitir que a geração de ordens de compra seja direcionadas para um único comprador (centralizador) (Origem do chamado TTL956);
• Permitir que a geração de ordens de compra seja direcionada para um comprador alternativo na ausência do principal (Origem do chamado TTHTVQ);
• Permitir que o campo de preço do item seja ocultado no momento da inclusão de requisição de compra (Origem do chamado TIFQ95)

Requisitos que não serão atendidos:

• Apresentação das ordens de compra gerada em formato de arquivo (.pdf) e abertura de tela de ordens com as mesmas geradas (isto será desenvolvido em um requisito posterior);
• Transferência de ordens de compra entre compradores (isto será desenvolvido em um requisito posterior);
• Geração de ordens de compra para compradores alternativos ou centralizador em rotinas já existentes (Flex e Progress);
• Ocultar o preço do item na inclusão de requisição compra em rotinas Flex e Progress;

(Obrigatório)

Definição da Regra de Negócio

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.

Detalhamento das regras de negócio

A solução proposta consiste em desenvolver as telas propostas com o novo Framework HTML da TOTVS, com as mesmas funcionalidades existentes no Flex atualmente, assim como incluir alguns pequenos itens de melhoria sugeridos por clientes e citados nos requisitos. 

1) Listagem de solicitações pendentes de atendimento pelo comprador:

Consiste na conversão da tela existente em Flex, de atendimento de requisições para a tecnologia HTML, considerando todas as funcionalidades existentes.

A listagem de solicitações pendentes deverá ter o layout conforme apresentado na sequência. Os itens serão categorizados conforme o prioridade de aprovação definida para os mesmos (Baixa, Média, Alta ou Muito Alta).

Listagem com a apresentação dos detalhes:

Atualmente, em flex, o usuário comprador somente tem acesso a visualizar os itens de requisição que estão sob sua responsabilidade ou aos grupos de compra ao qual pertence, isso causa uma restrição caso seja necessário gerar ordens de compra para outro usuário (que é possível através do CC0325). Por isso, por padrão a tela mostrará somente os itens de responsabilidade de atendimento pelo próprio usuário, porém através dos filtros (de comprador) ele poderá visualizar itens sob responsabilidade de outro comprador.

Através do "Filtro avançado" o usuário terá acesso a tela apresentada na sequência, onde terá acesso aos mesmos filtros de possui no Flex, mais os seguintes filtros:

• Comprador;
• Somente solicitações alternativas;
• Prioridade de aprovação;
• Descrição complementar do item;
• Código complementar;
• Informação complementar;

O filtro simples deverá permitir a busca por solicitação, código do item e descrição do item.

Como opções de ordenação, deverão ser disponibilizadas as seguintes opções:

• Data Entrega;
• Item;
• Solicitação (será a padrão - como ascendente);
• Estabelecimento;
• Prioridade de aprovação;
• Urgência;

Na parte da listagem das informações além das informações já apresentadas no flex, deverão ser apresentadas também:

• Prioridade de aprovação;
• Narrativa do Item;
• Narrativa da solicitação;

Na listagem o usuário poderá realizar as seguintes ações:

• Atender: Caso utilizado o botão da parte superior da tela, será executada a rotina para atendimento dos itens selecionados, com a abertura da tela de configuração de geração de ordens (detalha no tópico a seguir);
• Detalhar Item: Disponível através do link de título, abrirá a tela de detalhe de item de requisição, já liberada no produto;
• Mudar situação para incompleta: essa opção estará disponível através da edição do campo "situação";
• Acessar o follow-up: Abrirá a tela de follow-up, já liberada no produto. Através dela o comprador poderá por exemplo informar o motivo pelo qual mudou a solicitação para incompleta (por falta de alguma informação específica). Obs.: Essa opção não existia na tela flex;
• Detalhar requisição: Abrirá a tela de detalhe de requisição, já liberada no produto. Obs.: Essa opção não existia na tela flex; 

A listagem apresenta somente:

• Itens de requisição aprovados;
• Na situação aberta ou incompleta;
• Somente solicitações de compra e cotação;
• Inicialmente somente requisições com data dos últimos 30 dias;
• Se o sistema estiver configurado para gerar ordens de compra conforme o "Comprador" (CC0104):
  • Somente deverá apresentar itens de solicitação que pertençam a faixa de compradores informados em tela;
• Se o sistema estiver configurado para gerar ordens de compra conforme o "Grupo de Compra" (CC0104):
  • Somente deverá apresentar itens de solicitação em que algum comprador da faixa informada pertença ao grupo de compra do item da solicitação;

• Se o parâmetro "Somente solicitações alternativas" for marcado, deve apresentar somente solicitações para o qual o usuário logado é comprador alternativo (Mais detalhes sobre o cadastro do comprador alternativo no tópico a seguir) na data em questão;
  
  

Informações técnicas sobre listagem de requisições:

• Campos a serem utilizados:
  • Título: Solicitação - Sequência - Código do Item: it-requisicao.nr-requisicao, it-requisicao.sequencia, it-requisicao.it-codigo
  • Desc Item: item.desc-item
  • UM: it-requisicao.un
  • Situação: {ininc/i02in274.i 04 it-requisicao.situacao} (deverá ser utilizado o totvs-editable para possibilitar a alteração do campo através de um combo-box)
  • Quantidade: it-requisicao.qt-requisitada
  • Estab: requisicao.cod-estabel
  • Requisitante: it-requisicao.nome-abrev
  • Urgente: it-requisicao.log-1
  • Data Entrega: it-requisicao.dt-entrega
  • Descrição complementar do item da solicitação: it-requisicao.narrativa
  • Narrativa solicitação: requisicao.narrativa
  • Narrativa do Item: requisicao.narrativa
  • Prioridade de aprovação: it-requisicao.prioridade-aprov (verificar os valores que definem cada prioridade em itRequisicaoAfterFill da ccp/ccapi354.p)
• Para apresentação dos dados a ideia é utilizar a mesma API já existente para listagem de requisições no html.mcc.cd1406, ou seja, a ccp/ccapi354.p (procedure REST_POST_getListRequests, que precisará de algumas adaptações);
  • Alguns parâmetros deverão ser fixados com valores e outros deverão ser preenchidos conforme informado em tela:
    • Modo de listagem deve ser de itens (ou seja, ttListParameters.sight = 1);
    • Ordenação conforme tela (ttListParameters.sortBy e ttListParameters.orderAsc);
    • Filtro simples conforme tela (ttListParameters.basicFilter);
    • Para paginação passar os campos ttListParameters.cCodEstabelec, ttListParameters.rLastRequestRowid e ttListParameters.rLastRequestItRowid da mesma forma como é feito no html.mcc.cd1406);
    • Situações: ttListParameters.statusOpen (conforme tela), ttListParameters.statusIncomplete (conforme tela), ttListParameters.statusClosed (fixo NO), ttListParameters.statusWithOrder (fixo NO);
    • Estado: ttListParameters.approved (fixo YES), ttListParameters.notApproved (fixo NO);
    • Tipo: ttListParameters.inventoryRequest (fixo NO), ttListParameters.purchaseRequest (conforme tela), ttListParameters.quotationRequest (conforme tela);
    • Data requisição (ttListParameters.dateIni e ttListParameters.dateEnd conforme tela);
    • Requisição (ttListParameters.requestNumberIni e ttListParameters.requestNumberEnd conforme tela);
    • Estabelecimento (ttListParameters.siteIni e ttListParameters.siteEnd conforme tela);
    • Requisitante (ttListParameters.requestIni e ttListParameters.requestEnd conforme tela);
    • Item (ttListParameters.itemCodeIni e ttListParameters.itemCodeEnd conforme tela);
    • Descrição do item (ttListParameters.itemDescriptionIni e ttListParameters.itemDescriptionEnd conforme tela);
    • Descrição complementar (ttListParameters.itemCompCodeIni e ttListParameters.itemCompCodeEnd conforme tela);
    • Informação complementar (ttListParameters.itemCompInfoIni e ttListParameters.itemCompInfoEnd conforme tela);
    • Hoje só há um campo de narrativa, que é usado para narrativa da solicitação ou narrativa do item da solicitação (conforme estado da tela). Esse campo deverá ser separado em dois na ccapi354.p para contemplar a nova tela (campo atual ttListParameters.description).
  • Será necessário implementar mais dois tipos de ordenação na listagem: por prioridade de aprovação (it-requisicao.prioridade-aprov) e por urgência (it-requisicao.log-1);
  • Será necessário implementar nos filtros as informações:
    • Um campo para indicar que é referente ao atendimento de requisições. Nesta nova tela o valor deverá ser enviado como YES, e na tela já existente como NO;
    • Prioridade de aprovação, com as 4 opções. Nesta nova tela os valores deverão ser enviados conforme os parâmetros de tela, mas deve-se tomar o cuidado para que na tela existente envie sempre os 4 campos como YES.
    • Comprador: Nesta nova tela os valores deverão ser enviados conforme os parâmetros de tela, mas deve-se tomar o cuidado para que na tela existente envie sempre a faixa aberta.
    • Geração por grupo de compra (param-compra.int-2 = 1):
      • Se <comprador inicial> = <comprador final>:
        • Mostrar o item da solicitação se o comprador pertencer ao grupo de compra do item (ou seja, se encontrar gr-cmp-comprad onde gr-cmp-comprad.cod-comprado = <comprador> e gr-cmp-comprad.cod-grp-compra = it-requisicao.cod-grp-compra.
          
          
      • Se <comprador inicial> <> <comprador final>:
        • Mostrar o item da solicitação se existir na faixa informada um comprador que pertença ao grupo de compra do item (ou seja, se encontrar gr-cmp-comprad onde gr-cmp-comprad.cod-comprado >= <comprador inicial> e gr-cmp-comprad.cod-comprado <= <comprador final> e gr-cmp-comprad.cod-grp-compra = it-requisicao.cod-grp-compra.
    • Geração por comprador (param-compra.int-2 = 2):
      • Se <comprador inicial> = <comprador final>:
        • Mostrar o item da solicitação se it-requisicao.cod-comprado = <comprador>

• • • • Se <comprador inicial> <> <comprador final>:
        • Mostrar o item da solicitação se it-requisicao.cod-comprado >= <comprador inicial> e  it-requisicao.cod-comprado <= <comprador final> 

• • • Comprador alternativo: Se marcado para mostrar apenas os compradores alternativos, verificar se existe cmprdor-altern onde o comprador alternativo (cod-cmprdor-altern) seja igual ao usuário logado e a data de validade esteja dentro da data atual. Neste caso para as regras descritas acima, deve-se verificar se o comprador (cod-comprado) é comprador do item ou faz parte do grupo de compra para que a solicitação seja apresentada.
      Obs.: Se houver faixa de comprador informado neste caso, somente considerar o registro se o cod-comprado estiver dentro da faixa informada.
• Para a troca de situação da requisição, utilizar a rotina já existente: fch/fchmat/fchmatpurchrequestprocess.p (procedure changeStatus).

2) Cadastro do Comprador Alternativo:

 Será necessária a criação de um cadastro de comprador alternativo (que será um para um), ou seja, somente um comprador alternativo para cada comprador, com data de validade de início e término para o mesmo.

 As telas deverão ser desenvolvidas conforme protótipos abaixo, e gravarão os dados na nova tabela criada (especificada no tópico de dicionário de dados).

A busca simples deverá fazer a busca por comprador e comprador alternativo, já a busca avançada, deverá ter faixas dos 4 campos do cadastro.

Na inclusão de comprador alternativo, deverão ser feitas as seguintes validações:

• Somente pode haver um comprador alternativo por comprador;
• A data final não pode ser menor que a data inicial;
• O comprador deve ser um comprador válido (cadastrado);
• Não pode ser informado o mesmo usuário como comprador e como alternativo;

Deverá ser construído um zoom de comprador (para ser utilizado nos dois campos), que deverá apresentar:

• Comprador;
• Nome do comprador;
• Limite Compra;
• Moeda;

Como filtros deverão ser disponibilizadas as opções:

• Comprador;
• Nome;

Informações técnicas sobre comprador alternativo:

• A tela nova deverá ficar ficar na estrutura de menu dts/mcc/alternativebuyer, com o nome de html.cc0122.
• Utilizar as tabelas e campos conforme definidos no tópico de dicionário de dados;
• Para busca e efetivação dos dados deverá ser criada a BO da nova tabela em questão e utilizada.
• O zoom de comprador deverá utilizar a tabela comprador e campos: cod-comprado, nome, lim-compra, mo-codigo.
  
  

3) Geração de ordens de compra com base em requisições pré-selecionadas:

 A geração de ordens, consiste em desenvolver a tela de configuração de ordem de compra conforme protótipo abaixo, assim como existe no Flex, com algumas novas opções conforme detalhado na sequência.

Com relação as novas opções da geração de ordens de compra, elas dizem respeito principalmente a "quem" elas devem ser direcionadas:

• Se o sistema estiver configurado para gerar ordens de compra por grupo de compra:
  • Serão habilitadas as opções de "Grupo de Compra" e "Comprador específico" (juntamente com o zoom de comprador);
• Se o sistema estiver configurado para gerar ordens de compra por comprador:
  • Serão habilitadas as opções de "Comprador Responsável pelo Item" e "Comprador específico" (juntamente com o zoom de comprador);

• Como irão funcionar essas opções na geração de ordens de compra:
  • Grupo de compra: gerará as ordens de compra vinculadas ao grupo de compra do item da requisição
  • Comprador Responsável pelo Item: gerará as ordens de compra vinculadas ao comprador do item da requisição
    • Neste caso, quando houver um comprador alternativo cadastrado, todas as ordens de compra que deveriam ser direcionadas para o comprador principal, serão direcionadas para o seu alternativo;
    • Para que seja possível identificar que a ordem foi gerada para um comprador alternativo, será armazenado um campo com o comprador original da ordem, pois o campo de comprador ficará sempre com a informação de que comprador está atendendo a ordem no momento;
    • No caso de necessidade de transferência de ordens, fora desse período que há um comprador alternativo, para devolver as ordens para o comprador principal por exemplo, deverá ser utilizada uma rotina de transferência, a ser construída no próximo requisito;
  • Comprador específico: gerará as ordens de compra para o comprador especificado do campo abaixo.
    • Necessário validar se o comprador informado é válido;
    • Caso este comprador seja usuário que irá centralizar as ordens de compra para depois delegar para outros usuários, no requisito de ordem de compra será prevista uma rotina de transferência de ordens, que poderá ser utilizada com esse intuito.

• As demais opções da tela devem funcionar como já era feito do Flex anteriormente.

Na consulta de ordem de compra deverá ser incluído o campo de comprador original, que deverá estar visível apenas se houver valor:

Após a geração das ordens de compra, as ordens geradas serão apresentadas em um relatório a ser gerado em Birt, com a opção de geração em planilha (xlsx).

A ideia é que esse relatório possa ser reaproveito para outras rotinas, então ele será construído com a possibilidade de apresentar todos os campos da tabela de ordem de compra e das entregas.

A apresentação dos campos no relatório será feita conforme parametrização do usuário, de forma semelhante ao protótipo apresentado na sequência.

Todas as informações serão mostradas em uma única linha no relatório, para facilitar a utilização de filtros na planilha gerada.

• Quando estiver marcado o parâmetro "Detalha parcelas", serão apresentadas as informações de parcela também, duplicando as informações de ordem nas linhas;
• Quando estiver desmarcada essa opção, serão apresentadas as informações da ordem e somente serão apresentadas as informações da parcela caso haja apenas uma parcela (caso contrário, será apresentado apenas a informação "Parcelada" nas colunas.
• As colunas disponíveis no relatório deverão ser apresentadas para que o usuário selecionar se quer que elas apareçam visíveis ou não.

Sobre as colunas:

Informações técnicas sobre geração de ordens de compra:

• Para saber como o sistema está configurado para trabalhar por grupo de compra ou comprador, utilizar a procedure "getParamCompra" da fch/fchmat/fchmatpurchrequestprocess.p;
• Para a geração das ordens de compra efetivamente, utilizaremos basicamente a mesma lógica que existe hoje para o Flex com algumas adaptações em função das novas regras:
  • Ao chamar a procedure "createPurchaseRequisitions" da fchmatpurchrequestprocess:
    • O parâmetro "generateOrdersRelation" deverá ter, valor 1 se informado em tela por grupo de compra e valor 2 se informado comprador do item ou comprador específico;
    • O parâmetro "buyer" deverá ter valor somente se informado comprador específico, e neste caso deve ter o código do comprador (confirmar se o flex só envia se estiver nesta situação, senão será necessário ajustar);

• • Na ccapi100.i1, será necessário ajustar para que quando a geração for por "comprador", se for passado o parâmetro de comprador para API considere este para a geração, senão considere o comprador do item;
  • Ainda na ccapi100.i1, será necessário implementar a regra para direcionar as ordens para um comprador alternativo caso exista. Neste caso, gravar o comprador original em: ordem-compra.char-1 (posição inicial 195, 12 posições)
• Para apresentação das ordens geradas utilizar as informações da ttSummaryPurchRequisition.

4) Permitir que o campo de preço do item seja ocultado no momento da inclusão de requisição de compra:

 Deverá ser criado um parâmetro no programa de usuário de materiais (CD1700) para indicar se o preço da solicitação deve ou não ficar visível ao usuário;

Na tela inclusão de solicitação HTML, deverá ser tratado o parâmetro em questão para ocultar o preço do item. 

Caso o parâmetro esteja desmarcado, a tela tela o comportamento atual.

Caso o parâmetro esteja marcado, o comportamento da tela será o seguinte:

• Caso o preço do item tenha valor diferente de 0, ou seja, o sistema conseguiu de alguma maneira sugerir o valor, o campo não deverá ficar visível em tela. Caso contrário, deverá ficar visível.

 Nas mensagens de aprovação deverá ser ajustado para que não seja apresentado o valor também.

Informações técnicas sobre ocultar preço do item:

• O novo campo ficará armazenado em um campo livre: usuar-mater.char-1 (posição inicial 21, 1 posição) - Quando marcado deve ter valor "S", se tiver valor "N" ou "" (branco), significa que o preço deve ficar visível em tela.
• Para buscar o parâmetro do usuário, referente a visualização do preço do item, colocar um parâmetro novo de retorno na REST_GET_getRequestItemForEdit e REST_GET_getDefaultsItem, e tratar no HTML.
• Para as mensagens de aprovação, alterar os programas: fchmatenterrequests.p (eletronicApprovalMessage) e boin168fx.p (eletronicApprovalMessage) para que quando o parâmetro estiver marcado, mostre "-" ao invés do valor.

Opcional

Protótipo de Tela

Apresentados juntamente com as regras de negócio.

Opcional

Fluxo do Processo

<Nesta etapa incluir representações gráficas que descrevam o problema a ser resolvido e o sistema a ser desenvolvido. Exemplo: Diagrama - Caso de Uso, Diagrama de Atividades, Diagrama de Classes, Diagrama de Entidade e Relacionamento e Diagrama de Sequência>. 

Opcional

Dicionário de Dados

Tabela Nova:

Obs.: Lembrar de gerar e efetivar as triggers da tabela nova (dump-name da tabela in01022)

Mais campos livres.

Reserva de campos Livres:

• Oculta Preço Solicitação: usuar-mater.char-1 (posição inicial 21, 1 posição)
• Comprador original: ordem-compra.char-1 (posição inicial 195, 12 posições)

(Opcional)

Estrutura de Menu

Procedimentos

Programas

Cadastro de Papéis

Não se aplica