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

Possibilitar a utilização do Portador do Cliente/Fornecedor do Financeiro no lugar do Portador do Cliente/Fornecedor do Industrial dentro do módulo de Documentos de Frota que utilizam esta informação.

(Obrigatório)

Definição da Regra de Negócio

Atualmente no TOTVS 12, os cadastros de Cliente/Fornecedor no Financeiro são por empresa e no Industrial não. Alguns módulos do Industrial necessitam da informação do Portador e Modalidade destes cadastros durante as movimentações. Quando há necessidade de diferenciar a informação por empresa no Industrial, é necessário antes de efetivar a movimentação no módulo, alterar os cadastros para conterem a informação correta.

No Financeiro, como os cadastros de Cliente/Fornecedor são por empresa, é possível definir um Portador diferente por empresa para o mesmo Cliente ou Fornecedor.

Tendo em vista que o processo de unificação destes cadastros é muito complexo, porém, esta situação de poder diferenciar o Portador por empresa do Cliente/Fornecedor no Industrial deve ser corrigida, este requisito deve prever esta correção.

A partir da release TOTVS 12.1.11, haverá uma nova função que possibilitará a utilização do Portador do Cliente/Fornecedor do Financeiro no lugar do Portador do Cliente/Fornecedor do Industrial dentro dos módulos do Industrial que utilizam esta informação.

De forma resumida, antes de uma movimentação em algum módulo do Industrial utilizar o Portador e Modalidade, será verificado o Cliente/Fornecedor equivalente no Financeiro para a empresa do movimento e será buscado/utilizado o Portador do cadastro do Financeiro. Devido a conceitos diferentes: Portador e Modalidade x Portador e Carteira, será utilizada a Matriz de Tradução de Portador já existente que fará a tradução do Portador do Industrial para o Financeiro e vice-versa.

Algumas observações: 

• Este requisito terá como proposta, uma solução suavizada, ou seja, será possível ativar ou desativar a função que será criada para este requisito a qualquer momento. Os programas alterados deverão estar preparados.
• A partir do momento que a função estiver ativada, é essencial que a Matriz de Tradução de Portador esteja devidamente atualizada referenciando os Portadores do Industrial com os Portadores Financeiros de todos os Clientes/Fornecedores (Emitentes) que possuírem a informação, por isso, será necessário a criação de um relatório que demonstre possíveis inconsistências.
• Os cadastros de Clientes/Fornecedores do Industrial deverão ser alterados para, ao informar um Portador, seja utilizado um novo Zoom que irá apresentar a relação entre Portador e Modalidade do Industrial e Portador e Carteira do Financeiro.
• Apesar da proposta deste requisito ser a utilização do Portador Financeiro ao invés do Portador do Industrial nos cadastros de Cliente/Fornecedor, não significa que o código do Portador e Carteira do Financeiro serão utilizados nos módulos do Industrial, ou seja, será utilizado a Matriz de Tradução para identificar o Portador e Modalidade do respectivo Portador e Carteira do Financeiro.

<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

• Realizada as devidas manutenções nas api's responsáveis de gerar títulos e antecipações, onde o objetivo será buscar as informações do "Portador" e "Modalidade" cadastradas na tabela Emitente existente no Financeira no lugar do existente no Industrial (EMS 2).

Tabelas Utilizadas

• Emitente.

Solicitação Pagamentos (ND0303):

Esta funcionalidade tem o objetivo de agrupar pagamentos de apontamentos de eventos de custo, podendo integrar com Contas a Pagar.

Atualmente as informações de "Portador" e "Modalidade" utilizadas para gerar títulos e antecipações são provenientes da tabela de Emitente existente no Industrial (EMS 2).

Deverá ser realizada as devidas manutenções nas api's responsáveis de gerar títulos e antecipações, onde o objetivo será buscar as informações do "Portador" e "Modalidade" na tabela Emitente existente no Financeira no lugar do existente no Industrial (EMS 2).

Como no Financeiro o Emitente pode ter um "Portador" ou "Modalidade" para cada empresa, estaremos sempre buscando as devidas informações referente a Empresa do usuário logado. Importante: Atualmente já é utilizado a Empresa do usuário logado na geração de títulos e antecipações.

Nota: Não será realizada nenhuma alteração em tela, somente nas "ndapi001.p" e "ndapi002.p".

Segue algumas regras a serem utilizadas nas api's de negócio:

• A busca do "Portador" ou "Modalidade" somente será realizada se a função "Portador Financeiro do Emitente" estiver implantada;
• Empresa a ser enviada para o Financeiro deverá ser a Empresa do usuário logado;
• Tipo do emitente a ser enviada para o Financeiro deverá ser "Fornecedor";
• Caso ocorra erros durante a integração, os mesmos deverão ser exibidos em tela e no client-log;

• As informações recebidas do Financeiro vão passar pela Matriz de Tradução de Portador para identificar o respectivo Portador e Modalidade do Industrial, ou seja, continuará usando Portador e Modalidade do Industrial (EMS2). Essas informações serão retornadas através da api do financeiro.

Dicas para realizar a manutenção nas api's ndapi001.p e ndapi002.p: 

Nota: Durante o desenvolvimento desta especificação poderão ser utilizadas lógicas diferentes das existentes neste documento, pois as mesmas são sugestões para auxiliar o desenvolvedor, no entanto, deverão ser utilizadas as lógicas necessárias para que o objetivo desta engenharia seja alcançado.

• Integração Frotas x AP (Implantação Títulos / Baixa Antecipação (NDAPI001):
  
  • Incluir a definição da include a baixo no local das variáveis:
    {cdp/cdapi3009.i1} /* PCREQ-9759 - Portador do Emitente */
  • Incluir o código abaixo na procedure pi-inicializa-handles: 

/*******************************************************************************

 PCREQ-9759 - Portador do Emitente 

Verifica no programa do HUB e chamar a procedure que irá retornar para uma
variável se a função relacionada ao Portador Financeiro do Emitente está ativa
********************************************************************************/  

{cdp/cdapi3009.i2} 

• • Eliminar o fonte abaixo:

Image Added

• • Incluir o código abaixo:

Image Added

• Integração Frotas x AP (Implantação Antecipação) (NDAPI002):

• • Incluir a definição da include a baixo no local das variáveis:
    {cdp/cdapi3009.i1} /* PCREQ-9759 - Portador do Emitente */
  • Incluir o código abaixo na procedure pi-inicializa-handles:

/*******************************************************************************

PCREQ-9759 - Portador do Emitente

Verifica no programa do HUB e chamar a procedure que irá retornar para uma
variável se a função relacionada ao Portador Financeiro do Emitente está ativa
********************************************************************************/ 

{cdp/cdapi3009.i2}

• • Eliminar o fonte abaixo:

Image Added

• • Incluir o código abaixo:

Image Added

• Documentação de como executar a api do financeiro:

  \\joaquina\pastahst\Roadmap 2015-2016\Finanças\PCREQ-9042 - Portador do Emitente\Analise\4_Especificacao\Técnica de Alteração Módulos.docx

Programas Auxiliares Utilizados para teste: 

• Funcionalidades Industriais (EMS 2)
  • AB0138 - Manutenção Equipamento Frota;
  • AB0113 - Manutenção Eventos (Tem que ter Eventos Custos);
  • ND0305 - Apontamento Eventos Custos;
  • ND0303 - Solicitação Pagamentos;
  • CD0401 - Manutenção Fornecedores.
• Funcionalidades Financeira (EMS 5)

  • prgint/ufn/ufn008aa.r - Manutenção Portadores;

  • prgint/ufn/ufn003aa.r - Manutenção Fornecedores Financeiro;

  • prgint/dcf/dcf013aa.r - Matriz Portador (banco);

  • prgint/utb/utb118aa.r - Manutenção Matriz Trad Organização Ext;

  • prgfin/apb/apb704aa.r - Aprova Contas a Pagar;

  • Prgint/utb/utb223aa.r - Consulta Fornecedor/Emitente (Botão Títulos).

Como Gerar e Consultar Títulos:

• ND0305 - Apontamento Eventos Custos;
• ND0303 - Solicitação Pagamentos, nesse realizar os seguintes passos:
  • Criar uma Solicitação com Ação da Integração igual a Título;
  • No folder Eventos informar o documento criado na funcionalidade Apontamento Eventos Custos.
• Prgint/utb/utb223aa.r - Consulta Fornecedor/Emitente (Botão Títulos).

Informação para o Help on-line: 

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)

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