Integrasi ERP dengan sistem pajak sering menyentuh database internal dan API eksternal dalam satu proses. Solusi yang aman tidak mengharuskan database ERP menjadi publik. Yang diperlukan adalah komponen terotorisasi di dekat ERP, kontrak data yang ditinjau, dan pemanggilan API pajak sesuai dokumentasi serta credential environment tujuan.
Mulai dari kewenangan setiap sistem
ERP biasanya menjadi sumber transaksi komersial, master pelanggan, item, dan jurnal sesuai desain instalasinya. Sistem pajak memiliki kontrak API, validasi, status, dan kewenangan resmi yang berbeda. Workflow integrasi menerjemahkan dan mengorkestrasi, tetapi tidak boleh menciptakan keputusan pajak yang tidak disetujui pemilik proses atau menggantikan validasi sistem resmi.
Tentukan data mana yang boleh dibaca, peristiwa apa yang memicu pengiriman, siapa menyetujui dokumen, serta status apa yang ditulis kembali. Pada SAP HANA atau SAP Business One, nama tabel dan field dapat bergantung versi, add-on, serta kustomisasi. Inspeksi schema runtime dan review oleh pihak yang memahami instalasi wajib dilakukan; direct write ke tabel inti ERP sebaiknya dihindari bila API/service layer resmi tersedia.
Pola arsitektur tanpa database publik
Tempatkan agent pada jaringan yang memiliki akses sah ke ERP. Agent membuat koneksi keluar yang terkelola ke Core dan mengeksekusi pembacaan atau tindakan dari boundary jaringan tersebut. Core mengatur workflow dan status, sedangkan credential database tetap pada environment agent. Panggilan API sistem pajak juga dilakukan melalui agent yang dipilih sesuai kebutuhan jaringan.
Firewall, DNS, proxy, TLS, dan allowlist tetap perlu dikonfigurasi oleh operator. Agent-centric mengurangi kebutuhan inbound langsung ke database; ia bukan alasan melewati kontrol jaringan atau memberikan hak database lebih luas dari yang diperlukan.
Binding schema dan API harus eksplisit
| Boundary | Yang harus diverifikasi | Bukti |
|---|---|---|
| ERP | Tabel/view/API, tipe, key, timezone, decimal | Schema runtime dan sampel aman |
| Mapping | Arti field, default, pembulatan, referensi | Mapping yang disetujui owner |
| API pajak | Endpoint, versi, auth, payload, status, quota | Dokumentasi resmi environment |
| Respons | ID eksternal, validasi, rejection, retryability | Contract test Sandbox |
Jangan menebak kode pajak, pembulatan, identitas, atau aturan dokumen. Gunakan tipe desimal presisi untuk nilai uang dan tetapkan aturan timezone. Perubahan kontrak harus melalui review serta regression test. Contoh payload tidak membuktikan seluruh kasus; sertakan nilai kosong, multi-item, koreksi, pembatalan, dan batas yang diizinkan API.
Rancang retry bersama idempotensi dan rekonsiliasi
API eksternal tidak berada dalam transaksi ACID database ERP. Jika request berhasil tetapi respons hilang, retry dapat membuat dokumen ganda kecuali API menyediakan idempotency key atau query status yang andal. Gunakan correlation ID stabil, simpan referensi request–response, klasifikasikan error sementara dan permanen, serta lakukan login ulang hanya sesuai kontrak autentikasi.
- Ekstrak kandidat.
Baca hanya record yang memenuhi status dan watermark terverifikasi.
- Validasi.
Tolak atau arahkan review untuk kontrak, nilai, dan referensi yang tidak lengkap.
- Kirim idempoten.
Gunakan key stabil bila didukung dan simpan correlation.
- Catat hasil.
Simpan ID/status eksternal melalui API atau tabel integrasi yang aman, bukan direct write sembarang.
- Rekonsiliasi.
Bandingkan status kedua sisi dan eskalasi perbedaan yang tidak aman diotomatisasi.
Checklist keamanan dan tata kelola
- Gunakan akun read-only untuk ekstraksi bila penulisan ERP tidak diperlukan.
- Simpan secret database dan API pada boundary agent serta rotasi secara terencana.
- Redaksi NPWP/identitas, token, dan data sensitif dari log, trace, dan sampel.
- Pisahkan Sandbox dan Production berikut credential, endpoint, serta datanya.
- Terapkan approval manusia untuk penerbitan atau koreksi yang memerlukan kewenangan.
- Uji backup, replay, rekonsiliasi, dan prosedur saat API eksternal tidak tersedia.
Menyusun blueprint di NitroNet
Versioning perlu mencakup tiga hal: versi mapping internal, versi schema ERP yang telah diverifikasi, dan versi kontrak API tujuan. Simpan ketiganya pada catatan release agar hasil dapat dijelaskan ketika salah satu pihak berubah. Untuk perubahan tanpa backward compatibility, siapkan periode transisi, data uji yang disetujui, dan rollback yang tidak menghapus bukti transaksi yang sudah diterima sistem eksternal.
Blueprint dapat memakai Jadwal atau Terima Data, Baca DB melalui agent ERP, validasi dan mapping, Untuk Setiap item bila diperlukan, Panggil API dalam mode tunggu, lalu percabangan Respons atau Tangkap Error. Simpan hasil pada tujuan yang disetujui. NitroNet menyediakan building block tersebut, tetapi kesiapan tiap ERP dan API pajak harus dibuktikan melalui binding aktual dan credential Sandbox pemilik.
Mulai dari satu jenis dokumen dan satu jalur koreksi, lakukan parallel reconciliation, lalu perluas setelah owner finance/pajak menyetujui hasil. Baca arsitektur agent-centric dan pola invoice header–item. NitroNet membantu mengorkestrasi boundary; ia tidak mengklaim connector pajak universal atau kewenangan menentukan kepatuhan.