Skip to content

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.


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


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_RatingtblT_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” di SV-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).

FULL MICROSERVICE (DB sendiri) — SPLIT (service) + PISAH DATA (database). Kandidat dengan bukti terbersih sejauh ini di antara semua yang sudah divalidasi ketat.