CHAT_GPT & DEEP SEEK HELP:
MEKARI as Solusi SaaS untuk Tingkatkan Produktivitas Perusahaan

Mekari SaaS - Custom Field & Button Guide

๐Ÿงพ Mekari (Jurnal by Mekari)
Custom Field, Button & Database Key

SaaS Indonesia · Accounting · Akses & Batasan

Jurnal Mekari dashboard preview Custom field contoh di Mekari Talenta integration Mekari dashboard button

➤ 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 terbatas

Mekari 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 sistem

Sebagai user: tidak bisa menambahkan tombol custom di UI internal, tidak bisa edit source code, atau inject frontend.

✅ TAPI bisa via:
  • ๐Ÿ”น 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 schema

Zero 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
๐Ÿ“˜ Dokumentasi API Mekari

๐Ÿข 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:

  1. Gunakan API ID sebagai reference
  2. Simpan relasi di external DB
  3. Gunakan webhook sync
  4. Bangun integration layer (middleware)

Comments