Angka 64.000.000 di contoh resmi itu tidak pernah dibayar siapa pun

Selama kira-kira 3 minggu saya mengira angka 64.000.000 itu angka sungguhan. Angka itu ada di dalam sebuah berkas XML yang dibagikan sebagai contoh resmi untuk formulir tahunan. Kalau dibuka, seluruh elemen formulir berjajar rapi menurut urutannya, dan di dalamnya terisi angka-angka yang tampak seperti nominal sebenarnya. Inilah wujud pelaporan yang sesungguhnya, begitu kami membacanya.

Saya tulis seberapa dalam hal itu sudah masuk. Kami punya tabel spesifikasi, 1 baris untuk 1 kolom, yang menuliskan apa yang harus diisikan ke setiap kolom formulir. 17 baris dari tabel itu menyebut nama berkas ini sebagai sumbernya. Berkas contoh yang kami pakai untuk pengujian pun salinan dari contoh itu, hanya nominalnya yang diganti. Artinya, yang menentukan keluaran kami benar atau tidak adalah berkas ini.

Saya menemukannya secara kebetulan. Saya ingin memeriksa soal pengodean karakter, jadi berkas itu saya buka apa adanya di editor teks. Di bagian paling atas ada 1 baris komentar. Tertulis: Created with Liquid Technologies. Agak ke bawah, kolom nomor pajaknya berisi huruf x sebanyak 16 buah berderet. Kalau diteruskan, kolom-kolom yang sifatnya opsional pun terisi semua, dan setiap kolom teks panjangnya persis sepanjang batas maksimum yang diizinkan skema.

Jadi berkas itu adalah contoh yang dibuat mesin secara otomatis dari skema (XSD). Nama elemen, urutannya, bentuk sarangnya, mana yang wajib dan mana yang opsional — soal bentuk, ketepatannya tidak ada tandingannya. Sebaliknya, nilai yang ada di dalamnya adalah nilai yang ditaruh mesin untuk mengisi kolom bertipe itu. Tidak ada orang yang membayar 64.000.000. Tidak ada kantor pajak yang pernah menerimanya.

Saya tulis apa yang terjadi. Karena di contoh itu bagian yang opsional pun ikut terisi, kami mengeluarkan bagian tersebut setiap kali, tanpa peduli syaratnya. Coretax yang sebenarnya tidak menerima berkas yang membawa bagian itu. Waktu pertama kali ditolak, kira-kira 4 hari kami habiskan mencari-cari di dalam kode kami sendiri. Bentuk keluaran kami tidak berbeda 1 huruf pun dari contoh itu, jadi penyebabnya pasti ada di tempat lain di pihak kami. Bahwa justru premisnya yang keliru, sama sekali tidak terpikir.

Saya bertanya kepada V. Dia akuntan di Jakarta yang menguji KAZENA Books dengan data nyata dari kantornya sendiri. Ketika saya tanya apakah isi formulir tahunan yang benar-benar dilaporkan berbentuk seperti ini, dia membuka berkas yang pernah dilaporkan kantornya dan memberi tahu saya elemen apa saja yang ada dan yang tidak ada di dalamnya. Bagian yang menjadi masalah itu memang tidak pernah ada. Apa yang tidak saya pahami selama 3 minggu membaca contoh, dijawab sekali jalan oleh dokumen yang nyata.

Saya tulis aturan yang kami tetapkan. Setiap baris di tabel spesifikasi harus memuat sumbernya, beserta derajat sumber itu. Derajatnya ada 4. Pertama, barang nyata — berkas yang benar-benar dikeluarkan atau diterima oleh sistem aslinya. Kedua, konfirmasi orang — seseorang yang mengerjakannya sehari-hari memastikannya di layar sungguhan, lengkap dengan tanggal pemeriksaannya. Ketiga, bunyi peraturan, atau skemanya sendiri. Keempat, contoh buatan mesin dan dugaan kami sendiri. Lalu kami putuskan: perilaku yang hanya bersandar pada derajat keempat tidak boleh masuk ke produk secara diam-diam.

Dengan aturan itu, 17 baris tadi kami telusuri ulang. 6 baris tergantikan oleh barang nyata. 5 baris terbukti lewat bunyi peraturan. 4 baris terisi oleh konfirmasi V. Sisanya, 2 baris, tidak punya sumber di mana pun. Artinya tidak ada alasan lain selain karena contoh itu menuliskannya demikian. Perilaku yang ditopang 2 baris tersebut kami cabut dari produk.

Kata resmi bekerja keras sekali di sini. Karena berkasnya dibagikan secara resmi, maka sampai 1 bita di dalamnya pun pasti resmi — begitu kami membacanya. Yang benar-benar resmi adalah skema yang diikuti berkas itu. Angka-angka di dalamnya hanyalah hiasan yang ditaruh untuk menjelaskan skema. Yang salah bukan contohnya. Yang salah adalah kami, yang tidak membaca contoh sebagai contoh.

Sisi produknya juga kami betulkan. Dulu, kalau ada isian yang kurang, kami hanya menulis: kolom ini wajib diisi. Sekarang alasannya kami pisahkan. Kolom yang memang ditetapkan wajib oleh skema, dan kolom yang pernah membuat pelaporan ditolak karena dikosongkan, adalah 2 kalimat yang berbeda. Berkas contoh untuk pengujian pun bukan lagi salinan contoh resmi, melainkan berangkat dari berkas yang sungguh-sungguh diterima sistem. Nomor-nomornya sudah diganti menjadi bentuk yang jelas-jelas karangan, misalnya angka 9 sebanyak 16 digit. Kami tidak ingin menyimpan nomor sungguhan di dalam pengujian kami.

Kepada siapa pun yang sedang membangun sesuatu agar cocok dengan sistem pemerintah, ada 1 hal yang ingin saya sampaikan. Pastikan siapa yang membuat angka yang sedang Anda andalkan. Nilai yang ditaruh mesin ke dalam skema, nilai yang tercetak di dokumen panduan, nilai yang dijawab seorang praktisi dari ingatannya, dan berkas yang dikeluarkan oleh sistem itu sendiri — di layar, keempatnya berwajah sama. Huruf hitam yang sama, jumlah digit yang sama. Bedanya hanya seberapa jauh Anda harus mundur untuk membetulkan keadaan kalau salah satunya ternyata meleset.

Untuk berjaga-jaga saya tuliskan: saya bukan konsultan pajak. Apa yang harus ditulis di formulir tahunan dan kolom mana yang wajib diisi ditentukan di sisi peraturan, dan itu berubah dari waktu ke waktu. Yang saya tulis di sini adalah catatan tentang kami yang salah memperlakukan dasar rujukan. Untuk keputusan pelaporan yang sebenarnya, mohon selalu dipastikan kepada ahlinya.

Terakhir, ada satu permintaan. Kalau di layar KAZENA ada kolom yang tertulis wajib tetapi Anda tidak paham alasannya, tolong beri tahu kami. Ada kemungkinan dasar rujukan kami untuk kolom itu masih berhenti di derajat keempat. Derajat dasar rujukan tidak terlihat oleh pemakainya. Menjaga agar yang tidak terlihat itu tetap benar adalah tugas kami.