Por que SE1 e SE2 sao tabelas separadas?
A historia tecnica e de negocio por tras da separacao de Contas a Receber (SE1) e Contas a Pagar (SE2) no Protheus.
Toda vez que dev novo em Protheus pergunta "por que financeiro tem 2 tabelas iguais?", a resposta tradicional e "porque sempre foi assim". A resposta real e mais interessante.
Contexto historico
O Protheus nasceu nos anos 90, em DBF (xBase). Naquela epoca, regras importantes:
- 1 tabela = 1 arquivo .dbf + indices. Tabela com milhoes de registros virava arquivo de centenas de MB — lento pra mover backup, sincronizar, abrir
- Lock pessimista por tabela: muitos usuarios mexendo na mesma tabela = lock contention
- Sem JOIN nativo decente em DBF — separar dominios em tabelas distintas era pratico
- Indices limitados: cada arquivo tinha set proprio de indices
Decisao tecnica
Receber e Pagar tem regras DIFERENTES:
- SE1 (receber): cliente, vendedor, ICMS substituicao, comissao, fatura, NF saida
- SE2 (pagar): fornecedor, condicao de pagamento, retencao IRRF, IRRF, ISS, NF entrada
Compartilham conceitos (parcela, vencimento, baixa), mas campos especificos divergem. Tentar unificar exigiria 50% mais colunas com NULL pra metade dos registros — desperdiciava espaco e atrapalhava queries.
Consequencias hoje
Mesmo no SQL moderno, a separacao trouxe vantagens permanentes:
- Performance: queries de cobranca (SE1) nao concorrem com fechamento de fornecedores (SE2)
- Permissao: usuario do contas a pagar tipicamente nao acessa receber e vice-versa
- Indices especificos: cada tabela tem set otimizado pro padrao de query proprio
- Auditoria/contabilizacao: integracoes saem separadas naturalmente
O preco
Voce paga em consistencia de modelo: todo dev novo precisa aprender 2 schemas quase iguais. Funcoes como SaldoTit e SomaAbat tem que ser chamadas separadamente pra cada uma. Codigo duplica.
Foi um trade-off da epoca que ficou na pedra. Em ERPs modernos (SAP, Oracle), tudo e BSEG ou AP_INVOICES + tipo. Mas mexer no Protheus exigiria refator de milhares de pontos.
Curiosidade: outras tabelas em par
Mesma logica em:
- SC1 / SC7: Solicitacao de Compra vs Pedido de Compra
- SD1 / SD2 / SD3: NF entrada / saida / movimento interno (3 dominios afins)
- SA1 / SA2: Cliente / Fornecedor (e nao um "Parceiro" generico)