(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 

O objetivo consiste em desenvolver Métodos/Webservices Logix Desenvolver Web Service para consulta de pedidos de Vendas no LOGIX com base no protocolo REST. 

O Método ou Webservice Web Service irá tratar toda a regra de negócio porém não contempla interface. Ou seja, deverá ser chamado por algum aplicativo passar passando os parâmetros de entrada e receberá recebendo o retorno do processamento. A interface ficará sob responsabilidade do cliente.

(Obrigatório)

Definição da Regra de Negócio

Desenvolver funções 4GL para centralização do processo de consulta de pedidos externo no LogixBasicamente serão desenvolvidas duas funções 4gl, sendo uma API para trabalhar como Web Service e outra com as regras de negócios do produto.

A estrutura dos novos fontes seguirá a seguinte divisão:

 VDP90422VDPR0003.4gl – Centralizador consulta, tomar como base as funções desenvolvidas para o WorkFlow de compras: 

Funções externas:

·         Método Fluig - Função que será chamada por processos desenvolvidos via WorkFlow Fluig. Deverá fazer o GET dos filtros que poderão ser passados pelo Fluig, são eles:

Empresa - CHAR(50)

Pedido - CHAR(1000)

Cliente - CHAR(1000)

Natureza de operação - CHAR(500)

Condição de pagamento - CHAR(500)

Carteira - CHAR(200)

Representante (Somente o primeiro ou todos?) - CHAR(400);

Situação do pedido - CHAR(50);

Data emissão pedido DE - DATE;

Data emissão pedido ATE - DATE;

Prazo de entrega DE - DATE;

Prazo de entrega ATE - DATE;

Transportadora - CHAR(500);

Campo livre - CHAR(5000);

Parâmetros:

-- Tipo de pesquisa - Indica quais dados do pedido serão carregados. Opções:

             1 - Todos;

             2 - Empresa e pedido;

             3 - Empresa, pedido, cliente, natureza de operação, condição de pagamento, situação, transportadora, carteira, representante 1, data emissão pedido;

-- Paginação - Indica a quantidade de pedidos que serão carregados/retornados por execução; Caso não informado ou informado valor 0, serão carregados todos os pedidos;

-- Posição inicial paginação - Indica a partir de qual posição serão carregados os pedidos.

Funções internas:

·         set() - Deverá fazer a carga dos parâmetros e filtro para a função vdp90423;

get() - Fazer o get das seguintes informações e retornar para o fluig:

         Dados do pedido conforme o tipo de pequisa;

         Status de execução;

         Indicador status paginação; (F - Finalizado ; P - Pendente)

VDP90423.4gl – Controle de consulta de pedidos externos

 Funções externas:

·         inicializa_variáveis() - Inicializar todos os parâmetros que são recebidos pelas funções SET abaixo.

·         função_set() - Criar função de SET para cada campo de filtro e parâmetros que serão enviados pelo vdp90422.

·         função_get()  - Criar funções de GET para os retornos que são esperados pelo VDP90422, conforme abaixo:

o   Todos os dados do pedido, conforme tabelas em anexo;

o   Status da paginação;

·         processo_consultar_pedidos()  - Será a função principal, executada pelo VDP90422. Dentro dela:

         1) Criar um cursor dinâmico, com base nos filtros informados, buscando apenas empresa e pedido (utilizar DISTINCT) e ordenando por esses mesmos campos.

Funções internas:

·         validação_tela() - Fará as chamadas das funções VDPR260.

·         efetivar_tabelas_pedido() - Efetivar dados das tabelas quentes através das respectivas DML's

·         consiste_pedido() - Executar o vdp20023 para consistir o pedido

·         simular_faturamento() - Executar o vdp90046 para simular o faturamento do pedido (necessário ajustes por causa das msgs em tela)

VDPR260.4gl – Validações dos campos conforme é realizado hoje em tela (VDP20000)

 Funções externas:

• carrega_parametros() - Fará carga dos parâmetros do LOG00086 e outros necessários durante a validação.
• valida_XXXX() - Cria uma função para cada campo que necessite de validação.
  Observações: 1) Deverá receber todas as variáveis por parâmetro local;
  2) Sempre retornar 3 parâmetros: status de execução, mensagem e o tipo de mensagem: E - Erro SQL / V - Validação /  A - Alerta;
  2) Revisar as mensagens se estão com linguagem clara do erro.
  3) Adicionar nas mensagens a chave do cadastro. Ex.: Cliente XXXXX não cadastrado.
  4) Deverá respeitar os parâmetros do LOG00086 para obrigar ou não o preenchimento dos campos.

Tabelas que serão previstas

Tabelas que não serão previstas

API para consulta de pedido de venda. Deve receber os parâmetros por REST, enviar para a função de consulta e retornar os dados para o requisitante. 

Método: vdpr0003_pub_get_consultaPedidoVenda()

Parâmetros de entrada:

Parâmetros de saída:

VDP90423.4gl – Consulta de pedidos externos.

          1) Criar função para pesquisa que será executada pela API vdpr0003 ou alguma outra função que venha a ser desenvolvida futuramente.Estrutura da função: 

                  --> Criar um cursor dinâmico, com base nos filtros informados, buscando apenas os dados da tabela "pedidos" (utilizar DISTINCT) e ordenando pelos campos empresa e pedido.

                  --> Dentro do FOREACH: adicionar a lógica de paginação; inserir os pedidos em uma temp (estrutura da temp: empresa e pedido) e armazenar os dados da tabela  "pedidos" no array para posterior retorno.

                   –> Se a pesquisa for do tipo "COMPLETA", criar novo cursor na temp para percorrer pelas empresas encontradas. Para cada empresa carregar os parâmetros e as validações de tabela utilizada. Dentro desse cursor carregar os demais dados das tabelas auxiliares, criando cursores relacionando a tabela com a temp (conforme parametrização); 

                   --> Realizar FREE de todos os cursores após uso.

                  --> Retornar Status de execução e Mensagem (erro/validação,etc) para a função chamadora;

Funções externas:

1) inicializa_variáveis() - Inicializar todos os parâmetros que são recebidos.

2) função_set() - Criar função de SET para cada campo de filtro e parâmetros que serão enviados pela função chamadora.

3) função_get()  - Criar funções de GET para os seguintes retornos:

o   Para cada campo/tabela de pedidos prevista na função

o   Status da paginação: "PENDENTE" quando utiliza paginação e não retornou todos os registros solicitados; "FINALIZADO" se conseguiu retornar todos os pedidos daquele filtro.

Obs.: Para desenvolvimento das API com protocolo REST seguir o padrão estabelecido em: http://tdn.totvs.com.br/display/public/FRAMJOI/LGX+-+Desenvolvimento+de+API 

Conceitos que não serão previstos: 

--> Integração com módulo de fluxo de caixa;
--> Conceito de Kit;
--> Integração com módulo de assistência técnica;
--> Cota de representante (Parâmetro "controla_cota");
--> Previsão de produção;

   Tabelas previstas

         Tabelas que não foram previstas