Histórico da Página

(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 para consulta de pedidos de Vendas. 

O Método ou Webservice irá tratar toda a regra de negócio porém não contempla interface. Ou seja, deverá ser chamado por algum aplicativo passar os parâmetros de entrada e receberá 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 Logix.

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

 VDP90422.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);

Funções internas:

·         set() - Deverá fazer a carga dos parâmetros para função vdp90420. Será utilizada pelo método acima.

VDP90420.4gl – Controle de inclusão 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 situação a seguir:

o   todos os campos de todas as tabelas de pedido que hoje são contempladas pelo VDP20000 (lista de tabelas em anexo).

o   simular faturamento - Indicador se simula ou não o faturamento do pedido ao término da inclusão.

§  Sim

§  Não

o   consistir pedido - Indicador se consiste ou não o pedido ao término da inclusão.

§  Não consistir

§  Consistir e incluir o pedido independente do resultado

§  Consistir e caso encontre alguma consistência diferente de 117, não incluir o pedido (executar ROLLBACK)

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

o   Número do pedido;

o   Mensagens de validação e consistência (Em forma de array);

o   Valor dos tributos e pedidos a nível de item e pedido (igual opção simular faturamento do vdp20000);

·         processo_incluir_pedido()  - Será a função principal, executada pelo VDP90419 e irá controlar todo o fluxo de inclusão, executando as funções internas abaixo.

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