Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|
Informações Gerais
Especificação | |||
Produto | CRM | Módulo | CRL - Relacionamento |
Segmento Executor | Manufatura | ||
Projeto1 | IRM1 |
| |
Requisito1 |
| Subtarefa1 |
|
Chamado2 |
| ||
País | ( X ) Brasil ( ) Argentina ( ) Mexico ( ) Chile ( ) Paraguai ( ) Equador ( ) USA ( ) Colombia ( ) Outro _____________. | ||
Outros |
Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos).
Objetivo
Permitir ao usuário consultar os dados referentes ao CEP na base dos Correios através da API do TOTVS Mashups. Esta consulta tem por intenção validar o CEP informado no cadastro dos endereço junto a base dos Correios a fim de garantir maior integridade. A utilização do TOTVS Mashups será opcional, sendo necessário ativa-la para utilização no CRM.
Definição da Regra de Negócio
Parâmetros
A fim de garantir a suavização das novas funcionalidades, o primeiro passo para este desenvolvimento é criar um novo parâmetro no CRM (MASHUPS_ATIVOS) para que seja possível chavear a funcionalidade. Este parâmetro tem como função habilitar e desabilitar as chamadas à API do TOTVS Mashups.
IF NOT CAN-FIND(FIRST CRM_PARAM NO-LOCK WHERE CRM_PARAM.NOM_PARAM_CRM = 'MASHUPS_ATIVOS') THEN DO: CREATE CRM_PARAM. ASSIGN CRM_PARAM.NUM_ID = NEXT-VALUE(SEQ_CRM_PARAM). CRM_PARAM.NOM_GRP_PARAM = 'Integração'. CRM_PARAM.NOM_TIT_PARAM = 'Habilita a integração com o serviço do TOTVS Mashups?'. CRM_PARAM.NOM_PARAM_CRM = 'MASHUPS_ATIVOS'. CRM_PARAM.DSL_PARAM_CRM = 'false'. CRM_PARAM.DSL_PARAM_CRM_DEFAULT = 'false'. CRM_PARAM.IDI_CAMPO_COMPON = 4. CRM_PARAM.IDI_TIP_DADOS_CRM = 2. CRM_PARAM.DSL_DESCR_PARAM = 'Este parâmetro indica se o CRM está habilitado a utilizar os serviços de domínio público disponíveis no TOTVS Mashups (Consulta a base de CEP dos Correios, Receita Federal, entre outros). Para maiores informações entre em contato com o Suporte da TOTVS.'. END.
Este parâmetro deve ser incluído no programa crm_param.p para que o administrador do CRM possa realizar a carga do mesmo no sistema. Por padrão este parâmetro será liberado como 'false', ou seja, esta funcionalidade estará desativada, sendo necessário ativa-la para utilização.
Validação de CEP
A consulta/validação do CEP através da API do TOTVS Mashups deverá ocorrer de forma transparente para o usuário final.
Desta forma será preciso alterar o a fachada de CEP (fchcrm1008.p) para adicionar um novo método para realizar este procedimento com a seguinte assinatura:
PROCEDURE validatePostalCode: DEFINE INPUT PARAM c_code AS CHARACTER NO-UNDO. DEFINE OUTPUT PARAM DATASET FOR DSCRMCEP. DEFINE OUTPUT PARAM TABLE FOR RowErrors. END PROCEDURE.
Este método deverá estar exposto como serviço respeitando a seguinte assinatura:
PROCEDURE REST_GET_validate_postal_code: DEFINE INPUT PARAM QP_code AS CHARACTER NO-UNDO. DEFINE OUTPUT PARAM DATASET FOR DSCRMCEP. DEFINE OUTPUT PARAM TABLE FOR RowErrors. RUN validatePostalCode (INPUT QP_code, OUTPUT DATASET DSCRMCEP, OUTPUT TABLE RowErrors). END PROCEDURE.
Importante
A definição do Dataset de CEP (DSCRMCEP) não deverá ser alterada.
A implementação do método deverá seguir a seguinte linha:
- Verificar se o CRM está habilitado a utilizar a API do TOTVS Mashups através do parâmetro: MASHUPS_ATIVOS.
- Caso o CRM não esteja habilitado a utilizar a API do TOTVS Mashups, o sistema deve continuar realizando a consulta na base de CEP do próprio CRM através do método: findPostalCode.
- Com o CRM habilitado a utilizar a API do TOTVS Mashups, o sistema deve realizar a chamada ao serviço de consulta de CEP conforme documentação disponibilizada pelo Framework JOI aqui.
- Quando ocorrer algum problema com a chamada da API do TOTVS Mashups o sistema deverá realizar a consulta na base de CEP do próprio CRM através do método findPostalCode. E retornar uma mensagem de informação ao usuário de que não foi possível realizar a consulta na API do TOTVS Mashups e o erro deve ser impresso no arquivo de log do Progress Appserver. Mensagem: Ocorreu uma situação inesperada durante a chamada ao serviço do TOTVS Mashups. A verificação do CEP foi realizada na base do CRM.
Quando encontrado o CEP na API do TOTVS Mashup, o retorno se dará através de um 'objeto' com os seguintes atributos:
- CEP: código do CEP informado;
- Estado: Código da unidade de federação;
- Cidade: Nome da cidade;
- Bairro: Nome do bairro, quando existir;
- Endereço: Logradouro, quando existir.
Importante
Em determinados casos um CEP pode corresponder a uma cidade inteira como é o caso de Barra Velha - SC, 88.390-000. Nestes casos os campos de bairro e logradouro não são retornados pela API do TOTVS Mashups.
Os dados retornados pela API do TOTVS Mashups para o CEP devem ser converitdos para os registros do CRM. Desta forma para cada um dos itens (Estado, Bairro e Cidade) será preciso buscar os respectivos registros na base do CRM conforme as seguintes regras:
- País: Buscar os dados na tabela crm_pais de acordo com o país padrão informado para o CRM;
Importante
A API do TOTVS Mashups não retorna o país do CEP informado pois o CEP em sí é exclusivo do Brasil. Neste caso, para montagem do dataset (DSCRMCEP) devemos considerar o país padrão informado para o CRM, especificado através do parâmetro PAIS_DEFAULT.
- Estado: Buscar os dados na tabela crm_unid_federac utilizando como filtros o código interno do país (crm_pais.num_id) e o código da unidade de federação (nom_unid_federac);
- Cidade: Buscar os dados na tabela crm_cidad utilizando como filtros o código interno da unidade de federação (crm_unid_federac.num_id) e o nome da cidade (nom_cidade);
- Bairro: Buscar os dados na tabela crm_bairro utilizando como filtros o código interno da cidade (crm_cidad.num_id) e o nome do bairro (nom_bairro); Caso o bairro não seja encontrado no CRM deve retornar para a tela de cadastro de endereço apenas o nome do bairro retornado pela API do TOTVS Mashups, para que, posteriormente, na inclusão do endereço o bairro seja incluído no CRM.
Importante
Quando o serviço não retornar nenhum dado o dataset (DSCRMCEP) deve ser retornado vazio para a tela de cadastro de endereço. Entretanto, quando a API do TOTVS Mashups retornar os dados e por ventura não possuir Bairro e/ou Endereço no retorno, estes deverão ser retornados "em branco" no dataset (DSCRMCEP).
Na parte HTML do CRM será preciso criar o método validatePostalCode na factory crm.crm_cep.factory (fchcrm1008.js), conforme exemplo a baixo:
factory.validatePostalCode = function (cep, callback) { return this.TOTVSQuery({method: 'validate_postal_code', code: cep}, function (result) { if (callback) { callback(result); } }); };
E por fim alterar o método getZipcodes no controller crm.account-address.edit.control (address-services.js) para realizar a chamada ao método validatePostalCode ao invés do findPostalCode, conforme exemplo:
this.getZipcodes = function(value) { this.postalcodes = undefined; if (!value || value === '' || value.length < 8) return []; return postalcodeFactory.validatePostalCode(value, function(result) { CRMControlAccountAddressEdit.postalcodes = result || []; if (CRMControlAccountAddressEdit.postalcodes.length === 0) { $rootScope.$broadcast(TOTVSEvent.showNotification, { type: 'warning', title: $rootScope.i18n('l-addresses', [], 'dts/crm'), detail: $rootScope.i18n('msg-not-found-postal-code', [ value ], 'dts/crm') }); } }); }
Importante
A consulta de CEP na API do TOTVS Mashups somente é realizada com o CEP completo (8 dígitos), portanto, a chamada ao método validatePostalCode somente será realizada após o preenchimento completo do CEP.
Rotina | Tipo de Operação | Opção de Menu | Regras de Negócio |
Cadastro de Endereços | Alteração | CRM -> Gestão de Contas -> Manutenção de Contas | - |
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
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> |
Grupo de Perguntas
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. |
---|