Simulasi ERP Travel

Buka Alur Data ERP Travel →Penjelasan alur data penjualan tiket dari pesanan sampai laba.

Sistem lama vs sistem baru

Sistem lama = database erp yang berjalan sekarang (data Nov 2017 – Sep 2023). Sistem baru = struktur ERP Travel yang disimulasikan di halaman ini.

Aspek	Sistem lama	Sistem baru
Struktur data	28 tabel tanpa satu pun relasi (foreign key); ID berupa teks bebas, mis. customer `EMMY 2`	33 tabel dengan 46 relasi yang dijaga database; ID angka + kode unik (`CUS-0001`)
Pencatatan tiket	Satu baris menyimpan penumpang, harga jual, harga beli, no. invoice, dan no. order sekaligus	Dipisah: data penumpang, tagihan ke customer, dan pembelian ke supplier, lalu dihubungkan untuk menghitung laba
Beda supplier	Hanya lewat nomor order di tiap baris penumpang (terjadi di 1.106 reservasi)	Satu PO per supplier dibuat otomatis; setiap tiket tercatat dibeli dari supplier mana
Pembayaran	Hanya tanggal lunas yang dicatat; nominal, cicilan, dan rekening tidak ada (tabel penerimaan kosong)	Setiap pembayaran tercatat: tanggal, rekening, metode, jumlah, dan tagihan yang dibayar; bisa dicicil
Kelebihan bayar	Tidak ada tempat mencatatnya	Menjadi deposit customer dan bisa dipakai untuk tagihan berikutnya
Jatuh tempo	Kolom ada tetapi tidak pernah diisi (0 dari 12.485 piutang)	Dihitung otomatis dari term customer/supplier; ada laporan umur piutang dan hutang
Limit kredit	Tidak ada	Dicek otomatis sebelum tagihan aktif
Status dokumen	Kolom status tidak pernah diisi	Alur jelas per dokumen: draft → aktif → sebagian dibayar → lunas, atau void
Nomor tiket	Hampir tidak pernah dicatat (5 dari 24.625 tiket)	Wajib diisi sebelum tiket dinyatakan issued
Laba	Dihitung manual dari selisih kolom harga	Otomatis per tiket, per pesanan, dan per supplier
Angka uang	Tipe `DOUBLE`, bisa meleset pembulatan	Tipe `DECIMAL(15,2)`, tepat sampai sen
Jejak perubahan	Hanya nama user terakhir yang mengubah	Tercatat siapa membuat dan kapan; pembatalan memakai void dengan alasan

Keunggulan sistem baru

Jejak uang lengkapSetiap rupiah yang masuk dan keluar bisa ditelusuri ke tagihan, supplier, dan rekening bank.

Laba per tiket otomatisTanpa hitung manual; bisa dilihat per pesanan, per supplier, dan per admin.

Hutang dan piutang tepat waktuMuncul saat benar-benar terjadi (tiket issued, tagihan aktif) lengkap dengan jatuh tempo.

Risiko kredit terkendaliLimit kredit dicek otomatis; kelebihan bayar customer tersimpan sebagai deposit.

Data konsistenRelasi dijaga database dan saldo bisa direkonsiliasi, jadi tidak ada data yatim atau angka yang tidak cocok.

Siap dikembangkanPola yang sama dipakai untuk hotel, visa, paspor, bus, dan voucher; banyak penumpang dan supplier dalam satu pesanan.

Cara kerja sistem baru

Admin mencatat pesanan sekali. Sistem langsung menyiapkan pesanan pembelian ke tiap supplier dan draft tagihan ke customer.
Satu pesanan bisa berisi banyak penumpang dan beberapa supplier. Harga boleh berbeda untuk dewasa, anak, dan bayi.
Hutang ke supplier baru dicatat setelah tiket issued, yaitu saat nomor e-ticket keluar. Sebelum itu kursi hanya ditahan.
Tagihan ke customer baru aktif setelah dicek limit kreditnya. Customer yang melewati limit harus melunasi dulu.
Customer boleh mencicil. Kalau membayar lebih, kelebihannya disimpan sebagai deposit untuk transaksi berikutnya.
Setiap uang masuk dan keluar tercatat lengkap: tanggal, rekening, dan tagihan mana yang dibayar.
Laba dihitung otomatis per tiket: harga jual dikurangi harga beli, lalu dijumlahkan per pesanan dan per supplier.
Tagihan yang sudah aktif tidak diubah. Kalau ada kesalahan, tagihan dibatalkan (void) dan dibuat tagihan baru.

Cara memakai: Pilih studi kasus dan baca ceritanya Klik tombol di tiap langkah secara berurutan Lihat hasil laba dan saldo di langkah Laporan

Struktur tabel final yang dipakai simulasi

Kolom bertanda * adalah usulan tambahan terhadap dbdocs v4. L1–L5 = langkah di simulator.

Tabel	Kolom kunci	Ditulis di
`bookings`	no_booking, service_cat_id, customer_id, tgl_booking, tgl_layanan, tgl_selesai, status, created_by, updated_by*	L1 insert (pending) · L2 confirmed
`flight_bookings`	booking_id, airline_id, flight_number (GA-302), origin_airport_id, destination_airport_id, departure_time, arrival_time, kelas_penerbangan, pnr_code	L1
`booking_segments`	booking_id, flight_booking_id, nama_penumpang, salutation_id, tipe_pax, kelas, no_tiket, status_tiket	L1 pending · L2 issued
`purchase_orders`	no_po, booking_id, supplier_id, status, po_date, tgl_jatuh_tempo, subtotal, tax_amount, total_amount, paid_amount, remaining_amount	L1 draft · L2 confirmed · L5 paid
`purchase_order_items`	po_id, segment_ref_type, segment_ref_id, tipe, deskripsi, qty, unit_cost, subtotal	L1
`invoices`	no_invoice, booking_id, customer_id, status, tgl_invoice, tgl_jatuh_tempo, subtotal, tax_pct, tax_amount, diskon, total_amount, paid_amount, remaining_amount, bill_to_, void_reason	L1 draft · L3 active · L4 paid
`invoice_items`	invoice_id, segment_ref_type, segment_ref_id, tipe (tiket / biaya_lain / …), deskripsi, qty, harga_satuan, line_total, status	L1 · L3 (biaya layanan)
`invoice_item_costs`	invoice_item_id, purchase_order_item_id, cost_amount, allocation_pct	L1
`accounts_payable`	ap_number, po_id (UNIQUE*), supplier_id, original_amount, outstanding_amount, tgl_po, tgl_jatuh_tempo, status	L2 · L5
`accounts_receivable`	ar_number, invoice_id (UNIQUE*), customer_id, original_amount, outstanding_amount, tgl_invoice, tgl_jatuh_tempo, status	L3 · L4
`payments`	no_pembayaran, payment_type, customer_id / supplier_id, kas_bank_id, payment_date, payment_method, amount, unallocated_amount*, reference_no	L4 · L5
`payment_allocations`	payment_id, ar_id XOR ap_id, amount_allocated, tgl_alokasi*	L4 · L5
`customers` / `suppliers` / `kas_bank`	kredit_limit, term_bayar_hari, saldo_piutang, saldo_deposit* · term_bayar_hari, saldo_hutang · saldo_saat_ini	L2–L5 (trigger)

Simulator

Studi kasus