MDR Report Summary

Kode report: mdr_report_summary, berlabel "MDR Report Sumary" di menu (typo seed). Membuka mode cetak documents_master dengan type=mdr_report_summary; handler-nya documents_mater_handler_print_mdr_report_summary.php (perhatikan mater di nama file), 1.011 baris, sepenuhnya memakai $pdo. Satu baris per discipline berisi hitungan: berapa dokumen MDR yang ada, berapa yang sudah di-issue di tiap status, berapa yang masih under review, dan berapa yang membawa tiap return code. Kalau MDR Report menjumlahkan progress berbobot, yang ini menghitung dokumen.

Cara halaman ini diverifikasi

Ditelusuri di master pada 2026-09-06 dan dibandingkan dengan big five dan KTP. Screenshot dari inact-ktp.eris.place pada snapshot produksi KTP, project SNS. Salinan KTP berbeda 311 baris; lihat perbedaan antar instance.

Form filter

MDR Report Summary, form filter · click to enlarge

Project, jendela Actual Date (actual_date_from, actual_date_to, d/m/Y), dan Preview atau Excel (mdr_report_summary_download_as). Tidak ada filter field. Berbeda dengan MDR Report, jendela tanggal di sini memfilter baris library yang dihitung: menjadi d.doc_send_received BETWEEN ... (atau >= / <= kalau satu sisi kosong) di kedua query dokumen. Baris judul "Actual Date from ... to ..." menampilkan jendelanya, atau doc_send_received paling awal dan paling akhir di project kalau jendela kosong.

Empat query-nya

1. Daftar referensi: discipline (ts_docdiscipline, dikunci docdisc_id), return code (ts_doc_resultcode, urut doc_res_sort), issued status (ts_issued_status urut ts_progress_gate.sequence, dikunci issued_id).
2. MDR: setiap baris ts_documents_master project, di-join ke discipline-nya lewat dm_discipline_identifier = docdisc_code, dan dikelompokkan per docdisc_id. Dokumen yang kode discipline-nya tidak ada di daftar discipline tidak masuk grup mana pun, jadi tidak dihitung di mana-mana kecuali QTY (QTY mencocokkan kode, bukan join).
3. Baris issued: ts_documents project di-join ke ts_issued_status lewat issued_code, untuk issued status yang dipakai, di dalam jendela tanggal. Disimpan per nomor dokumen dan issued_id. Revisi _R (return) dan _C (comment) tidak dikecualikan di sini, berbeda dengan MDR Report.
4. Baris library terakhir per dokumen: ts_map_documents_library di-join ke ts_documents, di dalam jendela tanggal, satu baris per doc_number. Di MySQL berupa GROUP BY doc_number atas subquery yang diurutkan doc_send_received DESC, doc_rev DESC, yang mengandalkan MySQL mengembalikan baris pertama tiap grup; di SQL Server dan PostgreSQL berupa ROW_NUMBER() OVER (PARTITION BY doc_number ORDER BY doc_due_date DESC, doc_send_received DESC, doc_rev DESC). Kedua urutan itu berbeda: SQL Server dan PostgreSQL memilih due date terbaru dulu, MySQL tanggal diterima terbaru.

Tidak ada tabel routing yang dibaca. Report ini tidak peduli apakah sebuah revisi pernah di-routing.

Kolomnya

MDR Report Summary, preview HTML pada snapshot KTP · click to enlarge

Satu baris per discipline project, dalam urutan apa pun yang dikembalikan ts_docdiscipline (query-nya tidak punya ORDER BY), lalu baris Total dan baris Percentage. Kolomnya terbagi dua bagian yang memakai dua definisi berbeda tentang keadaan dokumen, dan itulah yang perlu diingat saat kedua bagian tidak sepakat: Latest Issuance melihat setiap baris library dokumen di dalam jendela, Status melihat satu baris, yang terbaru.

QTY dan baris discipline

Header dan discipline pertama: QTY, satu kolom Latest Issuance per status, Not Yet Submitted, Under Review dan satu kolom per return code · click to enlarge

Kolom	Nilai
Discipline	docdisc_code - docdisc_name, satu baris per baris discipline project, bahkan kalau tidak punya dokumen
QTY	baris MDR yang dm_discipline_identifier-nya sama dengan kode discipline. Dihitung dari daftar MDR datar, jadi dokumen yang kodenya tidak cocok dengan baris discipline mana pun tidak masuk QTY siapa pun dan tidak masuk kolom lain juga

Bagian Latest Issuance

Kolom	Nilai
satu kolom per issued status, urut gate	jumlah dokumen discipline itu yang punya minimal satu baris library dengan issued status itu di dalam jendela (query 3). Namanya menyesatkan: ini bukan issue terakhir. Dokumen yang melewati IFR, lalu IFA, lalu AFC dihitung sekali di masing-masing dari tiga kolom itu
Not Yet Submitted	dokumen discipline itu yang tidak punya baris library di issued status mana pun di dalam jendela

Dua hal mengikuti. Kolom-kolom ini bukan corong, jadi IFA bisa lebih besar dari IFR kalau dokumen masuk di IFA. Dan revisi _R dan _C dihitung seperti baris lain, yang tidak mengubah apa pun selama kembaran return membawa status yang sama dengan aslinya, tetapi membuat dokumen yang revisi aslinya berada sebelum awal jendela tetap terhitung lewat baris return-nya di dalam jendela.

Bagian Status

Kolom	Nilai
Under Review	dokumen discipline itu yang baris library terbarunya (query 4) punya doc_appdate kosong, tanggal sign-off approver
satu kolom per return code, urut doc_res_sort	dokumen yang baris terbarunya punya doc_appdate dan doc_res_id itu

Satu dokumen dihitung paling banyak sekali, dan bisa tidak dihitung di mana pun: baris terbaru dengan tanggal sign-off tetapi result code yang tidak ada di daftar project jatuh begitu saja, dan dokumen tanpa baris library di dalam jendela tidak punya baris terbaru sama sekali. Jadi Under Review ditambah kolom return code tidak sama dengan QTY, dan selisihnya bukan himpunan yang sama dengan Not Yet Submitted.

Baris terbaru biasanya kembaran return _R, karena doc_send_received-nya adalah tanggal return. Kembaran itu membawa result code dan tanggal sign-off yang sama dengan aslinya, jadi hitungannya sama; pengaruhnya hanya pada jendela, seperti dicatat di atas.

Baris Total dan Percentage

Baris total dan baris persentase di bawah discipline · click to enlarge

Baris	Nilai
Total	jumlah kolom atas semua discipline
Percentage	tiap total dibagi total QTY, sebagai persen bulat di HTML dan sel 0.00% di Excel. QTY sendiri selalu 100%. Persentase Latest Issuance bisa berjumlah jauh di atas 100, yang Status di bawahnya

Contoh, satu dokumen Civil di KTP

SNS-C-CC-10-002 (discipline C - Civil) punya sepuluh baris library: revisi A (IFR), B dan B1 (IFA), 0 dan 0R (AFC), masing-masing dengan kembaran return _R, semuanya di dalam jendela screenshot (2024-03-06 sampai 2026-02-04).

Bagian	Yang dilihat handler	Di mana dokumen dihitung
Latest Issuance	semua sepuluh baris: IFR, IFA dan AFC masing-masing muncul minimal sekali; ASB dan FI tidak pernah	IFR 1, IFA 1, AFC 1, ASB 0, FI 0, Not Yet Submitted 0
Status	baris terbaru saja: 0R_R, diterima 2025-02-05, doc_appdate 2025-02-05, doc_res_id 1 (AP, APPROVED)	APPROVED 1; tidak ada di Under Review atau kode lain

Jumlahkan 73 dokumen Civil dengan cara yang sama dan hasilnya baris di bawah.

Baris Civil di KTP

Project SNS pada snapshot, jendela 2024-03-06 sampai 2026-02-04, QTY 805. Baris C - Civil berbunyi:

QTY	IFR	IFA	AFC	ASB	FI	Not Yet Submitted	Under Review	AP	AC	NA	RC	FI
73	51	64	47	2	0	6	5	14 + 43 + 2	4	5	0	0

• IFA (64) lebih tinggi dari IFR (51): dokumen bisa masuk di IFA, dan dokumen dihitung di setiap status yang punya barisnya.
• Bagian Status di sini berjumlah sama dengan QTY: 5 + 59 + 4 + 5 = 73, jadi setiap dokumen Civil punya baris library di dalam jendela. Maka 6 "Not Yet Submitted" adalah dokumen yang barisnya membawa issued status di luar daftar, atau tidak ada sama sekali. Kedua bagian memakai definisi berbeda dan hanya cocok secara kebetulan.
• Di tingkat project tidak cocok: kolom Status berjumlah 764 dari 805. 41 dokumen lainnya tidak punya baris library di dalam jendela dan berada di dalam 100 "Not Yet Submitted".
• Kolom APPROVED terbagi tiga (14 / 43 / 2) karena KTP mengelompokkan tiap return code menurut issued status baris terbaru: IFR/IFA, AFC/FI, ASB. Master mencetak satu kolom per return code.

Baris total adalah 805 / 577 / 582 / 553 / 18 / 92 / 100 / 64 / 505 (21 + 505 + 2 dalam pembagian KTP) / 38 / 54 / 79 / 1, dan baris persentase membagi masing-masing dengan 805.

Masalah yang diketahui

• Pembagian dengan nol kalau project tidak punya baris MDR: baris persentase membagi dengan QTY.
• MySQL mengandalkan GROUP BY non-standar di query 4. Apakah baris yang dimaksud yang terpilih tergantung sql_mode server; handler ini tidak mengaturnya, handler Routing Overdue mengaturnya.
• "Baris terbaru" berbeda di driver berbeda, lihat query 4: SQL Server dan PostgreSQL mengurutkan due date dulu, MySQL tanggal diterima.
• Revisi return dan comment dihitung sebagai issuance di kolom Latest Issuance, karena query 3 tidak mengecualikan revisi _R dan _C.
• Dokumen bisa hilang dari bagian Status: baris terbaru yang result code-nya tidak ada di daftar project, atau dokumen tanpa baris di dalam jendela, tidak dihitung di mana pun, jadi kolom Status dan QTY tidak sepakat tanpa alasan yang terlihat.
• "Latest Issuance" salah nama. Kolomnya menghitung setiap status yang pernah punya baris untuk dokumen itu, bukan yang terakhir.
• Project tanpa baris MDR melewati query 3 (ist.issued_id in (%s) akan kosong), jadi setiap kolom issuance mencetak 0 dan Not Yet Submitted sama dengan QTY, yang juga 0.

Perbedaan antar instance

Diperiksa 2026-09-06 dengan diff handler.

Instance	Perbedaan
KTP (311 baris)	Menambah grup $approved_by_issued_codes (IFR, IFA; AFC, FI; ASB) dan baris header ketiga yang membagi setiap kolom return code berdasarkan grup itu. Query khusus MySQL (cabang driver tidak ada). Ada timer di sekitar eksekusi.
Timas (181 baris)	Layout lebih lama dari hitungan yang sama; MySQL saja.
Prima Energy (181 baris)	Versi sebelum query 3 ditulis ulang: satu query issuance per dokumen dan per status (sprintf dengan nomor dokumen dan issued_id di dalam loop), jadi waktu jalannya tumbuh sebesar baris MDR dikali status. Diperiksa lewat diff pada 2026-09-08, belum ditelusuri.
Medco (98 baris)	Kekhususan SQL Server di dua query dokumen.
Jadestone (8 baris)	Kosmetik; logika identik.
JOTRE	Identik dengan master.

Terkait

• MDR Report: versi berbobot.
• Report DMS.
• Setting DMS: tempat discipline, issued status dan return code dipelihara.