Transaksi Importer & Rekonsiliasi
Dokumentasi ini mencakup pembaruan logika bisnis (Business Logic) terkait fungsi CSV Importer dan Reconciliation API pada sistem Penjualan GO.
1. CSV Importer Transaksi
Modul Importer bertugas untuk membaca (parsing) dan melakukan injeksi (batch upsert) ribuan data transaksi mitra dari file CSV ke dalam database secara efisien.
Penanganan Duplikasi Request ID (Update Terbaru)
Sistem kini memiliki lapisan proteksi (layer of protection) tambahan terhadap anomali data dari supplier. Pada kasus tertentu, supplier dapat menghasilkan request_id yang sama persis untuk dua transaksi yang berbeda apabila terjadi pada detik yang sama.
Untuk menghindari tabrakan (collision) pada Unique Index MySQL yang akan menyebabkan kegagalan upsert, sistem kini otomatis menggabungkan ( append) MSISDN ke dalam request_id:
// Format baru request ID
newReqID := fmt.Sprintf("%s_%s", *item.RequestID, *item.Msisdn)
Hal ini dijamin membuat identifikasi baris unik menjadi jauh lebih aman (bulletproof) ketika melakukan import data massal.
2. Laporan Ringkasan Rekonsiliasi (Summary By Date)
Fitur Rekonsiliasi membandingkan data transaksi internal (Server) dengan data yang tercatat di pihak supplier (NGRS) dalam rentang tanggal tertentu.
Pembaruan Logika Perhitungan Selisih
Algoritma perhitungan (aggregation) untuk rekonsiliasi harian telah ditingkatkan dengan menggunakan LEFT JOIN spesifik untuk akurasi yang lebih presisi, terutama untuk menyoroti Selisih secara terpisah:
- Total NGRS: Keseluruhan transaksi yang tercatat pada supplier (NGRS) di tanggal tersebut.
- Total Server: Keseluruhan transaksi di database internal di tanggal tersebut (transaksi
DEPOSIT_UNITdikecualikan). - Selisih NGRS: Transaksi yang ada di NGRS namun TIDAK ADA di Server. (Membantu mendeteksi transaksi supplier yang gagal masuk ke sistem lokal).
- Selisih Server: Transaksi yang ada di Server namun TIDAK ADA di NGRS. (Membantu mendeteksi transaksi lokal yang tidak diakui atau gagal di pihak supplier).
- Cocok (Matched): Transaksi yang sinkron (berhasil di kedua belah pihak), dihitung secara dinamis melalui formula:
Total Server-Selisih Server.
Melalui pendekatan agregasi ini, Admin Backoffice kini dapat langsung mengidentifikasi dari pihak mana bottleneck atau missing data terjadi pada laporan harian tanpa perlu mengecek raw data satu per satu.