BOOTINGJRV//SYSTEMS/
OKAYA menjalankan perniagaan pengangkutan dan perdagangan di Malaysia. Apabila fasa terakhir MyInvois berkuat kuasa, masalah sebenar bukan API. Masalahnya ialah invois pengangkutan atas kertas tidak pernah membawa medan yang kini diperlukan LHDN, jadi tiada apa untuk dihantar walaupun klien penyerahan sudah wujud.
Naluri apabila e-invois diwajibkan ialah mencari klien API. Kami mulakan di tempat yang kurang menarik: apakah yang LHDN perlukan pada invois yang tidak pernah dibawa oleh invois pengangkutan, dan adakah OKAYA memiliki mana-mana daripadanya?
Jawapannya hampir tiada satu pun. Invois pengangkutan atas kertas membawa nama syarikat, alamat, perjalanan dan jumlah. Spesifikasi Invois v1.1 LHDN mahukan TIN pembeli, skim dan nombor pengenalan, pendaftaran SST jika ada, kod negeri, dan hubungan — medan yang tidak pernah muncul pada dokumen, dan oleh itu tidak pernah dikumpul semasa pelanggan didaftarkan.
Itu mengubah bentuk projek. Setiap laluan ke arah pematuhan melalui pintu yang sama, termasuk yang percuma: walaupun menaip invois ke portal LHDN secara manual memerlukan identiti pembeli. Jika data itu tiada, tiada kerja integrasi yang membantu. Jadi perkara pertama yang dibina bukan klien. Ia adalah senarai semak.
Setiap rekod pelanggan dinilai berbanding medan pembeli mandatori, dan skrin menjawab satu soalan bagi setiap firma: jika e-invois perlu dihantar untuk pelanggan ini esok, apakah yang masih kosong?
Dua keadaan sengaja dipisahkan. Medan kosong ialah kerja yang belum dibuat. Medan yang diisi tetapi salah format — TIN dengan bentuk yang salah, kod negeri yang tiada dalam senarai LHDN — ialah kerja yang dibuat secara salah. Kedua-duanya dibaca secara berbeza dan memerlukan perkataan berbeza, kerana orang yang melihat skrin perlu mengangkat telefon dan bertanya sesuatu yang khusus.
Peraturan diambil daripada spesifikasi medan rasmi LHDN, bukan andaian mengenainya. Satu had dinyatakan pada skrin itu sendiri: TIN dengan bentuk yang betul masih boleh menjadi TIN yang salah. Hanya LHDN boleh mengesahkannya semasa penyerahan. Semakan jurang memberitahu apa yang hilang, bukan apa yang benar.
Separuh kedua kesediaan ialah dari mana invois itu datang. Dalam sistem OKAYA, ia dijana daripada perjalanan belum dibil — rekod operasi adalah sumbernya, dan invois diterbitkan daripadanya, bukan disusun secara manual dalam pakej berasingan.
Ini lebih penting untuk pematuhan daripada yang kelihatan. Apabila invois ditaip semula antara sistem, dua perkara boleh menyimpang: angka, dan set invois yang wujud secara keseluruhan. Invois yang wujud atas kertas tetapi tiada dalam mana-mana sistem tidak kelihatan sehingga seseorang menyesuaikan yang dibukukan dengan yang disahkan, dan pada masa itu ia sudah menjadi masalah lampau, bukan masalah semasa.
Tujuh modul berjalan secara langsung pada lejar yang sama, jadi perjalanan, invois dan catatan perakaunan adalah tiga paparan bagi satu rekod, bukan tiga rekod berasingan yang perlu dipadankan.
Sistem ini tidak menyerah ke MyInvois. Tiada klien API, tiada OAuth, tiada tandatangan XAdES dan tiada kod QR, dan tiada satu pun daripadanya boleh dibina secara bertanggungjawab sehingga OKAYA memegang pendaftaran ERP dengan LHDN dan sijil digital daripada CA berlesen Malaysia. Membina klien penyerahan berdasarkan kelayakan yang belum wujud hanya menghasilkan kod yang tiada siapa boleh uji.
Sebaliknya, ia mengeksport sebahagian lejar semasa sebagai buku kerja kelompok LHDN sendiri, untuk dimuat naik. Eksport itu tidak berlagak naif: minta ia semak dahulu dan ia menjawab berapa banyak invois akan dihantar, yang mana ditahan, dan apa yang masih kurang bagi setiap satu. Soalan itu ditanya sebelum muat turun, kerana alternatifnya ialah fail yang ditolak LHDN sejam kemudian dengan nombor baris, bukan nama pelanggan.
Apabila pendaftaran dan sijil sudah tersedia, klien penyerahan hanyalah tambahan yang jelas di atas data yang sudah betul. Itulah susunan kerja yang sepatutnya, dan ia adalah kebalikan daripada cara kebanyakan projek e-invois dijual.
Betulkan pengumpulan data di sumber sebelum membina apa-apa di peringkat hiliran. Langkah yang tidak glamor — mendapatkan TIN pembeli, pendaftaran SST dan kod klasifikasi dikumpul semasa pelanggan didaftarkan, bukan dikejar pada penghujung bulan — adalah yang menentukan sama ada segala-galanya selepasnya berfungsi.
Nyatakan had pada skrin, bukan dalam nota kaki. Alat pematuhan yang melebih-lebihkan kepastiannya sendiri lebih buruk daripada hamparan, kerana orang akan berhenti menyemaknya.
