Histórico da Página
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 | TSS | Módulo | TSS |
Segmento Executor | Serviços | ||
Projeto1 | M_SER_TSS002 | IRM1 | PCREQ-8285 |
Requisito1 | PCREQ-8286 | Subtarefa1 | PDR_SER_TSS002-336 |
Chamado2 |
| ||
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>. | ||
Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos).
(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>.
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
- 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
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 |
Disponibilizar uma API para Bilhetagem do TSS.
(Obrigatório)
Definição da Regra de Negócio
Através da API de bilhetagem do TSS, as aplicações cliente do TSS poderão obter informações sobre a quantidade de documentos que foram para a fila do TSS online. A consulta será realizada por CNPJ ou CPF, mês e ano. O critério para consulta na base de dados será obtido através dos parâmetros recebidos pela API. A API terá como retorno duas listas, uma informando as quantidades do ambiente de produção e outra das quantidades do ambiente de homologação, as quantidades são separadas por tipo de documento e estarão estruturados em um objeto.
O consumo da API deverá ser realizado através de mensagens JSON em base 64 definidas no WebService RestBilling().
O processo de Serialização e Deserialização de mensagens deverá ser realizado através das funções FwJsonSerialize() e FwJsonDeserialize() respectivamente.
Os códigos de status serão baseados no formato padrão de mensagens HTTP, conforme o link:
https://pt.wikipedia.org/wiki/Lista_de_c%C3%B3digos_de_status_HTTP
A API funciona com paginação de dados, para cada requisição da API existe um limite de retorno de dados. O limite está em 100 CNPJs ou CPFs por requisição.
Caso existe paginação após a primeira requisição, a API retornará no atributo “PAG” com um conteúdo diferente de “” (branco ou vazio, porém nunca nulo), o conteúdo deste atributo deverá ser retornado no próximo consumo da API, para assim dar continuidade no retorno dos dados.
As informações obrigatórias para o consumo da API são mês e ano, as demais são opcionais.
WebService: RestBilling()
WebService responsável pela definição da Interface da API de Bilhetagem TSS.
O WebService deverá receber mensagens na estrutura JSON codificado em base64, onde serão decodificadas e passadas como parâmetro para a função GetBilling().
O retorno do WebService será uma mensagem JSON contendo duas listas estruturadas em um Objeto.
Parâmetros:
JSON =
ew0KCSJFTVBSRVNBIjogew0KCQkiQ0dDIjogIjEyMzQ1Njc4OSIsDQoJCSJ0aXBvcGVzc29hIjogMg0KCX0sDQoJIlBhcmFtZXRyb3MiOiB7DQoJCSJhbm8iOiAiMjAxNiIsDQoJCSJtZXMiOiAiMDkiDQ
oJfSwNCgkiUkVDTk8iOiAwDQp9
Mensagem JSON sem codificação 64:
{
"EMPRESA": {
"CGC": "123456789",
"tipopessoa": 2
},
"Parametros": {
"ano": "2016",
"mes": "09"
},
"PAG": ""
}
Retorno Negativo:
{
"RESULT": {
"PAG": "",
"BILHETAGEM": []
},
"error": " Par�metros de data n�o foram informados. "
}
Retorno Positivo:
{
"RESULT": {
"PAG": "04022046000162",
"BILHETAGEM": [{
"CGC": "00358730000169",
"PRODUCAO": {
"DADOSBILHETAGEM": [{
"TIPODOC": "NFE",
"DOCUMENTOS": 46,
"TENTATIVAS": 133
}, {
"TIPODOC": "CTE",
"DOCUMENTOS": 9,
"TENTATIVAS": 15
}, {
"TIPODOC": "MDFE",
"DOCUMENTOS": 4,
"TENTATIVAS": 10
}, {
"TIPODOC": "NFSE",
"DOCUMENTOS": 15,
"TENTATIVAS": 51
}, {
"TIPODOC": "GNRE",
"DOCUMENTOS": 10,
"TENTATIVAS": 25
}, {
"TIPODOC": "ESOCIAL",
"DOCUMENTOS": 6,
"TENTATIVAS": 21
}, {
"TIPODOC": "MDE",
"DOCUMENTOS": 3,
"TENTATIVAS": 6
}, {
"TIPODOC": "NFCE",
"DOCUMENTOS": 5,
"TENTATIVAS": 11
}],
"TOTALDOCUMENTOS": 98,
"TOTALTENTATIVAS": 272
},
"HOMOLOGACAO": {
"DADOSBILHETAGEM": [{
"TIPODOC": "NFE",
"DOCUMENTOS": 68,
"TENTATIVAS": 173
}, {
"TIPODOC": "CTE",
"DOCUMENTOS": 26,
"TENTATIVAS": 59
}, {
"TIPODOC": "MDFE",
"DOCUMENTOS": 22,
"TENTATIVAS": 58
}, {
"TIPODOC": "NFSE",
"DOCUMENTOS": 36,
"TENTATIVAS": 90
}, {
"TIPODOC": "GNRE",
"DOCUMENTOS": 8,
"TENTATIVAS": 23
}, {
"TIPODOC": "ESOCIAL",
"DOCUMENTOS": 7,
"TENTATIVAS": 19
}, {
"TIPODOC": "MDE",
"DOCUMENTOS": 8,
"TENTATIVAS": 23
}, {
"TIPODOC": "NFCE",
"DOCUMENTOS": 8,
"TENTATIVAS": 17
}],
"TOTALDOCUMENTOS": 183,
"TOTALTENTATIVAS": 462
}
}, {
"CGC": "03890445000182",
"PRODUCAO": {
"DADOSBILHETAGEM": [{
"TIPODOC": "NFE",
"DOCUMENTOS": 32,
"TENTATIVAS": 95
}, {
"TIPODOC": "CTE",
"DOCUMENTOS": 3,
"TENTATIVAS": 3
}, {
"TIPODOC": "MDFE",
"DOCUMENTOS": 9,
"TENTATIVAS": 21
}, {
"TIPODOC": "NFSE",
"DOCUMENTOS": 13,
"TENTATIVAS": 43
}, {
"TIPODOC": "GNRE",
"DOCUMENTOS": 2,
"TENTATIVAS": 2
}, {
"TIPODOC": "ESOCIAL",
"DOCUMENTOS": 7,
"TENTATIVAS": 19
}, {
"TIPODOC": "MDE",
"DOCUMENTOS": 7,
"TENTATIVAS": 25
}, {
"TIPODOC": "NFCE",
"DOCUMENTOS": 3,
"TENTATIVAS": 6
}],
"TOTALDOCUMENTOS": 76,
"TOTALTENTATIVAS": 214
},
"HOMOLOGACAO": {
"DADOSBILHETAGEM": [{
"TIPODOC": "NFE",
"DOCUMENTOS": 50,
"TENTATIVAS": 149
}, {
"TIPODOC": "CTE",
"DOCUMENTOS": 19,
"TENTATIVAS": 58
}, {
"TIPODOC": "MDFE",
"DOCUMENTOS": 23,
"TENTATIVAS": 59
}, {
"TIPODOC": "NFSE",
"DOCUMENTOS": 46,
"TENTATIVAS": 118
}, {
"TIPODOC": "GNRE",
"DOCUMENTOS": 5,
"TENTATIVAS": 14
}, {
"TIPODOC": "ESOCIAL",
"DOCUMENTOS": 7,
"TENTATIVAS": 19
}, {
"TIPODOC": "MDE",
"DOCUMENTOS": 5,
"TENTATIVAS": 11
}, {
"TIPODOC": "NFCE",
"DOCUMENTOS": 3,
"TENTATIVAS": 9
}],
"TOTALDOCUMENTOS": 158,
"TOTALTENTATIVAS": 437
}
}]
},
"error": null
}
Função: GetBilling()
A função GETLISTDOC() deverá receber mensagens na estrutura JSON, onde serão convertidas em objeto pela função fwJsonDeserialize().
Caso não haja erro na deserialização de JSON para objeto, será chamada a rotina ValEntrada(), passando como parâmetro o objeto.
A função ValEntrada() retornará uma matriz com objetos, onde cada objeto será um tipo de documento diferente. Essa matriz será passada como parâmetro na chamada da função getJSONResp() junto com a mensagem de erro (caso exista). O retorno da função getJSONResp() é a mensagem já na estrutura JSON.
A rotina GetBilling() será finalizada e como retorno será passado a mensagem na estrutura JSON.
Parâmetros:
cJsonRequest =
{
"empresa": {
"CGC": "53113791000122",
"tipopessoa": 2
},
"parametros": {
"dtini": "19900101",
"dtfim": "20150826"
},
"PAG":"" ,
}
Retorno Negativo:
{
"RESULT": [],
"PAG": "",
"error": " Nenhuma entidade encontrada na base. "
}
Retorno Positivo:
{
"RESULT": [{
"CGC": "00860905000484",
"PRODUCAO": {
"NFE": {
"DOCUMENTOS": 43,
"TENTATIVAS": 109
},
"CTE": {
"DOCUMENTOS": 8,
"TENTATIVAS": 26
},
"MDFE": {
"DOCUMENTOS": 10,
"TENTATIVAS": 28
},
"NFSE": {
"DOCUMENTOS": 15,
"TENTATIVAS": 30
},
"GNRE": {
"DOCUMENTOS": 7,
"TENTATIVAS": 13
},
"ESOCIAL": {
"DOCUMENTOS": 4,
"TENTATIVAS": 10
},
"MDE": {
"DOCUMENTOS": 6,
"TENTATIVAS": 9
},
"NFCE": {
"DOCUMENTOS": 6,
"TENTATIVAS": 18
}
},
"HOMOLOGACAO": {
"NFE": {
"DOCUMENTOS": 37,
"TENTATIVAS": 91
},
"CTE": {
"DOCUMENTOS": 5,
"TENTATIVAS": 17
},
"MDFE": {
"DOCUMENTOS": 11,
"TENTATIVAS": 32
},
"NFSE": {
"DOCUMENTOS": 10,
"TENTATIVAS": 22
},
"GNRE": {
"DOCUMENTOS": 8,
"TENTATIVAS": 20
},
"ESOCIAL": {
"DOCUMENTOS": 3,
"TENTATIVAS": 9
},
"MDE": {
"DOCUMENTOS": 13,
"TENTATIVAS": 34
},
"NFCE": {
"DOCUMENTOS": 4,
"TENTATIVAS": 13
}
}
}],
"PAG": "",
"error": null
}
Função: ValEntrada()
A função receberá como parâmetro o objeto da requisição, validará todos os campos quanto a obrigatoriedade, tamanho e tipo de dados. Se algum dado estiver inconsistente, deverá retorna a mensagem de validação correspondente informando.
Os dados contidos no objeto recebido como parâmetro, serão validados afim de identificar quais foram preenchidos, os campos: TipoPessoa, CGC, DTINI, DTFIM e PAG (paginação).
Com as informações validadas, será chamada a função Billing(), para essa função serão passados como parâmetros: o CNPJ,CPF, data inicial, data final e paginação para a consulta. O retorno desta função será uma matriz contendo as informações de bilhetagem.
Após obter o retorno da rotina Billing(), a função ValEntrada() será encerrada, retornando a matriz.
Parâmetros:
oObjeto – Mensagem JSon deserializada e transformada em Objeto.
@cError – Mensagem de erro.
Retorno:
aMatriz – matriz contendo os dados da bilhetagem.
Função: Billing()
A rotina deverá executar o filtro na tabela do TSS , e deverá ter como retorno, uma matriz contendo as informações da bilhetagem dividido por: CNPJ/CPF - produção/homologação – Tipo de Documento – Total de tentativas/Total de documentos.
Após executar a query, a rotina gravará todos os dados encontrados em uma matriz. Essa matriz será o retorno da função.
Parâmetros:
cCNPJ – CNPJ do cliente.
cCPF - CPF do cliente.
dDtini – Data inicial de inclusão do documento do TSS
dDtfim – Data final de inclusão do documento no TSS
cPag – Controle de paginação de dados
cError – Mensagem de erro
Retorno:
aMatriz - Matriz multidimensional contendo objetos.
Função: GetJSONResp()
A rotina consiste em obter os dados de entrada e gerar a mensagem em estrutura JSON.
A rotina retornará uma string na estrutura JSON
Parâmetros:
aArray– Array multidimensional.
cPag – Controle de paginação.
cError – Mensagem de erro.
Retorno:
cJSONResponse – String na estrutura JSON.
(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
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
|---|
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas