FINA Features

DETAIL FEATURES:

Download User Guide (Tutorial)
Multi-Organization
Kepemilikan data dan informasi spesifik organisasi tetap terjaga, sementara sharable information dan consolidated information dengan mudah diakses lintas organisasi.
Multi-Approval Hierarchy
Approval hierarchy dapat didefinisikan dan dilekatkan pada entitas-entitas bisnis dan transaksi misalnya organisasi atau dokumen-dokumen sehingga tercipta workflow yang fleksibel di lingkungan yang multi-organisasi.
Multi-Currency
Transaksi dan harga bisa dinyatakan dengan mata uang apapun. Nilai tukar dikelola secara historis
Single View of Partner
Desain ini memungkinkan agregasi yang menyeluruh dan konsisten tentang setiap pihak yang terlibat di Fina (customer, supplier, dll).
Run on Any Device
Fina diakses menggunakan web browser (HTML5, CSS3, ES5 compatible). Penerapan responsive web design pada user-interface mengoptimalkan akses dari semua perangkat.
API-Driven Architecture
API (Application Programming Interface) adalah central-hub ke seluruh proses dan data di Fina. Penerapan 100% API-driven architecture ini meningkatkan scalability sistem sekaligus memungkinkan integrasi dan interoperability dengan sistem-sistem lain.
Fine-Grained Access Control
Access Control mengatur hak akses user ke proses dan data di FINA secara detail (fine-grained). Penerapannya memperhatikan:
  • Hak akses user pada proses
  • Hak akses user pada data atau dokumen
  • Workstate data (status data dalam alir kerja)

FINA System

FINA adalah sistem keuangan untuk mencatat aktivitas-aktivitas keuangan dan aliran dana (sisi operation) dalam lingkungan KG Media.

Fungsi-fungsi Fina terbagi menjadi beberapa modul (sub-system), seperti: Bank Module, Cash Module, A/R sub-system, A/P sub-system, Accounting sub-system, dll.

Mencakup aktivitas-aktivitas di 2 alir besar operasional keuangan yaitu:

  1. Alir Penerimaan Dana (Receipt Workflow)
  2. Alir Pengeluaran Dana (Payment Workflow)

Agar dapat diintegrasikan dengan sistem-sistem yang digunakan oleh organisasi-organisasi dalam lingkungan KG Media, Fina menerapkan beberapa konsep:

Latar Belakang Pengembangan

Multi-Systems di KG (Media)
Sudah sejak lama KG (kelompok Media khususnya) berusaha mewujudkan sistem bisnis yang terintegrasi.
  • Penerapan Microsoft Connected Services Framework (2005), dengan pendekatan modular architecture. Berhenti di tataran konsep.
  • Penerapan SAP Media (2008), dengan pendekatan monolitik, sudah terimplementasi namun belum menggantikan seluruh fungsi sistem yang berjalan.
  • Inisiatif bersama PricewaterhouseCoopers (2016)
Usaha-usaha tersebut belum mencapai hasil yang diharapkan. Untuk memenuhi kebutuhannya, masing-masing unit tetap melakukan pengembangan-pengembangan, yang hasil akhirnya tidak terintegrasi satu sama lain.
  • Sangat sulit ditemui sistem yang bisa menjawab kebutuhan semua unit
  • Di beberapa bisnis proses, sistem-sistem hasil pengembangan internal sudah lebih unggul
SPSK, FastKom, AMS, GMMS, adalah contoh "multi-system" (polylitic) di KGMedia.
Single Financial Controlling System
Di tingkat unit usaha (legal entity), pengawasan keuangan dikelola oleh departemen keuangan masing-masing. Di tingkat kelompok usaha (KG, khususnya KGMedia) ada lembaga-lembaga pengawas (keuangan). Salah satu peran lembaga yang sering di sebut "Corporate" tersebut adalah mengembangkan dan mengimplementasikan sistem keuangan. Apapun sistem transaksi yang dikembangkan oleh unit usaha akan mem-posting data masuk ke sistem keuangan yang dikembangkan oleh "Corporate" tersebut.
Sering timbul masalah pertukaran data antar sistem karena pengembangan sistem-sistem tersebut tidak direncanakan dan dikembangkan dalam satu payung. Juga karena perbedaan prioritas pekerjaan pengembangan sistem unit dengan corporate.
Masalah Kontrol Saldo Customer
Salah satu masalah pertukaran data yang sudah lama terjadi adalah pertukaran informasi "Status Pembayaran" dari sistem Finance Corporate ke sistem-sistem penjualan (Gate✝, SPIK✝, SPSK, FastKom, AMS).
Masalah makin memburuk sejak kasir menggunakan SAP pada bulan Mei 2018. Di FastKom, informasi status pembayaran terlambat hingga 5 bulan (status Desember 2018). Beberapa kali rapat melibatkan Keuangan Corporate (Kasir, Penagihan, FSD), TI Kompas, dan CITIS, namun belum mencapai solusi seperti yang diharapkan.
Masalah tersebut juga sudah meningkat menjadi masalah kontrol saldo agen di SKG (SPSK) sehingga mendorong Bp.Titus (GM Marketing Produk Kompas) mengundang pihak-pihak terkait pada tanggal 21 Juli 2020 untuk mencari jalan keluarnya.
FINA = Keputusan Bersama
Rapat tanggal 21 Agustus 2020 memutuskan Usulan ke-2, dari 2 usulan solusi yang diajukan, untuk segera dikembangkan menjadi solusi masalah kemacetan informasi pembayaran customer. Rapat dihadiri oleh perwakilan-perwakilan dari Marketing Product Kompas, Accounting Kompas, SKG, FSD, CITIS, dan TI Kompas (GoMed).
Sistem yang baru akan digunakan oleh Kasir, para admin Bank dan diharapkan dapat dimanfaatkan oleh SPSK, FastKom, AMS, dan sistem-sistem lainnya. Diputuskan juga SKG (SPSK) akan menjadi yang pertama memanfaatkan versi pertama sistem yang baru (v1.0).

History Pengembangan

Fina v1.0
Rujukan spesifikasi Fina v1.0 adalah Usulan ke-2 yang disepakati dalam rapat tanggal 21 Agustus 2020. Karena anggota tim masih terikat ke proyek lain, pengembangan baru dimulai tanggal 10 Desember 2020 (project kick-off), selesai tanggal 18 Februari 2021 (total 43 hari kerja, terlambat 6 hari dari rencana semula 37 hari kerja).
Fina v1.0 berfokus pada penerimaan pembayaran agen SPSK baik melalui bank maupun langsung ke kasir. Sasaran utamanya adalah mempercepat arus informasi pembayaran.
  • Penerimaan Kas: multiple-allocation, multiple payment-methods
  • Pengelolaan Rekening Bank: import (manual/ import MT940)
  • Alokasi penerimaan Bank: multiple-allocation
  • Receipt List (=A/R Receipt wanna be)
  • Integrasi dengan SPSK melalui download - upload file DBF
Rencana implementasi di 2 Sirda Jakarta (Gajahmada & Fatmawati) tanggal 12 April 2021, sosialisasi sudah dilakukan tanggal 19 Maret 2021.
Fina v1.1
Pengembangan Fina v1.1 dimulai tanggal 5 April 2021 berdasarkan masukan-masukan saat sosialisasi. Penambahan fitur (minor) pada versi ini:
  • Refund1 dan koreksi (void)
  • Import Bank Statement via Paste Area
  • Pengiriman informasi pembayaran ke SPSK melalui jalur posting langsung, fitur download-upload file DBF dimatikan
  • Sinkronisasi daftar agen SPSK
  • Bukti Kas Penerimaan (Receipt Voucher)
  • COA, COA Addressing (hanya untuk proses bukti kas)
Rencana implementasi di 2 Sirda Jakarta (Gajahmada & Fatmawati) tanggal 12 April 2021 tidak terlaksana (tanpa kabar, tidak ada data masuk ke server production yang sudah dipersiapkan).
1 Transaksi Refund belum bisa dipenuhi, menunggu keseluruhan A/R sub-system selesai dikembangkan.
Fina v2.0
Tanggal 30 Maret 2021, tim menyusun dan menyepakati Roadmap Pengembangan Business System KG Media untuk menjawab kebutuhan fungsi sistem-sistem bisnis di KG Media (selain SPSK). Roadmap tersebut sudah masuk dalam agenda proyek pengembangan KG Media, sesuai keputusan Rapat Alignment (KG Media: IT, Finance, SMO) tanggal 25 Juni 2021.
Fina v2.0 mulai dikembangkan tanggal tanggal 1 Juni 2021, mencakup keseluruhan arus dana masuk:
  • Cash Balance (top-up, withdrawal, transfer, bank clearing)
  • Deposit (Customer/ Employee/ Organization/ Supplier)
  • Ovarhaul layar kasir untuk mengakomodir deposit dan informasi-informasi balance
  • A/R Invoicer (Generic)
  • A/R (Invoice, Receipt, Memo, Balance, Mutation, Allocation)
  • Taxation (PPN K, PPH WABA, Withholding)
  • Collection
  • Pre-Payment (BS)
  • COA (GL Accounts, Addressing)
Fina v3.0
Setelah mengalami beberapa kegiatan sela (Tribun, Reorganisasi KGX, Iklan), kegiatan pengembangan dilanjutkan untuk mewujudkan v3.0 yang mencakup keseluruhan proses keuangan dan akunting (operastional):
  • A/P Invoicer (Generic)
  • A/P (Invoice , Payment, Memo, Balance,...)
  • Payment Requisition (PD, Pesanan Dana)
  • Update (revisit) Pre-Payment (BS)
  • Bank Transfer List
Disepakati tanggal 18 Oktober 2021, Fina v3.0 mencakup sampai ke General Ledger, diharapkan KG Media sudah dapat melepaskan ketergantungan pada sistem SAP sepenuhnya pada awal 2023. Cakupan fungsi ditambah:
  • General Ledger (G/L)
  • Accounting Period Management

History Implementasi

KGX - 18 Agustus 2021
Fina v2.0 mulai digunakan oleh kasir dan FO KGX tanggal 18 Agustus 2021. Hanya sebagian fungsi-fungsi yang diimplementasikan:
  • Penerimaan Kas: multiple-allocation, multiple payment-methods
  • Pengelolaan Rekening Bank: import (Manual/ Paste Area/ MT940)
  • Alokasi penerimaan Bank: multiple-allocation
  • Pengelolaan Receipt Giro/ Cheque: registration, disbursement, clearing
  • Pengelolaan saldo kasir: Top-Up, Withdrawal, Transfer
  • Receipt List (A/R Receipt Register wanna be)
  • Report-report operasional, combined-report SPSK-FINA (outstanding payment, etc)
  • FINA - SPSK integration (API-sync, two-ways): Payment Post, Payment Verify, Payment ReSend, Customer Sync, Combined Reports.
  • Oct 11, 2021 update: FINA - SAP integration (.tsv download-upload, one-way)
Kompas (Iklan) - 4 Mei 2023
Fina v3.0 digunakan oleh iklan mulai 4 Mei 2023. Hanya sebagian fungsi-fungsi yang diimplementasikan:
  • Penerimaan Kas: multiple-allocation, multiple payment-methods
  • Pengelolaan Rekening Bank: import (Manual/ Paste Area/ MT940)
  • Alokasi penerimaan Bank: multiple-allocation
  • Pengelolaan Receipt Giro/ Cheque: registration, disbursement, clearing
  • Pengelolaan saldo kasir: Top-Up, Withdrawal, Transfer
  • Receipt List (A/R Receipt Register wanna be)
  • Report-report operasional, combined-report FastKom-FINA (outstanding payment, etc)
  • Pengelolaan deposit (titipan)
Kompas (Iklan) - 31 Mei 2023
Setelah dievaluasi, Fina sejak 31 Mei 2023 mulai menerima aliran Invoice dari FastKom.
  • Integrasi Invoice A/R FastKom dan FINA
  • Data mengalir ke A/R sampai ke G/L, bersifat non operasional sampai Kompas benar-benar meninggalkan SAP.

FINA Receipt Workflow

Alir kerja penerimaan dana/ pembayaran masuk (Receipt Workflow) dimulai saat invoice penjualan diterbitkan dan berakhir ketika seluruh pembayaran atas invoice tersebut sudah diterima. Section ini menjelaskan alir kerja penerimaan dana dan modul-modul (sub-systems) Fina yang terlibat.

Sales Invoicing

Invoice Penjualan (Sales Invoice) diterbitkan oleh unit penjual (Sales Organization) menggunakan sales system masing-masing. Dalam kasus sales system yang digunakan oleh unit penjual tidak dapat menerbitkan invoice, maka invoice penjualan dapat dibuat menggunakan modul Fina A/R Invoicer.

External Sales Invoicer (existing)
Dari sudut pandang Fina, sales system yang digunakan oleh unit penjual Sales Org untuk menerbitkan Sales Invoice adalah sistem eksternal. Fina menggunakan istilah "Source Application" atau Application untuk menyebut sistem eksternal (sales system) tersebut.
Beberapa informasi/ dokumen penting yang 'mungkin' dipertukarkan dengan Fina antara lain:
  • Order Penjualan (Sales Order, SO)
  • Order Pembelian dari Customer (Customer's Purchase Order, PO Customer)
  • Invoice Penjualan (Sales Invoice)
  • Dokumen Pengiriman (Delivery Order/ Shipping Notes) atau setara: Bukti Tayang, dll.
  • Data-data rujukan seperti: Produk, Customer, dll.
Dalam alir penerimaan pembayaran, Invoice penjualan yang diterima dari sistem eksternal akan dilanjutkan prosesnya di Fina sampai seluruh pembayaran diterima. Informasi dari pembayaran yang diterima oleh Fina akan dikembalikan (post-back) ke sistem asalnya.
Pada gambar, sistem eksternal ditunjukkan dengan warna abu-abu sedangkan modul-modul Fina ditunjukkan dengan warna biru tua.
Fina A/R Invoicer = "Generic" Sales Invoicer (Jan 2022)
Modul ini digunakan untuk membuat Invoice penjualan sekaligus mencatatkannya ke dalam A/R. Bisa digunakan sebagai Sales Invoice dalam kasus:
  • Unit jual (Sales Organization) tidak menggunakan/ memiliki sales system
  • Unit jual (Sales Organization) menggunakan/ memiliki sales system namun tidak tersedia fasilitas untuk menerbitkan invoice penjualan.
Product untuk dicantumkan dalam invoice diambil dari daftar produk di Fina. Informasi produk yang lebih detail dapat diketikkan sebagai note (catatan). Product di Fina dikelola oleh unit keuangan karena berperan penting dalam penentuan akun (COA Addressing).
Sejauh memungkinkan, unit-unit tetap didorong untuk menerbitkan invoice dari sales system masing-masing dengan pertimbangan:
  • Informasi produk dan paket yang dijual bisa lebih presisi, lebih mudah dipahami oleh pembeli. Pengelompokan produk sesuai untuk kepentingan analisa sales.
  • Informasi penjualan lebih presisi, dapat menyediakan report analisa penjualan
  • Fina adalah sistem keuangan, bukan sistem penjualan, tidak dirancang untuk menyediakan seluruh fasilitas dan kebutuhan informasi penjualan yang diperlukan oleh unit jual.

Receipt Processing

Receipt processing adalah serangkaian proses untuk menangani dan mencatat aliran dana masuk sejak pembayaran tagihan (invoice) diterima oleh kasir atau masuk ke rekening bank sampai tercatat di G/L. Proses yang panjang ini melibatkan beberapa sub-sistem Fina dan juga sistem eksternal terkait.

Fina Bank Import (Feb 2021)
Pembayaran yang diterima melalui transfer bank perlu dialokasikan ke tagihan/ invoice nya. Modul Fina Bank Import berperan di awal proses Penerimaan Bank (Bank Receipt) untuk memindahkan baris-baris laporan RC Bank (Bank Statement/ Rekening-Courant) ke dalam sistem, sebelum proses alokasi dapat dilakukan.
Disediakan 3 cara untuk pemindahan RC Bank:
  1. Manual dengan mengetikkan baris-baris RC bank. Digunakan jika bank tidak menyediakan data digital untuk diimport.
  2. Paste Area untuk copy-paste dari Excel masuk ke dalam sistem. Digunakan jika bank menyediakan data digital non-standar dalam bentuk tabel atau setara tabel yang dapat diolah dengan Excel.
  3. Import file MT940. Digunakan jika bank menyediakan RC dalam format Swift MT940 yang bisa di download. Format ini adalah de facto standar yang digunakan oleh banyak bank.
Data RC bank yang sudah dimasukkan ke sistem kemudian di-posting ke masuk ke modul Fina Bank Statement. Pengkodean eksternal (Swift standar) diterjemahkan ke pengkodean internal.
Fina Bank Statement (Feb 2021)
Fungsi modul Fina Bank Statement untuk menyimpan dan mengalokasikan baris-baris RC Bank ke transaksi-transaksi internal. Contohnya: baris RC bank "Transfer In" dialokasi ke "Receipt Customer" SPSK agen A sehingga piutang agen A berkurang.
Fitur-fitur Fina Bank Statement antara lain:
  • Informasi saldo bank secara kronologis
  • Multiple Bank Allocations sehingga satu baris RC bisa dialokasikan ke beberapa transaksi sekaligus (Receipt, Payment, Deposit, Clearing, Bank Expense, Bank Interest, etc)
  • Multi Company
  • Multi Currency Transaction (Fixed and Floating rate conversion)
  • Kliring pencairan saldo kasir ke bank (Withdrawal)
  • Kliring pencairan Giro/ Check
Hasil alokasi penerimaan bank (Bank Receipt) kemudian di-posting masuk ke Fina Receipt List untuk bergabung dengan hasil alokasi penerimaan tunai (Cash Receipt).
Fina Cash (Receipt) (Feb 2021)
Modul yang dioperasikan oleh Cashier ini digunakan untuk melayani transaksi penerimaan dana tunai/ setara tunai (cash receipt).
Fitur-fitur Fina Cash antara lain:
  • Multiple Cash Payment Methods (Cash, BG, Cheque, Credit Card, etc) for Multiple Cash Allocations (Receipt, Payment, Deposit)
  • Multi Company (support inter company Balance Funding, Balance Transfer)
  • Multi Currency Transaction (Fixed and Floating rate conversion)
  • Giro and Cheque Processing (Receiving and registration, Handed-over, inter Cash Counter transfer)
  • Cash Balance management (Top-Up, Withdrawal, Transfer)
  • Deposit Management: (Deposit-In, Deposit-Out, Deposit Balance Tracking)
  • Cash Counter management (Check-In, Check-Out, Rest, forced Kick-Out)
Hasil alokasi penerimaan kas (Cash Receipt) kemudian di-posting masuk ke Fina Receipt List untuk bergabung dengan hasil alokasi penerimaan bank (Bank Receipt).
Fina Giro/ Cheque (Receipt)(Aug 2021)
Modul ini digunakan untuk melacak keberadaan, status, dan proses yang perlu dilakukan pada lembar-lembar giro/ cheque sejak diterima oleh Cashier di Cash Counter tertentu sampai diserahkan sebagai pembayaran (payment) atau dicairkan ke bank (receipt).
Ada 2 jenis Giro/ Cheque yang dikelola oleh modul ini:
  1. Receipt Giro/ Cheque yaitu giro atau cheque yang diterima sebagai pembayaran masuk. Keberadaan dan statusnya dilacak sejak diterima (outstanding), dalam proses pencairan (disbursing), sampai selesai dicairkan ke rekening bank (disbursed) atau ditolak (rejected).
  2. Payment Giro/ Cheque yaitu giro atau cheque yang akan diserahkan sebagai pembayaran keluar. Keberadaan dan statusnya dilacak sejak diterima (outstanding) sampai diserahkan sebagai pembayaran keluar (handed-over)
Walaupun penerimaan pembayaran giro atau cheque baru diakui setelah cair di rekening bank (3-5 hari), informasi giro atau cheque yang diterima namun belum cair perlu diinformasikan ke unit sales agar pelanggan tidak dikejar untuk membayar.
Fina Receipt List (Feb 2021)
Modul Fina Receipt List adalah muara dari seluruh penerimaan pembayaran yang sudah selesai dialokasi di Fina Bank dan Fina Cash. Tugas modul ini antara lain:
  1. Mengembalikan (post-back) informasi penerimaan pembayaran (Receipt) ke aplikasi pengumpannya (=aplikasi asal, = aplikasi sumber) misalnya ke SPSK, FastKom, AMS, dll. Tujuannya agar aplikasi-aplikasi tersebut mendapat informasi bahwa invoice atau tagihannya sudah terbayar (sebagian/ penuh).
  2. Membuat (generate) Receipt Voucher dan mem-postingnya ke Fina Voucher. Fina Receipt List membaca decision table pengalamatan nomor akun (Account Addressing) untuk memperoleh nomor akun yang tepat untuk dicantumkan dalam Receipt Voucher.
  3. mem-posting transaksi penerimaan pembayaran (Receipt) ke modul (sub system) Fina A/R agar penyelesaian tagihan atau invoice dapat dilacak.
Kelanjutan proses penerimaan pembayaran (Receipt) dapat dengan mudah dipantau menggunakan modul Fina Receipt List ini. Post back ke aplikasi pengumpan bahkan dapat diulang karena interoperability antar aplikasi memang berpotensi terjadi kegagalan (failure).
Fina Voucher (Receipt) (Apr 2021)
Voucher (Bukti Kas/ Bukti Bank) adalah bukti (proof/ evidence) terjadinya transaksi di bank atau di kasir yang menjadi dasar untuk jurnal akuntansi.
Ada 4 jenis voucher di Fina yaitu:
  1. Bank Receipt Voucher (Bukti Bank Masuk)
  2. Cash Receipt Voucher (Bukti Kas Masuk)
  3. Bank Payment Voucher (Bukti Bank Keluar)
  4. Cash Payment Voucher (Bukti Kas Keluar)
Receipt Voucher bisa dibuat dengan 2 cara:
  1. Manual menggunakan layar input voucher di modul Fina Voucher
  2. Dihasilkan dari proses voucher-generation di Fina Receipt List. Beberapa transaksi receipt bisa dikelompokkan menjadi satu Receipt Voucher untuk mengurangi jumlah voucher yang dihasilkan dan jumlah posting-an ke Fina G/L
Setelah dibuat Receipt Voucher di-posting ke Fina G/L. Nomor akun tujuan diperoleh dari COA Addressing.
Voucher dan proses voucher-generation di Receipt List perlu ditinjau ulang karena belum diuji terhadap perkembangan spesifikasi Fina.
Fina A/R Receipt (Jan 2022)
Sebagai sebuah tabel, Fina A/R Receipt berisi daftar transaksi penerimaan pembayaran (Receipt) yang sudah diterima oleh bagian A/R, biasa disebut "Payment Register". Isi tabel tersebut menjadi dokumen rujukan untuk tracking saldo (balance) piutang di Fina A/R Balance.
Sementara Fina Receipt List menggunakan kode-kode transaksi yang berlaku di Fina Cash dan Fina Bank, Fina A/R Receipt menggunakan kode-kode transaksi yang berlaku khusus di modul A/R.
Fina Withholding Tax In (Dec 2021)
Fungsi Fina Withholding Tax In untuk mencatat penerimaan bukti setor pajak (PPh). Walaupun bukan alat bayar, bukti setor dicantumkan dalam penjelasan section ini karena berguna sebagai pengurang saldo piutang A/R.
Informasi Bukti Setor Pajak diinput oleh kasir yang sekaligus merujukkannya ke satu atau beberapa nomor invoice. Saat di-posting, bukti setor pajak tersebut akan masuk ke Fina A/R Memo menjadi Credit Memo yang mengurangi tagihan atas invoice-invoice yang dirujuk.

Forward Workflow

No. Proses Operator Modul
A.Saat Invoice
A1.

Membuat Invoice Penjualan

Pada saat penjualan terjadi atau pada waktu yang disepakati, unit penjualan menerbitkan invoice ditujukan kepada pembeli (tertagih)

 Unit Penjualan External Invoicer
Fina A/R Invoicer
A2.

Posting Invoice Penjualan

Setelah diterbitkan, invoice penjualan di-posting masuk ke A/R. Invoice dapat diterima jika dilengkapi informasi Application dan Sales Org. penerbit invoice tersebut.

Proses mapping produk dan registrasi Party dalam invoice perlu dilakukan jika invoice yang berasal dari External Invoicer. Party yang dimaksud misalnya Pelanggan, Agen, Pengiklan, Biro Iklan, dll.

 Unit Penjualan External Invoicer
Fina A/R Invoicer
A3.

Posting ke G/L

Item-item Invoice dan Memo di A/R di-posting masuk ke Fina G/L

  • Item-item yang di-posting: Invoice, Credit Invoice, Debit Memo, Credit Memo
  • Nomor akun tujuan diperoleh dari Fina COA Addressing.

 Petugas A/R Fina A/R Balance
Fina COA Addressing
Fina G/L
No. Proses Operator Modul
B.Saat Pembayaran Diterima
B1.

Penerimaan dan alokasi Pembayaran

Pembeli dapat membayar tagihannya secara tunai melalui kasir (multi alat bayar) atau transfer melalui bank. Jika pembayaran diterima oleh kasir maka alokasi pembayaran ke invoice atau pembayar dilakukan langsung di depan kasir. Jika pembayaran dilakukan melalui transfer, maka alokasi dilakukan setelah buku bank (Bank Statement) diimport masuk ke dalam sistem.

 Kasir, FO, Bank Admin Fina Cash
Fina Bank Import
Fina Bank Statement
B2.

Pemrosesan Receipt

Pembayaran yang telah diterima dan dialokasikan ke invoice atau pembelinya akan masuk ke tabel Receipt List. Dari Receipt List informasi pembayaran kemudian di-posting ke beberapa tujuan:

  • Application sumbernya (post back)
  • Receipt Voucher (generate)
  • A/R, masuk ke tabel A/R Receipt

 Kasir, Bank Fina Cash
Fina Bank Import
Fina Bank Statement
B3.

Post Back ke Aplikasi Asal

Proses mengembalikan informasi pembayaran yang diterima ke aplikasi sumber berbeda-beda untuk setiap aplikasi. Penjelasan yang lebih lengkap dapat dilihat di section Fina Integration.

 (system, custom per aplikasi) Fina Receipt List
B4.

Receipt Voucher Generation

Sistem akan meng-generate Cash/ Bank Receipt Voucher tergantung jalur penerimaannya. Dalam proses ini sistem akan membaca decision table yang menyimpan logika pengalamatan nomor akun (account addressing).

 (system) Fina Receipt List
Fina COA Addressing
Fina Voucher
B5.

Posting ke A/R

Posting penerimaan pembayaran dari Receipt List akan masuk ke tabel A/R Receipt.

 (system) Fina Receipt List
Fina A/R Receipt
Fina A/R Balance
B6.

Posting ke G/L

Receipt Voucher di-posting dari Fina Receipt List masuk ke Fina G/L

  • Yang diposting ke G/L adalah header Receipt Voucher bukan detailnya
  • Saat posting tersedia pilihan di-posting

 Petugas A/R Fina A/R Balance
Fina COA Addressing
Fina G/L

Reversed Workflow

Status/ Kondisi Proses Operator Modul
Invoice belum di-posting ingin diralat atau dibatalkan Edit Invoice/ Void Invoice Unit Penjualan External Invoicer
Fina A/R Invoicer
Invoice sudah di-posting ingin diralat atau dibatalkan
  1. Buat Credit Invoice (CI) total atau sebagian
  2. Buat Invoice (I) baru
 Unit Penjualan External Invoicer
Fina A/R Invoicer
Cash Receipt belum di-posting ingin diralat atau dibatalkan Ralat Receipt/ Void Receipt Kasir Fina Cash
Cash Receipt sudah di-posting ingin diralat atau dibatalkan

Di kondisi ini, Cash Receipt sudah tidak bisa diralat atau dibatalkan lagi. Langkah-langkah ralat/ pembatalan:

  1. Kasir nenbuat transaksi "Reversed Receipt" senilai pembatalannya menggunakan modul Fina Cash
  2. Kasir mem-posting transaksi "Reversed Receipt". Status transaksi akan berubah menjadi Need Approval
  3. Atasan Kasir mem-posting ulang transaksi "Reversed Receipt" sehingga statusnya berubah menjadi Receipt Posted, transaksi "Reversed Receipt" akan mengalir masuk ke Fina Receipt List
  4. Dari Fina Receipt List, transaksi "Reversed Receipt" di-posting ke Fina A/R, Fina Voucher seperti langkah B2, B4, B5, B5. Post Back ke sistem pengumpan B3 tergantung skenario masing-masing sistem.
 Kasir,
Atasan Kasir,
Petugas A/R		 Fina Cash
Fina Receipt List
Fina A/R Receipt
Fina [source-app] Console

Skenario ini pernah dibahas via WA dan diskusi 22 Feb 2022, baru diputuskan dalam rapat 1 Maret 2002. Sistem sedang dalam penyesuaian (di-update).

Skenario manual yang sebelumnya pernah digunakan tanggal 2 Feb 2022 masih dipertahankan sampai pengembangan update selesai:

  1. (kasir) Minta persetujuan atasan untuk membatalkan
  2. (atasan) mengirimkan pesan tertulis kepada IT Media dan Petugas A/R untuk membatalkan (tergantung kondisi)
  3. (IT) jalankan dbo.CashReceiptVoidUnconditionally untuk void receipt dan membuat reversed payment sampai ke Receipt List
  4. (IT) jika informasi pembayaran sudah terkirim ke aplikasi sumber maka perlu dilakukan pembatalan di aplikasi sumber (berbeda, tergantung aturan masing-masing aplikasi)
  5. (Petugas AR) jika informasi pembayaran sudah terkirim ke A/R maka perlu dibuat transaksi reversed receipt, kemudian di-posting ke A/R sehingga mengurangi jumlah pembayaran invoice.
Bank Import belum di-posting ingin diralat/ dibatalkan Ralat data Bank Admin Fina Bank Import
Bank Statement belum di-posting ingin diralat atau dibatalkan Pada prinsipnya, ralat adalah membatalkan yang lama dan membuat yang baru.
  1. Dari Fina Bank Statement, pastikan tidak ada alokasi pada baris Bank Statement yang akan diralat atau dibatalkan. Hapus (lepaskan) alokasi jika ada.
  2. Buat transaksi pembalik dari Fina Bank Import supaya saldo rekening bank sesuai
  3. Posting transaksi pembalik ke Fina Bank Statement
  4. Dari Fina Bank Statement, update Deskripsi dengan alasan pembatalan.
  5. Dari Fina Bank Statement, transaksi lama dan transaksi pembalik di close supaya tidak dialokasi
  6. Dalam kasus ralat, buat transaksi baru dengan data yang benar dari Fina Bank Import, kemudian posting ke Fina Bank Statement seperti biasa.
 Bank Admin Fina Bank Import
Fina Bank Statement
Bank Allocation sudah di-posting ingin diralat atau dibatalkan Pada prinsipnya, ralat adalah membatalkan yang lama dan membuat yang baru.
  1. Dari Fina Bank Import, buat transaksi pembalik senilai pembatalannya.
  2. Dari Fina Bank Import, buat transaksi dengan nilai yang benar (khusus ralat)
  3. Dari Fina Bank Import, posting transaksi pembalik dan transaksi baru ke Fina Bank Statement
  4. Dari Fina Bank Statement, alokasikan transaksi pembalik ke tagihan/ invoice yang sama dengan transaksi lama yang diralat atau dibatalkan. Jenis transaksi alokasi: "Reversed Receipt", Deskripsi diisi dengan alasan pembatalan atau koreksinya.
  5. Dari Fina Bank Statement, posting transaksi "Reversed Receipt" ke Fina Receipt List. Statusnya akan berubah menjadi Receipt Posted
  6. Dari Fina Bank Statement, alokasikan transaksi yang baru ke tagihan/ invoice yang sesuai (khusus ralat)
  7. Dari Fina Bank Statement, posting transaksi "Reversed Receipt" dan transaksi yang baru ke Fina Receipt List. Statusnya keduanya akan berubah menjadi Receipt Posted
  8. Dari Fina Receipt List, transaksi "Reversed Receipt" dan transaksi yang baru di-posting ke Fina A/R, Fina Voucher seperti langkah B2, B4, B5, B5. Post Back ke sistem pengumpan B3 tergantung skenario masing-masing sistem.
 Bank Admin,
Petugas A/R		 Fina Bank Import
Fina Bank Statement
Fina Receipt List
Fina A/R Receipt
Fina [source-app] Console

Fina Payment Workflow

Alir kerja pengeluaran dana/ pembayaran keluar (Payment Workflow) diawali dengan proses pemesanan dana (requisition), kemudian mengalir ke proses pembayaran, sampai pembayaran tersebut dipertanggungjawabkan. Section ini menjelaskan alir kerja pengeluaran dana dan modul-modul (sub-systems) Fina yang terlibat.

Requisition

Requisition adalah proses pemesanan dana untuk membayar tagihan yang telah terjadi atau yang akan terjadi. Proses dimulai dari inisiasi pesanan dana melalui Fina A/P Invoice, Fina DP Invoice, dan Fina Pre-Payment dan berakhir saat permintaan dana diikat menjadi dokumen Pesanan Dana di Fina Payment Requisition.

Ada 3 (tiga) dokumen yang dapat menginisiasi proses pemesanan dana, yaitu:

  1. Fina A/P Invoice, pemesanan dana untuk pembelian yang sudah terjadi, barang/ jasa sudah diterima.
  2. Fina Down Payment Invoice (DP), pemesanan dana untuk pembelian yang sudah terjadi, barang/ jasa belum diterima
  3. Fina Pre Payment (BS), pemesanan dana untuk pembelian yang akan terjadi.

Saat disetujui (approve/ confirm/ post), dokumen-dokumen tersebut di atas akan menghasilkan satu atau beberapa rencana pembayaran (installments). Rencana pembayaran yang memenuhi kriteria tertentu dapat dapat digabung-gabungkan menjadi satu Pesanan Dana (Payment Requisition). Detail proses Requisition (pemesanan dana) dijelaskan di section Fina Payment Requisition (PD)

External Procurement/ Purchasing System (existing)
Adalah sistem pengadaan (procurement system) atau sistem pembelian (purchasing system) yang saat ini digunakan oleh unit-unit pengadaan/ pembelian di KG Media. Sistem-sistem tersebut merupakan sistem eksternal yang di Fina disebut "Source Application" atau Application.
Beberapa informasi/ dokumen yang 'mungkin' dipertukarkan dengan Fina:
  • Order Pembelian (Purchase Order, PO)
  • Dokumen Pengiriman/ Tanda Terima Barang (Delivery Order)
  • Berita Acara Serah Terima Hasil Pekerjaan/ Jasa (BAST)
  • Faktur atau Invoice Pembelian dari Supplier (Purchase Invoice/ Supplier's Invoice)
  • Data-data rujukan seperti: Barang, Supplier, dll.
Dalam alir pembayaran, Invoice Pembelian (Supplier's Invoice) yang diterima dari sistem eksternal akan akan dilanjutkan prosesnya di Fina sampai terbayar. Informasi dari pembayaran yang dilakukan dari FINA akan dikembalikan (post-back) ke sistem asalnya.
Pada gambar, sistem eksternal ditunjukkan dengan warna abu-abu sedangkan modul-modul FINA ditunjukkan dengan warna biru tua.
Fina A/P Invoicer (April 2022)
Adalah modul untuk mencatat Invoice Pembelian (Purchase Invoice) atau bukti-bukti transaksi pembelian lainnya yang diterima dari supplier, sekaligus mencatatkannya ke dalam A/P.
Product untuk dicantumkan dalam invoice diambil dari daftar produk di Fina. Informasi produk yang lebih detail dapat diketikkan sebagai note (catatan). Product di Fina dikelola oleh unit keuangan karena berperan penting dalam penentuan akun (COA Addressing).
Satu A/P Invoice bisa memiliki lebih dari satu tanggal jatuh tempo pembayaran (installments). Ada 2 jenis Installment, yaitu:
  1. Requisition Installment yaitu installment yang akan menimbulkan Payment Requisition saat diposting.
  2. Prepayment Installment yaitu installment yang sudah dibayar dengan dana dari prepayment sehingga tidak menimbulkan Payment Requisition saat diposting.
Saat di-posting, purchase invoice akan terkirim ke modul Fina A/P Balance untuk diikuti saldo terutangnya. Jika masih ada saldo, proses akan berlanjut ke modul Fina Payment Requisition (Pesanan Dana) untuk dieksekusi pembayarannya.
Fina Pre-Payment (BS) (May 2021)
Bon Sementara atau Prepayment adalah dokumen pengajuan permintaan dana. Prepayment digunakan sebelum pembelian dilakukan, atau dalam kondisi invoice pembelian/ tagihan dari supplier belum diterima dan atau bukti transaksi pembelian belum ada (terkumpul).
Modul Fina Pre-Payment berfungsi untuk mengatur workflow Prepayment sejak dibuat, diajukan untuk mendapat persetujuan, sampai diselesaikan.
Prepayment dibuat oleh karyawan yang berhak untuk dikirimkan kepada atasannya dalam hirarki otorisasi. Atasan memiliki opsi untuk menyetujui (approve), menolak (reject), dan mengembalikan (send-back) untuk direvisi.
Ketika disetujui (appoved), Prepayment akan ter-posting secara otomatis ke modul Fina Payment Requisition untuk diproses lebih lanjut ke pembayaran
Setelah tagihan dan bukti-bukti transaksi pembelian terkumpul, Prepayment diselesaikan di kasir berikut sisa uangnya. Jika tagihan lebih besar dari dana yang diterima, karyawan dapat mengajukan Prepayment baru (BS baru) untuk mengganti uang yang telah dikeluarkannya (reimburse).
Fina Payment Requisition (PD) (under development)
Dokumen Payment Requisition (Pesanan Dana, PD) dicatat dan dikelola dalam modul Fina Payment Requisition. Payment Requisition berfungsi sebagai permintaan dari unit kepada unit keuangan untuk membayarkan sejumlah uang kepada pihak (party) tertentu. Isinya antara lain:
  • Nilai yang harus dibayarkan (amount)
  • Cara pembayaran (payment method) yang dikehendaki
  • Pihak penerima pembayaran
  • Cost Center dan Project (Budget)
  • Employee penanggungjawab (PIC).
Disediakan 2 cara pembuatan Payment Requisition (PD)
  1. Manual, menggunakan layar input di modul Fina Payment Requisition
  2. Otomatis, saat Prepayment (BS) di-approve dari modul Fina Pre=Payment
Pesanan dana yang sudah dicatat/ dibuat kemudian di-posting ke proses disposisi pembayaran di Fina Payment Dispatcher.

Payment Processing

Pemrosesan pembayaran (Payment Processing) adalah serangkaian proses yang harus dilalui untuk memenuhi Payment Requisition (Pesanan Dana). Proses dimulai sejak pesanan dana diterima, kemudian dialirkan untuk dieksekusi pembayarannya, berakhir saat dana diserahkan kepada penerimanya berikut seluruh penyelesaian administrasinya di A/P, Voucher, G/L, dan di R/C Bank.

Fina Payment Dispatcher (under development)
Karena alasan-alasan tertentu, tanggal dan metode pembayaran yang tertera di dalam Payment Requisition belum tentu dapat dipenuhi. Bisa juga terjadi, pesanan dana belum menyebutkan metode pembayarannya. Modul Fina Payment Dispatcher digunakan untuk menjadwalkan dan menetapkan (ulang) metode pembayaran (payment method) atas Payment Requisition (Pesanan Dana) yang masuk.
Fitur-fitur Fina Payment Dispatcher antara lain:
  • Menjadwal ulang tanggal eksekusi pembayaran
  • Mengubah metode pembayaran (Bank Transfer, Cash, Cash BRI, Giro, dll)
  • Menetapkan rekening bank pengirim dan cash counter untuk pengambilan pembayaran tunai
  • Menyusun "Bank Transfer List" (auto-credit)
  • Mencetak giro dan slip-slip pembayaran lainnya
  • Mencatat penitipan giro dan slip-slip pembayaran ke cash counter
Pesanan Dana yang sudah selesai diproses di modul ini kemudian di-posting ke modul Fina A/P Payment dan ke modul Fina Voucher. Dalam alir pembayaran, pengakuan terjadi sebelum dana "benar-benar" diserahkan ke penerimanya.
Fina Voucher (Payment) (Apr 2021)
Voucher (Bukti Kas/ Bukti Bank) adalah bukti (proof/ evidence) terjadinya transaksi di bank atau di kasir yang menjadi dasar untuk jurnal akuntansi.
Ada 4 jenis voucher di Fina yaitu:
  1. Bank Receipt Voucher (Bukti Bank Masuk)
  2. Cash Receipt Voucher (Bukti Kas Masuk)
  3. Bank Payment Voucher (Bukti Bank Keluar)
  4. Cash Payment Voucher (Bukti Kas Keluar)
Payment Voucher bisa dibuat dengan 2 cara:
  1. Manual menggunakan layar input voucher di modul Fina Voucher
  2. Dihasilkan dari proses payment disposition di Fina Payment Dispatcher. Beberapa transaksi payment bisa dikelompokkan menjadi satu Payment Voucher untuk mengurangi jumlah voucher yang dihasilkan dan jumlah posting-an ke Fina G/L
Setelah dibuat Payment Voucher di-posting ke Fina G/L. Nomor akun tujuan diperoleh dari COA Addressing.
Fina Bank Import (Feb 2021)
Pembayaran keluar melalui transfer bank akan muncul di dalam R/C akun bank pengirimnya. Modul Fina Bank Import berfungsi untuk memindahkan baris-baris laporan RC Bank (Bank Statement/ Rekening-Courant) ke dalam sistem.
Disediakan 3 cara untuk pemindahan RC Bank:
  1. Manual dengan mengetikkan baris-baris RC bank. Digunakan jika bank tidak menyediakan data digital untuk diimport.
  2. Paste Area untuk copy-paste dari Excel masuk ke dalam sistem. Digunakan jika bank menyediakan data digital non-standar dalam bentuk tabel atau setara tabel yang dapat diolah dengan Excel.
  3. Import file MT940. Digunakan jika bank menyediakan RC dalam format Swift MT940 yang bisa di download. Format ini adalah de facto standar yang digunakan oleh banyak bank.
Data RC bank yang sudah dimasukkan ke sistem kemudian di-posting ke masuk ke modul Fina Bank Statement. Pengkodean eksternal (Swift standar) diterjemahkan ke pengkodean internal.
Fina Bank Statement (Feb 2021)
Fungsi modul Fina Bank Statement untuk menyimpan dan mengalokasikan baris-baris RC Bank ke transaksi-transaksi internal. Contohnya: baris RC bank "Transfer Out" dialokasi ke "Payment Supplier" untuk membayar invoice pembelian.
Fitur-fitur Fina Bank Statement antara lain:
  • Informasi saldo bank secara kronologis
  • Multiple Bank Allocations sehingga satu baris RC bisa dialokasikan ke beberapa transaksi sekaligus (Receipt, Payment, Deposit, Clearing, Bank Expense, Bank Interest, etc)
  • Multi Company
  • Multi Currency Transaction (Fixed and Floating rate conversion)
  • Kliring pencairan saldo kasir ke bank (Withdrawal)
  • Kliring pencairan Giro/ Check
Hasil alokasi transfer bank (Bank Payment) kemudian di-posting masuk ke Fina Payment List untuk bergabung dengan hasil alokasi pembayaran tunai (Cash Payment).
Fina Cash (Payment) (Feb 2021)
Modul yang dioperasikan oleh Cashier ini digunakan untuk melayani transaksi pembayaran tunai/ setara tunai (cash payment).
Fitur-fitur Fina Cash antara lain:
  • Multiple Cash Payment Methods (Cash, BG, Cheque, Credit Card, etc) for Multiple Cash Allocations (Receipt, Payment, Deposit)
  • Multi Company (support inter company Balance Funding, Balance Transfer)
  • Multi Currency Transaction (Fixed and Floating rate conversion)
  • Giro and Cheque Processing (Receiving and registration, Handed-over, inter Cash Counter transfer)
  • Cash Balance management (Top-Up, Withdrawal, Transfer)
  • Deposit Management: (Deposit-In, Deposit-Out, Deposit Balance Tracking)
  • Cash Counter management (Check-In, Check-Out, Rest, forced Kick-Out)
Hasil alokasi pembayaran tunai (Cash Payment) kemudian di-posting masuk ke Fina Payment List untuk bergabung dengan hasil alokasi pembayaran bank (Bank Transfer).
Fina Giro/ Cheque (Payment) (Aug 2021)
Giro, cheque, dan slip-slip pembayaran yang di-"titip"-kan ke Cash Counter (kasir) dicatat oleh kasir menggunakan modul Fina Giro/ Cheque. Dengan demikian serah-terima "titipan" terkonfirmasi dan dapat dilacak di kedua sisi, kasir dan penitipnya.
Karena pada saat di-"titip"-kan pembayaran telah diakui, maka Fina memperlakukan giro, cheque, dan slip-slip pembayaran tersebut setara dengan dana tunai lainnya. Artinya akan terakumulasi sebagai saldo kasir yang harus dipertanggungjawabkan.
Saldo kasir akan tersebut akan berkurang ketika giro/ cheque/ slip pembayaran diserahkan kepada penerimanya.

Skenario ini pernah disinggung dalam diskusi 8 Nov 2021 mengunakan Fina Giro/ Cheque (payment). Masih perlu disepakati tentang saldo kasirnya karena voucher sudah diterbitkan sebelumnya

FINA Cash

Kasir (Cashier)
Cashier atau disebut kasir adalah karyawan yang bertugas melayani transaksi kas dengan Customer, Supplier, atau Employee. Kasir menjalankan tugasnya di Cash Counter.
Kasir adalah BP
Seluruh pihak (parties) yang terlibat dalam proses bisnis di Fina disebut Business Partner atau BP. Dalam pengertian tersebut Cashier adalah BP juga.
Cashier adalah karyawan (employee) yang merupakan salah satu dari 5 jenis BP yang ada di Fina yaitu:
  1. Internal Organization
  2. Customer
  3. Supplier
  4. Bank
  5. Employee (Cashier, Bank Admin, dll)
Cash Counter
Cash Counter adalah tempat di mana Cashier menjalankan tugasnya melayani transaksi kas dengan Customer, Supplier, atau Employee. Cash Counter adalah entitas ambigu, bisa bermakna "tempat", bisa bermakna "organisasi" karena seperti "organisasi", Cash Counter punya approval-hirarchy dan default currency (mata uang).
Cash Counter adalah entitas kerja yang tidak berada di bawah legal-entity tertentu, dapat melayani transaksi kas untuk semua Company (legal-entity)
Ambiguitas berlanjut karena Cash Counter juga berfungsi sebagai akumulator kas, di mana jumlah uang kas akan dipertanggungjawabkan per Cash Counter.

Cash Counter Management

Cash Counter Access
Cash Counter hanya dapat diakses oleh Cashier yang terdaftar di dalam Hierarchy yang ditetapkan untuk Cash Counter tersebut. Fina hanya mengijinkan satu orang Cashier masuk ke Cash Counter pada suatu saat.
Cash Counter Status
Ada 3 status (workstate) Cash Counter yaitu:
OpenCash Counter sedang beroperasi, ada seorang Cashier yang sedang check-in di Cash Counter tersebut.
CloseCash Counter sedang tidak beroperasi, tidak ada Cashier yang sedang check-in di Cash Counter tersebut.
IdleCash Counter sedang tidak beroperasi, ada Cashier yang sedang check-in di Cash Counter tersebut namun sedang beristirahat atau tidak dapat melayani customer
Cashier Check-In
Seorang Cashier hanya boleh masuk (check-in) ke Cash Counter yang berstatus "Closed". Sebelum masuk, Cashier akan diminta untuk mengetikkan password walaupun kasir tersebut sudah login ke Fina. Setelah masuk, Cash Counter akan berubah status menjadi Open dan Cashier akan terhubung dengan Cash Counter sampai Cashier tersebut melakukan check-out.
Cashier Check-Out
Seorang Cashier hanya boleh keluar (check-out) dari Cash Counter yang saat itu berstatus "Open" dan terhubung dengan Cashier tersebut. Setelah checked-out Cash Counter akan kembali berstatus "Closed" dan Cashier lain dapat melakukan check-in ke Cash Counter tersebut. Proses check-out biasanya diikuti dengan pertanggungjawaban Cashier atas kas yang terakumulasi di Cash Counter tersebut.
Cashier Rest
Status Rest digunakan untuk menandai bahwa kasir sedang tidak dapat melayani pelanggan (istirahat, pipis) tanpa melepaskan hubungan dengan Cash Counter tempat dia bertugas. Tanda ini mencegah Cashier lain melakukan check-in ke Cash Counter nya. Saat kembali, Fina akan meminta Cashier tersebut mengetikkan password-nya.

Cash Transaction

Cash Transaction Types
Transaksi kas yang terjadi di Cash Counter dicatat oleh Cashier menggunakan layar "Cash Transaction". Ada 3 jenis transaksi kas yaitu:
  1. Cash Receipt
  2. Cash Payment
  3. Cash Deposit

Cash Receipt Transaction

Transaksi Penerimaan Kas
Item-item (tagihan-tagihan) yang dibayar oleh Customer diinput dan dihitung nilainya. Perhitungan dilakukan dalam (default) mata uang yang ditetapkan di Cash Counter tersebut menggunakan nilai tukar (rate) yang berlaku saat itu.
Customer dapat melakukan pembayaran dengan kombinasi alat bayar (tunai, bg, cc, dll) dalam currency yang berbeda-beda. Nilai yang diterima dikonversi ke default currency yang berlaku di Cash Counter tersebut menggunakan nilai tukar rate yang berlaku saat itu.
Transaksi dapat disimpan setelah nilai total item (tagihan) yang di bayar sama (100% match) dengan nilai total pembayaran Customer yang diterima. Lembar Cash Receipt dapat dicetak setelah transaksi tersimpan.
Aturan-Aturan Penerimaan Kas
Pembayaran dari beberapa Customer yang berbeda dapat digabungkan menjadi satu transaksi jika customer-customer tersebut merujuk ke BP yang sama (mahluk sebenarnya sama).
Pembayaran ke beberapa SalesOrg yang berbeda dapat digabungkan menjadi satu transaksi jika masih dalam satu Company
Customer yang membayar sebagian tagihannya (tidak penuh) dapat diterima. Nilai yang diakui adalah nilai yang dibayar oleh Customer bukan nilai total tagihan (invoice). Sisa tagihan dilacak dari invoice. Note: Fitur ini masih dipelajari lebih lanjut oleh FSD.
Posting Penerimaan Kas
Setelah transaksi tersimpan dan terverifikasi, Cashier dapat langsung mem-posting transaksi tersebut untuk menghasilkan Voucher (Cash Receipt Voucher/ Bukti Kas Masuk) . Tanggal Posting dapat di set mundur agar transaksi masuk ke periode bayar yang disepakati dengan Customer.
Jika tanggal posting di set mundur (back dated), maka status transaksi akan menjadi Need Approval. Approval dari atasan dalam hirarki Cash Counter diperlukan sebelum posting benar-benar dilakukan.
Penerimaan Kas dan Deposit Out
Pihak tertagih dapat membayar tagihannya menggunakan deposit yang pernah tercatat sebelumnya. Fina secara otomatis akan mencatat pengambilan deposit yang digunakan untuk membayar tagihan tersebut. Dalam hal ini deposit pihak tertagih dianggap sebagai alat bayar (payment method).
Penerimaan Kas dan Deposit In
Ketika pihak tertagih membayar lebih banyak dari total tagihannya, maka kelebihan pembayaran tersebut dapat dicatatkan sebagai deposit baru menggunakan layar penerimaan kas. Secara otomatis, Fina akan membuat transaksi deposit-in baru.

Cash Payment Transaction

Transaksi Pengeluaran Kas
Ada beberapa transaksi pengeluaran kas yang dapat dilakukan oleh Cashier di Cash Counter, di antaranya:
  • Refund (pengembalian dana) secara tunai kepada Customer karena kelebihan bayar, klaim, dan lain-lain.
  • Reimburse (penggantian dana) secara tunai atas pengeluaran yang dilakukan oleh Employee
  • Pembayaran tunai atas Payment Request (pesanan dana) transaksi pembelian atau pengeluaran dana lainnya oleh Employee
  • Pembayaran tunai atas Down Payment (bon sementara) transaksi pembelian atau pengeluaran dana lainnya oleh Employee
  • Pembayaran tunai atas Supplier Invoice (tagihan supplier) atas transaksi pembelian yang telah dilakukan atau uang muka
Item-item pengeluaran kas kepada Customer, Supplier, atau Employee diinput dan dihitung nilainya. Perhitungan dilakukan dalam (default) mata uang yang ditetapkan di Cash Counter tersebut menggunakan nilai tukar (rate) yang berlaku saat itu.
Cashier dapat mencetak lembar Payment Receipt (tanda terima pembayaran) dan meminta tanda tangan penerima dana. Setelah itu Cashier menyerahkan dana dalam mata uang yang disepakati menggunakan nilai tukar yang berlaku saat itu.
Aturan-Aturan Pengeluaran Kas
Posting Pengeluaran Kas

Cash Deposit Transaction

Transaksi Titipan
Transaksi titipan di Fina versi 1.1 ini berfokus untuk mencatat titipan di cash counter
Aturan-Aturan Deposit
Posting Deposit
Beberapa issue yang belum terkonfirmasi atau yang belum jelas masuk dalam scope atau tidak:
  • Mekanisme pengisian petty cash di cash counter
  • Report closing cash counter
  • Timing posting pembayaran ke sistem asal (disepakati 4 Mar 2021)
  • Bukti Kas penerimaan dan kaitannya dengan posting yang sudah dilakukan
  • Transaksi internal antara Sales Org dengan funder Cash Counter (Kompas/ Gramedia). Faktanya sudah disampaikan oleh FSD sejak 15 Januari 2021. Detailnya belum dijelaskan.

Multi-Currency Proses Cash

Entitas-Entitas Currency Proses Cash

Fitur multi-currency di Finamendetaksi setiap potensi perbedaan mata uang (currency) pada entitas-entitas dalam transaksi penerimaan pembayaran melalui cash, yaitu:

ACurrency SalesOrg, organisasi yang melakukan penjualan

BCurrency Invoice atau tagihan customer lainnya

CCurrency Alat Bayar customer (payment method)

DCurrency Cash Counter (kasir) penerima pembayaran customer

ECurrency Funder Cash Counter, Sekarang penerimaan kas disetorkan ke salah satu dari 2 rekening, milik Kompas atau Gramedia, berbeda dengan SalesOrg-nya

Skenario Currency-Exchange Proses Cash

  Skenario Keterangan Konversi
1. Home-currency SalesOrg A Standar mata uang yang berlaku di SalesOrg. Mata uang ini juga yang akan digunakan untuk laporan keuangan SalesOrg tersebut –
2. Currency Invoice B Invoice dapat diterbitkan oleh SalesOrg dalam mata uang yang berbeda dengan mata uang standar yang berlaku di SalesOrg tersebut.
Note: Peraturan BI No. 17/3/PBI/2015 mewajibkan penggunaan Rupiah dalam setiap transaksi		 –
  a. Currency tagihan Customer B Customer menerima tagihan dalam mata uang sesuai Invoice –
  b. Currency omzet penjualan di A/R A Omzet penjualan dibukukan sesuai home-currency SalesOrg walaupun currency Invoice tetap dibawa untuk referensi. Konversi dari Invoice currency ke SalesOrg home-currency mengacu ke nilai tukar (rate) pada tanggal posting ke A/R. B ➔ A
3. Default currency Cash Counter D Cash Counter penerima pembayaran Customer menerapkan default currency yang berlaku di Cash-Counter tersebut (di set dari master Cash Counter). Fungsi default currency itu untuk akumulasi nilai cash dan untuk pelaporan. –
4. Currency Invoice yg dibayar B Tagihan (Invoice dan non invoice) yang akan dibayar oleh Customer dikonversi terlebih dahulu ke default currency Cash Counter menggunakan rate konversi yang berlaku saat pembayaran diterima. B ➔ D
5. Currency alat bayar Customer C Pembayaran Customer dalam mata uang apapun akan dikonversi ke default currency di Cash Counter menggunakan rate konversi yang berlaku saat pembayaran diterima. C ➔ D
6. Currency Edit List Payment A Baris-baris alokasi payment di-posting ke Edit List Payment dalam home-currency SalesOrg nya. Konversi dilakukan saat posting dengan mengacu ke nilai tukar (rate) pada tanggal transaksi penerimaan cash, bukan tanggal posting. D ➔ A

FINA Bank

Bank Group
Bank Group adalah sekelompok Bank di bawah naungan manajemen yang sama. Contoh: Bank Central Asia (BCA), Bank Rakyat Indonesia (BRI). dan Maybank. Setiap Bank Group menyimpan 3 digit sandi BI (Kode Bank Indonesia = Central Bank Code).
Bank
Bank adalah institusi keuangan tempat Bank Account (rekening bank) diterbitkan. Setiap Bank adalah cabang dari sebuah Bank Group, misalnya BRI KC Kota adalah cabang dari BRI. Setiap Bank menyimpan 7 digit sandi BI dan kode-kode pengenal lain yang ditetapkan oleh konsorsium bank internasional: SWIFT Code dan IBAN Code.
Bank Account
Bank Account atau rekening bank adalah adalah catatan tentang nasabah dan transaksinya di bank nasabah tersebut terdaftar. Setiap Bank Account menyimpan Bank tenpat rekening dibuka, Nomor rekening, Nama nasabah, dan mata uang (currency).

Pengelolaan Bank Account

Kepemilikan Bank Account
Ada 3 entitas di Fina yang bisa memiliki Bank Account yaitu:
  1. Customer
  2. Supplier - (not exist in this version)
  3. Internal Organisasi
Seorang Customer/ Supplier dapat memiliki lebih dari satu Bank Account. Satu Bank Account dapat dimiliki secara beramai (share) oleh lebih dari satu Customer/ Supplier dari Application yang berbeda.
Hubungan many-to-many antara Bank Account dengan Customer/ Supplier sengaja dipersiapkan karena customer atau supplier yang sama (mahluknya sama) bisa tercatat di beberapa aplikasi yang berbeda, dan kemudian aplikasi-aplikasi tersebut mem-posting data Customer/ Supplier ke Fina lengkap dengan informasi Bank Account nya.
Di sisi yang lain, satu Bank Account hanya boleh dimiliki oleh satu dan hanya satu Organization. Sifat kepemilikannya eksklusif dan tidak bisa di share bahkan ke induk (parent) Organization tersebut. Suatu Organisasi tentu saja boleh memiliki lebih dari satu Bank Account.
Atribut owner-type akan diberikan pada setiap Bank Account untuk menandai jenis pemiliknya, salah satu dari ketiga entitas tersebut di atas, atau "not-set" jika belum ada pemiliknya atau dilepas oleh pemiliknya.
Managed vs Unmanaged
Atribut managed dapat dilekatkan ke Bank Account jika transaksi dalam rekening bank tersebut akan diikuti (di-track) di dalam Fina. Hanya Bank Account yang dimiliki oleh Organization saja yang bisa di managed.
Registrasi
Bank Account diregistrasi dari layar Bank Account yang tersedia. Sistem akan memeriksa duplikasi berdasarkan Nomor Rekening, Bank tempat rekening dibuka, dan Nama pemilik rekening (owner/ holder name).
Setelah tersimpan, Bank Account dapat dihubungkan dengan Organization atau dengan Customer/ Supplier pemiliknya. Secara otomatis sistem akan melekatkan atribut owner-type sesuai dengan jenis pemiliknya (Customer/ Supplier/ Organization).
Registrasi juga dapat dilakukan langsung dari layar Customer dan Supplier. Bank Account secara otomatis terhubung ke Customer atau Supplier tersebut.
Informasi Bank di Bank Account
Informasi Bank di Bank Account diisi dengan cara dengan memilih Bank dari daftar atau dengan cara mengetikkan nama bank secara bebas. Opsi ini sengaja dibuka untuk mengantisipasi informasi bank yang tidak lengkap dari Application sumbernya.
Perubahan Data dan Penghapusan
Seluruh informasi Bank Account dapat diubah baik dari layar Bank Account maupun dari layar Customer/ Supplier. Namun jika Bank Account diberi label managed dan sudah ada transaksi (statement) terekam di Fina maka perubahan data tidak dapat dilakukan lagi.
Hal yang sama juga berlaku untuk penghapusan. Hanya Bank Accout yang belum memiliki rekaman transaksi di Fina yang dapat dihapus. Penghapusan dapat dilakukan dari layar Customer/ Supplier. Namun sifatnya hanya melepaskan kepemilikan Bank Account dari Customer/ Supplier itu. Penghapusan yang sebenarnya harus dilakukan langsung dari layar Bank Account.

Bank Processing

Pemrosesan Rekening Koran Bank (Rekening-courant/ RC = Bank Statement) meliputi kegiatan-kegiatan sbb:

  • Memindahkan baris-baris RC bank (eksternal data) ke dalam sistem dan memetakan pengkodean eksternal ke pengkodean internal
  • Menerjemahkan baris-baris transaksi dalam Bank Statement (internal) ke transaksi-transaksi bisnis yang dilakukan perusahaan
  • Menerjemahkan baris-baris transaksi dalam Bank Statement (internal) ke akun-akun General Ledger (Tax, Expense, Revenue)

Alir kerja (workflow) pemrosesan rekening koran melibatkan 2 modul Fina yaitu: Bank Import Module dan Bank Statement Module.

Bank Import Module

Modul Bank Import digunakan untuk memasukkan laporan RC bank ke dalam Fina. Sebagian bank sudah menyediakan laporan RC dalam bentuk file digital yang bisa di-download. Sebagian yang lain hanya menyediakan laporan RC dalam bentuk cetakan yang harus di-input secara manual ke dalam sistem.

Upload RC Bank
Fasilitas upload bisa digunakan jika bank menyediakan laporan RC digital dalam format MT940. File RC harus di-download terlebih dahulu sebelum di upload ke Fina.
Dokumen yang baru saja di upload statusnya "unposted". Fina akan menyimpan file aslinya sebagai arsip dan menampilkan isinya untuk di review. User dapat memeriksa baris-baris transaksi RC tersebut, namun tidak dapat melakukan perubahan data (read-onlu).
Jika tidak ditemukan masalah, dokumen RC tersebut bisa langsung di-posting masuk ke Modul Bank Statement. Status dokumen setelah posting berubah menjadi "posted".
Input RC Bank Manual
Fasilitas input digunakan jika tidak tersedia laporan RC dalam bentuk digital. Sebelum menginput, user membuat dokumen kosong dan memberi nama pada dokumen tersebut. Dokumen yang baru saja dibuat akan berstatus "unposted".
Setelah dokumen tersedia, user dapat langsung menginputkan baris-baris transaksi RC secara manual. Dokumen dapat diubah isinya selama statusnya masih "unposted"
Setelah input manual selesai, dokumen bisa langsung di-posting masuk ke Modul Bank Statement. Status dokumen setelah posting berubah menjadi "posted".
Paste RC Bank
Sistem menyediakan Paste Area di mana user dapat melakukan copy paste laporan RC dalam format Excel. Sebelum menginput, user membuat dokumen kosong dan memberi nama pada dokumen tersebut. Dokumen yang baru saja dibuat akan berstatus "unposted".
Setelah dokumen tersedia, baris-baris transaksi Excel dapat di copy dan di paste ke area yang disediakan. Dokumen dapat diubah isinya selama statusnya masih "unposted"
Setelah selesai, dokumen bisa langsung di-posting masuk ke Modul Bank Statement. Status dokumen setelah posting berubah menjadi "posted".
Swift Code Mapping
Pada proses upload RC, jenis transaksi yang dilaporkan oleh bank dideteksi dari kode-kode yang melekat pada transaksi tersebut. Kode-kode itu mengacu ke spesikasi Swift MT940 format. Spesifikasi yang diikuti oleh banyak bank di dunia.
Sebelum ditampilkan, kode-kode transaksi eksternal tersebut diterjemahkan ke kode-kode transaksi yang digunakan secara internal. Fina memelihara kode-kode transaksi (eksternal & internal) di dalam master Transaction Type dan tabel konversi antar kode.
Posting ke Modul Bank Statement
Proses posting adalah proses pengiriman isi dokumen RC ke Modul Bank Statement. Setelah di-posting status dokumen berubah menjadi "posted" dan perubahan data sudah tidak dapat dilakukan lagi.

Bank Statement Module

Modul Bank Statement digunakan untuk melakukan alokasi baris-baris Bank Statement menjadi pembayaran atas invoice atau transaksi penjualan.

Listing dan Filtering
Modul Bank Statement menampilkan setiap baris transaksi yang terjadi pada sebuah Bank Account. Tersedia filter-filter untuk membatasi jumlah baris yang ditampilkan. Status pemrosesan masing-masing baris transaksi di tampilkan dengan indikator berwarna (workstate). Nilai-nilai di kolom Debit, Credit, dan Balance dinyatakan dalam currency Bank Account nya.
Alokasi
Proses alokasi adalah proses memasangkan baris-baris transaksi bank statement dengan ke pos-pos pembayaran atau penerimaan bank.
Posting dan Pembuatan Voucher
Setelah alokasi tersimpan dan terverifikasi, Bank Admin dapat langsung mem-posting transaksi tersebut untuk dibuat Voucher (Bank Voucher/ Bukti Bank) . Tanggal Posting dapat di set mundur agar transaksi masuk ke periode bayar yang disepakati dengan Customer.
Jika tanggal posting di set mundur (back dated), maka status transaksi akan menjadi Need Approval. Approval dari atasan dalam hirarki admin Bank Account diperlukan sebelum posting benar-benar dilakukan.

Multi-Currency Proses Bank

Entitas-Entitas Currency Proses Bank

Fitur multi-currency di Finamendetaksi setiap potensi perbedaan mata uang (currency) pada entitas-entitas dalam transaksi penerimaan pembayaran melalui bank, yaitu:

ACurrency SalesOrg, organisasi yang melakukan penjualan

BCurrency Invoice atau tagihan customer lainnya

CCurrency Alat Bayar customer (payment method)

DCurrency Bank Account (rekening bank) penerima pembayaran customer

ECurrency Owner Bank Account, organisasi pemilik rekening bank. Entitas pemilik account dengan entitas penjual sengaja dibedakan meskipun biasanya sama.

Skenario Currency-Exchange Proses Bank

  Skenario Keterangan Konversi
1. Home-currency SalesOrg A Standar mata uang yang berlaku di SalesOrg. Mata uang ini juga yang akan digunakan untuk laporan keuangan SalesOrg tersebut –
2. Currency Invoice B Invoice dapat diterbitkan oleh SalesOrg dalam mata uang yang berbeda dengan mata uang standar yang berlaku di SalesOrg tersebut.
Note: Peraturan BI No. 17/3/PBI/2015 mewajibkan penggunaan Rupiah dalam setiap transaksi		 –
  a. Currency tagihan Customer B Customer menerima tagihan dalam mata uang sesuai Invoice –
  b. Currency omzet penjualan di A/R A Omzet penjualan dibukukan sesuai home-currency SalesOrg walaupun currency Invoice tetap dibawa untuk referensi. Konversi dari Invoice currency ke SalesOrg home-currency mengacu ke nilai tukar (rate) pada tanggal posting ke A/R. B ➔ A
3. Currency Bank Account penerima D Rekening bank untuk menerima transfer pembayaran Customer menggunakan mata yang ditentukan saat rekening dibuka. Misalnya: BCA Dollar (USD), Tahapan BCA (IDR) –
  a. Currency Bank Statement (RC) D RC bank akan dinyatakan dalam mata uang sesuai mata uang rekening bank –
  b. Currency pembayaran Customer D Transfer pembayaran customer dinyatakan dalam mata uang rekening bank. Jika terjadi perbedaan akan langsung dikonversi oleh Bank menggunakan rate konversi yang berlaku di Bank saat customer melakukan transfer. –
4. Currency di proses Bank Import D Proses-proses di bank import menggunakan currency rekening bank –
  a. Currency file RC yg di download D File RC yang di download (format MT940) selalu dalam currency yang sama dengan currency Bank Account nya. –
  b. Currency input manual RC D Baris-baris transaksi bank yang diinput secara manual (Manual Bank Statement) dinyatakan dalam currency yang sama dengan currency Bank Account nya –
5. Currency di proses Bank Statement D Proses-proses di bank statement menggunakan currency rekening bank –
  a. Currency baris RC DE Baris-baris transaksi RC bank ditampilkan dalam 2 currency yaitu currency rekening bank dan home-currency pemilik rekening bank. Konversi dilakukan pada saat baris transaksi tersebut masuk ke Bank Statement dengan mengacu ke nilai tukar (rate) pada tanggal transaksi RC, bukan tanggal import/ input D ➔ E
  b. Currency sisa (blm di) alokasi D Nilai (amount) sisa yang belum dialokasi adalah nilai tertera di RC dalam currency Bank Account –
  c. Currency Invoice yg dibayar B Nilai (amount) Invoice/ tagihan yang bayar (mendapat alokasi) dinyatakan dalam currency sesuai Invoice/ tagihannya. Nilai tersebut akan mengambil sebagaian/ seluruh nilai sisa yang belum teralokasi. Konversi dilakukan saat alokasi dengan mengacu ke nilai tukar (rate) pada tanggal transaksi RC, bukan tanggal alokasi. B ➔ D
  d. Currency selisih (deviasi) kurs D

Deviasi bisa terjadi karena perbedaan nilai tukar (rate) dan juga biaya-biaya transfer yang langsung membebani nilai yang di transfer.

  • saat Customer melakukan pembayaran di mana bank melakukan konversi berdasarkan rate bank (poin 3b.).
  • saat proses alokasi di mana Fina melakukan currency berdasarkan rate internal (poin 5c.).
Meskipun konversi mengacu ke tanggal yang sama, perbedaan tetap mungkin terjadi.

Deviasi yang lebih nyata terjadi karena perbedaan

  • nilai invoice saat di-posting ke A/R (poin 2b)
  • nilai Invoice saat proses alokasi (poin 6)
karena jeda waktunya bisa berbulan-bulan.

–
6. Currency Edit List Payment A Baris-baris alokasi payment di-posting ke Edit List Payment dalam home-currency SalesOrg nya. Konversi dilakukan saat posting dengan mengacu ke nilai tukar (rate) pada tanggal transaksi RC, bukan tanggal posting. D ➔ A

FINA Disposition

Disposition adalah pemindahan saldo pada suatu Cash Counter dan Bank Account. Ada 4 jenis transaksi disposisi, yaitu Bank to Bank, Bank to Cash (Top Up), Cash to Bank (Withdrawal) dan Cash to Cash (Transfer).

Bank to Bank Disposition

Input dan Posting RC Bank (Novi, Juli 2023)
Modul Fina Bank Import berperan di awal proses Bank to Bank Disposition untuk memindahkan baris-baris laporan RC Bank (Bank Statement/ Rekening-Courant) ke dalam sistem, sebelum proses disposisi dapat dilakukan. Bank Import dengan kode BTO (Bank Transfer Out) merupakan kode pencatatan dari sumber RC Bank yang akan dipindahkan. Sedangkan kode BTI (Bank Transfer In) merupakan kode pencatatan dari target RC Bank yang menerima dana.
Data RC Bank yang sudah dimasukkan ke sistem kemudian di-posting dan masuk ke modul FINA Bank Statement. Pengkodean eksternal (Swift standar) diterjemahkan ke pengkodean internal. RC Bank yang sudah di-posting juga dikirim ke modul Fina Disposition untuk dibuatkan dokumen pemindahan saldo Bank to Bank.
Pemindahan Saldo "Bank to Bank" (Novi, Juli 2023)
Pemindahan saldo antar bank account dicatat oleh admin bank menggunakan modul FINA Disposition "Bank to Bank". Dokumen ini merupakan pernyataan/laporan bahwa telah dilakukan pemindahan saldo. Saldo bank hanya dapat dipindahkan ke bank account yang masih dalam 1 organisasi atau ke organisasi yang masih dalam 1 grup.
Setelah proses input selesai, dokumen disposisi diproses dan sistem secara otomatis akan membuat alokasi RC Bank pada modul FINA Bank Statement ke transaksi-transaksi Balance In dan Balance Out. Contohnya: baris RC Bank "Transfer Out" dialokasikan ke transaksi "Balance Out" sesuai dengan jumlah target bank RC pada Disposition. Baris RC Bank "Transfer In" dialokasikan ke transaksi "Balance In".
Saat Disposition sudah diproses, status disposisi akan berubah menjadi Closed. Sistem secara otomatis juga akan membuat Installment Paid, Payment Requisition Clear dan Bank Payment Voucher.

Bank to Cash Disposition (Top Up)

Permintaan Isi Ulang Saldo Cash Counter (Novi, Juli 2023)
Untuk melakukan top up pada suatu Cash Counter, diawali dengan kasir membuat permintaan/request top up kepada pihak bank. Proses request ini dibuat di modul FINA Disposition "Bank to Cash".
Setelah permintaan top up selesai dibuat, dokumen top up diproses untuk membuat rencana pembayaran atau Installment dan pesanan dana atau Payment Requisition. Saat permintaan sudah diproses, sistem merubah status Disposition menjadi Processed, Installment Processed dan Payment Requisition New. Installment yang dibuat memiliki tipe Transfer Installment, yang menandai bahwa pesanan dana ini merupakan permintaan untuk isi ulang saldo Cash Counter.
Persetujuan PD (Payment Requisition) (Novi, Juli 2023)
Pesanan Dana Payment Requisition yang diterima kemudian disetujui (Approve) oleh pihak A/P Controller untuk diserahkan ke pihak bank dan dieksekusi pembayarannya. Pesanan dana yang disetujui akan memiliki status Approved.
Membuat & Memproses Slip (Novi, Juli 2023)
Pembuatan Slip dilakukan oleh admin bank untuk dicairkan ke kasir. Petugas bank akan menentukan dari akun bank yang mana Slip akan dibuat. Slip yang baru kemudian diproses dan sistem secara otomatis membuat Bank Payment Voucher serta mengirim dokumen slip ke Cash Counter. Fisik slip diserahkan ke kasir untuk dikonfirmasi bahwa slip sudah diterima.
Konfirmasi Slip (Novi, Juli 2023)
Slip yang diterima oleh kasir perlu dikonfirmasi bahwa slip pembayaran sudah diterima. Proses ini akan merubah status Disposition menjadi Closed dan menambah saldo pada Cash Counter dengan tipe Balance In (BALIN). Selain itu, Slip yang diterima berubah status menjadi Handed Over, Installment dan Payment Requisition menjadi Paid.
Untuk slip dengan metode pembayaran Giro/Cheque/Cash BRI, akan merubah status Payment BGCQ menjadi Outstanding dan sistem mengirimkan slip tersebut ke modul FINA Disposition "Cash to Cash". Cash to Cash Disposition dilakukan untuk menangani :
  • Pemindahan saldo slip menjadi cash pada suatu Cash Counter
  • Pemindahan saldo ke Cash Counter lain apabila mengalami kesalahan top up Cash Counter
Kliring PD (Payment Requisition) (Novi, Juli 2023)
Proses terakhir dari top up saldo Cash Counter adalah dengan melakukan kliring PD (Payment Requisition) agar status PD berubah menjadi Clear. Pembayaran keluar melalui transfer bank akan muncul di dalam R/C akun bank pengirimnya. Modul FINA Bank Import berfungsi untuk memindahkan baris-baris laporan RC Bank (Bank Statement/ Rekening-Courant) ke dalam sistem.
RC Bank yang sudah dipindahkan ke sistem, kemudian di-posting dan masuk ke modul FINA Bank Statement. RC Bank pada Bank Statement dialokasikan dengan dokumen Payment Requisition untuk dilakukan proses kliring. Hasil dari alokasi selanjutnya di-posting untuk merubah status PD menjadi Clear.

Cash to Bank Disposition (Withdrawal)

Pemindahan Saldo "Cash to Bank" (Novi, Juli 2023)
Proses pemindahan saldo "Cash to Bank" (Penarikan Dana/Withdrawal) dibuat oleh pihak kasir untuk melaporkan ke admin bank bahwa telah terjadi penarikan dana pada suatu Cash Counter. Dana tersebut disetorkan oleh kasir ke bank untuk dilakukan proses clearing (kliring).
Setelah laporan penarikan dana dibuat, dokumen withdrawal diproses untuk mengurangi saldo Cash Counter dan masuk ke modul FINA Bank Statement untuk dikliring.
Kliring RC Bank (Novi, Juli 2023)
Dana yang sudah disetorkan oleh kasir ke bank akan muncul di dalam R/C akun bank penerimanya, RC Bank tersebut perlu dipindahkan ke sistem dengan kode BTI (Bank Transfer In) oleh admin bank melalui modul FINA Bank Import. Kemudian isi dokumen RC Bank di-posting untuk dikirim ke modul FINA Bank Statement.
RC Bank pada modul FINA Bank Statement dialokasikan dengan dokumen Cash to Bank Disposition untuk dilakukan proses kliring. Hasil dari alokasi selanjutnya di-posting untuk merubah status Disposition menjadi Closed.

Cash to Cash Disposition (Transfer)

Pemindahan Saldo "Cash to Cash" (Novi, Juli 2023)
Kasir dapat melakukan pemindahan saldo (transfer) di Cash Counter mereka. Terdapat 2 fitur yang ada dalam proses transfer, yaitu :
  • Memindahkan saldo antar Cash Counter
  • Merubah alat bayar pada suatu Cash Counter
Setelah pembuatan disposisi selesai, dokumen transfer diproses untuk mencatat operasi direct balance (BALIN dan BALOUT) pada Cash Counter. Pada proses ini terjadi pengecekan apakah kasir memindahan saldo ke Cash Counter lain, atau memindahkan saldo dari Giro/Cheque/Cash BRI Payment Method ke Cash Payment Method pada Cash Counter tersebut.
Pemindahan Saldo Antar Cash Counter (Novi, Juli 2023)
Dokumen ini ditandai dengan Source Cash Counter tidak sama dengan Destination Cash Counter dan Source Payment Method sama dengan Destination Payment Method. Contohnya: Kasir A memindahkan saldo cash ke Kasir B.
Saat dokumen transfer diproses, sistem akan memeriksa apakah dokumen tersebut merupakan pemindahan saldo antar Cash Counter. Jika iya, maka status Disposition berubah menjadi Closed. Kemudian, apabila saldo yang dipindahkan berupa cash, maka sistem langsung mencatat operasi direct balance (BALIN dan BALOUT) pada Cash Counter. Sedangkan pada pemindahan saldo slip (Giro/Cheque/Cash BRI), maka sistem akan merubah Cash Counter pada Slip dan mencatat perubahan saldo dengan tipe Balance In (BALIN) dan Balance Out (BALOUT).
Merubah Alat Bayar di Cash Counter (Novi, Juli 2023)
Perubahan alat bayar dilakukan saat kasir ingin memindahkan saldo slip menjadi cash. Slip tersebut didapatkan dari proses top up slip pada Bank to Cash Disposition. Dokumen ini ditandai dengan Source Cash Counter sama dengan Destination Cash Counter dan Source Payment Method tidak sama dengan Destination Payment Method. Alat bayar yang bisa dirubah yaitu antara Giro/Cheque/Cash BRI Payment Method ke Cash Payment Method pada Cash Counter tersebut.
Saat dokumen transfer diproses, sistem akan memeriksa apakah dokumen tersebut merupakan perubahan alat bayar di Cash Counter. Jika iya, maka status Disposition berubah menjadi Closed dan Payment BGCQ menjadi Disbursed. Saldo pada Cash Counter juga berubah yang dicatat dengan tipe Balance In (BALIN) dan Balance Out (BALOUT).

FINA Down Payment

Down Payment (DP) atau uang muka adalah pembayaran atas tagihan (invoice) supplier sebelum barang atau jasa diterima oleh pembeli. Salah satu fungsi Down Payment adalah untuk mengikat transaksi jual beli.

DP Invoice (Down Payment Invoice)
DP Invoice adalah dokumen untuk mencatat tagihan uang muka yang diterima dari supplier sekaligus berfungsi sebagai permintaan dana ke bagian keuangan untuk membayar tagihan tersebut.
DP Invoice terdiri dari 2 bagian:
  1. Informasi Down Payment
    • Dokumen: Nomor, Tanggal, Referensi Invoice Supplier
    • Sumber Transaksi: Application, Purchasing Org
    • Penyandang dana: Company, Project
    • Employee (Petugas AP): Penanggung Jawab (PIC)
    • Keterangan penggunaan dana
  2. Informasi Installment (rencana pembayaran) dana DP.
    • Nilai DP, PPN, PPH dan dana yang diminta
    • Penerima Dana (PaidToParty/ Supplier)
    • Metode pembayaran (payment method) dan kelengkapannya: Bank Account/ Lokasi Kasir tempat pengambilan dana.
    • Tanggal pembayaran (due date)
Penggunaan DP
Down Payment (DP) digunakan dalam kondisi:
  1. Tagihan (invoice) dari Supplier (penjual atau pemberi jasa) sudah diterima. Gunakan Pre-Payment jika tagihan atau bukti transaksi lainnya belum ada.
  2. Supplier belum menyerahkan barang atau jasa senilai yang ditagihkan. Gunakan A/P Invoice jika barang atau jasa senilai yang ditagihkan sudah diterima.
Biasanya nilai DP lebih kecil atau maksimal sama dengan nilai barang atau jasa yang dibeli. Namun, anomali bisa terjadi saat terjadi pembatalan atau gagal kirim yang mengubah nilai total tagihan.
Penginput DP (Creator, Confirmator)
DP (down payment) diinput ke Fina oleh Employee (karyawan) petugas (admin) pembelian. Petugas (admin) pembelian juga yang akan melakukan konfirmasi DP.
Penanggung DP (Employee Responsible/ PIC)
Employee Responsible (PIC) atau penanggungjawab DP adalah Employee (karyawan) yang bertanggungjawab atas dana DP baik dari sisi penggunaan, pembuktian, maupun penarikan sisa dana jika terjadi.
PIC adalah Employee (karyawan) yang ter-asosiasi dengan User penginput data. Bisa dirinya sendiri, bisa karyawan lain yang diwakilinya.
Penerima Dana DP (Paid to Party)
Dana DP biasanya ditransfer langsung ke rekening bank Supplier atau dapat juga diambil secara tunai (dan setara tunai) oleh Supplier di Cash Counter.
Hanya Supplier yang bisa menjadi penerima dana DP (Paid to Party)
Employee (karyawan) tidak bisa bertindak sebagai penerima dana DP, seandainya Employee bertindak sebagai penalang dana (DP sudah dibayar menggunakan uang pribadi) maka selanjutnya akan memunculkan Installment bertipe Reimburse di AP Invoice.
Workflow DP (Down Payment Workflow)
Alir kerja/ proses (workflow) DP dibagi menjadi 3 tahap yaitu:
  1. Down Payment Creation (Penyusunan DP)
  2. Down Payment Disbursement (Pencairan dana DP)
  3. Down Payment Realization (Realisasi DP)
Alir kerja (worklow) DP meliputi proses-proses langsung pada dokumen Invoice DP dan juga proses-proses pada dokumen-dokumen terkait lainnya, terutama::
  • Installment (rencana pembayaran)
  • Payment Requisition (pesanan dana)
  • Slip (slip pembayaran)
  • Cash Payment (pembayaran tunai/ setara tunai)
  • Bank Payment (bank transfer)
  • A/P Invoice (tagihan dari penjual)
Worklow DP akan mengubah status (workstate) dokumen DP Invoice. Diagram workstate menunjukkan perjalanan status DP Invoice mulai dari New sampai selesai (final) dengan workstate Void, atau Closed.

Down Payment Creation (Penyusunan DP)

Workflow penyusunan DP (Down Payment Creation) mencakup proses penyusunan DP sampai menghasilkan Payment Requisition (pesanan dana) yang mengalir ke proses pembayaran.

Input dan Konfirmasi DP
Tagihan Down Payment yang diterima dari Supplier penjual atau pemberi jasa diinput ke Fina oleh petugas (Admin) menggunakan modul DP Invoice.
DP Invoice yang baru diinput akan mendapat nomor urut dari sistem (internal numbering). Status (workstate) nya New. DP Invoice dengan workstate New bisa di edit berulangkali. DP juga dapat dihapus atau di-Void.
Setelah proses input selesai, DP Invoice dikonfirmasi (confirm) oleh petugas sehingga statusnya berubah menjadi Confirmed. Pada status tersebut edit sudah tidak dapat dilakukan lagi.
Daftar DP, Detail DP
Seluruh document DP yang diinput ke Fina akan masuk ke dalam daftar DP (Down Payment List). Berbagai status (workstate) DP dapat dikenali dengan kode warna yang berbeda-beda. Tersedia fasilitas pencarian dan filter-filter untuk memudahkan pemantauan DP.
Layar detail DP menyajikan informasi detail dan menu terkait DP tertentu:
  • Informasi dokumen DP
  • Informasi saldo (sisa dana) DP yang belum dipertanggungjawabkan (invoiced)
  • History pemrosesan DP
  • Menu-menu pemrosesan dokumen DP (edit, delete, confirm, print, dll)

Down Payment Disbursement (Pencairan Dana DP)

Pencairan dana DP dimulai saat Payment Requisition (pesanan dana) dari DP mengalir ke bagian keuangan sampai dana dibayarkan melalui transfer bank atau kasir.

Saat DP terkonfirmasi (Confirmed) maka secara otomatis sistem akan menghasilkan (generate) 1 Installment baru bertipe DP dengan status (workstate) New.
Installment DP akan terdaftar bersama dengan instalment-installment lain di modul Fina Installment. Menggunakan fasilitas di modul tersebut, installment-installment yang sejenis dan bertanggal bayar sama akan digabungkan menjadi Payment Requisition (PD)
Paymment Requisition (PD) yang memuat installment DP itulah yang selanjutnya diproses pembayarannya. Dokumen DP Invoice (DP) akan berubah statusnya saat menerima sinyal notifikasi dari proses Payment Requisition Disbursement, yaitu:
  • Saat pembayaran sudah siap, status DP akan berubah menjadi Payment Ready
  • Saat pembayaran sudah dilakukan, status DP akan berubah menjadi Paid, pelacakan saldo (balance-tracking) DP dimulai.
Penjelasan tentang proses Down Payment Disbursement (pembayaran DP) yang lebih rinci dapat dilihat dalam penjelasan proses Payment Requisition Disbursement karena di proses itulah pembayaran DP sebenarnya dilakukan.

Down Payment Closing (Penyelesaian DP)

Sampai 21 Agustus 2022 masih belum dijelaskan skenario closing DP, pengembalian sisa dana karena perubahan nilai total invoice, apakah Paid-to-Party Employee diijinkan

FINA Pre-Payment

Pre-Payment atau (BS/ Bon Sementara/ Kas Bon) adalah permintaan dana untuk membayar transaksi yang belum terjadi sehingga belum tersedia bukti transaksi dari penjual/ pemberi jasa.

Dokumen/ Form BS (Pre-Payment Document)
Dokumen/ Form BS adalah dokumen untuk meminta dana BS, dibuat oleh Employee (karyawan), ditujukan ke atasannya. Dokumen BS terdiri dari 2 bagian:
  1. Informasi Pre-Payment
    • Dokumen: Pre-Payment Type (jenis BS), nomor, tanggal
    • Penyandang dana: Company, Project
    • Employee (karyawan): Penyunting Dokumen (creator), Peminta Dana (requestor), Penanggung Jawab (PIC)
    • Keterangan penggunaan dana
  2. Informasi Installment (rencana pembayaran) dana BS.
    • Jumlah dana yang diminta (amount)
    • Penerima Dana (PaidToParty)
    • Metode pembayaran (payment method) dan kelengkapannya: Bank Account/ Lokasi Kasir tempat pengambilan dana.
    • Tanggal pembayaran (due date)
Peminta Dana BS (Requestor)
Peminta dana BS (Requestor) adalah Employee (karyawan) yang karena jabatan/ perannya berhak mengajukan permintaan dana BS untuk berbagai kepentingan. Hak tersebut diatur dari layar "Employee".
User (pengguna) yang menginput BS ke Fina belum tentu adalah karyawan peminta dana BS itu sendiri. Contoh: Agus Ramdhani adalah peminta dana (requestor), BS nya dibuat oleh Rica sekretarisnya (creator). Dalam hal ini Rica mewakili dan bertindak sebagai Agus Ramdhani dalam membuat BS. Mekanisme "bertindak sebagai" (association) dapat diatur dari layar "Employee" untuk kelancaran proses sekaligus membatasi hak dan tanggungjawab nya.
Penerima Dana BS (Paid to Party)
Ada 4 pihak yang bisa menjadi penerima dana BS (Paid to Party) yaitu:
  1. Supplier
  2. Customer
  3. Employee untuk dinas luar (DLK/DLN), penggantian talangan dana (reimburse), dll.
  4. Organization untuk pemindahan dana (KM) antar organisasi di dalam KG Media.
Dana BS bisa diambil langsung di Cash Counter, bisa diterima melalui Bank Account (rekening bank) penerima dana. Dari 4 pihak di atas hanya Employee (karyawan) yang dapat sekaligus bertindak sebagai penanggungjawab.
Penanggung BS (Employee Responsible/ PIC)
Employee Responsible (PIC) atau penanggungjawab BS adalah Employee (karyawan) yang bertanggungjawab atas dana BS baik dari sisi penggunaan, pembuktian, maupun pengembalian sisa dana.
Penanggungjawab BS adalah salah satu dari:
  1. Peminta Dana (Requestor), misalnya untuk BS yang dibayarkan kepada pihak luar perusahaan (supplier/ customer).
  2. Penerima Dana (Paid to Party), misalnya: BS untuk dinas luar, penerima dana adalah karyawan yang berdinas, karyawan tersebut juga yang menjadi penanggungjawab BS.
Otorisator BS (Approver)
Otorisator BS (approver) adalah atasan (superior) peminta dana (requestor) berdasarkan Approval Hierarchy (hirarki otorisasi) yang melekat pada Company peminta dana.
Approval Hirarchy adalah hirarki atasan-bawahan tanpa memperhatikan asal organisasinya. Hirarki ini memungkinkan otorisator (approver) berasal dari Company yang berbeda dengan peminta dana (requestor). Sangat cocok diterapkan di lingkungan KG Media yang multi-company, terutama untuk otorisasi dokumen internal.
Jenis-Jenis BS (Pre-Payment Types)
Ada beberapa Pre-Payment Type (jenis BS) yaitu: BS Standar, BS Dinas Luar, BS Proyek, dll. Fungsinya untuk mengatur:
  • Siapa penanggung jawab BS: Peminta Dana (Requstor) atau Penerima Dana (PaidToParty)
  • Isian-isian dokumen/ form BS yang wajib diisi
Jenis BS tidak dapat digunakan untuk mengatur penggunaan dana BS karena penggunaan dana baru terealisasi setelah Invoice A/P diterbitkan saat BS dipertanggungjawabkan.

Ada praktik di mana satu BS dapat digunakan untuk pembelanjaan multi cost-center. Hal ini menyebabkan informasi Budget dan Cost Center tidak dapat dilekatkan secara langsung ke dokumen Pre-Payment (BS).

Workflow BS (Pre-Payment Workflow)
Alir kerja/ proses (workflow) BS dibagi menjadi 3 tahap yaitu:
  1. Pre-Payment Submission (Pengajuan BS)
  2. Pre-Payment Disbursement (Pencairan dana BS)
  3. Pre-Payment Realization (Penyelesaian BS)
Alir kerja (worklow) BS meliputi proses-proses langsung pada dokumen/ form BS dan juga proses-proses pada dokumen-dokumen terkait, terutama:
  • Installment (rencana pembayaran)
  • Payment Requisition (pesanan dana)
  • Slip (slip pembayaran)
  • Cash Payment (pembayaran tunai/ setara tunai)
  • Bank Payment (bank transfer)
  • A/P Invoice (tagihan dari penjual)
Worklow BS akan mengubah status (workstate) dokumen/ form BS. Diagram workstate menunjukkan perjalanan status Pre-Payment mulai dari New sampai selesai. Ada 3 status (workstate) yang menyatakan BS sudah selesai yaitu:
  1. Declined (ditolak). Lihat Pre-Payment Submission.
  2. Void (dibatalkan). Lihat Pre-Payment Cancellation.
  3. Closed (ditutup). Lihat Pre-Payment Realization.

Pre-Payment Submission (Pengajuan BS)

Workflow pengajuan BS (pre-payment submission) mencakup proses pembuatan BS, iterasi persetujuan BS, sampai BS menghasilkan Payment Requisition (pesanan dana) yang mengalir ke proses pembayaran.

Proses pembuatan dan pengajuan BS (Pre-Payment Submission) didesain sebagai proses yang online, paperless (19 April 2021)

Dalam penjelasan-penjelasan berikutnya (mulai Maret 2022) BS perlu tanda tangan basah sehingga hanya perlu proses input.

IT memutuskan, workflow otorisasi BS yang sudah ada tidak perlu dicabut, workflow bisa di bypass jika tidak dikehendaki. "Send" dari penginput BS = "approve" atau diimplementasikan seperti GMMS di Grid.

Persetujuan via email Call to Action (CTA) akan ditambahkan jika tetap dibutuhkan.

Pembuatan/ Pengisian BS
Dokumen Pre-Payment (Form BS) seharusnya diinput sendiri ke Fina oleh Employee peminta dana (Requestor). Namun dalam kasus khusus (khusus tapi banyak), input Pre-Payment (BS) dilakukan oleh sekretaris atau sekretariat unit mewakili peminta dana.
Berkas Pre-Payment (BS) baru akan mendapat tanda (workstate) New, BS bisa diedit berkali-kali sebelum dikirimkan untuk mendapat persetujuan dari atasan peminta dana. BS juga dapat dihapus atau di-Void.
Setelah proses input selesai, dokumen Pre-Payment (BS) dikirimkan kepada atasan peminta dana untuk mendapat persetujuan. Setelah dikirimkan status dokumen Pre-Payment (BS) akan berubah menjadi Need Approval, edit sudah tidak dapat dilakukan lagi.
Approval BS
Atasan peminta dana (approver) menerima BS dengan status (workstate) Need Approval. Kelengkapan isi dan jumlah uang yang diminta dapat diperiksa sebelum menentukan persetujuannya. Ada 3 opsi persetujuan/ tindakan:
  1. Approve (setujui). Status BS akan berubah menjadi Approved. System secara otomatis akan membuat Payment Requisition (PD/ Pesanan Dana) baru dengan nomor yang sama dengan BS yang di-approve.
  2. Decline (tolak). Status BS akan berubah menjadi Declined, BS tidak diproses lebih lanjut.
  3. Send Back (minta direvisi). Status BS akan berubah menjadi Need Revision. Proses selanjutnya BS direvisi dan dikirim ulang oleh peminta dana.
Daftar BS, Detail BS
Seluruh document BS yang diinput ke Fina akan masuk ke dalam daftar BS (Pre-Payment List). Berbagai status (workstate) BS dapat dikenali dengan kode warna yang berbeda-beda. Tersedia fasilitas pencarian dan filter-filter untuk memudahkan pemantauan BS.
Layar detail BS menyajikan informasi detail dan menu terkait BS tertentu:
  • Informasi dokumen BS
  • Informasi saldo (sisa dana) BS yang belum dipertanggungjawabkan (invoiced)
  • History pemrosesan BS
  • Menu-menu pemrosesan dokumen BS (edit, delete, send, send=back, approve, decline, print, dll)

Pre-Payment Disbursement (Pencairan Dana BS)

Pencairan dana BS dimulai saat Payment Requisition (pesanan dana) dari BS mengalir ke bagian keuangan sampai dana dibayarkan melalui transfer bank atau kasir.

Saat BS disetujui (Approved) maka secara otomatis sistem akan menghasilkan (generate) 2 entitas yang berperan penting dalam pencairan dana BS tersebut, yaitu:
  1. Installment (rencana pembayaran), 1 BS akan menghasilkan 1 installment bertipe BS.
  2. Payment Requisition (pesanan dana/ PD), 1 BS yang disetujui akan menghasilkan 1 PD dengan nomor yang sama dengan nomor BS nya.
Pre-Payment (BS), Installment, dan Payment Requisition (PD) yang dihasilkan langsung melekat satu sama lain sehingga mem-by-pass proses penggabungan di modul "Installment".
(Lihat kesepakatan tgl 17 Mei 2022)
Paymment Requisition (PD) dari BS itulah yang selanjutnya diproses pembayarannya. Dokumen Pre-Payment (BS) akan berubah statusnya saat menerima sinyal notifikasi dari proses Payment Requisition Disbursement, yaitu:
  • Saat pembayaran sudah siap, status BS akan berubah menjadi Payment Ready
  • Saat pembayaran sudah dilakukan, status BS akan berubah menjadi Paid, pelacakan saldo (balance-tracking) BS dimulai.

Penjelasan tentang proses Pre-Payment Disbursement (pembayaran BS) yang lebih rinci dapat dilihat dalam penjelasan proses Payment Requisition Disbursement karena di proses itulah pembayaran BS sebenarnya dilakukan.

Pre-Payment Realization (Penyelesaian/ Closing BS)

Penyelesaian BS mencakup proses membuktikan, mempertanggungjawabkan penggunaan dana BS, dan menutup dokumen BS.

Langkah-Langkah Penyelesaian BS
Langkah-langkah Pre-Payment Realization/ Penyelesaian BS:
  1. Menginput bukti transaksi penggunaan dana BS
  2. Menyusun satu atau beberapa dokumen A/P Invoice dan mengalokasikan nilai BS ke invoice-invoice tersebut.
  3. Jika dana BS kurang (BS < Invoice), maka kekurangan dana di input sebagai installment baru
  4. Jika dana BS lebih (BS > Invoice), maka kelebihan dana dapat ditransfer ke rekening bank perusahaan, atau dapat diserahkan secara tunai ke kasir.
  5. Menyerahkan A/P Invoice, form Pre-Payment, bukti-bukti transaksi, tanda terima pengembalian dana (jika ada) ke kasir
  6. Berdasarkan dokumen dan bukti transaksi yang diterima, kasir menyusun dokumen Realization.
  7. Dokumen Realisasi di validasi oleh Kasir, yang sekaligus menutup BS.
Mencatat Bukti Transaksi Penggunaan Dana BS
Penerima dana BS wajib mengumpulkan bukti-bukti transaksi (proofs, evidences) penggunaan dana BS yang asli karena dibutuhkan pada saat penyelesaian BS.
Bukti-bukti transaksi tersebut diinput ke Fina menggunakan modul Receiving, atau dapat juga diinput sebagai item menggunakan modul A/P Invoice.
Modul Receiving disediakan agar pengguna dana BS dapat menyusun daftar pembelian yang telah dilakukan sehingga memudahkan proses penyelesaian BS sekaligus mengurangi "catatan-catatan pinggir" di Excel atau lainnya.
Dokumen Receiving yang sudah dibuat bisa dipanggil (Load) saat menyusun A/P Invoice.
Menghubungkan BS dengan A/P Invoice
Pre-Payment (BS) dipertanggungjawabkan dengan cara menghubungkan BS dengan dokumen A/P Invoice yang memuat daftar item barang atau jasa yang dibayar menggunakan dana BS tersebut.
Jika dilihat dari sisi A/P Invoice, Pre-Payment (BS) adalah Installment yang sudah dibayar sehingga mengurangi jumlah uang yang harus dibayarkan untuk invoice tersebut.
Dana dari satu Pre-Payment (BS) dapat digunakan untuk membayar satu atau beberapa A/P Invoice. Satu A/P Invoice bisa dibayar menggunakan dana dari satu atau beberapa Pre-Payment (BS) → many-to-many.
Kekurangan Dana BS
Saat penyusunan dokumen A/P Invoice, jika nilai invoice lebih besar dari dana BS yang dialokasikan ke invoice tersebut, maka kekurangannya dijadikan Installment baru sehingga invoice akan terbayar penuh. Jenis Installment baru tersebut bisa:
  • Regular Installment jika kekurangan dana harus dibayarkan ke Supplier atau yang mewakili (agen, dll)
  • Reimburse Installment jika kekurangan dana sudah ditutup (ditalangi) menggunakan dana pribadi Employee (karyawan)
Kekurangan dana BS dalam bentuk Installment baru tersebut selanjutnya akan dibayar dalam proses Payment Requisition Disbursement.
Kelebihan (Sisa) Dana BS
Jika nilai BS lebih besar dari nilai yang dialokasikan ke satu atau beberapa A/P Invoice, maka ada sisa dana BS yang harus dikembalikan ke perusahaan.
Pengembalian dana dapat dilakukan sebelum atau bersamaan dengan proses Pre-Payment Realization (Penyelesaian BS). Metode pengembalian:
  • Transfer ke Bank Account (rekening bank) perusahaan. Dana yang masuk akan muncul dalam Bank Statement dan akan dialokasi sebagai Receipt Employee.
  • Setor secara tunai (atau setara tunai) ke Cashier di Cash Counter yang ditunjuk. Dana tunai akan dicatat sebagai Receipt Employee.
Bukti transfer atau tanda terima tunai Receipt dari kasir disimpan untuk di realisasi kan di kasir.
Realization dan Closing BS
Proses terakhir penyelesaian BS adalah menyerahkan berkas-berkas ke Cashier di Cash Counter khusus penyelesaian BS untuk di-validasi. Berkas-berkas tersebut:
  • Pre-Payment
  • A/P Invoice termasuk Installment kekurangan dana BS jika ada
  • Cash Receipt atau Bank Allocation jika ada sisa dana
  • Bukti-bukti transaksi sesuai item-item yang tercantum dalam A/P Invoice
Cashier kemudian menyusun Realization berdasarkan berkas-berkas yang diterimanya menggunakan layar Fina Realization.
Pada dasarnya Realization adalah pengikat dokumen BS dengan kelengkapannya menjadi satu kesatuan
Setelah informasi dalam Realization lengkap dan cocok, kasir kemudian memberi tanda validasi pada Realization yang sekaligus akan mengubah status (workstate) BS menjadi Closed.

Hanya Cash Counter tertentu saja yang dapat melayani proses penyelesaian BS. Cash Counter tersebut memiliki penanda (flag) Pre-Payment di layar pengaturan Cash Counter.

Pre-Payment Cancellation (Pembatalan BS)

No. Kondisi Workstate Awal Action Workstate Akhir
1. BS baru belum dikirimkan untuk mendapat persetujuan, ingin dibatalkan New Hapus BS Void
2. BS sudah dikirimkan, sedang menunggu persetujuan, ingin dibatalkan Need Approval ? ?
3. BS sudah dikirimkan, sedang dalam proses revisi, ingin dibatalkan Need Revision Hapus BS Void
4. BS sudah disetujui, pembayaran belum siap, ingin dibatalkan Approved ? ?
5. BS sudah disetujui, pembayaran sudah siap, ingin dibatalkan Payment Ready ? ?

Part ini sudah sempat disinggung dalam rapat tanggal 14 April 2021, masih dipikirkan flow nya oleh FSD

Pre-Payment Journal (Jurnal BS)

No. Transaksi/ Proses COA Debit COA Credit
1. Dana BS ditransfer ke rekening bank ? ?
2. Giro/ Cheque diserahkan ke Cash Counter ? ?
3. Giro/ Cheque diserahkan ke penerima dana ? ?
4. ? ? ?

Part ini sudah disepakati dalam rapat tanggal 14 April 2021, akan didokumentasikan di sini oleh FSD

FINA Receiving

Receiving adalah catatan penerimaan barang (goods) atau jasa (services) dari Supplier (penjual atau pemberi jasa) oleh penerima barang atau jasa. Receiving disusun berdasarkan checklist dokumen pengiriman (DO/ SN), faktur pembelian, atau tanda terima pembayaran dari supplier.

Good Receipt (GR) vs Receiving
Good Receipt (GR) adalah dokumen penerimaan barang/ jasa yang melekat di sistem pengadaan/ pembelian (Procurement System/ Purchasing System/ Operation) sedangkan Receiving adalah dokumen sejenis yang dikelola oleh Fina sebagai sistem keuangan (Finance System). Ada beberapa perbedaan antara Good Recipt/ GR dengan Receiving:

 

[GMMS] Good Receipt [FINA] Receiving
Bagian dari sistem pengadaan Bagian dari sistem keuangan
Data diinput oleh petugas gudang atau penerima barang/ jasa Data diimpor dari sistem pengadaan, atau diinput langsung jika tidak ada sistem pengadaan.
Definisi produk berorientasi pada kepentingan pengadaan, komunikasi dengan supplier, dan penyimpanan: Spidol Snowman Hitam, Notebook Lenovo ThinkPad X1 Carbon Definisi produk berorientasi pada kepentingan penjurnalan akuntansi: Alat Tulis Kantor, Alat Kerja: Notebook
Sumber Data Receiving
Sumber data Receiving diinput dari berbagai cara yaitu: input langsung di FINA melalui modul Receiving atau input dari invoice A/P yang diimport dari bagian pengadaan barang ke FINA dengan reference NO yang ada.
Dokumen Receiving (Receiving Document)
Informasi dalam dokumen Receiving
  • Dokumen: Receiving nomor, tanggal, Ref PO dan Ref GR
  • Source Aplikasi: GMMS, FINA, dll
  • Pengirim barang (receive from): Customer, Organization,Supplier
  • Employee (karyawan): Penyunting Dokumen (creator), Pemerima barang (received by), Penanggung Jawab (PIC)
  • Amounts: Gross, Discount, Surcharge, Net Tax Free, Net Tax Chargeable, VAT, Netto, Income Tax
  • Items/barang: Received Product, Katagori, Kuantiti, Harga
  • Informasi proses/workstate.
Product Mapping
Product Mapping adalah suatu pemetaan product menggunakan bahasa yang ada di FINA untuk mengenali jenis barang yang sesuai dengan kegunaannya.
Product Mapping dalam Receiving dibagi menjadi 3:
  • Purchased Product: Purchased Product adalah product yang dibeli oleh bagian pembelian seperti contoh pembelian Laptop merek Lenovo Thinkpad tipe E14, pembelian batu baterai ABC tipe AA, atau pembelian alat pel Merk NAGOYA
  • Product Catagory: Product Catagory adalah pengkategorian product yang dipetakan oleh bagian pembelian berdasarkan jenis barang, contoh: Laptop Lenovo Thinkpad tipe E14 adalah Perlengkapan Komputer, Batu Baterai ABC dikatagorikan sebagai Stationary
  • Product Usage: Product Usage adalah product yang dipetakan oleh bagian keuangan berdasarkan kegunaannya seperti contoh pembelian laptop serta pembelian batu baterai pada purchased product dikatagorikan sebagai alat kerja kantor, kemudian pembelian alat pel dikatagorikan sebagai kebersihan.
Amount Calculation
Ada banyak angka dan perhitungan dalam dokumen Receiving, angka-angka (amounts) tersebut antara lain:
  • Cost adalah biaya yang dikeluarkan untuk membayar suatu barang atau jasa yang diterima.
  • Gross 1 atau Gross VAT Free dalam Receiving berarti jumlah harga yang harus dibayarkan kepada Supplier dengan jumlah kotor atausebelum dikenakan VAT (PPN), dalam Nilai Gross 1 diberikan penanda bahwa nilai tersebut VAT free yang artinya tidak ditambahkan biaya pajak, namun bisa jadi ditambahkan biaya lain-lain seperti ongkos kirim dan hal diluar pengiriman barang.
  • Gross 2 atau Gross VAT Chargeable berarti jumlah harga kotor yang harus dibayarkan setelah dikenakan VAT-nya.
  • Discount adalah Potongan harga yang diberikan oleh Supplier pada saat atau setelah terjadi transaksi dan biasanya muncul saat terjadi tawar menawar harga dengan alasan kedekatan personal, volume pembelian, atau jenis barang maupun jasa.
  • Surcharge adalah harga tambahan yang dibebankan kepada pembeli/penerima di luar harga barang atau jasa yang dibeli.
  • Net VAT Free adalah Jumlah harga pasti yang harus dibayarkan sebelum dikenakan VAT (PPN) dan sesudah dikenakan discount dan surcharge.
  • Rumus Net VAT Free adalah: Gross VAT Free - (Gross VAT Free * Discount Percentage) + (Gross VAT Free * Surcharge Percentage)
  • Net VAT Chargeable adalah harga pasti yang diberikan supplier untuk barang yang dibeli sesudah dikenakan VAT (PPN), discount dan surcharge.
  • Rumus Net VAT Chargeable adalah: Gross VAT Chargeable - (Gross VAT Chargeable * Discount Percentage) + (Gross VAT Chargeable * Surcharge Percentage)
  • VAT atau PPN adalah pungutan pajak yang dibebankan atas transaksi jual-beli barang atau jasa kena pajak yang dilakukan oleh Wajib Pajak Pribadi maupun Wajib Pajak Badan yang telah dikukuhkan sebagai Pengusaha Kena Pajak (PKP).
  • Netto adalah Jumlah harga pasti yang harus dibayarkan sebelum dikurangi income tax.
  • Rumus Netto pada Receiving adalah: Net VAT Free + Net VAT Chargeable + VAT
  • Income Tax adalah pajak penghasilan, pajak ini dibebankan atas suatu penghasilan yang diterima oleh Wajib Pajak, baik yang berasal dari Indonesia maupun dari luar negeri. Penghasilan yang dimaksud meliputi usaha, gaji, hadiah, honorarium, dan lain sebagainya.
  • Paid amount adalah Jumlah harga pasti yang harus dibayarkan setelah dikurangi income tax.
  • Rumus Paid Amount adalah: Netto - Income Tax
Penerima Barang
Penerima Barang adalah seseorang yang bertugas menerima barang (received) dari pengirim. Yang bertugas menerima barang ialah Employee/petugas penerimaan barang atau PIC dari barang tersebut.
Pengirim Barang (Supplier)
Pengirim Barang ialah ia yang bertugas mengirimkan barang (shipped) kepada penerima barang, dalam contoh kasus di FINA pengirim barang ialah supplier dan penerima barang ialah Employee yang bertugas di bagian penerimaan barang.
Workflow Receiving
Alir kerja/ proses (workflow) Receiving terbagi menjadi 3 proses, yaitu:
  1. Receiving Registration (Regristrasi Receiving)
  2. Receiving Confirmation (Konfirmasi Receiving)
  3. Receiving Invoicing (Penagihan Receiving)
Worklow Receiving akan mengubah status (workstate) dokumen/ form Receiving. Diagram workstate menunjukkan perjalanan status Receiving mulai dari New sampai selesai (final) dengan workstate Void atau Invoiced. Garis berwarna biru menunjukkan proses maju, sedangkan garis berwarna hijau menunjukkan proses pembatalan.
Receiving Registration
Receiving Registration atau Registrasi Penerimaan adalah proses pertama dari pembuatan Receiving di FINA dengan meng-create new Receiving maka nantinya akan terbentuk satu dokumen Receiving baru. Receiving yang diterima dari Supplier (penjual atau pemberi jasa) tersebut diinput ke FINA oleh petugas penerima barang menggunakan modul Receiving.
Receiving yang baru diinput akan mendapat nomor urut dari sistem (internal numbering). Status (workstate)nya New. Receiving dengan workstate New bisa diedit berulangkali. Receiving juga dapat dihapus atau di-Void.
Receiving Confirmation
Setelah dilakukannya registrasi dokumen baru Receiving, dilakukan proses konfirmasi dokumen/ confirmation Receiving yang dilakukan oleh petugas pembelian barang atau petugas penerimaan barang yang. Confirmation Receiving dilakukan untuk mengkonfirmasi kembali pembelian atau penerimaan barang agar tidak terjadi kekeliruan sebelum dilakukannya proses selanjutnya. Pada status tersebut proses edit dan delete/void sudah tidak dapat dilakukan lagi.
Post A/P Invoice
Posting A/P Invoice tanpa loading Receiving akan menghasilkan receiving baru dengan status workstate-nya invoiced.
Realisasi Receiving di A/P Invoice
Realisasi Receiving pada A/P Invoice dimulai pada saat Receiving Confirmation mengalir ke A/P Invoice. Saat Receiving terkonfirmasi (confirmed) maka selanjutnya ialah dilakukan proses post invoice yang dilakukan di A/P Invoice. Receiving yang sudah dikonfirmasi (confirm) oleh petugas bisa diload oleh petugas AP melalui modul A/P Invoice. Petugas memasukkan no receiving dalam kolom GR dan melakukan load data.
Saat AP Invoice di-post akan muncul signal bahwa posting A/P sudah dilakukan, kemudian signal tersebut diterima oleh Receiving dan workstate receiving otomatis berubah menjadi invoiced.

FINA Payment Requisition

Payment Requisition (Pesanan Dana/ PD) terbentuk dari Installment yang dihasilkan dari proses approval Pre-Payment (Bon Sementara/ BS) dan proses approval A/P Invoice. Pesanan dana menjadi dasar eksekusi pembayaran oleh bagian keuangan kepada pihak yang ditunjuk baik melalui bank maupun kasir.

Installment (Item Pesanan Dana)

Installment = item Pesanan Dana
Pada prinsipnya seluruh permintaan dana harus dituangkan ke dalam dokumen/ form Payment Requisition (Pesanan Dana/ PD). Permintaan dana berasal dari:
  1. Pre Payment (Bon Sementara/ BS). Satu BS akan memunculkan satu permintaan dana.
  2. AP Invoice (Tagihan dari penjual barang/ pemberi jasa). Satu tagihan akan memunculkan satu atau beberapa permintaan dana, misalnya dalam kasus pembayaran termin.
Permintaan dana dari kedua entitas tersebut di atas langsung dituangkan menjadi dokumen/ form Payment Requisition (Pesanan Dana/ PD). Prinsip ini sudah lama menjadi SOP di KG Media. Lalu mengapa perlu ada Installment?
Installment muncul karena ada kebutuhan untuk menggabungkan beberapa permintaan dana yang memenuhi kriteria kesamaan tertentu menjadi satu dokumen Pesanan Dana . Agar dapat digabungkan, permintaan-permintaan dana dari BS dan AP Invoice tidak langsung menjadi PD tapi menjadi "Item PD" yang di Fina disebut Installment.
Dari penjelasan di atas, Pre-Payment dan AP Invoice akan menghasilkan Installment saat di-approve. Installment tidak bisa diinput secara manual. Workstate awal saat Installment dihasilkan adalah New.
Installment Verification
Proses verifikasi memastikan bahwa seluruh informasi di dalam Installment sudah benar dan lengkap. Ada beberapa informasi yang dapat diubah atau ditambahkan yaitu:
  • Metode pembayaran (payment method)
  • Bank Account tujuan pembayaran
  • Cash Counter tempat pencairan dana kas
  • Tanggal pembayaran akan dilakukan (installment due date)
Workstate Verified dapat disematkan pada Installment yang sudah diverifikasi agar terpisah dari Installment yang belum (masih harus) diverifikasi.
Installment Grouping
Beberapa Installment yang memenuhi kriteria kesamaan tertentu dapat diproses menjadi satu dokumen Payment Requisition (Pesanan Dana/ PD). Kriteria kesamaan tersebut:
  • Pihak penerima pembayaran (Paid to Party) sama
  • Company sama
  • Metode Pembayaran (Payment Method) sama
  • Tanggal jatuh tempo pembayaran (due date) sama
  • Bank Account sama atau Cash Counter tempat pencairan dana sama
Workstate Installment akan berubah menjadi Processed setelah diproses menjadi Payment Requisition. Di workstate tersebut Installment dan Payment Requisition yang dihasilkan sudah tidak dapat diubah lagi isinya.

Payment Requisition (Group of Installments)

Payment Requisition Creation (pembuatan PD)

Payment Requisition Disbursement (pencairan dana PD)

FINA A/P Invoice

FINA Voucher (Bukti Kas/ Bank)

Voucher Types
Semua transaksi yang menyebabkan pergerakan jumlah uang di Cash Counter dan di Bank Account harus dinyatakan dengan dokumen finansial yang disebut Voucher (Bukti Kas/ Bukti Bank)
Ada 4 jenis Voucher yaitu:
  1. Cash Receipt Voucher atau Bukti Kas Masuk
  2. Cash Payment Voucher atau Bukti Kas Keluar
  3. Bank Receipt Voucher atau Bukti Bank Masuk
  4. Bank Payment Voucher atau Bukti Bank Keluar
Di Fina keempat jenis tersebut dikelola dari Voucher.
Pembuatan Voucher
Voucher dihasilkan (generated) dari posting transaksi di modul Kasir dan Modul Bank. Setiap transaksi Cash akan menghasilkan Cash Voucher, bisa Receipt, bisa Payment tergantung jenis transaksinya. Demikian juga setiap baris di Bank Statement akan menghasilkan Bank Voucher, bisa Receipt, bisa Payment tergantung jenis transaksinya.
Baris-baris alokasi penerimaan pembayaran dapat digabungkan menjadi satu Bukti Kas jika:
  • Berasal dari Application (sistem sumber) yang sama
  • Diterima oleh Bank Account atau Cash Counter yang sama
  • Ditujukan kepada SalesOrg yang sama
  • Berasal dari Allocation Transaction Type yang sama
  • Posting date sama
Masih perlu penjelasan lebih rinci tentang bukti kas:
  • Transaksi-transaksi Bukti Kas datang dari proses apa saja (4 April 2021)
  • Bukti Kas terkait pembatalan BS (13 April 2021)
  • Conflict Rule: Pembuatan Bukti Kas saat posting Kasir dan Bank vs Pengelompokan Bukti Kas (19 April 2021)

FINA Account Receivable (A/R)

A/R Subsystem

Account Receivable (A/R) atau disebut "Piutang" adalah catatan tentang tagihan kepada pihak tertagih karena transaksi penjualan atau lainnya yang belum dibayar. Di dalam akuntansi, piutang tercantum di dalam Neraca (Balance Sheet) di sisi Aktiva (asset).
A/R mencatat 3 entitas yang mempengaruhi nilai tagihan, yaitu:
  1. Tagihan (Invoice/ Billing) termasuk koreksi/ pembatalan nya
  2. Penerimaan Pembayaran (Receipt) termasuk koreksi/ pembatalan nya
  3. Koreksi saldo tagihan (Memo)
Di subsistem FINA A/R ketiga entitas di atas disebut A/R Invoice, A/R Receipt, dan A/R Memo. Selain tiga entitas itu ada juga entitas A/R untuk melacak sisa saldo tagihan (receivable balance).
Processing Method
FINA mendukung 2 metode pencatatan A/R
  1. Balance Forward yaitu metode pelacakan (tracking) berdasarkan pihak (Party) yang ditagih. Metode pencatatan ini digunakan oleh sistem-sistem berbasis langganan seperti SPSK, dll.
  2. Open Item yaitu metode pelacakan (tracking) berdasarkan dokumen tagihan (Invoice/ Billing). Metode pencatatan ini digunakan oleh sistem penjualan non-langganan seperti FastKom, AMS, dll.
A/R Invoice
A/R Invoice adalah tabel untuk mencatat tagihan, koreksi tagihan, pembatalan tagihan. Semua tagihan yang akan dilacak oleh FINA A/R harus dimasukkan ke dalam tabel ini.
A/R Receipt
A/R Receipt adalah tabel untuk mencatat penerimaan pembayaran (Receipt), koreksi receipt, pembatalan receipt. Semua penerimaan pembayaran yang akan dilacak oleh FINA A/R harus dimasukkan ke dalam tabel ini.
A/R Memo
A/R Memo adalah tabel untuk mencatat memo-memo koreksi pada saldo tagihan. Semua koreksi yang akan dilacak oleh FINA A/R harus dimasukkan ke dalam tabel ini.
CodeFlowNameDescription
ARIInvoiceDebitInvoice tagihan biasa
ARIDPInvoice DPDebitInvoice yang dibuat sebelum barang/ jasa diserahkan (unearned). Fungsi ini sebagai pengikat "down payment", di mana pihak tertagih menginginkan faktur pajak.
ARITURInvoice TurunanDebitInvoice yang dibuat sebagai turunan dari Invoice DP setelah produk atau jasa diserahkan (sebagian/ seluruhnya)
ARCICredit InvoiceCreditCredit Invoice tagihan biasa
ARCIDPCredit Invoice DPCreditPembatalan sebagian atau seluruh Invoice DP
ARCITURCredit Invoice TurunanCreditPembatalan sebagian atau seluruh Invoice Turunan
ARRCPReceiptCreditPenerimaan Pembayaran
ARRCPDPReceipt DPCreditPenerimaan Pembayaran sebagai DP di mana invoice belum diterbitkan.
ARRRCPReversed ReceiptDebitPembatalan sebagaian atau seluruh pembayaran.
ARCMCredit MemoCreditKoreksi kredit pada saldo tagihan, sehingga saldo tagihan berkurang.
CRDMDebit MemoDebitKoreksi debit pada saldo tagihan, sehingga saldo tagihan bertambah.
A/R Tracking
Baris-baris transaksi dari table A/R Invoice, table A/R Receipt, dan tabel A/R Memo akan di-posting masuk ke table A/R untuk dilacak saldo akhir piutangnya.
Setiap entry dalam tabel A/R membawa informasi jenis transaksi A/R seperti (lihat tabel). Nilai (amount) dalam transaksi akan mengisi sisi Debit atau Credit sesuai dengan jenis transaksinya.
Ketika selisih Debit dan Credit sudah 0 (nol) maka dikatakan tagihan piutang sudah lunas terbayar.
Posting dari A/R Invoice, A/R Payment, dan A/R Memo ke tabel A/R bisa dilakukan secara manual atau otomatis.
Advanced Receipt
Advanced Billing
Realokasi Pembayaran
Bukti Potong Pajak

A/R Integration

Data Integration
A/R Invoicer
Managing Product

FINA General Ledger

Modul Fina G/L berisi sehimpunan proses akuntansi yang dimulai dari penerjemahan transaksi-transaksi keuangan menjadi akun-akun di jurnal sampai laporan keuangan pada suatu periode dihasilkan.

Accounting Period

Financial Statement/ Reporting

Report Layout

12-Columns Layout System
12-Columns Layout/ Grid System adalah sistem tata letak (layout) yang sangat populer dan banyak digunakan dalam dunia desain (grafis). Konsepnya sangat sederhana:
  1. Desain (media/ kertas/ layar/ area) dibagi menjadi baris-baris virtual yang disebut ROW. Jumlah ROW tidak dibatasi.
  2. Setiap ROW terdiri dari 12 kolom virtual atau COL. Jumlah COL pada setiap ROW harus tepat 12, tidak lebih, tidak kurang.
  3. COL akan menciptakan area desain yang baru yang lebih kecil. Area yang dibatasi oleh COL tersebut dapat digunakan untuk:
    • Menampilkan kolom-kolom data sesuai Fina Data Columns System
    • Dibagi menjadi area yang lebih kecil lagi dengan ROW dan COL (konsep ke-1), demikian seterusnya.
Layout/ Grid yang terdiri dari ROW dan Col tersebut dapat mengatur penempatan elemen-elemen desain secara fleksibel dan rapi. Angka 12 dipilih karena dapat membagi area menjadi: 1/1 (full), 1/2, 1/3, 1/4, 1/6, 1/12.

Report Data Columns (Mar 7, 2023 --> May 25, 2023)

 Kolom DataKeterangan
1.PeriodNilai (amount) pada periode yang dilaporkan
2.PeriodSumRatioRasio dari summary Period terhadap total summarynya
3.PeriodYTDNilai (amount) Year to Date, yaitu akumulasi nilai dari awal tahun sampai periode yang dilaporkan
4.PlanningNilai (amount) planning pada periode yang dilaporkan
5.PlanningSumRatioRasio dari summary Planning terhadap total summarynya
6.PlanningDeltaSelisih antara nilai (amount) pencapaian dengan nilai planning pada periode yang dilaporkan
7.PlanningRatioRasio antara nilai (amount) pencapaian dengan nilai planning pada periode yang dilaporkan
8.PlanningYTDNilai (amount) Year to Date, yaitu akumulasi nilai planning dari awal tahun sampai periode yang dilaporkan
9.PlanningYTDDeltaSelisih antara YTD periode yang dilaporkan dengan YTD planning
10.PlanningYTDRatioRatio antara YTD periode yang dilaporkan dengan YTD planning
11.LastYearNilai (amount) pada bulan yang sama di tahun lalu dari periode yang dilaporkan
12.LastYearSumRatioRasio dari summary Last Year terhadap total summarynya
13.LastYearDeltaSelisih nilai (amount) antara periode yang dilaporkan dengan bulan yang sama tahun lalu
14.LastYearRatioRasio antara nilai (amount) periode yang dilaporkan dengan bulan yang sama tahun lalu
15.LastYearYTDNilai (amount) Year to Date pada bulan yang sama di tahun lalu dari periode yang dilaporkan
16.LastYearYTDDeltaSelisih nilai YTD antara periode yang dilaporkan dengan bulan yang sama di tahun lalu
17.LastYearYTDRatioRatio antara nilai YTD periode yang dilaporkan dengan bulan yang sama di tahun lalu
18.OutlookAkumulasi nilai (amount) pencapaian dari awal tahun sampai periode yang dilaporkan ditambah akumulasi nilai (amount) planning di sisa bulan tahun yang sama
19.LastMonthNilai (amount) pada bulan sebelumnya dari periode yang dilaporkan (disepakati: 25 May 2023)
20.LastMonthSumRatioRasio dari summary Last Month terhadap total summarynya (disepakati: 25 May 2023)
21.LastMonthDeltaSelisih nilai (amount) antara periode yang dilaporkan dengan bulan sebelumnya (disepakati: 25 May 2023)
22.LastMonthRatioRasio antara nilai (amount) periode yang dilaporkan dengan bulan sebelumnya (disepakati: 25 May 2023)
23.LastMonthYTDNilai (amount) Year to Date pada bulan sebelumnya dari periode yang dilaporkan (disepakati: 25 May 2023)
24.LastMonthYTDDeltaSelisih nilai YTD antara periode yang dilaporkan dengan bulan sebelumnya (disepakati: 25 May 2023)
25.LastMonthYTDRatioRatio antara nilai YTD periode yang dilaporkan dengan bulan sebelumnya (disepakati: 25 May 2023)
26.January Nilai (amount) pada bulan January (added: 11 June 2023 for Outlook)
26.February Nilai (amount) pada bulan February (added: 11 June 2023 for Outlook)
26.March Nilai (amount) pada bulan March (added: 11 June 2023 for Outlook)
26.April Nilai (amount) pada bulan April (added: 11 June 2023 for Outlook)
26.May Nilai (amount) pada bulan May (added: 11 June 2023 for Outlook)
26.June Nilai (amount) pada bulan June (added: 11 June 2023 for Outlook)
26.July Nilai (amount) pada bulan July (added: 11 June 2023 for Outlook)
26.August Nilai (amount) pada bulan August (added: 11 June 2023 for Outlook)
26.September Nilai (amount) pada bulan September (added: 11 June 2023 for Outlook)
26.October Nilai (amount) pada bulan October (added: 11 June 2023 for Outlook)
26.November Nilai (amount) pada bulan November (added: 11 June 2023 for Outlook)
26.December Nilai (amount) pada bulan December (added: 11 June 2023 for Outlook)

Ada 18 kolom data yang dapat ditampilkan dalam report-report keuangan. Setiap kolom data terbagi lagi menjadi 10 kolom untuk menampung summary secara bertingkat (cascaded).

Kolom data mana yang akan ditampilkan dalam suatu report dapat diatur dari layar FINA Report Spec. FINA Report Spec juga mengatur bagaimana angka-angka (amounts) dalam kolom data ditampilkan

  • Angka ditampilkan apa adanya atau dalam ribuan (in-thousand)
  • Nilai desimal ditampilkan atau tidak
  • Summary ditampilkan secara bertingkat (cascaded) atau digabungkan menjadi 1 kolom (merged)

Saat ditampilkan, kolom-kolom data akan ditempatkan pada posisi nya masing-masing dalam FINA Data Columns System..

FINA Data Columns System
Adalah suatu tabel yang terdiri dari banyak kolom yang disusun sedemikian rupa untuk menampilkan suatu nilai (amount), summary, teks, dan garis.
  1. Cascaded: Summary data disusun bertingkat. SUM_1 paling kiri, disusul SUM_2, SUM_3, dst dalam kolomnya masing-masing.
  2. Merged: Summary data disusun dalam satu kolom. Jadi SUM_1, SUM_2, SUM_3 semuanya ada dalam kolom yang sama.

Nilai Kolom-Kolom Data (Data Column's Value)

Amount:

  • [BAL] = Balance
  • [NC] = NetChange
  • [YTD] = Year to Date

Source:

  • TBCOA = Trial Balance of Account (COA)
  • TBCF = Trial Balance of Cash Flow
  • TBRE = Trial Balance of Retained Earning

Time:

  • Period: Periode yang dilaporkan
  • LM (Last Month): Periode bulan sebelumnya dari Periode yang dilaporkan
  • LY (Last Year): Periode bulan yang sama tahun sebelumnya dari Periode yang dilaporkan
  • YE (Year End): Periode bulan Desember tahun yang sama dengan Periode yang dilaporkan
  • EOY (End of Year): Periode bulan Desember tahun sebelumnya dari Periode yang dilaporkan
  • EOYLY (End of Year of Last Year): Periode bulan Desember 2 tahun sebelum Periode yang dilaporkan
  • LMLY (Last Month of Last Year): Periode bulan yang sebelumnya di tahun sebelum Periode yang dilaporkan
  • LMLM (Last Month of Last Month): Periode 2 bulan sebelum Periode yang dilaporkan

Data TagData Column ValueSum
PeriodPeriodYTDL.MonthL.MonthYTDL.YearL.Year YTDPlanPlan YTD
RANGE (Period Type)TBCOA.Period.[NC]TBCOA.Period.[YTD]TBCOA.LM.[NC]TBCOA.LM.[YTD]TBCOA.LY.[NC]TBCOA.LY.[YTD]TBCOA.Period.[PlanNC]TBCOA.Period.[PlanYTD]SUM_1
RANGE (Cash Flow)TBCOA.LM.[BAL]TBCOA.EOY.[BAL]TBCOA.LMLM.[BAL]TBCOA.0.00000TBCOA.LMLY.[BAL]TBCOA.EOYLY.[BAL]TBCOA.LM.[PlanBAL]TBCOA.EOY.[PlanBAL]SUM_1
RANGE (Balance Type)TBCOA.Period.[BAL]TBCOA.Period.[YTD]TBCOA.LM.[BAL]TBCOA.LM.[YTD]TBCOA.LY.[BAL]TBCOA.LY.[YTD]0.000000.00000SUM_1
RANGE (Outlook Type)TBCOA.Period.[YTD]TBCOA.Period.[YTD]0.000000.00000TBCOA.EOY.[YTD]TBCOA.EOY.[YTD]TBCOA.YE.[PlanYTD]TBCOA.Period.[PlanYTD]SUM_1
ACCOUNT (Period Type)TBCOA.Period.[NC]TBCOA.Period.[YTD]TBCOA.LM.[NC]TBCOA.LM.[YTD]TBCOA.LY.[NC]TBCOA.LY.[YTD]TBCOA.Period.[PlanNC]TBCOA.Period.[PlanYTD]SUM_2
ACCOUNT (Cash Flow)TBCOA.LM.[BAL]TBCOA.EOY.[BAL]TBCOA.LMLM.[BAL]TBCOA.0.00000TBCOA.LMLY.[BAL]TBCOA.EOYLY.[BAL]TBCOA.LM.[PlanBAL]TBCOA.EOY.[PlanBAL]SUM_2
ACCOUNT (Balance Type)TBCOA.Period.[BAL]TBCOA.Period.[YTD]TBCOA.LM.[BAL]TBCOA.LM.[YTD]TBCOA.LY.[BAL]TBCOA.LY.[YTD]0.000000.00000SUM_2
ACCOUNT (Outlook Type)TBCOA.Period.[YTD]TBCOA.Period.[YTD]0.000000.00000TBCOA.EOY.[YTD]TBCOA.EOY.[YTD]TBCOA.YE.[PlanYTD]TBCOA.Period.[PlanYTD]SUM_2
CF_RANGE (Period Type)0.000000.000000.000000.000000.000000.000000.000000.00000SUM_1
CF_RANGE (Cash Flow)TBCF.Period.[NC]TBCF.Period.[YTD]TBCF.LM.[NC]TBCF.LM.[YTD]TBCF.LY.[NC]TBCF.LY.[YTD]TBCF.Period.[PlanNC]TBCF.Period.[PlanYTD]SUM_1
CF_RANGE (Balance Type)0.000000.000000.000000.000000.000000.000000.000000.00000SUM_1
CF_ACCOUNT (Period Type)0.000000.000000.000000.000000.000000.000000.000000.00000SUM_2
CF_ACCOUNT (Cash Flow)TBCF.Period.[NC]TBCF.Period.[YTD]TBCF.LM.[NC]TBCF.LM.[YTD]TBCF.LY.[NC]TBCF.LY.[YTD]TBCF.Period.[PlanNC]TBCF.Period.[PlanYTD]SUM_2
CF_ACCOUNT (Balance Type)0.000000.000000.000000.000000.000000.000000.000000.00000SUM_2
RET_EARNING (Period Type)TBRE.Period.[NC]
TBCOA.Period.[NC]		TBRE.Period.[YTD]
TBCOA.Period.[YTD]		TBRE.LM.[NC]
TBCOA.LM.[NC]		TBRE.LM.[YTD]
TBCOA.LM.[YTD]		TBRE.LY.[NC]
TBCOA.LY.[NC]		TBRE.LY.[YTD]
TBCOA.LY.[YTD]		0.000000.00000SUM_1
RET_EARNING (Cash Flow)0.000000.000000.000000.000000.000000.000000.000000.00000SUM_1
RET_EARNING (Balance Type)TBRE.Period.[BAL]
TBCOA.Period.[BAL]		TBRE.Period.[YTD]
TBCOA.Period.[YTD]		TBRE.LM.[BAL]
TBCOA.LM.[BAL]		TBRE.LM.[YTD]
TBCOA.LM.[YTD]		TBRE.LY.[BAL]
TBCOA.LY.[BAL]		TBRE.LY.[YTD]
TBCOA.LY.[YTD]		0.000000.00000SUM_1
RET_EARNING_YTD TBRE.Period.[YTD]TBRE.Period.[YTD]TBRE.LM.[YTD]TBRE.LM.[YTD]TBRE.LY.[YTD]TBRE.LY.[YTD]0.000000.00000SUM_1
RET_EARNING_EOYTBRE.EOY.[BAL]
TBCOA.EOY.[BAL]
TBCOA.Period.[YTD]		TBRE.EOY.[BAL]
TBCOA.EOY.[BAL]
TBCOA.Period.[YTD]		TBRE.EOY.[BAL]
TBCOA.EOY.[BAL]
TBCOA.LM.[YTD]		TBRE.EOY.[BAL]
TBCOA.EOY.[BAL]
TBCOA.LM.[YTD]		TBRE.EOYLY.[BAL]
TBCOA.EOYLY.[BAL]
TBCOA.LY.[YTD]		TBRE.EOYLY.[BAL]
TBCOA.EOYLY.[BAL]
TBCOA.LY.[YTD]		0.000000.00000SUM_1

Contoh Nilai Kolom-Kolom Data Periode: MEI 2023

Data TagData Column Value (May 2023)
PeriodPeriodYTDL.MonthL.MonthYTDL.YearL.YearYTDPlanPlanYTD
RANGE (Period Type)TBCOA.May2023.[NC]TBCOA.May2023.[YTD]TBCOA.Apr2023.[NC]TBCOA.Apr2023.[YTD]TBCOA.May2022.[NC]TBCOA.May2022.[YTD]TBCOA.May2023.[PlanNC]TBCOA.May2023.[PlanYTD]
RANGE (Cash Flow)TBCOA.Apr2023.[BAL]TBCOA.Dec2022.[BAL]TBCOA.Mar2023.[BAL]TBCOA.0.00000TBCOA.Apri2022.[BAL]TBCOA.Dec2021.[BAL]TBCOA.Apr2023.[PlanBAL]TBCOA.Dec2022.[PlanBAL]
RANGE (Balance Type)TBCOA.May2023.[BAL]TBCOA.May2023.[YTD]TBCOA.Apr2023.[BAL]TBCOA.Apr2023.[YTD]TBCOA.May2022.[BAL]TBCOA.May2022.[YTD]0.000000.00000
RANGE (Outlook Type)TBCOA.May2023.[YTD]TBCOA.May2023.[YTD]0.000000.00000TBCOA.Dec2022.[YTD]TBCOA.Dec2022.[YTD]TBCOA.Dec2023.[PlanYTD]TBCOA.May2023.[PlanYTD]
ACCOUNT (Period Type)TBCOA.May2023.[NC]TBCOA.May2023.[YTD]TBCOA.Apr2023.[NC]TBCOA.Apr2023.[YTD]TBCOA.May2022.[NC]TBCOA.May2022.[YTD]TBCOA.May2023.[PlanNC]TBCOA.May2023.[PlanYTD]
ACCOUNT (Cash Flow)TBCOA.Apr2023.[BAL]TBCOA.Dec2022.[BAL]TBCOA.Mar2023.[BAL]TBCOA.0.00000TBCOA.May2022.[NC]TBCOA.May2022.[YTD]TBCOA.Apr2023.[PlanBAL]TBCOA.Dec2022.[PlanBAL]
ACCOUNT (Balance Type)TBCOA.May2023.[BAL]TBCOA.May2023.[YTD]TBCOA.Apr2023.[BAL]TBCOA.Apr2023.[YTD]TBCOA.May2022.[BAL]TBCOA.May2022.[YTD]0.000000.00000
ACCOUNT (Outlook Type)TBCOA.May2023.[YTD]TBCOA.May2023.[YTD]0.000000.00000TBCOA.Dec2022.[YTD]TBCOA.Dec2022.[YTD]TBCOA.Dec2023.[PlanYTD]TBCOA.May2023.[PlanYTD]
CF_RANGE (Period Type)0.000000.000000.000000.000000.000000.000000.000000.00000
CF_RANGE (Cash Flow)TBCF.May2023.[NC]TBCF.May2023.[YTD]TBCF.Apr2023.[NC]TBCF.Apr2023.[YTD]TBCF.May2022.[NC]TBCF.May2022.[YTD]TBCF.May2023.[PlanNC]TBCF.May2023.[PlanYTD]
CF_RANGE (Balance Type)0.000000.000000.000000.000000.000000.000000.000000.00000
CF_ACCOUNT (Period Type)0.000000.000000.000000.000000.000000.000000.000000.00000
CF_ACCOUNT (Cash Flow)TBCF.May2023.[NC]TBCF.May2023.[YTD]TBCF.Apr2023.[NC]TBCF.Apr2023.[YTD]TBCF.May2022.[NC]TBCF.May2022.[YTD]TBCF.May2023.[PlanNC]TBCF.May2023.[PlanYTD]
CF_ACCOUNT (Balance Type)0.000000.000000.000000.000000.000000.000000.000000.00000
RET_EARNING (Period Type)TBRE.May2023.[NC]
TBCOA.May2023.[NC]		TBRE.May2023.[YTD]
TBCOA.May2023.[YTD]		TBRE.Apr2023.[NC]
TBCOA.Apr2023.[NC]		TBRE.Apr2023.[YTD]
TBCOA.Apr2023.[YTD]		TBRE.May2022.[NC]
TBCOA.May2022.[NC]		TBRE.May2022.[YTD]
TBCOA.May2022.[YTD]		0.000000.00000
RET_EARNING (Cash Flow)0.000000.000000.000000.000000.000000.000000.000000.00000
RET_EARNING (Balance Type)TBRE.May2023.[BAL]
TBCOA.May2023.[BAL]		TBRE.May2023.[YTD]
TBCOA.May2023.[YTD]		TBRE.Apr2023.[BAL]
TBCOA.Apr2023.[BAL]		TBRE.Apr2023.[YTD]
TBCOA.Apr2023.[YTD]		TBRE.May2022.[BAL]
TBCOA.May2022.[BAL]		TBRE.May2022.[YTD]
TBCOA.May2022.[YTD]		0.000000.00000
RET_EARNING_YTD TBRE.May2023.[YTD]TBRE.May2023.[YTD]TBRE.Apr2023.[YTD]TBRE.Apr2023.[YTD]TBRE.May2022.[YTD]TBRE.May2022.[YTD]0.000000.00000
RET_EARNING_EOY TBRE.Dec2022.[BAL]
TBCOA.Dec2022.[BAL]
TBCOA.May2023.[YTD]		TBRE.Dec2022.[BAL]
TBCOA.Dec2022.[BAL]
TBCOA.May2023.[YTD]		TBRE.Dec2022.[BAL]
TBCOA.Dec2022.[BAL]
TBCOA.Apr2023.[YTD]		TBRE.Dec2022.[BAL]
TBCOA.Dec2022.[BAL]
TBCOA.Apr2023.[YTD]		TBRE.Dec2021.[BAL]
TBCOA.Dec2021.[BAL]
TBCOA.May2022.[YTD]		TBRE.Dec2021.[BAL]
TBCOA.Dec2021.[BAL]
TBCOA.May2022.[YTD]		0.000000.00000

Control Tags dan Text Modifiers

Display Tags

TagKeterangan
TEXTMenampilkan teks melintasi semua kolom teks dan data
TEXT_0Menampilkan teks di kolom teks (kolom 0).
TEXT_TITLEMenampilkan teks melintasi semua kolom data.
NOTEMenampilkan pesan "dalam ribuan" melintasi semua kolom teks dan data
NOTE_0Menampilkan pesan "dalam ribuan" di kolom teks (kolom 0).
NOTE_TITLEMenampilkan pesan "dalam ribuan" melintasi semua kolom data.
ULMenampilkan garis melintasi semua kolom teks dan data
UL_0Menampilkan garis di kolom teks (kolom 0).
UL_1Menampilkan garis di kolom teks (kolom 0) dan kolom summary 1 kolom data.
UL_2Menampilkan garis di kolom teks (kolom 0) dan kolom summary 2 kolom data.
(dan seterusnya untuk UL_3 sampai UL_10)
UL_TITLEMenampilkan garis di kolom data
DLMenampilkan garis ganda melintasi semua kolom teks dan data
DL_0Menampilkan garis ganda di kolom teks (kolom 0).
DL_1Menampilkan garis ganda di kolom teks (kolom 0) dan kolom summary 1 kolom data.
DL_2Menampilkan garis ganda di kolom teks (kolom 0) dan kolom summary 2 kolom data.
(dan seterusnya untuk DL_3 sampai DL_10)
DL_TITLEMenampilkan garis ganda di kolom data
TITLEMenampilkan judul kolom-kolom data
LEGENDMenampilkan legend judul kolom-kolom data

Data Tags

TagKeterangan
ACCOUNTMenampilkan Account dari Trial Balance sesuai Range yang ditetapkan (kecuali Retained Earning) kemudian mengakumulasikannya ke SUM_2
RANGEMengakumulasi nilai Account dari Trial Balance sesuai Range yang ditetapkan (kecuali Retained Earning) ke SUM_1 tanpa menampilkannya.
CF_ACCOUNTMenampilkan Account dari Cash Flow Trial Balance sesuai Range yang ditetapkan kemudian mengakumulasikannya ke SUM_2
CF_RANGEMengakumulasi nilai Account dari Cash Flow Trial Balance sesuai Range yang ditetapkan ke SUM_1 tanpa menampilkannya.
RET_EARNINGMengambil nilai Retained Earning periode yang dilaporkan ke SUM_1 tanpa menampilkannya.
RET_EARNING_YTDMengambil nilai YTD Retained Earning periode yang dilaporkan ke SUM_1 tanpa menampilkannya.
RET_EARNING_EOYMengambil nilai BALANCE Retained Earning akhir tahun lalu (EOY=End of Year) ke SUM_1 tanpa menampilkannya.
SUM_1Menampilkan nilai SUM_1 dan mengakumulasikannya ke SUM_2, kemudian me-reset nilai SUM_1 menjadi 0 (nol).
SUM_2Menampilkan nilai SUM_2 dan mengakumulasikannya ke SUM_3, kemudian me-reset nilai SUM_2 menjadi 0 (nol).
(dan seterusnya untuk SUM_3 sampai SUM_10)
BREAK_1Me-reset nilai akumulasi SUM_1 menjadi 0 (nol)
BREAK_2Me-reset nilai akumulasi SUM_2 menjadi 0 (nol).
(dan seterusnya untuk BREAK_3 sampai BREAK_10)
CALC_1Mengakumulasi nilai SUM_1 ke SUM_2, kemudian me-reset nilai SUM_1 menjadi 0 (nol)
CALC_2Mengakumulasi nilai SUM_2 ke SUM_3, kemudian me-reset nilai SUM_2 menjadi 0 (nol).
(dan seterusnya untuk CALC_3 sampai CALC_10)
NEGATE_1Menegasikan nilai SUM_1 dari positif ke negatif dan sebaliknya
NEGATE_2Menegasikan nilai SUM_2 dari positif ke negatif dan sebaliknya.
(dan seterusnya untuk NEGATE_3 sampai NEGATE_10)
SET Menetapkan (set) tetapan (settings) pencetakan. Misalnya untuk menetapkan judul kolom data "LastYearYTD" menjadi "LY YTD" maka masukkan perintah:
SET %LastYearYTD%, LY YTD
RATIOMenandai awal perhitungan ratio. Seluruh SUM yang yang ada dalam rentang RATIO...RATIO_END akan dihitung rasionya ke SUM tertinggi dalam rentang tersebut
RATIO_ENDMenandai akhir perhitungan ratio. Seluruh SUM yang yang ada dalam rentang RATIO...RATIO_END akan dihitung rasionya ke SUM tertinggi dalam rentang tersebut

Layouting Tags

TagKeterangan
ROWDefine the beginning of a row
ROW_ENDDefine the ending of a row
COL_1Define the beginning of a column, 1/12 width of area
COL_2Define the beginning of a column, 2/12 width of area
COL_3Define the beginning of a column, 3/12 width of area (a quarter)
COL_4Define the beginning of a column, 4/12 width of area (a third)
COL_5Define the beginning of a column, 5/12 width of area
COL_6Define the beginning of a column, 6/12 width of area (a half)
COL_7Define the beginning of a column, 7/12 width of area
COL_8Define the beginning of a column, 8/12 width of area
COL_9Define the beginning of a column, 9/12 width of area
COL_10Define the beginning of a column, 10/12 width of area
COL_11Define the beginning of a column, 11/12 width of area
COL_12Define the beginning of a column, 12/12 width of area (full width)
COL_ENDDefine the ending of a column

Text Modifiers

Text ModifierKeterangan
%Date%Tanggal report dibuat, format: DD/MM/YYYY
%Time%Jam report dibuat, format: hh:mm:ss
%User%Nama user yang membuat report
%Layout%Kode Layout yang digunakan
%Spec%Kode Spec yang digunakan
%PeriodName%Nama periode, format: YYYY.MM, misalnya: 2023.02
%PeriodBegin%Tanggal awal periode, format: DD/MM/YYYY
%PeriodEnd%Tanggal akhir periode, format: DD/MM/YYYY
%PeriodMonth%Nama bulan periode: January, February, dst
%PeriodYear%Tahun periode: 2020, 2021, 2022, dst
%LastYearName%Nama periode tahun lalu , format: YYYY.MM, misalnya: 2023.02
%LastYearBegin%Tanggal awal periode tahun lalu, format: DD/MM/YYYY
%LastYearEnd%Tanggal akhir periode tahun lalu, format: DD/MM/YYYY
%LastYearMonth%Nama bulan periode tahun lalu: January, February, dst
%LastYearYear%Tahun periode tahun lalu: 2020, 2021, 2022, dst
%OrganizationCode%Kode Organisasi
%OrganizationName%Nama Organisasi
%CurrencyCode%Kode mata uang: IDR, USD, dst
%CurrencyName%Nama mata uang: Indonesian Rupiah, dll
%CurrencySymbol%Simbol mata uang: Rp, $, €, ¥, dll.

Sesuai namanya, Text Modifier adalah "pengganti" atau "pengubah" isi teks. Text Modifier digunakan dengan cara disisipkan ke dalam teks. Saat report dihasilkan (rendered), sistem akan mengganti Text Modifier dengan data sesuai konteksnya. Contohnya ada di Line ke-4.

Contoh penggunaan Tag dan Text Modifier

Tata letak (layout) seperti pada gambar Fina 12 Columns Layout System dapat diperoleh dengan merangkai Tag dan Text Modifier seperti contoh di bawah:

LineTagData, Teks, Style/ Atribute
1ROW
2COL_12
3TEXTREPORT HEADING/ TITLE Text: Width 12, Align Center, Style: Big, Bold
4TEXT%OrganizationName%, period %PeriodBegin% - %PeriodEnd% Text: Width 12, Align Center
5COL_END
6ROW END
7ROW
8COL_6
9TEXTLEFT DATA AREA Text: Width 12, Align Center
10RANGE[...]
11SUM_1Kas dan Setara Kas Text: Width 8, Align Left, Amount: Width 4, Align Right
12RANGE[...]
13SUM_1Piutang Usaha Text: Width 8, Align Left, Amount: Width 4, Align Right
14COL_END
15COL_6
16TEXTRIGHT DATA AREA Text: Width 12, Align Center
17COL_END
18ROW_END
19ROW
20COL_4
21TEXTSIGNER AREA 1 Text: Width 12, Align Center
22COL_END
23COL_4
24TEXTSIGNER AREA 2 Text: Width 12, Align Center
25COL_END
26COL_4
27TEXTSIGNER AREA 3 Text: Width 12, Align Center
28COL_END
29ROW_END

Chart of Accounts (COA)

FINA BP

Single View of Partner
BP (Business Partner) adalah representasi yang teragregasi, menyeluruh dan konsisten tentang setiap pihak yang terlibat di dalam proses-proses bisnis Fina. Ada 5 jenis BP di Fina yaitu:
  1. Internal Organization
  2. Customer
  3. Supplier
  4. Bank
  5. Employee (Cashier, Bank Admin, dll)
Desain single-view butuh pengelolaan terpusat (Centralized Management)
BP Multiple-Roles
Partner yang sama hanya perlu dicatat sekali di BP. Multiple roles dapat di-assign ke partner tersebut sehingga BP dapat menjalankan fungsi yang berbeda-beda di Fina. Contohnya: PT.KMN, bisa menjalankan peran sebagai internal-organization, customer, dan supplier sekaligus.
Registration & Editing
BP diinput secara manual dari layar BP yang tersedia. Sistem akan memeriksa duplikasi berdasarkan nomor NPWP (jika ada) dan kombinasi atribut unik lainnya seperti nomor identitas, nama dan email, nama dan nomor telepon.
Registrasi BP secara otomatis bisa dilakukan saat menginput Customer atau Supplier baru, dengan memilih BP: (auto) dari layar Customer atau Supplier
Confirmation
Konfirmasi menandai bahwa BP sudah diperiksa. Tujuannya untuk membantu pengelola BP memisahkan BP yang sudah diperiksa dengan BP yang baru/ berubah. Perubahan data BP bisa datang dari layar Customer/ Supplier atau di ekstrak dari data transaksi, misalnya invoice.
Konfirmasi perlu diulang setiap kali ada perubahan informasi BP.
Merging
Merging dapat dilakukan ketika pengelola BP menemukan beberapa BP yang sama (terduplikasi). Proses merging akan menggabungkannya menjadi satu.
Proses ini diperlukan terutama untuk BP berjenis Customer atau Supplier yang registrasinya dilakukan otomatis atau yang di ekstrak dari data transaksi, misalnya: invoice.

FINA Organization

Internal Organization
Internal Organization atau disebut Organization saja adalah unit-unit bisnis atau unit-unit kerja yang terlibat atau memiliki peran dalam proses dan transaksi di Fina baik secara fungsional maupun struktural.
Internal Organization adalah BP
Seluruh pihak (parties) yang terlibat dalam proses bisnis di Fina disebut Business Partner atau BP. Dalam pengertian tersebut Internal Organization adalah BP juga.
Internal Organization merupakan salah satu dari 5 jenis BP yang ada di Fina yaitu:
  1. Internal Organization
  2. Customer
  3. Supplier
  4. Bank
  5. Employee (Cashier, Bank Admin, dll)
Struktur Internal Organization
Internal Organization disusun secara hirarkis membentuk pohon (tree) yang disebut struktur organisasi. Walaupun ada kemiripan, struktur organisasi di Fina tidak harus sama persis dengan struktur organisasi (departemental) menurut HR (Human Resource). Karena ada unit-unit yang sulit diwakili oleh organisasi sebagai departemen, misalnya konsorsium, proyek, organisasi functional seperti gudang, dll.
Pewarisan (Inheritance)
Internal Organization dapat memiliki atribut informasi yang dilekatkan langsung ke Internal Organization tersebut seperti informasi Nama, Home Currency, dan Bank Account. Organization juga dapat mewarisi (inherit) atribut informasi dari induknya (parent).
Pada gambar dicontohkan Divisi Marketing tidak menetapkan home-currency nya. Transaksi di Divisi Marketing akan dilakukan dalam currency IDR mengikuti home-currency yang dilekatkan pada tingkat Legal Entity yaitu Kompas Media Nusantara, PT.
Konteks (Context)
Posisi suatu organisasi di dalam struktur menciptakan "konteks" pada organisasi tersebut. Contohnya: Legal Entity dari Gudang Barter pada gambar adalah Kompas Media Nusantara, PT. Konteks legal-entity tersebut diperoleh karena posisi Gudang Barter secara hirarkis yang ada di bawah Kompas Media Nusantara, PT.
Internal Organization Multiple-Roles
Internal Organization bisa menjalankan lebih dari satu peran (role) sekaligus. Peran-peran tersebut adalah sebagai Legal Entity, Company, Department, Revenue Center, Cost Center, Sales Organization, Purchasing Organization, Warehouse, Asset Center, dan Cash Funder
Organisasi Fungsional
Beberapa peran fungsional Internal Organization membutuhkan atribut informasi khusus yang tidak dimiliki oleh Internal Organization secara umum. Untuk itu diciptakan entitas-entitas organisasi baru yang merupakan keturunan dari Internal Organization. Di entitas turunan tersebut atribut-atribut informasi yang kurang bisa ditambahkan sesuai dengan peran fungsionalnya.
Entitas-entitas turunan dari Internal Organization adalah:
  • Sales Organization (SalesOrg)
  • Purchasing Organization (PurchasingOrg)
  • Warehouse (future version)
  • Asset Center (future version)
Peran/ RoleDescription
Legal Entity (LE)Organisasi sebagai badan hukum, entitas pajak: Perusahaan, PT, Yayasan, dll.
CompanyOrganisasi sebagai "company".
Business Area (BA)Organisasi sebagai "business area"/ suku usaha.
DepartmentOrganisasi struktural sesuai struktur organisasi SDM
Revenue CenterOrganisasi dapat menerima dan mengakumulasi pendapatan
Cost CenterOrganisasi dapat menanggung atau menerima beban (biaya)
Sales OrganizationOrganisasi fungsional yang menjual barang atau jasa kepada customer
Purchasing OrganizationOrganisasi fungsional yang membeli barang atau jasa dari supplier
WarehouseOrganisasi fungsional yang menyimpan barang-barang stock
Asset CenterOrganisasi fungsional yang mengelola barang-barang inventaris perusahaan
Cash FunderOrganisasi sebagai penyandang dana "talangan" Cash atau Bank setara Cash.

FINA Customer

Customer
Customer adalah semua pihak yang melakukan transaksi pembelian ke SalesOrg baik yang berasal dari luar (external parties) maupun yang berasal dari lingkungan KG (KGMedia) sendiri.
Dari kacamata keuangan, Customer adalah pihak yang menerima tagihan dari SalesOrg, yang tercantum di dalam A/R, yang membayar melalui Cash Counter atau Bank.
Customer adalah BP
Seluruh pihak (parties) yang terlibat dalam proses bisnis di Fina disebut Business Partner atau BP. Dalam pengertian tersebut Customer adalah BP juga.
Customer merupakan salah satu dari 5 jenis BP yang ada di Fina yaitu:
  1. Internal Organization
  2. Customer
  3. Supplier
  4. Bank
  5. Employee (Cashier, Bank Admin, dll)
Customer di lingkungan Multi-System
Ada beragam sistem penjualan di KG (KGMedia khususnya). Masing-masing sistem tersebut mencatat customer-nya masing-masing. Customer yang sama bisa tercatat di 2 sistem yang berbeda dan mendapat nomor registrasi yang berbeda juga.
Lingkungan yang multi-system tersebut mendasari desain pengelolaan Customer di Fina. Data customer yang masuk dicatat sistem asalnya, lengkap dengan nomor referensi (unique number) di sistem asalnya. Dengan cara demikian Fina selalu dapat mengembalikan status transaksi customer ke sistem sistem asalnya.
Sebaliknya, sistem asalnya dapat mengambil informasi transaksi customer-nya langsung dari Fina melalui jalur API yang tersedia dengan menggunakan unique number dari sistemnya sendiri.
Desain yang demikian menyebabkan customer yang sama bisa tercatat beberapa kali di Fina karena berasal dari Application atau sistem sumber yang berbeda-beda.
BP = Single View of Customer
Beberapa Customer dapat "disatukan" dengan merujukkan Customer yang berbeda-beda tersebut ke satu BP. Dengan cara demikian prinsip single-view of customer tetap dapat dicapai. Tentu saja penyatuan ini butuh usaha dari para "admin" atau pengelola BP. Sebagai catatan, penyatuan data BP bukanlah syarat untuk melakukan transaksi di Fina.
Customer Registration
Customer dapat diinput secara manual dari layar customer yang tersedia. Melalui layar customer tersebut Customer dapat dirujukkan ke BP yang sudah ada atau membuat BP secara otomatis.
Registrasi Customer dengan cara export/ import perlu disepakati terlebih dahulu mekanismenya mengingat struktur informasi customer di masing-masing aplikasi berbeda-beda.

FINA Supplier

Supplier
Supplier adalah semua pihak penyedia barang dan jasa yang melakukan transaksi penjualan kepada PurchasingOrg baik yang berasal dari luar (external parties) maupun yang berasal dari lingkungan KG (KGMedia) sendiri.
Dari kacamata keuangan, Supplier adalah pihak yang melayangkan tagihan kepada PurchasingOrg, yang tercantum di dalam A/P, yang dibayar melalui Cash Counter atau Bank.
Supplier adalah BP
Seluruh pihak (parties) yang terlibat dalam proses bisnis di Fina disebut Business Partner atau BP. Dalam pengertian tersebut Supplier adalah BP juga.
Supplier merupakan salah satu dari 5 jenis BP yang ada di Fina yaitu:
  1. Internal Organization
  2. Customer
  3. Supplier
  4. Bank
  5. Employee (Cashier, Bank Admin, dll)
Supplier di lingkungan Multi-System
Ada beragam sistem pembelian di KG (KGMedia khususnya). Masing-masing sistem tersebut mencatat Supplier-nya masing-masing. Supplier yang sama bisa tercatat di 2 sistem yang berbeda dan mendapat nomor registrasi yang berbeda juga.
Lingkungan yang multi-system tersebut mendasari desain pengelolaan Supplier di Fina. Data Supplier yang masuk dicatat sistem asalnya, lengkap dengan nomor referensi (unique number) di sistem asalnya. Dengan cara demikian Fina selalu dapat mengembalikan status transaksi Supplier ke sistem sistem asalnya.
Sebaliknya, sistem asalnya dapat mengambil informasi transaksi Supplier-nya langsung dari Fina melalui jalur API yang tersedia dengan menggunakan unique number dari sistemnya sendiri.
Desain yang demikian menyebabkan Supplier yang sama bisa tercatat beberapa kali di Fina karena berasal dari Application atau sistem sumber yang berbeda-beda.
BP = Single View of Supplier
Beberapa Supplier dapat "disatukan" dengan merujukkan Supplier yang berbeda-beda tersebut ke satu BP. Dengan cara demikian prinsip single-view of Supplier tetap dapat dicapai. Tentu saja penyatuan ini butuh usaha dari para "admin" atau pengelola BP. Sebagai catatan, penyatuan data BP bukanlah syarat untuk melakukan transaksi di Fina.
Supplier Registration
Supplier dapat diinput secara manual dari layar Supplier yang tersedia. Melalui layar Supplier tersebut Supplier dapat dirujukkan ke BP yang sudah ada atau membuat BP secara otomatis.
Registrasi Supplier dengan cara export/ import perlu disepakati terlebih dahulu mekanismenya mengingat struktur informasi Supplier di masing-masing aplikasi berbeda-beda.

FINA Employee

Karyawan (Employee)
Karyawan/ Employee adalah orang-orang yang bekerja untuk Internal Organization tertentu dan memiliki peran dalam proses-proses di Fina. Peran Employee dibedakan menjadi 2 yaitu:
  1. Peran sebagai Operator/ Pengguna misalnya sebagai Kasir, Bank Admin, approver, dll. Untuk menjalankan peran operator, Employee harus terasosiasi (terhubung) dengan User tertentu.
  2. Peran dalam Transaksi. Seorang Employee bisa tercatat sebagai pihak yang terlibat dalam transaksi walaupung dia bukanlah pengguna Fina. Namanya bisa tercantum dalam transaksi Bon Sementara, transaksi Pembelian, dll.
Employee adalah BP
Seluruh pihak (parties) yang terlibat dalam proses bisnis di Fina disebut Business Partner atau BP. Dalam pengertian tersebut Employee adalah BP juga.
Employee merupakan salah satu dari 5 jenis BP yang ada di Fina yaitu:
  1. Internal Organization
  2. Customer
  3. Supplier
  4. Bank
  5. Employee (Cashier, Bank Admin, dll)
Employee sebagai Operator
Employee yang login dan mengoperasikan Fina secara langsung disebut Operator. Peran operator antara lain:
  • Cashier, karyawan yang bertugas menerima transaksi di Cash Counter
  • Bank Admin, karyawan yang bertugas mengelola akun-akun bank
Untuk dapat berperan sebagai operator, Employee dihubungkan dengan User tertentu. Proses yang dapat dijalankan oleh Employee tersebut tergantung pada hak akses yang melekat pada User yang terhubung dengan Employee tersebut.
Employee Registration
Employee dapat diinput secara manual dari layar Employee yang tersedia. Melalui layar Employee tersebut Employee dapat dirujukkan ke BP yang sudah ada atau membuat BP secara otomatis.
Registrasi Employee dengan cara export/ import perlu disepakati terlebih dahulu mekanismenya mengingat struktur informasi Employee di masing-masing aplikasi berbeda-beda.

FINA Integration

FINA dibangun dalam realitas lingkungan sistem KG Media yang polylitic. Sejak desain awal, sistem-sistem bisnis yang sampai sekarang dijalankan oleh KG Media sudah masuk dalam pertimbangan rancangan. Kemampuan integrasi dan interoperability sudah "melebur" dalam setiap fitur dan fungsi bisnis di FINA.

Integration Enablers
Multi-Application
Aplikasi-aplikasi yang terintegrasi dengan Fina terdaftar dalam Master Data Application. Fina menyebut aplikasi-aplikasi tersebut sebagai aplikasi sumber atau Source Application
Informasi Source Application dilekatkan pada entitas-entitas transaksi bisnis seperti: Cash Receipt, Cash Payment, Bank Allocation, A/R Invoice, dll. Dengan cara ini Fina mengetahui dari aplikasi mana transaksi berasal. Jika diperlukan, Fina juga dapat mengembalikan feedback ke aplikasi sumbernya dengan tepat.
Application based Customer and Supplier
Entitas Customer dan entitas Supplier dimiliki oleh masing-masing Application. Fina langsung menggunakan entitas-entitas tersebut apa adanya dalam transaksi-transaksi bisnis, seolah-olah berasal dari Fina sendiri.
  • Independensi masing-masing aplikasi dalam mengelola customer dan suppliernya tetap terjaga
  • Tidak dibutuhkan proses "mapping" sebelum transaksi dicatat yang selama ini menjadi bottleneck
Self-Contained Modularity
Setiap modul (sub-system) di Fina bersifat independen satu sama lain. Masing-masing modul dapat beroperasi tanpa adanya modul lain.
  • Setiap modul mengelola dan menyimpan informasi yang dibutuhkan oleh modul tersebut
  • Setiap modul memiliki pintu masuk (entry point) sendiri-sendiri
Dengan pendekatan ini, modul-modul di Fina dapat di deploy sesuai kebutuhan organisasi yang mengoperasikannya.

SPSK Integration as per Nov 7, 2021

Integration Description
Common Modules Cash Receipt, Bank R/C Import, Bank Statement (for Receipt Allocation) untuk mencatat penerimaan pembayaran dari agen-agen SPSK.
SPSK Receipt Post Back

Fina mengembalikan status penerimaan pembayaran dari customer-customer SPSK (agen-agen) langsung ke tabel TrxBayar di SPSK.

Rapat tanggal 1 Maret 2022 menyepakati post-back dari FINA ke SPSK juga mengirimkan transaksi "Reversed Payment". Kode transaksi Reversed Payment FINA akan diterjemahkan ke kode transaksi reversed di SPSK. Nilai Reversed Receipt yang dikirimkan akan bernilai negatif (<0)
SPSK Customer Sync. Menu untuk meng-import data agen SPSK menjadi customer di Fina. Informasi Customer tidak dapat di ekstrak dari transaksi karena SPSK tidak mengirimkan tagihan/ invoice penjualannya ke Fina.
SPSK Balance FINA-SPSK combined report yang membandingkan nilai pembayaran agen yang di-posting oleh FINA dengan nilai pembayaran agen yang diterima oleh SPSK. Selain pembayaran, report ini juga menyajikan informasi saldo tagihan agen untuk mambantu kontrol saldo. Data Saldo Awal, Omzet, CM, DM, dan Premi di ambil dari SPSK melalui proses sinkronisasi. Sinkronisasi dilakukan secara "lazy-loading" saat report di buka.
SPSK Balance Summary SPSK report yang menyajikan balance summary per wilayah distribusi (sirda) per bulan selama setahun. Report ini disediakan oleh FINA karena aplikasi SPSK yang sekarang sudah tidak dikembangkan lagi. Data Saldo Awal, Omzet, CM, DM, dan Premi diambil dari SPSK melalui proses sinkronisasi. Demikian juga informasi wilayah distribusi.
SPSK Console Menu untuk memantau tabel TrxBayar di database SPSK. Tersedia fasilitas untuk update periode, void payment, dll. Hanya boleh digunakan dalam keadaan sangat memaksa di mana alter data langsung memang diperlukan.

AMS Integration planned on Nov 2, 2021

Integration Description
Common Modules Cash Receipt, Bank R/C Import, Bank Statement, A/R Invoicer, A/R Tracking. Modul-modul tersebut direncanakan untuk menggantikan SAP IS/MAM yang selama ini digunakan untuk menerbitkan invoice iklan.
AMS Order Post to FINA Order/ Paket dari AMS yang sudah disepakati bersama client di-posting masuk ke Fina menjadi invoice. Informasi Customer akan diekstrak dari order. Tujuan dari perubahan ini agar Paket AMS di update sesuai dengan iterasi dealing dengan customer, mengurangi proses dengan Excel, meniadakan double input.

GMMS Integration planned on Mar 15, 2022

Integration Description
Common Modules Material & Service Receiving untuk penerimaan barang dan jasa, Pre Payment (BS), Invoice Down Payment untuk mencatat invoice dengan DP, A/P Invoice untuk mencatat tagihan dari supplier, realisasi DP dan BS.
GMMS GR Post Informasi Penerimaan barang dan jasa dari supplier yang dicatat oleh GMMS/GR diposting ke FINA masuk ke tabel Material & Services. Data dapat "dipanggil" ketika invoice (AP) dibuat. Data GR yang diterima oleh FINA termasuk: Product Vendor
GMMS A/P Invoice Karena tidak tersedia modul invoice (A/P) di GMMS maka dapat menggunakan modul A/P Invoice di FINA. Jika memang diperlukan dan ada "kekhususan" maka akan dibuat modul A/P Invoice di GMMS yang langsung terintegrasi dengan A/P Invoice FINA.
GMMS Product Category Synch. Setiap perubahan di master GMMS Product Category akan disinkronisasikan ke master FINA Product Category. Master: GMMS, Slave: FINA.
GMMS Product Usage Synch. Setiap Perubahan di master GMMS Product Usage akan disinkronisasikan ke master FINA Product Usage. Master: GMMS, Slave: FINA.
GMMS Budget Synch. Master Budget di GMMS akan mengacu ke master budget FINA
GMMS G/L Account Synch. Master G/L Account dan addressing di GMMS akan mengacu ke master COA dan COA Addressing di FINA

HR KG Media (New Tribun HR) Integration planned on Jun 13, 2022

Integration Description
Common Modules AP Invoice untuk pembayaran pinjaman ke karyawan, AR Invoice untuk mencatat piutang ke karyawan.
Pinjaman Karyawan di approve Pinjaman karyawan yang sudah di approve secara otomatis akan menghasilkan 1 invoice AP untuk pembayaran dan 1 invoice AR untuk cicilan. Nilai yang masuk ke AP Invoice dan AR Invoice adalah nilai gelondongan (total), bukan nilai per individu. HR KG Media perlu memelihara semacam AP dan AR untuk memantau pinjaman pada tingkat yang lebih detail.
Cicilan Pinjaman karyawan (potong gaji) (belum di bahas) Beberapa alternatif:
  • Langsung masuk ke AR sehingga mengurangi piutang kepada karyawan
  • Melalui mekanisme penerimaan pembayaran, dengan payment method "potong gaji"
  • Lainnya
Rencana Dinas di approve Rencana Dinas yang sudah di approve akan menghasilkan "approved" BS dan "processed" PD jika rencana dinas tersebut menggunakan BS.
Pertanggungjawaban Dinas di approve Pertanggungjawaban Dinas yang sudah di approve akan menghasilkan "approved" AP Invoice. Jika sebelumnya menggunakan BS maka installment BS nya akan melekat. Kekurangan dana perjalanan akan menghasilkan installment bertipe reimburse.

Tribun Kecil Skenario planned on Jun 13, 2022

Integration Description
Common Modules belum di putuskan
Ada 2 pendekatan solusi untuk Tribun dengan operator terbatas:
  1. Membuat 2 layar bypass untuk mencatat receipt dan payment. 2 layar tersebut akan langsung menghasilkan receipt voucher dan payment voucher, mengupdate AR dan AP,
  2. Membuat 2 layar bypass untuk mencatat receipt dan payment. 2 layar tersebut akan langsung menghasilkan receipt voucher dan payment voucher, mengupdate AR dan AP, dan secara otomatis juga akan mengisi tabel-tabel di arus penerimaan dan pembayaran (cash, bank statement, bank allocation, installment, slip).

FINA Technical

Architecture & Technology Stack

Fina dapat dilihat dari tampilannya. Namun, di balik tampilan tersebut sebenarnya Fina terdiri dari beberapa bagian (subsystems) yang memiliki fungsinya masing-masing dan menerapkan teknologi yang berbeda-beda. Bagian-bagian itu ditata menganut konsep API-driven architecture.

Tentang API
API (Application Programming Interface) adalah suatu perantara (intermediary) yang memungkinkan suatu sistem atau aplikasi berbicara satu sama lain. Melalui API, sebuah aplikasi dapat mengakses dan mengolah informasi yang dikelola oleh aplikasi lain.
Manfaat API semakin penting di masa sekarang karena jangkauan sistem sudah tidak dapat dibatasi hanya Windows on PC/ Notebook saja, namun juga menjangkau perangkat bergerak seperti smartphone dan tablet.
Tentang API-driven Architecture
Pada dasarnya, API-driven Architecture atau juga disebut API-first Architecture adalah suatu pendekatan perancangan software yang berpusat pada API untuk menciptakan sistem-sistem yang dapat berinteraksi satu sama lain dengan mudah.
Melalui pendekatan ini akan tercipta ekosistem aplikasi yang modular, reusable, dan scalable, seperti mainan LEGO®.
Fina Application
Inilah satu-satunya sub sistem Fina yang dikenal dan di-bookmark oleh User. Sub sistem ini diakses melalui alamat http://fina.kgmedia.com. Tugasnya menyediakan layar-layar tampilan sehingga User dapat melakukan interaksi dengan sistem.
Layar-layar Fina menerapkan "Responsive Design" yang dapat menyesuaikan tampilan di berbagai macam ukuran layar (hp, tablet, notebook, printer).
Fina API
Sub sistem ini menjadi jembatan dari dan ke Bisnis Logic, tabel-tabel data, dan file-file yang dikelola oleh Fina. Selain melayani permintaan data atau proses dari Fina Application, sub sistem ini juga dapat melayani permintaan data dan proses dari sistem-sistem lain.
Fina API mengikuti kaidah (non-standard) JSON Web API. Format nya sangat mudah dipahami dan konsisten diterapkan di seluruh sub sistem ini
Fina Business Logic
Aturan-aturan bisnis, SOP, alir kerja, algoritma, cara baca data, dan hal-hal semacam itu disimpan di dalam sub sistem ini dalam bentuk program-program kecil (subroutines/ codes) yang siap dieksekusi oleh API. Contoh-contoh program kecil itu antara lain: BankRead(), BankSave(), BankStatementRead(), CashTransactionSave(), AllocationSave(), dll.
Secara teknis, program-program kecil tersebut adalah SQL Stored Procedures dan SQL Stored Functions
Fina Database Server & File Server
Sub sistem ini adalah "gudang" penyimpan data. Kebanyakan data yang dilihat dan diolah oleh User melalui layar tampilan Fina disimpan dalam tabel-tabel 2 dimensi (kolom dan baris) di dalam sistem manajemen database (RDBMS/ Relational Database Management System). Contoh tabel-table tersebut misalnya: CustomerTable, BankStatementTable, dan CashTransactionTable.
Data berbentuk file di simpan ke dalam folder-folder di server. File-file tersebut masuk ke Fina dengan cara upload, dan dapat ditarik dengan cara download. Contoh file yang disimpan: File MT940 dan file-file attachment.
Technology Stack
Web Server:IIS on Windows Server 2012
Server Side App:C#, Razor on Microsoft ASP .Net MVC 4.5.2
Database SideMicrosoft SQL Server 2012
Client Side:HTML5, CSS3, Javascript (ES5)
Libraries:JQuery, Bootstrap 3.3.7, Select2, Moment.js

Object Access Control

Action based Security
Pengamanan akses yang sudah diterapkan di seluruh sistem di Kompas (FastKom, Sitika, GMMS, dll). Pengamanan ini membatasi seorang USER untuk menjalankan PROSES (action) tertentu, misalnya Bank Save, Organization Delete, PO Approve, dll. Hanya User yang berhak dapat mengeksekusi proses-proses (actions) tersebut.
Data Ownership based Security
Pengamanan akses untuk menjaga kepemilikan data (Data Ownership) di dalam sistem yang multi-organization. Seorang User yang memiliki hak akses untuk meng-approve PO (PO Approve) dapat dibatasi agar proses approval dilakukan hanya untuk PO organisasi tertentu dan rentang nilai PO tertentu saja
Object State based Security
Pengamanan ini berfokus pada Workstate atau status object di dalam alir kerja (workflow), untuk mencegah proses yang tidak sah dilakukan pada object dengan status tertentu.

How to read our ERD

Entitas (Entity)
Definisi Entity menurut Collins: "Sesuatu yang benar-benar ada yang bisa dibedakan dengan yang lain dan punya identitas yang jelas". Pengertian Entity bisa berbeda-beda, misalnya di perpajakan, entitas artinya Orang/ Organisasi berbadan hukum. Contoh-contoh entitas di Fina: Customer, Bank, BankStatement, Currency, User, BP, InternalOrganization, Address, dll.
ERD = Entity Relationship Diagram
Entitas-entitas di suatu sistem biasanya terhubung satu sama lain. ERD adalah diagram yang menjelaskan hubungan antar entitas tersebut. Ada beberapa notasi (cara penulisan) ERD. Di Fina ERD dituliskan dalam notasi Crow's foot.
Cardinality
Hubungan antara dua entitas digambarkan dengan garis yang menghubungkan kedua entitas. Simbol di kedua ujung garis menyatakan "cardinality", yaitu banyaknya suatu entitas terhadap entitas lain yang dihubungkan.
Colouring
Semakin besar sistem, semakin banyak pula entitas-nya, semakin tidak mungkin menggambarkannya dalam satu ERD. Untuk mengatasinya, ERD dipecah-pecah sehingga masing-masing hanya menerangkan satu bagian sistem atau satu kelompok entitas. Pewarnaan akan memberi fokus pada konteks, topik, dan entitas yang sedang di-model-kan.
Mengapa ERD?
Ada banyak cara pemodelan: ERD, UML, ORM, dll. Namun ERD punya keunggulan dalam perancangan relational-database karena dapat memetakan secara langsung tabel-table di database.

How to read our Workflow Diagrams

Workflow
Workflow atau "alir kerja" adalah serangkaian kegiatan untuk menyelesaikan suatu pekerjaan. Suatu aktivitas (activity) mencakup serangkaian aksi (action) dan melibatkan beberapa obyek/ entitas (object/ entity). Contoh: Workflow pembuatan BS melibatkan entitas dokumen BS, dokumen PD, dll.
Workstate
Workstate adalah status (state) suatu entitas di dalam alir kerja (workflow). Contoh: Entitas (dokumen) BS yang baru dibuat akan berstatus New. Ketika BS tersebut dikirimkan ke atasan untuk mendapat approval statusnya akan berubah menjadi Need Approval. New, Need Approval adalah workstate.
Perubahan workstate (workstate-transition) disebabkan karena terjadi aksi (action) pada suatu entitas (object). Salah satu peran penting sebuah sistem adalah mengelola perubahan workstate dan menetapkan aksi yang diijinkan pada workstate tertentu.
State Diagram dan Activity Diagram
Ada 3 jenis diagram yang digunakan oleh Fina untuk menjelaskan suatu alir kerja (workflow), yaitu:
  1. Workflow Diagram dalam notasi Flowchart
  2. State Diagram dalam notasi Directed Graph/ FSM karena sederhana dan sudah cukup untuk menjelaskan perubahan status (state-transition) suatu obyek/ entitas (object/ entity).
  3. Activity Diagram dengan notasi UML 2.0 karena selain dapat menjelaskan rangkaian aksi di dalam alir kerja juga dapat menjelaskan obyek/ entitas (objects/ entities) yang terlibat.

Why not stick to UML?

Activity Diagram dan State Diagram dengan notasi yang [jauh] lebih kompleks sudah menjadi bagian dari Behavioral UML Diagrams (ISO Standard). Namun, kompleksitas dan tingkat adopsi UML yang relatif rendah, menjadikannya sulit digunakan untuk membangun kesepahaman dengan berbagai pihak (tujuan dokumentasi ini). Ada catatan menarik,

"In software engineering, most practitioners do not use UML, but instead produce informal hand drawn diagrams; these diagrams, however, often include elements from UML"

— Unified Modelling Language, 5th paragraph. Retrieved 3 Sep 2023.

"Some people (including Jacobson, a major contributor to UML) feel that UML's size hinders learning (and therefore, using) it."

— Unified Modelling Language, last paragraph. Retrieved 20 Dec 2021,

Fina Project

Initial project timeline seperti tertulis di dokumen Desain Usulan 2, mencakup 37 hari kerja.

Project Team

Yustinus Edi SusiloAccounting KompasProject Manager
Juanda Eka SetiawanKompas Product Sales ManagerRepresentative
HussintoAccounting KompasBusiness Analyst, Financial Analyst
Adiyan Randal SingarimbunSirkulasi Kompas GramediaBusiness Analyst - Marketing
EriyantoSirkulasi Kompas GramediaBusiness Analyst - Marketing
EliadaSirkulasi Kompas GramediaBusiness Analyst - Back Office
Yettie KrisnhaCorp. FSDFinancial Analyst, implementor
Prima DyahCorp. FSDFinancial Analyst, implementor
Darma DatuCorp. FSDFinancial Analyst, implementor
RudyantoTI Kompas/ GoMedProject liaison, implementor
Heru MargowiyonoTI Kompas/ GoMedSystem Analyst, programmer
Daniel KurniawanTI Kompas/ GoMedSystem Analyst, programmer
Mukhlis WicaksonoTI Kompas/ GoMedProgrammer
Immanuel SaragihTI Kompas/ GoMedProgrammer
RohimamTI Kompas/ GoMedProgrammer
Wiwik DyahTI Kompas/ GoMedSQA, implementor
Setyo SabdonoTI Kompas/ GoMedSPSK matter-expert

Project Log

21 Juli 2020
Online Meeting (Marketing/SKG/ Accounting/ FSD/ CITIS/ IT).
  • Agenda: Persoalan kontrol saldo agen SKG menggunakan sistem SPSK
  • Disampaikan: masalah kelambatan status pembayaran adalah masalah global di KG apalagi sejak Mei 2018 ketika kasir berpindah ke sistem SAP
  • Disampaikan: Sudah disepakati berulangkali agar CITIS membuka akses API di SAP namun belum terealisasi.
  • Disepakati: Menjajaki 2 alternatif solusi: 1. Membuka API di SAP (CITIS), 2. Mengembangkan sendiri sistem penerimaan pembayaran (TI Kompas)
  • Disepakati: CITIS dan TI Kompas masing2 akan men-submit usulan dan timeline nya ke Sdr. Agus Ramdhani (GM IT Enterprise Solution GoMed)
5 Agustus 2020
Rapat Penyusunan Usulan 2 (FSD/ IT)
  • Agenda: Menyusun spesifikasi Usulan 2 (mengembangkan sendiri)
  • Ditemukan: Proses manual identifikasi pembayar (agen) memakan waktu, berpotensi menjadi penghambat utama kelancaran informasi pembayaran.
  • Ditemukan: SPSK ternyata sudah ada penerimaan pembayaran sederhana (spt kasir)
7 Agustus 2020
Desain Usulan 2 (TI Kompas) di submit ke Bp. Agus Ramdhani
21 Agustus 2020
Online Meeting (Marketing Kompas/ SKG/ Accounting/ FSD/ CITIS/ IT).
  • Agenda: Memutuskan akternatif solusi penerimaan pembayaran (SPSK)
  • Disepakati: Usulan-2 (mengembangkan sendiri) dipilih
  • Disepakati: Pengembangan akan dimulai setelah tim TI dan FSD selesai melakukan pengembangan dan implementasi GMMS di Harian Kompas (rencana: 1 November 2020)
    Note: Implementasi GMMS di harian Kompas baru dimulai 1 Desember 2020 (mundur 1 bulan) sehingga menunda kickoff proyek ini.
10,11,14 Des 2020
Rapat Penyusunan Spesifikasi Sistem (SKG/ Accounting/ FSD/ IT)
  • Project Kickoff
  • Penetapan tim proyek
  • Disampaikan: Gambaran umum sistem2 keuangan, kendala, dan ekspektasi
  • Disampaikan: Kendala-kendala dan ekspektasi-ekspektasi operasional di SKG
  • Disampaikan: Skenario dan alternatif integrasi SPSK dengan sistem yang akan dikembangkan
  • Disepakati: SPSK tidak ada perubahan, integrasi dengan sistem penerimaan pembayaran yang baru melalui jalur import yang sudah tersedia di SPSK.
  • Dikirimkan: Screnshot layar2 Bank Handling (Yettie via WA)
  • Outstanding: Screenshot layar2 Kasir akan menyusul karena FSD belum bisa simulasi.
21 Desember 2020
Briefing ke tim teknis, Basic Accounting, Design Overview, Project Overview. Fina for Developer
24,28,29,30,31 Des 2021
Libur Natal, Tahun Baru beberapa anggota tim cuti secara bergantian. Proyek kembali aktif: 4 Januari 2020.
13 Januari 2021
WFH@Yettie
  • Disampaikan: modul-modul pengelolaan master data yang sudah selesai (demo)
  • Disampaikan: mockup layar Bank Statement (masih tanpa valas)
  • Disampaikan: untuk bank-bank tertentu, sandi BI mengacu ke kantor pusatnya.
  • Disepakati: perlunya penambahan entitas Sales Org karena invoice diinput manual (AR belum ada tahap ini). Jalur [Customer-->Applikasi] belum cukup untuk merujuk entitas organisasi yang menerbitkan invoice.
  • Outstanding: Screenshot layar kasir, Daftar Transaksi Bank dan Kasir, Daftar House Bank Kompas (sample saja)
15 Januari 2021
WFH@Yettie
  • Disampaikan: Update mockup layar Bank Import dan Bank Statement
  • Disampaikan: Rekening setoran kasir hanya 2, milik Kompas atau Gramedia. Bukan disetorkan langsung ke Sales Org yang bertransaksi.
  • Disepakati: Penambahan "Required Bank Issuer" di master Payment Type
  • Disepakati: Penambahan "Swift Code" dan "IBAN Code" di master Bank
  • Disepakati: Bank Account tidak harus merujuk ke Master Bank untuk antisipasi data Bank Account yang dipost dari sistem pengumpan. Bank Account yang di "manage" tetap harus merujuk ke Master Bank
  • Outstanding: Screenshot layar kasir CMS
  • Outstanding: Daftar kode transaksi yang akan digunakan di Bank dan Cash Counter, termasuk mapping-nya
  • Outstanding: Daftar House Bank Kompas
27 Januari 2021
WFH@Yettie
  • Disampaikan: Draft skenario valas karena perbedaan mata uang antara: Invoice, Bank Account, Sales Org, Organisasi pemilik rekening (Kompas/ Gramedia)
  • Disampaikan: Layar Kasir CMS (ditunjukkan)
  • Disepakati: Mockup layar Bank Import dan Bank Statement (perubahan bisa terjadi karena skenario valas)
  • Outstanding: Skenario Forex transaksi penerimaan pembayaran di Bank
  • Outstanding: Skenario Forex transaksi penerimaan pembayaran di Cash Counter/ Kasir
  • Outstanding: Daftar kode transaksi yang akan digunakan di Bank dan Cash Counter, termasuk mapping-nya
  • Outstanding: Kesepakatan mockup layar Cash Receipt (kasir)
1 Februari 2021
WFH@Yettie
  • Disepakati: Tanggal transaksi Kasir faktual sesuai tanggal sistem, namun tanggal posting boleh diubah dengan approval atasan di Cash Counter
  • Disepakati: Posting transaksi Kasir bisa dilakukan atas seluruh transaksi hari itu atau per transaksi. Tanggal postingnya boleh diubah
  • Outstanding: Skenario Forex transaksi penerimaan pembayaran di Bank
  • Outstanding: Skenario Forex transaksi penerimaan pembayaran di Cash Counter/ Kasir
  • Outstanding: Daftar kode transaksi yang akan digunakan di Bank dan Cash Counter, termasuk mapping-nya
  • Outstanding: Kesepakatan Mockup layar Cash Receipt (kasir)
3 Februari 2021
WFH@Yettie
  • Disampaikan: Perlu dibuat menu di Cash Counter yang berbeda dengan menu Customer untuk mencatat mata uang asing yang dibeli dengan mempertahankan nilai tukar saat mata uang tersebut dibeli.
  • Disepakati: Penomoran transaksi penerimaan pembayaran di Cash Counter (Kasir) tidak perlu mencantumkan kode cash counternya (ikut cara SAP sekarang). Format: [StaticCode]-[Year]/[Sequence]. Misalnya: PR-2021-00000001. Agar format penomoran bisa diatur maka Fina akan menyediakan master penomoran seperti di GMMS.
  • Dinikmati: Bakmi Surya Gading Serpong
  • Disepakati: Skenario Forex transaksi penerimaan pembayaran di Bank (dikirimkan oleh Prima ke WAG)
  • Disepakati: Skenario Forex transaksi penerimaan pembayaran di Cash Counter/ Kasir (dikirimkan oleh Prima ke WAG)
  • Disepakati: Mockup layar Cash Receipt (kasir)
  • Disepakati: Penggunaan running-balance di Bank dan di Cash Counter
  • Outstanding: Daftar kode transaksi yang akan digunakan di Bank dan Cash Counter, termasuk mapping-nya
18 Februari 2021
Diskusi Online Tim Teknis
  • Peserta: Daniel, Heru Margowiyono, Rudyantos
  • Disampaikan: Semua modul selesai di coding (total 43 hari kerja, terlambat 6 hari dari rencana semula 37 hari kerja)
  • Disampaikan: Security belum dipasang karena menunggu input data awal dan testing fungsi (butuh 1 minggu untuk pasang dan test)
  • Disampaikan: Berdasarkan log, belum ada data awal diinput kecuali oleh tim teknis sendiri, belum ada testing kecuali internal tim teknis sendiri, belum ada evaluasi apapun sejak rapat pertama 10 Des 2020.
  • Disepakati: Jika tidak ada masukan baru, security akan di pasang, dokumentasi diupdate sesuai kondisi terakhir, dan tim mendorong agar proyek bisa dinyatakan selesai
19 Februari 2021
WFH@Yettie
  • Disampaikan: Tim teknis sudah menyelesaikan seluruh modul, jika tidak masukan maka pekerjaan teknis dapat dianggap selesa (setelah security dipasang, dokumentasi disesuaikan kondisi terakhir).
  • Disampaikan: Keputusan tentang deposit dana di cash counter --> gabungan antara cara SAP dengan CMS
  • Didemokan: Cash Transaction, Cash Counter Activity (CheckIn, CheckOut, Rest), Bank Import, Bank Statement, Cash Receipt Posting, Payment List
  • Gagal didemokan: Proses menggeser tanggal posting Cash Transaction (proses sudah tapi input tanggal posting belum ada).
  • Gagal didemokan: Input manual di Bank Import karena masalah sequence data yang diketikkan, input upload juga gagal didemokan karena tidak ada file MT940 yang sesuai
  • Disepakati: Informasi yang muncul di payment list sudah OK jika Nomor Invoice ditampilkan.
  • Disepakati: Customer yang dipilih dalam transaksi-transaksi Bank dan Cash adalah customer masing-masing aplikasi (bukan gabungan-nya) supaya statusnya dapat dikembalikan ke aplikasi sumber nya. Satu transaksi bisa melibatkan lebih dari satu customer (asal makhluknya sama).
  • Disepakati: Posting Cash Transaction akan mengubah workstate transaksi menjadi "Need Approval" jika:
    • Atasan ada, terdefinisi dalam hirarchy di cash counter
    • Transaksi tidak di-posting di tanggal yang sama dengan tanggal transaksi penerimaan
    • Tanggal posting di geser mundur (back date)
    Atasan tinggal melakukan posting ulang, sehingga workstatenya berubah menjadi "Posted". Kecuali kondisi tersebut di atas, transaksi akan langsung berubah menjadi "Posted".
  • Disepakati: Workflow Cash Receipt. Tidak perlu ada proses UNCONFIRM menjadi CONFIRM karena dilakukan oleh orang yang sama.
  • Disepakati: Tim FSD membutuhkan waktu 1 minggu untuk test fitur2 FINA
  • Disepakati: Penerimaan pembayaran sebagian nilai invoice/ pembayaran tidak penuh (tidak sengaja terakomodir di Fina karena invoice tidak ada, siap di turn-off di kemudian hari jika dikehendaki)
  • Disepakati: Transaksi (cash) yang sudah di-posting tidak bisa dianulir namun bisa dikoreksi dengan transaksi kebalikannya
  • Disepakati: Tolakan kliring bank (BG, etc) dilakukan dengan menginput amount negative.
  • Outstanding: Daftar kode transaksi yang akan digunakan di Bank dan Cash Counter, termasuk mapping-nya
  • Outstanding: Test dan konfirmasi fungsi-fungsi yang sudah jadi
24 Februari 2021
Online Meeting (undangan Kompas Product Marketing)
  • Agenda: Evaluasi progress proyek
  • Hadir: Juanda (pengundang), Sinto, Eriyanto, Daniel, Rudyanto, Heru Margowiyono
  • Disampaikan: Secara teknis sudah selesai per 18 Februari 2021, security belum dipasang agar fungsi2 bisa di test. Saat ini tim teknis terus malakukan iterasi test, peningkatan dan perbaikan bersama SQA (Wiwik).
  • Disampaikan: Tim FSD sedang melakukan evaluasi pada fitur2 FINA yang sudah ada (1 minggu, mulai Senin 22 Februari 2021)
  • Didemokan: Overview layar2 Kasir, Bank Import, Bank Statement, Payment List
  • Disepakati: Report pembayaran agen per periode waktu (customer per periode) untuk membantu pemantauan saldo agen
  • Disepakati: Pemantauan saldo akan dilakukan dari 2 sistem SPSK dan FINA karena omzet belum mengalir ke FINA
  • Disepakati: Mas Sinto akan melaporkan progress kepada Bp. Edi. Akan diadakan meeting untuk evaluasi dan persiapan langkah selanjutnya, menunggu kesiapan tim FSD dan Bp. Edi
26 Februari 2021
Diskusi Online Tim Teknis
  • Peserta: Daniel, Setyo Sabdono, Heru Margowiyono (terpisah)
  • Disampaikan: Masih menunggu kabar tentang timing posting pembayaran ke SPSK, apakah disaat bank dan kasir posting ke Payment List atau di-posting dari PaymentList.
  • Disepakati: Improvement, posting pembayaran dari Fina ke SPSK tidak melalui download-upload file DBF tapi melalui API. Mekanisme ini dinilai lebih cepat dan reliable
  • Disepakati: Improvement, posting pembayaran dari Fina ke SPSK tidak dilakukan per-batch sehingga real-time dan tidak perlu menunggu proses akhir hari di kasir atau bank
  • Disepakati: Data yang tidak valid tidak akan terposting ke SPSK (periode tutup, dll), user control dilakukan langsung dari layar FINA.
  • Disepakati: Mapping tabel dbo.PaymentTable di Fina ke dbo.TrxBayar di SPSK
  • Disepakati: Procedure dbo.PaymentPostSPSK akan difinalisasi hari Senin, 28 Februari 2021.
4 Maret 2021
Diskusi Online (Dadakan sehabis Rapat atas undangan Agus Ramdhani)
  • Peserta: Daniel, Yettie, Prima
  • Disampaikan: Masih menunggu kabar tentang timing posting pembayaran ke SPSK, apakah disaat bank dan kasir posting ke Payment List atau di-posting dari PaymentList.
  • Disampaikan: Tanggal 3 Maret 2021 di diskusi internal KG Media IT (AHA, DAN, YON, RDY) disepakati modul AR dan Invoice adalah modul yang paling besar berdampak pada integrasi sistem2 sales sehingga akan diusahakan agar prioritas pengembangan berikutnya mengarah ke modul AR tersebut.
  • Disepakati: Posting ke sistem asal (SPSK) dilakukan bersamaan dengan posting Cash dan Bank ke Payment List. Jika terjadi kesalahan (posting gagal) maka transaksi penerimaan pembayaran dicegah masuk ke Payment List. Berhenti di Cash dan Bank dengan status "Posting Gagal"
  • Disepakati: Di Payment List ada proses harian untuk membuat bukti kas. Proses itu akan dilakukan akhir hari.
  • Disepakati: Beberapa transaksi penerimaan pembayaran dapat digabungkan menjadi satu jika:
    • Cash Counter atau Bank Account nya sama
    • SalesOrg yang sama
    • Application yang sama
  • Disepakati: Nomor Referensi di Payment List harus ikut dibawa ke Bukti Kas
  • Disepakati: Pertemuan IT Media dengan FSD akan dilakukan setiap hari Selasa, dengan topik-topik terkait proyek bersama: GMMS, FINA, dll
8 Maret 2021
Diskusi Online (undangan Bp. Juanda, Marketing Produk)
  • Peserta: Pak Titus, Juanda, Terry, Edi Susilo, Sinto, Eriyanto, Yono, Daniel, Yettie, Prima
  • Disampaikan: Status proyek per 8 Maret 2021
  • Disepakati: Yang meng-upload RC Bank tetap SKG karena rekening Bank untuk SKG selama ini dipegang oleh Mas Eliada.
  • Disampaikan: Diharapkan ada kontrol dipihak penerbit terkait pembayaran
  • Disampaikan: Sedang akan disepakati ulang kerjasama-kerjasama termasuk dengan SKG, akan termasuk proses-proses dengan FINA
  • Disepakati: Akan diadakan pertemuan dengan SKG untuk mengawali implementasi FINA, dimulai dari Sirda-Sirda di Jakarta
  • Disampaikan: Diharapkan 1 April 2021, FINA sudah mulai dijalankan
  • Disepakati: Laporan progress mingguan ke Pak Edi.
  • Disepakati: Pertemuan dengan user akan diadakan Selasa, 16 Maret 2021.
  • Outstanding: Format Bukti Kas yang bisa diterima oleh SAP, format laporan ke SAP.
16 Maret 2021
Rapat Rutin FSD IT Media
  • Disepakati: Penambahan "Company Code" di struktur organisasi
19 Maret 2021
Sosialisasi Fina kepada Front Office dan Cashier SKG Jabodetabek (Offline)
  • Disepakati: Modul Cash dan Bank mudah dioperasikan oleh tim SKG untuk selanjutkan perencaan training dan GO LIVE
  • Disepakati: Jika terjadi kesalahan input alokasi payment dan sudah di-posting maka dilakukan proses KM,DM sesuai SOP (SAP)
  • Disampaikan: Pembayaran type GIRO pengakuan pembayaran mengekuti SOP saat ini
  • Disepakati: User diatur hak aksesnya hanya boleh alokasi terhadap no rekening yang di ijinkan
  • Disepakati: Batasan Backdate tetap mengikuti SOP sekarang proses approval dilakukan di pusat (Mas Ely, Mas Erwan)
  • Disepakati: Monitoring alokasi data di Bank Statement dilakukan oleh Mas Ely , Mas Erwan memastikan tidak ada data yang gantung
  • Disepakati: RC dari bank yang didapat tidak realtime ini dikarenakan adanya proses konsolidasi data antar bank , proses alokasi dilakukan seperti SOP sekarang
  • Disepakati: Pilot Project : Sirda Fatmawati dan Gajahmada
  • Disampaikan: Proses refund akan dikembangkan di staging berikutnya baik model full atau sebagian
  • Disampaikan: Proses Cashier akan di import ke SAP setelah Closing Cashier dan proses Bukti Kas
25 Maret 2021
Rapat Online (Product Marketing, Accounting, SKG, FSD, IT)
  • Disampaikan: Butuh fungsi Refund, Koreksi (transaksi koreksi) di FINA untuk koreksi kesalahan input kasir.
  • Disampaikan: Sedang dikembangkan fungsi paste area sebagai alternatif yang lebih untuk meng-upload RC bank selain MT940. Paste area untuk mengupload excel, csv, dll.
  • Disampaikan: Rencana implementasi awal Gama dan Fatmawati, sementara upload ke SAP dibantu oleh FSD.
  • Disampaikan: Informasi pembayaran langsung mengalir ke SPSK ketika transaksi penerimaan di-posting dari Cash dan Bank.
  • Disampaikan: Sebaiknya rekening bank dikelola di KGMedia (inkaso) atau Akunting Kompas (sekarang di Dana)
  • Disampaikan: Data RC bank yang bisa ditarik hanya BCA, yang lainnya dikirimkan lewat email, kadang tidak rutin setiap hari.
  • Disepakati: Input alokasi bank dilakukan oleh masing-masing Sirda, posting tetap dilakukan oleh tim SKG Mas Eliada.
  • Disepakati: Alokasi untuk sirda-sirda yang belum menggunakan FINA (masa transisi) dilakukan oleh tim Mas Eliada. Supaya baris RC tersebut teralokasi penuh.
  • Disepakati: Target terbaru go live implementasi: 12 April 2021 di Gajahmada dan Fatmawati, tanpa fungsi refund dan koreksi. Sementara fungsi tersebut dilakukan manual di SAP dan SPSK oleh tim SKG Mas Eliada.
29, 30 Maret 2021
Rapat Rutin FSD IT Media
  • Disepakati: Roadmap Pengembangan Business System KG Media.
  • Disepakati: Currency Conversion, tidak ada perubahan dari kesepakatan
  • Disepakati: Deviasi akan diinput per baris alolasi, disimpan dalam baris yang sama di Payment, namun akan dipecah menjadi pembayaran dan biaya atau pendapatan selisih kurs
  • Disepakati: Deviasi juga akan diinput di header disertai pilihan alasan deviasi
  • Disepakati: Penambahan filter WorkstateID dan Tanggal Transaksi di Cash Transaction History
  • Disepakati: Untuk transaksi BG, posting bisa belok menjadi "Outstanding" jika tanggal jatuh tempo BG masih jauh.
  • Disepakati: Bukti Kas Penerimaan digunakan juga sebagai Bukti Bank. Nama Document: Receipt Voucher. Untuk pembayara akan ada dokumen lain yaitu: Payment Request (pesanan dana), bukti Bank tidak perlu dibuat tapi ditulis oleh admin di Payment Request tersebut.
  • Disepakati: Bukti Kas Penerimaan (Receipt Voucher) akan merujuk ke COA yang dikelola di FINA. Struktur data sudah disepakati. Proses GL sendiri baru akan dibangun di fase paling akhir dari pengembangan FINA.
  • Disepakati: Secara umum, target COA tidak akan dilekatkan ke entitas-entitas transaksi seperti CUSTOMER, ORGANIZATION, dll. Target COA akan ditentukan menggunakan COA Addressing Logic. Di versi FINA 1.1, COA Addressing logic akan dibuat khusus untuk addressing COA di proses Bukti Kas.
  • Outstanding: Selisih waktu (tanggal) BG yang boleh di-posting, akan ditanyakan FSD ke Kasir
  • Outstanding: Proses-proses lain di Bank Statement dan Cash Counter selain alokasi ke pembayaran.
1,2,3,4 April 2021
Kamis Putih, Jumat Agung, Paskah, very long weekend
5 April 2021
Pengembangan FINA v1.1 dimulai sesuai kesepakatan dalam roadmap. Target selesai: 30 April 2021. Hanya beberapa fitur yang akan masuk dalam implementasi 12 April 2021, karena tim teknis masih harus deploy ke production server dan memasang security2 (7 work days full team).
  • Bukti Kas Penerimaan (Receipt Voucher)
  • Refund, Correction
  • Paste Area
  • SPSK Agency Integration
  • COA, COA Addressing (hanya untuk proses bukti kas)
6, 7 April 2021
Rapat rutin IT Media & FSD.
  • Disampaikan: Deviasi di Bank Allocation sudah jadi, siap di coba
  • Disampaikan: COA dan kelengkapannya sudah jadi, siap dicoba
  • Disepakati: Kelengkapan data dan UI COA sudah ok
  • Disepakati: Penerapan forex (cash dan bank) sudah sesuai skenario forex, tidak ada perubahan.
  • Disepakati: Ada proses-proses lain setara alokasi di Bank Statement yaitu Penerimaan Customer (alokasi yg sekarang), Penerimaan Supplier, Titipan Customer, Titipan Internal, Biaya Bank, Jasa Giro, Selisih Kurs, Selisih Bayar
  • Disepakati: Jenis-jenis transaksi alokasi akan didaftarkan ke Transaction Type
  • Disepakati: Penambahan "for Allocation" di Transaction Type
  • Disepakati: Transaction Type Mapping perlu dibuka untuk semua transaksi, perlu penambahan parameter debit/ credit.
  • Disepakati: Deviasi di Bank Alokasi di drop, deviasi berupa biaya atau pendapatan muncul sebagai baris baru (setara alokasi).
  • Disepakati: Bukti Kas menjadi 2 dokumen: Receipt Voucher (Bukti Kas Masuk) dan Payment Voucher (Bukti Kas Keluar). Struktur data sudah disepakati.
  • Disepakati: Penambahan kriteria pengelompokan bukti kas dari proses payment.
  • Disepakati: Proses Correction (koreksi) diarahkan menggunakan CM/DM, tidak disediakan fasilitasnya di kasir
  • Disepakati: Proses Refund di kasir sama persis dengan Receipt, tetapi alat bayar hanya Kas saja (tidak semua bisa dipilih)
  • Disepakati: Payment Type (Payment Method) akan ditambah flag: "for Cash Receipt", "for Cash Refund"
  • Disepakati: Pengembangan yang terhubung ke Bank Statement baru akan dimulai setelah 12 April 2021 karena server development masih harus berfungsi dengan skenario proses yang ada.
  • Outstanding: Proses bukti kas akan ditanyakan, datang dari proses mana saja, transaksi-transaksinya termasuk dari proses titipan (BS?)
13, 14 April 2021
Rapat rutin IT Media & FSD.
  • Disepakati: Agenda: Menelusur ulang arus masuk dan keluar kas dan bank agar keseluruhan proses dapat di dokumentasikan
  • Disampaikan: Proses Bukti Kas, proses Bon Sementara, proses Deposit
  • Disampaikan: Deposit tidak hanya dari Customer saja tapi juga datang dari proses BS
  • Disepakati: Bank account untuk penerimaan pembayaran customer akan dibedakan dengan bank account untuk setoran kasir sehingga mempermudah proses alokasi --> SOP
  • Disepakati: Fitur Bon Sementara akan dibuat untuk melengkapi proses di kasir.
  • Disepakati: Di kasir payment, titipan, dan receipt akan diakumulasi menjadi 1 tabel (accumulator), lengkap dengan running-balance nya.
  • Outstanding: Setoran modal kasir menggunakan Deposit, diskusi terputus, kemudian dilupakan tanpa kesepakatan.
  • Outstanding: Skenario penyelesaian BS dan hubungannya dengan penerbitan Bukti Kas
  • Outstanding: Skenario Pembatalan BS dan hubungannya dengan penerbitan Bukti Kas
19 April 2021
Rapat mendadak IT Media & FSD setelah rapat dengan Ibu Sumani.
  • Disepakati: Proses-proses Pengajuan BS (paperless seperti GMMS.Request), Pendanaan BS, Pencairan BS.
  • Disepakati: Posting dari Cash Counter akan langsung menghasilkan Bukti Kas (Voucher). Proses generate voucher dari Payment List diputus.
  • Disepakati: Posting dari Bank Allocation akan langsung menghasilkan Bukti Kas (Voucher). Proses generate voucher dari Payment List diputus.
  • Disepakati: Rapat rutin 20, 21 April ditiadakan, tim IT akan mendokumentasikan mengukur dampak perubahan-perubahan yang disepakati di atas
  • Disepakati: Posting BS Transfer, BS Giro, BS Cheque akan langsung menghasilkan Bukti Bank Keluar (Bank Payment Voucher). BS Tunai (pencairan kasir maupun bank) Bukti Kas Keluar dibuat setelah posting di kasir (Mbak Yettie habis mandi).
  • Disepakati: FSD akan menyusun skenario deposit cash counter, penyelesaian BS, dan pembatalan BS secepatnya (20 April 2021)
  • Outstanding: Skenario deposit kasir dan hubungannya dengan penerbitan Bukti Kas
  • Outstanding: Skenario penyelesaian BS dan hubungannya dengan penerbitan Bukti Kas
  • Outstanding: Skenario Pembatalan BS dan hubungannya dengan penerbitan Bukti Kas
21 April 2021
Diskusi IT, FSD by Chat, Phone.
  • Disampaikan: Hasil diskusi FSD tentang deposit kasir dan bukti kas dan pengisian modal cash counter
  • Disampaikan: Hak akses sudah dipasang, Supplier, Purchasing Org sudah dibuat, COA sudah ditambahkan ke Bank Account.
  • Disepakati: (oleh DAN-YON): FSD gagal dikonfirmasi, deposit kasir dan voucher belum bisa disesuaikan. Enhancement proses kasir tidak mungkin di deliver sebelum rencana implementasi 26 April 2021 (SPSK). No-point rushing, lebih baik IT slowing down menyesuaikan FSD.
  • Disepakati: (oleh DAN-YON): Grouping Kasir dan Bank Admin menjadi employee, hirarki BS menjadi hirarki employee.
  • Outstanding: Skenario pencatatan deposit kasir dan hubungannya dengan penerbitan Bukti Kas
  • Outstanding: Skenario penyelesaian BS dan hubungannya dengan penerbitan Bukti Kas
  • Outstanding: Skenario Pembatalan BS dan hubungannya dengan penerbitan Bukti Kas
22, 23 April 2021
WFH@Yettie, Konfirmasi by phone
  • Disepakati: Skenario deposit di Cash Counter dan penerbitan Bukti Kas, akan segera didokumentasikan agar mengikat
  • Disepakati: Penyelesaian BS kurang bayar dengan membuat BS baru, flow sama.
  • Disepakati: Penyelesaian BS lebih bayar langsung menjadi titipan di kasir jika Cash. Jika transfer atau alat bayar lainnya masih outstanding.
  • Disepakati: BS+ dan BS- tidak masuk menjadi summary Cash Counter, akan di track langsung dari layar BS.
  • Disepakati: Cash BRI (kas tapi ambil di bank) akan masuk menjadi proses kasir, tracking menggunakan fasilitas deposit di kasir.
  • Outstanding: Skenario penyelesaian BS lebih bayar
  • Outstanding: Skenario Pembatalan BS dan hubungannya dengan penerbitan Bukti Kas
28 April 2021
Rapat Rutin TI Media & FSD
  • Disepakati: Mekanisme deposit Cash BRI, penambahan sudah diupdate ke Skenario deposit di Cash Counter
  • Disepakati: Nilai yang masuk ke Cash BRI sesuai dengan jumlah uang yang diminta saja
  • Outstanding: Skenario penyelesaian BS lebih bayar
  • Outstanding: Skenario Pembatalan BS dan hubungannya dengan penerbitan Bukti Kas
5 Mei 2021
Rapat Rutin TI Media & FSD
  • Disepakati: Penambahan Business Area di Organization
  • Outstanding: Skenario penyelesaian BS lebih bayar
  • Outstanding: Skenario Pembatalan BS dan hubungannya dengan penerbitan Bukti Kas
5-31 Mei 2021
Proyek FINA diliburkan karena masa lebaran dan konsentrasi ke proyek GMMS menjelang implementasi di Grid tgl. 1 Juni 2021.
  • GMMS: Penambahan TOP sbg kriteria pemilihan vendor
  • GMMS: Report integrasi ke SAP yang terpending sejak November 2020.
(sesuai dengan Roadmap Pengembangan Sistem Bisnis KG Media yang telah disepakati)
18 Mei 2021
Rapat Rutin TI Media & FSD
  • Disepakati: Skenario deposit di Cash Counter
  • Disepakati: Penambahan link di Bank Account ke Payment Method untuk masalah Cash BRI dan E-Banking di kasir, sekaligus antisipasi untuk auto-credit
  • Disepakati: Laporan Harian Kasir
  • Outstanding: Skenario penyelesaian BS lebih bayar
  • Outstanding: Skenario Pembatalan BS dan hubungannya dengan penerbitan Bukti Kas
1 Juni 2021
Pengembangan FINA v2.0 dimulai sesuai kesepakatan dalam roadmap. Target siap digunakan: September 2021.
  • Deposit (Customer/ Employee/ Organization/ Supplier)
  • Invoicer (Generic)
  • Taxation (PPN K, PPH WABA)
  • Collection
1 Juni - 21 Juli 2021
Pengembangan FINA tertunda karena tim TI dan FSD berkonsentrasi pada implementasi GMMS Media yang mundur 1 bulan.
  • GMMS: Implementasi mundur 1 bulan dari 1 Juni ke 1 Juli, request pertama masuk 8 Juli 2021.
  • GMMS: Tim IT dan FSD terlibat aktif dalam training, konfigurasi, dan baby sitting sampai 21 Juli 2021.
21 Juli 2021
Diskusi Online DAN - YETTIE
  • Disepakati: Simulasi A dan Simulasi B pencatatan deposit dari transaksi penerimaan kasir, split nilai alat bayar ke alokasinya.
  • Disepakati: Transaksi DEPOSIT-IN (debit) dicatat sebagai penambah tagihan yang harus dibayar (sebagai item).
  • Disepakati: Transaksi DEPOSIT-OUT (credit) dicatat sebagai pengurang tagihan yang harus dibayar (sebagai item)
  • Disepakati: Saat transaksi cash receipt disimpan (save) namun masih ada selisih antara tagihan dengan pembayaran maka sistem akan memunculkan 3 opsi: Rounding, Deposit, dan Revisi.
  • Disepakati: Maksimum selisih yang boleh di rounding: Rp. 1000 (setara), minimum selisih yang boleh disimpan sebagai deposit: Rp. 50000 (setara).
  • Disepakati: Master data transaksi (Transaction Type) sementara dikontrol oleh IT karena tidak terupdate sesuai kesepakatan2 terakhir, sedangkan IT sangat membutuhkannya untuk men-coding alir proses dari setiap jenis transaksi
  • Outstanding: Skenario posting transaksi vs kebutuhan untuk revisi
26 Juli 2021
Rapat Online (Product Marketing, Accounting, SKG, FSD, IT)
  • Dilaporkan: Pengembangan FINA sudah masuk ke v2.0 (in-progress), keseluruhan fitur akan siap bulan September 2021.
  • Dilaporkan: Fitur-fitur di FINA v1.0 dan FINA v1.1 sudah jadi sebelumnya dan sudah sempat disosialisasikan tidak lagi siap digunakan karena terjadi perubahan-perubahan untuk fitur v2.0.
  • Dilaporkan: Perlambatan pengembangan FINA karena pekerjaan implementasi GMMS
  • Disampaikankan: Kebutuhan pemantauan saldo sangat dinantikan, delay akan memperparah situasi (sales)
  • Disepakati: Sebagian fitur FINA 2.0 akan diimplementasikan pada pertengahan Agustus 2021. Fitur yang diimplementasikan setara dengan fitur yang ada di FINA 1.1.
  • Disepakati: Implementasi akan langsung ke semua Sirda
29 Juli 2021
Diskusi Online DAN - YETTIE
  • Disampaikan: Ada perbedaan metode pencatatan antara Simulasi A dan Simulasi B. Simulasi A mencatat deposit out sebagai item pengurang tagihan sedangkan Simulasi B mencatat deposit out sebagai alat bayar.
  • Disampaikan: Perbedaan metode pencatatan di atas menyebabkan kebingungan pada saat coding, dan menghasilkan alir input tidak sesuai harapan.
  • Disampaikan: 3 layar CASH RECEIPT yang pernah dikembangkan. 1. Layar lama, 2. Layar baru (deposit sebagai alat bayar), 3. Layar baru (deposit sebagai item pengurang tagihan).
  • Disepakati: Layar ke-3 yang akan dilanjutkan pengembangannya.
  • Outstanding: Skenario posting transaksi vs kebutuhan untuk revisi
  • Outstanding: Contoh cetakan Tanda Terima Titipan
3 - 4 Agustus 2021
Diskusi Online YETTIE, DARMA, DAN, YON, RDY (, SAB secara terpisah)
  • Disampaikan: Fitur untuk pencatatan receipt baik dari cash counter maupun bank sudah dapat dicoba.
  • Disampaikan: Security yang sebelumnya sudah dipasang (v1.1) sudah dibuka lagi saat pengembangan v2 untuk kemudahan testing
  • Disampaikan (IT): Belum cukup jelas skenario posting transaksi vs kebutuhan untuk revisi
  • Disampaikan (Yettie): Seluruh jenis transaksi di-posting ke payment list, hanya pembayaran customer yang dilanjutkan sampai ke SPSK.
  • Disampaikan: Void transaksi tetap diperlukan untuk kepentingan koreksi. Saat ini void hanya dapat dilakukan sebelum posting
  • Disampaikan: Koreksi setelah posting dilakukan langsung di SAP sampai void pembayaran SPSK dari FINA dapat dilakukan (kebutuhan baru).
    Note: hasil diskusi DAN-SAB 3 Agst 2021, Void dapat dilakukan dengan "membatalkan" baris status bayar yang sudah dikirimkan sebelum di-posting menjadi RC. Tidak dapat dilakukan dengan transaksi balikan atau amount negatif. Hal ini sudah disampaikan ke tim 4 Agst 2021. Pengembangan fitur ini langsung dilakukan namun perlu waktu untuk menyelesaikannya).
  • Disepakati: Testing diarahkan untuk menguji kebenaran input transaksi, sementara tim TI akan berfokus pada penyesuaian proses posting
  • Disepakati: Status bayar ke aplikasi sumber (SPSK) dikirimkan saat posting baik dari Cash maupun Bank
  • Disepakati: Semua jenis transaksi alokasi (Receipt, Deposit, dan Rounding) dikirimkan ke "Payment List" (akan diubah menjadi "Receipt List").
  • Outstanding: Contoh cetakan Tanda Terima Titipan
10 Agustus 2021
Sosialisasi FINA secara online
  • Hadir: Adi, Adiyan, Agus Hendarto, Agus Rahmadi, Alia, Anis Musa, Ari, Ariel Satya, Asep, Atik, Cahya Pamungkas, Cahyono Bayu Aji, Chrisma, Daniel Kurniawan, Darma Datu, Dasep Rustaone, Demang, Didiet Raditya, Dina, Donie, Edi Susilo, Eliada, Eriyanto, Erwan, Fadjar Kurniadi, Ferdinandus SAW, Harjanto, Hermawan Kristanto, Heru Margowiyono, IIs Sugiarto, Iman Sabarudin, Johanes Deddy, Juanda, Jumahira, Kristanto, Kuncoro, Laurentius Nirmono, LG K10, Margaretta Elrina, Niko Dwiputra, Novie, Nurul, Petrus Supatno, Prima, Redmi Note 9, Rika Trisna, Riswan Tohir, Rudyanto, Surochman, Tamara, Tari, Titik, Tri Irianto, Unggul, Widyawati, Wilson, Wiwik Dyah, Yettie Krisnha, Yuli, Yustinus Aji Endaryanto
  • Pembukaan: Bp. Ferdinandus SAW, Bp. Titus Kitot, Bp. Edi Susilo
  • Disampaikan: Tujuan utama adalah RC bayangan SPSK se-update mungkin
  • Disampaikan: Alir proses dan informasi Kas dan Bank saat ini dan menggunakan FINA (Yettie)
  • Disampaikan: Alir proses di aplikasi FINA Cash dan Bank (Darma)
  • Diskusi dan Masukan
    • Ingin dibantu proses penagihan
    • Proses penarikan dan setoran saldo cash counter
    • Proses pembayaran dengan BG, pembayaran BG untuk beberapa tagihan
    • Saldo lebih/ kurang, masuk mana, bagaimana masuk saldo agen
    • Ingin dibantu kebijakan transfer di akhir bulan (sudah dijawab dengan backdate posting)
10 Agustus 2021
Diskusi online DAN - YETTIE
  • Disampaikan (dan): Proses posting dan void (sblm posting) sudah dihidupkan kembali.
  • Disampaikan (dan): Layar untuk Top Up, Mutasi Saldo Kasir yang sebenarnya sudah jadi namun belum tahu akan diletakkan di mana (belum ada arahan dan keputusan, ditanyakankan ulang lewat WA 4 Agustus 2021). Sementara sampai diputuskan, dibuat link dari "Cash Summary" menuju ke halaman tersebut.
  • Disampaikan (yettie): Ada perubahan cara pencatatan BG. Saat diterima, BG harus dicatat sebagai titipan dan tidak boleh memotong tagihan agen. Hal ini sesuai dengan keputusan rapat (tgl 5 Agustus 2021??) di mana IT Kompas/ Media memang tidak hadir. Mekanisme yang terpasang di sistem-sistem penjualan Kompas (SPSK, FastKom, dll) selama ini adalah mekanisme yang sudah harus diubah.
  • Disampaikan (dan): Aplikasi FINA sejak v1.0 (selesai Feb 2021) sudah dapat membayar banyak tagihan sekaligus dengan banyak alat bayar sekaligus. Tagihan yang dibayar agen (Receipt) ada di atas, sedangkan BG sebagai alat bayar ada di bawah. Cara mencatat tersebut itulah yang dipahami bersama dan sudah diuji bersama oleh tim IT Media dan FSD. Tidak ada masukan baru sampai tanggal 10 Agustus 2021 malam.
  • Disepakati: Cegatan transaksi BG tidak bisa posting dihilangkan (module posting sudah langsung diupdate).
  • Disepakati: Penambahan tab "balance" di kasir menampilkan informasi yang sama seperti di "Cash Summary" namun dibatasi di cash counter di mana kasir login. "Cash Summary" perlu menampilkan total di bawah masing masing kolom angka.
  • Disepakati: Diskusi akan dilanjutkan siangnya (11 Agustus 2021) sambil mencari cara agar perubahan skenario BG dapat diakomodir dengan perubahan aplikasi yang seminimal mungkin mengingat implementasi 16 Agustus 2021.
  • Outstanding: Pengembangan tab "balance" di layar kasir
  • Outstanding: Kesepakatan penanganan BG (perubahan menjadi titipan)
  • Outstanding: Contoh cetakan Tanda Terima Titipan
12 Agustus 2021
Last Minute Updates
  • Minor development: Penambahan tab balance di layar kasir (ditambah dengan daftar BG/CQ yang tersimpan di cash counter tempat kasir login)
  • Minor update: Penambahan total di "Cash Summary"
  • Ujicoba Cash dan Bank oleh calon pengguna menggunakan server development
  • Outstanding: Kesepakatan penanganan BG (perubahan menjadi titipan)
  • Outstanding: Contoh cetakan Tanda Terima Titipan
14 Agustus 2021
Implementasi 16 Agustus 2021 ditunda
  • Bp.Edi Susilo melalui WA Group "FINA KOMPAS" mengumumkan ujicoba masih akan dilanjutkan sampai 16 Agustus 2021
  • Outstanding: Kesepakatan penanganan BG (perubahan menjadi titipan)
  • Outstanding: Contoh cetakan Tanda Terima Titipan
18 Agustus 2021
Implementasi 18 Agustus 2021
  • Sistem mulai digunakan untuk real transaksi. Address ke production server dan login user diinformasikan melalui WA Group "FINA KOMPAS".
  • Penanganan BG (Giro) dan Cheque dikembalikan ke sistem SAP karena belum tersedia cara yang sesuai di FINA.
  • Outstanding: Kesepakatan penanganan BG (perubahan menjadi titipan)
  • Outstanding: Contoh cetakan Tanda Terima Titipan
23 Agustus 2021
Rapat Online Evaluasi Implementasi FINA Kompas (SPSK)
  • Hadir: Titus Kitot, Edi Susilo, Juanda, Eriyanto, Eliada, Daniel, Rudyanto, Prima, Yettie, Darma
  • Dilaporkan (Yettie, Edi Susilo):
    • Sistem FINA sudah digunakan mulai tanggal 18 Agustus 2021, mundur 2 hari dari rencana 16 Agustus 2021 karena beberapa kendala. Belum semua cabang menjalankan FINA (daftar ada dlm slide presentasi)
    • Informasi penerimaan pembayaran Agen yang dari FINA sudah mengalir ke SPSK
    • Kendala di awal implementasi, beberapa hardware PC tidak dapat digunakan untuk mengakses FINA, menyebabkan user tidak bisa ikut ujicoba. Masalah sudah teratasi menggunakan PC bekas yang sudah tidak ada nilai bukunya (update dari Yettie, Eliada)
      NOTE: Secara terpisah, dikonfirmasi ke unit operation KG Media, memang alat kerja mereka tidak di dalam wilayah support KG Media.
    • Kendala setelah implementasi, karena prosedur kerja terutama untuk cabang-cabang yang akun bank nya tergabung berubah dari training. Sudah disepakati pembagian kerja import dan posting
    • Penanganan BG dan Cheque sementara masih menggunakan SAP, karena fitur BG dan Cheque di FINA masih perlu disesuaikan.
  • Disampaikan (Yettie, Edi Susilo): Giro dan Cheque selama ini memang diakui setelah dicairkan baik menggunakan SAP maupun sebelumnya saat menggunakan CMS
  • Disampaikan (Titus): Pengakuan kapan diakuinya dana BG diserahkan sepenuhnya kepada Accounting, meskipun demikian, Marketing untuk kepentingan kontrol oplah, tetap memerlukan informasi bahwa agen sudah datang 'membayar', ada yang belum di-posting, ada BG yang belum cair dan cair nya kapan. Keputusan itu diharapkan mengakhiri perbedaan pendapat mengenai pengakuan omzet.
  • Disampaikan (Titus): Diharapkan (ekspektasi minggu depan) tim sudah dapat menyelesaikan fitur BG dan Cheque sehingga tujuan utama: akurasi informasi saldo agen untuk kontrol oplah tercapai.
26 Agustus 2021
Rapat Online IT Media - FSD
  • Hadir: DAN, YON, RDY, Yettie, Darma Datu
  • Disampaikan (DAN): Sudah tersedia 3 jalur pemrosesan giro/ cheque di FINA
    • Jalur Receipt Customer --> tidak sesuai policy pengakuan pembayaran
    • Jalur Titipan Customer --> tidak sesuai keinginan karena baru akan menjadi "pengurang tagihan" pada pembayaran kas berikutnya
    • Jalur Titipan Giro/ Cheque --> flow baru yang diusulkan
  • Disampaikan (RDY): Demo
    • Flow pemrosesan giro/ cheque melalui jalur titipan giro/ cheque yang diusulkan
    • Laporan Pembayaran Agen SPSK All Status (khusus SPSK).
      Report ini dibuat untuk kepentingan kontrol oplah dan collection seperti disampaikan oleh Pak Titus dalam rapat tgl 23 Aug 2021.
    • Sinkronisasi master data agen SPSK dengan master customer FINA
      Modul ini sudah ada sejak April 2021 namun belum disepakati dipasang di mana dan siapa yang akan melakukannya. Untuk sementara sudah dibuat link di Master Customer, layar historynya ada di setting, sampai disepakati ulang.
  • Disepakati: Flow pemrosesan giro/ cheque melalui jalur "Titipan Giro"
  • Disepakati: TI Media akan mengusahakan agar kombinasi jenis alokasi dengan alat bayar (bg dan cheque) yang sesuai policy bisa "dipaksakan" dalam design yang multi alokasi multi alat bayar.
  • Disepakati: "Manual Disburse" oleh kasir dari menu Receipt BG/ CQ dihapus digantikan dengan menu "Disbursing" yang menandakan giro/ cheque sudah disetorkan ke bank untuk pencairan.
  • Disepakati: Transaksi tolakan giro (sangat jarang) akan diselesaikan dengan CM/DM seperti biasa karena A/R masih di SAP.
  • Disepakati: Akan ditambahkan filter "from date" dan detail ke report "Pembayaran Agen SPSK All Status"
  • Disepakati: Sinkronisasi Agen SPSK - Customer FINA hanya meng-copy yang baru dari SPSK. Modifikasi dan perubahan status (inactivate, delete) SPSK diabaikan --> sudah dieksekusi.
  • Outstanding: Contoh cetakan Tanda Terima Titipan
  • Outstanding: (Darma) penataan ulang layar2 informasi “Cash” yang sekarang terdistribusi di beberapa layar dengan mempertimbangkan:
    • Siapa yang akan mengakses
    • Informasi yang dibutuhkan setiap pengakses
27 Agustus 2021
Rapat Online IT Media - FSD
  • Hadir: DAN, YON, RDY, Yettie, Darma Datu
  • Disampaikan: Flow pemrosesan giro dan cheque melalui titipan sudah siap diuji coba.
  • Disampaikan: Perlu penjelasan tentang balance-out giro dan cheque apakah saat disbursing atau saat disburse dari bank.
  • Disepakati: Balance out kasir dilakukan saat "disbursing". Proses disburse di bank hanya mengubah status giro/ cheque menjadi "disburse" tanpa ada dampaknya lagi pada saldo kasir --> sudah langsung dieksekusi, siap dicoba.
  • Outstanding: Contoh cetakan Tanda Terima Titipan
  • Outstanding: (Darma) penataan ulang layar2 informasi “Cash” yang sekarang terdistribusi di beberapa layar dengan mempertimbangkan:
    • Siapa yang akan mengakses
    • Informasi yang dibutuhkan setiap pengakses
6 September 2021
Rapat Online Operasional FINA dan Kebutuhan Report
  • Hadir: Juanda, Ucok, Eliada, Eriyanto, DAN, RDY
  • Disampaikan (Ucok): Kebutuhan report penunjang operasional harian kasir.
  • Disampaikan (Ucok): Kebutuhan report yang 'link' dengan SPSK untuk kontrol saldo agen
  • Disampaikan (DAN): (demo) "RPT SPSK Receipt Transaction" untuk laporan harian kasir/ FO dan "RPT SPSK Receipt All Status" sebagai penunjang kontrol saldo.
  • Disampaikan (DAN): Ada kendala teknis untuk menyajikan Omzet dan Tagihan SPSK dalam listing "All Status" karena prosesnya dapat membebani server SPSK yang sudah tua. Saat ini Omzet dan Tagihan SPSK disajikan hanya di detail per agen dari laporan tersebut.
  • Disampaikan (Eliada): Kesepakatan yang berlaku tentang back-date posting, saat ini setting di FINA belum sesuai dengan kesepakatan tersebut.
  • Disepakati: Akan diusahakan agar laporan Omzet dan Tagihan SPSK dapat disajikan dalam listing "all-status"
  • Disepakati: Akan dikembangkan report-report lain untuk kepentingan analisa, format dan data yang ditampilkan menyusul.
  • Outstanding: Diskusi lanjutan tentang policy back-date (TI - Mas Eliada)
  • Outstanding: Format laporan-laporan yang dibutuhkan. Update 7 Sep 2021: sudah diterima beberapa format laporan dari Mas Ucok via Rudyanto.
7 September 2021
Rapat Online Evaluasi 2 Implementasi FINA Kompas (SPSK)
  • Hadir: Titus Kitot, Edi Susilo, Juanda, Adiyan, Eriyanto, Eliada, Bruno, Daniel, Rudyanto, Prima, Yettie, Darma
  • Dilaporkan (Yettie): Masih ada beberapa kasir yang belum menggunakan FINA (listing ada di slide presentasi)
  • Disampaikan (Yettie): Sedari awal ada 2 masalah terkait lambatnya informasi pembayaran agen
    1. Masalah sistem yang lambat mengembalikan status bayar
    2. Masalah identifikasi pembayar saat alokasi transfer rekening bank
    FINA dikembangkan untuk mengatasi masalah yang pertama.
  • Dilaporkankan (Yettie): Sudah disediakan report "SPSK Receipt All-Status" yang menampilkan seluruh penerimaan pembayaran agen baik yang sudah di-posting maupun yang belum di-posting atau outstanding. Saat ini report tersebut masih diharus dibandingkan dengan report "Rekap Pra Tagihan" keluaran SPSK. Diperlukan kerja sama agar nilai-nilai sementara FINA dapat masuk ke laporan SPSK tersebut. Perlu keputusan dari GM IT (Agus Ramdhani) Media agar pengembangan tersebut dapat dilakukan
  • Dilaporkan (DAN): Hal-hal yang sudah dibahas dalam rapat 6 September 2021 antara Marketing, KGX, dan IT Media.
    • Sudah disepakati oleh FSD dan IT Media (26 Agustus 2021) proses penanganan giro dan cheque melalui "Deposit BG/CQ" yang sesuai dengan ketentuan. Beberapa perubahan minor yang disepakati dalam rapat tersebut sudah jadi dan siap diuji sejak 27 Agustus 2021.
    • (demo) Sudah ada report baru "SPSK Receipt Transactions" yang menampilkan semua penerimaan pembayaran agen pada periode waktu tertentu yang dapat dipilah berdasarkan Area Distribusi (SIRDA) dan kanal penerimaannya (kasir/ bank account). Report ditujukan untuk kontrol operasional kasir dan FO.
    • (demo) Report "SPSK Receipt All-Status" sudah diperbarui sehingga hanya menampilkan transaksi penerimaan pembayaran agen pada periode SPSK yang masih terbuka ditambah seluruh penerimaan pembayaran yang masih outstanding. Pada detail per-agen sudah ditampilkan informasi saldo, omzet dari Rekap Pra Tagihan SPSK. Report ini menjadi "combined-repost" sistem FINA dan SPSK, ditujukan untuk menunjang kontrol saldo agen.
    • Ada kendala teknis untuk menampilkan informasi saldo, omzet SPSK di dalam listing karena bisa terjadi pengambilan data secara massive (5600+ agen) yang akan memberatkan sistem SPSK.
    • Yang disimpan di SPSK adalah saldo awal, sedangkan saldo akhir harus dihitung dari transaksi pada periode yang dilaporkan. Hal ini menyebabkan angka saldo akhir yang ditampilkan oleh FINA untuk periode yang masih terbuka masih belum final (asumsi).
    • Sesuai kesepakatan rapat tanggal 6 September 2021, IT Media akan berusaha sedapat mungkin agar angka-angka omzet dan tagihan dari SPSK dapat ditampilkan dalam listing "all-status"
  • Disampaikan (Yettie): Jika angka-angka SPSK memang dibawa ke FINA, lebih baik pengembangan A/R FINA dipercepat sehingga laporan menjadi lebih riil.
  • Dilaporkan: Dari rapat tanggal 6 September 2021, ada celah di mekanisme pembatasan back-date posting di FINA (dilanjutkan diskusi tentang back-date posting: (Eliada, Adiyan, Yettie, Bruno, Edi Susilo)
  • Disampaikan (RDY, DAN): Mekanisme back-date posting berdasarkan kesepakatan selama pengembangan, boleh dilakukan jika mendapat approval atasan. Sudah tersedia flag (belum ditampilkan), untuk mencegah back-date posting dilakukan dari cash counter tertentu.
  • Disampaikan (Eliada): Jika memungkinkan posting penerimaan pembayaran dari sirda-sirda yang sudah memiliki rekening bank sendiri dapat dilakukan langsung oleh FO masing-masing untuk mempercepat proses.
  • Disepakati: Akan di set agar ada "atasan" di setiap cash counter sehingga back-date dapat dilakukan setelah mendapat approval. SOP tetap diberlakukan agar back date posting terkontrol.
  • Disepakati: Akan di set agar FO di cabang yang sudah memiliki akun bank sendiri dapat melakukan posting alokasi secara mandiri.
  • Disepakati: Report-report yang didemokan akan dinaikkan ke production server besok, 8 September 2021. Report-report lain untuk kebutuhan lain akan dikembangkan
  • Disepakati: Pemrosesan giro dan cheque di FINA melalui "Titipan Giro dan Cheque" akan dibuka. Untuk sosialisasi, akan dibuat video tutorial (Rudyanto). Video akan disebarkan setelah diperiksa oleh FSD.
20 September 2021
Sosialisasi Report-Report SPSK ke ME dan FO KGX
  • Hadir: Sekitar 30 orang ME, FO, dan ASM/BSM KGX
  • Disampaikan (Rudyanto): Penggunaan report-report khusus SPSK di FINA. Report yang dibahas: Report Transaction, Report Posting, Report Balance, Report Balance Detail
27 September 2021
Rapat Online Evaluasi 3 Implementasi FINA Kompas (SPSK)
  • Hadir: Titus Kitot, Edi Susilo, Juanda, Adiyan, Eriyanto, Eliada, Bruno, Daniel, Rudyanto, Prima, Yettie, Darma
  • Disampaikan (Darma, Yettie):
    • Report SPSK Transaction
    • Report SPSK Posting
    • Report SPSK Balance
    • Report SPSK Balance Detail
    • Report SPSK Balance Summary (older version)
  • Disampaikan (Daniel)
    • Di report SPSK Balance Summary sudah ditambahkan section "Open Period Summary" sehingga menggambarkan posisi terakhir per sirda (dan nasional).
    • Angka Penjualan dan Pembayaran di periode SPSK yang sudah ditutup sudah tidak bergerak lagi
    • Angka Penjualan dan Pembayaran di periode SPSK yang masih terbuka masih bersifat sementara
    • Angka Penjualan dihitung berdasarkan harga eceran, akan dikoreksi menjadi harga sebenarnya saat periode ditutup
    • Angka Penjualan sudah dikurangi nilai retur pada periode yang dilaporkan, jika retur sudah diinput dan diproses di SPSK
  • Diskusi: Laporan SPSK yang ditarik ke FINA mengikuti periode keuangan (RC/ Tagihan), bukan periode penjualan yang berbasis edisi.
  • Diskusi: Untuk analisa trend penjualan masih diperlukan laporan penjualan berbasis edisi, retur akan diakumulasi juga ke edisi. Report semacam ini hanya bisa disediakan oleh sistem penjualan (SPSK).
  • Disampaikan (Pak Titus): Report-report khusus SPSK di FINA sudah cukup memenuhi kebutuhan kontrol saldo piutang agen dan oplah
  • Disepakati: Akan segera disusun policy-policy yang berkaitan kontrol oplah dan saldo piutang agen untuk menjaga availability produk dan keamanan finansial. Bp. Titus mengajak Akunting, KGX, dan FSD dalam penyusunan policy tersebut.
28 September 2021
Rapat Rutin IT Media - FSD (R.Rapat TI Kompas)
  • Hadir: DAN, RDY, YON, Prima, Yettie, Darma
  • Disampaikan (Yettie): Selisih antara laporan SPSK Balance dengan SPSK Posting
  • Disampaikan (DAN): Selisih antara laporan SPSK Balance dengan SPSK Posting terjadi karena penggunaan report yang tidak sesuai peruntukannya. Report SPSK Balance berdasarkan "User Defined Posting Date" sedangkan report SPSK Posting berdasarkan "System Posting Date" (timestamp). Report Posting SPSK melaporkan posting yang dilakukan oleh operator pada suatu periode tanggal. Target postingnya bisa masuk ke periode bulan berjalan atau bulan lalu (backdate). Report Posting SPSK adalah report operasional bukan untuk pencocokan posting yang masuk pada periode bulan tertentu.
  • Disampaikan (DAN): Perlu segera diselesaikan aliran data menuju ke SAP (GL?). Topik: voucher, account addressing
  • Disampaikan (DAN): Kesalahan posting di awal implementasi FINA - SPSK, sudah di-posting ulang ke SPSK. Sudah disediakan perangkat untuk mengantisipasi kejadian2 luar biasa --> SPSK Console, Resend, Verify
  • Disampaikan (Yettie): Istilah "posting" harus diganti dengan "send" karena istilah posting "milik keuangan". Kolom "Posting Date" di laporan SPSK Posting harus diganti menjadi "System Posting Date". (update: langsung dieksekusi)
  • Diskusi: Account addressing, parameter yang sudah bisa digunakan:
    • Transaction Type
    • Payment Type
    • Party (Cust/Emp/Org/Supp)
    • Company --> Sales Org, Puchasing Org (kurang kode)
    • Application
    • Source (Cash Counter/ Bank Account) --> respective COA
  • Disepakati: Akan ditambahkan field "Code" di Organization, field "In COA" dan "Out COA" di Cash Counter dan Bank Account (update: sudah dipenuhi 30 Agustus 2021)
  • Disepakati: Akan dibuat report posting berbasis "User Defined Posting Date" untuk keuangan dan akunting, generic report, not SPSK specific. (update: sudah dipenuhi 29 Sept 2021 23:31)
  • Disepakati: Sebelum report selesai, IT Media akan menurunkan data posting bulan agustus ke excel. (update: sudah dipenuhi 28 September 2021 22:30)
  • Disepakati: Darma akan mencoba dan memeriksa kelengkapan data "Voucher" di FINA yang sudah tersedia, akan mengisi informasi COA di akun2 bank dan cash counter
  • Outstanding: Topik utama tentang Voucher generation dan Account addressing tidak sempat dibahas karena kesibukan update perubahan pajak.
4 Oktober 2021
Rapat Rutin IT Media - FSD (R.Rapat TI Kompas)
  • Hadir: DAN, RDY, YON, Yettie, Darma
  • Disampaikan (Yettie): Dari rapat manajemen, report "SPSK Balance Summary" diberi penanda naik/ turun, sehat kurang sehat berdasarkan angka-angka pada periode sebelumnya --> (persentase dan kode warna lupa... someone?)
  • Disampaikan (Darma): Report "Receipt Posting" sudah benar, namun belum sesuai dengan template upload ke SAP.
  • Disampaikan (Darma): Format template upload ke SAP disertai darimana data tersebut diambil dari FINA, diharapkan report "Receipt Posting" dapat disesuaikan agar mempermudah proses upload ke SAP.
  • Disampaikan (Darma): Filter "Source" di laporan "Receipt Posting" agar dipisah menjadi sehingga dapat di pilah antara penerimaan dari "Bank" atau dari "Cash"
  • Disepakati: Untuk memenuhi kebutuhan upload ke SAP akan ditambahkan field-field Posting Code, In Posting Code, Out Posting Code di Cash Counter dan Bank Account
  • Disepakati: Report "Receipt Posting" akan disesuaikan agar dapat langsung diupload ke SAP dan dilengkapi dengan export as "tab-delimited text".
  • Disepakati: Penambahan persentase dan kode warna di Report "SPSK Balance Summary" akan diselesaikan setelah urusan ke SAP selesai. Report-report "penjualan" tidak akan disediakan oleh FINA, didorong untuk disediakan oleh SPSK.
  • Disepakati: Urusan gagal posting di awal implementasi bulan Agustus dapat dianggap selesai dengan langkah koreksi yang sudah diambil.
  • Outstanding: Topik utama tentang Voucher generation dan Account addressing belum selesai dibahas sampai ke level siap di code
  • Outstanding: Simulasi dan review fitur Voucher yang sudah ada di FINA, sehingga siap dilanjutkan ke Voucher Generation (Darma)
11 Oktober 2021
Rapat Rutin IT Media - FSD (R.Rapat TI Kompas)
  • Hadir: DAN, YON, Yettie, Darma
  • Disampaikan (DAN): Report "SAP Posted Receipt" sesuai spesifikasi upload SAP tanggal 7 Oktober 2021 (Darma) sudah selesai di hari yang sama.
  • Disepakati: Report "SAP Posted Receipt", termasuk penyesuaian minor pada deskripsi (long-text) sudah sesuai dan berhasil diupload ke SAP.
  • Disampaikan (Yettie): Alir Proses Pembayaran.
  • Disampaikan (Yettie): Alir Proses A/R.
  • Disepakati: Pemisahan function yang lebih strict antara sistem penjualan dengan sistem keuangan, terutama yang terkait "produk".
  • Disepakati: Pengembangan lanjutan FINA tetap mengikuti roadmap: A/R, Invoicer, dst
  • Outstanding: Voucher generation dan Account addressing belum selesai dibahas sampai ke level siap di code
  • Outstanding: Simulasi dan review fitur Voucher yang sudah ada di FINA, sehingga siap dilanjutkan ke Voucher Generation (Darma)
18, 25 Oktober 2021
Rapat Rutin IT Media - FSD (R.Rapat TI Kompas, 2x half-day)
  • Hadir: DAN, YON, RDY, Ramdhani (18 Oct), Yettie, Darma, Sumani (18 oct)
  • Disampaikan (Ramdhani): Hasil diskusi dengan CITIS, KG Media sudah harus lepas dari SAP paling lambat awal tahun 2023
  • Disampaikan (Yettie): Cakupan FINA harus sampai ke General Ledger ketika KG Media sudah "lepas" dari SAP karena belum ada "stok" sistem yang dapat menggantikan. Hal ini sejalan juga dengan kebutuhan Tribun yang sejak awal tidak menggunakan SAP.
  • Diskusi & Simulasi: A/R Invoice, A/R Table
  • Disepakati: Transaksi "Advanced Payment" (DP)
  • Disepakati: Transaksi "Advanced Billing"
  • Disepakati: Transaksi "Allokasi DP"
  • Disepakati: Transaksi Pembatalan Penerimaan Pembayaran menggunakan "Reversed Receipt"
  • Disepakati: Transaksi Mutasi dengan menggunakan Reversed Receipt + Receipt"
  • Disepakati: Skenario "late-binding" mapping produk dari aplikasi sumber ke produk di FINA
  • Disepakati: A/R Invoice segera masuk ke fase coding
  • Outstanding: Voucher generation dan Account addressing belum selesai dibahas sampai ke level siap di code
  • Outstanding: Simulasi dan review fitur Voucher yang sudah ada di FINA, sehingga siap dilanjutkan ke Voucher Generation (Darma)
25 Oktober 2021
IT Media (R.Rapat TI Kompas)
  • Hadir: DAN, YON, RDY, AHA
  • Disampaikan (DAN): Rencana implementasi FINA-AMS, sesuai roadmap pengembangan FINA
  • Disepakati: Invoice AMS di generate di FINA dari Order AMS, user (admin) tidak menginput secara langsung.
  • Disepakati: Perlu diciptakan mekanisme dan kesepakatan bersama user agar paket diupdate mengikuti dealing dengan customer. Hal ini sangat penting agar nantinya analisa berbasis produk dapat disediakan.
  • Disepakati: Pengembangan integrasi FINA-AMS akan mengakibatkan pengembangan di masing-masing aplikasi. Pengembangan akan dilakukan bersama.
1 November 2021
Rapat Rutin IT Media - FSD (R.Rapat TI Kompas)
  • Hadir: DAN, YON, RDY, Yettie, Darma
  • Disampaikan (DAN, YON): Usulan untuk mencatat Advanced Billing hanya menggunakan A/R table, tanpa "Unearned Table" --> dilanjut diskusi
  • Diskusi: Product di FINA
  • Disampaikan (DAN, RDY): Pengelompokan produk menjadi Online, Print, Event, Service, dll adalah hasil pengolahan tim Marketing, sehingga tidak bisa di supply dari sistem di depan nya (FastKom, AMS)
  • Disepakati: Usulan IT tentang Advanced Billing di tolak, Advanced Billing tetap harus menggunakan "Unearned Table".
  • Outstanding: Voucher generation dan Account addressing belum selesai dibahas sampai ke level siap di code
  • Outstanding: Simulasi dan review fitur Voucher yang sudah ada di FINA, sehingga siap dilanjutkan ke Voucher Generation (Darma)
  • Outstanding: Simulasi dan review fitur A/R Invoicer yang draftnya sudah ada di FINA (Darma)
  • Outstanding: Simulasi dan review fitur Payment BG/ CQ (Darma)
3 November 2021
Diskusi Online IT Media - FSD
  • Hadir: DAN, Yettie, Darma
  • Disepakati: Referensi no BS atau no. Pesanan Dana di layar payment kasir ada di detail Item, bukan di header dokumen.
  • Disepakati: Invoice di layar detail payment kasir dihilangkan karena invoice tidak boleh menjadi referensi pembayaran. Detail invoice seharusnya ada di BS atau PD.
  • Outstanding: Voucher generation dan Account addressing belum selesai dibahas sampai ke level siap di code
  • Outstanding: Simulasi dan review fitur Voucher yang sudah ada di FINA, sehingga siap dilanjutkan ke Voucher Generation (Darma)
  • Outstanding: Simulasi dan review fitur A/R Invoicer yang draftnya sudah ada di FINA (Darma)
  • Outstanding: Simulasi dan review fitur Payment BG/ CQ (Darma)
8 November 2021
Rapat Rutin IT Media - FSD (R.Rapat TI Kompas)
  • Hadir: DAN, YON, RDY, Yettie, Darma, Prima, Hermann
  • Disepakati: Pengurutan display A/R (dan A/P) bertingkat dari induk (Invoice, Receipt DP, Payment DP) diikuti turunannya (Alokasi, Payment, Credit Invoice, dll).
  • Disepakati: Penambahan kolom "Level" di transaction type untuk kepentingan pengurutan.
  • Disepakati: Workflow dasar pembayaran (payment): BS/PD --> Payment Disposition --> Bukti Kas --> (banking) --> RC Bank --> Alokasi (tdk bikin bukti kas). Dalam kasus BS Cash, disposisi tetap dilalui tanpa proses user
  • Disepakati: Product dari Sales System disimpan apa adanya sebagai Reference Product. Product FINA dipilih oleh user (Manual Invoice), atau dihasilkan dari proses mapping (posting dari source application). Pemetaan Sales Product ke FINA Product dilakukan di belakang (late-binding)
  • Outstanding: Voucher generation dan Account addressing belum selesai dibahas sampai ke level siap di code
  • Outstanding: Simulasi dan review fitur Voucher yang sudah ada di FINA, sehingga siap dilanjutkan ke Voucher Generation (Darma)
  • Outstanding: Simulasi dan review fitur A/R Invoicer yang draftnya sudah ada di FINA (Darma)
  • Outstanding: Simulasi dan review fitur Payment BG/ CQ (Darma)
9 November 2021
Rapat Roadmap Fina (R.Rapat Proyek)
  • Hadir: DAN, Yettie, Sumani
  • Disampaikan: Periodisasi akunting.
  • Disampaikan: Periode adalah bulan, dan tahun, company-wise
  • Disampaikan: Paralel open periode diijinkan, open-closed dikontrol oleh user. Period addressing berdasarkan PostedDate (default) transaksi, tapi dapat juga diarahkan langsung (dipilih) oleh operator
  • Disepakati: Mapping Sales Product ke FINA Product
  • Outstanding: Voucher generation dan Account addressing belum selesai dibahas sampai ke level siap di code
  • Outstanding: Simulasi dan review fitur Voucher yang sudah ada di FINA, sehingga siap dilanjutkan ke Voucher Generation (Darma)
  • Outstanding: Simulasi dan review fitur A/R Invoicer yang draftnya sudah ada di FINA (Darma)
  • Outstanding: Simulasi dan review fitur Payment BG/ CQ (Darma)
16 November 2021
Rapat Rutin IT Media - FAS (R.Rapat Proyek)
  • Hadir: DAN, YON, RDY, Yettie, Darma
  • Disampaikan: Open Close period bisa dipilih sub ledger yang di open atau closed.
  • Disepekati: Penambahan "Workstate" di COA
  • Disepekati: Penambahan flag "General Journal" di Sub Ledger untuk mengontrol apakah account2 terkait Sub Ledger tersebut boleh digunakan saat journal memorial (general journal)
  • Disampaikan: Tidak semua jenis alokasi Cash dan Bank dikirimkan ke A/R, A/P. Semuanya dikirimkan ke G/L.
  • Disepakati: Transaksi penerimaan Cash dan Bank tidak meng-generate voucher tapi langsung masuk ke Cash/ Bank Receipt List. Berdasarkan Receipt List dicetak dokumen Receipt Register.
  • Disepakati: Transaksi penerimaan Cash dan Bank masuk ke "Receipt List" dengan COA hasil "COA Addressing". Receipt kemudian di-posting menjadi "Receipt Voucher". Jika posting berhasil maka ID Voucher di post back ke "Receipt List". Akan disediakan fasilitas re-read COA Addressing.
  • Disepakatikan: Voucher di ganti menjadi "Payment Requisition". Strukturnya dan Cetakan akan disesuaikan lagi.
  • Outstanding: Transaksi2 yang akan dikirimkan ke AR/AP/GL
  • Outstanding: Voucher generation dan Account addressing belum selesai dibahas sampai ke level siap di code
  • Outstanding: Simulasi dan review fitur Voucher yang sudah ada di FINA, sehingga siap dilanjutkan ke Voucher Generation (Darma)
  • Outstanding: Simulasi dan review fitur A/R Invoicer yang draftnya sudah ada di FINA (Darma)
  • Outstanding: Simulasi dan review fitur Payment BG/ CQ (Darma)
17 November 2021
Rapat Rutin IT Media - FSD (R.Rapat Proyek)
  • Hadir: DAN, YON, RDY, Yettie, Darma, Hermann
  • Disepekati: Pencatatan CI di A/R, menggunakan MUTIN/ MUTOUT untuk melepaskan Receipt dari Invoice yang dibatalkan
  • Disepekati: Penambahan Debit Cash Flow, Credit Cash Flow di Receipt bersamaan dengan COA Debit dan COA Credit
  • Disepekati: Flow pembatalan BG/ CQ, melalui "BG/CQ Rejection" yang akan men-trigger transaksi RBGCQRJK jika sudah dialokasi, dan akan mengupdate workstate di listing Receipt BG/CQ
  • Outstanding: Transaksi2 yang akan dikirimkan ke AR/AP/GL
  • Outstanding: Voucher generation dan Account addressing belum selesai dibahas sampai ke level siap di code
  • Outstanding: Simulasi dan review fitur Voucher yang sudah ada di FINA, sehingga siap dilanjutkan ke Voucher Generation (Darma)
  • Outstanding: Simulasi dan review fitur A/R Invoicer yang draftnya sudah ada di FINA (Darma)
  • Outstanding: Simulasi dan review fitur Payment BG/ CQ (Darma)
23 November 2021
Rapat Rutin IT Media - FSD (R.Rapat Proyek)
  • Hadir: DAN, YON, RDY, Yettie, Darma, Hermann, Prima
  • Disepekati: Receipt Workflow
  • Disepekati: Payment Workflow
  • Disepekati: Tambahan Payment Method, Manual eBanking dan eBanking Auto Credit
  • Disepekati: Change management implementasi FINA di unit-unit finance/ accounting KG Media dan unit-unit lain yang terdampak (Corporate, SKG, dll) menjadi tanggung jawab FSD.
  • Disepekati: A/R Alokasi, A/R Mutasi, A/R Memo diakses dari menu A/R, akan disediakan link dari A/R Detail
  • Disepekati: Disediakan menu A/R Consolidation untuk mengumpulkan sisa DP menjadi satu.
  • Disepekati: A/R Receipt Mutasi (one-to-many) akan menutup nomor lama, dan menghasilkan nomor baru.
  • Disepekati: Untuk proyeksi saldo bank, akan disediakan laporan salda bank ditambah bg/cq dan transfer out (BTO) yang belum ter-kliring. Pengganti Buku Bank.
  • Diskusi: Tolakan transfer?, Clearing BS? Otorisasi Payment? Penomoran Dokumen apakah per Company, Bank Book --> belum ada keputusan
  • Outstanding: Transaksi2 yang akan dikirimkan ke AR/AP/GL
  • Outstanding: Voucher generation dan Account addressing belum selesai dibahas sampai ke level siap di code
  • Outstanding: Simulasi dan review fitur Voucher yang sudah ada di FINA, sehingga siap dilanjutkan ke Voucher Generation (Darma)
  • Outstanding: Simulasi dan review fitur A/R Invoicer yang draftnya sudah ada di FINA (Darma)
  • Outstanding: Simulasi dan review fitur Payment BG/ CQ (Darma)
25 November 2021
Rapat Online Evaluasi Proyek FINA - SPSK (Closing)
  • Hadir: Edi Susilo, Titus Kitot, Juanda, Ferdi SAW, Adyan, Eriyanto, Eliada, Yettie, Darma, Daniel, Agus Ramdhani, Bruno
  • Disepakati: Pengembangan report (update dan baru) terkait omzet diarahkan untuk diselesaikan bersama pengembangan SPSK karena memang SPSK yang mengelola data-data dalam report yang diminta.
  • Disepakati: Proyek pengembangan FINA versi SPSK sudah bisa ditutup agar tim bisa fokus ke pengembangan modul-modul lainnya. Masih ada beberapa sisa pekerjaan terkait SPSK seperti tolakan giro/ check (new on 17 November 2021) akan segera diselesaikan.
30 November 2021
Rapat Rutin IT Media - FSD (R.Rapat Proyek)
  • Hadir: DAN, YON, RDY, Yettie, Darma, Hermann, Prima
  • Disepakati: Void Cash Payment yang mengandung BG/ CQ akan mengubah workstate Payment BG/CQ menjadi "outstanding"
  • Disepakati: Transaction Type Mapping akan dibuka untuk semua jenis transaction, sekarang hanya terbuka untuk external transaction.
  • Outstanding: Voucher generation dan Account addressing belum selesai dibahas sampai ke level siap di code
  • Outstanding: Simulasi dan review fitur Voucher yang sudah ada di FINA, sehingga siap dilanjutkan ke Voucher Generation (Darma)
  • Outstanding: Simulasi dan review fitur A/R Invoicer yang draftnya sudah ada di FINA (Darma)
7 Desember 2021
Rapat Rutin IT Media - FSD (R.Rapat Proyek)
  • Hadir: DAN, YON, RDY, Yettie, Darma, Hermann, Yori
  • Disepakati: Satu voucher berisi gabungan transaksi receipt dengan kriteria penggabungan yang sudah disepakati.
  • Disepakati: Voucher diposting dari Receipt List ke G/L. Yang diposting adalah header Voucher bukan detail voucher.
  • Disepakati: Status posting di Receipt List akan ditambah status untuk Voucher dan A/R (seperti status post back ke source apps)
  • Disampaikan: Flow penerimaan bukti potong (sekarang)
    • Bukti potong diterima dan dicap di loket pajak
    • Bukti potong diserahkan ke collecting untuk dialokasikan ke invoice
    • Customer membayar senilai invoice dikurangi nilai bukti potong
  • Disepakati: Flow penerimaan bukti potong (draft)
    • Bukti potong diterima FO dan di input ke FINA dan langsung dialokasi ke invoice nya
    • Kasir menerima sisa pembayaran customer, dan menginput sesuai nilai yang dia terima dengan layar cash yang sekarang
    • Bukti potong yang sudah dialokasikan ke invoice di-posting menjadi A/R Memo (tipe: CM)
    • Orang A/R akan mem-posting Memo (CM) tersebut ke A/R
  • Disepakati: Perlu ditambahkan: Nomor Item A/R Allocation.
  • Disampaikan: Atribut2 Form Bukti Potong (Yettie)
  • Disepakati: A/R Alokasi bisa dilakukan ke invoice2 yang currency nya sama. Konversi mata uang dilakukan pada saat alokasi jika diperlukan.
  • Outstanding: Skema konversi mata uang sejak invoice/ dp sampai ke A/R akan dikonfirmasi oleh FSD
  • Outstanding: Voucher generation dan Account addressing belum selesai dibahas sampai ke level siap di code
  • Outstanding: Simulasi dan review fitur Voucher yang sudah ada di FINA, sehingga siap dilanjutkan ke Voucher Generation (Darma)
  • Outstanding: Simulasi dan review fitur A/R Invoicer yang draftnya sudah ada di FINA (Darma)
8 Desember 2021
Rapat Online Mendadak IT Media - FSD (Zoom invitation oleh FSD, melanjutkan diskusi via WA)
  • Hadir: DAN, YON, RDY, Yettie, Darma, Hermann, Yori
  • Diskusi: Atribut-atribut bukti potong PPH, beberapa data masih belum jelas asal dan inputnya, ditanyakan ke bagian pajak
  • Diskusi: Fokus pengembangan FINA bulan Nov 2021 - Jan 2022, rencana implementasi mulai Februari 2022 dikaitkan dengan kebutuhan Tribun jangka dekat (awal tahun)
  • Disepakati: Bukti Potong PPH akan dibuat berdasarkan asumsi IT Media agar aliran data ke A/R bisa segera diselesaikan.
  • Disepakati: Fokus pengembangan FINA Nov - Des: A/R, Jan-Feb: A/P, Bank & Cash Payment, tetap seperti kesepakatan semula
  • Outstanding: Atribut-atribut Bukti Potong PPH, asal dan inputnya akan ditanyakan ke bagian Pajak oleh FSD (Yettie)
  • Outstanding: Skema konversi mata uang sejak invoice/ dp sampai ke A/R akan dikonfirmasi oleh FSD
  • Outstanding: Voucher generation dan Account addressing belum selesai dibahas sampai ke level siap di code
  • Outstanding: Simulasi dan review fitur Voucher yang sudah ada di FINA, sehingga siap dilanjutkan ke Voucher Generation (Darma)
  • Outstanding: Simulasi dan review fitur A/R Invoicer yang draftnya sudah ada di FINA (Darma)
14 Desember 2021
Rapat Rutin IT Media - FSD
  • Hadir: DAN, YON, RDY, Yettie, Darma, Hermann, Yori
  • Disepakati: Perubahan attribut di Income Tax
    • Form Code (hapus)
    • Jenis Pendapatan (baru)
    • Jenis PPH (21,23,26,etc)
    • Penambahan master data baru: Income Type
  • Disepakati: Perubahan pada Customer, Supplier, Employee, Org. Implikasi: Multi Address di drop
  • Disepakati: Fokus pengembangan FINA Nov - Des: A/R, Jan-Feb: A/P, Bank & Cash Payment, tetap seperti kesepakatan semula
  • Outstanding: Contoh Excel yang memuat rumus perhitungan PPH
  • Outstanding: Skema konversi mata uang sejak invoice/ dp sampai ke A/R akan dikonfirmasi oleh FSD
  • Outstanding: Voucher generation dan Account addressing belum selesai dibahas sampai ke level siap di code
  • Outstanding: Simulasi dan review fitur Voucher yang sudah ada di FINA, sehingga siap dilanjutkan ke Voucher Generation (Darma)
  • Outstanding: Simulasi dan review fitur A/R Invoicer yang draftnya sudah ada di FINA (Darma)
21 Desember 2021
Rapat Rutin IT Media - FSD
  • Hadir: DAN, YON, RDY, MUKHLIS, ROHIMAM, Yettie, Darma, Hermann, Yori, Andika, Prima
  • Disepakati: Produk FINA hanya untuk kepentingan membedakan "Account/ COA", tidak digunakan untuk "Sales Product"
  • Disepakati: Income Type, Income Tax sudah OK, Nama di Income Tax di build berdasarkan atribut2 di income tax ybs.
  • Disepakati: Penambahan flag KG/ Non KG di Customer.
  • Disepakati: Penambahan flag di Income Tax untuk menandai Income Tax yang digunakan dalam commission.
  • Disepakati: Penambahan parameter "Tax Type" di Income Tax (incl/ excl).
  • Diskusi: Penambahan "Media/ Publication" di Invoice Item sebagai bagian dari atribut "Produk".Terkait dengan penambahan field ini:
    • Tidak sesuai dengan kesepakatan tanggal 4 & 11 Oktober 2021 tentang pemisahan fungsi sistem.
    • Perlu tambahan master data "Publikasi/ Media"
    • Perlu "mapping" antara "publikasi/ media" di sistem sales (source) dengan "publikasi/ media" di FINA --> Paket?
    • Invoicer Generic tidak lagi "generik" karena akan berkiblat pada penjualan berbasis "publikasi/ media"
    • FINA akan diminta untuk menyediakan laporan "penjualan/ produk" yang karena perbedaan dimensi, detail, periodisasi akan tetap sulit untuk mencukupi kebutuhan analisa produk yang sebenarnya.
  • Disepakati: Penambahan atribut "Publication/ Media" di Invoice Item, naming "Publication/ Media/ lainnya" akan diputuskan oleh FSD. Waktu untuk mengupdate aplikasi akan dihitung, karena tidak mungkin hanya input bebas saja.
  • Outstanding: Skema konversi mata uang sejak invoice/ dp sampai ke A/R akan dikonfirmasi oleh FSD
  • Outstanding: Voucher generation dan Account addressing belum selesai dibahas sampai ke level siap di code
  • Outstanding: Simulasi dan review fitur Voucher yang sudah ada di FINA, sehingga siap dilanjutkan ke Voucher Generation (Darma)
  • Outstanding: Simulasi dan review fitur A/R Invoicer yang draftnya sudah ada di FINA (Darma)
22 Desember 2021
Rapat Internal IT Media
  • Hadir: DAN, YON, RDY
  • Perlu ditelusur di mana saja atribut "Publikasi/ Media" perlu dilekatkan dan keterkaitan dengan mapping produk yg belum sempat dicoba.
  • Dengan asumsi penambahan hanya di "Invoice Item" saja, maka perlu penambahan 3 minggu kerja untuk coding: Update DB structure, Master Publikasi/ Media (simple CRUD), Mapping Publikasi/ Media (complex CRUD), update Invoice (complex CRUD), update Credit Invoice (complex CRUD), dan Lookup (simple read), test.
22 Desember 2021
Rapat Internal IT Media
  • Hadir: DAN, YON, RDY
  • Perlu ditelusur di mana saja atribut "Publikasi/ Media" perlu dilekatkan dan keterkaitan dengan mapping produk yg belum sempat dicoba.
  • Dengan asumsi penambahan hanya di "Invoice Item" saja, maka perlu penambahan 3 minggu kerja untuk coding: Update DB structure, Master Publikasi/ Media (simple CRUD), Mapping Publikasi/ Media (complex CRUD), update Invoice (complex CRUD), update Credit Invoice (complex CRUD), dan Lookup (simple read), test.
27 Desember 2021 - 10 Februari 2022
Proyek FINA diliburkan karena libur Natal Tahun Baru, fokus tim proyek dialihkan ke Sirkulasi.
  • Tim IT cuti (masal) sejak 27 Desember 2021, masuk kembali 10 Januari 2022 (10 hari kerja)
  • Pekerjaan tim beralih ke Sirkulasi sejak 10 Januari 2022 (membahas usulan solusi menggunakan SPSK dan ADS oleh FSD)
  • Keputusan rapat tanggal 11 Januari 2022 (Bp. Andreas, SMO, FSD, IT, Sirkulasi), proyek FINA (dan proyek lainnya) "diparkir" sementara agar tim IT dan FSD bisa fokus ke Sirkulasi.
  • Jika pekerjaan Sirkulasi berjalan sesuai timeline (22 hari kerja), maka target dan timeline FINA akan molor total 32 hari kerja. Target yang sudah direvisi dapat dilihat di tab "Delivery Schedule".
22 Februari 2022
Rapat Rutin IT Media - FSD (Zoom Meeting 10.00 - 12.30)
  • Hadir: DAN, YON, RDY, Yettie, Darma, Hermann, Yori
  • Disampaikan (Yettie): Pekerjaan di Sirkulasi belum selesai, masuk minggu terakhir sebelum go-live tanggal 1 Maret 2022
  • Disampaikan (DAN): Modul A/R yang tertunda karena cuti natal-tahun baru dan pekerjaan Sirkulasi sudah diselesaikan, menunggu test dan masukan dari FSD. Fungsi-fungsi dalam modul A/R yang sudah siap:
    • A/R Balance
    • A/R Invoice
    • A/R Payment
    • A/R Memo
    • A/R Allocation
    • A/R Mutation
  • Disampaikan (DAN): Modul Tax yang terkait ke alir penerimaan dana dan A/R sudah selesai. Fungsi-fungsi dalam modul Tax antara lain:
    • Withholding Tax In
    • Tax Processing
    • eFaktur
  • Disampaikan (DAN): Modul COA sudah ditambah dengan fungsi addressing untuk masing-masing account dalam COA:
    • Fungsi "Save" account di COA sekarang sekaligus menyimpan informasi addressing Debit dan Credit untuk account tersebut. Tujuannya untuk memudahkan pengelolaan account dan pengelolaan addressing nya.
    • Sudah disediakan fungsi "COA Addressing Simulation"
  • Disampaikan (DAN): Pembatalan receipt yang salah karena kegagalan penerapan SSO sudah diperbaiki. Logic perbaikan data (database) tanpa menu sehingga jika terjadi lagi butuh "bantuan TI" untuk menjalankannya. Untuk ke depannya diharapkan penanganan masalah ini dapat dilakukan sendiri oleh user. Mekanisme dan prosedurnya masih perlu disepakati.
  • Disampaikan (DAN): Master Supplier sudah diupdate sehingga informasinya tersimpan di Master tersebut, tidak tergantung pada BP nya. Setelah master Customer dan Supplier update akan dilanjutkan ke Master Organization dan Master Employee.
  • Diskusi: Penyatuan pengelolaan COA dan COA Addressing menjadi satu berpotensi membingungkan, akan ditinjau ulang setelah ditest oleh FSD
  • Diskusi: Informasi "External/ Internal" perlu ditambahkan di master Customer dan Supplier. Hal ini sudah pernah dibahas namun lupa ditambahkan padahal informasi ini menentukan COA Addressing
  • Disepakati: Tim FSD (Hermann, Darma, Yori, Andika) akan segera mulai melakukan simulasi pada fungsi-fungsi yang dilaporkan di atas
  • Disepakati: Tim FSD (Hermann, Darma, Yori, Andika) akan menyusun skenario pembatalan receipt setelah posting dengan memperhatikan kondisi-kondisi di A/R (sudah dimutasi, sudah dialokasi, dll) dan kondisi-kondisi di sistem sumber.
  • Disepakati: Penambahan informasi internal/ eksternal --> KG/ non KG di master data Customer dan Supplier
  • Disepakati: Target waktu pengembangan dan delivery yang sudah direvisi, di tab "Delivery Schedule" (paling bawah).
1 Maret 2022
Rapat Rutin IT Media - FSD (R.Rapat TI 14.00 - 18.30)
  • Hadir: DAN, YON, RDY, Yettie, Darma, Prima, Andika
  • Disampaikan (Darma, Andika): Modul-modul yang sudah dilaporkan tanggal 22 Februari 2022 belum sempat diperiksa dan disimulasi. FSD masih sibuk dengan sirkulasi dan lainnya.
  • Disampaikan (DAN): Dokumentasi alir proses penerimaan sudah diperbarui, akan menyusul dokumentasi alir proses pembayaran keluar
  • Diskusi: Alir proses Reversed Receipt (void payment dari kasir)
  • Diskusi: Pencatatan tolakan Giro dan Cheque
  • Diskusi: Posting ke G/L pada alir proses receipt
  • Diskusi: Hubungan antara BS dengan Invoice AP
  • Disepakati: Alir proses ralat/ pembatalan receipt untuk 5 kondisi sbb:
    1. Cash transaction belum posting: Ralat/ Void
    2. Cash transaction sudah posting: buat transaksi pembalik, di posting, di mutasi, di alokasi
    3. Bank Import belum posting: edit/ delete
    4. Bank Statement belum posting: buat transaksi pembalik, transaksi lama dan transaksi pembalik kemudian di close
    5. Bank Statement sudah posting: buat transaksi pembalik dan transaksi baru, di posting, di mutasi, di alokasi
    (Detail alir pembatalan dapat dilihat di dokumentasi Reversed Workflow yang sudah diupdate tanggal 2 Maret 2022.)
  • Disepakati: Void payment ke sistem SPSK melalui posting transaksi pembalik, mekanisme void akan di drop setelah sistem di update
  • Disepakati: Tolakan giro dan cheque dicatat melalui proses reversed receipt dari modul kasir, sistem akan disesuaikan. Layar khusus pencatatan tolakan giro/ cheque tidak perlu dibuat.
  • Disepakati: Posting ke G/L dari Voucher akan mengirimkan informasi Receipt, Reversed Receipt, sedangkan posting ke G/L dari A/R hanya mengirimkan Invoice, Credit Invoice, Debit Memo, Credit Memo
  • Disepakati: Tim FSD (Hermann, Darma, Yori, Andika) akan segera mulai melakukan simulasi pada fungsi-fungsi yang dilaporkan di atas
  • Disepakati: Tim FSD (Hermann, Darma, Yori, Andika) akan menyusun skenario pembatalan receipt setelah posting dengan memperhatikan kondisi-kondisi di A/R (sudah dimutasi, sudah dialokasi, dll) dan kondisi-kondisi di sistem sumber.
8 Maret 2022
Rapat Rutin IT Media - FSD (R.Rapat TI 14.00 - 18.16)
  • Hadir: DAN, YON, RDY, Yettie, Darma, Prima, Andika, Yori, Hermann
  • Disampaikan (DAN): Modul Prepayment Submission sudah selesai, siap diuji
  • Disampaikan (Yettie): Workflow pembayaran versi CMS, SAP, dan Oracle
  • Disepakati: Invoice A/P TIDAK punya tipe "invoice" dan "prepayment".
  • Disepakati: Struktur A/P Invoice: AP - Item (one-to-many), AP - Installment (one-to-many), AP - Prepayment (one-to-many)
  • Disepakati: Satu BS (prepayment) hanya akan memuat satu installment (tgl bayar). Jika lebih dari satu installment, tinggal displit ke beberapa BS
  • Disepakati: Satu BS (prepayment) bisa untuk pembelanjaan multiple cost center, penentuan cost center saat invoice AP (displit barangnya)
  • Disepakati: Beberapa "Installments" dapat digabung menjadi 1 PaymentRequest (PD) jika Company sama, Tujuan (PayTo) sama, no account bank/ cash counter sama
  • Disepakati: Hirarki Otorisasi Invoice AP dilekatkan ke "Company"
  • Disepakati: Hirarki Otorisasi PD dilekatkan ke "Company"
  • Disepakati (ulang): Akan disediakan input Giro/ Cheque/ slip di modul Dispatcher untuk dilekatkan di PD
  • Disepakati: Pengiriman Giro, Cheque, dan Slip2 ke Cash Counter akan menambah saldo alat bayar kasir
  • Disampaikan (Yettie): Saat Giro/ Cheque/ Slip/ Auto Credit dibuat akan menimbulkan Voucher Bank (kliring pada bank? embuh)
  • Disamoaikan (Yettie): Saat Giro/ Cheque/ Slip dibayar oleh kasir akan muncul Voucher Kasir (kas pada kliring? embuh)
  • Outstanding: Tim FSD (Hermann, Darma, Yori, Andika) akan segera mulai melakukan simulasi pada fungsi-fungsi yang dilaporkan di atas
  • Outstanding: Tim FSD (Hermann, Darma, Yori, Andika) akan menyusun skenario pembatalan receipt setelah posting dengan memperhatikan kondisi-kondisi di A/R (sudah dimutasi, sudah dialokasi, dll) dan kondisi-kondisi di sistem sumber.
15 Maret 2022
Rapat Rutin IT Media - FSD (R.Rapat TI 14.00 - 17.30)
  • Hadir: DAN, YON, RDY, Yettie, Darma, Prima, Andika
  • Disampaikan (DAN): Mockup layar AP Invoice dan mockup Layar Installment, Workflow Integrasi dengan sistem procurement (GMMS, ...)
  • Disepakati: Akan dibuat modul "Penerimaan Barang dan Jasa" untuk kepentingan integrasi sistem-sistem pembelian, HR, dan FINA
    • Not a full-fledge GR system, berfungsi sebagai "Buffer" untuk kepentingan FINA
    • Menyimpan produk asli sebagai catatan dan mapping ke product category (formerly: Product) di FINA
    • Berfungsi sebagai catatan penerimaan barang untuk pembelian non PO atau non GR
    • berfungsi sebagai rujukan AP Invoice Item
  • Disepakati: Layar AP Invoice seperti mockup dengan beberapa perubahan:
    • Cost Center dan Project turun ke Item level
    • Type Invoice (header): Invoice Reguler dan Invoice Uang Muka (DP)
    • Informasi bank account di Installment, terhubung dengan payment type (8 Maret 2020: diskusi DAN + Yettie)
    • Notes ke bagian eksekutor installment (PD) (8 Maret 2020: diskusi DAN + Yettie)
  • Disepakati: Entitas "Product" di FINA akan "menggunakan" Product Hirarki dan Product Usage GMMS
  • Disepakati: Ditambahkan tracker uang muka (DP) terpisah dari tracker AP
  • Disepakati: Tipe Installment di Invoice AP ada 3
    • Reguler, akan mengalir menjadi PD saat di posting
    • Pre Payment (BS), TIDAK mengalir menjadi PD saat di posting untuk clearing Pre Payment.
    • Down Payment (DP), TIDAK mengalir menjadi PD saat di posting, untuk clearing Invoice Down Payment.
  • Disepakati: Layar Installment, dan generation PD dari layar tersebut.
  • Disepakati: Biaya Bank, Biaya Transfer (kasus transfer ke karyawan dari HR) akan di alokasi sebagai payment menggunakan modul Bank. Nilai transfer yang dicatatkan sebagai Invoice AP adalah nilai murni tanpa biaya2 bank/ transfer
  • Outstanding: (Yettie) Struktur Budget per account akan coba dialirkan ke tingkat Cost Center/ Profit Center yang lebih "operasional"
  • Outstanding: (All) Hirarki Otorisasi dan View Invoice AP dibahas ulang, terkait juga dengan otorisasi Budget
  • Outstanding: Tim FSD (Hermann, Darma, Yori, Andika) akan segera mulai melakukan simulasi pada fungsi-fungsi yang dilaporkan di atas
  • Outstanding: Tim FSD (Hermann, Darma, Yori, Andika) akan menyusun skenario pembatalan receipt setelah posting dengan memperhatikan kondisi-kondisi di A/R (sudah dimutasi, sudah dialokasi, dll) dan kondisi-kondisi di sistem sumber.
17 Maret 2022
WA Group Chat IT - FSD
  • Hadir: DAN, Yettie, Darma
  • Pertanyaan (DAN): Informasi "Cost Center" dan "Project" sudah diturunkan dari header AP Invoice ke Item AP Invoice. Sehingga 1 dokumen AP dapat mencakup multiple cost-center dalam 1 company. Implikasinya:
    • Installment yang muncul dari AP Invoice tidak dapat dirujukkan ke level "Cost Center" atau "Project"
    • Pemisahan installment berdasarkan Cost Center/ Project tidak dapat dilakukan sejak installment sampai ke proses-proses pembayaran
    • Pre payment yang menimbulkan installment setara AP Invoice (beda tipe) tidak bisa dirujukkan ke Cost Center tertentu.
    Apakah skenarionya memang demikian?
  • Disepakati:
    • Satu AP Invoice dapat diassign ke multiple cost center/ project pada masing-masing itemnya
    • Sikron dengan penjelasan FSD (Yettie) tentang Pre-Payment, di mana satu BS bisa dibelanjakan untuk multiple cost center
    • IT: Mockup AP Invoice disesuaikan, tabel AP Invoice, tabel AP Invoice Item, db logic diupdate, pengembangan AP Invoice dilanjutkan berdasarkan keputusan ini, Informasi Cost Center di cabut dari Pre Payment (BS)
  • Outstanding: (Yettie) Struktur Budget per account akan coba dialirkan ke tingkat Cost Center/ Profit Center yang lebih "operasional"
  • Outstanding: (All) Hirarki Otorisasi dan View Invoice AP dibahas ulang, terkait juga dengan otorisasi Budget
  • Outstanding: Tim FSD (Hermann, Darma, Yori, Andika) akan segera mulai melakukan simulasi pada fungsi-fungsi yang dilaporkan di atas
  • Outstanding: Tim FSD (Hermann, Darma, Yori, Andika) akan menyusun skenario pembatalan receipt setelah posting dengan memperhatikan kondisi-kondisi di A/R (sudah dimutasi, sudah dialokasi, dll) dan kondisi-kondisi di sistem sumber.
22 Maret 2022
Rapat persiapan implementasi SPSK untuk Periodical (catatan di bawah hanya memuat part yang terkait FINA)
  • Hadir: DAN, SAB, Yettie, Prima, Darma, Andika, Eliada, Ucok, Eriyanto, Oman, Dono, ...
  • Disepakati: Posting mundur penerimaan pembayaran (receipt back date posting)
    • Posting back date ke periode bulan sebelumnya masih dapat diterima sampai tanggal 7 bulan berjalan
    • Pemeriksaan back date di sistem FINA dengan approval atasan berdasarkan keputusan rapat tanggal 7 September 2021 akan disesuaikan untuk mencegah posting back date setelah tanggal 7.
    • Pemeriksaan back date diharapkan sudah terimplementasi (di Cash & di Bank) sebelum closing periode Maret 2022.
5 April 2022
Diskusi: DAN - Yettie (10 min, waktu tunggu kedatangan tim Kompas TV)
  • Disepakati: Dalam 1 form invoice (AP) hanya boleh ada 1 jenis VAT (1%, 1.1%, 11%, dll), namun di itennya diijinkan "tax free". Sehingga kombinasi yang benar adalah: 11% dan 0%, 1.1% dan 0%. Kombinasi yang tidak diijinkan misalnya: 1.1% dengan 11%.
  • Disepakati: Pilihan jenis VAT akan diinput di header
  • Disepakati: Akan disediakan chekbox "Tax Free" pada item untuk mengakomodir VAT 0% (BTKP). Untuk party memang bebas pajak maka cukup diset VAT 0% di header.
  • Disepakati: Di header akan dimunculkan 2 total:
    • Total untuk dikenakan VAT
    • Total yang "Tax Free"
  • Disepakati: Invoice diskon dan Invoice surcharge jika ada dikenakan pada kedua Total (Kena pajak dan Tidak kena pajak)
  • Disepakati: Nilai VAT hanya dikenakan pada Total Kena Pajak - porsi diskon kena pajak + porsi surcharge kena pajak.
  • Disepakati: Kalkulasi tersebut di atas akan langsung diterapkan pada modul2 AP FINA.
Diskusi: IT Media - FSD - Kompas TV (14.10 - 16.00)
  • Hadir: DAN, YON, Yettie, Andika, (teman FSD terbaru), Tim Kompas TV
  • Disampaikan (TV):
    • Jika TV atau unit lain punya kebutuhan yang lebih detail atau spesifik, bagaimana sistem (FINA) dapat mengakomodirnya sedangkan unit lain mungkin butuh yang jauh lebih sederhana.
    • Semua kegiatan keuangan di TV sudah ter-sistem, Orlansoft sudah memenuhi kebutuhan karena sudah disesuaikan untuk TV. Hanya Bank Auto Credit saja yang masih menggunakan aplikasi internal KG. Interoperability dengan Gen21 sudah ada.
  • Disampaikan (DAN):
    • FINA awalnya dikembangkan hanya untuk mengatasi masalah penerimaan pembayaran. Kemudian dilanjutkan untuk melepaskan ketergantungan KG Media pada sistem SAP
    • FINA tidak dikembangkan sebagai monolitic system (tunggal, centralistic) melainkan sebagai sistem keuangan yang di dapat berintegrasi dengan sistem sekitar
    • FINA didesain dengan konsep: API-driven, single database tenancy model, self-contained modularity, berangkat dari kesadaran sulit sekali menemukan sistem yang fit dengan kebutuhan seluruh unit bisnis di KG Media.
    • Target penyelesaian FINA sudah ditetapkan: 2023 KG Media sudah tidak tergantung ke sistem SAP, artinya akhir tahun sudah harus selesai.
  • Disampaikan (Yettie):
    • FINA Sudah digunakan di kasir Sirkulasi sejak Agustus 2021, support cepat, tidak ada kendala yang harus mengotak-atik data secara langsung
    • FINA Sudah digunakan di kasir Sirkulasi sejak Agustus 2021, support cepat, tidak ada kendala yang harus mengotak-atik data secara langsung
    • Budget FINA belum ada, sekarang masih menempel di GMMS. Itu masih belum sesuai untuk kebutuhan TV. Tentang budget masih akan diusulkan agar lebih sederhana namun tetap mengakomodir kebutuhan informasi proyek.
    • Timeline pengembangan FINA beberapa kali direvisi menyesuaikan desakan kebutuhan implementasi dan kegiatan lainnya (Tribun, SPSK, GMMS, dll).
  • Disepakati:
    • Kompas TV belum akan dapat menggunakan FINA ditahun 2022. Karena keterbatasan tim, terutama FSD.
    • Pertemuan akan dilanjutkan ke topik yang lebih detail untuk memastikan kebutuhan TV akan terakomodir oleh FINA dikemudian hari. Topik pertama yang akan dibahas: arus pembayaran (pengeluaran dana) sejak dibudgetkan, direquest, sampai diselesai.
    • Pertemuan lanjutan akan memanfaatkan waktu pertemuan rapat rutin IT Media - FSD hari Selasa.
12 April 2022
Rapat Rutin IT Media - FSD (10.30 - 13.30)
  • Disampaikan (DAN): Layar AP Invoice, Pre Payment, Installment, Payment Requisition, Bank Payment sudah jadi, siap diuji skenarionya.
  • Diskusi: Ada kebutuhan untuk mencatat hutang employee ke perusahaan. Kasus: reimburse rumah sakit, Invoice 100%, Perusahaan menanggung 90%, 10% ditanggung karyawan (potong gaji/ bayar langsung). Ada 2 pendekatan: Invoice diakui 100% atau diakui 90%.
  • Diskusi: Tentang Pre Payment, jika belanja lebih apakah lebih baik BS lagi atau langsung muncul installment baru dari AP Invoice
  • Disepakati: Tentang hutang employee akan dibahas oleh FSD, baru kemudian disepakati menjadi spec. FINA
  • Disepakati: Bank Payment sudah berfungsi sebagai Voucher (Bank Payment Voucher)
  • Disepakati: Cash Payment harus memanggil PD sebagai rujukan pembayaran (selalu bayar penuh).
  • Disepakati: Receiving vs Invoice AP = 1:1. Jadi satu receiving tidak bisa di invoice ap berkali-kali.
Diskusi: IT Media - FSD - Kompas TV (14.36 - 16.00)
  • Hadir: DAN, YON, RDY, Yettie, Andika, Tim Kompas TV: Shofikh
  • Disampaikan (as is TV):
    • Proses Create Budget, sekretariat unit (setiap bulan utk bulan depan), OPEX, CAPEX, Program jadi satu. Yang diinput budget setelah final. Sudah ada fasilitas untuk draft budget.
    • Update budget: bikin memo diapprove BMA, additional masuk ke budget.
    • Browser untuk mengakses Orlansoft: Firefox.
    • Satu budget bisa melibatkan departemen terkait. Budget bisa melekat ke Qty atau Value
    • Request Item merujuk ke item dalam budget (Qty, Value) atau ke kelompok itemnya (Value). Request dibuat oleh sekretariat unit ditujukan ke departemen terkait.
    • PR dibuat oleh departemen terkait, jika ingin dilanjutkan ke procurement
    • Receiving dibuat oleh pihak yang ditunjuk untuk menerima barang/ jasa dalam PO.
    • Untuk barang yang dibeli harga di set, kalau tidak dibeli harga = 0, sejak dari Budget.
    • Purchase Request tidak dapat digabungkan menjadi satu PO/MO/RO, dll.
    • Supplier di masterkan ke dalam system sedangkan barang tidak di master kan, sejak dari budget, request, sampai ke pembelian semuanya diketikkan.
    • Invoice AP di buat oleh departemen terkait/ GA/ Procurement (siapa yang PO), di approve, diposting oleh GMA.
    • Partial receiving belum disupport. Perubahan barang yang datang dengan barang yang di PO harus membatalkan PO dan buat baru lagi.
19 April 2022
Rapat Rutin IT Media - FSD (11.00 - )
  • Hadir: DAN, WIK, YON, RDY, Yettie, Prima, Darma, Andika, Sandy
  • Disepakati: Fitur cek duplikasi data di BP (Cust, Supp, dll) berdasarkan kesamaan No Identitas dan NPWP tidak bisa diberlakukan. Pemeriksaan ini dicabut.
  • Disepakati: Data SPSK yang sudah ditolak masuk ke FINA tanggal 31 Maret 2022 (464 data) akan di proses dari backend, hari Kamis sudah masuk ke FINA.
  • Disepakati: NPWP Pemungut di WAPU mengikuti NPWP Purchasing Org.
Diskusi: IT Media - FSD - Kompas TV (14.00)
  • Hadir: DAN, YON, RDY, Yettie, Prima, Andika, Sandy, Tim Kompas TV: Shofikh
  • AP Invoice disusun oleh user departemen terkait, diajukan kepada BMA, setelah diverifikasi diposting kepada Finance. Akan dieksekusi pembayarannya oleh Finance, setelah itu Payment Voucher.
  • Issue Check dibuat untuk melakukan pembayaran atas satu atau banyak invoice AP (same vendor/ supplier)
  • Issue Check diposting akan keluar jurnal dan menghasilkan payment voucher. Payment Voucher tidak dibuat tapi dihasilkan dari posting payment voucher
  • Layar Jurnal list melisting daftar transaksi yang dijurnal. Di detailnya baru dimunculkan detail akun2 yang terlibat
  • Orlansoft tidak dirancang multi company, meskipun company diinput hanya sebatas untuk membatasi akses saja, tapi secara (data) database tidak dipisah.
  • Orlansoft tidak dapat menangani posting transaksi ke periode sebelumnya (backdate) atau ke peride berikutnya (next period)
22 April 2022
Waktu Jeda Rapat Skenario ERP Tribun (11.00 - 13.50) --> hanya mencatat bagian yang terkait FINA saja.
  • Hadir: DAN, WIK, YON, RDY, Yettie, Prima, Darma, Sandy, Sumani, Agus Ramdhani (pengundang), Sys.Dev Tribun (6 orang)
  • Ditanyakan (DAN): Apakah 1 slip pembayaran boleh membayar beberapa PD sekaligus
  • Disampaikan (YON): Fitur menggabungkan item-item yang berbeda pengenaan income tax menjadi satu AP Invoice terkendala format bukti potong/ bukti pungut PPH yang hanya bisa memuat 1 jenis PPH dalam 1 invoice.
  • Disepakati: Jenis PPH, persentase yang sebelumnya ada di Item dinaikkan ke header AP Invoice. Di Item hanya ditandai bahwa item tersebut dikenakan PPH atau tidak. Perubahan akan langsung di apply ke modul AP Invoice dan Receiving.
  • Outstanding: Semua fitur FINA belum diujicoba kecuali fitur terkair Cash and Bank Receipt --> A/R, A/P, PrePayment, Receiving, Voucher, COA, Taxation, etc.
  • Outstanding: Slip pembayaran apakah bisa membayar beberapa PD sekaligus.
26 April 2022
Alignment pengembangan FINA - HR Tribun (10.32 - 15.55)
  • Hadir: DAN, WIK, YON, Aulia, Wiwid, Ryan
  • Disampaikan (DAN):
    • Positioning sistem FINA sebagai kolaborator, integrator dengan sistem2 sekitaran termasuk HR Tribun yang akan dikembangkan.
    • Pengembangan sistem HR oleh tim SysDev Tribun perlu mempertimbangkan kebutuhan operasional di seluruh KG Media, konteks: multi organizations, multi applications.
  • Diskusi tentang konsep dan struktur Fina (dijelaskan tanpa hands-on workshop)
    • BP: Customer, Employee, Internal Organization
    • Internal Organization: Hirarki, inherintance, tree-contextual
    • Employee: User association, Employee Association
    • Alir dana keluar (Payment Workflow), terutama yang terkait dengan biaya2 karyawan
    • Bank Import, Bank Statement allocation, Kasir

  • Disampaikan (Wiwid): Item-item di HR yang mungkin terhubung ke FINA

    Items Occurence Partition
    Payroll: Gaji, Tunjangan, PPH, BPJS Tenaga Kerja, BPJS Kesehatan Bulanan Per Company, Per Cost Center
    Reimburse Medical: Obat, Dokter, Alat Kesehatan Accidental Per Employee
    Perjalanan Dinas (DLK/DLN) Accidental Per Employee
    Pinjaman Karyawan: pengajuan Accidental Per Employee
    Pinjaman Karyawan: cicilan Bulanan Per Employee
    Pinjaman Koperasi: cicilan Bulanan Per Employee
    Pesangon: Uang Pesangon, PPH Accidental Per Company, Per Cost Center
    Formulir A1 (SPT) Tahunan (Jan) Per Company, Per Cost Center
  • Usulan-Usulan:
    • Selain Payroll, perlu dikembangkan modul-modul "operasional" HR sebagai bagian dari keseluruhan sistem HR KG Media, yaitu:
      • Dinas Luar (DLK/DLN)
      • Pinjaman Karyawan
      • Reimburse Karyawan
      Modul-modul tersebut terintegrasi dengan FINA dan menjadi bagian dari keseluruhan ERP KG Media.
    • Kerjasama IT Media dan Sysdev dilanjutkan dalam konteks ERP KG Media.
2 May 2022 - 13 May 2022
Proyek FINA diliburkan karena libur dan cuti lebaran, tim kembali bekerja 17 Mei 2022.
  • Libur: 2, 3, 16 Mei 2022 (3 hari kerja)
  • Tim IT cuti tanggal 4,5,6,9,10,11,12,13 Mei 2022 (8 hari kerja)
  • Target delivery dalam timeline akan terkoreksi total 11 hari kerja. Target yang sudah direvisi dapat dilihat di tab "Delivery Schedule".
17 Mei 2022
Rapat Rutin FSD (11.00 - 17.00)
  • Hadir: DAN, WIK, YON, RDY, Yettie, Prima, Darma
  • Disepakati (ulang): Proses BS, Installment, Pre-Payment, sudah sesuai dan benar.
  • Disepakati: BS otomatis menghasilkan Installment (state: processed) dan Payment Requisition (state: new) saat BS di approve --> Payment Requisition (PD) dari BS tidak mungkin berisi gabungan installment. PD dari BS menggunakan nomor dokumen yang sama dengan nomor BS nya.
  • Disepakati: Satu slip pembayaran (Giro, Cheque, Deposit Withdrawal) bisa untuk membayar beberapa Payment Requisition (PD)
  • Disepakati: Flow penyelesaian BS yang kurang Bayar (BS < Invoice)
    1. Cara paling aman: Bikin BS baru, sama dengan proses BS biasa.
    2. Membuat Installment dari AP Invoice untuk menambal BS yang kurang. Installment bisa bertipe "Reguler" untuk dibayarkan kepada Paid To Party atau bertipe "Reimburse" untuk dibayarkan kepada employee yang nombokin.
  • Outstanding: Semua fitur FINA belum diujicoba kecuali fitur terkair Cash and Bank Receipt --> A/R, A/P, PrePayment, Receiving, Voucher, COA, Taxation, etc.
  • Outstanding: Slip pembayaran apakah bisa membayar beberapa PD sekaligus.
24 Mei 2022
Rapat Rutin FSD (11.00 - )
  • Hadir: DAN, WIK, YON, RDY, Yettie, Prima, Darma, Andika, Rohimam, Nuel, Mukhlis, Aulia, Zahra
  • Disepakati (ulang): Proses Installment, Pembayaran PD melalui bank transfer.
  • Disepakati (ulang): Proses Installment, Pembayaran PD melalui cash.
  • Disepakati (ulang): Proses Installment, Pembayaran PD melalui slip.
  • Disepakati: Saat diproses, Bank Payment akan menghasilkan Bank Payment Voucher. Nomor Bank Payment Voucher akan dilekatkan ke Payment Requisition (PD)
  • Disepakati (new): Akan dibuat layar Bank Payment Voucher (listing). Dilengkapi dengan fasilitas posting ke GL, export ke excel (various format).
  • Disepakati (new): Confirm cash payment dari PD bisa rombongan (bulk).
  • Disepakati (new): Penomoran Slip bisa auto, bisa manual. Ditambahkan checkbox "Auto Number" saat pembuatan slip (slip.new)
  • Disepakati: Satu Slip bisa membayar beberapa Payment Requisition (PD)
  • Disepakati: Penambahan jenis installment "Reimburse" di AP Invoice dengan Paid to yang berbeda dengan Paid to di AP Invoice.
  • Disepakati: Pembatalan Payment Requisition (PD) yang belum "Paid" melalui pembatalan slip, pembatalan Bank Transfer, pembatalan cash payment.
  • Outstanding: Pembatalan Payment Requisition (PD) yang sudah "Paid" --> BS Batal, Invoice batal, dll.
  • Outstanding: Outstanding penyelesaian BS, pengarsipan Invoice
  • Outstanding: Semua fitur FINA belum diujicoba kecuali fitur terkair Cash and Bank Receipt --> A/R, A/P, PrePayment, Receiving, Voucher, COA, Taxation, etc.
7 Juni 2022
Rapat Rutin FSD (11.00 - 17.25)
  • Hadir: DAN, WIK, YON, RDY, Yettie, Prima, Darma, Andika, Rohimam, Nuel, Mukhlis
  • Disepakati: Proses dalam sistem akan disepakati lebih dulu, baru konfigurasi penomoran dokumen, dan lainnya
  • Disepakati: Saat slip di confirm oleh kasir, sistem menerbitkan Bank Payment Voucher
  • Disepakati: Layar cash-payment yang baru (yang lebih sederhana)
  • Disepakati: Bank Payment Voucher untuk BS boleh digabung tapi sesama BS
  • Disepakati: Cash Payment Save --> sudah potong balance cashier
  • Disepakati: Cash Payment Post --> status2 PD, Installment, BS diupdate menjadi "Paid"
  • Outstanding: Outstanding penyelesaian BS, pengarsipan Invoice
8 Juni 2022
Rapat ERP Media Timeline (10.35 - 12.30)
  • ERP Project Kickoff??
  • Hadir: DAN, WIK, RDY, RAM, Yettie, Prima, Darma, Andika, Ninik, Yvanna, Tia, Sumani, Dobith
  • Disampaikan (DAN): Background
    1. IT Media butuh pendampingan dari "Ahli Keuangan" yang paham bisnis proses keuangan spesifik KG secara detail.
    2. Paralel proyek dan pekerjaan sela yang membengkak dikerjakan oleh tim proyek yang sama. Timeline masing-masing proyek/ pekerjaan tidak teragregasi ke timeline "global".

  • Disampaikan (DAN): Daftar proyek dan pekerjaan per 8 Juni 2022

    Pekerjaan Status ERP Scope
    FINAon going✓
    Sirkulasi 1: Migrasi KGX dari SAP ke SPSKon going, 99%−
    Sirkulasi 2: SPSK Extensionon going−
    Sirkulasi 3: All New SPSKbelum mulai✓
    Migrasi Tesys v1 ke v2stop, dialihkan ke ERP, support menyita potensi development SysDev Tribun−
    Sistem untuk Tribun unit kecilon going✓
    HR Tribunon going, lihat catatan 26 April 2022✓
    GMMS Updatebelum mulai✓
    FastAMSbelum mulai✓
    Pengganti Orlansoft TVbelum mulai✓

  • Disampaikan (DAN): Susunan tim kerja per 8 Juni 2022.

    Jenis Keterangan HR
    Developer/ Software EngineerProgrammer, Syetem Analyst, SQA, Technical Doc.IT-ES/CS: 5 orang
    IT-ES/OS: 3 orang (akan ditambah)
    SysDev: 4 orang
    IT SpecialistBusiness Analyst, Implementator, Business Support, UAT, Data transformation, Manual Doc.IT-ES/CS: 1 orang (akan ditambah)
    IT-ES/OS: 1 orang
    SysDev: 2 orang
    Financial Analyst (expert)Advise, directionCorp.FSD: 3 orang
  • Disampaikan (Dobith):
    • Kompas TV baru akan "menerima" implementasi KGMedia ERP setelah semua modul selesai dan tested.
    • Akan berkontribusi selama proyek berlangsung.
  • Disepakati: Beberapa proyek disatukan menjadi proyek KGMedia ERP dan akan disusun timeline ditingkat KGMedia ERP.
  • Disepakati: Tim FSD akan menyediakan waktu 2 hari Senin dan Selasa setiap minggu (tatap muka) untuk proyek KGMedia ERP
  • Disepakati: Tim SMO KGMedia akan mengikuti diskusi proyek setiap minggu untuk lebih memahami perkembangan dan kendala proyek, Tim SMO KGMedia (bersama yang lain) menerapkan prioritas dan fokus pekerjaan, mengupdate status dan timeline.
  • Outstanding: Rapat lanjutan untuk inventarisasi pekerjaan dan menyusun timeline "global" baru
13 Juni 2022
Rapat Rutin IT Media - FSD
  • Hadir: DAN, WIK, YON, Yettie, Darma, Andika, Rohimam, Immanuel
  • Disepakati: Saat pinjaman karyawan disetujui (approve), otomatis akan menghasilkan 1 invoice AP untuk pembayaran, 1 invoice AR untuk cicilan. Nilai AP Invoice dan AR Invoice --> gelondongan, bukan per individu.
  • Disepakati: HR memelihara sub AR dan sub AP di HR KG Media untuk tracking pinjaman individu. FINA hanya akan menerima gelondongannya.
  • Disepakati: Dinas luar yang disetujui akan menghasilkan BS dan PD untuk selanjutnya dibayarkan. Approval dinas luar sekaligus merupakan approval pada BS dan PD. Ada 2 jenis Dinas Luar, dengan BS dan tanpa BS.
  • Disepakati: Saat pertanggungjawaban Dinas Luar, form pertanggungjawaban Dinas diisi dan akan menghasilkan 1 invoice AP dengan reimburse installment atau BS installment. Item2 pengeluaran dinas luar akan langsung menjadi receiving untuk AP invoice tersebut. Approval form pertanggungjawaban dinas luar akan sekaligus mengapprove AP invoice tersebut. Proses closing tetap harus dilakukan di kasir (bukti2 fisik, dll)
  • Diskusi: Inventarisasi pekerjaan2 terkait modul atau item yang masuk dalam scope ERP.
  • Catatan: tim SMO sudah hadir di pagi hari, tapi batal rapat karena tim IT/ FSD masih menyelesaikan pekerjaan masing-masing. Akan datang lagi hari Selasa 14 Juni 2022 (miss comm).
14 Juni 2022
IT Media - FSD - SMO Media (10.15 - 12.06, 16.00 - 17.32)
  • Hadir: DAN, WIK, YON, RDY, SAB, Yettie, Darma, Andika, Yvanna, Tia, Zahra, Aulia
  • Disampaikan: Draft daftar pekerjaan terkait ERP KG Media
  • Disampaikan: Perlu segera dicari kesepakatan tentang scope dan status proyek HR KGMedia. Isu: Beberapa Tribun sudah sepakat menggunakan HR System dari Citis. Fokus: apakah perlu dilanjutkan, kalau dilanjutkan di mana "area bermain" nya.
  • Disepakati: Tim SMO akan melanjutkan inventaris pekerjaan dan menyusun timeline berdasarkan skala prioritas, terutama untuk pekerjaan-pekerjaan yang sudah jelas (scope, kebutuhan, dll).
  • Disampaikan (Yettie, ttg Sirkulasi/ SPSK): Diperlukan fasilitas untuk membuat invoice kepada special channel (toko buku, dll). Saat ini diinput ke SAP SD tapi ada kesulitan cetakan invoice nya. Kandidat solusi:
    • Menggunakan AR Invoice FINA -> Untested, tidak support produk issue, tidak support harga incl.PPN
    • Menggunakan Invoicer SPSK Extension -> Untested, sudah support product issue, sudah support harga incl.PPN
  • Disampaikan (Yettie, ttg Sirkulasi/ SPSK): PPN ikut NPWP Induk tapi alamat pajak ikut cabang. Aturan pajak baru ini berlaku juga untuk Iklan.
  • Diskusi:
    • Hanya SPSK yang punya struktur induk-anak untuk customernya (agen), sistem lain tidak menerapkan struktur tersebut.
    • Sales tidak tahu apakah customer yang bertransaksi adalah induk/ anak. NPWP dientry sesuai dengan yang diserahkan oleh customer.
  • Disepakati: Sementara terkait PPN dan NPWP tidak ada yang perlu diubah baik di SPSK maupun sistem2 penjualan lainnya.
20 Juni 2022
IT Media - FSD - SysDev (10.15 - 12.06, 16.00 - 17.32)
  • Hadir: DAN, RDY, Yettie, Sumani, Zahra, Aulia, Wiwid, Ryan, Hamzah, Yudi
  • Disampaikan (Sumani): Rencana implementasi sistem HR di Tribun terbagi 2
    1. Tribun Digital Network (TDO), Indopersda (IP), dan Wartakota, selama ini menggunakan SAP HR dan Payroll Legacy, selanjutnya akan menggunalam Odoo HR.
    2. Tribun-Tribun yang lain (Daerah) menggunakan SiSDM dan Payroll Tesys, selanjutnya akan menggunakan HR KGMedia (ERP)
    Proyek pengembangan HR KGMedia tetap dilanjutkan bahkan scopenya diperluas untuk seluruh KGMedia, bukan hanya Tribun.
  • Disepakati: Entitas Employee di KG Media mencakup
    • Karyawan yang terdaftar di HR Corporate, apapun sistemnya (SAP/ Odoo)
    • Karyawan yang terdafar hanya di sistem HR Tribun --> kontrak, kontributor, outsoucing, etc.
  • Disepakati: Akan disediakan interface ke entitas employee untuk HR Dept (karyawan) dan GA (outsource, etc)
  • Disepakati: Pembagian kerja yang lebih strict untuk development dan support di internal SysDev
  • Disepakati: Master Application akan dikelola secara terpusat pada tingkat ERP
  • Disepakati: Master organization akan dikelola secara mandiri di HR dengan rujukan (referensi) ke Organization di tingkat ERP.
  • Disepakati: Senin 27 Juni 2021 Master Employee HR KGMedia akan dipresent ke tim teknis, selanjutnya API master employee dengan FINA.
21 Juni 2022
IT Media - FSD - SysDev (10.15)
  • Hadir: DAN, RDY, YON, WIK, Yettie, Darma, Prima, Dobith, Tia (pagi)
  • Disampaikan (Darma): Jurnal-jurnal Bank Payment dan Cash Payment --> masih outstanding
  • Disepakati: Ditambah Cash Counter khusus untuk pemindahan transfer bank ke kasir karena BS (KM). Cash Counter ini melayani multi company tergantung dari company yang melakukan KM. Hanya ada 1 cash counter KM BS di seluruh sistem
  • Disepakati: Ditambah flag BS di Cash Counter, hanya boleh ada 1 cash counter yang memiliki flag ini.
  • Disepakati: Ditambah flag "Transaction types" yang boleh dilakukan disuatu cash counter.
  • Disepakati: Ditambah menu new di payment requisition (PD Manual), dapat digunakan untuk pengisian saldo kasir, dll --> skenario blm cukup jelas.
  • Outstanding: Closing BS.
    1. Alternatif 1: alat bayar "BS"
    2. Alternatif 2: (diterangkan oleh Yettie, saya masih belum jelas, anyone?)
28 Juni 2022
IT Media - FSD - SysDev - SMO (10.30)
  • Hadir: DAN, RDY, YON, WIK, Darma, Prima, Tia, [Zahra, Aulia, Wiwid, Ryan, Hamzah, Yudi] (half day)
  • Disampaikan (SysDev): Master Employee
    • Sudah ditambahkan "Relatives"
    • Organization masih dalam desain
  • Diskusi: Draft timeline ERP KG Media (Tria)
  • Disepakati: Diskusi tentang rancangan organsasi, perbedaan level organisasi antar unit bisnis, dll./li>
  • Disepakati: Timeline yang disusun oleh SMO disepakati untuk dilaporkan
  • Disepakati: Penyelesaian FINA memberikan dampak paling besar diantara penyelesaian modul-modul lainnya
  • Disepakati: Akan dilanjutkan pertemuan teknis antara SysDev - IT Media untuk detail desain master employee, organization, pertukaran data
28 Juni 2022
Rapat Core HR ERD IT Media - SysDev (14.00)
  • Hadir: DAN, RDY, YON, WIK, AHA, Zahra, Aulia, Wiwid, Ryan, Hamzah, Yudi
  • Disampaikan (SysDev): Initial ERD Core HR
  • Disampaikan (SysDev): Organization Chart Tribun (2 versi)
  • Diskusi: Entitas-entitas Core HR
    • Organization Layer: Directorate, Division, Sub Division,...
    • Position Layer: Director, GM, Manager, Supervisor,...
    • Employee Grade dan Position grade range: 1,2,3,....
    • Grade Group: A, B, C, D,.... untuk DLK, Medical, dll
    • Organization Hierarchy and Context: Organization Hierarchy Context, Organization Hierarchy
    • Employee Hierarchy and Context (operasional): Employee Hierarchy Context, Employee Hierarchy
    • Position Hierarchy
  • Disepakati: Core HR ERD, akan dilanjutkan pertemuan tentang atribute tanggal 30 Juli 2022
30 Juni 2022
Rapat ERD Core HR IT Media - SysDev
  • Hadir: DAN, RDY, YON, WIK, Zahra, Aulia, Wiwid, Ryan, Hamzah, Yudi
  • Disampaikan (SysDev): ERD dan atribut-atribut data Core HR
  • Diskusi: Atribut-atribut Core HR: Employee, Organization, Position, Employment
  • Diskusi:
    • Skenario mapping grade ke grade group: A, B, C, D,.... untuk DLK, Medical, dll
    • Organization Hierarchy and Context: Organization Hierarchy Context, Organization Hierarchy
    • Position Hierarchy
  • Disepakati: Atribut2 entitas-entitas HR Core
  • Disepakati: HR Core akan dibuat sebelum meminta masukan HR unit mengingat sudah ada pertemuan-pertemuan sebelumnya (KCM, Tribun)
  • Disepakati: HR Core akan menjadi "master" untuk entitas Organization dan Employee. Entitas sejenis di modul-modul lain (FINA, GMMS, ...) akan meng-copy dan meng-extend jika diperlukan.
  • Disepakati: Spesifikasi HR Core + Training sudah harus dapat menjawab kebutuhan yang disampaikan HR KCM kepada AHA
4 Juli 2022
Rapat Rutin IT Media - FSD
  • Breaking News: Covid-19 outbreak in Corporate Accounting Division, pembatasan pertemuan fisik disepakati.
  • Hadir: DAN, RDY, YON, WIK, Prima, Darma
  • Disampaikan (Darma, Prima): Skenario closing BS, pengalihan BS dari Bank ke Cash
  • Diskusi: Skenario jurnal dan timing proses BS, skenario pengalihan BS ke kasir.
  • Disepakati: Skenario Closing BS (tab: DEAL). IT dan FSD sepakat skenario tersebut dapat diterima dan dikerjakan. Namun akan dimintakan persetujuan Yettie yang hari itu sedang sakit.
7 Juli 2022
IT Media - SysDev
  • Hadir: DAN, RDY, YON, WIK, Zahra, Aulia, Wiwid, Yudi
  • Disampaikan (SysDev): Hasil pertemuan dengan HR Tribun (Mbak Iin) terkait golongan fasilitas (DLK, Medical). Di Tribun dikenakan pada posisi, posisi tertinggi yang diambil.
  • Diskusi: Separasi pengelolaan Employee misalnya: KGHR, Tribun HR, Kompas HR, KG Media HR, dll
  • Diskusi: Pemberian fasilitas di Kompas dan KCM yang melekat ke golongan employee
  • Diskusi: Skenario penyatuan data "employee" dari berbagai sistem HR dan pendukungnya di KG Media HR, skenario pertukaran data.
  • Diskusi: Progress development --> mundur
  • Disepakati: Penambahan atribut pengelolaan employee sehingga pengelolaan dapat dioper antar HR
  • Disepakati: Mekanisme penyatuan data "employee" di HR KG Media (pengepul) sehingga modul2 lain (FINA, GMMS, etc) tinggal mengambil sesuai kepentingan
8 Juli 2022
IT Media - FSD
  • Hadir: DAN, RDY, YON, WIK, Yettie, Darma, Prima
  • Diskusi: ERD HR Core Final
  • Diskusi: Work History
  • Disepakati: Layar Realisasi BS, flow pengisian:
    • Pilih (add) AP Invoice yang sudah posted
    • Sistem menampilkan installment AP Invoice yang dipilih
    • Sistem menampilkan informasi BS yang melekat ke Invoice yang dipilih
    • Jika ada sisa BS maka input receipt pengembalian dana BS (bank/ cash)
  • Disepakati: Realisasi BS sudah bisa di coding
11 Juli 2022
IT Media - SysDev
  • Hadir: DAN, RDY, YON, WIK, Zahra, Aulia, Wiwid, Ryan, Yudi
  • Diskusi: Progress pengembangan modul HR
  • Diskusi: Employment dan Assignment
  • Diskusi: Work history (pengalaman kerja)
  • Disepakati: Modularity KG Media HR: Core, Expense and Benefit, Competency,...
  • Disepakati: Module-modul HR akan diselesaikan sesuai urutan:
    • HR Core selesai Juli 2022.
    • Training selesai Juli 2022.
    • Expense & Benefit
    • Time Management
    Pertimbangan-pertimbangan: akan digunakan oleh KCM (ikut absensi HR Pusat), akan digunakan oleh Tribun daerah (presensi tidak pengaruh ke uang makan)
12 Juli 2022
Progress Report Proyek ERP 1
  • Hadir: Andreas Tirtarianto, Miftahun Nimah, Hadrianus Tjiptyantoro, Yettie, Sumani, RAM, DAN, RDY, WIK, AHA, Dobith Mulyawan
  • Disampaikan (RAM):
    • Scope, Modularity ERP KG Media
    • Time line untuk FINA, Sirkulasi, dan HR
    • FINA perlu mendapat fokus karena memberikan dampak terbesar
  • Disampaikan (Sumani):
    • Tribun2 baru yang tidak menggunakan Tesys sudah makin banyak, laporan keuangan sudah bisa diolah (GL Window?), akan menggunakan fasilitas Invoicer yang tersedia di FINA
    • SysDev Tribun masih banyak pekerjaan support tapi pengembangan modul HR sudah lebih cepat. HR sistem diperlukan oleh Tribun2 daerah, outsourcing, dll
    • Ruangan untuk tim KG Media HR sudah disediakan dan sudah digunakan
  • Disampaikan (Pak Tjip):
    • Tanya: apakah September sudah dapat digunakan, dijawab oleh RAM bisa dengan penyesuaian khusus untuk unit penggunanya
    • Kehadiran ERP sudah sangat dibutuhkan apalagi sudah makin banyak muncul tribun-tribun digital yang baru, saat ini menggunakan excel dan inisiatif "Invoicer" sudah masuk ke FINA
    • FSD perlu diperkuat karena sangat dibutuhkan untuk percepatan penyelesaian proyek
  • Disampaikan (Andreas):
    • Perlu diskusi dengan pengguna (user) supaya inisiatif perubahan sistem dapat diterima. Keluhan dan keinginan user perlu didengar.
    • Sistem diharapkan dapat digunakan oleh unit-unit dengan karakteristik yang berbeda-beda, sistem harus cukup fleksibel mengantisipasi kebutuhan kontrol yang berbeda-beda.
    • User jangan sampai merasa dipersulit karena kontrol yang tidak dibutuhkan muncul bersama sistem yang baru.
    • KG Media sedang menyusun standar agar perbedaan proses di masing-masing unit tidak terlalu jauh.
    • Diharapkan sistem dapat menyediakan report yang lebih realtime.
  • Disepakati: FINA mendapat prioritas.
  • Disepakati: Scope dan Timeline ERP
13 Juli 2022
IT Media - SysDev (Zoom, 17.00)
  • Hadir: DAN, Yettie, Darma, Prima
  • Disampaikan (DAN): Layar Realisasi BS (List, Edit)
  • Disampaikan (DAN): Save belum bisa
  • Diskusi:
    • Jurnal-jurnal
    • AP Invoice installment yang belum terbayar
    • Penundaan verifikasi realisasi sampai seluruh installment terbayar
  • Disepakati: Layar Realisasi BS sudah OK, diskusi selanjutnya tentang jurnal dan timingnya.
19 Juli 2022
WA Call DAN - YETTIE (08.00)
  • Disampaikan (DAN): Layar Realisasi BS sudah selesai, siap dicoba
  • Disampaikan (DAN): DAN, tidak hadir rapat online karena keluarga sedang sakit. Diharapkan rapat Selasa tetap berjalan.
    Update 11.00: DAN kena covid, YON tidak bisa masuk kantor karena blm booster. Rapat Selasa ditunda.
  • Disepakati: Layar Realisasi BS akan dicoba oleh FSD.
26 Juli 2022
Rapat Rutin IT Media - FSD (14.00)
  • Hadir: YON, RDY, Yettie, Darma, Andika
  • Disampaikan: Temuan dari test, Bank Payment Voucher yang dihasilkan dipisah sampai per rekening penerima dana. Saat ini Bank Payment Voucher dipisah sampai ke Party penerima dana.
  • Disampaikan: Ketika PD New diminta ada action Send dan Approve, setelah di approve baru bisa dilanjut ke proses berikut nya PD Generate Transfer (Transfer) / Generate Slip (BG/CQ) / Process (Cash) --> belum sepakat karena sudah ada action "proses" yang setara.
  • Disampaikan: Pada saat cash payment save mengechek balance counter jika kurang maka muncul message error dan tidak bisa di save . Cashier harus lakukan top up --> (update: tdk bisa dilakukan karena against mekanisme otomatis pinjam Funder)
  • Disampaikan: AP Invoice bisa di posting tanpa melakukan WAPU --> saat ini posting tidak bisa dilakukan kecuali WAPU sudah diproses.
  • Disampaikan: Proses intallment verified atau generate PD jika ada income tax harus dilakukan WAPU baru bisa di proses create PD --> tidak perlu ada pemeriksaan karena Installment dan PD baru muncul dari Invoice AP yang sudah diposting
  • Disampaikan: Masih muncul protocol error 500 jika menyimpan AP invoice dengan kombinasi item VAT, Include Tax ,dll --> check
  • Disepakati: Ditambahkan Paid Ammount di AP Invoice rumus Netto - Income Tax --> ditambahkan
  • Disepakati: Generate Bank Transfer - Jika no tujuan Bank Account berbeda maka BPV akan terbuat sesuai Bank Account sekarang masih ke PARTY
27 Juli 2022
IT Media - FSD (10.30)
  • Hadir: YON, RDY, Nuel, Rohimam, Yettie, Darma, Andika
1 Agustus 2022
IT Media - SysDev R.Rapat Tribun (10.30)
  • Hadir: DAN, AHA, Wid, Ryan
  • Diskusi: Kesesuaian desain dengan hasil
    • One to many Employment
    • Legal marital status, marital status
  • Diskusi: Kesulitan teknis untuk deploy dengan https ke hr.kgmedia.id (diskusi dengan AHA)
1 Agustus 2022
IT Media - FSD (14.30)
  • Hadir: DAN, YON, RDY, Yettie, Darma, Andika, Mukhlis, Immanuel
  • Disepakati: PD Approval ditambahkan untuk semua pembayaran, sebelum diproses masing-masing sesuai alat bayarnya
  • Disepakati: DP Installment tidak perlu diproses langsung menjadi PD, ikut proses penggabungan, boleh digabung sesama DP.
  • Disepakati: DP Invoice tambah PPH, diperlakukan pada DP Amount
  • Disepakati: Ditambahkan beberapa kolom di Installment untuk mengontrol bukti potong PPH (WAPU) yang menjadi pengurang pembayaran:
    • InstallmentAmount --> Original Installment Amount
    • IncomeTaxAmount --> Income Tax Amount (WHT Out/ WAPU)
    • Informasi WHT Out/ WAPU --> IncomeTaxID, IncomeTaxNumber, IncomeTaxLocked (agar tidak diproses menjadi PD)
    IncomeTax Amount diisi saat Invoice AP/ Invoice DP diposting Nilai IncomeTax akan mengurangi nilai yang harus dibayar (Amount = InstallmentAmount - IncomeTaxAmount). Jika bukti potong belum diproses, maka Installment akan di locked, tidak bisa diproses menjadi PD (overule all). Installment yang dipotong dengan IncomeTax adalah installment terakhir dari AP Invoice ybs.
  • Disepakati: Ditambahkan filter "Workstate" di report SPSK_Receipt_Transaction
  • Akan didiskusikan dengan Mas Yono:
    AP Invoice Installments I.Amount PPH Amount Keterangan
    AP Invoice 14,000.00 700.00 13,300.00 header, PPH: 5%
      DP Installment 1 2,000.00 100.00 1,900.00 PPH sudah diregister
      DP Installment 2 2,000.00 0.00 2,000.00 DP tanpa PPH
      DP Installment 3 2,000.00 100.00 1,900.00 PPH sudah diregister
      Regular Installment 1 4,000.00 0.00 4,000.00 Tanpa PPH
      Regular Installment 2 4,000.00 500.00 3,500.00 Rule: sisa PPH di installment terakhir
    (update: 2 Agustus 2022 → WHT perlu input DP, hitungan di atas bisa dikembangkan).
2 Agustus 2022
Rapat Rutin Selasa (10.30)
  • Hadir: DAN, YON, RDY, Yettie, Prima, Darma, Andika, Tria, Mukhlis, Nuel
  • Disepakati: Pengembangan kalkulasi PPH di installment Reguler dan DP seperti usulan tanggal 1 Agustus 2022.
  • Disepakati: WHT Out searching di Add/ Edit perlu ditambah untuk mencari ke Invoice DP
  • Disepakati: Penambahan "masa pajak" di WHT IN dan WHT Out, default: TaxDate (tanggal pajak). Format masa pajak: YYYY-MM. Rentang 5 tahun
  • Outstanding: Determinasi Budget dan Cost Center untuk BS dll.
  • Outstanding: (Yettie) Struktur Budget per account akan coba dialirkan ke tingkat Cost Center/ Profit Center yang lebih "operasional" (catatan 15 Maret 2022)
3 Agustus 2022
WA Chat YON - Yettie (10.30)
  • Hadir: YON, Yettie
  • Disepakati: Di APInvoice, pengenaan "sisa" WHTOut (setelah dikurangi WHTOut DP) bisa ke seluruh Regular Installment dalam AP Invoice tersebut. Aturan pengenaan WHTOut di Regular Installment terakhir dibatalkan
  • Outstanding: Determinasi Budget dan Cost Center untuk BS dll.
  • Outstanding: (Yettie) Struktur Budget per account akan coba dialirkan ke tingkat Cost Center/ Profit Center yang lebih "operasional" (catatan 15 Maret 2022)
9 Agustus 2022
Rapat Rutin ERP (10.30)
  • Hadir: DAN, YON, RDY, WIK, Yettie, Prima, Darma, Andika, Irwan, Tria, Novi, Lintang
  • Disampaikan (DAN): Perubahan dan update dari catatan tanggal 1 Agustus 2022 sampai tanggal 3 Agustus sudah diselesaikan, siap diuji.
  • Disampaikan (PRIMA): Format ebupot dan inventaris kolom2 excel untuk upload.
  • Disepakati: Nama party yang akan dicantumkan ke Giro bisa diubah oleh Petugas AP sebelum PD di approve. Default Name: holder name di bank account
  • Disepakati: Angka Netto (Downpayment + VAT) ditampilkan di Invoice Down Paymenyt.Detail dan Add Edit
  • Disepakati: Angka Netto dari DP yang diambil untuk installment AP Invoice
  • Disepakati: Kolom Tax Number di AP Invoice harus diisi jika VAT tidak sama dengan 0. Beberapa Invoice boleh memiliki Tax Number yang sama.
  • Disepakati: Ditambahkan kontrol untuk "add" dan "delete" AP Invoice di layar VAT In
  • Disepakati: Nama penyusun ebupot/ penandatangan dipilih waktu add/edit WHT Out (Wapu), default employee yang associated dengan user
  • Disepakati: AP dan DP Invoice, pilihan jenis VAT otomatis di set 0 untuk party Non PKP (pengusaha kena pajak)
  • Outstanding: Format dan ujicoba bukti potong unifikasi untuk ebupot
  • Outstanding: Determinasi Budget dan Cost Center untuk BS dll.
  • Outstanding: (Yettie) Struktur Budget per account akan coba dialirkan ke tingkat Cost Center/ Profit Center yang lebih "operasional" (catatan 15 Maret 2022)
12 Agustus 2022
Rapat IT Media - SysDev (R. Labuhan Bajo Tribun Palbar 10.30 - 11.35)
  • Hadir: DAN, AHA, RAM, Sumani, Wid, Ryan, Yudi, Aulia, Zahra
  • Disampaikan (RAM):
    • Progress pengembangan modul HR sampai di mana
    • Sysdev sudah masuk dalam tim ERP, diharapkan dapat bekerja bersama, jika ada kendala/ kesulitan bisa dipecahkan bersama.
    • Memperkenalkan AHA sebagai bagian dari tim ERP HR yang sudah berpengalaman membuat sistem menggunakan teknologi yang digunakan oleh Sysdev.
  • Disampaikan (Sumani):
    • Software development bukan area Mbak Sumani. Dalam proses pengembangan biasanya berperan dalam test (UAT).
    • Ada Mas Agus dan IT Media yang bisa mengarahkan dan membantu pengembangan software oleh SysDev.
  • Disampaikan (Aulia):
    • Ada kendala untuk hadir dalam pertemuan selasa karena persyaratan "Peduli Lindungi"
    • Sudah bertemu dengan user, ada perbedaan kebutuhan antar PT (Tribun, KCM, Kompas)
  • Disampaikan (DAN): Mengingatkan kembali kesepakatan-kesepakatan sebelumnya (IT Media - FSD - SysDev - SMO)
    • HR Core seharusnya sudah selesai bulan Juli 2022
    • Setelah melalui 5 kali pertemuan antara SysDev dan IT Media, desain HR Core sudah disepakati 30 Juni 2022 dan tidak ada perubahan sejak 7 Juli 2022
    • Pembagian kerja internal SysDev untuk pengembangan dan support yang lebih tegas sehingga dua fungsi tersebut dapat berjalan bersama.
    • Tidak mengadakan pertemuan "requirement gathering" dengan calon pengguna sebelum modul Core HR jadi sesuai desain agar ada "base" untuk membangun kesepakatan dengan calon user (30 Juni 2022).
      HR Core + Training sudah bisa menjawab kebutuhan yang disampaikan HR KCM kepada AHA, kemungkinan implementasi awal di KCM
    • Site https://hr.kgmedia.id (production) dan repo https://git.kgmedia.id/es/hr-kgmedia sudah disediakan oleh tim infrastriktur dan AHA.
    • Pertemuan 1 Agustus 2022 karena DAN, AHA sulit memantau progress penyelesaian modul HR Core.
  • Disampaikan (DAN): HR Core belum jadi, tidak memenuhi "KPI" sbb:
    1. Fitur-fitur sudah berfungsi sesuai desain
    2. Sudah dideploy ke site development sehingga bisa di review bersama
    3. Source code sudah di push ke repo
    4. Dokumentasi terkumpul dan bisa diakses bersama
  • Disampaikan (DAN): Tanggapan modul HR Core di hr.kgmedia.id per 12 Agustus 2022
    • Employee Master sudah ada, sudah bisa ditunjukkan
    • Organisasi belum menunjukkan hirarki nya
    • Banyak "mockup" UI yang tidak masuk dalam delivery HR Core perlu dihilangkan. Potensi: Mengaburkan fokus (fitur, hasil), mengajak user untuk "mimpi bersama", menunjukkan ketidaksiapan.
    • Efektivitas UI: side menu, tombol edit/ hapus (technical)
  • Disepakati: Akan dipersiapkan site development modul HR karena proses ftp ke cloud lama.
  • Disepakati: Timeline akan disusun ulang bersama SMO
  • Disepakati (ulang): Sinkronisasi jadwal SysDev dengan tim ERP, pertemuan mingguan
16 Agustus 2022
Rapat Rutin ERP (10.30)
  • Hadir: DAN, YON, RDY, Yettie, Prima, Andika, Irwan, Tria, Novi, Lintang, Mukhlis, Rohimam, Nuel
  • Disampaikan (Yettie): Kemungkinan perubahan dan update WHT Out (WAPU) untuk merujuk installment dalam invoice AP
  • Disampaikan (Yettie): Dasar pengenaan pajak (DPP) untuk perhitungan WHT Out (WAPU) diambil [IncomeTax]/[IncomeTaxPct].
  • Disampaikan (DAN): Progress pengembangan HR as of 12 Agustus 2022.
  • Disepakati: Dasar pengenaan pajak (DPP) ditampilkan di layar WHT Out (WAPU).
  • Disepakati: Struktur WFT Out (WAPU) 1 bukti potong 1 invoice tetap dipertahankan (seperti versi 16 Agustus 2022)
  • Outstanding: Format dan ujicoba bukti potong unifikasi untuk ebupot, hasil percobaan upload excel.
  • Outstanding: Determinasi Budget dan Cost Center untuk BS dll.
  • Outstanding: (Yettie) Struktur Budget per account akan coba dialirkan ke tingkat Cost Center/ Profit Center yang lebih "operasional" (catatan 15 Maret 2022)
22 Agustus 2022
Rapat IT Media - SysDev Tribun (10.00 - 12.00 di O2)
  • Hadir: AHA, Aulia, Zahra, Yudthi, Ryan
  • Diskusi : Organisasi dan Position
  • Disepakati Form Organisasi Detail
    1. Hide Associated BP
    2. Hide Approval Hierarchy
    3. Penambahan Required data, yang wajib diisi hanya Nama Organisasi dan Parent Id
    4. Hide Menu Hierarchy di drop down Organisasi
  • Disepakati pada Form Position
    1. Penambahan Field Jobdesk
    2. Pada isian Organisasi dibuat Select To
  • Disepakati: Pembahasan selanjutnya, Hari Kamis, 25 Agustus 2022 after makan siang
    1. Pembahasan Position dan penambahan data
    2. Input data employee
  • Outstanding: Modul HR Core
23 Agustus 2022
Rapat IT Media - FSD (10.00 - 12.00 di O2)
  • Hadir: DAN, YON, Rohimam, Lintang, Novi, WIK, Yettie, Prima, Darma, Andika, Tria, Irwan
  • Disampaikan (FSD): Skenario jurnal untuk account addressing
  • Diskusi: Tentang Closing DP Invoice
    • Pembatalan DP sebagian/ total sangat jarang sampai terjadi pengembalian dana oleh Supplier
    • Jika nilai DP Invoice lebih besar dari nilai barang/ jasa yang diterima maka harus diterbitkan CI atas DP Invoice tsb. CI DP kemudian di clearing dengan penerimaan (bank/ cash)
    • DP otomatis di "close" jika nilainya sudah 0 pada saat AP Invoice yang memuat DP tersebut di posting
  • Disepakati: Paid to Party di DP Invoice hanya Supplier.
  • Disampaikan (FSD): Rujukan skenario A/R yang telah disampaikan dan disepakati bersama IT Media ternyata tidak lengkap sehingga menyebabkan modul A/R Fina yang sudah jadi tidak sesuai ekspektasi. Modul A/R yang lebih sesuai adalah "mirror" modul A/P.
  • Disepakati: Modul A/R di Fina yang ada sekarang dianggap sudah selesai, tidak ada lagi pengembangan pada modul tersebut.
  • Disepakati: Disepakati akan dibangun modul A/R yang baru dan akan dimulai pengembangannya setelah modul A/P yang dijadikan rujukan selesai diuji.
  • Diskusi: Pengalihan pembayaran BS dari Bank ke Kas melalui voucher tanpa mengubah cash balance
    • Metode yang sudah dipikirkan Create CR dan CP di Cash Counter khusus BS
    • Metode lain melalui Voucher Bank dan Voucher Cash
  • Outstanding: AP Memo Type (reason memo) di Memo A/P.
  • Outstanding: Flag eksternal dan internal (KG dan Non KG) di Customer dan Supplier.
  • Outstanding: Metode pengalihan pembayaran BS dari Bank ke Kas.
  • Outstanding: Waktu yang diperlukan untuk membuat modul A/R yang baru.
30 Agustus 2022
Rapat IT Media - FSD (14.47 - )
  • Hadir: YON, RDY, WIK, Yettie, Dharma, Andika, Lintang, Novi
  • Disampaikan (FSD): DP Invoice
    • DP Amount=500,000.00
    • VAT = 10% = 50,000.00
    • PPH = 6% = 30,000.00
    • Amount = 520,000.00

    DP Balance yang diinginkan Mbak Yettie:

      Desciption Debit Credit Balance
    DP Invoice.Confirmed Confirmed 500,000.00 0.00 500,000.00
    Payment Requisition di Paid Paid 0.00 0.00 500,000.00
    AP Invoice.Posting   0.00 100,000.00 400,000.00
    AP Invoice.Posting   0.00 200,000.00 200,000.00

    Di A/P Balance urutannya:

    DPAP Invoice DP 4,440,000 
    BPMPayment Supplier4,440,000  
  • Penanganan AP Invoice dan DP Invoice menggunakan Kasus 1 simulasi tim mbak Yettie : Untuk pembayaran termin, maka buat DP Invoice sampai termin selesai. Setelah pembayaran termin selesai maka baru dibuat AP Invoicenya yang merujuk ke beberapa DP Invoice tersebut. VAT dan Income Tax dimasukkan di DP Invoice, sedangkan AP Invoice yang direlasikan dg DP Invoice diset VAT 0, Income Tax 0. AP Invoice jika Installment mengandung Installment Type = DP maka tidak boleh ada installment dg type lain. Bagaimana efek dg Tax In Number mandatory cek jika VAT > 0 ?
    1. Ap Inv Turunan untuk menandakan VAT tidak perlu diinput
    2. Ditambahkan flag dummy supaya no nya tidak dilaporkan
  • Menambahkan Transaction Type untuk Alloctaion DP
    Keterangan DP Balance  AP Balance
    (AP Balance = Gross + VAT)    		 PPN Balance(VAT In) PPh Balance(WHT Out)
    DP Invoice1.DP Amount = 400,000DP Invoice1.VAT = 10% = 40,000DP Invoice1.IncomeTax = 6% = 24,000    
    DP Invoice1.Confirm 440,000Debit 400,000Credit 440,000Debit 40,000Credit 24,000
    DP Invoice1.Paid 440,000 Debit 440,000  
    DP Invoice2.DP Amount = 600,000DP Invoice2.VAT = 10% = 60,000DP Invoice2.IncomeTax = 6% = 36,000    
    DP Invoice2.Confirm 440,000Debit 600,000Credit 660,000Debit 60,000Credit 36,000
    DP Invoice2.Paid 440,000 Debit 660,000  
    AP Invoice.Amount dari Invoice AP Asli = 1,000,000AP Invoice.VAT = 0%AP Invoice.Installment DP1 400,000AP Invoice.Installment DP2 600,000    
    AP Invoice.Posting  Credit 400,000Credit 600,000AP Inv  Credit 1,000,000 Alloc DP 1  Debit 400.000Alloc DP 2 Debut 600.000  
  • VAT In
    • Saat ini mengambil dari AP Invoice tidak dari DP Invoice
    • AP Invoice1.Tax In Number diedit dari 100 ke 200 maka seharusnya VAT In.Tax In Number = 100 dihapus, VAT In.Tax In Number = 200 diinsert AP Invoice1. Jadi masih BUG.
  • DP Invoice
    • Due Date minta direname menjadi Base Date
    • Tambah field: PO, TOP, Tax In Number, Tax In Date
    Mbak Yettie : Neraca tidak butuh profit center sehingga di DP Invoice tidak perlu ditambahkan Profit Center
  • AP Invoice
    • AP Invoice.Installment AddEdit.VAT ditambahkan
    • AP Invoice.Installment AddEdit.VAT nilai proporsi dari DP Invoice.Balance
    • AP Invoice.Installment AddEdit.DownPayment Amount default terisi dari DP Invoice.Balance selanjutnya bisa diubah
    • AP Invoice.Installment AddEdit.VAT dan AP Invoice.Installment AddEdit.Income Tax dihitung proporsi dari AP Invoice.Installment AddEdit.DownPayment Amount
  • Appdev.kompas.com/spskxt/ Invoice/AddEdit/0
    RUMUS
    Gross = Unit Cost x Quantity
    Discount = Unit Cost x Quantity x Persen Discount
    Net After Tax = Gross - Discount
    Net Before Tax = Net After Tax / (100 % + Persentase PPN)
    PPN = Net Before Tax x Persentase PPN

    Seharusnya nilai seperti di bawah:
    Net After Tax = 4,830,000
6 September 2022
Rapat IT Media - FSD (10.00 - 12.00)
  • Hadir: Mas Daniel, Mas Yono, Mas Rudy, Mbak Wiwik, Novi, Lintang, Mbak Yettie, Mbak Prima, Mas Andika, Mas Irwan
  • Ketika Down Payment dikonfirmasi atau Post DP menghasilkan 2 proses yaitu Payment Requisition atau Pesanan Dana (PD) yang nantinya akan memproses payment melalui Bank Payment maupun Cash Payment, dan Down Payment Balance. Saat Down Payment Balance sudah dapat dilihat proses confirmed dan paidnya, dilanjutkan dengan AP Invoicing yang nantinya mengarah ke AP Invoice.
20 September 2022
Rapat IT Media - FSD (14.00 - )
  • Hadir: DAN, YON, RDY, WIK, Lintang, Novi, Irwan, Yettie, Prima, Darma, Andika
  • Disampaikan (DAN): Seluruh perubahan yang disepakati sejak 1 Agustus sampai 20 September 2022 sudah diselesaikan, 1 request (minor) lupa belum dikerjakan.
  • Diskusi: VAT In di AP Invoice, DP Invoice (partial)
  • Disepakati: Penambahan flag "IN", "OUT", "CORP" di bank account. Pilihan tersebut diset dari registrasi di Organization. Untuk Customer, Supplier, Employee otomatis diset: IN, OUT, not CORP.
  • Disepakati: VAT In yang dikirimkan dari AP Invoice adalah penjumlahan (sum) dari VAT installment regular/ reimburse (non DP) dalam AP Invoice tersebut
  • Disepakati: Input "VAT In Number" di header AP Invoice diisi dengan nomor VAT IN atas sum (penjumlahan) regular/ reimburse (non DP) installment
  • Disepakati: Jika di dalam AP Invoice seluruhnya atas installment DP, maka AP Invoice tidak mengirimankan VAT IN, isian "VAT IN NUMBER" di disabled (dikosongkan)
4 October 2022
Rapat EPR Media (10.00 - )
  • Hadir: DAN, YON, RDY, WIK, Irwan, Tria, Prima, Andika
  • Disampaikan (SM): Sedang menyusun laporan ke manajemen, status proyek ERP Media termasuk yang akan dilaporkan. Disampaikan kerangka laporan, diharapkan tidak terjadi perbedaan pendapat antara laporan IT, laporan SM, dan laporan FSD.
  • Disampaikan (DAN): Perlu dilaporkan juga "challenges" dan "constraints" dalam penyelesaian proyek sehingga tidak selalu "timeline" yang menjadi sorotan (tambahan waktu blm tentu menyelesaikan masalah).
  • Diskusi: Status penyelesaian fungsi-fungsi FINA
  • Disepakati: Bank Payment perlu dimasukkan ke Payment List. Karena Payment List adalah "mirror" dari Receipt List maka akan masuk pada tingkat transaksi terkecil (PAYC, PAYS) --> tingkat installment
  • Disepakati: Input AP Invoice Installment untuk item-item yang beda PPN sudah benar seperti sekarang hanya perlu dibuka input amount nya dan dibuka validasinya.
  • Disepakati: Akan dilengkapi skenario testing oleh FSD, sehingga proses testing bisa dilanjutkan oleh teman-teman lain (IT Media, dll).
  • Disepakati: VAT In edit akan ditambahkan masa pajak
11 October 2022
Rapat EPR Media (10.00 - )
  • Hadir: DAN, YON, RDY, WIK, Irwan, Prima, Andika, Darma, AHA, Aulia, Ryan, Yutdhi
  • Disepakati: Balance BS nilai pemotong adalah AP Invoice installment amount + VAT (Netto)
  • Disepakati: BS validate tetap menggunakan UI yang sama, akan dibatasi hak akses.
  • Disepakati: BS validate melakukan posting ke AP Balance
  • Disepakati: Penambahan kalkulator untuk menghitung nilai installment amount berdasarkan netto dan ppn
  • Diskusi: Timeline modul2 HR (Irwan)
  • Disepakati: BS kekuarangan dana akan dibuat otomatis (tanpa approval) jika atribut2 BS bisa disupply
  • Disampaikan (DARMA): Pengiriman BS ke cash counter, memunculkan transaksi (KM) di Bank dan di Cash.
  • Disampaikan (DARMA): Nama di Slip (Bank Account Holder) seharusnya ambil dari Bank Account, akalau ada beberapa seharusnya disediakan pilihan.
  • Diskusi:
    • Transaksi2 KM jika masuk sebagai transaksi akan masuk ke Payment List dan Receipt List, dan perlu dilanjutkan prosesnya.
    • Transaksi2 KM di Cash membutuhkan "virtual cashier" login ke cash counter, atribut2 seperti: Sales Org, Purchasing Org, Source App, dll.
    • Usulan: masuk sebagai transaksi KM sejajar dengan Bal In, BalOut → hanya tentang amount saja
  • Outstanding (DARMA): Atribut2 BS otomatis untuk menambal kekurangan dana
  • Outstanding (DARMA): Konfirmasi pemindahan BS ke cash counter.
28 November 2022
Rapat EPR Media (13.30 - 17.00)
  • Hadir: DAN, YON, RDY, WIK, Yettie, Andika, Darma, Putri, Sumani, Aulia, Sahra
  • Disampaikan (Yettie, Sumani): Ada keperluan untuk menghitung kebutuhan dan waktu pengembangan modul G/L FINA
  • Disepakati: Tidak ada perubahan skenario untuk implementasi di Tribun bulan Feb 2023
  • Disampaikan (DAN): Perlu detail mapping/ translasi Transaksi FINA ke Akun2
  • Disepakati: Template excell mapping Transaksi FINA ke COA (Account Addressing)
  • Disepakati: Spesifikasi GL Windows dan GL SAP akan dibahas Selasa, 29 November 2022
  • Disepakati: Produk FINA ditambah flag "Apply Income Tax", Invoice AR (item) menyesuaikan flag "Income Tax" sesuai produk yang dipilih. (selesai 28 Nov 2022)
  • Disampaikan (Sumani): Minta fasilitas cetak faktur pajak tanpa QR
  • Outstanding (DARMA): Mapping transaction ke akun (Account Addressing)
29 November 2022
Rapat EPR Media (10.50 - )
  • Hadir: DAN, YON, RDY, WIK, Yettie, Andika, Darma, Putri, Irwan, Prima (nyusul)
  • Disampaikan (Yettie): Master GL --> Account, Company, LE, dll
  • Disepakati: Akun khusus "Retained Earning" akan disimpan sebagai setting, akan dibaca saat proses closing tahunan
  • Disepakati: COA Category ditambah Planning Category (Revenue/ Expense/ None)
  • Disepakati: Untuk list/ input "Planing" menggunakan cara batch, filter: Company, Tahun, Planning Category. Cost Center dan Profit Center ada di row.
  • Disepakati: Hasil account addressing masuk ke jurnal langsung dengan status "New" (atau setara). Perlu konfirmasi dari petugas accounting sebelum entry journal menjadi "Fixed"
  • Disepakati: Cash Receipt setara dengan Cash Receipt Voucher akan menjadi source doc di GL
  • Outstanding (DARMA): Mapping transaction ke akun (Account Addressing)
2 Desember 2022
Rapat EPR Media (10.50 - )
  • Hadir: DAN, YON, RDY, Yettie, Andika, Darma, Putri, Prima, Sumani, Aulia, Zahra
  • Disepakati: Tambah field "Cash Code" di Journal Entry
  • Disepakati: Ditutup fungsi untuk menginput jurnal "Single line"
  • Diskusi: Pembulatan (rounding) sejak dari AP/ AR/ Bank/ Cash sampai ke GL
  • Disepakati: Product Master Fina akan dikaitkan dengan [ProductCategory] dan [ProductType] yang di sync dari GMMS.
  • Disepakati: Saat penyusunan AP Invoice/ AR Invoice harus memilih produk dari daftar [Product] dalam master tersebut.
  • Disepakati: Master Product di FINA perlu ditambah flag "for AP" dan "for AR".
  • Disepakati: Master Product FINA akan dikelola oleh Finance team
  • Diskusi: Account addressing, penambahan cash code, mekanisme pencarian addressing
  • Outstanding: Policy tentang pembulatan (rounding)
  • Outstanding (IT): Sync Product Category, Product Type, dan Product Usage dari GMMS, Penyesuaian AP Invoice, AR Invoice, dan Receiving.
  • Outstanding (DARMA): Mapping transaction ke akun (Account Addressing)
6 Desember 2022
Rapat EPR Media (11.00 - 17.30)
  • Hadir: DAN, YON, RDY, WIK, Andika, Darma, Putri, Gilang, Prima, Rohiman, Mukhlis, Rudyanto
  • Disepakati: Security (hak akses) diterapkan pada partition data terlebih dahulu. Jika memungkinkan (waktu/ performance) akan dilekatkan ke alat bantu pengisian (filter, selector, dll/ non data).
  • Disepakati: Pengikatan periode di jurnal, mengikuti [Periode] open yang dipilih saat posting
  • Disepakati: Journal entry list mencantumkan [EntryDate] karena [PostingDate] baru diperoleh ketika posting dilakukan
  • Disepakati: Periode tidak ditentukan saat transaction/ entry, baru ditentukan saat posting (bisa rombongan).
  • Diskusi: Pembatasan account yang available untuk Journal Entry kiriman (non Manual). Salah satu usulan: bisa di edit account nya dengan account lain dari Sub Ledger yang sama.
  • Disepakati: Ditambahkan info di COA Master untuk mengatur enable/ disable atribut2 dalam jurnal, misalnya CC, PC, BA.
  • Disepakati: Pilihan2 Business Area (BA), Profit Center (PC), dan Cost Center (CC) di Journal entry harus sesuai dengan pilihan Company nya.
  • Outstanding: Policy tentang pembulatan (rounding)
  • Outstanding (IT): Sync Product Category, Product Type, dan Product Usage dari GMMS, Penyesuaian AP Invoice, AR Invoice, dan Receiving.
  • Outstanding (DARMA): Mapping transaction ke akun (Account Addressing), ditambah "Account Number", Master Amount, Cash Code (y/n)
9 Desember 2022
Account addressing scenario (excel, status: unfinishe) dikirimkan oleh Darma dan Andika via WA Chat (10.06)
  • Outstanding: Policy tentang pembulatan (rounding)
  • Outstanding (IT): Sync Product Category, Product Type, dan Product Usage dari GMMS, Penyesuaian AP Invoice, AR Invoice, dan Receiving.
  • Outstanding (DARMA): Mapping transaction ke akun (Account Addressing), ditambah "Account Number", Master Amount, Cash Code (y/n)
20 Desember 2022
Rapat EPR Media (14.20 - )
  • Hadir: DAN, YON, RDY, WIK, Andika, Darma, Putri, Gilang, Prima, Aulia, Sumani, Sahra, Riska
  • Disepakati: Income Tax tidak tergantung pada Tax Type, Tax Type hanya untuk PPN --> dihilangkan
  • Diusulkan (IT): Penyederhanaan Product mapping ke COA --> ditolak
  • Disepakati: Setiap FINA Product memiliki attribute Product Category dan Product Type
  • Disepakati: Pemilihan product di A/R Invoice dan A/P Invoice: FINA Product, Product Usage
  • Disampaikan (YETTIE): Konsep penerapan "Cash Code" saat pembayaran
  • Diskusi: Penerapan Cash Code
  • Disampaikan (DAN): Konsep Transaction ke COA Addressing
  • Disampaikan (DAN): Draft Layar COA Template
  • Disampaikan (DAN): Draft Layar COA Template Addressing
  • Disepakati: Layar COA Template, COA Template Addressing
  • Disepakati: Pertemuan 21, 22 Des 2022 untuk membahas Cash Code
  • Outstanding: Policy tentang pembulatan (rounding)
  • Outstanding (IT): Sync Product Category, Product Type, dan Product Usage dari GMMS, Penyesuaian AP Invoice, AR Invoice, dan Receiving.
  • Outstanding (DARMA): Mapping transaction ke akun (Account Addressing), ditambah "Account Number", Master Amount, Cash Code (y/n)
21 Desember 2022
Rapat EPR Media (14.20 - 18.00)
  • Hadir: DAN, YON, RDY, WIK, Andika, Darma, Putri, Gilang, Prima, Aulia, Sahra, Riska
  • Disepakati: Modul budget di copy dari GMMS ke FINA, pengembangan selanjutnya masih menunggu kepusan berikutnya.
  • Disampaikan (IT): Usulan untuk menghasilkan report Cash Flow management menggunakan tabel khusus (Cash/Bank sub ledger) tanpa menerapkan CASH CODE di jurnal
  • Disampaikan (FSD): Konsep penerapan CASH CODE untuk menghasilkan report Cash Flow (management)
  • Disepakati: Terbuka cara selain menggunakan CASH CODE di COA untuk menghasilkan report Cash Flow (operational) yang diharapkan.
  • Outstanding: Metode untuk menghasilan report cash flow manajemen --> dipelajari oleh FSD
  • Outstanding: Policy tentang pembulatan (rounding)
  • Outstanding (IT): Sync Product Category, Product Type, dan Product Usage dari GMMS, Penyesuaian AP Invoice, AR Invoice, dan Receiving.
  • Outstanding (DARMA): Mapping transaction ke akun (Account Addressing), ditambah "Account Number", Master Amount, Cash Code (y/n)
3 Januari 2023
Rapat EPR Media (14.20 - 18.00)
  • Hadir: DAN, YON, RDY, WIK, Yettie, Andika, Darma, Putri, Gilang, Prima, Aulia, Sumani, Sahra, Riska
  • Disepakati: "Tanggal posting transaksi" dari sistem pengumpan (AR/ AP/..) menjadi "tanggal posting" di G/L Journal.
  • Disepakati: Periode yang sudah di tutup masih bisa dibuka lagi untuk jurnal baru pada periode tersebut. Dengan ini perlu dihindari penerapan "running balance" dalam kalkulasi2.
  • Disepakati: Planning sudah bisa dibuat, input model matrix (account x bulan), level Cost Center dan Profit Center, per tahun.
  • Disepakati: Metode C (tanpa CASH CODE) dipilih untuk menghasilkan report Cash Flow (operasional). Dengan keputusan ini:
    • Cash Flow Code di Jurnal (List, Detail,..) --> di hapus
    • Cash Flow Code COA (List, Detail,..) --> di hapus
  • Outstanding: Policy tentang pembulatan (rounding)
  • Outstanding (IT): Sync Product Category, Product Type, dan Product Usage dari GMMS, Penyesuaian AP Invoice, AR Invoice, dan Receiving.
  • Outstanding (DARMA): Mapping transaction ke akun (Account Addressing), ditambah "Account Number", Master Amount, Cash Code (y/n)
4 Januari 2023
Rapat EPR Media (14.20 - 18.00)
  • Hadir: DAN, YON, WIK, Yettie, Andika, Darma, Prima, Sumani
  • Disepakati: Variasi kolom di Balance Sheet:
    1. Current
    2. Last Year
  • Disepakati: Variasi kolom di Income Statement (contoh Feb 2022):
    1. Actual Current Period (Feb 2022)
    2. Year to Date (Jan 2022 - Feb 2022)
    3. Actual Last Period (February 2021)
    4. Year to Date Last Year (Jan 2021 - Feb 2021)
    5. Planned/ Budget (Feb 2022)
    6. Planned/ Budget Year to Date (Jan 2022 - Feb 2022)
    7. Variance Current Period (Planned - Actual Current Period)
    8. Variance YTD (Planned YTD - Actual YTD)
    9. Variance Last Period (Actual Period - Actual Last Period)
    10. Variance Last Period YTD (Actual YTD - Last Period YTD)
    11. Outlook (YTD Jan-Feb 2022, Planning Mar-Des 2022)
  • Disepakati: Variasi rangkaian report Report Sequence setiap "Company" berbeda-beda. Level variasi: Company level.
  • Disepakati: Angka-angka yang muncul di "Balance Sheet" adalah selisih Debit dan Credit, tergantung jenis accountnya. Angka2 tersebut ditambah dengan saldo awal tahun
    Saldo Awal Tahun Jan Debit Jan Credit Feb Debit Feb Credit NetChange Feb Saldo Akhir Feb ... Dec Debit Dec Credit
    Feb Debit - Feb Credit Saldo Awal Feb + NetChange Feb ...
  • Disepakati: Report Trial Balance tidak dihasilkan dari Layout spt Report Balance Sheet
    • Input Range Account yang akan ditampilkan
    • Range Date yang diinginkan (bukan period)
    • Tidak disediakan pilihan Before/ After Posting (G/L Posting/ Journal Posting), FINA hanya menyediakan AFTER posting
    • Pilihan Summary/ Detail, summary = account, detail = berikut transaksinya.
  • Disepakati: Untuk report income statement pengambilan data sampai ke level Cost Center
  • Disepakati: Selector untuk report-report:
    • Balance Sheet: Group - Legal Entity - Company - Business Area
    • Income Statement: Group - Legal Entity - Company - Business Area
    • Trial Balance: Group - Legal Entity - Company - Business Area - Profit Center - Cost Center
  • Outstanding: Policy tentang pembulatan (rounding)
  • Outstanding (IT): Sync Product Category, Product Type, dan Product Usage dari GMMS, Penyesuaian AP Invoice, AR Invoice, dan Receiving.
  • Outstanding (DARMA): Mapping transaction ke akun (Account Addressing), ditambah "Account Number", Master Amount, Cash Code (y/n)
10 Januari 2023
Rapat EPR Media (14.20 - 18.00)
  • Hadir: DAN, YON, RDY, WIK, Yettie, Andika, Darma, Putri, Gilang, Prima
  • Disepakati: Proses-proses mapping dari Transaction menuju ke Journal, meliputi:
    • COA Template
    • COA Template Addressing
    • Journal Staging
    • Journal
  • Outstanding: Policy tentang pembulatan (rounding)
  • Outstanding (IT): Sync Product Category, Product Type, dan Product Usage dari GMMS, Penyesuaian AP Invoice, AR Invoice, dan Receiving.
  • Outstanding (DARMA): Mapping transaction ke akun (Account Addressing), ditambah "Account Number", Master Amount, Cash Code (y/n)
17 Januari 2023
Rapat EPR Media (11.00 - )
  • Hadir: DAN, YON, WIK, Andika, Darma, Putri, Gilang, Prima
  • Disepakati: Tanggal untuk memilih periode yang digunakan dari COA Addressing ke Jurnal adalah tanggal posting transaction.
  • Disepakati: Tambah criteria: Memo, InstallmentType
  • Outstanding: Policy tentang pembulatan (rounding)
  • Outstanding (IT): Sync Product Category, Product Type, dan Product Usage dari GMMS, Penyesuaian AP Invoice, AR Invoice, dan Receiving.
  • Outstanding (DARMA): Mapping transaction ke akun (Account Addressing), ditambah "Account Number", Master Amount, Cash Code (y/n)
20 Januari 2023
Rapat Persiapan Implementasi EPR Media Tribun (13.30 - 14.38)
  • Hadir: Pak CIP, Sumani, Ninik, Ledya, Yuniati, Ryan, Darma, Yettie, Ramdhani, Daniel, Sisil
  • Disampaikan (Ramdhani, Sumani, Yettie): Skenario Implementasi, ada perubahan, akan menggunakan FINA G/L bukan G/L Windows
  • Diskusi:
    • Tentang konsolidasi report/ data dari multi company
    • Tentang laporan cash flow (detail dari Piutang dan Hutang) --> seperti G/L Windows
    • Tentang setting proses sudah disederhanakan terutama untuk unit kecil, misalnya tidak mengimplementasikan GMMS, bisa direct AP/ AR
    • Tentang migrasi data, tentang pengelolaan aset
    • Tentang timeline yang ketat apakah realistis
    • Timelione perlu ditambah kegiatan (evaluasi) yang melibatkan pengguna langsung untuk mengumpulkan masukan sebanyak mungkin
  • Disepakati: Area implementasi, skenario Implementasi, timeline tidak ada perubahan, hanya ditambah satu untuk evaluasi go/ no go
30 Januari 2023
Rapat Rutin EPR Media (13.30 - 14.38)
  • Hadir: DAN, YON, RDY, Yettie, Darma, Andika, Gilang, Putri, Sumani
  • Disampaikan (DAN)
    • COA Balance untuk digunakan saat migrasi
    • COA Planning untuk planning
  • Disepakati: COA Planning table ditambah Profit Center (PC), Cost Center (CC).
  • Disepakati: Penambahan Variabel untuk digunakan dalam COA Template Addressing
    • VATINCOA
    • VATOUTCOA
    • WHTINCOA
    • WHTOUTCOA
  • Disepakati: Penambahan field COA di TaxType (VAT) dan IncomeTaxType (WHT).
  • Diskusi: Pembulatan amount dalam transaksi, pending menunggu Mas Yono dan Prima
  • Disepakati: Tabel Journal SUM tidak perlu field Cash Flow ID
  • Outstanding: Policy tentang pembulatan (rounding)
  • Outstanding (IT): Sync Product Category, Product Type, dan Product Usage dari GMMS, Penyesuaian AP Invoice, AR Invoice, dan Receiving.
31 Januari 2023
Rapat Rutin EPR Media (10.00 - 19.00)
  • Hadir: DAN, YON, RDY, WIK, Yettie, Darma, Andika, Gilang, Putri, Sumani, Aulia
  • Disampaikan (DAN)
    • FINA tetap memelihara data bertipe decimal, 5 digit di belakang koma. Tingkat presisi yang bisa di capai: 2 digit. Tingkat presisi 2 digit ini harus bisa dipertahankan sampai laporan akhir.
    • Pembulatan rencananya akan dilakukan pada output akhir jika dibutuhkan (disediakan setting report)
  • Disepakati: Kode Organisasi tetap bersifat unik, akan ditambahkan kolom untuk pengelompokan report. Penambahan kolom dilakukan saat pengembangan report (tidak sekarang)
  • Disepakati: BS tidak perlu ditambah Business Area, business area tidak dibutuhkan untuk addressing account2 Neraca
  • Disepakati: Business Area (BA), Profit Center (PC), Cost Center (CC) perlu di disable di seluruh account2 Neraca
  • Diskusi: Pembulatan di Invoice, diinginkan NETTO level item bulat (tidak ada pecahan).
  • Diskusi: Faktur Pajak (pembatalan) untuk Balance Forward (Sirkulasi) --> I + CI, Sales
  • Diskusi: Reversed receipt --> masih belum diputuskan untuk reversed karena kesalahan alokasi invoice, karena CI tidak bisa dilakukan.
  • Outstanding: Pembulatan di Invoice (termasuk CI, PDD, dll), akan diinvestigasi (DARMA, YON, MUKHLIS)
  • Outstanding (IT): Sync Product Category, Product Type, dan Product Usage dari GMMS, Penyesuaian AP Invoice, AR Invoice, dan Receiving.
7 Feb 2023
Rapat Rutin EPR Media (10.00 - 19.00)
  • Hadir: DAN, YON, RDY, WIK, Yettie, Prima, Darma, Andika, Gilang, Putri, Aulia, Zahra, Riska
  • Disepakati: Transaksi penyertaan modal, sementara akan dicatat menggunakan AP/ AR sebelum modul Treasury diselesaikan.
  • Disepakati: Transaksi penyertaan modal akan dibedakan dari transaksi AP/ AR normal berdasarkan "Produk" atau "Product Usage".
  • Disepakati: Transaksi Mutasi AP untuk pengalihan hutang dari satu party ke party lain. Pengembangan akan dilakukan setelah G/L selesai. Sementara jika ada kebutuhan akan dijurnal manual/ menggunakan memo.
  • Outstanding: Pembulatan di Invoice (termasuk CI, PDD, dll), akan diinvestigasi (DARMA, YON, MUKHLIS)
  • Outstanding (IT): Sync Product Category, Product Type, dan Product Usage dari GMMS, Penyesuaian AP Invoice, AR Invoice, dan Receiving.
8 Feb 2023
Rapat "Balance" IT Media & FSD (14.00 - 20.00)
  • Hadir: DAN, YON, RDY, WIK, Yettie, Prima, Darma, Andika, Gilang, Putri
  • Disepakati: Bank Import proses di jurnal berdasarkan SUM per transaction type, DocumentType: Bank Import (doctype baru).
  • Disepakati: Cash Slip, di jurnal saat PROCESS dan CONFIRM, document type: slip. Proses ini akan dilakukan setelah COA Addressing selesai.
  • Disepakati: Transaksi cash reversed receipt yang sekarang dimasukkan melalui Cash Receipt (CR) akan mendapat voucher CP (Cash Payment)
  • Disepakati: Balance-In dan Balance-Out yang terjadi di Cashier dilaporkan menjadi "Dokumen RK Cash". Dokumen tersebut akan diposting ke GL melalui addressing. Nantinya, setelah modul treasury ada maka dokumen tersebut akan masuk menjadi "RK Sub Ledger".
    Disepakati ulang via WA Call (DAN-Yettie) Feb 10, 2023: Report tidak diposting melalui addressing, karena belum ada dukungan subledger. Sementara Subledger RK belum ada, jurnal dilakukan secara manual.
  • Outstanding: Pembahasan tentang saldo Deposit, sisa saldo BS karena mekanisme yang sekarang tidak mengakomodir keinginan keuangan.
  • Outstanding: Pembulatan di Invoice (termasuk CI, PDD, dll), akan diinvestigasi (DARMA, YON, MUKHLIS)
  • Outstanding (IT): Sync Product Category, Product Type, dan Product Usage dari GMMS, Penyesuaian AP Invoice, AR Invoice, dan Receiving.
14 Feb 2023
Rapat Implementasi FINA untuk FastKom (14.00 - 16.45)
  • Hadir: DAN, YON, RDY, WIK, Yettie, Prima, Andika, Pak Edi, Wahyu
  • Agenda:
    1. Implementasi FINA untuk penerimaan pembayaran (Receipt) FASTKOM
    2. Export Invoice dari FASTKOM ke SAP agar dapat dibedakan jenis revenue nya: pendapatan iklan, revenue, buku, dll.
  • Diskusi: Ada 2 skenario untuk agenda no.1:
    • Memindahkan jalur "Receipt" dari SAP ke FINA
    • Membangun jalur "Revenue" dari FASTKOM ke FINA dan memindahkan jalur "Receipt" dari SAP ke FINA
  • Disepakati: Untuk quick-win, tahap pertama hanya memindahkan jalur "Receipt" dari SAP ke FINA.
    • Nomor Invoice dan nilai yang dibayar tidak di lookup tapi diinput oleh kasir/ petugas
    • Info penerimaan pembayaran dikembalikan ke FASTKOM untuk mengupdate A/R FASTKOM
    • Info penerimaan pembayaran diposting ke SAP FICO mengikuti jalur yang sudah ada untuk SPSK
    • Usulan pembagian kerja: customer credit ditangani oleh Steven (inkaso), non-credit ditangani oleh Wahyu
    • Target 1 Maret 2023 receipt sudah dilakukan menggunakan FINA
  • Kegiatan agar 1 Maret 2023 receipt sudah pindah ke FINA:
    • Sosialisasi perubahan kepada Finance KG Media (inkaso - Steven) --> akan diundang oleh Accounting Kompas
    • Transisi: Tanggal terima pembayaran 1 Maret langsung dilakukan di FINA, penerimaan pembayaran sebelum 1 Maret (jan, feb) tetap dilakukan di collecting
    • Training: untuk operator
    • Persiapan Data: Daftar Bank (penerimaan), Customer, Employee (of operator, termasuk hirarki)
    • Pengembangan aplikasi: Modul di FASTKOM untuk menerima pembayaran dari FINA
    • Koordinator persiapan menuju 1 Maret 2023: Wahyu, Rudyanto, Andika
  • Diskusi: Agenda no.2, ada 2 skenario dan kendala
    • Invoice FASTKOM di split sampai ke tingkat component --> sesuai dengan struktur invoice-produk FASTKOM --> kendala: nilai per component
    • Invoice FASTKOM di split sampai ke tingkat produk (SO) --> syaratnya:
      • 1 Produk 1 Component
      • 1 Invoice 1 ComponentType
    • Untuk memutuskan perlu dicoba mulai cara membuat SO, mana yang paling bisa diterima. Skenario split sampai level product sudah dikerjakan oleh TI sudah di apply ke production. Mapping GL Account di Product sedang dikerjakan
  • Tambahan catatan 15 Feb 2023:

    Disepakati: Tidak ada penambahan criteria untuk COA Addressing, pengembangan modul G/L bisa dilanjutkan. Jika nantinya ditemukan kriteria baru maka akan ditambahkan setelah modul G/L diselesaikan (update/ upgrade system)
    (Sebelumnya, tanggal 13 Feb 2023 melalui WAG "IT Media & FSD" IT-Media memutuskan menutup penambahan kriteria baru karena isu tentang kriteria COA Addressing sudah terlalu lama terbuka. Hal ini terpaksa dilakukan agar pengembangan modul-modul terkait G/L bisa dilanjutkan)

21 Feb 2023
Rapat Rutin ERP Media (14.30 - )
  • Hadir: DAN, YON, RDY, WIK, Yettie, Prima, Darma, Andika, Gilang, Sumani, Putri, Aulia, Zahra, Rizka
  • Disepakati: Seluruh nilai (amount) Debit ditampilkan positif, Credit ditampilkan negatif
  • Disampaikan (Yettie): Hasil rapat persiapan implementasi Tribun antara FSD dengan SysDev Tribun
    • Sosialisasi dan Training difokuskan untuk kegiatan implementasi Maret 2023 sehingga user yang (akan) diundang hanya dari 6 company yang go-live Maret.
    • User-user dari Company lain yang diusulkan untuk memberi masukan akan diberikan slot waktu yang berbeda.
  • Disampaikan (DAN): Saat ini hanya ada 2 environment server: DEVELOPMENT dan PRODUCTION. Dan tidak ada mekanisme "staging" dalam framework pengembangan. Konfigurasi (master, data awal) di server DEV harus diulang di server PRODUCTION.
  • Disepakati: Penggunaan server DEVELOPMENT untuk development dan training (sosialisasi). Data di development akan disesuaikan semirip mungkin dengan kebutuhan implementasi.
  • Diskusi: Tentang pengelolaan hak akses
  • Disepakati: Penambahan report (cetakan)
    • AP Invoice Rekap
    • Bank Payment Voucher/ Cash Payment Voucher
    Spesifikasi report: Darma, Gilang (22 Feb 2023)
  • Disepakati: Pertemuan 22 Feb 2023 untuk membahas voucher.
  • Outstanding: Pembahasan tentang saldo Deposit, sisa saldo BS karena mekanisme yang sekarang tidak mengakomodir keinginan keuangan.
  • Outstanding: Pembulatan di Invoice (termasuk CI, PDD, dll), akan diinvestigasi (DARMA, YON, MUKHLIS)
  • Outstanding (IT): Sync Product Category, Product Type, dan Product Usage dari GMMS, Penyesuaian AP Invoice, AR Invoice, dan Receiving.
22 Feb 2023
Rapat Rutin EPR Media (09.00 - 14.00)
  • Hadir: DAN, YON, RDY, WIK, Yettie, Darma, Andika, Gilang, Putri
  • Disepakati: BPV, CPV (Payment Voucher) tidak mencantumkan skenario jurnal. Reason: Journal baru diproses saat posting ke G/L dan langsung masuk ke staging.
  • Disepakati: BPV, CPV (Payment Voucher) dibuat per Pesanan Dana (PD, Payment Requisition). Jadi 1 BPV = 1 PD, 1 CPV = 1 PD.
  • Disepakati: Posting ke G/L akan di lakukan dari BPV/ CPV bukan dari BPM/ CP
  • Disepakati: Journal Sum Cash Flow tidak butuh PC dan CC
  • Outstanding: Pembulatan di Invoice (termasuk CI, PDD, dll), akan diinvestigasi (DARMA, YON, MUKHLIS)
  • Outstanding (IT): Sync Product Category, Product Type, dan Product Usage dari GMMS, Penyesuaian AP Invoice, AR Invoice, dan Receiving.
22 Feb 2023
Rapat Implementasi FINA untuk FastKom (14.00 - 17.00)
  • Hadir: DAN, YON, RDY, Yettie, Darma, Andika, Prima, Edi, Ari, Wahyu, Steven, Dedi, Syeni, Ledya
  • Disampaikan (Yettie): Histori aliran data dari FastKom ke keuangan (SAP), 2 Proposal aliran data dari FastKom ke FINA
  • Disampaikan (Yettie): Skenario aliran data dari FastKom ke FINA, SAP, Collecting yang bisa diimplementasikan mulai 1 Maret 2023
    • Invoice FastKom tidak dikirimkan ke FINA, tetap dikirimkan ke SAP seperti sekarang
    • Pembayaran diterima di FINA melalui modul Bank dan Cash
    • Pembayaran yang diterima dari FINA dipasangkan Invoice di A/R FastKom
    • Pembayaran yang diterima oleh FINA akan diposting ke SAP seperti yang sudah berjalan di sirkulasi (SPSK)
  • Diskusi: Penerimaan pembayaran dengan BG/ CQ
  • Disepakati: BG/ CQ yang diterima diinput di FINA
  • Disepakati: Akan dibuatkan Cash Counter khusus Collection (Fin KG Media).
  • Disepakati: Akan dibuatkan Cash Counter khusus Kompas (Wahyu)
  • Disepakati: Yang ditagih oleh Collecting akan diinput di 3 tempat: di Collecting, FINA, dan SAP
  • Disepakati: Yang ditagih oleh Kompas akan hanya di input di FINA, kemudian diupload ke SAP menggunakan fasilitas upload yang baru
  • Disampaikan: Perlu dibuat upload receipt ke SAP yang bisa memuat informasi Invoice. Waktu untuk membuat report tersebut tidak mempengaruhi rencana 1 Maret 2023
  • Disepakati: Jumat 24 Feb 2023 akan diadakan pertemuan perkenalan FINA di r.rapat Project Lt.4 Unit 2
3 Mar 2023
Training User Kompas (10.00 - 17.00)
  • Hadir:
  • (Notulen belum ada)
7 Mar 2023
Rapat Rutin ERP (10.00 - 17.00)
  • Hadir: DAN, YON, RDY, WIK, Yettie, Prima, Darma, Andika, Gilang, Putri
  • Diskusi: Penerimaan pembayaran di depan. Konteks: Rencana implementasi di Kompas
    1. Penerimaan digantung sebagai penerimaan yang belum teralokasi
    2. Dicatat sebagai DP (Invoice DP) --> tidak bisa diimplementasikan karena rencana terdekat FastKom belum mengirimkan invoice ke FINA
    3. Dicatat Deposit --> proses belum lengkap
  • Diskusi: Proses-proses Deposit (A.K.A TTT)
    • Harus diterima bersama transaksi alokasi di kas dan di bank. Tidak boleh diterima sebagai deposit sendirian (alone)
    • Deposit BUKAN alat bayar, sehingga dapat digunakan sebagai pengurang nilai transaksi (implementasi spt diskon).
    • Jika Deposit (TTT) ingin dicairkan menjadi alat bayar, maka harus dibuat PD untuk pencairan dana depositnya.
    • Pencairan Deposit (TTT) tidak boleh ke bank, hanya boleh ke Kas atau menjadi Memo A/R setara dengan pembayaran.
  • Disepakati: Tentang laporan keuangan
    • Akan dibuat "Spec" untuk menyimpan atribut-atribut kolom yang akan ditampilkan dalam report, pembulatan angka, dll.
    • Setiap "Spec" merujuk ke "jenis report" (Report Type) dan "Layout" tertentu.
  • Disepakati (ulang): kolom-kolom yang bisa dipilih dari "Spec"
    1. Current Period (Period)
    2. Current Period YTD (PeriodYTD)
    3. Current Planning (Planning)
    4. Variance Planning (PlanningDelta)
    5. Variance Planning Ratio (PlanningRatio)
    6. Current Planning YTD (PlanningYTD)
    7. Variance Planning YTD (PlanningYTDDelta)
    8. Variance Planning YTD Ratio (PlanningYTDRatio)
    9. Last Year Period (LastYear)
    10. Variance Last Year (LastYearDelta)
    11. Variance Last Year Ratio (LastYearRatio)
    12. Last Year Period YTD (LastYearYTD)
    13. Variance Last Year YTD (LastYearYTDDelta)
    14. Variance Last Year YTD Ratio (LastYearYTDRatio)
    15. Outlook
  • Disepakati: Akan dibuat Installment Type Deposit, untuk selanjutnya dibuat menjadi Pesanan Dana (PD) dan dieksekusi pembayarannya secara normal.
  • Disepakati: Ditambahkan field "Auto Credit Code" di Bank Account untuk menyimpan kode auto credit dari bank.
  • Disampaikan: Perlu disusun skenario "Clearing" untuk transaksi "Bank Transfer", setoran kasir ke bank, dll.
14 Mar 2023
Tidak ada Rapat Rutin
  • Event: Training hari ke-1 untuk calon user Tribun by FSD dan SysDev di Tribun
  • Disampaikan (DAN via WA Chat): Disampaikan ke Yettie, tentang penyelesaian deposit di FINA
    • Deposit --> Deposit A/R Allocation --> Memo A/R (done)
    • Deposit --> Deposit Refund --> Deposit Installment --> Payment Requisition (PD) --> Payment Process (done)
  • Disepakati: COA Planning menggunakan notasi plus (+) untuk menyatakan Debit dan notasi minus (-) untuk menyatakan Credit. Account di "planning" secara debit atau credit tergantung COA Category nya.
15 Mar 2023
Emang bukan jadwal Rapat Rutin
  • Event: Training hari ke-2 untuk calon user Tribun by FSD dan SysDev di Tribun
  • Disampaikan (Yettie via WA Call): Tentang penggunaan angka2 Trial Balance di laporan2 keuangan, menjawab pertanyaan DAN.
    • Laporan Posisi Keuangan (Neraca/ Balance Sheet) mengambil angka "Balance" dari Trial Balance
    • Laporan Laba Rugi (Income Statement) mengambil angka "NetChange" dan "YTD" dari Trial Balance
    • Laporan Arus Kas (Cash Flow) mengambil angka "NetChange" dan "YTD" dari Trial Balance
  • Disepakati: Ditambahkan field "Increased By" di master Cash Flow.
  • Disepakati: Cash Flow Planning menggunakan notasi plus (+) untuk menyatakan Debit dan notasi minus (-) untuk menyatakan Credit. Cash Flow di "planning" secara debit atau credit sesuai jenisnya: Pendapatan, Biaya, dll.
21 Mar 2023
Rapat Rutin ERP (14.00 - 19.00)
  • Hadir: DAN, YON, RDY, WIK, Yettie, Prima, Darma, Andika, Gilang, Putri, Aulia, Zahra, Riska, Ryan
  • Disampaikan (Darma, Andika): Catatan training Tribun 14-17 Mar 2023
  • Diskusi: Tentang pre payment supaya penyelesaian tidak perlu menunggu PD BS baru dibayar
    • Saat ini hanya BS yang sudah dibayar saja yang bisa dilekatkan ke AP Invoice. Kontrol ini memang diperlukan.
    • Dalam hak ini BS otomatis tidak dapat menolong karena pelekatan BS ke AP Invoice harus menunggu pembayaran.
    • FSD akan memikirkan agar kontrol tetap ada namun proses kerja bisa dipercepat.
  • Diskusi: Transaksi "clearing" pembayaran secara manual. Diskusi tidak sekesai, belum ada keputusan.
    • Menambahkan "jenis transaksi baru" untuk dialokasi dengan layar Bank Statement yang sekarang berpotensi membongkar modul bank secara besar-besaran.
    • Layar alokasi di Bank Statement yang sekarang dibangun untuk alokasi menuju ke A/R (belum ada kesepakatan baru saat pengembangan AP - Maret 2022)
    • Perubahan terlalu riskan karena modul sudah digunakan dan ada beban implementasi dalam waktu dekat.
  • Diskusi: Tentang pemindahan saldo (KM) khususnya antar Bank
  • Disepakati: Modul pemindahan saldo (mutasi/ RK) akan dibuat
    • Akan dibuat jenis installment baru "Balance Mutation Installment"
    • Akan dibuat layar baru untuk melakukan pemindahan saldo
    • Satu sumber dana (rekening bank/ fund) bisa dipindahkan ke beberapa rekening bank (One-to-Many)
    • Saat "Pemindahan Saldo" di posting, secara otomatis akan menciptakan installment bertipe "Balance Mutation" dan juga PD dalam status "Approved" (untuk bypass proses approve PD)
    • Proses "clearing" di sisi pengirim dan penerima perlu dilakukan, termasuk auto-credit nya. Proses "clearing" belum selesai dibahas.
    • Pengembangan akan dilakukan setelah seluruh beban pengembangan yang sudah disepakati selesai (termasuk G/L), paling cepat bulan April jika tidak tertunda cuti2 Paskah, Lebaran.
  • Disampaikan (Rudyanto): Sample file (spesifikasi) autocredit dan MT940 yang diserahkan oleh FSD tidak sesuai dengan format yang sekarang berlaku sekarang sehingga modul pembayaran bank dan auto credit FINA bermasalah. Sample-sample juga sangat terlambat diterima oleh TI Media.
  • Disampaikan (Daniel): Beberapa bug dan tambahan yang ditemukan/ diminta saat training sudah diselesaikan
    • Seharusnya update yang dilakukan TI segera diperiksa
    • Catatan bugs atau penambahan fitur yang disusun oleh FSD perlu diperbarui sebagai bentuk tanggungjawab atas laporan/ permintaan perubahan. Feedback (FSD) perlu lebih cepat (sample, data, skenario, keputusan).
    • Persiapan data untuk implementasi belum diselesaikan. TI Media mempertanyakan kapan data difinalisasi: COA, terkait pajak, user, hierarchy, dll.
    • Terkait "kesalahan data" setelah implementasi, TI Media bersedia membantu jika data lebih banyak dari line of code yang harus dibuat, namun TI tidak bersedia bertanggungjawab atas perintah "main kayu" pada data. Tanggung jawab tetap melekat pada pemilik data bukan pihak yang membantu.
    • Paskah, Puasa, Lebaran, akan membuat bulan April menjadi kurang (tidak) efektif
  • Disampaikan (Daniel): Demo tambahan 2 proses penyelesaian Deposit: Allocate dan Refund yang sudah diselesaikan, menunggu di test.
  • Outstanding: Data-data untuk implementasi
  • Outstanding: Skenario Clearing pembayaran manual
  • Outstanding: Test update modul Deposit, Voucher (v3)
29 Mar 2023
Rapat Mendadak TI - FSD WA Call, Chat, Zoom (18.00 - 19.40)
  • Hadir: DAN, Yettie, Prima, Darma
  • Disampaikan (Yettie): FSD tidak hadir dalam pertemuan rutin hari Selasa 28 Maret 2023 karena banyak pekerjaan
    • Training sehubungan dengan go-live HR Corp.
    • Persiapan data untuk go-live FastKom Kompas - FINA
  • Diskusi: Tentang persiapan go-live Tribun
    • TI Media menanyakan status persiapan setelah training dilakukan. Tidak ada modul yang belum diselesaikan kecuali G/L dan Modul Pemindahan Saldo antar Bank yang baru disepakati 21 Maret 2023.
    • TI Media menilai data dan konfigurasi untuk go-live belum dipersiapkan (COA, CashFlow, PPh, master-master lainnya).
    • FSD sedang mencari cara agar penyelesaian BS tidak harus menunggu pembayaran tanpa mengorbankan sisi kontrol.
    • Disampaikan oleh FSD (Yettie) Tribun (Mbak Sumani) sedang menyusun masukan-masukan yang disampaikan selama dan setelah training. Akan segera disampaikan.
    • FSD (Yettie) belum sempat memeriksa modul G/L yang sudah selesai (all minus Financial Statement)
  • Disampaikan/ Demo (DAN): Status pengembangan dan update aplikasi
    • Deposit Allocation (done)
    • Deposit Refund (done)
    • Upload CSV Bank Statement, Paste Area CSV untuk BCA, Mandiri, BRI (done)
    • Penambahan Report Spec (done)
    • Penambahan atribut-atribut data: COACategory.[HasPlanning], CashFlow.[HasPlanning], CashFlow.[IncreasedBy] (done)
    • Modul G/L yang seharusnya sudah selesai 18 Maret 2023 masih dikerjakan karena terpotong pengembangan poin2 di atas. Test dan spesifikasi belum lengkap disampaikan
  • Outstanding: Data-data untuk implementasi
  • Outstanding: Skenario Clearing pembayaran manual
  • Outstanding: Test update modul Deposit, Voucher (v3)
11 April 2023
Rapat Rutin ERP Media (14.30 - 16.00)
  • Hadir: DAN, YON, RDY, WIK, Yettie, Prima, Darma, Andika, Putri, Gilang, Sumani, Aulia, Riska, Zahra, Hamzah, Ryan.
  • Disepakati: BS yang sudah di approve tapi belum dibayar sudah bisa dilekatkan ke AP Invoice. Ini hanya solusi sementara, sebelum skenario yang lebih baik disepakati.
  • Diskusi: Migrasi saldo piutang ke FINA
    • Disampaikan ulang (DAN): Skenario migrasi saldo piutang (A/R) ke FINA harus melalui transaksi (invoice). Tidak dimungkinkan memasukkan saldo nya saja karena informasi-informasi yang menyertai saldo tersebut tidak bisa di bypass.
    • Disampaikan (Sumani): Tribun keberatan jika saldo piutang harus diinput secara manual karena banyak pekerjaan.
    • Disampaikan (Sumani): Jumlah data saldo piutang yang harus di entry masih dalam proses oleh audit (belum ada per 13 April 2023).
    • Disampaikan ulang (DAN): TI media hanya bersedia membantu jika data cukup massive melebihi line of code yang harus dibuat, baik itu berupa modul migrasi maupun modul screen robot (tuyul). Lihat catatan: 21 Maret 2023.
    • Diusulkan: Saldo piutang dibuat invoice di CAS kemudian di sync ke FINA melalui jalur API yang sudah tersedia.
    • Disampaikan (Sysdev): Invoice migrasi berpotensi mengganggu report analisa sales (??)
    • Disampaikan (DAN): Jika terpaksa harus diimport maka lebih baik masuk dari sisi CAS karena:
      • Modul import adalah bagian dari support, bukan bagian dari pengembangan, support data Tribun sebaiknya dilakukan oleh Tribun.
      • Setiap saldo piutang harus berelasi dengan Customer yang harus sudah ada di CAS (untuk ID to ID relationship)
      • Spesifikasi data, tanggung jawab data harus tetap di Tribun kecuali yang sudah masuk dan dikelola FINA. Dalam kasus import data belum masuk ke FINA tapi sudah berpotensi mem=bypass rule-rule yang ada di FINA (siapa akan bertanggungjawab?)
  • Disepakati: Skenario migrasi saldo piutang A/R
    • Saldo piutang masuk sebagai A/R Invoice di FINA
    • Saldo piutang akan masuk melalui jalur API yang sudah disediakan oleh FINA.
    • Sysdev akan membuat modul kecil atau memanfaatkan modul-modul CAS untuk membaca data Excel ke data yang siap dikirimkan ke API.
  • Outstanding: Data-data untuk implementasi
  • Outstanding: Skenario Clearing pembayaran manual
  • Outstanding: Test update modul Deposit, Voucher (v3)
12 April 2023
Rapat Khusus G/L Reporting (15.10 - 19.40)
  • Hadir: DAN, WIK, Yettie, Prima, Darma, Andika, Putri, Gilang.
  • Disampaikan (DAN):
    • Penjelasan tentang konsep 12column layouting system, perintah-perintah layout: COL_*, ROW_*
    • Penjelasan tentang Kolom-Kolom data, bagaimana mengatur judul masing-masing kolom
    • Penjelasan tentang data teks: TEXT_*, UL_*, DL_*
    • Penjelasan tentang data retrieval: RANGE, ACCOUNT, SUM_*, BREAK_*, CALC_*
  • Disepakati: Kebutuhan dan standar laporan keuangan
    • Pembatasan organisasi (Legal Entity, Company, Business Area, Profit Center, Cost Center) saat data retrieval: RANGE dan ACCOUNT
    • SUM perlu 10 level dari SUM_1, SUM_2 sampai SUM_10.
    • Kolom SUM bisa cascade (10 level), bisa merge menjadi 1 kolom
    • Bug "Text Padding" tidak berfungsi saat render akan diperbaiki
    • Kolom ratio antar SUM_* data, tidak akan tersedia dalam jangka pendek, akan diusahakan dalam pengembangan lanjutan.
  • Outstanding: Data-data untuk implementasi
  • Outstanding: Skenario Clearing pembayaran manual
  • Outstanding: Test update modul Deposit, Voucher (v3)
2 Mei 2023
Rapat Rutin ERP (10.40 - 16.45)
  • Hadir: DAN, Rohimam, Nuel, Novi, Yettie, Prima, Putri, Gilang, Vincent
  • Disampaikan (Yettie):
    • Jurnal closing
    • Proses Tahunan
  • Outstanding: Data-data untuk implementasi
  • Outstanding: Skenario Clearing pembayaran manual
  • Outstanding: Test update modul Deposit, Voucher (v3)
3, 4 Mei 2023
Rapat Rutin ERP (10.40 - 16.45)
  • Hadir: DAN, YON, Yettie, Prima, Putri, Gilang
  • Disampaikan (Yettie), Diskusi:
    • Penjelasan proses dan jurnal closing tahunan
    • Kolom-kolom dan layar closing tahunan di SAP
    • Kolom-kolom data di Trial Balance GL Windows
    • Ekspektasi: Angka akun-akun Rugi/ Laba tidak di reset menjadi 0 saat closing tahunan dilakukan
    • Ekspektasi: Closing Tahunan dapat diulang-ulang untuk menghasilkan laporan Neraca dengan angka Retained Earning sementara
    • Angka kalkulasi RATIO... RATIO_END belum sesuai ekspektasi, cara kalkulasi berbeda dengan yang sudah dibuat di FINA. Diskusi tidak dilanjutkan karena bukan topik pertemuan (Closing Tahunan)
  • Disampaikan (DAN):
    • Perintah-perintah baru di Report Layout: LEGEND, NOTE, TEXT_TITLE, dll.
    • Penggunaan: RATIO dan RATIO_END
  • Disepakati:
    • Kolom-kolom dalam Trial Balance COA sudah benar, organisasi: Company, Business Area, Profit Center, Cost Center
    • Kolom-kolom dalam Trial Balance Cash Flow sudah benar, organisasi: Company, Business Area.
  • Outstanding: Data-data untuk implementasi
  • Outstanding: Skenario Clearing pembayaran manual
  • Outstanding: Test update modul Deposit, Voucher (v3)
4 Mei 2023
Rapat Evaluasi Implementasi FINA Kompas (13.15 - 14.30)
  • Hadir: Novi, Atok, DAN, YON, RDY, Edi, Wahyu, Yettie, Prima, Gilang, Darma
  • Disampaikan (Wahyu):
    • Sudah berjalan sejak tanggal 2 Mei 2023
    • Ada beberapa rekening bank yang digunakan bersama oleh Iklan dan Sirkulasi
    • Pertanyaan: Ada pembayaran kartu kredit dari unit lain (non Kompas), bagaimana refund?
  • Disampaikan (Pak Edi):
    • Perlu dievaluasi penggunaan rekening2 bank yang digunakan bersama (BRI dan Mandiri)
    • Kemungkinan akan dibuka rekening bank baru untuk transaksi non Sirkulasi (Iklan)
    • Ada rekening Bank (yang digunakan untuk EDC) Kompas dimanfaatkan oleh unit lain (Konnan, dll). Menjadi beban Wahyu yang saat ini juga menjalankan fungsi kasir.
  • Disampaikan (Yettie):
    • Tentang fungsi kasir dan bank sehubungan implementasi FINA perlu ditata ulang.
    • Sudah disampaikan ke Mbak Ninik, masih harus menunggu keputusan Pak Gatot
  • Disepakati:
    • Untuk rekening2 bank yang digunakan bersama (BRI dan Mandiri) akan disepakati salah satu dari Iklan atau Sirkulasi saja yang melakukan upload.
    • Pengembangan aplikasi selanjutnya setelah implementasi FINA kasir di Iklan: otomatisasi status bayar ke FastKom, integrasi AR.
    • Proyek solusi jangka pendek untuk iklan dianggap selesai, support/ dukungan selanjutnya masuk ke ranah operasional.
11 Mei 2023
Rapat Rutin ERP (14.00 -)
  • Hadir: DAN, YON, RDY, Yettie, Prima, Andika, Darma, Putri, Rohimam
  • Diskusi tentang Retained Earning:
    Lap.Posisi Keuangan Mei 2023
    Kas5.000Hutang3.500
    L/R Tahun2 Lalu1.000
    L/R Tahun ini500
  • L/R Tahun2 Lalu:
    • Trial Balance COA sampai Mei 2023, ditambah (+)
    • Trial Balance Closing sampai Desember 2022
  • L/R Tahun Ini:
    • Trial Balance COA (akun Pendapatan - Biaya) Januari 2023 - Mei 2023 (YTD), atau
    • Trial Balance Closing (akun RE) Januari 2023 - Mei 2023 (YTD)
  • Sedang dipertimbangkan untuk efisiensi proses, dibuat perintah RANGE khusus kalkukasi Retained Earning (RE), misalnya RE_PAST dan RE_CURRENT
    • Untuk menghidari penambahan option di perintah RANGE yang sudah ada
    • Supaya tidak terjadi kalkulasi besar2an pada akun-akun L/R sedangkan angka2 yang dibutuhkan sudah tersimpan di Trial Balance Closing
  • Diputuskan: Tentang implementasi FINA di Iklan Kompas
    • Transaksi dengan kartu kredit akan didorong menjadi penerimaan pembayaran bank, tidak ditunggu sampai cair di bank dan diperlakukan sebagai penerimaan pembayaran bank.
    • Bank Statement untuk transaksi kartu kredit tidak perlu di alokasi.
    • Refund deposit customer diselesaikan sampai SAVE saja, metode pembayaran diarahkan menggunakan CASH. Proses dilanjutkan di SAP untuk payment-nya.
  • Outstanding:
    • Data-data untuk implementasi
    • Skenario Clearing pembayaran manual
    • Test update modul Deposit, Voucher (v3)
    • Contoh laporan Cash Flow, test layout Cash Flow (Darma)
    • Template posting Receipt dengan invoice ke SAP (Darma)
24 Mei 2023
Rapat Rencana Implementasi di Tribun (14.00 - 15.30)
  • Zoom Meeting, hadir: Pak Cip, Pak Dahlan, DAN, RAM, Yettie, Andika, Darma, Ledya, ...
  • Disampaikan (Yettie, Sumani, RAM):
    • Status persiapan implementasi
    • Status kesiapan sistem (FINA): Mutasi antar Bank belum ada, GL belum teruji.
    • Siap jalan Juni 2023
  • Disampaikan (Pak Cip):
    • Implementasi lebih baik ditunda sampai Juli 2023 setelah semua modul FINA selesai dan diuji
    • Ingin pengguna sudah bisa mengenal dulu FINA, bisa menguji dari awal sampai akhir.
  • Disepakati: Go live mulai bulan Juli 2023.
Rapat Lanjutan FSD + IT Media (15.30 - 18.30)
  • Hadir: DAN, WIK, Rohimam, Yettie, Andika, Darma, Gilang
  • Disampaikan (DAN): Balance Sheet, Income Statment sudah bisa dikeluarkan menggunakan kalkulasi Retained Earning yang baru.
  • Disampaikan (Andika, Gilang): Berdasarkan data-data yang di "paste" ke dalam sistem (Tribun Lombok, Des 2022, Jan 2023) sudah menghasilkan angka Laba/ Rugi dan Balance Sheet yang benar.
  • Diskusi: Layout dan angka-angka di dalam laporan Cash Flow
    • Disampaikan (DAN): Angka-angka yang muncul di kolom-kolom data yang sudah dikirimkan tanggal 16 Mei 2023.
    • Disampaikan (Yettie): perlu angka-angka "Last Month" untuk menyusun laporan Cash Flow
    • Disampaikan (Yettie): Laporan Cash Flow tidak hanya mengambil data dari Trial Balance Cash Flow, tapi perlu mengambil data dari Trial Balance COA juga
    • Men-diversifikasi perintah RANGE dan ACCOUNT menjadi RANGE, ACCOUNT, CF_RANGE, CF_ACCOUNT untuk keperluan layout laporan Cash Flow
    • Membahas dan merevisi tabel kolom-kolom data
    • Disampaikan (Yettie): Masih ada 2 laporan lagi yang harus dikeluarkan menggunakan report render: Laporan Perubahan Modal, Laporan Perubahan Posisi Keuangan
    • Disampaikan (DAN): Data "Last Month" yang dibutuhkan akan merombak modul reporting secara masive karena kolom tersebut selama ini tidak di maintain
    • Jika kolom "Last Month" terpaksa dikeluarkan untuk kepentingan report Cash Flow, maka lebih baik sekaligus ditambahkan ke kolom-kolom data yang bisa dipilih untuk dimunculkan (Report Spec). Meliputi: LastMonth, LastMonthDelta, LastMonthRatio, LastMonthYTD, LastMonthYTDDelta, LastMonthYTDRatio, LastMonthPlanning??
  • Disepakati
    • Tentang pembatasan jumlah item di Jurnal (max 50 item) tetap diberlakukan. TI akan memeriksa jumlah item dan menampilkan kesalahan jika jumlah item melampaui 50 (langsung di eksekusi).
    • Tabel spesifikasi angka-angka yang muncul dalam kolom2 data laporan keuangan akan diperiksa lagi oleh Yettie, excel terbaru sudah dikirimkan via WA Chat.
    • Penambahan perintah CF_RANGE dan CF_Account dan juga update perintah RANGE dan ACCOUNT existing akan dilakukan setelah seluruh kebutuhan data teridentifikasi dengan menyusun layout Laporan Perubahan Modal dan Laporan Perubahan Posisi Keuangan.
    • Layout Laporan Perubahan Modal dan Laporan Perubahan Posisi Keuangan akan disusun oleh Yettie dan Wiwik hari Kamis 25 Mei 2023 atau paling lambat Jumat 26 Mei 2023.
  • Outstanding:
    • Data-data untuk implementasi
    • Skenario Clearing pembayaran manual
    • Test update modul Deposit, Voucher (v3)
    • Contoh laporan Cash Flow, test layout Cash Flow (Darma)
    • Template posting Receipt dengan invoice ke SAP (Darma)
    • Contoh dan test laporan Perubahan modal, laporan perubahan posisi keuangan (Yettie, WIK)
    • Verifikasi angka-angka yang muncul dalam kolom2 data laporan keuangan akan diperiksa lagi oleh Yettie
26 Mei 2023
Test Financial Reporting (15.30 - 18.30)
  • Hadir: DAN, Rohimam, Yettie, Andika, Darma, Gilang
  • Disampaikan (Yettie): Dari data ujicoba yang diinput ke sistem sudah menghasilkan laporan keuangan dengan angka-angka yang benar:
    • Laporan Posisi Keuangan (Balance Type)
    • Laporan Laba/ Rugi (Period Type)
    • Laporan Perubahan Modal (Balance Type)
    • Laporan Perubahan Posisi Keuangan (Period Type)
  • Disampaikan (Yettie): Laporan outlook (dalam pivot 1 tahun)
  • Disepakati: Tentang laporan Outlook dalam format pivot 1 tahun:
    • Karena baru ditunjukkan, TI tidak bisa mengantisipasi kolom2 yang dibutuhkan dalam laporan Outlook pivot
    • Report Outlook akan masuk dalam report yang "custom" layout
    • FSD akan mengirimkan contoh laporan lengkap dengan kolom2nya.
  • Disampaikan (Yettie): Laporan cash flow belum bisa dihasilkan karena membutuhkan data "Last Month" yang saat ini belum tersedia (belum pernah di request juga)
  • Disepakati:
    • Update tag ACCOUNT dan RANGE supaya tetap mengambil angka dari Trial Balance COA meskipun dieksekusi dari laporan Cash Flow.
    • New tag CF_ACCOUNT dan CF_RANGE untuk mengambil angka-angka dari Trial Balance Cash Flow
    • Tambahan kolom-kolom "Last Month": LastMonth, LastMonthDelta, LastMonthRatio, LastMonthYTD, LastMonthYTDDelta, LastMonthYTDRatio.
    • Nilai-nilai kolom-kolom data akan diperiksa oleh Yettie
  • Outstanding:
    • Data-data untuk implementasi
    • Skenario Clearing pembayaran manual
    • Test update modul Deposit, Voucher (v3)
    • Contoh laporan Cash Flow, test layout Cash Flow (Darma)
    • Contoh laporan Outlook format pivot 1 tahun (Darma) --> sudah dikirimkan oleh Andhika 31 Mei 2023 via WAG "IT Media - FSD"
    • Template posting Receipt dengan invoice ke SAP (Darma)
    • Contoh dan test laporan Perubahan modal, laporan perubahan posisi keuangan (Yettie, WIK)
    • Verifikasi angka-angka yang muncul dalam kolom2 data laporan keuangan akan diperiksa lagi oleh Yettie
31 Mei 2023
Rapat Evaluasi Implementasi Integrasi FINA dengan FastKom (15.00 - 16.15)
  • Hadir: Novi Eastiyanto, Wahyu, Yettie, Andhika, Darma, Gilang, DAN, YON, RDY, WIK
  • Disampaikan (Wahyu):
    • Informasi penerimaan pembayaran dari FINA sudah mengalir ke FastKom
    • Menunggu keputusan kapan Invoice FastKom dialirkan ke FINA supaya fitur "Lookup" invoice bisa digunakan.
    • Deposit BGCQ tanpa invoice belum bisa dijalankan.
  • Disampaikan (Yettie): Ada selisih antara laporan edit list pembayaran di FastKom dengan laporan Receipt yang dikirimkan oleh FINA.
    (as per 31 Mei 2023 17.00, penyebab selisih antar laporan sudah dapat dijelaskan, karena tarikan data dari sisi FastKom tidak lengkap)
  • Diskusi: Deposit BGCQ seharusnya bisa dilakukan karena fasilitas sudah digunakan oleh SPSK.
  • Diskusi: Peluang2 terjadinya selisih
    • Salah input nomor invoice
    • Salah input nilai invoice
    • Saat perubahan URL FastKom dari http ke https server lupa dihidupkan
  • Disampaikan (Yettie): Prima (FSD) lupa mengirimkan template upload untuk integrasi FINA dengan SAP sehingga per 31 Mei 2023 integrasi SAP - FINA untuk invoice open-item belum tersedia.
  • Disepakati:
    • Invoice FastKom akan dialirkan ke FINA mulai Juni 2023 (tidak menunggu tanggal 1)
    • Invoice yang dialirkan ke FINA adalah semua Invoice outstanding di FASTKOM.
    • Produk-produk FastKom akan di map ke produk FINA: Migrasi Iklan
    • Sales FastKom akan di map ke sales FINA: Iklan Kompas
    • Billing/ Invoice baru FastKom juga dialirkan ke produk: Migrasi Iklan, sales: Iklan Kompas.
    • Data dari FastKom akan dialirkan sampai ke G/L. TI akan membantu menghapus data A/R balance dan G/L jika suatu saat perlu dibersihkan.
    • Selisih angka kiriman FINA dengan penerimaan FastKom harus dicari dulu karena diperlukan untuk memisahkan antara invoice yang outstanding dan invoice yang sudah selesai.
      (as per 31 Mei 2023 17.00, penyebab selisih antar laporan sudah dapat dijelaskan, karena tarikan data dari sisi FastKom tidak lengkap)
    • Mulai 2 Juni 2023, TI Media (Rudyanto) dan FSD akan meng-konfigurasi master-master data di FINA live server
  • Disampaikan (Yettie): Fungsi kasir setelah KGMedia menggunakan FINA akan diputuskan bulan Agustus 2023. Bp. Gatot sedang melakukan restrukturisasi. Sementara menunggu hasilnya, Wahyu dan tim menjalankan fungsi kasir.
  • Disepakati: Proses refund masih di SAP karena FINA AP belum goLive. Penyelesaian AP masih harus dilakukan di SAP
    • Modul FINA A/P sudah siap digunakan tapi tim FSD (Yettie) kehabisan waktu karena banyak pekerjaan lain
    • Modul FINA A/P baru akan digunakan setelah restrukturisasi selesai.
  • Diskusi: Kelanjutan pengembangan modul-modul Sales dalam cakupan KGMedia ERP
    • DAN: Grand design sales system disampaikan sejak Januari 2023, sampai sekarang belum tim proyek dan koordinasi pada tingkat eksekusi belum pernah dilakukan.
    • Mas Novi: TI hanya perlu bertemu dengan Mbak Devi, Mas Wahyu, Mbak Sinta Ratnawati, dan Mas Patrice karena sudah mencukup semua nya.
  • Disepakati: Mas Novi akan mengadakan pertemuan yang melibatkan semua titik omzet membahas langkah ERP Media/ Sales selanjutnya.
6 Juni 2023
Rapat Rutin ERP Media (11.00 - )
  • Hadir: DAN, WIK, Yettie, Andhika, Darma, Gilang, Putri, Vincent
  • Diskusi: Alternatif2 alir mutasi dana (antar bank/cash)
    1. Cashier TOPUP: Create PD Top-Up --> lanjut ke aliran seperti Slip BC/CQ tapi jenis dananya: CASH, dana masuk ke kasir melalui layar konfirmasi
    2. Cashier TOPUP: Create transaksi Penerimaan Top Up --> lanjut seperti proses Receipt BG/ CQ, dana masuk ke kasir melalui transaksi RECEIPT.
    3. Cash to Cash: Review BALIN dan BALOUT Kasir, Report RC Intercompany
    4. Cash to Cash: Review Deposit BG/CQ Kasir
  • Kesepakatan: Diskusi lanjut hari Kamis
  • Outstanding:
    • Data-data untuk implementasi: COA, Org, Acc Addressing, ...
    • Skenario Clearing pembayaran manual
    • Test update modul Deposit, Voucher (v3)
    • Template posting Receipt dengan invoice ke SAP (Darma)
13 Juni 2023
Rapat Rutin ERP Media (10.00 - 17.50, terpotong makan2)
  • Hadir: DAN, WIK, YON, RDY, Yettie, Andhika, Darma, Gilang, Putri, Vincent
  • Disampaikan (DAN):
    • Jenis report baru berbasis layout: Outlook Type sudah selesai, siap diuji.
    • Penjelasan kolom-kolom tambahan penunjang report Outlook: EOY.[YTD], Period.[YTD], [PlanningTotal], [PlanningYTD]
  • Disepakati: Penambahan fitur "in-million" untuk menampilkan angka-angka dalam "jutaan" di Report Spec.
    (sudah langsung dikerjakan, sudah ditunjukkan 13 Juni 2023 13:15)
  • Diskusi: Transaction-transaksi Receipt dan Payment yang dialokasi (Kas/ Bank) tapi tidak mengalir ke A/R dan A/P: LBYR, KBYR, JASA GIRO, BUNGA BANK, dan transaction2 lain. Akan di bahas masing2. Keputusan sebelumnya: disediakan report untuk dijurnal manual di G/L.
  • Disepakati: Tentang Mutasi antar Bank
    • Akan dibuat layar baru "Clearing Mutasi Bank" untuk menginput mutasi dari rekening Bank Asal ke rekening Bank Tujuan termasuk proses clearing nya.
    • User bisa mengubah data dalam layar tersebut sampai di confirm
    • Saat di confirm:
      • Generate: Installment (type: Mutasi) sebanyak rekening bank tujuan
      • Generate: 1 Payment Requisition (PD) untuk masing-masing rekening bank tujuan
      • Generate: 1 Bank Payment (BPM)
      • Generate: Bank Payment Voucher (BPV) sebanyak rekening bank tujuan
      • Clearing: 1 baris RC di rekening bank asal
      • Clearing: 1 baris RC di masing-masing rekening bank tujuan
  • Diskusi: Pada sisi penerima seharusnya muncul Bank Receipt Voucher (BRV).
    • Kapan dan siapa yang akan menerbitkan voucher receipt belum diputuskan
    • Secara keseluruhan spesifikasi Receipt Voucher masih outstanding (2021)
  • Diskusi: CASH TOP-UP dan CASH WITHDRAWAL
    • Mengulang diskusi sebelumnya (6 Juni 2023)
    • Akan didiskusikan terlebih dahulu oleh FSD dan Finance tentang penanganan ke depannya
  • Disepakati: Setelah mutasi, seluruh fitur untuk implementasi Tribun bisa dikatakan "selesai". Penambahan atau perubahan fitur, jika ada, akan masuk ke "system update".
  • Outstanding:
    • Data-data untuk implementasi: COA, Org, Acc Addressing, ...
    • Skenario Clearing pembayaran manual
    • Test Report Outlook (Andhika)
    • Test update modul Deposit, Voucher (v3)
    • Template posting Receipt dengan invoice ke SAP (Darma)
    • Skenario CASH-TOPUP dan CASH-WITHDRAWAL (Yettie)
20 Juni 2023
Rapat Rutin ERP Media (14.50 - 18.30)
  • Hadir: DAN, WIK, YON, RDY, Yettie, Andhika, Darma, Gilang, Putri, Aulia, Zahra, Rizka
  • Diskusi: Cash Top Up (Bank to Cash), alir proses nya:
    • Cashier membuat "Balance Transfer" dengan tipe: "Bank to Cash", kemudian diproses. Saat proses, akan dihasilkan: Installment (processed) dan Payment Requisition/ PD (new).
    • Payment Requisition/ PD di approve oleh yang berwenang
    • Untuk pengisian kasir, Bank akan membuat slip untuk dicairkan oleh kasir di bank, bukan menyerahkan uang tunai. Petugas bank menentukan dari bank yang mana slip akan dibuat dan dilanjutkan dengan "Generate Slip". Slip yang baru kemudian di "Process". Fisik slip nya diserahkan ke kasir.
    • Kasir meng "Confirm" slip yang diterima. Ketika diterima, balance kasir akan naik senilai slip.
    • Kasir menjalankan "Cash to Cash" untuk mengubah "Slip" menjadi "Cash" setelah slip dicairkan ke bank
  • Disampaikan (DAN): Balance Transfer Bank to Bank (B2B) sudah selesai.
    • Demo Bank to Bank bisa dilakukan setelah transaksi di Bank Statement dari sisi pengirim maupun penerima sudah diimport masuk.
    • Baris2 Bank Statement di sisi bank penerima maupun bank pengirim harus dalam status belum dialokasi
    • Ditunjukkan: proses B2B meng-generate Installment, Payment Requisition, Bank Transfer, Bank Payment Voucher seperti keputusan tanggal 13 Juni 2023.
    Catatan: Status penyelesaian sudah disampaikan sebelumnya melalui WA Group IT Media n FSD tanggal 19 Juni 2023.
  • Disampaikan (Yettie): Belum bertanya kepada Finance (Dana) tentang proses-proses balance transfer.
  • Diskusi: Cash Withdrawal (Cash to Bank), alir proses nya:
    • Cashier membuat "Balance Transfer" dengan tipe: "Cash to Bank", kemudian diproses.
    • Saat setoran kasir muncul di Bank Statement. Petugas mengalokasi setoran kasir sebagai clearing "Balance".
    • Saat clearing di posting maka Balance Transfer C2B yang dibuat kasir akan berubah status menjadi selesai.
  • Diskusi tentang Voucher
    • Saat Slip.Process maunya tercreate BPV. Setelah dicek struktur tabel data, Slip ini tidak ready digenerate ke BPV, ada kolom yang kurang
    • BPV selama ini disiapkan hanya untuk Bank Payment, tidak disiapkan untuk ke Slip. Jika ingin bisa digunakan untuk slip, maka struktur tabel perlu dirombak. IT Media bersedia merombak, namun harus sudah difinalkan dari FSD maunya dibuat seperti apa.
      Catatan: Sudah ada 2 versi voucher dibuat di FINA, belum pernah direview secara utuh oleh FSD. Diskusi terakhir: 2021.
    • IT Media meminta FSD akan menyusun skenario dan lengkap dengan simulasinya: timing, grouping, dll.
  • Diskusi: Cash to Cash:
    • Cashier membuat "Balance Transfer" dengan tipe: "Cash to Cash", kemudian diproses.
    • Cash to Cash digunakan untuk memindahkan dana:
      • Antar Cash Counter
      • Dari alat bayar selain "Cash" menjadi "Cash" di satu Cash Counter.
    • Saat diproses, balance transfer akan mengubah balance alat bayar di cash counter yang bersangkutan. Prosesnya selesai di kasir.
    • Cash to Cash tidak dijurnalkan.
  • Disepakati:
    • Proses Bank to Bank sudah benar, ada issue penerbitan voucher
    • Proses Bank to Cash, Cash to Bank, dan Cash to Cash akan dibuat sesuai catatan diskusi di atas.
    Update: 3 proses B2C, C2B, C2C sudah selesai dan sudah dilaporkan melalui WA Group IT Media n FSD tanggal 23 Juni 2023.
  • Outstanding:
    • Skenario dan simulasi Voucher: timing, grouping, dll
    • Data-data untuk implementasi: COA, Org, Acc Addressing, ...
    • Skenario Clearing pembayaran manual
    • Test Report Outlook (Andhika)
    • Test update modul Deposit, Voucher (v3)
    • Template posting Receipt dengan invoice ke SAP (Darma)
    • Skenario CASH-TOPUP dan CASH-WITHDRAWAL (Yettie)
27 Juni 2023
Rapat Rutin ERP Media (15.00 - )
  • Hadir: DAN, WIK, YON, RDY, Yettie, Andhika, Darma, Gilang, Putri
  • Disampaikan (DAN): B2C, C2B, C2C sudah selesai (demo langsung di depan Yettie)
  • Disampaikan (DAN): Masih dicari cara way-around terbentuk BPV saat slip dibuat, pertimbangan2:
    • BPV membutuhkan "Bank Payment" sebagai inisiator dan itemnya
    • BPV yang sekarang tidak ada pengelompokan, karena diminta 1 PD 1 BPV
    • Voucher timing, proses, belum pernah didefinisikan secara utuh (Lihat outstanding)
  • Disepakati: Karena baru disampaikan minggu lalu (20 Juni 2023) maka Slip BPV tidak menjadi stopper implementasi Tribun. Slip BPV bisa menjadi proses yang cukup panjang karena proses sudah terkait ke mana-mana.
  • Disepakati: Setelah GL dan Balance Transfer maka pengembangan tahap ini selesai. IT Media berusaha agar slip BPV bisa segera diselesaikan.
  • Outstanding:
    • Skenario dan simulasi Voucher: timing, grouping, dll
    • Data-data untuk implementasi: COA, Org, Acc Addressing, ...
    • Skenario Clearing pembayaran manual
    • Test Report Outlook (Andhika)
    • Test update modul Deposit, Voucher (v3)
    • Template posting Receipt dengan invoice ke SAP (Darma)
28 Juni 2023
Persiapan Implementasi Tribun (13.00 - 14,30)
  • Hadir: RAM, DAN, YON, RDY, Yettie, Andhika, Darma, Sumani, Aulia, Ryan, ...
  • Disampaikan (RAM):
    • IT Media sudah menyelesaikan modul-modul yang ditunggu dari rapat sebelumnya.
    • Berharap implementasi bisa segera dilakukan
  • Disampaikan (SUMANI):
    • Sudah beberapa kali ditanya kapan implementasi FINA
    • Jadwal training bisa terkendala karena: Idul Adha, BPR, proses akhir bulan.
    • Perlu disusun materi training
    • Perlu menyusun presentasi kepada manajemen Tribun tentang fitur2 FINA
  • Diskusi:
    • Tim perlu menyampaikan status kesiapan kepada manajemen sesegera mungkin
    • Usulan agar presenter ke manajemen Tribun adalah personel dari Tribun (Aulia?)
    • Meskipun kapan training (ulang) dilaksanakan belum jelas, tim perlu segera mempersiapkan diri seandainya training dimulai minggu depan
    • Tentang COA baru yang belum selesai disusun, seharusnya tidak menjadi hambatan karena COA seharusnya dinamis (bisa berubah di masa mendatang) dan fasilitas untuk mengubahnya sudah tersedia.
  • Disepakati: Tim implementor akan bertemu hari Senin 3 Juli 2023 di r.rapat Proyek untuk menyusun presentasi dan menuntaskan persiapan2.
11 July 2023
Persiapan Implementasi Tribun (10.00 - 12.00)
  • Hadir: Pak Cip, Daniel, Dhanang, Amie, Sumanie, Ririen, Julia, Heru Kuncara, Regina, Ryan, Riska, Azzahra, Vinsensius Ghana, Michael Gilang, Prima, Putri, Dharma, Marina Napitupulu, Yettie, Agus Ramdhani, Rudyanto, Andhika, Yuyun
  • Disampaikan (RAM):
    • FINA bagian dari ERP Media, sebagian modul termasuk FINA sudah selesai, sebagian masih dibangun.
    • FINA sudah selesai, multi company, multi currency, sudah sebagian diimplementasikan, Tribun akan menggunakan all modules.
  • Diskusi:
    • Aulia: Penjelasan tentang proses di CAS dan FINA (dipotong, tidak dilanjutkan)
    • Heru: Diinginkan sistem yang inputnya tidak banyak, atau harus melalui proses yang panjang karena jumlah operator sedikit
    • Sumani: Kegiatan tetap dilanjutkan
Rapat Rutin ERP Media (14.00 - 19.00)
  • Hadir: DAN, YON, RDY, WIK, Yettie, Prima, Putri, Darma, Andhika, Vincent
  • Diskusi:
    • Darma: Ingin "transaction-type" dipindahkan ke posisi item dari COA Addressing
    • Darma, Andhika: Masih ada beberapa object yang perlu di assign ke addressing, sedang berlangsung dengan Mas Yono
    • DAN: Parameter addressing sudah diperiksa oleh FSD kenapa masih ada yang terlewat. Karena logic addressing sudah di roll-out, pemindahan "transaction-code" ke line item akan mengupdate banyak tempat, butuh waktu, butuh test ulang.
    • DAN: Sebaiknya keseluruhan addressing di skenariokan lengkap sebelum update dibuat jangan2 masih ada yang ketinggalan.
    • Diharapkan saat Giro/ Cheque "disbursing" system membuat "Cash Payment Voucher" (CPV).
  • Disepakati: Giro/ Cheque disbursing akan sekaligus:
    • Membuat Installment, tipe: Transfer, alat bayar: BG/CQ, Paid to Party: Organization pemilik bank, peminta: cashier.
    • Membuat Payment Requisition (PD) Status: Paid
    • Membuat tansaksi "Bal-Out" di kasir sehingga saldo Giro/ Cheque berkurang.
    Note: Aplikasi sudah diupdate 12 July 2023, sudah diinfo ke FSD via WA Group "IT Media n FSD".
  • Disepakati: Istilah "Balance Transfer" diubah menjadi "Disposition" dan akan diupdate ke seluruh object/ material di FINA.
  • Disepakati: Tim bertemu lagi besok, 12 Juli 2023, topik bahasan: Voucher
  • Outstanding:
    • Skenario dan simulasi Voucher: timing, grouping, dll
    • Data-data untuk implementasi: COA, Org, Acc Addressing, ...
    • Skenario Clearing pembayaran manual
    • Test Report Outlook (Andhika)
    • Test update modul Deposit, Voucher (v3)
    • Template posting Receipt dengan invoice ke SAP (Darma)
12 Juli 2023
Rapat Rutin ERP (13.30 - )
  • Hadir: DAN, YON, WIK, Yettie, Gilang
  • Disampaikan (DAN):
    • Update fungsi disbursing Giro/ Cheque sesuai kesepakatan tanggal 11 Juli sudah selesai
    • Disbursing Giro/ Cheque sudah menghasilkan Cash Payment Voucher
    • Diusulkan untuk membuat dokumen yang menyatakan Giro/ Cheque sedang dalam proses disbursing
    • Demo: disbursing Giro/ Cheque, sampai menghasilkan Installment, Payment Requisition (PD), Cash Payment Voucher.
    • Demo: Clearing Giro/ Cheque dari proses Bank Allocation, dan sudah mengubah status Giro/ Cheque menjadi disbursed.
  • Disampaikan (Yettie):
    • Setiap mutasi terhadap balance di Cash dan Bank harus menghasilkan voucher
    • Payment Voucher seluruhnya bertumpu pada PD 1:1. Tidak bisa di group lebih lanjut.
    • Receipt Voucher tetap harus dihasilkan, tapi perlu di group berdasarkan kriteria tertentu supaya mengurangi jumlah entry di GL dan jumlah cetakan (arsip).
  • Diskusi
    • Voucher grouping yang pernah disepakati sebelumnya (7 April 2021) dan sudah di-code menjadi Modul Voucher v.2:
      • Berasal dari Application (sistem sumber) yang sama
      • Diterima oleh Bank Account atau Cash Counter yang sama
      • Ditujukan kepada SalesOrg yang sama
      • Berasal dari Allocation Transaction Type yang sama
      • Posting date sama
      Modul tersebut belum pernah ditest secara lengkap oleh FSD sampai akhirnya dianggap tidak sesuai kebutuhan.
    • Masalah grouping perlu mempertimbangkan:
      • Satu transaksi penerimaan Cash (CR) atau satu baris Bank RC (RC) bisa dialokasi menjadi beberapa jenis transaksi/ Transaction Type.
      • Arsip dari satu transaksi (terutama CR) tidak boleh tercerai/ terpisah menjadi beberapa voucher penerimaan
      • Satu transaksi bisa melintas ke beberapa Sales Organization, ke beberapa Application, meskipun dalam satu Company.
    • Receipt Voucher grouping yang memungkinkan:
      • Berasal dari Company yang sama
      • Diterima oleh Bank Account atau Cash Counter yang sama
      • Posting date sama
      Diskusi tentang voucher belum final.
  • Disepakati:
    • PD hasil disbursing Giro/ Cheque akan berstatus "Cleared" untuk menghindari proses "Clearing". Sudah langsung diselesaikan.
    • Akan dibuat dokumen "disbursing" untuk menyatakan proses disbursing
    • Receipt Voucher akan langsung dikerjakan dengan kesepakatan sementara tentang grouping, pemindahan titik posting ke G/L akan diubah setelah modul Receipt Voucher selesai.
  • Outstanding:
    • Skenario dan simulasi Voucher: timing, grouping, dll
    • Data-data untuk implementasi: COA, Org, Acc Addressing, ...
    • Skenario Clearing pembayaran manual
    • Test Report Outlook (Andhika)
    • Test update modul Deposit, Voucher (v3)
    • Template posting Receipt dengan invoice ke SAP (Darma)
17 Juli 2023
Rapat Rutin ERP (Tidak jadi rapat karena kesibukan BPR)
  • Hadir: YON, Darma, Andhika, Gilang, Putri, Vincent
  • Diskusi:
    • Export Invoice ke SAP
    • Pertanyaan (DAN): jenis transaksi apa saja yang mengalir menjadi Voucher
    • Disampaikan (DAN): Dokumen "disbursing" belum dibuat karena malah akan memperpanjang informasi (ttg giro/ cheque). Apalagi dokumen semacam itu saat ini tidak ada. Pengurutan disbursing bisa berdasarkan tanggal disbursing.
    • Diskusi tentang Voucher harus menunggu keputusan FSD (Yettie)
  • Outstanding:
    • Skenario dan simulasi Voucher: timing, grouping, dll
    • Data-data untuk implementasi: COA, Org, Acc Addressing, ...
    • Skenario Clearing pembayaran manual
    • Test Report Outlook (Andhika)
    • Test update modul Deposit, Voucher (v3)
    • Template posting Receipt dengan invoice ke SAP (Darma)
26 Juli 2023
Rapat Pembahasan Masukan Bakal Calon User Tribun
  • Hadir: DAN, YON, RDY, WIK, Yettie, Darma, Andhika, Putri, Gilang, Vincent, Rohimam, Immanuel, Mukhlis.
  • Disepakati: Penambahan report baru "Buku Bantu Bank"
    • Filter: Bank Account, Tanggal Awal, Tanggal Akhir
    • Sort: Tanggal tua di atas (ascending)
    • Kolom: Sama seperti "Bank Statment", ditambah: Workstate (text), Bank Account Info, Beginning Balance
    Sudah langsung diselesaikan (26 Jul 2023).
  • Disepakati: Update report "Pre Payment Balance" ditambah: Requestor dan PIC. Historynya hanya "Paid", "BS Allocation", dan "Closed" saja yang ditampilkan. Update: Sudah langsung diselesaikan (26 Jul 2023).
  • Disepakati: Penambahan report baru "Deposit Balance". Bentuknya sama seperti Pre Payment Balance atau Down Payment Balance. Note: Sudah diselesaikan dan sudah dilaporkan tanggal 27 Jul 2023 melalui WAG "IT Media n FSD".
  • Disepakati: Sehubungan dengan peraturan pajak terbaru tentang Surat Keterangan Bebas (SKB) yang harus dibuat meskipun nilai nya nol
    • Master Supplier ditambah flag SKB dan nomor SKB, tanggal dibuat, tanggal berakhir (selalu 31 Des). Sudah diselesaikan dan sudah dilaporkan tanggal 27 Jul 2023 melalui WAG "IT Media n FSD".
    • Nilai WHT Out mengikuti informasi di APInvoice.[IncomeTaxAmount]. Jika SKB masih berlaku, APInvoice.[IncomeTaxPercentage] tetap ada nilainya, tapi APInvoice.[IncomeTaxAmount] = 0.0000
  • Disepakati: Sehubungan dengan peraturan pajak terbaru tentang Surat Keterangan Bebas (SKB) yang harus dibuat meskipun nilai nya nol
    • Master Supplier ditambah flag SKB dan nomor SKB, tanggal dibuat, tanggal berakhir (selalu 31 Des)
    • Nilai WHT Out mengikuti informasi di APInvoice.[IncomeTaxAmount]. Jika SKB masih berlaku, APInvoice.[IncomeTaxPercentage] tetap ada nilainya, tapi APInvoice.[IncomeTaxAmount] = 0.0000
  • Outstanding:
    • Skenario dan simulasi Voucher: timing, grouping, dll
    • Tambahan 27 Juli 2023: Test dan verifikasi Report Deposit Balance.
    • Data-data untuk implementasi: COA, Org, Acc Addressing, ...
    • Skenario Clearing pembayaran manual
    • Test Report Outlook (Andhika)
    • Test update modul Deposit, Voucher (v3)
    • Template posting Receipt dengan invoice ke SAP (Darma)
31 Juli 2023
Pertemuan mendadak karena ada permintaan 2 report baru "A/R Mutasi" dan "A/P Mutasi"
  • Hadir: DAN, RDY, Yettie, Darma, Andhika, Putri, Gilang, Vincent
  • Disepakati: Penambahan report baru "A/R Mutasi"
  • Disepakati: Penambahan report baru "A/P Mutasi"
  • Outstanding:
    • Skenario dan simulasi Voucher: timing, grouping, dll
    • Tambahan 27 Juli 2023: Test dan verifikasi Report Deposit Balance.
    • Tambahan 27 Juli 2023: Test dan verifikasi Report Buku Bantu Bank.
    • Data-data untuk implementasi: COA, Org, Acc Addressing, ...
    • Skenario Clearing pembayaran manual
    • Test Report Outlook (Andhika)
    • Test update modul Deposit, Voucher (v3)
    • Template posting Receipt dengan invoice ke SAP (Darma)
5 Sep 2023
Rapat rutin ERP IT Media - FSD (10.00 - )
  • Hadir: DAN, RDY, YON, WIK, ROH, Yettie, Darma, Andhika, Putri, Gilang, Vincent
  • Disampaikan (Darma): Masukan-masukan dari training user Tribun 28, 29, 30 Agustus 2023:
    • Ada kasus orang salah transfer, untuk pengembalian sudah bisa menggunakan deposit, user ingin lebih pendek --> ditampung
    • Belum ada transaction type "Bank Expense" untuk alokasi --> langsung ditambahkan
    • Memo type sekarang dikunci, berarti penambahan data harus oleh IT (Rudyanto)
    • Melaporkan bug: laporan VAT In (Pajak) jika "paid to" bertipe organization tidak muncul di eFactur
    • Minta bisa di export ke excel: VAT-In dan VAT-Out (langsung dikerjakan)
    • Biaya Bunga Pinjaman, dialokasi menjadi "Biaya Bunga Pinjaman", langsung di buat jurnal memo tanpa voucher. --> langsung dibuat.
  • Diskusi: Upload invoice ke SAP
    • Saat ini SIS masih digunakan untuk mencatat buku dan merchandise, terutama untuk update stock. Admin memelihara excel untuk mencegah double posting ke SAP dengan yang diinput ke FastKom --> terkonfirmasi
  • Outstanding:
    • Tambahan 27 Juli 2023: Test dan verifikasi Report Buku Bantu Bank.
    • Data-data untuk implementasi: Org, COA Addressing, ...
13 Sep 2023
Fina Project Dihentikan
  • Diskusi via WA Chat (21:30)
  • Disampaikan (RAM): Proyek pengembangan Fina dihentikan, selanjutnya peran Fina akan diambil alih oleh Odoo
    • Pengembangan sistem dihentikan
    • Implementasi di Tribun dihentikan
    • Lanjutan implementasi di Harian Kompas dihentikan, yang sudah masuk Fina menunggu kesiapan Odoo
    • Developer yang selama ini membantu pengembangan di ES KG Media akan di layoff. Sebagian akan diambil oleh CITIS
  • Aftermath:
    • 18 Sept 2023, assesment pada 14 orang programmer yang membantu ES KG Media (termasuk 3 programmer FINA dan 1 tester FINA) oleh CITIS dimulai.
    • 25 Sept 2023, dari 14 orang yang di asses, 3 bergabung ke CITIS (termasuk 2 programmer FINA), 11 lainnya di-layoff (termasuk 1 programmer FINA dan 1 tester FINA).
    • Per 1 Nov 2023, DAN, YON, RDY, WIK bergabung ke TPD (Teknology, Product, Data) harian Kompas.
    • Proses selanjutnya menunggu CITIS untuk implementasi KG ERP (Odoo) di KG Media.
— WE WERE HERE —
Sutekno Dev.Team