Páginas filhas
  • ER_PCREQ-4888_Unificar_bibliotecas_compartilhadas_dos_frameworks_Logix_Protheus

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico.

  

Informações Gerais

Especificação

Produto

Logix

Módulo

Framework

Segmento Executor

Tecnologia

Projeto

LD_FRW_FRW001

IRM

PCREQ-4887

Requisito

PCREQ-4888

Subtarefa

PDR_LD_FRW001-68

Release de Entrega Planejada

12.1.7

País

(X) Brasil  (  ) Argentina  (  ) Mexico  (  ) Chile  (  ) Paraguai  (  ) Equador

(  ) USA  (  ) Colombia   (  ) Outro _____________.

Outros

 


Objetivo

Unificar as bibliotecas e componentes de framework compartilhados entre os produtos Protheus e Logix para que não haja qualquer incompatibilidade ou conflito na unificação dos mesmos em um repositório de objetos (RPO) único.

(Obrigatório)


Definição da Regra de Negócio

 

<Regra de negócio é o que define a forma de fazer o negócio, o processo definido e/ou as regras que devem ser contempladas. Devem ser descritas restrições, validações, condições e exceções do processo. Caso necessário, incluir neste capítulo também regras de integridade que devem ser observadas no momento do desenvolvimento>.

 

<Na tabela abaixo informe quais são as rotinas envolvidas, o tipo de operação, a opção de menu e se necessário uma breve descrição das regras de negócio relacionadas a rotina>.

 

Rotina

Tipo de Operação

Opção de Menu

Regras de Negócio

[ACAA040 – Parâmetros]

[Alteração]

[Atualizações -> Acadêmico-> Tesouraria]

-

[ACAA050 – Negociação Financeira]

[Envolvida]

[Atualizações -> Acadêmico-> Tesouraria]

-

[ACAA060 – Cadastro de Pedidos]

[Criação]

[Atualizações -> Acadêmico-> Cadastros]

-

 

Exemplo de Aplicação:

  • Criar o campo “% Mínimo Espécie” (AAA_PERESP) onde o usuário informará o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação.
  • Criar o campo “Referência Mínima para Cálculo” (AAA_REFCAL) onde o usuário informará um dos 4 valores disponíveis para pagamento das mensalidades  como a referência mínima para calcular o débito total do aluno.
  • Criar o parâmetro MV_ACPARNE que definirá se as informações de “% Mínimo Espécie” e “Referência Mínima para Cálculo” serão obrigatórias.
  • O parâmetro MV_ACPARNE deve ter as seguintes opções: 1=Obrigatório e 2=Opcional. Deve ser inicializado como opcional>.

 

Tabelas Utilizadas

Atualmente no Logix são utilizadas diversas bibliotecas que foram duplicadas do Protheus, porém com a unificação dos frameworks, estes fontes irão conflitar com os já existentes no Protheus. Para evitar tais conflitos, as bibliotecas utilizadas no Logix serão revisadas conforme as necessidades abaixo:

  1. Adequação:
    Funções do Logix com nomes iguais a funções do Protheus serão renomeadas ou serão retirados do código fonte do Logix.
  2. Renomeação:
    Caso o código fonte utilizado pelo Logix sofreu muitas alterações, o mesmo será renomeado e todos os outros fontes que o utilizam serão alterados.
  3. Verificação de produto:
    Caso o código fonte não possa ser renomeado, será feita uma alteração para verificar o produto em questão, executando a lógica conforme o resultado.

Para outras bibliotecas que não sofreram alterações, será apenas necessário readequar o local em que se encontra o código fonte - os mesmos deverão permanecer na pasta de códigos fontes do Protheus.

Adequação

No Logix existem muitas funções que possuem nomes iguais a funções já existentes no Protheus (pode-se perceber isto durante a unificação do RPO), estas são funções copiadas de códigos fontes do Protheus ou por coincidência foram criadas com o mesmo nome. Neste caso deve-se avaliar cada uma das funções conflitantes para que a mesma seja renomeada ou alterada para estática ou retirada do código fonte de Logix para que o mesmo passe a utilizar a função que se encontra no Protheus.

Renomeação

Com a evolução de ambos os produtos, algumas bibliotecas duplicadas para uso no Logix foram alteradas com diversas correções e melhorias inviabilizando o merge entre os fontes. Para que não haja qualquer impacto tanto no produto Logix quanto no Protheus, o código fonte alterado será renomeado, criando-se assim uma nova classe ou biblioteca específica para o produto Logix.

Verificação do Produto

Em casos específicos, como serviços WS do tipo SOAP ou REST, não é possível renomear o código fonte e suas funções - o mesmo código fonte deve ser utilizado por ambos os produtos. Para isso, estas bibliotecas serão alteradas para verificar se o produto em execução é Logix ou Protheus e executará a lógica conforme o resultado. A verificação poderá consistir o produto conforme uma chave encontrada no arquivo APPSERVER.INI do servidor de aplicação, conforme o exemplo abaixo:

 

FWIsLogix

 

OBS: Atentar para questão das chaves SERVERTYPE e DATEZERO que podem estar definidas no ambiente em uso ou na seção GENERAL. A prioridade é ambiente e quando não encontradas são pesquisadas na seção GENERAL

  • SE2 – Cadastro de Contas a Pagar
  • FI9 – Controle de Emissão de DARF>

    .

     

     

     

     

     

     

    Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico.