MDR Report

Kode report: mdr_report_2. Membuka modul documents_master dalam mode cetak (print=browse&print_browse=all&type=mdr_report_2); dispatcher documents_master_handler_print_browse.inc.php meng-include documents_master_handler_print_mdr_report_2.php, 2.051 baris, sepenuhnya memakai $pdo. Satu dokumen per baris, dikelompokkan per discipline dan document type, dengan Table Summary per discipline di sebelah kiri. Keluarannya halaman HTML di tab baru (Preview) atau .xlsx (Excel); keduanya berasal dari array yang sama, jadi angkanya identik.

Cara halaman ini diverifikasi

Ditelusuri query demi query di master pada 2026-09-06, lalu angkanya dicek manual terhadap snapshot produksi KTP (inact_ktp_eris, project SNS). Screenshot dari inact-ktp.eris.place pada snapshot itu. KTP menjalankan salinan handler yang lebih lama dan dikustomisasi; di mana berbeda, perbedaan antar instance menyebutkannya.

Form filter

view=custom merender documents_master_print_mdr_report_2_custom.htm. Form ini dikirim kembali sebagai GET dengan field berikut:

Field	Arti
`project`	project; default project pertama yang boleh dilihat user, dan form memilih project di header
`field[]`, `operator[]`, `what[]`	baris filter; operator `equals`, `not_equal`, `greater_than`, `less_than`, `less_than_equals`, `contains`, `start_with`, `not_contain`
`actual_date_from`, `actual_date_to`	d/m/Y; jendela summary, lihat di bawah. Tidak memfilter baris
`mdr_report_2_download_as`	`html` untuk Preview, `excel` untuk download
`person_id`	user, hanya dicetak di header

Setiap field filter diarahkan ke salah satu dari tiga query. Ini penting, karena field milik query library diam-diam membuang setiap dokumen yang tidak punya baris library:

Field di form	Diterapkan ke	Catatan
Document Number, Document Title	query MDR dan query routing	nama kolomnya berbeda (`dm_docmaster_number` / `rout_doc_number`)
Discipline, Document Category, Weight Factor, Contractor Name (`dm_originator_code`), dan kolom mana pun dari template MDR project	query MDR	Contractor Name ditulis ulang menjadi `company_code` untuk query routing
Rev	query routing (`mrf.rout_rev`)	menyalakan `$is_search_routing`: dokumen tanpa routing dibuang
Issued Status, Status Return, Incoming Transmittal, Outgoing Transmittal, Remarks, Date Received, Due Date, Date Returned, Originator	query library (`d.*`)	menyalakan `$is_search_doclib`: dokumen tanpa baris library dibuang. Tanggal dikonversi dari d/m/Y
Over Due Status	query library	`Equals` menyimpan baris yang due date-nya masih di depan (`doc_due_date − hari ini > 0`), punya issued status dan tanpa result code; `Not Equal` menyimpan sisanya. Sejak INA01-852 (master, 2026-09-07) dan INA27-302 (Jadestone) ekspresi tanggalnya bercabang per driver; JOTRE, Timas dan Medco masih membawa `DATEDIFF(day, ...)` khusus SQL Server, yang error di MySQL dan PostgreSQL. Lihat Masalah yang diketahui untuk apa yang sebenarnya dipilih filter ini
Document Status Flow	diterapkan di PHP setelah baris dibangun	`equals` hanya menyimpan keadaan itu, selain itu mengecualikannya

Beberapa baris pada field yang sama digabung dengan OR; field berbeda dengan AND.

Lima query, berurutan

Daftar referensi. Project, _getIssuedList() (issued status di-join ke ts_progress_gate, diurutkan sequence gate), discipline, document type, kolom template MDR (getProjectSelectedColumn), perusahaan.
MDR. ts_documents_master untuk project dengan filter MDR, diurutkan discipline lalu document type. Daftar ini menentukan dokumen mana yang tampil: dokumen yang ada di library tetapi tidak di MDR tidak pernah dicetak. Kunci grup: dm_discipline_identifier lalu dm_document_type; nilai kosong masuk grup 0.
Routing yang diabaikan. Dua hitungan atas ts_map_routing_to untuk routing terkirim (rout_have_send = 1) yang tidak ada di ts_routmaster_temp: penerima per routing, dan penerima dengan rout_is_oninbox = 0. Kalau keduanya sama, tidak ada lagi yang memegang routing itu di inbox dan routing masuk $routIdListWithNoUserInbox lalu dikecualikan dari langkah 4. Routing yang masih ada di ts_routmaster_temp juga dikecualikan di sana.
Routing per dokumen. ts_routing di-join ke ts_map_routing_file (rout_type = 1, file utama), ts_documents_master dan ts_documents lewat nomor dokumen, untuk routing terkirim, dengan revisi _R (return) dibuang. Diurutkan discipline, type, nomor dokumen, sequence progress gate, rout_id. Loop menyimpan satu baris per nomor dokumen dan revisi serta satu per dokumen; karena menimpa, baris terakhir yang menang: routing di gate tertinggi, dan di antaranya rout_id tertinggi. Revisi routing itu menjadi kolom Rev dan kunci pencarian library.
Baris library. ts_documents untuk project, revisi _R dibuang, di-join ke ts_doc_resultcode untuk status return, plus dua kolom hitungan: due_day (hari dari due date ke hari ini) dan due_day_return (hari terlambat saat return). Disimpan per nomor dokumen dan revisi, dan, hanya kalau revisi itu punya routing dari langkah 4, per nomor dokumen dan issued status. Indeks kedua inilah yang dibaca flag Issued Status, blok issue ordinal dan seluruh perhitungan progress. Baris library untuk revisi yang tidak pernah di-routing, atau routing-nya sudah keluar dari semua inbox, tidak terlihat oleh mereka.

Kolom per dokumen

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

Satu baris per dokumen MDR, dikelompokkan di bawah baris discipline dan baris document type. Tiap baris dibangun dari tiga record: baris MDR (ts_documents_master), routing yang dipilih di langkah 4, dan baris library (ts_documents) dari revisi routing itu, dipilih di langkah 5. Dua yang terakhir bisa tidak ada, dan sebagian besar sel yang sering diperdebatkan bermuara pada routing mana dan baris library mana yang dipilih.

Routing yang mana, baris library yang mana

Routing-nya adalah routing terkirim di progress gate tertinggi, dan di antara itu yang rout_id-nya paling besar. Routing yang sudah tidak ada di inbox siapa pun (langkah 3) dan routing yang masih ada di ts_routmaster_temp dilewati. Revisinya menjadi kolom Rev.
Baris library-nya adalah baris ts_documents dengan nomor dokumen itu dan revisi itu, baris return _R dikecualikan. Setiap kolom dari Status Recv sampai Over Due Status membaca satu baris ini. Kalau revisi yang di-routing tidak punya baris library, dokumen dicetak Not Received Yet dan sisa barisnya kosong.

Ambil SNS-C-CC-10-002 di screenshot. Library-nya menyimpan revisi A (IFR), B dan B1 (IFA), 0 dan 0R (AFC), masing-masing dengan kembaran _R. Routing di gate tertinggi adalah yang untuk 0R, jadi Rev adalah 0R, Status Recv adalah AFC, dan tanggal diterima, transmittal, due date dan status return adalah milik revisi 0R, apa pun yang terjadi pada A, B, B1 dan 0. Revisi yang lebih awal hanya muncul di flag Issued Status dan di blok issue ordinal.

Dokumen, bobot, progress dan revisi

Blok kolom pertama: dokumen, judul, discipline, bobot, progress, revisi routing dan status diterima · click to enlarge

Kolom	Sumber	Catatan
Document Number, Document Title	`dm_docmaster_number`, `dm_docmaster_title`	dari baris MDR
Discipline	label discipline grup	menampilkan Code Package Identifier kalau `project_vdr` menyala; flag itu di-hardcode `0`
Weight (%)	`dm_weight_factor`	kosong kalau 0 atau kosong
Progress (%)	Σ `progress_per_issued` atas semua status, lihat Progress	kosong kalau 0
Blok Issued Date: Plan Date, Actual Date, Progress (%) per issued status	hanya kalau template MDR mengaktifkan kolom `dm_plan_date_all_issued`	Plan Date selalu kosong: query MDR tidak memilih kolom itu. Actual Date adalah `doc_send_received` pertama di antara baris library dengan status itu. Progress (%) adalah `progress_per_issued` status itu
Rev	`rout_rev` dari routing yang dipilih	revisi routing, bukan revisi library terbaru
Status Recv	`issued_code` baris library	issued status saat revisi itu diterima

Diterima, di-review, dikembalikan

Blok kedua: tanggal diterima dan due date, transmittal, Document Status Flow, flag Issued Status dan Contractor Name · click to enlarge

Kolom-kolom ini mengikuti satu revisi sepanjang hidupnya, dan masing-masing ditulis oleh langkah routing yang berbeda. Tahu langkah mana yang menulis sebuah kolom menjelaskan kenapa kolom itu kosong.

Kolom	Kolom `ts_documents`	Ditulis saat
Date Received from Contractor	`doc_send_received`	revisi masuk library: transmittal in, upload MDR, atau publish D - Transmit
Incoming Transmittal	`doc_submission_number`	saat yang sama; nomor transmittal kontraktor
Due Date	`doc_due_date`	saat yang sama; `get_santos_duedate()` menambahkan waktu review dalam hari kerja ke tanggal diterima, melompati daftar National Holiday
Document Status Flow	turunan	lihat bagian berikutnya
Over Due	`due_day`, dihitung di query	hari ini dikurangi Due Date. Dicetak hanya selama baris masih Under review dan angkanya positif; kosong begitu approver sign-off, seterlambat apa pun pengembaliannya
Over Due Status	kata `Overdue`	aturan yang sama dengan Over Due
Status Return	`doc_res_name`, lewat `doc_res_id`	sign-off approver: Return Code yang dipilih di form sign-off
Outgoing Transmittal	`outgoing_transmittal_no`	transmittal return dibuat, lewat jalur mana pun: close approver dengan return mail, Ready to Return, atau return batch (`routing_handler_post.php`, `routing_handler_ajax.php`, `routing.inc.php`)
Date Returned to Contractor	`doc_issued_date`	praktis tidak pernah. Jalur return yang hidup menulis `doc_appdate` (tanggal sign-off, dicetak sebagai Date Return di blok issue) dan, di master sejak 2026-08, `doc_returned_date`. Hanya kode transmittal-register lama di `routing.inc.php` dan form edit library yang menulis `doc_issued_date`. Di snapshot KTP 0 dari 7.299 baris SNS mengisinya, itu sebabnya kolom ini kosong di setiap screenshot di sini
Remarks	`doc_notes`	catatan baris library

due_day adalah ekspresi per driver: DATEDIFF(CURRENT_TIMESTAMP, doc_due_date) di MySQL dan EXTRACT(DAY FROM CURRENT_TIMESTAMP - doc_due_date) di PostgreSQL, keduanya "hari sejak due date". Di SQL Server argumennya terbalik, DATEDIFF(day, CURRENT_TIMESTAMP, doc_due_date), hari menuju due date. Lihat Masalah yang diketahui.

Hanya Jadestone: Plan Date, Status dan Next Expected Submission

Project AKT Jadestone: tiga kolom INA27-298 berada di antara Date Received from Contractor dan Outgoing Transmittal · click to enlarge

Ditambahkan di Jadestone oleh INA27-298 (Done, masuk main 2026-09-06). Master dan fork lain tidak memilikinya.

Plan Date dibandingkan Date Received memberi Ahead, Late atau Achieve; Next Expected Submission mencetak kode beserta deskripsinya · click to enlarge

Kolom	Nilai	Kosong kalau
Plan Date	plan date yang diisi di tab MDR Progress untuk issued status dari revisi yang dicetak: `ts_mdr_progress.progress_content`, key `two`, entri `<Status Recv>`, field `plan_date`. Bukan `dm_plan_date_all_issued`, yang tidak ada di Jadestone	dokumen tidak punya baris progress, atau status itu tidak punya plan date
Status	Plan Date dibandingkan Date Received from Contractor, tanggal saja: `Late` kalau diterima setelah rencana, `Ahead` kalau sebelum, `Achieve` kalau di hari yang sama	salah satu tanggal tidak ada
Next Expected Submission	`next_expected_id` dari baris library yang sama, dicetak sebagai `kode - deskripsi` lewat `ts_issued_status` (`IFA - Issued for Approval`). `0`, NULL dan kosong dicetak kosong, berbeda dari nilai mentah di dalam Document Status Flow	approver tidak memilih apa pun. Seluruh kolom hilang kalau konfigurasi `enable_next_issue_code` mati, gerbang yang sama yang dipakai field Next Expected Submission lain (INA27-171). Plan Date dan Status selalu tampil

Output Excel punya tiga kolom yang sama di tempat yang sama. Handler memuat semua baris ts_mdr_progress project di awal untuk plan date; persentase progress tidak disentuh perubahan ini.

Document Status Flow

Dievaluasi pada baris library dari revisi yang di-routing, urut begini:

Kondisi, diperiksa urut	Teks	Kunci yang dipakai filter
tidak ada baris library, atau `issued_code` kosong	`Not Received Yet`	`not_received_yet`
`outgoing_transmittal_no` terisi	`<next_expected_id> - Not yet submitted by <perusahaan originator>`	`not_yet_submitted`
selain itu, `doc_res_name` terisi	`Return to <perusahaan originator>`	`return_to_contractor`
selain itu	`<issued_code> - Under <kode perusahaan owner> review`; kalau `due_day > 0` juga Over Due dan `Overdue`	`under_review`

Bacalah sebagai siklus hidup. Under review selama owner memegang dokumen. Return to begitu approver sudah sign-off tetapi transmittal return belum keluar. Not yet submitted begitu transmittal keluar, dan bola ada di kontraktor.

Status yang disebut di "Not yet submitted" bukan status saat ini. Itu next_expected_id, Next Expected Submission yang dipilih approver di form sign-off di samping Return Code (routing_resp.htm menolak sign-off tanpa keduanya). Itu sebabnya baris KTP di atas berbunyi AFC - Not yet submitted by KTP - KSO TIMAS PRATIWI pada revisi yang Status Recv-nya IFA dan Status Return-nya APPROVED: approver menyetujui IFA dan meminta AFC berikutnya. Isinya apa pun yang dipilih approver. Di snapshot KTP field ini berisi IFR, IFA, AFC, ASB, FI, FINAL, nilai 0 di 1.365 baris (opsi yang tidak dipilih) dan satu nan, dan report mencetaknya apa adanya, jadi 0 - Not yet submitted by ... adalah baris yang benar-benar ada.

Dua akibatnya. "Not yet submitted" menang atas "Return to" setiap kali ada nomor outgoing transmittal, bahkan kalau Return Code-nya penolakan. Dan dokumen yang dikembalikan tanpa nomor transmittal tetap di "Return to" selamanya.

Flag Issued Status dan Contractor Name

Issued Status: 1 kalau dokumen punya revisi ter-routing di status itu. Contractor Name adalah owner project di setiap baris · click to enlarge

Kolom	Nilai	Catatan
Issued Status, satu kolom per issued status project	`1` kalau dokumen punya minimal satu baris library di status itu yang revisinya punya routing dari langkah 4, selain itu `0`	berbeda dari Status Recv, flag melihat ke belakang ke semua revisi. `SNS-C-CC-10-001` mencetak 1 1 0: IFR dan IFA di-routing, dan revisi AFC `0`-nya hanya ada di library sebagai baris return `0_R`, jadi AFC tetap 0
Contractor Name	perusahaan yang `company_code`-nya sama dengan `dm_originator_code` baris MDR	query MDR memberi alias kode owner project sebagai `dm_originator_code`, jadi setiap baris mencetak owner (`KTP - KSO TIMAS PRATIWI`), tidak pernah originator dokumen. Medco memperbaikinya, lihat Perbedaan antar instance

Blok issue ordinal

Blok ordinal: satu set sembilan kolom per issue yang dilewati dokumen · click to enlarge

Di kanan Contractor Name report mengulang blok sembilan kolom per issue: 1st Issue [1], 2nd Issue [2], dan seterusnya. Jumlah bloknya adalah jumlah issued status terbanyak yang dicapai dokumen mana pun yang dicetak, jadi kalau satu dokumen melewati IFR, IFA, AFC dan ASB cetakannya punya empat blok untuk semua, dan dokumen yang mencapai lebih sedikit membiarkan sisanya kosong.

Untuk satu dokumen blok-bloknya adalah issued status-nya urut sesuai revisi pertama kali di-routing (urutan langkah 4: gate sequence, lalu rout_id): satu blok per status, bukan per revisi. Kolomnya:

Kolom	Sumber
Status	`issued_code`
Date Received	`doc_send_received`
Trans No.	`doc_submission_number`, transmittal masuk
Rev	`doc_rev`
Due Date	`doc_due_date`
Date Return	`doc_appdate`, tanggal sign-off approver
Over Due	`due_day_return`, hari keterlambatan pengembalian: `doc_appdate − doc_due_date` di PostgreSQL, `doc_issued_date − doc_due_date` di MySQL, `doc_due_date − doc_appdate` di SQL Server. Kosong kecuali positif
Trans No.	`outgoing_transmittal_no`, transmittal return
Return Status	`doc_res_name`

Dokumen dengan beberapa revisi di satu issue mencetaknya bertumpuk di dalam blok · click to enlarge

Kalau satu status punya beberapa baris library (revisi B dan B1 di IFA pada screenshot ini) setiap sel blok menumpuk nilainya dengan line break, satu baris per revisi, urut doc_no. Kolom utama tetap menampilkan satu revisi yang di-routing.

Karena MySQL menghitung Over Due ini dari doc_issued_date, yang sudah tidak diisi apa pun, kolom Over Due di blok kosong di setiap instance MySQL, termasuk KTP.

Progress

Setiap angka di kolom Progress dan di Table Summary dibangun dari satu besaran, progress_per_issued: progress yang diperoleh satu dokumen untuk satu issued status. Tiga masukan membentuknya.

Masukan	Asalnya	Di project SNS KTP
Weight factor dokumen	`ts_documents_master.dm_weight_factor`, diisi lewat Import MDR. Kolom `Weight (%)` di report	2,94 untuk sebagian besar dokumen; kosong di sebagian
Persentase issued status	progress gate tempat status itu bergantung (`ts_progress_gate`, di-join oleh `_getIssuedList()`). Tiap gate punya dua angka, Submission % dan Completion %, dijelaskan di bagian berikutnya	IFR 30 / 40, IFA 60 / 75, AFC 95 / 100, ASB 100 / 100, FI 100 / 100 (Submission % / Completion %)
Apakah dokumen mencapai status itu	baris library dengan `issued_code` itu yang revisinya di-routing, lihat query 5 di atas

Submission % dan Completion %, dua angka di balik gate

Referensi Progress Gate di Jadestone (Setting, Project, Multi Reference, Reference = Progress Gate, project AKT): satu baris per gate dengan Sequence, Gate Code, Submission % dan Completion % · click to enlarge

Nama kolom di ts_progress_gate adalah bagian paling membingungkan dari report ini, dan bagian yang pertama menjebak developer yang lama tidak menyentuh INACT. Layar menyebut dua angka itu Submission % dan Completion %. Tabel menyebutnya submission_progress dan percentage. Tidak ada apa pun di nama percentage yang menjelaskan yang mana, jadi bacalah sebagai Completion % setiap kali bertemu di kode.

Di layar	Kolom	Dokumen memperolehnya saat	Ditulis oleh
Submission %	`submission_progress`	revisi dipublikasikan ke Document Library di issued status itu. Itulah saat Document Control resmi menerima dokumen untuk di-review, dari situ namanya	`updateMDRProgress('two', ...)` di `tracking_function.inc.php`
Completion %	`percentage`	routing ditutup dan result code-nya adalah persetujuan (`ts_doc_resultcode.doc_res_action = approved`). Penolakan membiarkan Submission % tetap	`updateMDRProgress('three', ...)` di file yang sama

Keduanya masuk ke ts_mdr_progress.progress_content, key one, sebagai percentage_progress, dengan earned_value = weight_factor × percentage_progress / 100. Tab Progress di MDR menampilkannya, dan tombol Recalculate di sana mengulang aturan yang sama dari library.

Kapan langkah two berjalan tergantung apakah routing punya langkah D - Transmit (Document Control):

Routing dengan D. D sign-off, routing_handler_doccon_lib_publish.php menyalin file ke library, dan routing_handler_post.php memanggil updateMDRProgress('two', ...) tepat setelahnya. submitExtrans() di routing.inc.php, jalur transmittal-out yang mempublikasikan beberapa dokumen sekaligus, melakukan hal yang sama.
Routing tanpa D. Upload MDR itu sendiri yang mempublikasikan file (documents_master_multiupload_upload.php), dan langkah two langsung berjalan di sana, karena tidak akan ada langkah Document Control setelahnya.

Langkah three berjalan dari dua tempat, keduanya berarti "routing selesai": sign-off terakhir approver, tepat setelah email persetujuan terkirim (routing_handler_post.php), dan pembuatan transmittal return. updateMDRProgressThree membaca result code routing, dan hanya approved yang mengganti Submission % dengan Completion %.

Jadi di project SNS KTP, revisi IFA bernilai 60 pada hari Document Control mempublikasikannya dan 75 pada hari approver menutupnya dengan kode yang menyetujui. Di Jadestone kedua kolom sama di setiap gate (50 / 50, 70 / 70, 100 / 100), jadi perbedaannya tidak pernah terlihat di sana.

Aturannya, per dokumen dan per issued status, urut gate:

kalau dokumen tidak pernah mencapai status itu:   progress_per_issued = 0
selain itu:
    pct = Submission % gate   (master: selalu, karena query yang hilang)
    pct = Completion % gate   (KTP: kalau revisi issue itu disetujui)
    progress_per_issued = weight_factor × pct / 100

Lalu nilai yang sama ditambahkan di tiga tempat, asalkan Actual Date issue itu ada di dalam jendela summary (tanpa jendela: selalu):

Progress (%) dokumen, jumlah atas status-statusnya;
sel <issued> (%) discipline di Table Summary, jumlah atas dokumen-dokumen discipline itu;
baris Total Table Summary, jumlah se-project.

Contoh, tiga dokumen Civil di KTP

Dokumen	Bobot	Dicapai	IFR	IFA	AFC	ASB	FI	Progress (%)
`SNS-C-CC-10-001`	2,94	IFR disetujui, IFA disetujui. Revisi AFC `0` di-routing tetapi satu-satunya baris library-nya adalah return `0_R`, jadi AFC tidak dihitung	2,94 × 40% = 1,18	2,94 × 75% = 2,21	0	0	0	3,38
`SNS-C-CC-10-002`	2,94	IFR disetujui, IFA disetujui, AFC disetujui di `0R`	2,94 × 40% = 1,18	2,94 × 75% = 2,21	2,94 × 100% = 2,94	0	0	6,32
`SNS-C-CC-10-023`	kosong	tidak pernah diterima	0	0	0	0	0	kosong
Baris summary untuk ketiganya		Total Doc Submitted 3	2,35	4,41	2,94

Dua angka tebal di kolom Progress adalah yang ada di screenshot KTP, 3,38 dan 6,32. Master akan mencetak 2,65 dan 5,44 untuk baris yang sama, karena selalu mengambil Submission % (30, 60, 95). Dokumen ketiga tetap dihitung 1 di Total Doc Submitted walau tidak pernah diterima; kolom itu menghitung baris MDR, bukan penyerahan.

Baca seluruh discipline dengan cara yang sama: C - Civil di KTP punya Total Doc Submitted 73, IFR 39,98, IFA 79,38, AFC 101,58. Tiap sel itu adalah jumlah kolom progress_per_issued atas 73 dokumen; IFA lebih besar dari IFR karena persentase IFA lebih besar, dan AFC lebih besar lagi karena sebagian besar dokumen Civil mencapainya di 100%. Tidak ada yang dibagi dengan apa pun: selnya jumlah bobot × persentase, jadi tumbuh dengan jumlah dokumen dan melewati 100 begitu bobotnya berjumlah lebih dari 100.

Dua hal yang terus ditemukan ulang tim:

Satu status dihitung sekali per dokumen, berapa pun revisi yang di-issue di bawahnya. Tiga revisi IFA tetap memberi satu kontribusi IFA.
Status yang tidak dicapai tidak menyumbang apa-apa di master. Salinan KTP membawa nilai status sebelumnya ke sel kosong summary, itu sebabnya kolom ASB-nya sama dengan kolom AFC; master membiarkan ASB kosong sampai dokumen benar-benar di-issue As Built.

Total grup

Baris Total, discipline dan document type membawa jumlah dokumen, jumlah bobot dan jumlah progress · click to enlarge

Setiap baris grup (discipline, document type, baris Total) menampilkan jumlah dokumen, jumlah weight factor dan jumlah Progress (%). Hitungannya atas baris MDR yang lolos filter, diterima atau tidak.

Table Summary

Tabel di sebelah kiri, berjudul Table Summary (Actual Date from <min> to <max>). Tanggalnya adalah jendela dari form, atau, kalau kosong, doc_send_received paling awal dan paling akhir di antara dokumen yang dicetak.

Kolom	Nilai
Discipline	satu baris per discipline yang punya baris MDR
Total Doc Submitted	jumlah baris MDR di discipline itu, diterima atau tidak. Namanya menyesatkan; dokumen `Not Received Yet` ikut di dalamnya
`<issued> (%)`, satu per issued status	Σ `progress_per_issued` status itu atas dokumen discipline, di dalam jendela. Kosong kalau 0
Total	jumlah yang sama se-project

Karena setiap sel adalah jumlah bobot × persentase, kolom-kolomnya terbaca sebagai poin progress yang diperoleh per status, dan bisa melebihi 100 kalau bobotnya besar atau banyak dokumen melewati status itu. Project yang MDR-nya tidak punya weight factor menampilkan summary kosong: setiap hasil kali 0 dan 0 dicetak kosong. Itu sebabnya screenshot Jadestone untuk report ini punya daftar dokumen penuh dan summary kosong.

Jendelanya

Field actual_date_from / actual_date_to tidak memfilter daftar dokumen; keduanya menentukan issue mana yang dihitung dalam penjumlahan. Actual Date sebuah issue adalah doc_send_received pertama di antara baris status itu. Issue di luar jendela tetap menampilkan 1 di flag Issued Status dan tanggalnya di blok ordinal, tetapi tidak menambah apa pun ke Progress (%) maupun summary. Atur jendela ke satu bulan untuk mendapatkan progress yang diperoleh bulan itu per discipline.

Masalah yang diketahui

Progress tidak pernah memakai Completion % di master (query ts_mdr_progress yang hilang di atas). Port query KTP atau buang cabangnya; sekarang report dan tab Progress MDR tidak sepakat.
Filter Over Due Status: sudah diperbaiki di master dan Jadestone, masih rusak di tempat lain, dan memilih baris yang salah di mana pun. DATEDIFF(day, CURRENT_TIMESTAMP, d.doc_due_date) yang di-hardcode error di MySQL dan PostgreSQL; INA01-852 (master, 2026-09-07) dan INA27-302 (Jadestone) mencabangkannya per driver, JOTRE dan Timas (MySQL) masih error, Medco (SQL Server) tidak pernah error. Tetapi di setiap driver filter menghitung doc_due_date − hari ini dan Equals menyimpan baris yang nilainya positif, jadi "Over Due Status equals" mengembalikan dokumen yang masih di dalam waktu review-nya. Itu cocok dengan kolom Over Due yang terbalik di SQL Server dan bertentangan dengan kolom yang benar di MySQL dan PostgreSQL.
Over Due terbalik di SQL Server. due_day dan due_day_return sama-sama punya argumen yang terbalik di cabang sqlsrv. Kolom Over Due utama menghitung hari menuju due date dan menempelkan Overdue pada dokumen yang masih di dalam waktu review, dan Over Due di dalam blok issue menampilkan pengembalian yang lebih awal, bukan yang terlambat. Medco berjalan di SQL Server.
Date Returned to Contractor selalu kosong, dan di MySQL begitu juga Over Due di dalam blok issue: keduanya membaca doc_issued_date, yang tidak pernah ditulis jalur return yang hidup (KTP: 0 dari 7.299 baris). doc_appdate, atau doc_returned_date di master, adalah kolom yang menyimpan tanggal pengembalian.
Document Status Flow mencetak next_expected_id mentah, jadi approver yang tidak memilih Next Expected Submission menghasilkan 0 - Not yet submitted by ... (1.365 baris di KTP).
Plan Date selalu kosong. Query MDR memilih enam kolom dan dm_plan_date_all_issued bukan salah satunya.
Baris library tanpa routing tidak terlihat oleh flag Issued Status, blok issue dan progress. Dokumen yang diterima lewat transmittal tetapi tidak pernah di-routing dicetak Not Received Yet dengan Issued Status semua 0.
Routing yang sudah keluar dari semua inbox diabaikan (langkah 3), jadi dokumen yang satu-satunya routing sudah selesai diproses jatuh ke routing lebih lama atau tidak ada.
Contractor Name adalah owner project untuk setiap baris, bukan originator dokumen.
Label header "MDR Report Sumary" di menu adalah typo seed; judul report ini sendiri benar.

Perbedaan antar instance

Diperiksa 2026-09-06 dengan diff handler.

Instance	Perbedaan
KTP (`ina-ktp`, 340 baris berbeda)	Query `ts_mdr_progress` ada, jadi issue yang disetujui memakai Completion % gate. Untuk status yang belum dicapai dokumen, sel summary membawa nilai status sebelumnya (`$progress_summary_from_prev_issued_code`), yang membuat summary kumulatif. Nilai field form memakai nama lama `doc_number` / `doc_title` dan ada filter `Remarks (MDR)`. Contractor Name adalah owner project, seperti master.
Jadestone (68 baris)	Form lebih lama (`docmasterMakeFieldCol`), tanpa filter kolom template; kolom transmittal-nya "Outgoing Transmittal" dan "Return Transmittal", bukan "Incoming" dan "Outgoing". Membaca `ts_mdr_progress` hanya untuk kolom Plan Date, jadi progress masih menilai setiap issue dengan Submission %. Tiga kolom tambahan setelah Date Received from Contractor: Plan Date, Status dan Next Expected Submission, lihat di atas. Weight factor hanya ada di 27 dari 55 baris AKT (snapshot 2026-09-07); AAL dan AAL-VS tidak punya, jadi summary-nya kosong. INA27-302 (Done): filter Over Due Status jalan di MySQL, lihat Masalah yang diketahui. Heading Report-nya berbunyi "Project".
JOTRE (101 baris)	Membaca `dm_phase` dan menurunkan nomor urut dari nomor dokumen. Query hilang yang sama dengan master.
Timas (111 baris)	Mode `condition=B` mengelompokkan per discipline dan package, plus sebelas field filter MDR tambahan (`dm_pic_document`, `dm_wp_no`, `dm_package_number`, ...). Query hilang yang sama.
Prima Energy (78 baris)	Form lebih lama (`docmasterMakeFieldCol`, tanpa filter kolom template) dan filter Over Due Status yang belum bercabang, jadi filter itu error di instance MySQL ini. Diperiksa lewat diff pada 2026-09-08, belum ditelusuri.
Medco (8 baris)	Contractor Name berasal dari `dm_originator_code` di baris MDR, originator sebenarnya, bukan owner project.

Terkait

Report DMS: entri lain dan cara dispatch-nya.
MDR Report Summary: pendamping berbasis hitungan.
Import MDR: asal weight factor dan discipline.
Upload: yang membuat baris library dan routing yang dibaca report ini.

Master Doc. Register

Document Routing

DMS

MDR Report

Form filter

Lima query, berurutan

Kolom per dokumen