About – FINA™

Peran/ Role	Description
Legal Entity	Organisasi sebagai badan hukum, entitas pajak: Perusahaan, PT, Yayasan, dll.
Company	Organisasi sebagai "company"/ suku usaha.
Department	Organisasi struktural sesuai struktur organisasi SDM
Revenue Center	Organisasi dapat menerima dan mengakumulasi pendapatan
Cost Center	Organisasi dapat menanggung atau menerima beban (biaya)
Sales Organization	Organisasi fungsional yang menjual barang atau jasa kepada customer
Purchasing Organization	Organisasi fungsional yang membeli barang atau jasa dari supplier
Warehouse	Organisasi fungsional yang menyimpan barang-barang stock
Asset Center	Organisasi fungsional yang mengelola barang-barang inventaris perusahaan
Cash Funder	Organisasi sebagai penyandang dana "talangan" Cash atau Bank setara 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:

Internal Organization
Customer
Supplier
Bank
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:

Open	`Cash Counter` sedang beroperasi, ada seorang `Cashier` yang sedang check-in di `Cash Counter` tersebut.
Close	`Cash Counter` sedang tidak beroperasi, tidak ada `Cashier` yang sedang check-in di `Cash Counter` tersebut.
Idle	`Cash 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:

Cash Receipt
Cash Payment
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 memposting 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

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:

Customer
Supplier - (not exist in this version)
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 Statement Processing - (Receipt Only)

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".

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 memposting 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

Pre-Payment atau selanjutnya disebut BS (Bon Sementara) adalah permintaan dana untuk membayar transaksi yang akan dilakukan, atau yang nilainya masih belum diketahui secara pasti, dan belum tersedia bukti transaksi dari Supplier (pihak ketiga: penjual atau pemberi jasa).

Di Fina, siklus Pre-Payment dibagi menjadi 4 yaitu:

Pre-Payment Submission (Pengajuan BS)
Pre-Payment Funding (Penyediaan dana untuk BS)
Pre-Payment Disbursement (Pencairan dana BS)
Pre-Payment Closing (Penyelesaian BS)

Proses-proses BS tersebut di atas akan mengubah status dokumen BS. Di Fina status dokumen (entitas) di dalam alir kerja (workflow) disebut dengan Workstate.

Diagram workstate memperlihatkan status BS mulai dari New sampai selesai (finale) dengan workstate Void, Rejected, Closed, atau Cancelled. Garis berwarna biru menunjukkan proses maju, sedangkan garis berwarna hijau menunjukkan proses pembatalan (reject/ void/ cancel).

Pre-Payment Submission (Pengajuan BS)

Pembuatan/ Pengisian Form BS

Form BS seharusnya dibuat/ diisi sendiri oleh peminta dana langsung di Fina. Dalam kasus khusus, pengisian dapat diwakili oleh orang lain (sekretaris, sekretariat unit). Peminta dana secara otomatis akan menjadi penanggungjawab BS tersebut. Informasi dalam BS yang harus diisi antara lain:

Penanggungjawab (debtor) adalah Employee karyawan tetap peminta dana.
Anggaran dari mana dana akan diambil. Dengan memilih Budget, sejak awal BS untuk kepentingan operasional atau proyek sudah dipisahkan. Dari pilihan Budget juga langsung diketahui Cost Center, Company, dan Legal Entity untuk pembebanan.
Jumlah dana (amount) yang diminta dan dalam mata uang apa
Metode Pembayaran (payment method) yang diminta, misalnya tunai, transfer, BG, cheque dilengkapi dengan informasi nomor rekening penerima, tanggal pencairan, kasir tempat pencairan tunai, dll.

BS yang baru dibuat akan mendapat tanda (workstate) New. BS bisa diedit berkali-kali sebelum dikirimkan untuk mendapat persetujuan dari atasan. BS juga dapat dihapus atau di-Void.

BS dikirimkan dengan menekan tombol "Send" pada layar Pre-Payment. Saat dikirimkan status BS akan berubah menjadi Need Approval, isi form BS tidak dapat diubah lagi.

Approval Form BS

Setelah formulir BS dibuat, peminta dana (atau yang mewakili) kemudian mengirimkan formulir tersebut ke atasannya untuk mendapatkan persetujuan (approval). Pengiriman dilakukan dengan menekan tombol "Send" pada layar Pre-Payment.

Atasan yang dimaksud adalah karyawan lain dalam hirarki otorisasi Budget yang dipilih dalam BS. Persetujuan dilakukan dengan menekan salah satu dari 3 tombol yang tersedia yaitu:

Tombol Approve, jika BS disetujui. Status BS akan berubah menjadi Approved
Tombol Reject, jika BS ditolak. Status BS akan berubah menjadi Rejected
Tombol Send Back, jika atasan ingin memina revisi. Status BS akan berubah menjadi Need Revision

Persetujuan via email Call to Action (CTA) baru akan ditambahkan di Fina v3.0. Di versi 1.1 ini BS hanyalah pelengkap proses titipan (deposit) di kasir.

Implementasi Fina Pre-Payment membawa perubahan (change) cukup besar pada proses bisnis berjalan sehingga tidak mungkin dilakukan di tahap ini.

Permintaan Dana BS: Jika form BS sudah disetujui oleh atasan dan sudah mendapat tanda approved secara otomatis form BS tersebut terkirim ke bagian keuangan dan masuk dalam Daftar Ajuan BS (Pre-Payment Request).; Proses selanjutnya adalah penyiapan dana oleh Finance Admin.

Pre-Payment Funding (Penyiapan Dana BS)

Daftar Ajuan BS (Pre-Payment Request)

BS yang sudah disetujui otomatis masuk ke Daftar Ajuan BS yang dikelola oleh Finance Admin. Daftar tersebut memudahkan Finance Admin memantau BS dan status-statusnya (workstates).

Layar Pre-Payment Request menyediakan menu-menu untuk memproses BS yaitu:

Edit untuk mengubah cara bayar dan tujuan kasir untuk pencairan dana
Cetak BG
Cetak Cheque
Cetak Slip Penarikan Dana (Withdrawal Slip), untuk dana tunai yang harus dicairkan ke bank (khusus BRI untuk kasir-kasir di Palmerah)
Transfer antar rekening bank

Penyiapan Dana

Berdasarkan cara bayar yang diminta dalam BS Finance Admin menyiapkan pendanaan untuk BS tersebut. Ada 3 skenario penyiapan dana BS:

BS transfer ke rekening bank, dilakukan langsung oleh Finance Admin
BS Tunai, disiapkan oleh Finance Admin, diselesaikan di Cash Counter atau di bank
BS Giro dan Cheque, disiapkan oleh Finance Admin, diselesaikan di Cash Counter

BS Transfer ke rekening bank: Finance Admin dapat langsung melakukan transfer dana BS ke rekening bank tujuan. Rekening bank tujuan bisa milik rekening peminta dana atau milik pihak lain sesuai tertera dalam BS.; BS yang dana-nya di transfer ke rekening bank statusnya akan berubah menjadi Paid (terbayar) ketika diposting.

BS Tunai

Ada 2 skenario BS Tunai yaitu:

BS Tunai, dana dicairkan di Cash Counter
BS Tunai, dana dicairkan di Bank

BS Tunai yang dana nya dicairkan di Cash Counter dapat langsung diposting, statusnya akan berubah menjadi Ready (siap dicairkan) setelah di posting.

BS Tunai yang dana nya dicairkan di Bank diproses oleh Finance Admin dengan mencetak slip penarikan dana bank (Bank Withdrawal Slip). Setelah slip dicetak, status BS akan berubah Printed.

Cetakan slip tersebut kemudian "titipkan" ke Cash Counter. Peminta dana akan mengambil slip penarikan dana di Cash Counter lalu mencairkan dana tunai yang diminta di bank.

BS Tunai yang dana nya dicairkan di Bank statusnya akan berubah menjadi Shipped setelah diposting.

BS Giro dan Cheque: BS Giro dan Cheque diproses oleh Finance Admin dengan mencetak Giro atau Cheque. Setelah slip dicetak, status BS akan berubah Printed.; Cetakan Giro atau Cheque tersebut kemudian "titipkan" ke Cash Counter. Peminta dana akan mengambil giro atau cheque nya di Cash Counter yang disebutkan dalam BS. BS Giro/ Cheque statusnya akan berubah menjadi Shipped setelah diposting.

Posting BS: Posting menandai akhir proses penyiapan dana BS. BS Tunai, BS Giro, dan BS Cheque akan berubah menjadi Shipped setelah posting, sedangkan BS Transfer akan langsung menjadi Paid (terbayar).; Voucher (Bank Payment Voucher/ Bukti Bank Keluar) langsung diterbitkan ketika BS Transfer, BS Giro, dan BS Cheque diposting.

Pre-Payment Disbursement (Pencairan BS)

Ada 2 proses yang terkait pencairan dana BS di Cash Counter, yaitu:

Mencatat Titipan Masuk
Mencatat Titipan Keluar dan Pembayaran Keluar

Mencatat Titipan Masuk: Proses ini terjadi saat Cashier menerima kiriman cetakan Giro/ Check/ Withdrawal Slip dari Finance Admin. Cashier mencatat alat-alat bayar yang diterimanya sebagai Transaksi Titipan Masuk (deposit-in) dengan tetap merujuk ke BS nya. Setelah dicatat sebagai titipan, status BS akan berubah menjadi Ready (siap diambil).

Mencatat Titipan Keluar dan Pembayaran Keluar: Proses ini terjadi saat peminta dana (debtor) datang ke Cash Counter untuk mengambil dana dengan menunjukkan identitasnya (kartu karyawan).; Cashier mencari BS atas nama peminta dana. Untuk BS Tunai yang dicairkan di bank, BS Giro, dan BS Cheque menyerahkan dana, dan mencatatnya sebagai Transaksi Pembayaran Keluar (Payment Out). Alat bayar yang digunakan sesuai tercantum dalam BS. Untuk BS Giro, BS Cheque, dan BS Tunai yang dananya akan dicairkan di Bank, Cashir harus mencatat terlebih dahulu Transaksi Titipan Keluar (Deposit Out).; Saat Transaksi Pembayaran Keluar diposting, status BS akan berubah menjadi Paid (terbayar). Khusus BS Tunai (cair di manapun), Voucher (Cash Payment Voucher/ Bukti Kas Keluar) akan diterbitkan saat posting.

Pre-Payment Closing (Penyelesaian BS)

Penyelesaian BS dapat dilakukan setelah dana dibayarkan ke Supplier (pihak ketiga penjual atau pemberi jasa) dan bukti transaksi (invoice, struk belanja, nota, dll) sudah tersedia.

Penyelesaian BS dicatat saat peminta dana (debtor) datang ke Cash Counter membawa bukti-bukti transaksi dan sisa dana (jika ada). Ada 3 kondisi yang mungkin saat penyelesaian BS:

Dana BS sama dengan Invoice yang sudah dibayar
Dana BS lebih besar dari Invoice yang sudah dibayar (surplus)
Dana BS lebih kecil dari Invoice yang sudah dibayar (minus)

Part ini sudah sempat disinggung dalam rapat tanggal 13 April 2021, lalu hilang dalam diskusi --> masih outstanding

Pre-Payment Cancellation (Pembatalan BS)

No.	Kondisi	Workstate	Action	Workstate Akhir
1.	Dibatalkan sendiri oleh pembuat BS	New, Need Revision	Hapus BS	Void
2.	Ditolak Atasan	Need Approval	Reject BS oleh atasan	Rejected
3.	BS sudah diajukan, belum diproses	Approved	`Finance Admin` membatalkan BS	Cancelled
4.	Giro/ Cheque/ Withdrawal slip sudah dicetak	Printed	?	Cancelled
5.	Giro/ Cheque/ Withdrawal slip dalam perjalanan ke `Cash Counter`	Shipped	?	Cancelled
6.	Giro/ Cheque/ Withdrawal slip sudah dicatat sebagai deposit di `Cash Counter`	Ready	?	Cancelled
7.	BS Giro, BS Cheque, BS Tunai, tidak jadi dibayarkan ke pihak ketiga, tidak ada bukti transaksi	Paid	Kembalikan Giro/ Cheque/ Withdrawal Slip/ Uang tunai ke `Cash Counter`	Closed
8.	BS Transfer, tidak jadi dibayarkan ke pihak ketiga, tidak ada bukti transaksi	Paid	?	?

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

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:

Cash Receipt Voucher atau Bukti Kas Masuk
Cash Payment Voucher atau Bukti Kas Keluar
Bank Receipt Voucher atau Bukti Bank Masuk
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)

Chart of Accounts (COA)

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 Side	Microsoft SQL Server 2012
Client Side:	HTML5, CSS3, Javascript (ES5)
Libraries:	JQuery, Bootstrap 3.3.7, Select2, Moment.js

Object Access Control

System Default Security: adalah pengamanan akses yang sudah diterapkan di seluruh sistem di Kompas (FastKom, Sitika, GMMS, dll). Skema ini berfokus pada PROSES dengan membatasi hak akses pada proses-proses seperti Bank Save, Organization Delete, PO Approve, dll. Hanya User yang diberi hak akses dapat mengeksekusi proses-proses tersebut.

Data Ownership based Security: Di sistem yang multi-organisasi, kepemilikan data dan informasi tetap harus dihormati. Seorang User yang memiliki hak akses untuk meng-approve PO (PO Approve) harus dipastikan User tersebut hanya dapat meng-approve PO dari Organization nya sendiri.

Object State based Security: Security 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 untuk perancangan relational-database, ERD masih lebih unggul karena dapat memetakan secara langsung tabel-table di dalam database.

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

Project Team

Yustinus Edi Susilo	Accounting Kompas	Project Manager
Juanda Eka Setiawan	Kompas Product Sales Manager	Representative
Hussinto	Accounting Kompas	Business Analyst, Financial Analyst
Adiyan Randal Singarimbun	Sirkulasi Kompas Gramedia	Business Analyst - Marketing
Eriyanto	Sirkulasi Kompas Gramedia	Business Analyst - Marketing
Eliada	Sirkulasi Kompas Gramedia	Business Analyst - Back Office
Yettie Krisnha	Corp. FSD	Financial Analyst, implementor
Prima Dyah	Corp. FSD	Financial Analyst, implementor
Darma Datu	Corp. FSD	Financial Analyst, implementor
Rudyanto	TI Kompas/ GoMed	Project liaison, implementor
Heru Margowiyono	TI Kompas/ GoMed	System Analyst, programmer
Daniel Kurniawan	TI Kompas/ GoMed	System Analyst, programmer
Mukhlis Wicaksono	TI Kompas/ GoMed	Programmer
Immanuel Saragih	TI Kompas/ GoMed	Programmer
Rohimam	TI Kompas/ GoMed	Programmer
Wiwik Dyah	TI Kompas/ GoMed	SQA, implementor
Setyo Sabdono	TI Kompas/ GoMed	SPSK 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: CITIS mengusulkan implementasi Odoo menjadi pengganti sistem pengendali keuangan yang sekarang dipakai (SAP/ CMS). Sementara itu, pengembangan Fina sebenarnya adalah keputusan bersama CITIS juga setelah melalui iterasi pencarian solusi yang cukup panjang untuk mengatasi masalah kelancaran informasi pembayaran yang telah terjadi bertahun-tahun.
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 diposting 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 diposting 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 diposting 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 diposting 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 diposting 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 diposting, 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 diposting, 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 diposting maupun yang belum diposting 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 diposting 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 peran 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)

— WE WERE HERE —
Sutekno Dev.Team

FINA General Features v2.0 Toggle Dropdown Version 3.0 Version 3.1 Version 2.0 Version 1.1 Version 1.0 (oldest)

DETAIL FEATURES:

FINA Financial System

Implementasi Agustus 2021 dan Kelanjutan FINA

FINA BP (Business Partner)

FINA Internal Organization

FINA Customer

FINA Supplier

FINA Employee

FINA Transaction

FINA Cash Management

Cash Counter Management

Cash Transaction

Cash Receipt Transaction

Cash Payment Transaction

Cash Deposit Transaction

Multi-Currency Proses Cash

Entitas-Entitas Currency Proses Cash

Skenario Currency-Exchange Proses Cash

FINA Bank Management

Pengelolaan Bank Account

Bank Statement Processing - (Receipt Only)

Bank Import Module

Bank Statement Module

Multi-Currency Proses Bank

Entitas-Entitas Currency Proses Bank

Skenario Currency-Exchange Proses Bank

FINA Pre-Payment (BS/ Bon Sementara)

Pre-Payment Submission (Pengajuan BS)

Pre-Payment Funding (Penyiapan Dana BS)

Pre-Payment Disbursement (Pencairan BS)

Pre-Payment Closing (Penyelesaian BS)

Pre-Payment Cancellation (Pembatalan BS)

Pre-Payment Journal (Jurnal BS)

FINA Voucher (Bukti Kas/ Bank)

FINA Ledger (v1.1 = partially)

Chart of Accounts (COA)

FINA Technical

Architecture & Technology Stack

Object Access Control

How to read our ERD

Fina Project

Project Team

Project Log

Data Kurang Lengkap

FINA General Features

Version 3.0

Version 3.1

Version 2.0

Version 1.1

Version 1.0 (oldest)