Histórico da Página

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. O front fará o filtro sozinho, sem o auxilio da API. (#011)

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).

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 (SF1, SF2, SE1, SE2, SE5) 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). 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.

{
	"branchs": [],
	"dataMin": '10/01/2021',
	"dataMax": '21/01/2021',
	"AccountantAccounts": [],
	"conciliateBy": 1 */ 1 = processo, 2 = extrato bancário */,
	"process?": '000000000',
	"bankStatement?": {bank: '', account: '', agency: ''},
	"operation?": [],
	"filterEntity": true,
	"costCenters": [],
	"accountingItems": [],
	"clvl": []
}

{
    "OriginEntries":[
		{
			"BranchId":"D MG 01",
			"OriginEntry":"D MG 0103-04-2020001000010000000001",
			"OriginValue":1000.00,
			"Accounted":true,
			"Reconcilied":true
		},
		{
			"BranchId":"D MG 01",
			"OriginEntry":"D MG 0103-04-2020001000010000000001",
			"OriginValue":1000.00,
			"Accounted":true,
			"Reconcilied":true
		},
		{
			"BranchId":"D RJ 02",
			"OriginEntry":"D RJ 0205-04-2020001000020000000010",
			"OriginValue":5000.00,
			"Accounted":true,
			"Reconcilied":false
		},
		{
			"BranchId":"D RJ 02",
			"OriginEntry":"D RJ 0206-04-2020001000020000000002",
			"OriginValue":20000.00,
			"Accounted":true,
			"Reconcilied":true
		}
	],
	"AccountingEntries": [
        {
            "BranchId":"D MG 01",
            "MovementDate":"03-04-2020",
			"BatchNumber":"08850",
			"SubLot":"001",
			"Document":"000001",
			"Item":"001",
			"ItemType":"1",
			"EntryValue":1000.00,
			"Reconcilied":true
        },
        {
           "BranchId":"D MG 01",
            "MovementDate":"03-04-2020",
			"BatchNumber":"08850",
			"SubLot":"001",
			"Document":"000001",
			"Item":"002",
			"ItemType":"2",
			"EntryValue":1000.00,
			"Reconcilied":true
        },
        {
           "BranchId":"D RJ 02",
            "MovementDate":"05-04-2020",
			"BatchNumber":"08850",
			"SubLot":"001",
			"Document":"000001",
			"Item":"001",
			"ItemType":"3",
			"EntryValue":5000.00,
			"Reconcilied":false
        },
        {
            "BranchId":"D RJ 01",
            "MovementDate":"06-04-2020",
			"BatchNumber":"08850",
			"SubLot":"001",
			"Document":"000005",
			"Item":"001",
			"ItemType":"1",
			"EntryValue":20000.00,
			"Reconcilied":true
        }
    ]
}

{
	"AccountingEntries": [
		{
			"AccountingEntry": "D MG 0103-04-2020001000010000000001",
			"success": true
		},
		{
			"AccountingEntry": "D MG 0103-04-2020001000010000000002",
			"success": true
		},
		{
			"AccountingEntry": :"D RJ 0205-04-2020001000020000000003",
			"success": false
		},
		{
			"AccountingEntry": :"D RJ 0205-04-2020001000020000000010",
			"success": true
		}
	],
}

Também é necessário que o back-end retorne a propriedade _messages no objeto de retorno nas APIs de exclusão, edição e salvamento da conciliação de registros, como explicado detalhadamente nesta página do PO UI. Resumindo, essa propriedade serve para que o front-end exiba as mensagens de alerta conforme o status da requisição.

05. Campos e Parâmetros

06. Tabelas Utilizadas

• XXX - Conciliacao Contabil