Histórico da Página

Informações Gerais

(Obrigatório)

Objetivo

<Nesta etapa informar o objetivo da especificação do requisito, ou seja, o que a funcionalidade deve fazer. Exemplo: Permitir que o usuário defina o percentual mínimo em espécie (dinheiro), a referência mínima para calculo dos débitos do aluno e o período de validade do parâmetro de negociação>.

(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>.

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

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

Opcional

Protótipo de Tela

<Caso necessário inclua protótipos de telas com o objetivo de facilitar o entendimento do requisito, apresentar conceitos e funcionalidades do software>.

Protótipo 01

 Image Removed

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

Arquivo ou Código do Script: AAA – Negociação Financeira / *Versao=CP.2014.12_03*/

(Opcional)

Grupo de Perguntas

<Informações utilizadas na linha Protheus>.

Nome: FINSRF2

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

Consulta: AMB

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.

Definição da Regra de Negócio

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 funções que possuem nomes iguais as 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, 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.

Código Fonte: LPrinterBase.prw
Conflito: Funções GetCoefFromIni, GetPrinterSession, PrinterSetup e IsPrinterOK já existentes no Protheus.
Solução: Remover estas funções do fonte LPrinterBase.prw e recolocá-las como estáticas no fonte LReportFile.prw que é onde são utilizadas.

Código Fonte: LNumericField.prw
Conflito: Função RemoveChar já existe no Protheus.
Solução: Remover a função do fonte LNumericField.prw, esta função não está sendo mais utilizada no Logix.

Código Fonte: miscfunctions.prw
Conflito: Função LoadBitmap já existe no Protheus.
Solução: Remover a função do fonte miscfunctions.prw e alterar os fontes do Logix para utilizar a função original do Protheus.

Código Fonte: string.prw
Conflito: Função Capital já existe no Protheus.
Solução: Remover a função do fonte string.prw, os fontes do Logix que a utilizam passarão a usar a função original do Protheus.

Código Fonte: version.prw
Conflito: Função GetVersao já existe no Protheus.
Solução: Remover a função do fonte version.prw, os fontes do Logix que a utilizam passarão a usar a função original do Protheus.

Código Fonte: mail.prw
Conflito: Include já existe com este mesmo nome no Protheus.
Solução: Renomear as funções de envio de e-mail.

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 a combinação entre os códigos 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.

Código Fonte: style.ch
Conflito: Include já existe com este mesmo nome no Protheus.
Solução: Renomear a include de style.ch para logixstyle.ch.

Código Fonte: FWChart.prw, FWChartBar.prw, FWCharColor.prw, FWChartFactory.prw, FWChartLegend.prw, FWChartLine.prw, FWChartPie.prw, FWChartSerie.prw
Conflito: Foram realizadas diversas melhorias e correções nos componentes, inviabilizando a combinação entre os fontes Logix e Protheus.
Solução: Renomear os componentes FWChart* para LFWChart* e revisar os fontes que o utilizam no Logix.

Código Fonte: FWLayer.prw, FWLayerCollumn.prw, FWLayerWindow.prw
Conflito: Foram realizadas diversas melhorias e correções nos componentes, inviabilizando a combinação entre os fontes Logix e Protheus.
Solução: Renomear os componentes FWLayer* para LFWLayer* e revisar os fontes que o utilizam no Logix.

Código Fonte: FWWindow.prw
Conflito: Foram realizadas diversas melhorias e correções nos componentes, inviabilizando a combinação entre os fontes Logix e Protheus.
Solução: Renomear os componentes FWWindow para LFWWindow e revisar os fontes que o utilizam no Logix.

Código Fonte: xtree.prw
Conflito: Foram realizadas diversas melhorias e correções nos componentes, inviabilizando a combinação entre os fontes Logix e Protheus.
Solução: Renomear os componentes XTree para LXTree e revisar os fontes que o utilizam no Logix.

Código Fonte: Transparent.prw
Conflito: As funções do fonte Transparent.prw foram completamente alteradas para que fossem utilizadas no Logix.
Solução: Criar um novo fonte com outro nome e recriar as funções do Transparent.prw com outros nomes neste novo fonte.

Código Fonte: FWSCIMSystray.prw
Conflito: As funções do fonte FWSCIMSystray.prw foram alteradas para que fossem utilizadas no Logix.
Solução: Renomear o fonte FWSCIMSystray.prw para LFWSCIMSystray.prw e revisar os fontes que o utilizam no Logix.

Verificação do Produto

Em casos específicos, como serviços WebServices (WS) SOAP e 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, conforme exemplo abaixo:

Function FWIsLogix(cSection)
Local lRet := .F.
If  Empty(cSection)
    lRet := Upper( GetPvProfString( "GENERAL" , "SERVERTYPE" , "" , GetAdv97() ) ) == "4GL" .Or. ;
            Upper( GetPvProfString( "GENERAL" , "DATEZERO"   , "" , GetAdv97() ) ) == "4GL
    If !lRet
        lRet := Upper( GetPvProfString( GetEnvServer() , "SERVERTYPE" , "" , GetAdv97() ) ) == "4GL"
                Upper( GetPvProfString( GetEnvServer() , "DATEZERO"   , "" , GetAdv97() ) ) == "4GL
    EndIf
Else
    lRet := GetPvProfString( cSection, "LOGIX" , "0" , GetAdv97() ) == "1"
EndIf
Return lRet

Os serviços WS SOAP e REST abaixo do Logix serão renomeadas para funções, a chamada para elas, a partir desta alteração, será realizada pelo serviço do Protheus:

Alguns outros fontes, serão renomeados por já existirem o fonte com o mesmo nome no Protheus, como:

Abaixo segue um exemplo de como ficará a chamada do EAIService do Logix de dentro do Protheus:

WSMETHOD receiveMessage  WSRECEIVE inMsg WSSEND outMsg WSSERVICE EAIService
Local lRetorno := .T.
 
If  FWIsLogix()
    lRetorno := EAIReceiveMessageLogix(self)
Else
    /* Código Protheus */
    lRetorno := .T.
EndIf
Return lRetorno

(Opcional)

Estrutura de Menu

<Informações utilizadas na linha Datasul>.

Procedimentos

Programas

Cadastro de Papéis

<O cadastro de papéis é obrigatório para os projetos de desenvolvimento FLEX a partir do Datasul 10>.

<Lembrete: o nome dos papeis em inglês descrito neste ponto do documento, devem ser homologados pela equipe de tradução>.