Árvore de páginas

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.                                                             

  

(Obrigatório)

Informações Gerais

 

Especificação

Produto

 

Módulo

 

Segmento Executor

 

Projeto

 

IRM

 

Requisito

 

Subtarefa

 

País

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

(  ) USA  (  ) Colombia   (  ) Outro _____________.

Outros

<Caso necessário informe outras referências que sejam pertinentes a esta especificação. Exemplo: links de outros documentos ou subtarefas relacionadas>.

Objetivo

Na integração marketplace - contas a receber, será necessário importar para o ERP as informações referentes aos pagamentos realizados. Estas informações podem vir dos marketplaces em três tipos de arquivos: num documento .TXT, num documento XLS ou ainda num documento XML. Além disso, cada tipo de arquivo tem suas próprias particularidades no quesito de formatação.

 

Devido à isso, além da rotina de importação, se faz necessária a criação de uma interface de parametrização desta importação, de forma que o usuário poderá definir um layout para o tipo do arquivo que deseja importar.

 

Esta rotina de parametrização deverá ser construída da maneira mais genérica possível, permitindo o reuso por outras rotinas de importação.

 

 

Definição da Regra de Negócio

 

Rotina

Tipo de Operação

Opção de Menu

Regras de Negócio

UTBXXX- parametrização

Nova

Datasul -> Financeiro / Controladoria ->Universal -> Cadastros

-

[ACAA050 – Negociação Financeira]

[Envolvida]

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

-

UTBXXX – API importação

Nova

 

ACRXXX – importa_tela

Nova

Datasul -> Financeiro / Controladoria -> Contas a Receber -> Tarefas

[ACAA060 – Cadastro de Pedidos]

[Criação]

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

-

 

UTBXXX – Cadastro de Layout da Transação.

 

As informações desta rotina serão guardadas em duas novas tabelas: layout_transacao e item_layout_transação, onde as informações gerais serão guardadas na tabela pai layout_transacao e na tabela filha item_layout_transacao serão armazenadas as informações dos campos individualmente.

Tela-pai:

Na tela-pai o usuário deve ser capaz de informar um código identificador (campo chave) e uma descrição para o layout. Também deverá permitir indicar se o layout é de importação ou exportação, e qual a transação que será importada, que no caso deste projeto sempre será “Pagto Marketplace”. As transações ficaram fixas no código-fonte, sendo que cada novo projeto deverá adicionar a sua transação no bloco respectivo dentro do programa.

O usuário também deverá indicar qual a extensão do arquivo que irá importar, se .TXT, .XLS ou .XML. Caso a extensão seja .TXT, deverá ser informado a delimitação dos campos: se por posição ou por um separador. Caso seja por um separador, deve gravar qual é. Caso a extensão seja .TXT ou .XLS, existirá um flag que indicará se o arquivo utiliza ou não um cabeçalho, de forma que a primeira linha do arquivo seja desconsiderada.

Tela-filha:

Na tela filha, dependendo da transação informada na tela pai, deve carregar a listagem de campos que o usuário pode parametrizar. Esta busca deve ser feita em um programa a parte, onde ficarão gravados diretamente no código-fonte o código, label e tipo de dado do campo conforme sua tabela. Desta forma facilitará a inclusão de novas transações nos projetos que venham a utilizar esta rotina, visto que não será preciso alterar regras de negócio, somente adicionar neste programa.

Uma vez carregado todos os campos, o usuário poderá informar, para cada campo:

  • A posição em que o campo irá aparecer na linha do registro;
  • Um valor padrão no caso do campo não conter dados válidos;
  • Um indicador se este campo possui alguma regra ou restrição;
  • A regra/descrição que deve ser aplicada, caso informe uma das duas no item anterior;

No caso especifico da extensão .TXT delimitada por posição, o usuário deve informar, para cada campo, a sua posição inicial e final.

No caso especifico da extensão .XML, o usuário deve informar, para cada campo, qual a tag correspondente.

 

Validações:

Caso o layout já tenha um processo (será descrito mais abaixo neste documento), não poderá ser modificado ou excluído, tendo que primeiro excluir o processo. Assim fica garantido que a importação realizada vai ter um layout cadastrado válido.

Uma vez criado o layout, não será mais possível alterar o tipo de transação.

 

Com todas as informações do layout devidamente cadastradas nas tabelas layout_transacao e item_layout_transacao, o processo pode avançar para a rotina de importação.

ACRXXX – Importação.

Para cada transação, deve existir uma tela de importação. Porém o processo de importação em si será encapsulado em uma API que deverá ser criada.

 

API

Esta API deve receber como parâmetro o layout que será usado, o local do arquivo, o diretório ondo o arquivo deve ser enviado depois de processado e um diretório para armazenar os possíveis logs de erro. Como retorno terá uma temp-table com os dados que irá ler dos arquivos e o código do processo que foi criado nesta importação.

O objetivo da API é ler todo o arquivo, de acordo com a parametrização do layout, gravar estas informações numa temp-table, criar um processo de importação e retornar os dados para que o programa de importação possa gravar no banco. A API só irá criar o processo, nada mais.

 

Tabela de processos

A tabela de processos de importação das transações é uma tabela filha da tabela de parametrização (layout_transacao) e será pai de todas as tabelas de transação, no caso deste projeto movto_admdra_cartao_cr. Esta tabela tem como objetivo guardar informações da importação do arquivo, sendo necessário guardar:

  • O código do layout;
  • Um identificador numérico sequencial;
  • O nome do arquivo importado;
  • O caminho completo do arquivo;
  • A data e hora da criação;
  • A data e hora da última modificação;
  • A data e hora da importação do arquivo;
  • Um indicador da situação do processo;
  • O usuário que realizou a importação.

Com esta tabela, é possível filtrar os registros criados pelo mesmo arquivo, sem precisar replicar diversos campos em todos os registros.

 

Tela Importação:

A tela de importação ficará responsável pela criação dos registros em banco provenientes da importação pela API. Nesta tela deve ser possível escolher uma faixa de administradoras de cartão de crédito, xxxx. 

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

 

 

 

 

 

 

 

 

 

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*/

  

Índice

Chave

01

<FI9_FILIAL+FI9_IDDARF+FI9_STATUS>

02

<FI9_FILIAL+FI9_FORNEC+ FI9_LOJA+FI9_EMISS+FI9_IDDARF>

03

<FI9_FILIAL+FI9_FORNEC+ FI9_LOJA+FI9_PREFIX+FI9_NUM+FI9_PARCEL+FI9_TIPO>

Campo

<AAA_PERESP>

Tipo

<N>

Tamanho

<6>

Valor Inicial

<Varia de acordo com o tipo informado. Por exemplo, quando o campo “tipo” for date, neste campo pode ser informado uma data>. 

Mandatório

Sim (  ) Não (  )

Descrição

<Referência Mínima para Cálculo>

Título

<Ref.Calc.>

Picture

<@E999.99>

Help de Campo

<Informar o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação>

 

(Opcional)

Grupo de Perguntas

 

<Informações utilizadas na linha Protheus>.

 

Nome: FINSRF2

X1_ORDEM

01

X1_PERGUNT

Emissão De

X1_TIPO

D

X1_TAMANHO

8

X1_GSC

G

X1_VAR01

MV_PAR01

X1_DEF01

Comum

X1_CNT01

'01/01/08'

X1_HELP

Data inicial do intervalo de emissões das guias de DARF a serem consideradas na seleção dos dados para o relatório 

 

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

 

Consulta: AMB

Descrição

Configurações de Planejamento

Tipo

Consulta Padrão

Tabela

“AMB”

Índice

“Código”

Campo

“Código”; ”Descrição”

Retorno

AMB->AMB_CODIGO

 

(Opcional)

Estrutura de Menu

 

<Informações utilizadas na linha Datasul>.

 

Procedimentos

 

Procedimento

 

 

 

Descrição

(Max 40 posições)

(Max 40 posições)

(Max 40 posições)

Módulo

 

 

 

Programa base

 

 

 

Nome Menu

(Max 32 posições)

(Max 32 posições)

(Max 32 posições)

Interface

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

Registro padrão

Sim

Sim

Sim

Visualiza Menu

Sim/Não

Sim/Não

Sim/Não

Release de Liberação

 

 

 

 

 

 

Programas

 

Programa

 

 

 

Descrição

(Max 40 posições)

(Max 40 posições)

(Max 40 posições)

Nome Externo

 

 

 

Nome Menu/Programa

(Max 32 posições)

(Max 32 posições)

(Max 32 posições)

Nome Verbalizado[1]

(Max 254 posições)

(Max 254 posições)

(Max 254 posições)

Procedimento

 

 

 

Template

(Verificar lista de opções no man01211)

(Verificar lista de opções no man01211)

(Verificar lista de opções no man01211)

Tipo[2]

Consulta/Manutenção/ Relatório/Tarefas

Consulta/Manutenção/ Relatório/Tarefas

Consulta/Manutenção/ Relatório/Tarefas

Interface

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

Categoria[3]

 

 

 

Executa via RPC

Sim/Não

Sim/Não

Sim/Não

Registro padrão

Sim

Sim

Sim

Outro Produto

Não

Não

Não

Visualiza Menu

Sim/Não

Sim/Não

Sim/Não

Query on-line

Sim/Não

Sim/Não

Sim/Não

Log Exec.

Sim/Não

Sim/Não

Sim/Não

Rotina (EMS)

 

 

 

Sub-Rotina (EMS)

 

 

 

Localização dentro da Sub Rotina (EMS)

 

 

 

Compact[4]

Sim/Não

Sim/Não

Sim/Não

Home[5]

Sim/Não

Sim/Não

Sim/Não

Posição do Portlet[6]

0 – Top Left

1 – Top Right

2 – Bottom Left

3 – Bottom Right

0 – Top Left

1 – Top Right

2 – Bottom Left

3 – Bottom Right

0 – Top Left

1 – Top Right

2 – Bottom Left

3 – Bottom Right

Informar os papeis com os quais o programa deve ser vinculado

 

 

 

 

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

 

Código Papel

(máx 3 posições)

Descrição em Português*

 

Descrição em Inglês*

 


[1] Nome Verbalizado é obrigatório para desenvolvimentos no Datasul 10 em diante.

[2] Tipo é obrigatório para desenvolvimento no Datasul 10 em diante

[3] Categorias são obrigatórias para os programas FLEX.

[4] Obrigatório quando o projeto for FLEX

[5] Obrigatório quando o projeto for FLEX

[6] Obrigatório quando o projeto for FLEX

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