Skip to main content

​
🧮 ERP Schema V2 Overview

ERP Schema V2 adalah schema ERP generik yang menyederhanakan lebih dari 250 tabel menjadi sekitar 60 tabel terstruktur, dengan fokus pada:
  • Universal Journal ala SAP S/4HANA
  • Master data minimalis (material, business partner)
  • Alur transaksi inti yang bersih (PR→PO→GR→AP→GL, SO→Invoice→AR→GL, dll.)
  • Multi-tenant, multi-company, multi-branch untuk skala nasional/enterprise.

​
1. Executive Summary

​
1.1 Latar Belakang

Schema lama:
  • 250 tabel untuk POS, SCM, Manufacturing, Promo Engine, Wallet, Finance, dll.
  • Banyak duplikasi:
    • Kode seperti merchant_code, branch_code, product_code tersebar di banyak tabel.
    • Banyak tabel log dan derived yang sebenarnya bisa dinormalisasi.
  • Sulit dipakai sebagai ERP core karena:
    • Tidak ada universal journal.
    • Master data tersebar dan saling overlap.
ERP Schema V2 menjawab masalah ini dengan:
  • Konsolidasi menjadi sekitar 60 tabel.
  • Pemisahan jelas antara:
    • Master data (material, customer, vendor, COA).
    • Dokumen bisnis (PO, SO, GR, invoice).
    • Posting keuangan (GL).
    • Logistik (stock, movement).
  • Fokus ke ERP tanpa kehilangan kemampuan POS/retail.

​
1.2 Tujuan & Manfaat

  • Sebagai core ERP generik yang bisa diadopsi berbagai bisnis.
  • Memudahkan integrasi:
    • Antar modul internal (inventory, finance, HR, CRM).
    • Dengan sistem eksternal (billing, data warehouse, BI).
  • Menurunkan kompleksitas:
    • Lebih sedikit tabel.
    • Struktur dan naming yang konsisten.
  • Memperkuat kualitas data:
    • Satu sumber kebenaran untuk master & journal.
    • Mengurangi duplikasi dan inkonsistensi.

​
2. Architecture Overview

​
2.1 Prinsip Desain Inti

  • Universal Journal sebagai pusat
    Semua transaksi keuangan berakhir di gl_entry + gl_line.
  • Master Data Minimalis
    • inv_mat sebagai material master tunggal.
    • so_customer & po_vendor sebagai business partner ringan.
    • Atribut turunan dipecah ke tabel kecil spesifik bila perlu.
  • Transaction Core yang Clean
    • Procurement → po_* + inv_* + fi_ap_* + gl_*.
    • Sales/POS → so_* + fi_ar_* + gl_*.
    • Inventory → selalu lewat inv_move.
  • Multi-tenant, Multi-company, Multi-branch
    • Tenant > Company > Branch sebagai hirarki standar.
  • Domain Prefix
    • Prefix tabel per domain (core_, fi_, gl_, inv_, po_, so_, hr_, crm_, cs_, au_, an_, ic_, rg_) untuk menjaga boundary dan memudahkan navigasi.

​
2.2 Domain Prefixes

PrefixDomainContoh tabel
core_Core, auth, RBAC, configcore_user, core_audit
fi_Finance AR/AP/Cashfi_ar_inv, fi_cash_tx
gl_General Ledger / Universal Journalgl_entry, gl_line
inv_Inventory & stockinv_mat, inv_move
po_Procurementpo_order, po_gr
so_Sales & POSso_order, so_pos
hr_Human Resourceshr_emp, hr_payroll
crm_Customer Relationship Managementcrm_contact, crm_lead
cs_Customer Service / Ticketingcs_ticket
au_Audit & Segregation of Dutiesau_sod
an_Analytics & KPIan_kpi, an_kpi_val
ic_Intercompany / Holdingic_entity, ic_tx
rg_Region, Currency, Policyrg_rate, rg_policy

​
2.3 Multi-tenant → Company → Branch

  • core_tenant
    Level SaaS / grup tertinggi.
  • core_company
    Entitas legal akuntansi (PT/CV). COA, GL, AR/AP terikat ke sini.
  • core_branch
    Unit operasional (toko, gudang, cabang). Stock dan POS terjadi di level ini.

​
2.4 Konvensi PK/FK & Penamaan

  • PK: id BIGINT UNSIGNED AUTO_INCREMENT.
  • FK umum:
    • tenant_id → core_tenant.id
    • company_id → core_company.id
    • branch_id → core_branch.id
    • mat_id → inv_mat.id
    • cust_id → so_customer.id
    • vendor_id → po_vendor.id
  • Kode unik lokal:
    • code unik per company (material, customer, vendor, COA) untuk memudahkan integrasi dan import dari sistem lain.

​
2.5 Alignment dengan SAP / S4HANA

ERP Schema V2 mengadopsi spirit SAP Universal Journal (ACDOCA) dan Material Master namun dengan eksekusi yang lebih ringan dan mudah dioperasikan di startup atau mid-size enterprise.
  • Universal Journal
    • SAP ACDOCA → V2: gl_entry + gl_line.
    • Semua posting AR/AP/expense/cash dihantarkan ke GL.
  • Material & Stock
    • SAP MARA/MBEW/MCHB → V2: inv_mat, inv_stock, inv_move.
  • Document Flow
    • SAP: PR→PO→GR→Invoice→Payment.
      V2: po_req→po_order→po_gr→fi_ap_inv→fi_ap_pay→gl_entry.

​
3. ERD Overview (Global)

​
4. Business Process Flows

  • Procurement: PR → PO → GR → AP → GL
  • Sales: SO → Invoice → AR → GL
  • POS Mini Flow
  • Inventory: Stock → Movement → Adjustment
  • Payroll Mini Flow
  • CRM & Ticket

​
Flow Ringkas

  1. Purchase Request (PR)
    • User cabang membuat kebutuhan di po_req + po_req_line.
  2. Purchase Order (PO)
    • Buyer meng-approve PR → generate po_order + po_order_line.
  3. Goods Receipt (GR)
    • Barang datang → create po_gr + po_gr_line.
    • GR men-trigger inv_move (movement type = IN_PURCHASE) dan update inv_stock.
  4. AP Invoice
    • Finance menerima invoice supplier → fi_ap_inv + fi_ap_inv_line.
  5. AP Payment
    • Pembayaran ke supplier → fi_ap_pay.
  6. GL Posting
    • AP invoice dan payment di-post ke gl_entry + gl_line (debit/credit COA terkait).

​
Diagram

​
5. Design Rationale

​
5.1 Kenapa Universal Journal?

  • Fakta:
    • Schema lama memisahkan jurnal per modul (AR, AP, POS, dsb).
    • Sulit membuat laporan konsolidasi & audit trail.
  • Pendekatan V2:
    • Semua posting keuangan selalu lewat gl_entry + gl_line.
  • Manfaat:
    • Laporan keuangan dan audit hanya perlu satu sumber data.
    • Implementasi AR/AP/asset/cash hanyalah “/view” domain di atas GL.

​
5.2 Kenapa Material Master Dinormalisasi?

  • Fakta:
    • Banyak duplikasi product vs inventory vs product_price.
  • Pendekatan V2:
    • Satu tabel inv_mat untuk material.
    • Harga, stock, movement dipisahkan ke tabel spesifik (inv_stock, inv_move, dsb.).
  • Manfaat:
    • Satu ID material di seluruh sistem.
    • Menyederhanakan integrasi dengan POS, e-commerce, dan sistem eksternal.

​
5.3 Kenapa POS Disederhanakan?

  • Fakta:
    • POS lama mencampur konsep GL dan inventory di banyak tabel.
  • Pendekatan V2:
    • POS cukup so_pos + so_pos_line.
    • Posting GL & movement inventory dilakukan oleh service terpisah (terhadap fi_cash_tx, inv_move, gl_entry).
  • Manfaat:
    • Engine POS tetap ringan & offline-friendly.
    • Akuntansi dan stock tetap terkendali dengan cara yang konsisten.

​
5.4 Kenapa Domain Prefix Penting?

  • Memudahkan:
    • Pengembang baru memahami batas domain.
    • Query & migrasi berdasarkan modul.
    • Pemetaan ke tim/domain (core, finance, inventory, dsb.).
  • Mengurangi:
    • Risiko konflik nama.
    • Risiko mencampur domain (mis. tabel finance dipakai langsung oleh modul inventory).

​
6. Glossary

IstilahDefinisi singkat
TenantPemilik instance ERP (grup/holding/penyedia layanan)
CompanyEntitas legal akuntansi (PT/CV)
BranchUnit operasional (toko, gudang, cabang)
MaterialItem/barang yang dikelola di inventory (inv_mat)
COA (Chart of Accounts)Daftar akun buku besar untuk GL (gl_coa)
Universal JournalModel di mana semua posting keuangan masuk ke satu struktur GL
PR (Purchase Request)Permintaan pembelian awal (po_req)
PO (Purchase Order)Pesanan pembelian ke vendor (po_order)
GR (Goods Receipt)Pencatatan barang masuk (po_gr)
AR (Accounts Receivable)Piutang usaha (fi_ar_*)
AP (Accounts Payable)Hutang usaha (fi_ap_*)
POS (Point of Sale)Transaksi penjualan kasir (so_pos)
MovementPergerakan stok yang mempengaruhi inv_stock (inv_move)
AdjustmentPenyesuaian stok akibat opname/selisih (inv_adj, inv_adj_line)
SoD (Segregation of Duties)Pemisahan tugas untuk mencegah fraud (au_sod)
KPIKey Performance Indicator (an_kpi, an_kpi_val)
IntercompanyTransaksi antar entitas dalam satu grup (ic_entity, ic_tx)
Region/PolicyPengaturan regional, mata uang, dan kebijakan (rg_*)

​
7. Navigasi ke Dokumentasi Modul

Gunakan file modul di folder 40-database/erp-v2/:
  • Satu file per modul (Core, Finance, GL, Inventory, Procurement, Sales, HR, CRM, CS, Audit, Analytics, Intercompany, Global) mencakup:
    • List tabel & deskripsi pendek.
    • Key fields & FK.
    • Hubungan antar tabel per modul.
    • Contoh flow minimal & snippet query SELECT untuk laporan.