...
| Produto: | | Solucoes_totvs |
|---|
| Solucao | TOTVS Jurídico Departamentos |
|---|
|
| Solucoes_totvs_parceirosexptotvs |
|---|
|
|
|---|
| Linha de Produto: | |
|---|
| Segmento: | |
|---|
| Módulo: | | Modulos_totvs_juridico |
|---|
| ModulosTOTVSJuridico | Departamentos - Departamentos (SIGAJURI) |
|---|
|
| Modulos_totvs_prestadores_de_servicos |
|---|
|
|---|
| Função: | WSJurConsultas.PRW jurconsultas.service.ts custom-fields.component.ts |
|---|
| País: | Brasil |
|---|
| Ticket: |
|
|---|
| Requisito/Story/Issue (informe o requisito relacionado) : |
|
|---|
02. SITUAÇÃO/REQUISITO
03. SOLUÇÃO
...
| tabs | Passo 01, Passo 02, Passo 03, Passo 04 |
|---|
| ids | passo1,passo2 |
|---|
Foi identificado que, em algumas consultas padrão, utilizadas via TJD, os usuários precisam preencher campos auxiliares adicionais em tela (como Banco, Agência e Conta) a partir de dados retornados pela consulta. Porém esses dados são apenas concatenados no label do campo, deixando a visualização poluída e pouco usável.
Atualmente, o cliente configura múltiplos campos de origem (ex.: A2_BANCO, A2_AGENCIA, A2_CONTA, A2_CNTDIV) no 3º parâmetro da JURSXB, e o sistema monta um único label com todas as informações, o que dificulta a leitura e não permite preencher automaticamente os campos de destino do cadastro (ex.: NT3_CODBAN, NT3_CODAGE, NT3_AGNDIV, NT3_CNTBNC, NT3_CONDIV).
Diante disso, surgiu a necessidade de padronizar uma forma de a Consulta Padrão informar ao TJD quais campos adicionais devem ser retornados, e em quais campos do formulário esses valores deverão ser aplicados, por meio de uma estrutura de de/para que permita ao endpoint retornar esses dados extras para os Campos Customizados.
03. SOLUÇÃO
Para tanto, implementamos uma nova regra na Consulta Padrão (getF3List) para permitir o retorno de campos adicionais vinculados à consulta, de forma parametrizada, contemplando o cenário em que o TJD consome essas informações para preenchimento automático de campos auxiliares em tela.
Criamos uma nova estrutura de dicionário/tabela (O1K) para registrar o de/para dos campos, onde passamos a identificar para cada registro: (i) qual é a Consulta Padrão utilizada; (ii) qual é a tela/rotina de origem; e (iii) quais são os campos de origem e de destino que devem participar do mapeamento, garantindo que, quando houver configuração, esses campos sejam incluídos automaticamente no SELECT e retornados no payload da API.
Adaptamos o endpoint responsável pela consulta para que, ao montar o response, retorne os valores mapeados na nova estrutura dentro de um objeto de “extras”, por exemplo: “extras”: { “NT3__AGENC”: “033”, “NT3__CONTA”: “555” ... }), permitindo que o componente de Campos Customizados aplique o patchValue nesses campos de destino e elimine a dependência da concatenação excessiva de informações no label da consulta.
Estrutura de dicionário e tabela O1K - De\Para de Campos Customizados:
...
| default | yes |
|---|
| referencia | passo1 |
|---|
...
04. DEMAIS INFORMAÇÕES
| Card documentos |
|---|
| Informacao | Use esse box para destacar informações relevantes e/ou de destaque. |
|---|
| Titulo | IMPORTANTE! |
|---|
|
...