Assalamu alaykum .. semua… hehehe … ngeliat judulnye…. bukan berarti bahwa ISO 8583 ini dari dan buatan nye Dir jend pajak ya… hanya… memang transaksi terbaru untuk mempermudah alur transaksi antara kebutuhan pajak dengan nasabah…
Lebih gambalang nye bahwa.. ini merupakan Proyek untuk melakukan integrasi dan pertukaran data antara nasabah si bank, Bea dan Cukai dan Ditjen Pajak. Proyek ini sebenernya di subkan ke seseorang yang katanya ngerti sistem perbankan, setiap kana di operasionalkan aplikasi tersebut mesti harus di lakukan UAT (User Acceptance Test).
Proses bisnis diawali pengiriman data pajak-pajak impor yang biasanya dilakukan oleh si nasabah secara manual berganti secara elektronik, kita sebut saja dengan nama Payment Order (PAYORD). Nah, PAYORD ini biasanya tidak dilakukan secara langsung oleh si nasabah yang notabene adalah importir namun diuruskan oleh PPJK. Masalahnya antara importir dan PPJK sering terjadi miss communication. Sekarang maunya importir juga bisa mengetahui alur proses data yang diuruskan oleh PPJK dan bank. Ok, maunya si importir kita akomodasi dah.
Kebutuhan yang lain di sisi bank. Bank pengennya, data PAYORD yang di kirimkan ke dia bisa langsung di pecah menjadi data SSP (Surat Setoran Pajak — dikirim ke DJP) dan SSPCP (Surat Setoran Pajak, Cukai dan Pabean — dikirim ke BC). Ok, clear deh semua user requestnya.
Kebetulan ikut team programing development dan UAT utk aplikasi gateway server switching pajak … jadi mau gak mau di tuntut utk paham ISO 8583 dirjen pajak nya… Jadi aku mo cerita yang sistem pengiriman data ke Pajak aja…
Ditjen Pajak telah mengimplementasikan sistem MP3 (bukan file musik ya…) yaitu sistem untuk memonitor pemberitahuan pembayaran pajak yang dilakukan oleh bank-bank devisa persepsi yang menerima pembayaran pajak-pajak. Sistem ini mengunakan metode request-respon dengan standar dokumen ISO8583 yaitu sebuah standar dokumen untuk pertukaran data keuangan secara real time. Bentuk data-nya sederhana dan hampir semua berisi data numerik. Biasanya dokumen ini digunakan di mesin-mesin ATM. Ini hal baru man buat aku, biasanya ngertinya cuman standar UN-EDIFACT doang… heheh
Ditjen Pajak mengeluarkan panduan implementasinya. Pada intinya data yang dikirimkan terbagi menjadi data Financial Transaction (kode pengenalnya 02xx), Reversal (pembatalan transaksi– kode pengenalnya 04xx) dan Network Management (kode 08xx). Setiap dokumen request yang dikirim akan mendapatkan respon dengan tambahan nilai 10. Jadi misalnya request Network Management dengan kode 0800 maka akan dibalas dengan respon 0810, 0200 dibalas dengan 0210 dan seterusnya. Hasil akhir yang ingin dicapai sebenernya sih penerbitan respon NTPP (Nomor Tanda Pembayaran Pajak).
Komponen paket data ISO8583-MP3 terdiri dari Data Start (ISO), MP3 Header (011000017), kode pengenal paket data (08xx/02xx/ 04xx), Primary/Secondary Bitmap (64 bit) dan isi dari data sendiri (data element). Data elementnya dan secondari bitmapnya sendiri diatur kemunculan di primary bitmap.. <– apa pula nech hahaha… Header data sendiri juga ada penjelasnya lengkap, namun nggak perlu aku uraikan disini karena nggak ngaruh (kebanyakan di hardcode aja..bukan variabel data) hahaha…
Element data disimbolkan dengan P-x. Jadi misalnya di primary bitmap request disebutkan sbb.
0111001000111000010000000000000100001000100000011000000000000000
Artinya element data yang harus muncul setelah primari bitmap adalah di bit 2, 3, 4, 7, 11, 12, 13, 18, 32, 37, 41, 48 dan 49. Ambil contoh yang muncul bit 2 (P-2), berdasarkan panduan P-2 artinya adalah Primary Account Number yang di representasikan oleh numerik sepanjang 16 digit. Atau ambil contoh lagi bit 3 (P-3), berdasarkan panduan berarti kemnculan elemen data Processing Code yang direpresentasikan oleh nilai numerik 6 digit berisi kode dan jenis transaksi yaitu 200000 (pembayaran SSP), 300000 (inquiry) dan 200001 (pembayaran SSP tanpa NPWP). Okeh cukup khan..?? Masalahnya kalo dicontohkan semua panjang nech… bisa jadi novel! 
Jadi paket data lengkap yang dikirimkan menjadi (ini hanya contoh — sengaja aku pecah per bit, aslinya sih cuman satu baris aja..)
ISO
011000017
0200
0111001000111000010000000000000100001000100000011000000000000000
160000000000015228
200000
000000010000
0611084115
123456
100221
0520
7010
040305
000000000001
0000000000000001
0460100111610530000011110002022002000000000000000
360
Setelah melakukan request, sistem inhouse MP3-Pajak akan langsung mengeluarkan respon yang diletakkan di bit ke-39, maka primary bit response biasanya sbb :
0111001000111000010000000000000100001010100000011000000000000000
Lihat di bit 39 bernilai “1″ artinya element data di response akan ada kemunculan bit-39 (P-39) yang direpresentasikan oleh numerik sepanjang 2 digit. Contoh respon sbb.
ISO
011000017
0210
0111001000111000010000000000000100001010100000011000000000000000
160000000000015228
300000
000000010000
0611084115
123456
100221
0520
7010
04 0305
000000000001
00 <– bit 39
0000000000000001
160CITI BANK N.A. LANDMARK CENTER LT.4 JL.JEND. SUDIRMAN KAV.1 – SETIA BUDI PPh Pasal
21 Masa / Angsuran
360
Lihat! Di bit ke-39 bernilai “00″ artinya pengiriman data kita di approve/sukses.
namun untuk bit 39 ini .. berbeda antara kebutuhan pajak dengan kebutuhan transaksi perbankan lain nya.. seperti atm dan mobile banking…
Hebatnya lagi sistem ini, jika pada saat komunikasi data terdapat kegagalan, maka kita diperbolehkan mengirimkan data advice dengan menyebutkan alasan pengiriman data advice tersebut, misalnya karena time-out atau hal lain yang diletakan di bit ke-60.
unutk lambat laun aplikasi yang gw hadepin .. aplikasi under server … palikasi ini lebih simple di banding aplikasi switchig lainnya … namun dari sisi lain aplikasi under client yang sedang dilakukan maintenance terus menerus (kelihatannya gak kelar2 tuh) nah ini yang buat masalh hingga setiap reconsiliasi harus terjadi update-an manual… dengan saat2 yang menegangkan tiap sore harinya … cut off.. cut off… pelimpahan… pelimpahan… hehehehe… parah neh.. mudah2an cepet kelar maintenance aplikasinya..
DIarsipkan di bawah: ENTERPRISE, my JOB | Ditandai: dirjen pajak, ISO 8583, pajak
Assalamualaikum Wr. Wb pas Sang,
Yang di Client aplikasinya gimana pak, apa prosedurnya:
Entry (mis NPWP dll) terus dirubah jadi format ISO-8583 baru dikirim ke Server…..dan server njawab request tersebut gitu…?
Bagi-bagi ya, trim
Wiend
wa alaykumussalam warohmatulloh….
alur ISO 8583 nya secara garis besar yangs saya pahami seperti ini …
aplikasi klient sebenernya aplikasi pembukuan input /semacam entry transaksi .. dari apliakasi client tersebut setelah di proses sesuai dengan proses bisnis nya di sisi client . baru data2 yang di inputkan tadi di lempar ke gateway application server.. (atau di sini aplikasi yang saya pegang aplikasi switching server )..
pelemparan menggunakan tipe data yang kemudian di koversi sesuai dengan format ISO 8583
dan kemudian setelah mampir sebentar dari aplikasi gateway server itu , baru di lempar ke pajak…dari sisi DJP pajak membacanya meggunaka ISO 8583 yang telah sesuaikan menurut ketentuan Dirjend pajaknya… baru dari server pajak bisa memposting hasil secara keseluruhan yang di dapat dari bank2 tersebut.
komunikasi dari sisi aplikasi client menuju aplikasi gateway server membutuhkan waktu yang ckup lama dan pekerjaan yang rumit…. entah yang disebut dengan pelimpahan dan sebagai nya untuk menselarasakan hasil yang di dapat dari sisi pembukuan aplikasi client.
aplikasi gateway harus bisa menampung hal tersebut. proses transaksi secara teknis memang seperti biasanya , ada request pasti di balas dengan respon, namun yang membutuhkan penangan dan pemahaman lebih adalah permodelan format ISO 8583.. baik itu tipe MTI nya , bit- bitnya utk penanggalan, dan yang penting di baca seorang admin adalah error code nya .. hehehe.. biar lebih mudah memahami messaging nya… klo dlihat dari sisi programmer dari sisi messaging ISO 8583 yang di convert itulah yang kemudian menjadi kan patokan harus terkirim type datanya dengan melalui berbagai modul2 fungsi sistem…
seringnya aplikasi server pajak di sebut sebagai aplikasi sispen terpadu..yang berkomunikasi dengan sistem host client menggunakan protokol komunikasi TCP/IP.
——- UNEK-UNEK gw —————–
inilah salah satu fungsi IT bisa menjembatani kebutuhan , menjadikan efektifitas dan efisiensi kerja.. salah satu tujuannya agar tidak terjadi peng-korupsian di dalam sistem pembayaran pajak… (masak sih .. ?/??? .. walau memang sebenrnya masih bisa dan sering terjadi peluang seperti itu .. mungkin ya..).. ..
mungkin ada yang bertanya…
jikalau masih ada celah untuk korupsi di mananya sih? bukannya pelaporan sudah langsung ke dirjenpajak?
jawabannya mungkin.. ya.. (soalnya belom begitu paham sih…– mudah2an saja ada yang berkenan mengangkat isu tersebut ke atas…) .. ya bisa jadi terjadi hal2 yangtidak di iniginkan.. semisal… kita coba lihat sistem pelaporan ke pajak ya… pelimpahan dari bank (bank sbagai tempat pembayran pajak oleh nasabah ) sudah di lakukan baik melalui sistem komputerisasi atau manual… sekian puluh trilyun dalam bulanan… (bisa jadi sebanyak itu.. karena pengalaman nih… transaksi pelimpahan dari satu bank saja , dalam satu hari bisa mencapai milyaran .sepertinya)..
..
nah dari situ pelaporan manual bulanan di lakukan.. dan justru disinilah celah2nya…
semisal : dari sisi bank melaporkan dalam jumlah Xmilyar rupiah , namun dari sisi pajak ternyata mengkalkulasikan sebesar Ymilyar rupiah , yang ternyata nilai Y milyar rupiah jumlahnya jauh di bawah dari X , katakanlah Y = (-y% (X)) bacanya .. hehe nilai Y sudah di kurangi bebrapa persennya dari nilai X .
dari sinilah persetujuan dari pelapor dan yang menerima laporan di uji moralnya… begitu juga moralnya sistem yang menerima laporan….entah dengan berbagai macam alasan..
bisa saja dari pihak bank yang gak mau ambil pusing mensetujui hal tersebut dengan tinggal tanda tangan dan
beres masalah pekerjaan .. dan memang kerugian nya tidak di tanggung bank sebagai pihak pelapor..
kalau sudah seperti ini mau di bilang apa? kerugian negara semakin bertambah besar… trilyunan rupiah yang di bayarkan nasabah sebagai bea pajak sudah terhitung hangus… jadi apa mau di kata…
– hanya sekedar unek-unek gw.. dari berbagai informasi dan sistem pengalaman kerja gw…
Terima kasih banyak Pak Sang, soal uneg-unegnya, he he he lumayanlah ada selangkah lebih maju dengan ’semi otomatisasi’. Langkah berikutnya tinggal kita tunggu aja transparasi informasi yang memang untuk public. Jadi masyarakat bisa mengkompare Penerima Pembayaran (Bank) dengan Hostnya. Jadi bagi khalayak yang suka ‘ngutak-atik’ bisa menganalisa sendiri variable sampean yang :
Y = (-y% (X)).
Selanjutnya…?????? teu’ nyaho’, emboh, mau diapain.
Sekali lagi terims atas bagi-bagi pengalamannya.