Documentation Index

Fetch the complete documentation index at: https://docs-mstore.faisalaffan.com/llms.txt

Use this file to discover all available pages before exploring further.

​

🧮 ERP Schema V2 Overview

---

​

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

​

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

• 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

---

​

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

---

​

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.