Histórico da Página

(Obrigatório)

Informações Gerais

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.

arquivos do tipo  TXT, XLS, XML ou alguma variação destas extenções, como por exemplo XLSX - > XLS; CSV - > TXT.

Além dos diferentes tipos de arquivo, cada marketplace utiliza um layout diferente, de forma que a disposição das informações estão numa ordem especifica daquele marketplace.

Por conta das diferentes formas em que a informação pode chegar, além da rotina de 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 o layout para e 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.  

Existirá ainda uma outra rotina de relatório, que irá listar os registros que já se encontram na base.

Definição da Regra de Negócio

 UTBXXX –

Cadastro de Layout da Transação.

As informações desta rotina serão guardadas em duas novas tabelas: layout_transacao trans e item_layout_transaçãotrans, onde as informações gerais serão guardadas na tabela pai layout_transacao trans e na tabela filha item_layout_transacao trans 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.

Deve ser criado um terceiro programa, sem interface, onde constarão, fixas no fonte, quais são as transações disponíveis e quais os campos que cada transação utilizará. A opção de XML não será tratada neste projeto, portanto não deve apresentar em tela nenhuma informação referente a este tipo de arquivo.

Tela-pai (Protótipo de tela 1):

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. No caso deste projeto, a transação sempre será “Pagto Marketplace”. 

O usuário também deverá indicar qual a extensão do arquivo que irá importar, se .TXTO 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(Protótipo de tela 2):

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 no terceiro 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 programaestarão as definições de campos por transação.

Não será exibido para o usuário o código do campo. No lugar disto, será somente exibido o label definido para aquele campo daquela transação.

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

• A posição ordem 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;
• Um campo que indicará se o usuário deseja importar: 
  • Todos os registros; 
  • Somente os registros que atendam uma regra; 
  • Todos os registros, exceto aqueles que atendam uma regra;
• A regra/descrição que deve ser aplicada, caso informe uma das duas ultimas opções 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.

além da posição inicial do campo, o seu tamanho, para que a importação seja possível. Nos outros casos, o campo tamanho será mostrado, mas desabilitado, e exibindo o valor de tamanho máximo cadastrado para a transação

Quando for informado um valor padrão, o conteúdo daquele campo será desconsiderado, e sempre irá importar o valor padrão. 

Validações:

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

Uma vez criado o layoutUma 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 trans e item_layout_transacaotrans, o processo pode poderá avançar para a rotina de importação.ACRXXX – Importação.

Importador Movimentos do Marketplace

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 arquivonome do arquivo, o diretório onde o arquivo está, o diretório ondo para onde o arquivo deve ser será enviado depois de processado e um diretório para armazenar os possíveis logs de erro. Como retorno terá em caso de sucesso, o diretório para onde o arquivo será enviado em caso de erro e a situação do processo, que por default será ' '.  A API deverá retornar 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

 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

o processo, nada mais.

A estrutura da API segue os seguintes passos:

• Validar parâmetros de entrada;
• Criar processo transação;
• Importar os dados de acordo com o tipo de arquivo cadastrado no layout;
• Se não houver nenhum erro até este momento, tenta mover o arquivo para a pasta destino;
• se falhar, ou se houver algum outro erro, move o arquivo para a pasta de erro.
• Devolver a temp-table com os dados, a de erros e o código do processo criado.

Caso o extrato de versão esteja ativo, a API deverá exportar as temp-tables e o registro do processo num diretório especificado.

Tabela de processos

A tabela de processos de importação das transações é uma tabela filha da tabela de parametrização (layout_trans) e será pai de todas as tabelas de transação (no caso deste projeto movto_mktplace). 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(Protótipo de tela 3):

Este programa será responsável por criar os movimentos dos marketplaces selecionados, utilizando os dados de acordo com o que for retornado da API, que será chamada conforme a parametrização do marketplace.

 A tela conterá uma seleção de marketplaces, que irá carregar num browse todos os registros correspondentes a busca, onde o usuário poderá marcar de quais marketplaces deseja importar. Neste browse será apresentado a identificação do marketplace, o código do layout que utiliza, e o local de origem dos arquivos que serão importados.

A parametrização dos marketplaces estarão na tabela param_mktplace (ER_MANFIN01-435_CIASHOP-ACR-Lote_Marketplace), onde, entre outras coisas, constará qual o layout que a administradora utiliza, o local onde os arquivos estão, para onde devem ir e um local em casos de erros.

Com estes parâmetros já é possível utilizar a API, portanto, para cada documento de cada marketplace, deve fazer a chamada correspondente a API. Quando esta terminar seu processamento, o programa de importação deverá criar registros na tabela movto_mktplace de acordo com a temp-table retornada. Além disso, deve gerar um relatório, onde constarão o total de arquivos encontrados e importados de cada marketplace, quantos registros foram importados em cada arquivo e o local de origem e atual do arquivo. Também deverá ser apresentado os possíveis erros neste relatório.

Relatório Movimentos Marketplace

O objetivo deste programa é a consulta dos movimentos de administradora já importados por meio de um relatório. 

A interface deste programa deve seguir o layout padrão dos outros programas de relatório, com todas as funcionalidades padrões já existentes. Na faixa de seleção, deve ser possivel filtrar por:

• por marketplace;
• por layout utilizado;
• por data de importação;

Este relatório servirá para simples conferencia de tudo o que já foi importado até o momento.

Protótipo de Tela

Protótipo 01

 Image Added

Protótipo 02

 Image Added

 Protótipo 3:

Image Added 

Fluxo do Processo

 <não se aplica>. 

Dicionário de Dados

Grupo de Perguntas

<não se aplica>.

Consulta Padrão

<não se aplica>.

Estrutura de Menu

(Opcional)

Estrutura de Menu

 

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*

	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

<não se aplica>..

 

---

 

[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