Histórico da Página

Front-End:

Os campos do filtro serão construídos com o componente DynamicForm do PO UI. Ao carregar a tela, será necessário chamar uma API que recupera os filtros já salvos pelo usuário. Caso o endpoint retorne vazio, significa que o usuário ainda não salvou nenhum filtro. 

Por questão de performance, os endpoints dos selects/multiselects vão ser chamados somente quando clicados nos inputs. 

Os campos serão por seleção, ou seja, o usuário poderá selecionar todos os itens ou um item específico. Os inputs serão construídos com o módulo MultiSelect do PO UI. (#001)

Abaixo todos os filtros que vão estar disponíveis para configuração:

• Filial (multiselect)
• Data (de/até) (date)
• Conta contábil (multiselect)
• Moeda (select)
• Conciliar por (select) (dependendo do filtro, abrirá um novo campo para o usuário colocar o número do processo ou extrato bancário) (#003), (#028)
• Lançamento Padrão (multiselect) (#006)
• Filtra entidade (select boolean)
• Centro de custo (multiselect)
• Item contábil (multiselect)
• Clvl (multiselect)
• Lote (#002)
• Valor mínimo (#019)
• Valor máximo (#019)

Teremos um filtro de valor mínimo e valor máximo para que o sistema desconsidere a divergência de valores (caso haja) nos itens conciliados automaticamente. (#019)

Como citado acima, após salvar o formulário, o front fará uma requisição para o back-end enviando os dados que o usuário selecionou nos filtros. Quando o usuário acessar novamente, os filtros estarão salvos. (#007)

Cada campo terá um parâmetro onde será possível adicionar um texto de ajuda para aquele campo específico. O local de exibição da ajuda na tela ainda não está definido. (#008)

Como o PO UI não tem a função de ordenar colunas arrastando e soltando como existe no Protheus, só é possível alterar a ordem das colunas por meio do gerenciador de colunas que existe nas tabelas do PO UI. (#023) 

Back-End:

Será necessário uma API para salvar os filtros do usuário e uma outra API para recuperar o filtro já salvo.

Para que o filtro que o usuário realizou reflita nos grids, o front vai chamar as APIs que trazem as informações dos grids passando os valores dos filtros como query strings, assim a API vai saber o que filtrar na hora de trazer o resultado.

Os filtros deverão possuir help para facilitar entendimento do usuário.

Serão necessárias disponibilidade das APIs abaixo:

• API para informações de Filiais - Branch (SM0)

[]

{
    "items": [

Front-end:

A tabela será construída com o componente Table do PO UI. Na aba Exemplos já existe um exemplo de como construir a tabela no mesmo modelo que o especificado.

Antes do usuário ter acesso as informações do grid, ele precisa primeiro preencher os filtros para que sejam retornados os valores conforme o filtro ele selecionou.

Como citado na seção de filtros, é necessário o front passar uma query string com os filtros selecionados na chamada desses endpoints para que eles realizem o filtro de registros ao buscar no banco de dados.

No final de cada linha, teremos um botão "..." que conterá mais ações que o usuário poderá realizar com o registro selecionado, como Edição, Exclusão, Impressão, etc (as ações citadas estão pendentes de um protótipo de alta fidelidade no Figma com as telas das ações).

O usuário poderá configurar a exibição das colunas conforme a sua preferência. Após o usuário alterar a visibilidade das colunas e fechar o modal de configuração, o front enviará para a API as colunas que o usuário selecionou, e da próxima vez que ele atualizar a tela, a API vai trazer essas informações com as colunas que o usuário selecionou. O usuário poderá resetar a seleção de colunas abrindo o gerenciador de colunas e clicando em "restaurar padrão". (#022)

Na tabela de lançamentos contábeis, será possível adicionar lançamentos manuais, para que seja possível conciliar com a tabela de origem. (#009)

Acima das tabelas, teremos um combobox onde o usuário poderá filtrar por registros conciliados ou não conciliados ou registros contabilizados ou não contabilizados. O front fará o filtro sozinho, sem o auxilio da API. (#04, #011, #027)

Teremos essas opções no combobox citado acima: 

• Registros contabilizados e conciliados
• Registros não contabilizados e conciliados
• Registros contabilizados e não conciliados
• Registros não contabilizados e não conciliados

Após clicar no botão "Conciliar", um modal (aba 3) será exibido para que o usuário confirme sua ação. O modal será construído com o componente Modal do PO UI. Depois da confirmação do usuário, o sistema irá exibir um alerta para o usuário informando o usuário sobre o resultado da ação (aba 4). O alerta será construído com o Interceptor do PO UI, em conjunto com o back-end.

Abaixo dos grids, haverá dois totalizadores que vão calcular o valor de cada grid respectivamente. (#012).

Grid deverá possuir uma opção na parte superior para "Marcar Todos" ou marcar registro individual no check do próprio item (#015).  

Ao clicar no item origem ou destino, este item e seu correspondente na outra grid devem mudar de cor, dessa forma, facilitará a identificação (#016, #020).

Grid deve apresentar uma coluna "CTB" nos registros de origem, para indicar quando já foram contabilizados (#017).

Quando o valor da contabilização não bater com o valor origem, item deve apresentar uma cor diferente para identificação de divergências (#018).

Será possível realizar a exportação das tabelas via excel. Ao exportar o arquivo, os matches precisam estar alinhados para facilitar a visualização. No arquivo também terá a informação dos filtros que foram selecionados. (#020, #021).

Ao clicar sobre o registro de origem, sistema deverá exibir o rastreio, por exemplo se foi um lançamento com Nota Fiscal de Saída, Nota Fiscal de Entrada, Movimentação Bancária etc (#024).

Caso nos filtros seja selecionado fazer uma conciliação por saldo, as colunas da tabela serão alteradas para atender esse estilo de contabilidade. Os extratos terão um drill drown onde será possível ver todos os descontos dentro daquele extrato caso clicado para expandir a linha. Segue um exemplo: PO Table - Airfare (#028)

Back-end:

Será necessária disponibilidade das API abaixo, as consultas serão realizadas conforme os parâmetros informados:

• API para Lançamentos Contábeis (CT2) com as opções Get, Post, Put e Delete, receberá os parâmetros: Filial, Data, Número de Lote, Sub-Lote, Documento, Conciliados e Lançamento Padrão. Deve-se preencher o ComboBox com o status do lançamento: Conciliados, Não Conciliados

Na opção Get, deve-se retornar  dois objetos, um contendo os registros origens (SN4, SC5, SC7, SF1, SF2, SE1, SE2, FK5) dos lançamentos contábeis recuperados, quando tratar-se de lançamentos contábeis aglutinados, será necessário trazer cada origem relacionada e outro contendo as contabilizações destes registros juntamente com a conciliação quando já ocorreu (#010).

A apresentação dos registros de origem poderão ser Por Processos, onde serão retornadas as informações conforme o processo selecionado (Ativo Fixo, Compras/Estoque Custos, Contas a Pagar, Contas a Receber e Faturamento) ou Por Extrato Bancário, neste caso, a conciliação ocorre de maneira sintética, por saldo bancário olhando o extrato bancário (#028).

Quando apresentação por Extrato Bancário e um Recebimento de Título no Financeiro ocorreu no período filtrado, este será apresentado no grid de origem e sistema deverá apresentar também o lançamento que originou esse recebimento, mesmo que em outro período, exemplo: Lançamento que ocorreu em Novembro e o Recebimento em Dezembro e data informada no Filtro de Dezembro, deve-se apresentar os títulos origem de Novembro (#005).

Ainda na apresentação por Extrato Bancário, deve-se retornar os valores Saldo Inicial e Saldo Atual, com base na tabela SE8 (E8_SALATUA e E8_DTSALAT), ver função fa380Rec no fonte FINA380.PRX (#013). 

A opção Post, deve realizar a inclusão de novas conciliações de acordo com os parâmetros informados, Put deverá realizar alterações nas Conciliações Contábeis já existentes e finalmente a opção Delete, realizará a exclusão das Conciliações Contábeis selecionadas.

Para melhor performance, necessário avaliar a possível criação de stored procedure para consultas e manipulações das informações na Conciliação Contábil e processo de retorno das informações deve ocorrer de forma assíncrona.

• API para informações de Origem dos Lançamentos:

{
	"branchs": [],
	"dataMin": '10/01/2021',
	"dataMax": '21/01/2021',
	"AccountantAccounts": [],
	"conciliateBy": 1 */ 1 = processo, 2 = extrato bancário */,
	"process":  1 */ 1 = ativo fixo, 2 = materiais, 3 = faturamento, 4 = contas a pagar, 5 = contas a receber */,
	"bankStatement": {code: '', number: '', acountantaccountcode: ''},
	"operation": 1 */ 1 = ativo fixo, 2 = materiais, 3 = faturamento, 4 = contas a pagar, 5 = contas a receber */,
	"filterEntity": true,
	"costCenters": [],
	"accountingItems": [],
	"clvl": []
}

{
    "items":[
		{
			"branch":"D MG 01",
			"originentry":"D MG 0103-04-2020001000010000000001",
			"originvalue":1000.00,
			"origintable":"SN4",
			"originoperation":"1",
			"accounted":true,
			"reconcilied":true
		},
		{
			"branch":"D MG 01",
			"originentry":"D MG 0103-04-2020001000010000000001",
			"originvalue":1000.00,
			"origintable":"SN4",
			"originoperation":"1",
			"accounted":true,
			"reconcilied":true
		},
		{
			"branch":"D RJ 02",
			"originentry":"D RJ 0205-04-2020001000020000000010",
			"originvalue":5000.00,
			"origintable":"SF2",
			"originoperation":"3",
			"accounted":true,
			"reconcilied":false
		},
		{
			"branch":"D RJ 02",
			"originentry":"D RJ 0206-04-2020001000020000000002",
			"originvalue":20000.00,
			"origintable":"SE1",
			"originoperation":"5",
			"accounted":true,
			"reconcilied":true
		}
    ],
	"hasNext":true,
    "po_sync_date":"2021-02-09T21:00:38Z"