About – FINA™

Internal Organization: Internal Organization atau disebut Organization saja adalah unit-unit bisnis atau unit-unit kerja yang terlibat atau memiliki peran dalam proses dan transaksi di Fina baik secara fungsional maupun struktural.

Internal Organization adalah BP

Seluruh pihak (parties) yang terlibat dalam proses bisnis di Fina disebut Business Partner atau BP. Dalam pengertian tersebut Internal Organization adalah BP juga.

Internal Organization merupakan salah satu dari 5 jenis BP yang ada di Fina yaitu:

Internal Organization
Customer
Supplier
Bank
Employee (Cashier, Bank Admin, dll)

Struktur Internal Organization: Internal Organization disusun secara hirarkis membentuk pohon (tree) yang disebut struktur organisasi. Walaupun ada kemiripan, struktur organisasi di Fina tidak harus sama persis dengan struktur organisasi (departemental) menurut HR (Human Resource). Karena ada unit-unit yang sulit diwakili oleh organisasi sebagai departemen, misalnya konsorsium, proyek, organisasi functional seperti gudang, dll.

Pewarisan (Inheritance): Internal Organization dapat memiliki atribut informasi yang dilekatkan langsung ke Internal Organization tersebut seperti informasi Nama, Home Currency, dan Bank Account. Organization juga dapat mewarisi (inherit) atribut informasi dari induknya (parent).; Pada gambar dicontohkan Divisi Marketing tidak menetapkan home-currency nya. Transaksi di Divisi Marketing akan dilakukan dalam currency IDR mengikuti home-currency yang dilekatkan pada tingkat Legal Entity yaitu Kompas Media Nusantara, PT.

Konteks (Context): Posisi suatu organisasi di dalam struktur menciptakan "konteks" pada organisasi tersebut. Contohnya: Legal Entity dari Gudang Barter pada gambar adalah Kompas Media Nusantara, PT. Konteks legal-entity tersebut diperoleh karena posisi Gudang Barter secara hirarkis yang ada di bawah Kompas Media Nusantara, PT.

Internal Organization Multiple-Roles: Internal Organization bisa menjalankan lebih dari satu peran (role) sekaligus. Peran-peran tersebut adalah sebagai Legal Entity, Company, Department, Revenue Center, Cost Center, Sales Organization, Purchasing Organization, Warehouse, dan Asset Center.

Organisasi Fungsional

Beberapa peran fungsional Internal Organization membutuhkan atribut informasi khusus yang tidak dimiliki oleh Internal Organization secara umum. Untuk itu diciptakan entitas-entitas organisasi baru yang merupakan keturunan dari Internal Organization. Di entitas turunan tersebut atribut-atribut informasi yang kurang bisa ditambahkan sesuai dengan peran fungsionalnya.

Entitas-entitas turunan dari Internal Organization adalah:

Sales Organization (SalesOrg)
Purchasing Organization (PurchasingOrg)
Warehouse
Asset Center

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

Customer: Customer adalah semua pihak yang melakukan transaksi pembelian dengan SalesOrg baik yang berasal dari luar (external parties) maupun yang berasal dari lingkungan KG (KGMedia) sendiri.; Dari kacamata keuangan, Customer adalah pihak yang menerima tagihan dari SalesOrg, yang tercantum di dalam A/R, yang membayar melalui Cash Counter atau Bank.

Customer adalah BP

Seluruh pihak (parties) yang terlibat dalam proses bisnis di Fina disebut Business Partner atau BP. Dalam pengertian tersebut Customer adalah BP juga.

Customer merupakan salah satu dari 5 jenis BP yang ada di Fina yaitu:

Internal Organization
Customer
Supplier
Bank
Employee (Cashier, Bank Admin, dll)

Customer di lingkungan Multi-System: Ada beragam sistem penjualan di KG (KGMedia khususnya). Masing-masing sistem tersebut mencatat customer-nya masing-masing. Customer yang sama bisa tercatat di 2 sistem yang berbeda dan mendapat nomor registrasi yang berbeda juga.; Lingkungan yang multi-system tersebut mendasari desain pengelolaan Customer di Fina. Data customer yang masuk dicatat sistem asalnya, lengkap dengan nomor referensi (unique number) di sistem asalnya. Dengan cara demikian Fina selalu dapat mengembalikan status transaksi customer ke sistem sistem asalnya.; Sebaliknya, sistem asalnya dapat mengambil informasi transaksi customer-nya langsung dari Fina melalui jalur API yang tersedia dengan menggunakan unique number dari sistemnya sendiri.; Desain yang demikian menyebabkan customer yang sama bisa tercatat beberapa kali di Fina karena berasal dari Application atau sistem sumber yang berbeda-beda.

BP = Single View of Customer: Beberapa Customer dapat "disatukan" dengan merujukkan Customer yang berbeda-beda tersebut ke satu BP. Dengan cara demikian prinsip single-view of customer tetap dapat dicapai. Tentu saja penyatuan ini butuh usaha dari para "admin" atau pengelola BP. Sebagai catatan, penyatuan data BP bukanlah syarat untuk melakukan transaksi di Fina.

Customer Registration: Customer dapat diinput secara manual dari layar customer yang tersedia. Melalui layar customer tersebut Customer dapat dirujukkan ke BP yang sudah ada atau membuat BP secara otomatis.; Registrasi Customer dengan cara export/ import perlu disepakati terlebih dahulu mekanismenya mengingat struktur informasi customer di masing-masing aplikasi berbeda-beda.

Kasir (Cashier): Cashier atau disebut kasir adalah karyawan yang bertugas menerima transaksi pembayaran tunai dari Customer. 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 menerima pembayaran dari Customer. 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 menerima transaksi pembayaran untuk semua 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

Penerimaan Pembayaran Customer: Transaksi kas yang terjadi di Cash Counter dicatat oleh Cashier menggunakan layar "Cash Transaction" yang di versi ini hanya dapat digunakan untuk mencatat penerimaan pembayaran (Payment Receipt) saja.; Item-item (tagihan-tagihan) yang akan dibayar 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

Aturan-Aturan Transaksi: 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 ke Edit List Pembayaran: Setelah transaksi tersimpan dan terverifikasi, Cashier dapat langsung memposting transaksi tersebut ke Payment List. 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.

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 Penerimaan Bank: Proses alokasi bank adalah proses memasangkan transaksi penerimaan bank dengan tagihan piutang penjualan (Invoice dan non-invoice).

Posting ke Edit List Pembayaran: Setelah alokasi tersimpan dan terverifikasi, Bank Admin dapat langsung memposting transaksi tersebut ke Payment List. 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.

Beberapa issue yang belum terkonfirmasi atau yang belum jelas masuk dalam scope atau tidak:

Timing posting pembayaran ke sistem asal
Mekanisme Bukti Kas masuk dan kaitannya dengan posting yang telah 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

Payment List

Payment List adalah sebuah tabel yang berisi seluruh transaksi penerimaan pembayaran dari Customer baik yang ditransfer ke Bank Account maupun yang dibayarkan langsung ke Cash Counter.

Melalui Payment List dapat dimonitor:

Tagihan (Invoice) yang dibayar oleh Customer
Jalur penerimaan: Cash Counter atau Bank Account
Nilai yang diterima
SalesOrg tujuan pembayaran
Application atau sistem asal yang menerima posting transaksi tersebut.

Masih perlu penjelasan lebih rinci, proses-proses di Payment List:

Posting ke Sistem Asal

Posting ke Application (sistem asal) dilakukan dari proses Bank dan proses Kasir. Jika posting ke sistem asal tidak berhasil dilakukan maka transaksi penerimaan pembayaran Customer tidak akan masuk ke Payment List.

Beberapa penyebab penerimaan pembayaran tidak berhasil diposting ke sistem asal:

Customer tidak ditemukan di sistem asal, bisa karena terhapus atau belum tersinkron sebelumnya.
Invoice tidak ditemukan di sistem asal, bisa terjadi karena kesalahan input nomor invoice saat penerimaan pembayaran (bisa terjadi di FastKom)
Periode yang akan dibayar sudah tertutup (bisa terjadi di SPSK).
Kegagalan teknis (jaringan putus, dll)

Pembuatan Bukti Kas

Proses pembuatan Bukti Kas adalah proses akhir hari untuk mengesahkan penerimaan pembayaran. Baris-baris alokasi penerimaan pembayaran di Payment List 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)

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
Elyada	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 Eliyada.
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 Eliyada.
Disepakati: Alokasi untuk sirda-sirda yang belum menggunakan FINA (masa transisi) dilakukan oleh tim Mas Eliyada. 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 Eliyada.

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?)

— WE WERE HERE —
Sutekno Dev.Team

FINA General Features

Version 3.0

Version 3.1

Version 2.0

Version 1.1

Version 1.0 (oldest)

DETAIL FEATURES:

FINA Financial System

FINA BP (Business Partner)

FINA Internal Organization

FINA Customer

FINA Cash Management

Cash Counter Management

Cash Transaction