MEKARI
Solusi SaaS untuk Tingkatkan Produktivitas Perusahaan
HOMEPanduan Integrasi ERP: Metode, Cara Kerja, dan Contoh Use Case GET FROM MEKARI
Bagaimana Cara Membuat API Endpoint di Mekari Officeless POST FROM MEKARI
Bagaimana Cara Konsumsi API dari External (Webhook, Public Endpoint)
๐งพ Mekari (Jurnal by Mekari)
Custom Field, Button & Database Key
SaaS Indonesia · Accounting · Akses & Batasan
➤ Aplikasi Mekari (Jurnal, Talenta, Klikpajak) adalah Accounting SaaS (bukan self-hosted). Artikel ini menjelaskan secara akurat: bisakah menambahkan control button, field baru, atau key tambahan di dalam tabel database? Simak detail batasan dan solusi middleware.
๐ 1️⃣ Menambahkan Field (Custom Field)
✅ BISA – tapi terbatasMekari menyediakan custom field resmi melalui antarmuka:
- ๐ Customer / Vendor / Produk / Invoice → opsi custom field via Setting → Custom Field.
- ๐ Tersedia di paket tertentu (Form customization).
- ⚠️ Tidak bisa: menambah kolom langsung ke database internal, mengubah struktur tabel sistem, atau membuat foreign key manual. Multi-tenant SaaS, semua dikontrol Mekari.
๐ฑ️ 2️⃣ Menambahkan Control Button (UI Button Baru)
❌ TIDAK bisa langsung di dalam sistemSebagai user: tidak bisa menambahkan tombol custom di UI internal, tidak bisa edit source code, atau inject frontend.
- ๐น API integration (resmi Mekari)
- ๐น Middleware seperti Zapier / Make / Power Automate
- ๐น Custom internal dashboard → tarik data dari API Mekari, lalu tambahkan tombol aksi di sistem eksternal Anda, kirim balik via API.
๐️ 3️⃣ Menambahkan Key di Table (Database Level)
❌ TIDAK BISA – SaaS tidak beri akses schemaZero akses SQL, zero modifikasi database. Alternatif wajib:
- ✅ Gunakan Custom Field sebagai logical key.
- ✅ Manfaatkan API ID / external database untuk relasi tambahan.
- ✅ Bangun sistem relasi sendiri di luar Mekari.
⚙️ Opsi Advanced (Jika Butuh Kontrol Lebih)
๐งฉ Rekomendasi arsitektur
- ✔️ Gunakan API resmi Mekari
- ✔️ Bangun middleware (Node.js / Python / Golang) sebagai jembatan
- ✔️ Simpan struktur custom di database Anda
- ✔️ Kontrol button via dashboard internal
๐ข Alternatif ERP self-hosted
Jika butuh full kontrol database & button:
- ๐ธ Odoo (Community)
- ๐ธ ERPNext
- ๐ธ Dolibarr
Sesuaikan dengan skala bisnis
๐ฏ Kesimpulan Singkat – Tabel Status
| Fitur / Kemampuan | Status | Catatan Penting |
|---|---|---|
| Tambah Custom Field | ✅ Ya (terbatas) | Hanya via fitur resmi (Setting › Custom Field), bukan SQL |
| Tambah Button UI | ❌ Tidak | Kecuali via sistem eksternal / middleware + API |
| Tambah Key / Kolom Database | ❌ Tidak | SaaS tidak memberi akses schema, tidak ada akses DB |
| Integrasi API / Webhook | ✅ Ya | Solusi paling fleksibel & resmi dari Mekari |
๐ก Intisari SaaS & Database Control
Mekari adalah platform akuntansi multi-tenant — user tidak memiliki akses ke struktur database. Namun fleksibilitas tetap bisa diraih dengan custom field + API + external middleware. Tidak bisa “edit core”, tapi bisa “extend by integration”.
✦ Konten ini disusun berdasarkan praktik umum SaaS (Software as a Service) dan dokumentasi publik Mekari. Untuk kebutuhan modifikasi database atau penambahan akses root, tidak dimungkinkan dalam arsitektur Jurnal by Mekari. ๐ฆ Blogger safe — semua styling inline & aman dari filter XSS. Gambar menggunakan src public domain help center.
Arsitektur Custom Field pada Platform SaaS:
Menjaga Stabilitas Skema Database Tanpa Mengubah Struktur Tabel Inti
Dalam arsitektur sistem pada platform Software as a Service (SaaS) seperti Mekari, khususnya pada sistem akuntansi berbasis cloud, perubahan struktur data—termasuk penambahan custom field—tidak dilakukan secara langsung pada tabel inti (basic table). Hal ini disebabkan oleh kebutuhan menjaga stabilitas sistem, skalabilitas infrastruktur, serta penerapan desain multi-tenant yang memungkinkan banyak pengguna berbagi arsitektur database yang sama.
Karena itu, ketika custom field perlu ditambahkan, sistem tidak mengubah skema fisik tabel utama, melainkan menerapkan pola struktur alternatif seperti penyimpanan berbasis metadata (misalnya model Entity-Attribute-Value), kolom bertipe JSON, atau tabel ekstensi terpisah. Pendekatan ini memungkinkan fleksibilitas tanpa mengganggu struktur dasar database.
Dengan demikian, penting untuk memahami bahwa struktur tabel baru dalam konteks SaaS bukan berarti penambahan kolom pada tabel inti, melainkan penambahan lapisan logis yang dirancang untuk mengakomodasi kebutuhan kustomisasi secara dinamis dan tetap menjaga integritas arsitektur sistem secara keseluruhan.
๐ Konteks: Mekari sebagai SaaS
Mekari adalah SaaS berbasis cloud. Artinya:
- Database dimiliki & dikontrol oleh vendor
- User tidak punya akses SQL
- Tidak bisa ubah schema fisik
❓ Jadi Struktur Tabel Baru Seperti Apa Setelah Tambah Custom Field?
Jawaban singkat:
TIDAK ADA perubahan struktur tabel utama (basic table).
Yang berubah adalah cara sistem menyimpan metadata tambahan.
๐ Bagaimana SaaS Biasanya Menyimpan Custom Field?
Ada 3 pola umum arsitektur:
1️⃣ Pattern A — EAV (Entity-Attribute-Value) Model
Ini yang paling umum dipakai SaaS.
Contoh:
customers --------- id name email phone created_at
Ketika Anda tambah custom field: "NPWP Customer"
Sistem TIDAK menambah kolom npwp ke tabel customers.
Sebaliknya dibuat tabel tambahan seperti:
custom_fields -------------- id entity_type field_name data_type custom_field_values ------------------- id entity_id custom_field_id value
Secara logika:
Customer ID 123 → Custom Field: NPWP → Value: 01.234.567.8-999.000
Kesimpulan pattern ini:
- ✔️ Tabel utama tetap
- ✔️ Custom disimpan sebagai metadata + value table
2️⃣ Pattern B — JSON Column
Beberapa SaaS modern menggunakan pendekatan JSON:
customers --------- id name email extra_data (JSON)
Contoh isi JSON:
{
"npwp": "01.234.567.8-999.000",
"segment": "Corporate",
"region": "Jakarta"
}
- ✔️ Tidak ubah schema
- ✔️ Lebih fleksibel
- ✔️ Tidak perlu alter table
3️⃣ Pattern C — Dynamic Shadow Table
Kadang dibuat struktur seperti:
customers customers_extended
Tabel extended hanya menyimpan tambahan.
Namun ini lebih jarang dibanding EAV.
๐ฏ Jadi Struktur Setelah Custom Field Ditambah?
Misalnya Anda menambah 3 field di Customer:
- NPWP
- Sales Region
- PIC Internal
Struktur fisik kemungkinan menjadi:
customers (tidak berubah) custom_fields custom_field_values
Bukan:
customers --------- id name email npwp sales_region pic_internal
๐ Kenapa SaaS Tidak Mengubah Tabel Basic?
- Ribuan tenant berbagi database
- Schema change berisiko tinggi
- Performance & migration cost besar
- Harus backward compatible
๐ Kesimpulan Teknis
Jika Anda menambah Custom Field di Mekari:
- ✅ Tidak ada alter table
- ✅ Tidak ada penambahan kolom fisik
- ✅ Tidak ada foreign key baru
- ✅ Hanya penambahan metadata
Yang berubah adalah:
Logical layer, bukan physical schema layer.
๐ก Jika Anda Butuh Relasi Tambahan?
Solusi profesional biasanya:
- Gunakan API ID sebagai reference
- Simpan relasi di external DB
- Gunakan webhook sync
- Bangun integration layer (middleware)
Comments
Post a Comment