Billing Service — Scorecard Kajian
DB-08 · SV-08 — 7 tabel (4 transaksi + 2 lookup ⚠️ + 1 scheduler). Diagram: Helicopter View · Detail SV-08/DB-08.
Fitur: 12 fitur (Get SO/Billing Credit, Simulate/Pay Open Billing, Get Bank, Get Booking Detail, Get/Cancel Credit Payment Status, Create Rating, Upload Evidence, Generate PDF, Scheduler auto-cancel)
✅ Scorecard divalidasi penuh (2026-07-28) — kandidat pertama dari kelompok SV-08..SV-13 yang divalidasi ketat, bukan cuma klaim placeholder, pola sama SV-01..SV-07. Bukti terbersih sejauh ini: 0 folder admin kompetitor, 0 kebutuhan ACID lintas domain, 0 FK fisik lintas domain.
Scorecard Service (maks 16)
Section titled “Scorecard Service (maks 16)”| Kode | Kriteria | Skor | Bukti / Alasan |
|---|---|---|---|
| J1 | Independent Deployability | 2 | Controller sendiri (OpenBillingCreditController, area V2) — 0 referensi silang dengan folder Payment (beda dari SV-04 yang F01/F02-nya tertanam di PaymentCommandHandler). |
| J2 | Independent Scalability | 1 | Tidak ada data APM riil, sama seperti kandidat lain. F02/F03 panggil SAP WSDL live per request, I/O-bound — argumen kualitatif tanpa angka traffic pasti. |
| J3 | Fault Isolation (blast radius) | 2 | F5 Failure Test: 0 dependency dari Payment/Booking Order ke SV-08 — kalau service ini mati, checkout & booking tetap jalan normal. |
| J4 | Team Ownership (Conway) | 1 | Ditanya langsung ke user — tidak ada testimoni tim terpisah, default skor lemah sama pola service lain. |
| J5 | Technology Divergence | 0 | Tidak ada kebutuhan runtime/stack berbeda. |
| J6 | Bounded Context (DDD) | 2 | 15 handler pure IStoreprocedureCall, 0 folder admin — domain “bayar AR di luar SO” jelas beda dari Checkout. DDD juga memecah BC-11 Billing dari BC-5 lama secara independen, sejalan dengan SV-08 yang sudah ditentukan lebih dulu. |
| J7 | Compliance / Security Isolation | 1 | Data finansial AR sensitif, tapi tidak ada bukti isolasi implementasi khusus (auth/enkripsi sama seperti domain lain). File evidence bukti bayar disimpan di UNC network share, bukan disk lokal per-pod — aman dari risiko multi-pod, tapi bukan bukti compliance khusus. |
| J8 | Independent Lifecycle Data | 2 | Scheduler auto-cancel sendiri (3 hari) — lifecycle PaymentCode independen dari Booking Order. |
| TOTAL | 11 / 16 |
Hard Blocker: HB1 = Tidak · HB2 = Tidak · HB3 = Tidak Keputusan: ✅ SPLIT
Scorecard Database (maks 14)
Section titled “Scorecard Database (maks 14)”| Kode | Kriteria | Skor | Bukti / Alasan |
|---|---|---|---|
| DB1 | Independensi Transaksi | 2 | Pola “SP kembar” ditelusuri (lihat catatan di bawah) — tidak ada transaksi ACID lintas domain seperti ditemukan di SV-02/SV-03 (RetryCreateSODO). Benar-benar bersih. |
| DB2 | Independensi Foreign Key | 2 | 0 FK fisik lintas-domain (cuma FK internal tblT_OpenBillingCredit_Rating→tblT_OpenBillingCredit). Baca KNA1/Sales_Org/Bank murni app-level tanpa constraint. |
| DB3 | Kohesi Aggregate | 2 | 4 tabel transaksi (header/detail/CRDR/rating) = satu aggregate utuh per PaymentCode. |
| DB4 | Single Writer | 2 | 4 tabel transaksi single-writer jelas. ⚠️ 2 tabel lookup (tblM_CreditPaymentType/tblM_CreditPaymentStatus_Locale) tetap tanpa jalur tulis terverifikasi (kemungkinan seed data statis) — tidak diturunkan karena tidak ada bukti multi-writer. |
| DB5 | Master Data / Sync | 2 | Bukan shared/master data — murni transaksional domain sendiri. |
| DB6 | Independensi Reporting | 2 | 0 SP populate/dashboard yang JOIN tabel SV-08. ⚠️ sp_BankService_TransactionData_Get (JOIN mentah lintas 4 domain) ditemukan tanpa caller terverifikasi — dicatat sebagai risiko potensial (lihat catatan), tidak mengurangi skor. |
| DB7 | Stabilitas Skema (co-change) | 1 | 0 migrasi EF Core untuk tabel SV-08 — tabel legacy pra-EF, dibuat lewat SQL script langsung, cuma muncul di model snapshot. Proxy co-change lewat migrasi tidak bisa diterapkan di sini, beda dari domain lain yang riwayat migrasinya bisa dicek langsung. |
| TOTAL | 13 / 14 |
Hard Blocker: DHB1 = Tidak · DHB2 = Tidak Keputusan: ✅ PISAH DATA
Temuan tambahan (sesi validasi 2026-07-28)
Section titled “Temuan tambahan (sesi validasi 2026-07-28)”- 13 SP “kembar” tanpa prefix
stp_cus_(sp_OpenBillingCredit_Save/_Update_Status/_Update_Payment/_Update_BankCodeNote/_Cancel_PaymentCode,sp_Load_OpenBillingCreditDetail_By_SoldTo(_Testing),sp_Load_OpenBillingCreditStatus_By_CrDr/_By_InvoiceNo,sp_Load_PaymentCode_By_*,sp_Credit_Debit_Note_*,sp_Check_Debit_Credit_Used) — pola nama mirip temuan “SP kembar” diSV-02/SV-03(yang ternyata aktif dipanggil Admin), TAPI di sini 0 caller ditemukan di seluruh kode. User menyatakan ini dead code — ditutup, bukan pelanggaran. sp_BankService_TransactionData_Get— SP pelaporan generik (@Transaction: 1=Booking Order, 2=Payment Code Kredit, 3=VA TopUp/Saldo, 4=E-Voucher) yang JOIN tabel mentah 4 domain sekaligus. 0 caller di kode C#. User tidak yakin statusnya — dicatat sebagai Q22, berpotensi jadi temuan DB6 nyata lintas 4 domain kalau ternyata dipakai sistem eksternal (mis. rekonsiliasi Bank).
Rekomendasi Akhir
Section titled “Rekomendasi Akhir”FULL MICROSERVICE (DB sendiri) — SPLIT (service) + PISAH DATA (database). Kandidat dengan bukti terbersih sejauh ini di antara semua yang sudah divalidasi ketat.