Inventário do BD

entidade	chave primária	atributos
core.cliente_e_factoring	id_nomus	7
core.empresa	empresa_id	7
core.nota_fiscal	id_nomus	13
core.papel	papel_id	2
core.pessoa	pessoa_id	8
core.tela	tela_id	5
core.titulo	id_nomus	16
desconto_titulos.bordero	bordero_id	15
desconto_titulos.leitura	leitura_id	9

Atributos

Cada coluna do banco, uma por linha. Embaixo do nome técnico vem a entidade desta linha; em onde vêm os outros lugares em que esse mesmo nome aparece — os dois nunca repetem a mesma informação. lugares conta o total, e é o teste do um campo, um cadastro, um lugar: 1 é o normal, e o número alto é o que merece olhar. dono ainda não é declarado em lugar nenhum: virá dos MAPA-DE-DADOS.md dos projetos, e até lá todo — aqui significa não declarado, nunca sem dono.

nome técnico	nome comum	tipo	chave	obrigatório	descrição	lugares	onde	dono
arquivo _controle.migracao	—	text	PK	sim	—	1	só aqui	—
sha256 _controle.migracao	—	text	—	sim	—	1	só aqui	—
aplicado_em _controle.migracao	—	timestamptz	—	sim	—	1	só aqui	—
aplicado_por _controle.migracao	—	text	—	sim	—	1	só aqui	—
duracao_ms _controle.migracao	—	integer	—	não	—	2	bi.leitura	—
pedido app.carteira_humano	—	text	PK	sim	—	3	app.pedido_pronto_desde, bi.carteira_item	—
tem_que_sair app.carteira_humano	—	date	—	não	—	1	só aqui	—
obs app.carteira_humano	—	text	—	não	—	1	só aqui	—
atualizado_em app.carteira_humano	—	timestamptz	—	sim	—	4	app.prazo_transito, core.cliente_e_factoring, desconto_titulos.bordero	—
atualizado_por app.carteira_humano	—	text	FK → core.pessoa.pessoa_id	não	—	3	app.prazo_transito, desconto_titulos.bordero	—
lido_em app.conferencia_a_faturar	—	timestamptz	PK (2 col.)	sim	Instante da execução. Parte da chave: duas leituras no mesmo dia são duas fotos legítimas, porque o BI é republicado e muda ao longo do dia (B1).	4	core.nota_fiscal, core.titulo, raw.resposta	—
meta app.conferencia_a_faturar	—	text	PK (2 col.)	sim	Qual das duas conferências: vigente (meta do mês corrente) ou proximo. As duas são independentes — uma pode bater e a outra não.	1	só aqui	—
meta_rotulo app.conferencia_a_faturar	—	text	—	sim	O rótulo do slicer do Power BI no dia da leitura, ex. "META SETEMBRO". Guardado porque o nome muda todo mês: sem ele, uma linha antiga não diz de que mês falava.	1	só aqui	—
bi_total app.conferencia_a_faturar	—	numeric	—	sim	Soma da coluna "A Faturar" do Power BI, no recorte desta meta, em reais.	1	só aqui	—
sf_total app.conferencia_a_faturar	—	numeric	—	sim	Total do relatório Quadro de Vendas do Salesforce, no recorte desta meta, em reais. Lido do relatório que o Rodrigo abre, com os filtros dele.	1	só aqui	—
diferenca app.conferencia_a_faturar	—	numeric	—	não	bi_total - sf_total. GERADA pelo banco: não pode discordar das parcelas (A7). Positiva = o BI diz que falta mais do que o Salesforce.	1	só aqui	—
bi_linhas app.conferencia_a_faturar	—	jsonb	—	sim	O retorno BRUTO do Power BI (A8): as linhas como vieram, inclusive campo que a conferência de hoje não usa. Reler traz o presente; o passado não volta.	1	só aqui	—
sf_linhas app.conferencia_a_faturar	—	jsonb	—	sim	O retorno BRUTO do relatório do Salesforce (A8): as 7 colunas de detalhe, incluindo as que a conferência não lê.	1	só aqui	—
achados app.conferencia_a_faturar	—	jsonb	—	sim	A análise pedido a pedido, derivada do bruto: o que está só num lado, e o que está nos dois com valores diferentes. É o corpo do e-mail.	1	só aqui	—
falhas app.conferencia_a_faturar	—	ARRAY	—	sim	O que NÃO foi possível conferir, e por quê (D1). Vazio = os dois lados responderam. Sucesso parcial não é sucesso, e o e-mail declara o que faltou.	2	bi.leitura	—
pedido app.pedido_pronto_desde	—	text	PK	sim	—	3	app.carteira_humano, bi.carteira_item	—
pronto_desde app.pedido_pronto_desde	—	date	—	não	Primeira execucao em que o pedido apareceu 100% pronto. NULO = ja estava pronto quando a medicao comecou (21/08/2026); a data nunca existiu em fonte nenhuma e a tela mostra a coluna vazia.	1	só aqui	—
visto_ate app.pedido_pronto_desde	—	date	—	sim	—	1	só aqui	—
registrado_em app.pedido_pronto_desde	—	timestamptz	—	sim	—	1	só aqui	—
cliente app.prazo_transito	—	text	PK	sim	—	2	bi.carteira_item	—
dias app.prazo_transito	—	integer	—	sim	—	1	só aqui	—
atualizado_em app.prazo_transito	—	timestamptz	—	sim	—	4	app.carteira_humano, core.cliente_e_factoring, desconto_titulos.bordero	—
atualizado_por app.prazo_transito	—	text	—	não	—	3	app.carteira_humano, desconto_titulos.bordero	—
atualizado_por_pessoa_id app.prazo_transito	—	text	FK → core.pessoa.pessoa_id	não	Quem alterou, provado por auth.uid(). NULL nas linhas anteriores ao login (agosto/2026), onde só existe o nome digitado em atualizado_por.	1	só aqui	—
leitura_id bi.carteira_item	—	bigint	FK → bi.leitura.id PK (2 col.)	sim	—	3	desconto_titulos.leitura, raw.resposta	—
seq bi.carteira_item	—	integer	PK (2 col.)	sim	—	1	só aqui	—
pedido bi.carteira_item	—	text	—	sim	—	3	app.carteira_humano, app.pedido_pronto_desde	—
inserido_em bi.carteira_item	—	date	—	não	—	1	só aqui	—
cliente bi.carteira_item	—	text	—	sim	—	2	app.prazo_transito	—
cod bi.carteira_item	—	text	—	sim	—	2	bi.produto	—
produto bi.carteira_item	—	text	—	sim	—	2	bi.produto	—
pend bi.carteira_item	—	integer	—	sim	—	1	só aqui	—
limite bi.carteira_item	—	date	—	não	—	1	só aqui	—
inspecao bi.carteira_item	—	text	—	não	—	1	só aqui	—
agend bi.carteira_item	—	date	—	não	—	1	só aqui	—
valor bi.carteira_item	—	numeric	—	sim	—	2	desconto_titulos.liquidacao	—
faturado bi.carteira_item	—	numeric	—	sim	—	1	só aqui	—
a_faturar bi.carteira_item	—	numeric	—	sim	—	1	só aqui	—
tipo_venda bi.carteira_item	—	text	—	não	—	1	só aqui	—
id bi.leitura	—	bigint	PK	sim	—	2	core.registro_de_mudanca	—
lida_em bi.leitura	—	timestamptz	—	sim	—	1	só aqui	—
data_ref bi.leitura	—	date	—	sim	—	1	só aqui	—
aprovada bi.leitura	—	boolean	—	sim	—	2	desconto_titulos.leitura	—
itens bi.leitura	—	integer	—	sim	—	1	só aqui	—
pedidos bi.leitura	—	integer	—	sim	—	1	só aqui	—
pend_total bi.leitura	—	integer	—	sim	—	1	só aqui	—
valor_total bi.leitura	—	numeric	—	não	—	2	core.nota_fiscal	—
ancoras bi.leitura	—	jsonb	—	sim	—	2	desconto_titulos.leitura	—
falhas bi.leitura	—	ARRAY	—	sim	—	2	app.conferencia_a_faturar	—
duracao_ms bi.leitura	—	integer	—	não	—	2	_controle.migracao	—
cod bi.produto	—	text	PK	sim	—	2	bi.carteira_item	—
produto bi.produto	—	text	ALT	sim	—	2	bi.carteira_item	—
apelido bi.produto	—	text	—	não	—	1	só aqui	—
visto_em bi.produto	—	timestamptz	—	sim	—	1	só aqui	—
id_nomus core.cliente_e_factoring	—	integer	PK	sim	O id da pessoa no ERP Nomus. E a chave do sync e a unica que sempre existe.	4	core.empresa, core.nota_fiscal, core.titulo	—
documento core.cliente_e_factoring	—	text	ALT	não	CNPJ (14 digitos) ou CPF (11), so digitos. E ele quem pega duplicata de verdade: a D8 registrou o mesmo cliente gravado com duas grafias de NOME. Fica nulo quando o Nomus nao trouxe.	1	só aqui	—
nome core.cliente_e_factoring	—	text	—	sim	Como aparece no Nomus (nomePessoa). NUNCA e chave: muda e repete. Existe para aparecer na tela.	4	core.papel, core.pessoa, core.tela	—
e_factoring core.cliente_e_factoring	—	boolean	—	sim	CAMPO HUMANO dentro de tabela de sync, e a excecao esta declarada no cartao de modelagem. Ele marca quem desconta; o Nomus nao distingue. O leitor faz on conflict do update coluna a coluna e NUNCA toca nesta — se tocasse, apagaria a marcacao dele a cada leitura (A10).	1	só aqui	—
ativo core.cliente_e_factoring	—	boolean	—	sim	Contraparte que saiu de uso e inativada, nunca apagada: apagar quebraria os titulos que apontam para ela.	3	core.empresa, core.pessoa	—
criado_em core.cliente_e_factoring	—	timestamptz	—	sim	Quando a linha entrou neste banco.	6	core.empresa, core.pessoa, desconto_titulos.bordero, desconto_titulos.liquidacao, desconto_titulos.operacao	—
atualizado_em core.cliente_e_factoring	—	timestamptz	—	sim	Ultima vez que o sync do Nomus reescreveu esta linha.	4	app.carteira_humano, app.prazo_transito, desconto_titulos.bordero	—
empresa_id core.empresa	—	text	PK	sim	Codigo curto e legivel, atribuido por ele: real, lider. Legivel de proposito — erro de digitacao aparece a olho, um numero errado nao avisa nada.	4	core.nota_fiscal, core.titulo, desconto_titulos.bordero	—
id_nomus core.empresa	—	integer	ALT	sim	O idEmpresa do ERP Nomus. E por ele que o leitor casa: 2 = Real, 3 = Lider. A instancia do Nomus tem SEIS empresas; so estas duas entram.	4	core.cliente_e_factoring, core.nota_fiscal, core.titulo	—
cnpj core.empresa	—	text	ALT	sim	CNPJ so com digitos, 14 posicoes, sem ponto nem barra.	1	só aqui	—
razao_social core.empresa	—	text	—	sim	Nome de registro, como sai na nota fiscal. Ex.: REAL ENERGIA LTDA.	1	só aqui	—
nome_fantasia core.empresa	—	text	—	não	Como a empresa e chamada no dia a dia. E POR CAUSA DESTE CAMPO que esta tabela e core: a Real Energia tem nomeFantasia "Ancora Industrial", entao dois apps gravando por conta propria escreveriam nomes diferentes para a mesma empresa (D63).	1	só aqui	—
ativo core.empresa	—	boolean	—	sim	Empresa que saiu de operacao e INATIVADA, nunca apagada: apagar quebraria toda nota e titulo que apontam para ela.	3	core.cliente_e_factoring, core.pessoa	—
criado_em core.empresa	—	timestamptz	—	sim	Quando a linha entrou neste banco. Nao e a data de abertura da empresa.	6	core.cliente_e_factoring, core.pessoa, desconto_titulos.bordero, desconto_titulos.liquidacao, desconto_titulos.operacao	—
id_nomus core.nota_fiscal	—	integer	PK	sim	O idNfe do Nomus. E por ele que o titulo casa com a nota — NUNCA pelo numero.	4	core.cliente_e_factoring, core.empresa, core.titulo	—
empresa_id core.nota_fiscal	—	text	FK → core.empresa.empresa_id ALT (3 col.)	sim	Qual das empresas dele emitiu.	4	core.empresa, core.titulo, desconto_titulos.bordero	—
numero core.nota_fiscal	—	integer	ALT (3 col.)	sim	O numero da nota. Sozinho NAO identifica: precisa de serie e empresa junto.	2	desconto_titulos.bordero	—
serie core.nota_fiscal	—	integer	ALT (3 col.)	sim	Serie da nota. A Lider emite serie 1; a Eletrorev, serie 0.	1	só aqui	—
chave core.nota_fiscal	—	text	ALT	não	Os 44 digitos da chave de acesso da NF-e. Unica no Brasil inteiro quando existe.	1	só aqui	—
is_fornecedor core.nota_fiscal	—	boolean	—	sim	false = nota de saida nossa; true = nota de fornecedor. Vem do isFornecedor do Nomus (0/1).	1	só aqui	—
status_nomus core.nota_fiscal	—	integer	—	não	Status NUMERICO do Nomus. 4 e o normal (150 de 152 vendas na janela medida). 6 e 7 apareceram 1 vez cada e NINGUEM sabe o que sao, nem ele — por isso a tela diz "status nao usual" e nunca "cancelada".	1	só aqui	—
natureza_operacao core.nota_fiscal	—	text	—	não	natOp do XML. NAO existe como campo da API do Nomus: so vem lendo o XML.	1	só aqui	—
cfop core.nota_fiscal	—	text	—	não	CFOP do XML. Tambem nao existe como campo da API.	1	só aqui	—
valor_total core.nota_fiscal	—	numeric	—	não	vNF do XML. Dinheiro em numeric, nunca float (A4).	2	bi.leitura	—
pedido_interno core.nota_fiscal	—	text	—	não	O numero do pedido de venda, extraido do infCpl do XML com o padrao "PEDIDO INTERNO: nnnn". E o elo com o Salesforce (OrderNumber). NAO confundir com SEU PEDIDO / xPed, que e a ordem de compra do CLIENTE.	1	só aqui	—
data_processamento core.nota_fiscal	—	date	—	não	dataProcessamento do Nomus — e por ela que a leitura diaria filtra a janela.	1	só aqui	—
lido_em core.nota_fiscal	—	timestamptz	—	sim	Quando o sync leu esta linha pela ultima vez.	4	app.conferencia_a_faturar, core.titulo, raw.resposta	—
papel_id core.papel	—	text	PK	sim	—	3	core.pessoa_tem_papel, core.tela_aceita_papel	—
nome core.papel	—	text	—	sim	—	4	core.cliente_e_factoring, core.pessoa, core.tela	—
pessoa_id core.pessoa	—	text	PK	sim	—	2	core.pessoa_tem_papel	—
nome core.pessoa	—	text	—	sim	—	4	core.cliente_e_factoring, core.papel, core.tela	—
email core.pessoa	—	text	ALT	sim	UNIQUE mas NAO e chave (D6/D40): o e-mail muda, e quando mudar e um UPDATE aqui, sem tocar em FK nenhuma.	1	só aqui	—
auth_id core.pessoa	—	uuid	FK → auth.users.id ALT	não	—	1	só aqui	—
precisa_trocar_senha core.pessoa	—	boolean	—	sim	D21: o Supabase Auth nao tem troca obrigatoria nativa. A tela barra o acesso enquanto isto for true.	1	só aqui	—
ativo core.pessoa	—	boolean	—	sim	—	3	core.cliente_e_factoring, core.empresa	—
inativado_em core.pessoa	—	timestamptz	—	não	—	1	só aqui	—
criado_em core.pessoa	—	timestamptz	—	sim	—	6	core.cliente_e_factoring, core.empresa, desconto_titulos.bordero, desconto_titulos.liquidacao, desconto_titulos.operacao	—
pessoa_id core.pessoa_tem_papel	—	text	FK → core.pessoa.pessoa_id PK (2 col.)	sim	—	2	core.pessoa	—
papel_id core.pessoa_tem_papel	—	text	FK → core.papel.papel_id PK (2 col.)	sim	—	3	core.papel, core.tela_aceita_papel	—
ligado_em core.pessoa_tem_papel	—	timestamptz	—	sim	—	1	só aqui	—
id core.registro_de_mudanca	—	bigint	PK	sim	—	2	bi.leitura	—
quando core.registro_de_mudanca	—	timestamptz	—	sim	—	1	só aqui	—
quem core.registro_de_mudanca	—	text	FK → core.pessoa.pessoa_id	não	—	1	só aqui	—
quem_auth core.registro_de_mudanca	—	uuid	—	não	—	1	só aqui	—
papel_no_banco core.registro_de_mudanca	—	text	—	sim	—	1	só aqui	—
tabela core.registro_de_mudanca	—	text	—	sim	—	1	só aqui	—
operacao core.registro_de_mudanca	—	text	—	sim	—	1	só aqui	—
antes core.registro_de_mudanca	—	jsonb	—	não	—	1	só aqui	—
depois core.registro_de_mudanca	—	jsonb	—	não	—	1	só aqui	—
tela_id core.tela	—	text	PK	sim	—	2	core.tela_aceita_papel	—
nome core.tela	—	text	—	sim	—	4	core.cliente_e_factoring, core.papel, core.pessoa	—
caminho core.tela	—	text	—	sim	—	1	só aqui	—
grupo core.tela	—	text	—	sim	—	1	só aqui	—
ativa core.tela	—	boolean	—	sim	—	1	só aqui	—
tela_id core.tela_aceita_papel	—	text	FK → core.tela.tela_id PK (2 col.)	sim	—	2	core.tela	—
papel_id core.tela_aceita_papel	—	text	FK → core.papel.papel_id PK (2 col.)	sim	—	3	core.papel, core.pessoa_tem_papel	—
id_nomus core.titulo	—	integer	PK	sim	O id do contasReceber no Nomus.	4	core.cliente_e_factoring, core.empresa, core.nota_fiscal	—
empresa_id core.titulo	—	text	FK → core.empresa.empresa_id	sim	Qual das empresas dele. O contasReceber mistura as SEIS empresas da instancia; so 2 (Real) e 3 (Lider) entram.	4	core.empresa, core.nota_fiscal, desconto_titulos.bordero	—
nota_fiscal_id core.titulo	—	integer	FK → core.nota_fiscal.id_nomus	não	A nota que originou. Fica NULO no lancamento 51.05 (desconto), que nao nasce de nota. O elo e sempre por idNfe, nunca pelo numero da nota.	1	só aqui	—
cliente_e_factoring_id core.titulo	—	integer	FK → core.cliente_e_factoring.id_nomus	não	ATENCAO — o significado MUDA conforme a classificacao. Em 10.01/10.02 e o CLIENTE que comprou. Em 51.05 e o DESCONTADOR, ou seja, a factoring que descontou. E o mesmo campo nomePessoa do Nomus fazendo dois papeis (D65).	1	só aqui	—
classificacao core.titulo	—	text	—	sim	Codigo da classificacao no Nomus. 10.01 venda a vista, 10.02 venda a prazo, 51.05 desconto de NF, 51.03 aporte de socios, 45.17 reembolso, 54.01 emprestimo, 10.03 outras receitas, 52.07 venda de ativos. SO 10.01 e 10.02 sao venda (D66).	1	só aqui	—
nome_classificacao core.titulo	—	text	—	não	O rotulo por extenso que o Nomus da a classificacao. E pista, nunca criterio: o codigo e que manda.	1	só aqui	—
data_competencia core.titulo	—	date	—	não	Data de competencia — na pratica a emissao.	1	só aqui	—
data_vencimento core.titulo	—	date	—	não	Quando o titulo vence. Nulo acontece, e a tela mostra vazio, nunca zero.	1	só aqui	—
data_baixa core.titulo	—	date	—	não	Quando o titulo foi baixado (recebido). Nulo = em aberto.	1	só aqui	—
valor_receber core.titulo	—	numeric	—	não	Valor de face do titulo.	1	só aqui	—
saldo_receber core.titulo	—	numeric	—	não	O que ainda esta DISPONIVEL PARA DESCONTAR. E a ancora de graca do app de desconto: a soma dos pedacos descontados tem de bater com valor_receber menos saldo_receber.	1	só aqui	—
valor_recebido core.titulo	—	numeric	—	não	Quanto ja entrou.	1	só aqui	—
conta_bancaria core.titulo	—	text	—	não	Nome da conta bancaria no Nomus.	1	só aqui	—
forma_pagamento core.titulo	—	text	—	não	Forma de pagamento no Nomus. E FORMA, nao condicao — nao confundir os dois (o pedido 7696 ja veio com "Boleto Bancario" no campo de condicao).	1	só aqui	—
status_desconto_duplicata core.titulo	—	smallint	—	não	Estado do desconto no Nomus. NULO = nunca passou por desconto. 3 = descontado. 1 = estado anterior ao 3, NAO DECIFRADO — nem ele sabe o que e, entao 1 nunca vira "descontado" na tela. Medido em 2.020 titulos (25/08/2026).	1	só aqui	—
lido_em core.titulo	—	timestamptz	—	sim	Quando o sync leu esta linha pela ultima vez.	4	app.conferencia_a_faturar, core.nota_fiscal, raw.resposta	—
bordero_id desconto_titulos.bordero	—	bigint	PK	sim	Chave propria. Existe porque o numero da factoria as vezes so chega depois, e o desconto precisa ser lancado antes.	2	desconto_titulos.operacao	—
empresa_id desconto_titulos.bordero	—	text	FK → core.empresa.empresa_id ALT (3 col.)	sim	Qual das empresas dele descontou: real ou lider.	4	core.empresa, core.nota_fiscal, core.titulo	—
factoring_id desconto_titulos.bordero	—	integer	FK → core.cliente_e_factoring.id_nomus ALT (3 col.)	sim	Quem descontou. Aponta para core.cliente_e_factoring — a MESMA tabela dos clientes, porque a concessionaria que compra tambem antecipa no proprio portal (a CPFL faz os dois).	1	só aqui	—
numero desconto_titulos.bordero	—	text	ALT (3 col.)	não	O numero que a factoring da ao bordero. Nulo enquanto nao chega. NAO vem de API nenhuma: 17 endpoints do Nomus deram 404.	2	core.nota_fiscal	—
data_operacao desconto_titulos.bordero	—	date	—	sim	Quando o desconto foi feito.	1	só aqui	—
valor_bruto desconto_titulos.bordero	—	numeric	—	não	Soma de face dos pedacos deste bordero, antes de taxa e tarifa.	1	só aqui	—
valor_taxa desconto_titulos.bordero	—	numeric	—	não	O juro da antecipacao. Junto com a tarifa, e o CUSTO da operacao — o numero que este micro app existe para mostrar e que hoje nao existe em lugar nenhum.	1	só aqui	—
valor_tarifa desconto_titulos.bordero	—	numeric	—	não	Tarifas fixas da operacao, separadas da taxa de propria porque nao variam com o prazo.	1	só aqui	—
valor_liquido desconto_titulos.bordero	—	numeric	—	não	O que efetivamente caiu na conta. ATENCAO na antecipacao por portal de concessionaria: os juros ja vem abatidos na origem, e o credito chega com nome de terceiro — "Finergy" e a CPFL. Casar credito com titulo por valor exato NAO fecha nesses casos.	1	só aqui	—
data_credito desconto_titulos.bordero	—	date	—	não	Quando o dinheiro caiu na conta. E o que permite casar com o extrato do Inter.	1	só aqui	—
observacao desconto_titulos.bordero	—	text	—	não	Texto livre dele.	2	desconto_titulos.liquidacao	—
criado_em desconto_titulos.bordero	—	timestamptz	—	sim	Quando a linha foi criada.	6	core.cliente_e_factoring, core.empresa, core.pessoa, desconto_titulos.liquidacao, desconto_titulos.operacao	—
criado_por desconto_titulos.bordero	—	text	FK → core.pessoa.pessoa_id	não	Quem criou, resolvido pelo TOKEN e nunca pelo que a tela digita (D9 do sistema-de-login).	3	desconto_titulos.liquidacao, desconto_titulos.operacao	—
atualizado_em desconto_titulos.bordero	—	timestamptz	—	sim	Ultima alteracao.	4	app.carteira_humano, app.prazo_transito, core.cliente_e_factoring	—
atualizado_por desconto_titulos.bordero	—	text	FK → core.pessoa.pessoa_id	não	Quem alterou por ultimo.	3	app.carteira_humano, app.prazo_transito	—
leitura_id desconto_titulos.leitura	—	bigint	PK	sim	Chave propria. A leitura nao tem identificador externo — ela so existe porque o nosso leitor rodou, e e por isso que ela nunca vai para o core (D46).	3	bi.carteira_item, raw.resposta	—
executado_em desconto_titulos.leitura	—	timestamptz	ALT	sim	Instante da execucao. UNIQUE: duas leituras nao acontecem no mesmo instante, e se acontecerem uma delas e re-execucao acidental.	1	só aqui	—
qtd_titulos desconto_titulos.leitura	—	integer	—	não	Total de titulos lidos. A particao tem de fechar: qtd_vendas + qtd_descontos + qtd_outros = qtd_titulos (1.609 na medicao de 25/08/2026).	1	só aqui	—
qtd_vendas desconto_titulos.leitura	—	integer	—	não	Titulos de venda — SO classificacao 10.01 e 10.02 (D66). Eram 902.	1	só aqui	—
qtd_descontos desconto_titulos.leitura	—	integer	—	não	Lancamentos 51.05, que NAO sao conta a receber de cliente: sao o registro do desconto, e o nomePessoa deles e o DESCONTADOR (D65). Eram 652.	1	só aqui	—
qtd_outros desconto_titulos.leitura	—	integer	—	não	As outras 6 classificacoes: aporte de socios, reembolso, emprestimo, outras receitas, venda de ativos. Eram 55.	1	só aqui	—
ancoras desconto_titulos.leitura	—	jsonb	—	sim	Resultado das 5 ancoras desta execucao, como jsonb. As de LEITURA (1 e 2) provam que li tudo e reprovam a leitura; as de CONSISTENCIA (3, 4 e 5) comparam fontes e NAO reprovam — divergencia entre sistemas e o que a tela existe para mostrar (D64).	2	bi.leitura	—
aprovada desconto_titulos.leitura	—	boolean	—	sim	false quando uma ancora de LEITURA falhou. Leitura reprovada nao alimenta a tela: a tela fica com o ultimo dado bom.	2	bi.leitura	—
motivo desconto_titulos.leitura	—	text	—	não	Por que reprovou. Obrigatorio quando aprovada = false, por constraint.	1	só aqui	—
liquidacao_id desconto_titulos.liquidacao	—	bigint	PK	sim	Chave propria. E a unica que existe: acerto nao tem identificador externo.	1	só aqui	—
operacao_id desconto_titulos.liquidacao	—	bigint	FK → desconto_titulos.operacao.operacao_id	sim	Qual pedaco esta sendo acertado.	2	desconto_titulos.operacao	—
data_liquidacao desconto_titulos.liquidacao	—	date	—	sim	Quando o acerto aconteceu.	1	só aqui	—
valor desconto_titulos.liquidacao	—	numeric	—	sim	Quanto foi acertado. Pode ser parcial: varios acertos por pedaco sao normais.	2	bi.carteira_item	—
observacao desconto_titulos.liquidacao	—	text	—	não	Texto livre dele.	2	desconto_titulos.bordero	—
criado_em desconto_titulos.liquidacao	—	timestamptz	—	sim	Quando o acerto foi lancado.	6	core.cliente_e_factoring, core.empresa, core.pessoa, desconto_titulos.bordero, desconto_titulos.operacao	—
criado_por desconto_titulos.liquidacao	—	text	FK → core.pessoa.pessoa_id	não	Quem lancou, resolvido pelo token.	3	desconto_titulos.bordero, desconto_titulos.operacao	—
operacao_id desconto_titulos.operacao	—	bigint	PK	sim	Chave propria.	2	desconto_titulos.liquidacao	—
bordero_id desconto_titulos.operacao	—	bigint	FK → desconto_titulos.bordero.bordero_id ALT (2 col.)	sim	Em qual bordero este pedaco entrou. Junto com o titulo, e a chave natural: dentro de um bordero um titulo aparece uma vez so, e cada pedaco novo e um bordero novo.	2	desconto_titulos.bordero	—
titulo_id desconto_titulos.operacao	—	integer	FK → core.titulo.id_nomus ALT (2 col.)	sim	Qual titulo foi descontado. A empresa, a nota e o cliente vem por ele — nao se repetem aqui.	1	só aqui	—
valor_descontado desconto_titulos.operacao	—	numeric	—	sim	Quanto deste titulo foi descontado NESTE pedaco. A soma dos pedacos de um titulo tem de bater com valor_receber menos saldo_receber do Nomus — e essa ancora sai de graca, porque o proprio Nomus mantem o saldo disponivel a descontar.	1	só aqui	—
criado_em desconto_titulos.operacao	—	timestamptz	—	sim	Quando o pedaco foi lancado.	6	core.cliente_e_factoring, core.empresa, core.pessoa, desconto_titulos.bordero, desconto_titulos.liquidacao	—
criado_por desconto_titulos.operacao	—	text	FK → core.pessoa.pessoa_id	não	Quem lancou, resolvido pelo token.	3	desconto_titulos.bordero, desconto_titulos.liquidacao	—
resposta_id raw.resposta	—	bigint	PK	sim	Chave propria.	1	só aqui	—
leitura_id raw.resposta	—	bigint	FK → desconto_titulos.leitura.leitura_id	sim	Qual execucao produziu esta resposta.	3	bi.carteira_item, desconto_titulos.leitura	—
fonte raw.resposta	—	text	—	sim	nomus, inter ou salesforce. Constraint em vez de texto livre: fonte escrita errada vira dado que nenhuma consulta acha.	1	só aqui	—
endpoint raw.resposta	—	text	—	sim	O endpoint chamado: contasReceber, nfes, banking/v2/extrato/completo, o id do relatorio do Salesforce.	1	só aqui	—
pagina raw.resposta	—	integer	—	não	Numero da pagina. Guardado porque as tres fontes paginam e ler so a primeira e o defeito silencioso classico — no Inter, 30 dias deram 315 lancamentos em 7 paginas.	1	só aqui	—
corpo raw.resposta	—	jsonb	—	sim	O JSON inteiro que a fonte devolveu, sem recorte.	1	só aqui	—
lido_em raw.resposta	—	timestamptz	—	sim	Quando esta resposta chegou.	4	app.conferencia_a_faturar, core.nota_fiscal, core.titulo	—

view	respeita a RLS de baixo
vw.carteira_item	sim
vw.carteira_mudou	sim
vw.carteira_pedido	sim
vw.carteira_produto	sim
vw.eu	sim
vw.leitura_atual	sim
vw.status	sim
vw.tela	sim

Inventário do BD

Entidades 82 atributos ao todo

Atributos

Relacionamentos

Schemas

Views

de	pela coluna	para	na coluna	cardinalidade
app.carteira_humano	atualizado_por	core.pessoa	pessoa_id	N : 1
app.prazo_transito	atualizado_por_pessoa_id	core.pessoa	pessoa_id	N : 1
bi.carteira_item	leitura_id	bi.leitura	id	N : 1
core.nota_fiscal	empresa_id	core.empresa	empresa_id	N : 1
core.pessoa	auth_id	auth.users	id	1 : 1
core.pessoa_tem_papel	papel_id	core.papel	papel_id	N : 1
core.pessoa_tem_papel	pessoa_id	core.pessoa	pessoa_id	N : 1
core.registro_de_mudanca	quem	core.pessoa	pessoa_id	N : 1
core.tela_aceita_papel	papel_id	core.papel	papel_id	N : 1
core.tela_aceita_papel	tela_id	core.tela	tela_id	N : 1
core.titulo	cliente_e_factoring_id	core.cliente_e_factoring	id_nomus	N : 1
core.titulo	empresa_id	core.empresa	empresa_id	N : 1
core.titulo	nota_fiscal_id	core.nota_fiscal	id_nomus	N : 1
desconto_titulos.bordero	atualizado_por	core.pessoa	pessoa_id	N : 1
desconto_titulos.bordero	criado_por	core.pessoa	pessoa_id	N : 1
desconto_titulos.bordero	empresa_id	core.empresa	empresa_id	N : 1
desconto_titulos.bordero	factoring_id	core.cliente_e_factoring	id_nomus	N : 1
desconto_titulos.liquidacao	criado_por	core.pessoa	pessoa_id	N : 1
desconto_titulos.liquidacao	operacao_id	desconto_titulos.operacao	operacao_id	N : 1
desconto_titulos.operacao	bordero_id	desconto_titulos.bordero	bordero_id	N : 1
desconto_titulos.operacao	criado_por	core.pessoa	pessoa_id	N : 1
desconto_titulos.operacao	titulo_id	core.titulo	id_nomus	N : 1
raw.resposta	leitura_id	desconto_titulos.leitura	leitura_id	N : 1

schema	tabelas	atributos
_controle	1	5
app	4	24
bi	3	30
core	10	72
desconto_titulos	4	37
raw	1	7